지난 한 달간 Claude Code가 이상하다고 느끼셨다면, 착각이 아니었습니다. Anthropic이 공식 포스트모템을 발행했습니다.
[핵심 요약]
→ 기간: 2026년 3월 4일 ~ 4월 20일
→ 영향 범위: Claude Code, Claude Agent SDK, Claude Cowork
→ API는 영향 없음
→ 원인 1: 기본 추론 노력을 High → Medium으로 낮춤 (3월 4일)
→ 원인 2: 캐싱 버그로 매 턴마다 Thinking이 삭제됨 (3월 26일)
→ 원인 3: 시스템 프롬프트에 응답 길이 제한 추가 (4월 16일)
→ 현재: v2.1.116 이상에서 전부 수정 완료
→ 보상: 전 구독자 사용량 한도 리셋 (4월 23일)
배경 — "Claude가 멍청해졌다"는 신호들
3월부터 GitHub, X, Reddit에서 개발자들의 불만이 폭발했습니다.
사용자들이 보고한 증상:
→ 복잡한 문제를 "가장 쉬운 수정"으로 때움
→ 세션 중간에 이전 맥락을 잊어버림
→ 같은 실수를 반복
→ 추론 깊이가 줄어든 느낌
→ 사용량 한도가 이상하게 빨리 소진
AMD AI 그룹 시니어 디렉터 Stella Laurenzo가 GitHub에 올린 분석이 결정타였습니다. 6,852개의 Claude Code 세션 파일과 234,760개의 툴 호출을 분석한 결과, 추론 깊이가 눈에 띄게 감소했다는 결론이었습니다. BridgeMind의 서드파티 벤치마크에서는 Claude Opus 4.6의 정확도가 83.3% → 68.3%로 하락했다는 결과까지 나왔습니다.
Anthropic은 처음엔 "모델 가중치는 변하지 않았다"고 방어했지만, 증거가 쌓이자 내부 조사에 착수했습니다. 그리고 오늘 공식 포스트모템을 발행했습니다.
기존 방식의 문제:
→ 세 가지 변경사항이 서로 다른 시점에 배포됨
→ 각각은 작은 변경처럼 보였지만 합쳐지면 광범위한 품질 저하
→ 영향 범위가 트래픽 슬라이스별로 달라서 재현이 어려웠음
→ "광범위하고 일관성 없는 품질 저하"처럼 보이는 원인이 된 것
실전 1 — 원인 1: 기본 추론 노력 High → Medium (3월 4일)
# Claude Code effort 레벨 구조
effort_levels = {
"xhigh": "가장 깊이 생각, 가장 느림, 토큰 많이 씀",
"high": "기본값 (원래), 복잡한 태스크에 적합",
"medium": "빠름, 단순 태스크에 적합",
"low": "가장 빠름, 간단한 작업만"
}
# 3월 4일 변경 전
default_effort = "high"
# 3월 4일 변경 후 (문제의 변경)
default_effort = "medium"
# → 이유: Opus 4.6 high 모드에서 UI가 "멈춘 것처럼" 보이는 레이턴시 문제
# → 결과: 복잡한 코딩 태스크에서 눈에 띄는 지능 저하
# 4월 7일 복구 (+ 한 단계 올림)
default_effort = {
"Opus 4.7": "xhigh", # 한 단계 올려서 복구
"기타 모델": "high"
}
[핵심 정리]
→ 레이턴시 줄이려다 추론 품질을 희생한 것
→ Anthropic 공식 입장: "잘못된 트레이드오프였다"
→ 사용자 피드백: "느려도 좋으니 똑똑하게 해달라"
→ 현재: Opus 4.7 기본값 xhigh, 나머지 high
실전 2 — 원인 2: 캐싱 버그로 Thinking이 매 턴 삭제 (3월 26일)
이게 진짜 핵심 버그였습니다.
# Claude Code Thinking 캐시 동작 원리
"""
Claude Code는 추론(Thinking) 결과를 대화 히스토리에 캐시합니다.
덕분에 이전 턴에서 왜 그런 결정을 했는지 다음 턴에서도 참조 가능합니다.
"""
# 의도한 동작 (정상):
def clear_thinking_cache(session):
if session.idle_time > 3600: # 1시간 이상 비활성
session.clear_thinking_once() # 딱 한 번만 삭제
# 이후 턴에서는 정상적으로 Thinking 유지
# 실제 버그 동작 (3월 26일 ~ 4월 10일):
def clear_thinking_cache_bugged(session):
if session.idle_time > 3600:
session.clear_thinking_every_turn() # 매 턴마다 삭제 ← 버그
# → Claude가 매 턴마다 이전 추론 맥락을 잃어버림
# → "이전에 왜 이렇게 했지?" 참조 불가
# → 반복적 실수, 이전 결정 망각, 같은 코드 반복 수정
[버그가 만든 증상]
→ 세션 중간에 갑자기 맥락을 잃은 것처럼 동작
→ 이미 수정한 버그를 다시 만들어냄
→ "왜 이렇게 했는지" 설명 불가능한 상태
→ 캐시 미스 폭증 → 사용량 한도 빠른 소진의 주범
→ 4월 10일 Sonnet 4.6, Opus 4.6에서 수정 완료
Simon Willison(유명 개발자)도 "나는 Claude Code 세션을 1시간 이상, 심지어 하루 이상 놔두고 돌아오는 경우가 많다. 이 버그가 내 작업에 가장 크게 영향을 미쳤다"고 언급했습니다.
실전 3 — 원인 3: 시스템 프롬프트 길이 제한 (4월 16일)
# 4월 16일 추가된 시스템 프롬프트 (문제의 구문)
system_prompt_addition = """
Length limits:
- Keep text between tool calls to ≤25 words.
- Keep final responses to ≤100 words unless the task requires more detail.
"""
# 의도: Opus 4.7이 기존 모델보다 훨씬 장황해서 토큰 절약 목적
# 문제: 다른 프롬프트 변경사항들과 결합되면서 코딩 품질 3% 저하
# 발견: 내부 테스트에서는 문제 없었음
# → 배포 후 확장된 평가셋으로 검증하니 비로소 발견
# 실제 영향 범위:
affected_models = ["Sonnet 4.6", "Opus 4.6", "Opus 4.7"]
# 4월 20일 해당 구문 시스템 프롬프트에서 제거 완료
[교훈 포인트]
→ 25단어 / 100단어 제한이 단순 응답엔 문제없었지만
→ 복잡한 코딩 설명이 필요한 상황에서 품질을 희생
→ 내부 테스트 평가셋이 실제 유저 케이스를 커버 못 했음
→ "내부 테스트 통과 = 안전" 가정이 틀렸다는 것을 Anthropic도 인정
세 가지가 겹치면 어떻게 보이나
타임라인:
3월 4일 → [원인1] 추론 기본값 High → Medium
3월 26일 → [원인2] 캐싱 버그 배포
4월 7일 → [원인1] 복구 (xhigh/high로)
4월 10일 → [원인2] 캐싱 버그 수정
4월 16일 → [원인3] 시스템 프롬프트 길이 제한 추가
+ Opus 4.7 출시 (같은 날)
4월 20일 → [원인3] 시스템 프롬프트 복구
4월 23일 → 공식 포스트모템 발행 + 전 구독자 사용량 리셋
각 변경이 다른 트래픽 슬라이스에 영향:
→ 원인1: Sonnet 4.6, Opus 4.6
→ 원인2: Sonnet 4.6, Opus 4.6
→ 원인3: Sonnet 4.6, Opus 4.6, Opus 4.7
→ 겹치는 구간에서 복합적으로 "전체적 품질 저하"처럼 보임
지금 당장 확인할 것
# Claude Code 버전 확인
claude --version
# v2.1.116 이상이어야 모든 수정 적용됨
# 버전 업데이트
npm update -g @anthropic-ai/claude-code
# 현재 effort 설정 확인
# Claude Code 실행 후 /status 또는 설정 패널에서 확인
# Opus 4.7: xhigh / 나머지: high 가 기본값
[현재 상태 정리]
→ v2.1.116 이상: 세 가지 수정 모두 적용
→ Opus 4.7 기본값: xhigh (이전보다 한 단계 높임)
→ 사용량 한도: 전 구독자 리셋 완료 (4월 23일)
→ API 사용자: 원래부터 영향 없었음
Anthropic이 약속한 재발 방지책
앞으로 달라지는 것:
→ Claude Code 내부 테스트 강화
→ Code Review 툴 개선 (변경사항 영향도 사전 측정)
→ 시스템 프롬프트 변경 평가셋 확장
→ @ClaudeDevs X 계정 운영 — 제품 결정 이유 공개 소통
→ GitHub 스레드에서 개발자 커뮤니티와 직접 소통
마무리
✅ 이번 사태에서 배울 점 (개발자 관점)
→ 하네스(harness) 레이어 버그가 모델 자체 문제처럼 보일 수 있음
→ 프로덕션 AI 시스템에서 캐시 로직은 치명적 포인트
→ 내부 테스트 평가셋이 실제 유저 케이스를 충분히 커버해야 함
→ effort 파라미터 설정은 항상 명시적으로 관리할 것
❌ 오해하면 안 되는 것
→ 모델 가중치 자체는 변경 없었음 (API 영향 없음 = 증거)
→ 의도적 성능 저하("nerfing")는 아님 — 세 가지 독립적 실수
→ 지금은 수정 완료 → v2.1.116 이상으로 업데이트하면 됨
관련 글
Opus 4.7 에이전트 비용 제어 실전 — effort + Task Budget 완전 가이드
에이전트를 Opus 4.7로 돌리면 비용이 예측 불가예요.왜 예측이 안 되냐:→ 에이전트 루프: 생각 + 툴 호출 + 툴 결과 + 출력이 쌓임→ xhigh 기본값: 더 많이 생각함→ 새 토크나이저: 같은 텍스트도
cell-devlog.tistory.com
Claude Code 토큰 낭비 없애는 법 — 컨텍스트 관리 완전 가이드
Claude Code 쓰다 보면 이런 상황이 생겨요.세션 초반: 완벽하게 프로젝트 이해하고 코드 짬세션 중반: "아까 만든 UserService 어디 있었죠?"세션 후반: 이미 만든 함수를 다시 만들고 아키텍처 규칙 위
cell-devlog.tistory.com
'AI Development' 카테고리의 다른 글
| Gemini 3.1 Flash TTS 완전 가이드 — 자연어로 AI 목소리를 연출하는 법 (0) | 2026.04.24 |
|---|---|
| Gemini Enterprise Agent Platform 완전 분석 — Vertex AI가 에이전트 플랫폼으로 진화한 이유 (0) | 2026.04.24 |
| Continue.dev 완전 가이드 — GitHub Copilot 대신 쓰는 무료 오픈소스 AI 코딩 어시스턴트 (0) | 2026.04.23 |
| LiteLLM 완전 가이드 — Claude, GPT, Gemini 100개+ LLM을 코드 한 줄로 전환하기 (0) | 2026.04.23 |
| LLM 추상화 레이어 — 48시간마다 새 모델이 나오는 시대에 살아남는 법 (1) | 2026.04.23 |