최근 몇 주 동안 Claude Code를 쓰는 사람들 사이에서 비슷한 얘기가 계속 나왔습니다. 예전보다 덜 똑똑해진 것 같고, 갑자기 잘 까먹고, 괜히 답만 짧아졌는데 코딩 품질도 같이 떨어진 것 같다는 이야기였습니다.
Anthropic은 이 체감 저하가 실제 문제였는지 조사해왔고, 2026년 4월 23일 공개한 포스트모템 ↗에서 실제로 세 가지 회귀가 있었다고 인정했습니다. 중요한 건 이게 모델을 일부러 약하게 만든 일이 아니라, Claude Code 제품 레이어에서 들어간 변경들이 겹치며 생긴 문제였다는 점입니다.
이번 사건이 흥미로운 이유도 여기 있습니다. 단순히 “모델이 별로였다”로 끝나는 얘기가 아니라, AI 코딩 도구에서 기본값, 캐시, system prompt 같은 제품 결정이 체감 품질을 얼마나 크게 흔들 수 있는지 보여주는 사례에 가깝기 때문입니다. 이 글에서는 Anthropic이 무엇을 인정했고, 실제로 어떤 문제가 있었고, Claude Code를 쓰는 입장에서 무엇을 기억해둘 만한지 정리해보겠습니다.
무슨 일이 있었나
Anthropic 설명을 요약하면, 최근 Claude 품질 저하 보고는 한 가지 원인으로 생긴 일이 아니었습니다. 서로 다른 세 가지 변경이 각기 다른 시점과 다른 범위에서 영향을 주면서, 사용자 입장에서는 그냥 “전체적으로 이상해졌다”고 느끼기 쉬운 상태가 됐습니다. 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는 겉으로는 계속 작업하지만, 왜 그런 편집과 도구 호출을 했는지에 대한 맥락을 점점 잃어버리게 됩니다. Anthropic이 사용자 보고에서 본 증상도 바로 이것이었습니다. 잘 까먹고, 반복적이고, 이상한 도구 선택을 한다는 체감입니다. (포스트모템 ↗)
이 버그는 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 버그 때문에 더 심한 forgetfulness를 겪었고, 또 어떤 사람은 Opus 4.7 출시 이후 지나치게 짧아진 응답과 코딩 품질 저하를 먼저 느꼈을 수 있습니다. (포스트모템 ↗)
즉 이번 일은 “모델 자체가 갑자기 나빠졌다”기보다, 기본값, context 관리, system prompt라는 서로 다른 층에서 생긴 변화가 겹쳐 전체 품질 저하처럼 보인 사건에 가깝습니다. Claude Code 같은 제품을 볼 때 이 지점이 특히 중요합니다. 모델 벤치마크만으로는 설명되지 않는 체감 품질 차이가 실제로 존재한다는 뜻이기 때문입니다.
이 맥락은 이전에 정리했던 Claude Code Ultra Plan, Claude Code Routines, Claude Code Channels 글과도 이어집니다. Claude Code는 점점 더 많은 제품 레이어와 자동화 흐름을 얹고 있고, 그래서 모델 품질만이 아니라 하네스와 제품 결정의 품질도 사용자 경험을 크게 좌우하게 됩니다.
앞으로 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 정책이 어떻게 바뀌는지 같이 보는 게 중요해졌습니다. 그런 의미에서 이번 포스트모템은 실수 인정문이면서 동시에, Claude Code가 꽤 복잡한 제품 단계로 들어섰다는 신호이기도 합니다.
마무리
Anthropic은 이번 글에서 모델 성능 저하를 부정하지 않았고, 세 가지 원인을 비교적 구체적으로 공개했습니다. 수정 시점, 롤백 이유, 내부 재발 방지 계획, usage limit 초기화까지 같이 설명한 점도 눈에 띕니다. 이런 식의 공개 포스트모템은 꽤 드문 편이라, 신뢰 회복 측면에서는 오히려 의미가 있습니다.
다만 더 중요한 건 앞으로입니다. Claude Code는 이미 단순한 터미널 도구가 아니라, effort 설정, extended thinking, code review, 자동화 기능이 복잡하게 얽힌 제품이 됐습니다. 그만큼 앞으로의 품질 문제도 “모델이 멍청해졌다” 한 줄로 설명되지 않을 가능성이 큽니다.
그래서 이번 사건은 단순한 장애 후기보다, AI 코딩 제품에서 품질이 어디서 무너질 수 있는지 보여준 사례로 읽는 편이 더 맞습니다. Claude Code를 진지하게 쓰고 있다면, 이번 포스트모템은 한 번 읽어둘 만합니다.
관련 글도 같이 보면 흐름이 더 잘 이어집니다.