Claude Code가 멍청해진 이유 — Anthropic이 직접 밝힌 3가지 원인과 수정 내역

지난 한 달간 Claude Code가 이상하다고 느끼셨다면, 착각이 아니었습니다. Anthropic이 공식 포스트모템을 발행했습니다.

[핵심 요약]

이번 품질 저하는 2026년 3월 4일부터 4월 20일까지 약 47일간 지속됐으며, 영향 범위는 Claude Code, Claude Agent SDK, Claude Cowork였습니다. API 직접 사용자는 영향을 받지 않았습니다. 원인은 세 가지로 정리됩니다. 첫째, 기본 추론 노력을 High에서 Medium으로 낮춘 것(3월 4일), 둘째, 캐싱 버그로 매 턴마다 Thinking이 삭제된 것(3월 26일), 셋째, 시스템 프롬프트에 응답 길이 제한이 추가된 것(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의 추론 노력은 xhigh, high, medium, low 네 단계로 구성됩니다. 원래 기본값은 high로, 복잡한 코딩 태스크에 적합한 수준이었습니다. 3월 4일, Anthropic은 이 기본값을 medium으로 낮췄습니다. Opus 4.6 high 모드에서 UI가 멈춘 것처럼 보이는 레이턴시 문제를 해소하기 위한 결정이었습니다.

# 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도 공식 입장에서 "잘못된 트레이드오프였다"고 인정했고, 사용자들의 피드백은 명확했습니다. "느려도 좋으니 똑똑하게 해달라"는 것이었습니다. 4월 7일 복구 시점에는 오히려 Opus 4.7 기본값을 xhigh로 한 단계 올려서 배포했습니다.

---

실전 2 — 원인 2: 캐싱 버그로 Thinking이 매 턴 삭제 (3월 26일)

세 가지 원인 중 실질적인 영향이 가장 컸던 버그입니다. Claude Code는 추론(Thinking) 결과를 대화 히스토리에 캐시해서 이전 턴의 결정 맥락을 다음 턴에서도 참조할 수 있도록 설계되어 있습니다. 3월 26일 배포된 코드에는 이 캐시 삭제 로직에 버그가 있었습니다.

# 의도한 동작 (정상):
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가 매 턴마다 이전 추론 맥락을 잃어버림
        # → "이전에 왜 이렇게 했지?" 참조 불가
        # → 반복적 실수, 이전 결정 망각, 같은 코드 반복 수정

정상 동작은 세션이 1시간 이상 비활성화됐을 때 캐시를 딱 한 번만 삭제하는 것입니다. 그러나 버그가 있는 코드는 비활성 조건이 충족되면 매 턴마다 캐시를 삭제했습니다. 이 때문에 Claude가 세션 중간에 갑자기 맥락을 잃은 것처럼 동작하고, 이미 수정한 버그를 다시 만들어내고, 캐시 미스가 폭증하면서 사용량 한도를 빠르게 소진시키는 증상이 나타났습니다.

유명 개발자 Simon Willison도 "나는 Claude Code 세션을 1시간 이상, 심지어 하루 이상 놔두고 돌아오는 경우가 많다. 이 버그가 내 작업에 가장 크게 영향을 미쳤다"고 언급했습니다. 버그는 4월 10일 Sonnet 4.6과 Opus 4.6에서 수정 완료됐습니다.

---

실전 3 — 원인 3: 시스템 프롬프트 길이 제한 (4월 16일)

4월 16일, Opus 4.7 출시와 같은 날 시스템 프롬프트에 응답 길이를 제한하는 구문이 추가됐습니다. Opus 4.7이 기존 모델보다 훨씬 장황하게 응답하는 경향이 있어 토큰을 절약하려는 목적이었습니다.

# 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단어 제한은 단순한 응답엔 문제가 없었지만, 복잡한 코딩 설명이 필요한 상황에서 품질을 희생시켰습니다. 더 큰 문제는 내부 테스트에서는 통과했다는 점입니다. 배포 후 확장된 평가셋으로 검증했을 때 비로소 코딩 품질 3% 저하가 확인됐습니다. Anthropic도 "내부 테스트 통과 = 안전"이라는 가정이 틀렸다는 것을 공식적으로 인정했습니다. 해당 구문은 4월 20일 시스템 프롬프트에서 제거됐습니다.

---

세 가지가 겹치면 어떻게 보이나

세 원인이 각기 다른 시점에 배포되고 수정됐기 때문에, 외부에서 보면 "전체적 품질 저하"처럼 느껴지는 게 당연했습니다.

날짜 내용

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과 2는 Sonnet 4.6과 Opus 4.6에 영향을 미쳤고, 원인 3은 Opus 4.7까지 포함한 전 모델에 영향을 줬습니다. 세 원인이 서로 다른 트래픽 슬라이스에 겹쳐서 재현 자체가 어려웠고, 결과적으로 "전반적이고 일관성 없는 품질 저하"처럼 보이는 원인이 됐습니다.

---

지금 당장 확인할 것

v2.1.116 이상으로 업데이트하면 세 가지 수정이 모두 적용됩니다. 아래 명령어로 버전을 확인하고 업데이트하세요.

# 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이 약속한 재발 방지책

Anthropic은 포스트모템에서 구체적인 재발 방지책을 공개했습니다. Claude Code 내부 테스트를 강화하고, Code Review 툴을 개선해 변경사항의 영향도를 사전에 측정할 수 있도록 합니다. 시스템 프롬프트 변경에 적용되는 평가셋도 실제 사용자 케이스를 더 잘 커버할 수 있도록 확장됩니다. 소통 방식도 달라집니다. @ClaudeDevs X 계정을 운영하며 제품 결정 이유를 공개적으로 공유하고, GitHub 스레드에서 개발자 커뮤니티와 직접 소통할 예정입니다.

---

마무리

이번 사태는 모델 자체의 문제가 아니었습니다. 하네스(harness) 레이어의 버그와 설정 변경이 쌓여서 모델이 멍청해진 것처럼 보인 케이스였습니다. 개발자 입장에서 배울 점은 분명합니다. 프로덕션 AI 시스템에서 캐시 로직은 치명적인 포인트가 될 수 있고, 내부 테스트 평가셋이 실제 사용자 케이스를 충분히 커버하지 못하면 배포 후에야 문제가 드러납니다. effort 파라미터 같은 설정값은 항상 명시적으로 관리하는 습관이 필요합니다.

오해하지 말아야 할 것도 있습니다. 모델 가중치 자체는 변경이 없었고, API 사용자에게 영향이 없었다는 게 이를 증명합니다. 의도적인 성능 저하가 아니라 세 가지 독립적인 실수가 겹친 결과였습니다. 지금은 수정이 완료됐으니 v2.1.116 이상으로 업데이트하면 됩니다.

 

관련 글

Opus 4.7 에이전트 비용 제어 실전 — effort + Task Budget 완전 가이드

 

Claude Code 토큰 낭비 없애는 법 — 컨텍스트 관리 완전 가이드