Anthropic April 23 Postmortem: Claude Code 품질 저하 3가지 원인과 거버넌스 교훈
Anthropic April 23 Postmortem: Claude Code 품질 저하 3가지 원인과 거버넌스 교훈
비유: 비행기 추락 사고 보고서를 읽는 항공 엔지니어가 된 기분이다. 엔진 결함, 조종사 실수, 기상 악화. 하나만 있어도 무사했을 사고를 세 가지가 동시에 만나서 터졌다.
지난 한 달간 Claude Code가 갑자기 멍청해졌다는 사용자 보고가 끊이지 않았다. 같은 프롬프트인데 답변이 짧아졌고, 코드를 작성하다가 맥락을 잊어버렸고, 사용량이 평소보다 빠르게 소진되었다. 2026년 4월 23일, Anthropic은 이 모든 보고를 조사한 결과를 공식 블로그에 공개했다. 결론은 충격적이다. 3가지 별개의 변경이 동시에 진행되어 진단이 거의 불가능했다.
이 글에서는 Anthropic의 공개 사후분석을 바탕으로 (1) 정확히 무슨 일이 있었는지, (2) 왜 검증을 통과한 버그가 라이브에서 터졌는지, (3) 1인 기업과 AI 도구 사용자가 배워야 할 거버넌스 교훈을 정리한다.
한 달간의 미스터리: Claude는 정말 멍청해졌는가
먼저 영향 범위를 명확히 한다. Anthropic 발표에 따르면 이번 사건의 영향을 받은 제품은 Claude Code, Claude Agent SDK, Claude Cowork 세 가지다. 일반 API는 영향을 받지 않았다. 즉, 직접 Anthropic API를 사용하는 개발자는 큰 변화를 느끼지 못했지만, Claude Code CLI를 사용하는 개발자들은 한 달 내내 답답함을 호소했다.
GitHub anthropics/claude-code 저장소에는 4월 한 달간 관련 이슈가 폭증했다. Issue #49244 (2026-04-16, Genaxa-Studio 보고)에는 "Opus 4.6이 4월 15일부터 명백히 품질이 저하됨"이라는 제목이 달렸고, Issue #49585 (2026-04-16, deafsquad 보고)는 smoosh 파이프라인 캐시가 깨져 cache hit률이 99.8%에서 급락했다는 분석을 담고 있다. AMD AI 시니어 디렉터 Stella Laurenzo는 GitHub #42796에서 6,852개 세션을 분석해 thinking depth가 67% 하락했고 월 청구액이 $345에서 $42,121로 폭증한 케이스를 입증했다.
사용자들이 미친 게 아니었다. 정말 뭔가 잘못되어 있었다.
원인 1: 3월 4일 — 추론 effort 기본값 변경
첫 번째 원인은 가장 단순하지만 가장 아이러니하다. 3월 4일, Anthropic은 Claude Code의 기본 추론 effort를 high에서 medium으로 낮췄다. 영향을 받은 모델은 Sonnet 4.6과 Opus 4.6이었다.
이유는 의외로 사용자 친화적이었다. high effort 모드에서 Claude가 너무 오래 사고하다 보니, 일부 사용자들이 "UI가 멈춘 것 같다"고 느꼈다는 피드백이 있었다. 1분 가까이 응답이 없으면 사용자는 응답을 포기하고 닫아버린다. 이를 해결하기 위해 기본값을 한 단계 낮춘 것이다.
결과는 정반대였다. 사용자들은 "지능이 떨어진 것 같다"는 피드백을 폭주시켰다. 한 달 사이에 Anthropic이 깨달은 것은 명확했다.
사용자가 원한 건 빠른 응답이 아니라 똑똑한 응답이었다.
4월 7일, Anthropic은 결정을 뒤집었다. 기본값을 다시 high로 되돌리고, "단순 작업에 한해서만 낮은 effort를 opt-in 방식으로" 제공하기로 했다. 현재 Opus 4.7의 기본값은 한 단계 더 높은 xhigh이다.
이 사례에서 가장 중요한 교훈은 "좋은 의도"가 사용자 가치와 충돌할 수 있다는 점이다. UX팀은 "응답 속도"를 최적화하려 했지만, 실제 사용자는 "응답 품질"을 더 우선시했다. AI 도구는 일반 SaaS와 다르다. 응답 한 번이 1분 걸리더라도 정확한 답을 주는 것이 중요한 사용자가 다수다.
원인 2: 3월 26일 — 캐싱 최적화 버그
두 번째 원인은 가장 기술적이고 가장 충격적이다. 3월 26일에 배포된 캐싱 최적화 코드에 버그가 있었다.
배경부터 보자. Claude Code는 사용자가 1시간 이상 idle 상태에서 세션을 재개할 때, 비용 절감을 위해 오래된 thinking 섹션을 일부 삭제하는 최적화를 도입했다. 사용된 헤더는 clear_thinking_20251015이고 옵션은 keep:1로 단 한 번만 삭제하도록 설계되어 있었다.
문제는 코드 구현이 의도와 달랐다는 것이다. 임계값을 통과하면 단 1회 삭제되어야 했는데, 실제로는 매 턴마다 삭제가 발생했다. 즉, Claude가 매번 자신의 추론 이력을 잃어버린 셈이다.
결과는 정확히 사용자들이 호소한 증상과 일치했다.
- 망각: 같은 세션에서 이전에 한 결정을 기억 못 함
- 반복: 이미 시도한 접근을 또 시도함
- 이상한 도구 선택: 맥락 없이 부적절한 도구 호출
- 사용량 폭증: cache miss 누적으로 토큰 비용이 빠르게 소진
특히 사용량 폭증은 이중 타격이었다. 캐시가 깨지면서 매번 전체 컨텍스트를 다시 보내야 했고, 이는 Pro/Max 5x/Max 20x 모든 플랜의 사용량 한도를 빠르게 소진시켰다. fordelstudios.com 분석에 따르면 단일 프롬프트가 세션 quota의 3-7%를 소비하는 케이스가 보고되었다.
검증을 통과한 버그라는 패러독스
이 버그가 더욱 충격적인 이유는 Anthropic의 모든 검증 단계를 통과했다는 점이다. 공식 발표에 따르면 다음을 모두 통과했다.
- 다중 인간 리뷰
- 자동 코드 리뷰
- 단위 테스트
- E2E 테스트
- 자동 검증
- 내부 dogfooding (Anthropic 직원이 직접 사용)
그런데 라이브에서 터졌다. 이 모순을 풀기 위해 Anthropic 엔지니어들은 사후 디버깅에 들어갔다. 결과는 흥미롭다.
두 가지 별개의 실험이 CLI 세션에서 이 버그를 가리고 있었다. 첫 번째는 서버 사이드 메시지 큐잉 실험이었고, 두 번째는 thinking 표시 변경 실험이었다. 이 두 실험이 켜진 환경에서는 캐시가 매 턴 삭제되더라도 사용자에게 보이는 증상이 다르게 나타났다. dogfooding을 했던 직원들은 우연히 다른 실험군에 속해 있었던 것이다.
여기서 더 흥미로운 디테일이 등장한다. Anthropic 팀은 "같은 코드 리뷰를 Opus 4.7로 백테스트해보자"라고 제안했다. 결과는 의미심장했다.
- Opus 4.7는 버그를 발견했다.
- Opus 4.6는 발견하지 못했다.
같은 회사의 자기 모델로 자신의 사고 과정을 검증한 결과, 다음 세대 모델(4.7)이 이전 세대(4.6)의 사각지대를 비추는 역할을 한 것이다. 이는 모델 진화가 단순히 답변 품질을 올리는 게 아니라 검증 도구로서의 가치도 함께 진화한다는 것을 보여준다.
이 캐싱 버그는 4월 10일 v2.1.101에서 수정되었다.
원인 3: 4월 16일 — 시스템 프롬프트 한 줄
세 번째 원인은 가장 짧지만 가장 의외다. 4월 16일, Anthropic은 시스템 프롬프트에 두 줄을 추가했다.
Length limits: keep text between tool calls to ≤25 words.
Keep final responses to ≤100 words unless the task requires more detail.
배경은 합리적이었다. 새로 출시된 Opus 4.7은 똑똑하지만 verbose했다. 출력 토큰이 평균적으로 많아 비용이 늘었고 일부 사용자는 답변이 길다고 느꼈다. 이를 완화하기 위해 시스템 프롬프트로 응답 길이를 제한하는 가벼운 수정을 한 것이다.
검증은 다중 주차에 걸쳐 진행되었고, 표준 평가 세트에서 회귀가 발견되지 않았다. 그러나 사후 ablation(시스템 프롬프트의 각 줄을 제거하면서 영향을 측정하는 실험)에서 충격적인 결과가 나왔다. 이 두 줄을 제거하니 Opus 4.6과 4.7 모두에서 한 평가 항목에서 3% 점수 하락이 사라졌다.
번역하면, 이 두 줄이 평가 점수를 3% 낮추고 있었다. 더 중요하게는, 이 영향은 모델이 출시된 후에야 ablation으로 발견되었다. 표준 평가 세트는 이 변화를 잡지 못했다.
4월 20일, Anthropic은 즉시 revert했다. 이 사례는 시스템 프롬프트가 production 코드와 같은 수준의 검토를 받아야 한다는 사실을 입증한다.
1인 기업이 배워야 할 5가지 거버넌스 교훈
이 사건은 Anthropic 같은 회사도 incident가 발생한다는 점을 보여준다. 우리 같은 1인 기업은 더 적은 자원으로 더 빠르게 변경을 푸시한다. 그렇다면 어떤 교훈을 적용해야 할까?
교훈 1: Multi-confounding을 피하라
Anthropic의 가장 큰 실수는 3개 변경을 짧은 기간에 동시에 진행한 것이다. 각각은 독립적으로 합리적이었지만, aggregate 효과는 broad하고 inconsistent하게 보였다. 사용자들이 "뭔가 이상하다"고만 말할 수 있었지 정확히 무엇이 잘못되었는지 짚을 수 없었다.
1인 기업도 마찬가지다. 같은 주에 가격 변경, UX 개편, 새 기능 출시를 동시에 하면 어느 변경이 매출에 영향을 주는지 알 수 없다. 한 번에 한 변수가 디버깅 가능성의 기본이다.
교훈 2: Eval blind spot을 인지하라
Anthropic이 통과시킨 검증 시스템은 단순한 게 아니었다. 다중 인간 리뷰, 자동 리뷰, 단위/E2E 테스트, dogfooding까지 풀 패키지였다. 그런데 버그가 통과했다.
이는 모든 평가 시스템에는 사각지대가 있다는 사실을 의미한다. 우리가 평가 통과를 "안전"의 증거로 받아들이는 순간, 평가 시스템 자체의 한계에 노출된다. 정기적으로 ablation, 백테스트, 실제 사용자 행동 분석으로 평가 시스템 자체를 검증해야 한다.
교훈 3: 사용자 피드백을 default 결정에 반영하라
3월 4일 effort 기본값 변경은 "일부 사용자 불편" 피드백을 듣고 진행되었다. 결과는 더 큰 사용자 반발이었다. Anthropic은 4월 7일 결정을 뒤집고 "더 똑똑한 게 default여야 한다, 단순 작업은 opt-in"으로 정책을 바꿨다.
여기서 배울 점은 사용자가 명시적으로 푸시백할 때 이를 default 결정에 반영해야 한다는 것이다. AI 회사들이 종종 빠지는 함정인 sycophancy(아첨)의 정반대 사례다. 사용자가 "이건 아니다"라고 말하면 듣고 바꿔야 한다.
교훈 4: 시스템 프롬프트는 production 코드다
"≤25 words"와 "≤100 words" 두 줄이 평가 항목 3% 하락을 만들었다. 시스템 프롬프트는 코드처럼 변경 관리되어야 한다.
- 모든 변경에 ablation 테스트 (한 줄씩 제거해보고 영향 측정)
- Soak periods (배포 후 일정 기간 모니터링)
- 점진적 롤아웃 (전체 사용자가 아닌 일부부터 시작)
- 회귀 평가 세트 갱신 (기존 평가가 잡지 못한 경우 평가 자체를 보강)
1인 기업이라면 LLM 프롬프트 변경을 git으로 관리하고, A/B 테스트를 통해 변경 영향을 측정하는 것부터 시작할 수 있다.
교훈 5: 차세대 모델로 자신을 검증하라
Opus 4.7이 Opus 4.6의 사각지대를 발견한 사례는 흥미로운 함의를 가진다. 새로운 세대의 AI 모델은 이전 세대 모델로 만든 코드/시스템을 검증하는 도구가 될 수 있다.
Claude Code 사용자라면, 정기적으로 최신 모델로 기존 코드/문서/프롬프트를 리뷰하는 습관을 들이면 된다. 1인 기업의 한정된 검토 자원을 보완하는 가장 비용 효율적인 방법이다.
Anthropic의 변화 약속
Anthropic은 발표문 마지막에 향후 변경 약속을 정리했다.
- 내부 직원이 정확히 공개 빌드의 Claude Code를 사용하도록 보장 (테스트 빌드가 아니라)
- 시스템 프롬프트 변경에 더 엄격한 통제: 변경마다 모델별 광범위 평가, ablation 지속, 검토/감사 도구 신설
- CLAUDE.md에 모델별 변경 가이드 추가 (특정 모델 타겟팅 명시)
- 지능 trade-off 변경에는 soak periods, 광범위 평가 세트, 점진적 롤아웃
- @ClaudeDevs X 계정 신설 (제품 결정 배경 설명)
- GitHub centralized threads로 동일 업데이트
- 4월 23일자로 모든 구독자 사용량 한도 리셋 (피해 보상)
이 정도 수준의 사후분석과 사과는 SaaS 업계에서 보기 드물다. 특히 사용량 한도 리셋은 실질적 피해 보상을 의미한다. 투명성, 원인 공개, 보상 모두 갖춘 incident 대응의 모범 사례라고 할 만하다.
결론: AI 시대의 incident 거버넌스
이번 사건의 진정한 교훈은 단순히 "Anthropic이 실수했다"가 아니다. AI 시스템은 기존 소프트웨어보다 incident 디버깅이 어렵다는 것이다. 이유는 명확하다.
- 평가 세트는 모든 사용 패턴을 커버하지 못한다
- 시스템 프롬프트 한 줄이 측정 어려운 영향을 만든다
- 모델 자체가 비결정적이라 재현이 어렵다
- 캐싱, 라우팅, prompt 등 여러 layer가 동시에 영향을 준다
따라서 incident 거버넌스도 진화해야 한다. ablation 테스트, 백테스트, 점진적 롤아웃, 사용자 피드백 채널, 평가 시스템 자체의 검증. 이 모두가 표준 운영 절차에 포함되어야 한다.
1인 기업이라고 예외가 아니다. 오히려 자원이 적기 때문에 더 체계적으로 변경을 관리해야 한다. 이번 Anthropic의 사례가 보여준 것은 "큰 회사도 실패한다"가 아니라 "큰 회사가 어떻게 회복했는지" 의 모범 사례다.
다음번에 Claude나 다른 AI 도구가 갑자기 이상해진 것 같다면, 혼자 "내가 프롬프트를 잘못 짰나?"라고 자책하지 말자. 공식 채널, GitHub 이슈, 커뮤니티를 먼저 확인하자. 시스템적 변경은 시스템적 영향을 만든다. 우리만의 문제가 아닐 가능성이 충분히 높다.
원문: The April 23 postmortem - Anthropic Engineering
관련 자료:
