🔴 POSTMORTEM ANALYSIS
Claude Code 한 달간의 품질 저하,
Anthropic이 인정한 3가지 실수
Three Engineering Missteps Behind a Month of Claude Code Degradation
📅 2026.04.27
📌 Anthropic Engineering Blog
⏱ 12 min read
🏷 AI · DevTools
INCIDENT OVERVIEW
무슨 일이 있었나
What happened to Claude Code
2026년 3월부터 4월까지, Claude Code 사용자들 사이에서 이상한 소문이 퍼졌습니다. “Claude가 바보가 됐다.” 복잡한 코딩 작업에서 모델이 얕은 수정만 내놓고, 이전 맥락을 잊어버리며, 사용량 제한이 비정상적으로 빨리 소진되는 현상이 보고되기 시작했습니다.
From March to April 2026, Claude Code users reported shallow reasoning, forgetfulness, and abnormally fast usage limit depletion — and it wasn’t their imagination.
GitHub 이슈가 쏟아졌고, Reddit과 X(구 트위터)에서는 “AI 슈링크플레이션(shrinkflation)”이라는 표현까지 등장했습니다. AMD AI 부문 시니어 디렉터 Stella Laurenzo는 6,852개 세션 파일, 17,871개 사고(thinking) 블록, 234,760건의 도구 호출을 분석한 포렌식 수준의 GitHub 이슈를 공개하며 문제를 정량적으로 입증했습니다.
그리고 4월 23일, Anthropic은 마침내 공식 포스트모템을 발표했습니다. 3가지 별개의 엔지니어링 변경이 한 달 넘게 Claude Code의 품질을 저하시켰으며, API와 모델 가중치(weight) 자체는 영향받지 않았다는 내용이었습니다.
47일
전체 영향 기간
3월 4일 → 4월 20일
3건
별개 원인
effort · cache bug · prompt
v2.1.116
최종 수정 버전
2026년 4월 20일 배포
TIMELINE
47일간의 타임라인
A 47-day chronicle of degradation and discovery
2026년 2월
Opus 4.6 출시, 기본 reasoning effort = high
Claude Code에 Opus 4.6이 배포되며 기본 사고 수준이 ‘high’로 설정됩니다.
3월 4일
🔻 이슈 #1 — 기본 effort를 medium으로 하향
UI 멈춤 현상과 과도한 토큰 소모를 줄이기 위해 기본값을 medium으로 변경합니다. 이 결정이 첫 번째 품질 저하의 시작점이 됩니다.
3월 26일
🐛 이슈 #2 — 캐시 최적화 버그 배포
1시간 이상 유휴 세션의 이전 thinking을 정리하는 기능이 배포되지만, 버그로 인해 매 턴마다 thinking이 삭제됩니다.
4월 2일
📊 Stella Laurenzo, 포렌식 분석 공개
AMD AI 시니어 디렉터가 6,852개 세션의 정량 분석을 GitHub Issue #42796으로 공개합니다.
4월 7일
✅ 이슈 #1 수정 — effort 기본값 복구
Opus 4.7은 xhigh, 나머지 모델은 high가 기본값으로 재설정됩니다.
4월 10일
✅ 이슈 #2 수정 — 캐시 버그 패치 (v2.1.101)
thinking 블록 삭제 버그가 수정됩니다. 배포 후 15일 만입니다.
4월 16일
📝 이슈 #3 — 간결화 시스템 프롬프트 추가
Opus 4.7과 함께 “도구 호출 사이 25단어, 최종 응답 100단어 이하”라는 시스템 프롬프트가 배포됩니다.
4월 20일
✅ 이슈 #3 수정 — 프롬프트 롤백 (v2.1.116)
확장된 평가에서 Opus 4.6·4.7 모두 약 3% 성능 저하가 확인되어 즉시 복구합니다.
4월 23일
📣 공식 포스트모템 발표 + 사용량 리셋
Anthropic이 엔지니어링 블로그에 전말을 공개하고 전체 구독자의 사용량 제한을 초기화합니다.
DEEP DIVE
3가지 원인, 하나씩 파헤치기
Dissecting each of the three root causes
Anthropic이 밝힌 3가지 원인은 각각 다른 시점에, 다른 범위의 사용자에게, 다른 방식으로 영향을 미쳤습니다. 이 때문에 개별적으로는 “보통의 편차”처럼 보였고, 합쳐지자 광범위한 품질 저하로 체감되었습니다.
Three distinct changes affected different user segments on different schedules, making the aggregate effect look like broad, inconsistent degradation that was hard to reproduce internally.
추론 수준(Reasoning Effort) 하향 조정
Opus 4.6 출시 후 일부 사용자에게서 “UI가 멈춘 것 같다”는 피드백이 들어왔습니다. 모델이 너무 오래 생각하면서 레이턴시(Latency)가 치솟고 토큰 소모도 급증한 것입니다. Anthropic은 이를 해결하기 위해 기본 reasoning effort를 high → medium으로 변경했습니다.
내부 평가에서는 “대부분의 작업에서 약간 낮은 지능으로 현저히 낮은 레이턴시”를 달성할 수 있었지만, 실사용자 관점에서는 복잡한 멀티스텝 코딩 작업의 품질이 눈에 띄게 하락했습니다. Anthropic은 나중에 이를 스스로 “잘못된 트레이드오프(the wrong tradeoff)”라고 인정했습니다.
Sonnet 4.6
Opus 4.6
의도된 변경
캐시 최적화 버그 — 사라지는 기억
Claude가 작업을 수행할 때 생성하는 추론(thinking) 내역은 대화 히스토리에 보존되어, 다음 턴에서 이전 판단을 참조할 수 있게 합니다. Anthropic은 1시간 이상 유휴 상태인 세션에서 오래된 thinking 블록을 정리해 재개 비용을 줄이려 했습니다.
하지만 구현에 버그가 있었습니다. thinking 삭제가 한 번만 실행되는 것이 아니라 이후 세션의 모든 턴에서 반복되었습니다. 심지어 도구 사용 중간에 후속 메시지를 보내면 현재 턴의 reasoning까지 삭제되었습니다. Claude는 자신이 왜 그런 결정을 내렸는지 점점 잊어갔고, 사용자들은 “건망증”과 “반복”을 경험했습니다.
이 버그는 캐시 미스(cache miss)까지 유발하여 사용량 제한이 예상보다 빨리 소진되는 문제도 일으켰습니다.
Sonnet 4.6
Opus 4.6
구현 버그
간결화 시스템 프롬프트의 역효과
Opus 4.7은 전작 대비 눈에 띄게 장황(verbose)한 특성이 있었습니다. Anthropic은 출력 토큰을 줄이기 위해 시스템 프롬프트에 단어 수 제한을 추가했습니다. 구체적으로 “도구 호출 사이 텍스트 ≤25단어, 최종 응답 ≤100단어”라는 지시가 들어갔습니다.
수 주간의 내부 테스트에서 문제가 발견되지 않았지만, 이번 사후 조사에서 확장된 평가 세트를 적용하자 Opus 4.6과 4.7 모두에서 약 3% 성능 하락이 확인되었습니다. 간결함을 위해 지능을 희생한 셈이 된 이 변경은 즉시 롤백되었습니다.
Sonnet 4.6
Opus 4.6
Opus 4.7
의도된 변경
TECHNICAL
캐시 버그의 작동 원리
How the caching bug cascaded through sessions
세 가지 이슈 중 유일한 “진짜 버그”는 캐시 최적화 문제였습니다. 의도한 동작과 실제 동작이 어떻게 달랐는지 살펴보겠습니다.
❌ 실제 동작 (버그)
- 1시간 유휴 후 thinking 삭제 실행
- 이후 모든 턴에서 계속 thinking 삭제 반복
- 현재 턴의 reasoning까지 소실
- 매번 캐시 미스 → 토큰 과다 소모
- 건망증, 반복, 비정상적 도구 선택
VS
✅ 의도된 동작
- 1시간 유휴 후 오래된 thinking만 1회 삭제
- 이후 정상적으로 전체 reasoning 유지
- 최신 thinking 블록은 항상 보존
- 캐시 히트율 유지 → 정상 토큰 소모
- 맥락을 기억하며 일관된 작업 수행
The intended one-time cleanup of stale thinking blocks turned into a per-turn wipe that compounded throughout the session, stripping Claude of its own reasoning context and inflating token usage via cache misses.
이 버그가 특히 발견하기 어려웠던 이유가 있습니다. 두 가지 별개의 내부 실험 — 메시지 큐잉 관련 서버 실험과 thinking 표시 방식 변경 — 이 대부분의 내부 CLI 세션에서 이 버그를 억제했습니다. 외부 빌드를 테스트할 때조차 문제가 재현되지 않았고, 결국 근본 원인을 확인하기까지 1주일 이상이 걸렸습니다.
흥미로운 점은 사후 조사 과정에서 Anthropic이 Code Review 도구로 문제의 풀 리퀘스트를 재검토했을 때, Opus 4.7은 버그를 발견했지만 Opus 4.6은 찾지 못했다는 것입니다.
왜 발견이 늦었나
Why it was so hard to catch these issues early
🧪
내부 평가 통과 — 기존 eval 세트에서 유의미한 차이 미검출
🔬
내부 빌드 ≠ 외부 빌드 — 직원들이 테스트용 빌드를 사용해 외부 버그 미재현
🎭
3가지 이슈의 시차 — 각기 다른 시점·범위로 “일반적 편차”처럼 보임
🔇
캐시 버그 억제 — 두 개의 관련 없는 내부 실험이 버그를 가림
📢
사용자 피드백이 결정적 — GitHub 이슈와 재현 가능한 보고가 근본 원인 발견의 열쇠
COMMUNITY
개발자 커뮤니티의 반응
How the developer community reacted
Anthropic의 포스트모템 발표는 사용자들의 불만을 잠재우지 못했습니다. 오히려 “그동안 가스라이팅(gaslighting)을 당했다”는 분노가 확산되었습니다.
Despite the postmortem, many users felt Anthropic had been gaslighting them for weeks — initially implying nothing was wrong and that users were to blame for their own performance issues.
“Claude Code 팀이 문제를 제기하는 사람들을 가스라이팅해왔다는 점이 가장 답답하다. 많은 돈을 내고 사용하는 제품이 오히려 일을 더 어렵게 만들 때, 사용자의 판단력을 의심하게 만드는 건 용납할 수 없다.”
— Muratcan Koylan, Sully.ai 기술 스태프 (X 게시글, Fortune 인용)
특히 논란이 된 것은 세 가지 이슈 중 두 가지(effort 하향, 프롬프트 변경)가 의도적 결정이었다는 점입니다. 진짜 “버그”는 캐시 문제 하나뿐이었는데, Anthropic은 포스트모템에서 세 가지를 “품질 저하”라는 하나의 범주로 묶어 설명하면서, 의도적 결정과 의도치 않은 버그의 경계를 흐렸다는 비판을 받았습니다.
Anthropic의 연간 반복 수익률은 300억 달러(약 42조 원)로 전년 대비 3배 이상 성장했고, Claude의 월간 활성 사용자는 2월 말 기준 2,000만 명을 돌파한 상태였습니다. 이 시점에서의 품질 논란은 OpenAI와의 경쟁, 그리고 올해 예정된 IPO 추진에 적지 않은 부담이 될 수 있습니다.
사용자 체감 지표 변화
Measured impact metrics from user reports (Jan → Mar 2026)
Source: Stella Laurenzo’s analysis — GitHub Issue #42796 (6,852 sessions, Jan–Mar 2026)
ANALYSIS
3가지 이슈 종합 비교
Side-by-side comparison of all three issues
| 항목 |
이슈 #1: Effort 하향 |
이슈 #2: 캐시 버그 |
이슈 #3: 프롬프트 |
| 유형 |
의도된 변경 |
구현 버그 |
의도된 변경 |
| 배포일 |
3월 4일 |
3월 26일 |
4월 16일 |
| 수정일 |
4월 7일 |
4월 10일 |
4월 20일 |
| 지속 기간 |
34일 |
15일 |
4일 |
| 영향 모델 |
Sonnet 4.6, Opus 4.6 |
Sonnet 4.6, Opus 4.6 |
Sonnet 4.6, Opus 4.6, Opus 4.7 |
| 주요 증상 |
얕은 추론, 단순 수정 |
건망증, 반복, 토큰 급소모 |
코딩 품질 하락 (~3%) |
| 발견 경로 |
사용자 피드백 |
내부 조사 + 사용자 보고 |
확장 eval (ablation) |
GOING FORWARD
Anthropic의 재발 방지 약속
What Anthropic pledges to do differently
Anthropic은 포스트모템에서 구체적인 재발 방지책을 제시했습니다.
🛡 재발 방지 핵심 조치
1. 외부 빌드 직접 사용 — 더 많은 내부 직원이 테스트용이 아닌 실제 공개 빌드를 일상 업무에 사용하도록 변경합니다.
2. 시스템 프롬프트 변경 통제 강화 — 모든 프롬프트 변경에 대해 모델별 광범위 eval을 의무화하고, 각 라인의 영향을 측정하는 ablation 테스트를 실행합니다.
3. Code Review 도구 개선 — Opus 4.7은 문제의 PR에서 버그를 발견했지만 Opus 4.6은 못 찾았습니다. 추가 저장소를 코드 리뷰 컨텍스트로 포함하는 기능을 배포 중입니다.
4. 점진적 롤아웃 도입 — 지능에 영향을 줄 수 있는 변경은 soak 기간을 두고 단계적으로 배포합니다.
5. @ClaudeDevs 채널 운영 — X(구 트위터)와 GitHub에서 제품 결정의 이유를 사전에 공유하는 공식 커뮤니케이션 채널을 신설합니다.
Anthropic pledged to use public builds internally, gate prompt changes behind broader evals, improve Code Review tooling, adopt gradual rollouts, and communicate product decisions proactively through @ClaudeDevs.
전체 구독자의 사용량 제한도 4월 23일자로 초기화되었습니다. 다만 일부 사용자들은 한 달간의 생산성 손실에 비해 사용량 리셋만으로는 충분치 않다는 의견을 보이고 있습니다.
PERSPECTIVE
더 큰 맥락: AI 코딩 도구의 신뢰 문제
The trust problem facing AI coding tools
이번 사건은 Anthropic만의 문제가 아닙니다. Claude Code, Codex, Cursor, GitHub Copilot, Gemini CLI 등 모든 AI 코딩 도구는 모델 자체 위에 쌓인 “하네스(harness)” — CLI 동작, 도구 체인, 세션 관리, 시스템 프롬프트, 배포 로직 — 에 의존합니다. 모델 가중치가 바뀌지 않았더라도 이 하네스의 작은 변경이 사용자 체감 품질에 큰 영향을 줄 수 있습니다.
This isn’t unique to Anthropic. Every AI coding tool depends on a “harness” layer around the model, and small changes in that layer can dramatically affect perceived quality — even when model weights remain unchanged.
💡 개발자가 기억할 4가지 질문
AI 코딩 도구가 갑자기 더 똑똑해지거나 나빠졌다고 느낄 때, 다음 4가지를 확인하세요.
1. 모델 가중치가 바뀌었나, 아니면 하네스(프롬프트·설정·세션 관리)가 바뀌었나?
2. 기본 설정(effort, context window, caching)이 업데이트되었는지 릴리스 노트를 확인했나?
3. 내 워크플로우를 정량적으로 추적하고 있는가? (세션 길이, 재시도 횟수, thinking 깊이)
4. 대안 모델/도구로 전환할 수 있는 탈출구를 준비해두었는가?
Anthropic이 이번 사건을 통해 보여준 것은, 3,800억 달러 기업가치를 지닌 AI 랩조차 프로덕션 레벨의 QA 실패에서 자유롭지 않다는 사실입니다. 동시에, 개발자 커뮤니티의 치밀한 정량 분석(Laurenzo의 GitHub 이슈가 대표적)이 기업의 공식 인정을 이끌어냈다는 점도 주목할 만합니다. AI 도구에 대한 신뢰는 결국 투명한 커뮤니케이션과 빠른 대응에서 비롯됩니다.
Trust in AI tools ultimately comes from transparent communication and rapid response. This incident proves that even a $380B AI lab isn’t immune to production QA failures — and that the developer community’s quantitative vigilance is what drives accountability.
답글 남기기