---
title: "Anthropic 포스트모템 — Claude Code 품질 저하 원인 3가지 공개, 구독자 전원 사용량 리셋"
published: 2026-04-23T17:48:38.000Z
canonical: https://jeff.news/article/1900
---
# Anthropic 포스트모템 — Claude Code 품질 저하 원인 3가지 공개, 구독자 전원 사용량 리셋

Anthropic이 지난 한 달간 쏟아진 'Claude Code가 멍청해졌다'는 리포트의 원인을 3가지 독립적인 변경으로 특정했다. reasoning effort 기본값을 medium으로 낮춘 결정, 캐싱 최적화 버그로 추론 기록이 매 턴 삭제된 버그, verbosity를 줄이려는 시스템 프롬프트가 코딩 품질을 3% 깎은 이슈다. 4월 20일 v2.1.116에서 모두 수정됐고 구독자 전원 사용량 한도가 리셋됐다.

> [!IMPORTANT]
> Anthropic이 지난 한 달간 "Claude Code가 멍청해졌다"는 불만의 원인을 공개함. API 자체는 문제없었고, Claude Code 쪽에서 **3개의 독립적인 변경**이 겹쳐서 발생. 4월 20일 v2.1.116에서 모두 수정됨. 구독자 전원 사용량 리셋.

- 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를 줄이려 함
- 그 중 하나가 시스템 프롬프트에 추가된 한 줄

> [!NOTE]
> "Length limits: keep text between tool calls to ≤25 words. Keep final responses to ≤100 words unless the task requires more detail."

- 수 주간 내부 테스트에서 리그레션 없다고 확인하고 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 + 점진적 롤아웃을 도입한다는 건, 프롬프트 엔지니어링을 **정식 배포 프로세스**로 편입시키겠다는 선언이기도 해요.

## 핵심 포인트

- 3월 4일부터 4월 20일 사이 3개의 독립적 변경이 겹쳐 품질 저하 발생, API는 무관
- reasoning effort 기본값을 high→medium으로 낮춘 게 잘못된 트레이드오프였고 4월 7일 롤백
- 유휴 세션 재개 시 thinking 히스토리를 매 턴마다 삭제하는 버그가 건망증·반복·이상한 툴 선택을 유발
- verbosity 감소용 시스템 프롬프트('100단어 이내')가 Opus 4.6/4.7 eval 점수를 3% 떨어뜨림
- 사내 실험들이 버그를 마스킹해서 재현이 한 주 넘게 안 됐음
- 문제의 PR을 Opus 4.7 Code Review로 역테스트했더니 4.7은 버그를 찾고 4.6은 못 찾음
- 앞으로 프롬프트 변경에 soak period + ablation + 점진적 롤아웃 적용
- 구독자 전원 사용량 한도 리셋

## 인사이트

LLM 프로덕션에서 '체감 지능'은 모델 가중치가 아니라 하네스(harness) 레이어의 사소한 변경에 좌우된다는 걸 보여주는 케이스. 시스템 프롬프트 한 줄, 캐시 최적화 한 조각이 실제 유저에게는 '멍청해졌다'는 전방위 저하로 인식된다.