Anthropicが 공식 포스트모템을 공개했다. 지난 한 달간 Claude Code 사용자들이 체감한 품질 저하의 원인이 세 가지 독립적인 변경의 복합 충돌이었다는 사실을, 이번엔 꽤 솔직하게 털어놨다. 추론 강도 기본값을 high에서 medium으로 낮춘 결정, 유휴 세션에서 추론 기록을 매 턴 삭제한 캐싱 버그, 그리고 단 한 줄의 시스템 프롬프트가 일부 모델 성능을 3% 끌어내린 사건. 이 세 가지는 서로 다른 타이밍에, 서로 다른 트래픽 구간에 영향을 주면서 '광범위하지만 일관되지 않은 품질 저하'처럼 보이게 만들었다.
사건의 구조를 들여다보면 흥미로운 패턴이 드러난다. 첫 번째 실수는 지표 기반 의사결정의 함정이다. 내부 평가에서 medium 추론 강도가 '지능은 약간 낮고 지연은 크게 줄어드는' 결과를 냈을 때, 팀은 그것을 수용 가능한 트레이드오프로 판단했다. 하지만 실제 사용자는 달랐다. 인라인 effort 선택기, 시작 알림, ultrathink 복구 옵션까지 여러 디자인 변경을 추가해도 대부분의 사용자는 medium 기본값에 머물렀고, 결국 '덜 똑똑해진 느낌'이라는 피드백이 쌓였다. 벤치마크가 체감을 대체할 수 없다는 오래된 교훈이 다시 증명된 셈이다.
두 번째 사건이 더 심각하다. 캐싱 최적화 버그는 단순한 코드 결함이 아니라 분산 시스템에서 코너 케이스가 얼마나 교묘하게 숨는지를 보여준다. 유휴 임계값(1시간)을 넘긴 세션에서만 발생하는 문제였고, 여러 코드 리뷰와 단위 테스트, 종단간 테스트, 심지어 dogfooding까지 통과했다. 근본 원인을 발견하는 데 1주일이 넘게 걸린 이유가 여기 있다. 흥미로운 건 사후 조사 과정에서 Anthropic이 Opus 4.7로 문제의 PR을 백테스트했을 때, Opus 4.7은 버그를 찾아냈지만 4.6은 찾아내지 못했다는 점이다. AI가 AI의 버그를 잡는 흐름이 실제 프로덕션 워크플로우로 자리 잡기 시작하고 있다.
세 번째 사건은 프롬프트 엔지니어링의 리스크를 정면으로 건드린다. 장황한 출력을 줄이기 위해 시스템 프롬프트에 추가한 한 줄—"Length limits: keep text between tool calls to ≤25 words. Keep final responses to ≤100 words unless the task requires more detail."—이 수주간의 내부 테스트에서는 회귀를 보이지 않다가, 더 넓은 평가 세트로 ablation을 수행하자 비로소 3% 하락이 확인됐다. 시스템 프롬프트 한 줄이 모델 지능에 과도한 영향을 줄 수 있다는 사실, 그리고 그 영향을 좁은 평가 세트로는 감지할 수 없다는 사실—이 두 가지가 이번 포스트모템에서 가장 실무적인 교훈이다.
이 지점에서 dev.to에서 주목받고 있는 'CLAUDE.md를 실패 로그로 쓰라'는 접근법이 맞닿는다. Mitchell Hashimoto(Terraform, Vagrant 제작자)가 Ghostty의 AGENTS.md를 운영하는 방식은 단순하다. 모든 줄은 에이전트가 실제로 저지른 실수에서 비롯된다. 포부나 가이드라인이 아니라, 날짜와 함께 기록된 사고 보고서가 곧 제약 조건이 된다. ETH Zurich 연구에 따르면 LLM 생성 에이전트 파일은 오히려 성공률을 0.5~2% 낮추면서 추론 비용을 20~23% 늘렸다. 반면 개발자가 직접 작성한 파일은 평균 4% 성능 향상에 그쳤고, 평균 641단어 9.7섹션이었다. 이 숫자들이 말하는 건 분명하다—지시어가 많다고 에이전트가 더 잘 따르지 않는다.
실패 기반 제약 설계의 핵심은 라우팅 결정에 있다. 에이전트가 실수를 저질렀을 때, 그 실수를 어느 레이어에 귀속시킬지를 먼저 판단해야 한다. 되돌릴 수 없거나 위험한 행동(force push, 프로덕션 파일 삭제)은 Hook으로, 반복 가능한 워크플로우는 Command로, 스타일과 컨벤션은 CLAUDE.md로. 이 결정 트리 없이 모든 실수를 CLAUDE.md에 쌓으면 파일은 점점 무거워지고 준수율은 60% 이하로 떨어진다. Hook은 셸 스크립트로 100% 강제 적용이 가능하지만, CLAUDE.md는 LLM 컨텍스트 안에서 확률적으로만 작동한다는 근본적 차이가 있다.
AI 코딩 툴 비교 관점에서 이번 포스트모템은 또 다른 함의를 갖는다. Claude Code는 현재 SWE-bench Verified에서 최고 점수를 기록한 에이전트지만, 동시에 가장 많은 운영 리스크를 안고 있는 도구이기도 하다. 계정 밴 리스크, 5시간 단위 토큰 윈도우, 시스템 프롬프트 변경에 따른 예측 불가능한 성능 변동—이 세 가지는 팀 단위 도입에서 반드시 사전에 설계해야 할 변수다. 실제로 Hacker News 커뮤니티에서는 이번 품질 저하 사태를 계기로 ChatGPT, Gemini, 심지어 이전 버전 Claude 4.5로 이동했다는 사용자들의 목소리가 꽤 눈에 띄었다.
세 가지 사건을 하나의 프레임으로 묶으면 이렇게 된다. 에이전트 운영은 배포가 아니라 관찰과 제약의 반복이다. Anthropic이 공개한 재발 방지 계획—내부 빌드와 공개 빌드 차이 축소, 시스템 프롬프트 변경의 ablation 의무화, 점진적 롤아웃 강제—은 사실 모든 AI 에이전트를 실무에 연결하려는 팀이 자체적으로 설계해야 할 구조와 다르지 않다. Anthropic 규모의 조직도 좁은 평가 세트와 내부 재현 실패로 한 달을 허비했다면, 작은 팀이 '그냥 믿고 써보기'로 운영할 경우 무슨 일이 생길지는 상상하기 어렵지 않다.
앞으로 AI 코딩 에이전트의 성숙도는 모델 벤치마크 점수보다 운영 설계의 정밀도로 갈릴 가능성이 높다. 어떤 변경이 어느 레이어에서 어떤 조건 하에 작동하는지 이해하고, 실패를 기록하고, 그 기록을 제약으로 변환하는 루프—이것이 Claude Code 포스트모템이 진짜로 가르쳐주는 것이다. 도구의 성능 곡선은 Anthropic이 관리하지만, 그 도구를 실무에서 안전하게 작동시키는 구조는 여전히 개발자의 몫이다.