저는 운영 중인 프로젝트에서 Claude Code를 실행했습니다. 워커(workers) 배포, 파일 편집, 빌드 실행 등을 수행했습니다. 그 후 전체 트랜스크립트(transcript)를 분석했습니다. 한 세션 동안 152번의 명령 실패가 발생했습니다.

실패 자체는 놀라운 일이 아니었습니다. 존재하지 않는 잘못된 플래그(flags), 반복적으로 시도되는 누락된 바이너리(binaries), Bash 구문 오류(syntax errors) 등 일반적인 AI 에이전트의 실수들이었습니다.

정작 문제가 된 것은 재시도(retries)였습니다.

에이전트는 gh: 명령어를 찾을 수 없다는 오류를 겪었습니다. 실패했습니다. PowerShell에서 다시 시도했습니다. 실패했습니다. 세션 동안 세 번을 더 시도했습니다. 설치된 적도 없는 바이너리를 실행하기 위해 다섯 번이나 시도한 것입니다.

wrangler deploy의 경우도 마찬가지였습니다. 라우트 설정(route config)이 잘못되었습니다. 에이전트는 한 가지를 수정하고 재시도했습니다. 여전히 잘못되었습니다. 다시 수정했습니다. 동일한 잘못된 설정에 대해 여덟 번을 시도했습니다.

모든 실패는 에러 출력(error output)을 컨텍스트 윈도우(context window)에 쏟아붓습니다. 모든 재시도는 해당 에러를 계속 전달하는 또 다른 추론(inference) 호출이 됩니다. 컨텍스트는 점점 무거워지고 비용은 복리로 증가합니다.

저는 실행 전 훅(pre-execution hook)을 사용하여 세션을 재시작했습니다. 에이전트가 생성하는 모든 명령은 셸(shell)에 도달하기 전에 검증(validation) 과정을 거칩니다. 명령이 작동하지 않을 경우 — 잘못된 플래그, 누락된 바이너리, 잘못된 구문 등 — 차단됩니다. 에이전트는 에러를 아예 보지 못하므로 재시도도 하지 않습니다.

동일한 프로젝트, 동일한 종류의 작업이었습니다. 단 한 번의 실패가 발생했습니다. 그 실패는 대용량 파일을 파싱하는 과정에서 발생한 PowerShell 구문의 엣지 케이스(edge case)였습니다. 환각(hallucinated)된 명령이 아니었습니다.

재시도는 줄어들지 않은 것이 아니라, 거의 사라졌습니다.

수치로 보는 전체 분석: 검증(Check) 기능이 없을 때 152번의 명령 실패. 검증 기능이 있을 때 1번의 실패.

(https://www.golproductions.com/blog/check-if-url-is-reachable-without-visiting.html)