Anthropic 포스트모템 — Claude Code 품질 저하 원인 3가지 공개, 구독자 전원 사용량 리셋

• Anthropic이 4월 23일자로 포스트모템 공개 — 3월부터 번진 "Claude Code 품질 저하" 리포트의 진짜 원인을 털어놓음
  • 영향받은 건 Claude Code, Claude Agent SDK, Claude Cowork. API는 무관이라고 못 박음
  • 각 변경이 서로 다른 트래픽 조각에, 서로 다른 스케줄로 적용되다 보니 "전방위 불규칙 저하"처럼 보였다는 게 회사 설명
  • 내부 사용/평가에서는 초반에 재현이 안 됐고 정상 피드백 변동과 구분이 어려워서 늦게 발견됨

원인 ①: reasoning effort를 high → medium으로 낮춘 게 잘못된 판단이었음

• 3월 4일, Claude Code 기본 reasoning effort를 high에서 medium으로 낮춤
  • 이유는 Opus 4.6 high에서 가끔 너무 오래 생각해서 UI가 얼어붙은 것처럼 보일 정도로 레이턴시가 튀는 이슈가 있었음
  • 내부 평가에서 medium이 "약간 덜 똑똑한데 대다수 태스크에서 훨씬 빠르고, 사용량 한도도 아껴 쓰게 해준다"고 나옴
• 그런데 유저들이 "Claude Code가 멍청해졌다"고 반응하기 시작
  • Anthropic은 처음엔 effort 설정을 바꿀 수 있다는 걸 더 잘 보이게 하는 UI 개선(시작 시 알림, 인라인 effort 셀렉터, ultrathink 복원)을 시도
  • 그래도 대부분의 유저는 medium 기본값을 그대로 뒀음
• 4월 7일 결국 결정을 뒤집음 — Opus 4.7은 xhigh, 다른 모델은 전부 high가 기본값
  • Sonnet 4.6, Opus 4.6에 영향

원인 ②: 캐싱 최적화 버그로 "추론 기록"이 매턴 날아감

• 3월 26일, 세션이 1시간 넘게 유휴 상태면 resume 시 예전 thinking 섹션을 한 번만 비우는 최적화를 배포
  • 어차피 캐시 미스인 요청에서 uncached 토큰을 줄이려는 목적. clear_thinking_20251015 API 헤더 + keep:1 조합
  • 취지는 "resume 한 번 할 때 깔끔하게 정리하고, 이후엔 다시 풀 추론 히스토리를 보냄"
• 버그 — 한 번만 비우는 게 아니라 세션이 유휴 임계치를 한 번 넘기면 그 세션 전체에서 매 턴마다 계속 비워짐
  • 연쇄 효과까지 있었음. Claude가 툴을 쓰는 중에 유저가 메시지를 보내면 새 턴이 시작되면서 현재 턴의 추론도 통째로 날아감
  • Claude가 실행은 계속하는데 "왜 이걸 하고 있었는지"를 잊어버림 → 유저가 신고한 "건망증, 반복, 이상한 툴 선택"의 정체
  • 매 요청마다 thinking 블록이 빠지니 캐시 미스도 줄줄이 발생 → "사용량 한도가 이상하게 빨리 타들어간다"는 별개 리포트의 원인도 이거였음
• 재현이 왜 안 됐냐 — 메시지 큐잉 관련 사내 전용 서버사이드 실험 + thinking 표시 방식의 무관한 변경이 대부분의 CLI 세션에서 이 버그를 마스킹해버림
  • 외부 빌드 테스트에서도 안 잡힘. 코드 리뷰, 자동 검증, 유닛/E2E 테스트, 도그푸딩 다 통과함
  • Claude Code 컨텍스트 관리 + Anthropic API + extended thinking 교차 지점 + stale session 코너 케이스가 겹쳐서 한 주 넘게 걸림
• 재미있는 포인트 — 문제의 PR을 Opus 4.7로 Code Review 역테스트했을 때 Opus 4.7은 버그를 찾았고 Opus 4.6은 못 찾음
  • 이후 Code Review에 더 많은 레포를 컨텍스트로 넣을 수 있게 개선 중
• 4월 10일 v2.1.101에서 수정

원인 ③: "길게 쓰지 마" 시스템 프롬프트가 코딩 품질을 깎아먹음

• Opus 4.7은 전작보다 확연히 verbose — 어려운 문제에선 더 똑똑해지지만 출력 토큰이 많아짐
• Anthropic은 모델 학습, 프롬프팅, thinking UX 개선을 다 동원해서 verbosity를 줄이려 함
• 그 중 하나가 시스템 프롬프트에 추가된 한 줄

• 수 주간 내부 테스트에서 리그레션 없다고 확인하고 4월 16일 Opus 4.7과 함께 출시
• 이후 더 넓은 평가 세트로 ablation(프롬프트 줄 하나씩 빼보기) 돌려봤더니, 이 문장이 Opus 4.6/4.7 둘 다에서 3% 점수 하락을 유발함
• 즉시 롤백 — 4월 20일 릴리스에 반영. Sonnet 4.6, Opus 4.6, Opus 4.7에 영향

앞으로 어떻게 막겠다는 건가

• 내부 직원들이 정확히 공개 빌드와 동일한 Claude Code를 쓰도록 확대 (이전엔 신기능 테스트용 버전 사용)
• 사내용 Code Review 툴을 개선해서 고객에게도 제공
• 시스템 프롬프트 변경에 대한 통제 강화
  • 프롬프트 변경마다 모델별 광범위 eval 실행
  • 각 줄의 영향을 이해하기 위한 ablation 지속
  • 프롬프트 변경을 리뷰/감사하기 쉽게 만드는 툴링 추가
  • 모델 특정 변경은 해당 모델에만 적용되도록 CLAUDE.md에 가이드 추가
• 지능과 트레이드오프가 있는 변경은 soak period + 넓은 eval + 점진적 롤아웃으로 조기 감지
• 커뮤니케이션 채널로 @ClaudeDevs X 계정과 GitHub 스레드를 통해 의사결정 배경 공유 예정
• 사과의 의미로 모든 구독자 사용량 한도 리셋

---

기술 맥락

reasoning effort의 기본값 선택은 단순 UX 선택이 아니에요. test-time-compute 곡선에서 "생각 시간 vs 레이턴시/한도 소모"의 어느 지점을 디폴트로 찍느냐 문제거든요. Anthropic이 medium을 골랐던 건 내부 evals에서 "약간 덜 똑똑한 대신 대다수 태스크에서 체감 속도가 훨씬 좋다"는 결과 때문이었어요. 근데 실제 유저는 속도보다 일관된 품질을 원했어요. 이게 evals로는 안 잡히는 UX 차원의 신호였죠. 기본값은 한 번 박히면 대부분 유저가 바꾸지 않는다는 점도 맞물렸고요.

두 번째 버그가 왜 그렇게 안 잡혔냐를 뜯어보면 재밌어요. 이론상 "코드 리뷰 통과 + 유닛 테스트 통과 + E2E + 도그푸딩"이면 웬만한 버그는 걸러지는데, 이 건은 stale session 코너 케이스에서만 발동했고, 하필 다른 두 실험(메시지 큐잉 서버사이드 실험 + thinking 표시 변경)이 사내 환경에선 이 버그를 자동으로 마스킹하고 있었어요. 버그 재현 환경 자체를 만들 수 없었다는 얘기예요. 에이전트 시스템처럼 상태가 많이 쌓이는 제품에선 "유휴 후 재개"라는 시간 축이 일반 테스트에서 잘 안 커버돼요.

**clear_thinking_20251015 + keep:1**은 Anthropic Messages API의 기능이에요. 추론(thinking) 블록을 대화 히스토리에서 제거하는 힌트인데, "한 번만 비우고 이후엔 풀 히스토리 재전송"이 설계 의도였어요. 그런데 구현이 "매 턴마다 keep:1"로 고착되니까 Claude가 본인이 왜 이 툴을 부르고 있었는지조차 잊어버리는 상태가 된 거예요. 에이전트가 "멍청해 보이는" 게 실제론 지능 저하가 아니라 컨텍스트 망각이었다는 게 포인트예요.

시스템 프롬프트 한 줄이 eval 점수 3%를 깎는다는 게 LLM 프로덕션의 현실이에요. "간결하게 써라"는 지시가 언뜻 무해해 보여도, 코딩 태스크에선 모델의 추론 과정 중간 출력까지 압축시켜서 실제 해결 품질을 떨어뜨려요. ablation(줄 단위로 하나씩 빼보기)이 왜 필요한지 보여주는 케이스예요. 앞으로 soak period + 점진적 롤아웃을 도입한다는 건, 프롬프트 엔지니어링을 정식 배포 프로세스로 편입시키겠다는 선언이기도 해요.