최근 몇 주 동안 Claude Code 사용자들 사이에서 품질이 떨어졌다는 보고가 이어졌습니다. 예전보다 덜 똑똑하고, 앞의 작업을 잘 잊고, 답은 짧아졌는데 코딩 품질도 떨어졌다는 내용이었습니다.
Anthropic은 2026년 4월 23일 공개한 포스트모템 ↗에서 실제로 세 가지 회귀가 있었다고 인정했습니다. 모델을 일부러 약하게 만든 것은 아니었습니다. Claude Code 제품 레이어에 들어간 변경 세 개가 겹쳐 생긴 문제였습니다.
이 사례는 기본값, 캐시, system prompt 같은 제품 결정이 AI 코딩 도구의 체감 품질을 크게 바꿀 수 있음을 보여줍니다. 이 글은 Anthropic이 인정한 내용, 세 가지 원인, Claude Code 사용자가 기억할 점을 정리합니다.
무슨 일이 있었나
Anthropic에 따르면 최근 품질 저하 보고의 원인은 하나가 아니었습니다. 서로 다른 세 가지 변경이 각기 다른 시점과 범위에 영향을 줬습니다. 그래서 사용자는 “전체적으로 이상해졌다”고 느꼈습니다. Anthropic도 초반에는 이 보고를 평소의 피드백 변동과 구분하기 어려웠다고 설명합니다. (포스트모템 ↗)
API는 영향을 받지 않았습니다. 문제는 Claude Code, Claude Agent SDK, Claude Cowork 같은 제품 레이어에서 발생했습니다. Anthropic은 세 문제를 4월 20일까지 모두 수정했다고 밝혔습니다. 4월 23일에는 모든 구독자의 usage limit를 초기화했습니다. (포스트모템 ↗)
flowchart TD
A[사용자 체감 품질 저하] --> B[기본 reasoning effort 하향]
A --> C[idle 세션 thinking history 삭제 버그]
A --> D[장황함 억제 system prompt]
B --> E[덜 똑똑하게 느껴짐]
C --> F[잘 까먹고 반복함]
D --> G[짧아졌지만 코딩 품질 하락]첫 번째 원인, 기본 reasoning effort를 낮춘 결정
첫 번째 문제는 3월 4일에 들어간 변경입니다. Anthropic은 high effort 모드에서 thinking이 너무 길어져 UI가 멈춘 것처럼 보인다고 판단했습니다. 그래서 기본 reasoning effort를 high에서 medium으로 낮췄습니다. (포스트모템 ↗)
이 변경에는 이유가 있었습니다. 응답 지연을 줄이고, usage limit 소모를 줄이고, thinking이 길어져 멈춘 것처럼 보이는 tail latency를 줄이려 했습니다. Anthropic 내부 평가에서 medium effort는 많은 작업에서 지능이 약간 낮은 대신 지연 시간이 훨씬 짧았다고 합니다. (포스트모템 ↗)
하지만 Claude Code 사용자는 다른 기본값을 기대했습니다. 간단한 작업이면 직접 effort를 낮출 수 있으니, 기본값은 더 똑똑한 쪽이기를 바랐습니다. Anthropic은 이 피드백을 받아 4월 7일 변경을 되돌렸습니다. 지금은 Opus 4.7은 xhigh, 나머지 모델은 high effort가 기본값입니다. (포스트모템 ↗)
두 번째 원인, thinking history를 계속 지워버린 캐시 버그
두 번째 문제는 영향이 더 컸습니다. 3월 26일 Anthropic은 캐시 최적화를 하나 넣었습니다. 한 시간 이상 idle 상태였던 세션을 다시 열 때 오래된 thinking section을 정리해 지연과 비용을 줄이는 기능입니다. 오래 쉬었던 세션을 다시 열 때 한 번만 이전 thinking을 정리해 uncached token 수를 줄이려 했습니다. (포스트모템 ↗)
구현에 버그가 있었습니다. 이 정리는 딱 한 번만 일어나야 했습니다. 실제로는 세션이 idle threshold를 한 번 넘으면 그 뒤의 모든 turn마다 반복됐습니다. 그러면 Claude는 작업을 계속하지만, 앞서 한 편집과 도구 호출의 이유를 점점 잃습니다. 사용자 보고에 나온 증상도 같았습니다. 잘 잊고, 같은 일을 반복하고, 이상한 도구를 고른다는 내용입니다. (포스트모템 ↗)
이 버그는 usage limit가 예상보다 빨리 닳는 현상과도 연결됐을 가능성이 큽니다. thinking block이 계속 빠지면서 이후 요청이 캐시 미스를 냈기 때문입니다. 사용자는 품질이 떨어졌는데 한도도 더 빨리 닳는 상황을 겪었습니다. (포스트모템 ↗)
Anthropic은 이 버그가 Claude Code의 context 관리, Anthropic API, extended thinking이 만나는 지점에 있었다고 설명합니다. 여러 코드 리뷰와 테스트를 통과했지만 corner case라서 한동안 잡히지 않았습니다. 나중에 Code Review ↗로 문제 PR을 다시 검사하자 Opus 4.7은 버그를 잡았고 Opus 4.6은 못 잡았습니다. Anthropic은 이를 계기로 Code Review가 더 많은 저장소를 context로 읽도록 지원하겠다고 밝혔습니다. (포스트모템 ↗, Code Review 문서 ↗)
세 번째 원인, 장황함을 줄이려다 코딩 품질을 해친 system prompt
세 번째 문제는 원인을 찾기 더 어려웠습니다. Anthropic은 Claude Opus 4.7 소개 글 ↗에서 이 모델이 hard problem에서는 더 똑똑하지만 verbose한 성향이 있다고 밝혔습니다.
Anthropic은 Opus 4.7 출시에 맞춰 Claude Code를 튜닝하면서 장황함을 줄이는 방법을 여럿 썼습니다. 그중 system prompt에 추가한 한 줄이 예상보다 큰 영향을 줬습니다.
Length limits: keep text between tool calls to ≤25 words. Keep final responses to ≤100 words unless the task requires more detail.
이 줄은 도구 호출 사이의 설명을 줄이고, 최종 답변이 필요 이상으로 길어지지 않게 하려고 넣었습니다. 하지만 이 제한은 다른 prompt 변경과 겹치면서 코딩 품질까지 떨어뜨렸습니다. 더 넓은 평가 세트에서 Opus 4.6과 4.7 모두 약 3% 하락이 확인됐고, 4월 20일에 바로 롤백됐습니다. (포스트모템 ↗)
system prompt 변경은 말투만 바꾸는 일로 보이기 쉽습니다. 이 사례에서는 응답 길이 제약이 reasoning 품질을 직접 떨어뜨렸습니다.
왜 이게 더 크게 느껴졌나
세 문제는 서로 다른 날짜에 들어갔고, 서로 다른 범위에 영향을 줬습니다. 그래서 사용자는 어느 날 한 번에 망가진 경험보다, 상황에 따라 들쑥날쑥한 이상 동작을 겪었을 가능성이 큽니다. 어떤 사람은 reasoning effort 하향을 먼저 느꼈습니다. 어떤 사람은 stale session 버그 때문에 앞의 작업을 더 자주 잊는 문제를 겪었습니다. 또 어떤 사람은 Opus 4.7 출시 이후 짧아진 응답과 코딩 품질 저하를 먼저 느꼈을 수 있습니다. (포스트모템 ↗)
모델 자체는 나빠지지 않았습니다. 기본값, context 관리, system prompt라는 서로 다른 층의 변경이 겹쳐 전체 품질 저하처럼 보였습니다. 모델 벤치마크만으로는 이런 체감 품질 차이를 설명할 수 없습니다.
Claude Code는 Ultra Plan, Routines, Channels처럼 제품 레이어와 자동화 흐름을 계속 늘리고 있습니다. 그만큼 모델 품질과 함께 하네스와 제품 결정의 품질이 사용자 경험을 좌우합니다.
앞으로 Anthropic이 바꾸겠다고 한 것
Anthropic은 포스트모템에서 재발 방지 계획 세 가지를 밝혔습니다.
1) 공개 빌드를 내부에서도 더 많이 쓰기
내부 테스트용 버전과 실제 공개 빌드 사이 차이가 있으면, 고객이 겪는 문제를 내부에서 놓치기 쉽습니다. Anthropic은 앞으로 더 많은 내부 인력이 정확히 공개된 Claude Code 빌드를 쓰게 하겠다고 말했습니다. (포스트모템 ↗)
2) Code Review와 평가 체계 강화
Anthropic은 내부에서 쓰는 Code Review ↗ 도구를 개선하고, 개선한 기능을 고객에게도 제공하겠다고 했습니다. 또 system prompt가 바뀔 때마다 더 넓은 per-model eval, line-by-line ablation, 점진적 rollout, soak period를 적용하겠다고 했습니다. (포스트모템 ↗, Code Review 문서 ↗)
3) 모델별 변경 범위를 더 엄격히 제한
Anthropic은 CLAUDE.md 가이드를 보강해, 특정 모델을 겨냥한 변경이 다른 모델로 번지지 않게 관리하겠다고 했습니다. 이번에는 Sonnet 4.6, Opus 4.6, Opus 4.7이 서로 다른 방식으로 영향을 받았습니다. (포스트모템 ↗)
이번 사건에서 기억할 것
첫째, 최근 Claude Code가 이상하다고 느꼈다면 실제로 회귀가 있었습니다. Anthropic이 이를 인정했습니다. (포스트모템 ↗)
둘째, AI 코딩 도구의 품질은 모델 가중치만으로 정해지지 않습니다. reasoning effort 기본값, context pruning, prompt 길이 제한 같은 제품 레이어의 작은 조정도 체감 성능을 크게 바꿉니다.
Claude Code 품질이 바뀌었다고 느끼면, 새 모델 출시 여부와 함께 기본 설정, 세션 동작, prompt 정책의 변경 내역을 확인합니다.
마무리
Anthropic은 이번 글에서 품질 저하를 부정하지 않고 세 가지 원인을 공개했습니다. 수정 시점, 롤백 이유, 재발 방지 계획, usage limit 초기화도 함께 설명했습니다.
Claude Code는 effort 설정, extended thinking, code review, 자동화 기능이 얽힌 제품입니다. 앞으로의 품질 문제도 모델 하나만으로 설명되지 않을 가능성이 큽니다. Claude Code를 업무에 쓰고 있다면 포스트모템 원문 ↗에서 각 원인의 시점과 수정 버전을 확인해 둡니다.