Executive Summary

아래는 이번 사건의 핵심 수치를 한눈에 정리한 것이다.

3월 4일, Claude Code의 기본 추론 노력(reasoning effort)을 high에서 medium으로 내렸다. 목적은 UI 지연 해결이었다. 사용자들은 곧바로 알아챘다.

"Claude가 덜 똑똑해졌다."

medium은 생각을 덜 하는 모드다. 응답은 빨라지지만, 복잡한 문제에서 정확도가 떨어진다. 속도와 지능의 트레이드오프에서 Anthropic은 속도를 택했고, 사용자들은 지능을 원했다.

4월 7일에 되돌렸다. 현재 Opus 4.7은 xhigh, 나머지 모델은 high가 기본이다.

3월 26일, 캐시 최적화 작업에서 버그가 배포되었다. 한 번만 실행될 정리 로직이 매 턴마다 반복 실행되었다. 결과는 건망증과 반복이었다. Claude가 같은 말을 되풀이하고, 방금 논의한 맥락을 잊어버렸다.

이 버그는 코드 리뷰, 유닛 테스트, e2e 테스트, 자동 검증, 내부 사용 — 모든 관문을 통과했다. 발견한 것은 Opus 4.7의 코드 리뷰였다. 4.6으로는 찾지 못했다. 더 똑똑한 모델이 더 교묘한 버그를 잡았다.

4월 10일에 수정되었다.

4월 16일, 시스템 프롬프트가 바뀌었다. 새 지시: "도구 호출 사이에는 25단어 이내로, 최종 응답은 100단어 이내로."

목적은 도구 호출 사이의 불필요한 텍스트를 줄이는 것이었다. 수 주간 내부 테스트를 통과했다. 그러나 배포 후 코딩 품질이 3% 하락한 것이 확인되었다.

말을 짧게 하라는 지시가 생각까지 짧게 만들었다. 설명을 줄이려다 추론의 밀도까지 줄어들었다.

4월 20일에 되돌렸다.

세 변경은 각각 다른 날짜에, 다른 트래픽 비율에 적용되었다. 각각은 작은 문제였지만, 합산 효과는 "비일관적 저하"라는 혼란스러운 증상으로 나타났다. 어떤 사용자는 문제를 느꼈고, 어떤 사용자는 괜찮았다. 원인을 특정하기 어려운 가장 까다로운 종류의 장애였다.

API는 영향받지 않았다. 문제는 전적으로 제품 레이어 — 하네스, 시스템 프롬프트, 캐싱 — 에서 발생했다. 같은 모델이 API로는 정상이고, 제품으로는 이상했다.

아래는 사건의 전체 타임라인이다.

Anthropic은 대응책을 내놓았다. 영향받은 사용자의 사용 한도를 리셋했고, @ClaudeDevs 채널을 개설해 제품 변경 사항을 실시간으로 공유하기 시작했다. 공개 빌드를 내부에서도 동일하게 사용하고, 시스템 프롬프트 변경에 대한 통제를 강화했다.

그러나 더 깊은 교훈은 조직적 대응이 아니라 구조적 진실에 있다.

시스템 프롬프트는 모델이 세상을 인식하는 방식을 결정한다. 캐시는 모델이 기억을 유지하는 메커니즘이다. 추론 노력은 모델이 얼마나 깊이 생각할지를 결정하는 설정이다. 이 세 가지는 모델 가중치 바깥에 있지만, 사용자 경험은 이것들로 결정된다.

그리고 이 문제를 발견한 건 사용자들이었다. 내부 테스트도, 자동화된 검증도, 코드 리뷰도 이 세 변경의 합산 효과를 잡아내지 못했다. 실전 사용자가 매일 겪는 워크플로우의 미묘한 저하를 감지한 것이다. 모델을 만드는 사람보다 모델을 쓰는 사람이 모델을 더 잘 안다는, 오래된 진실의 반복이다.

참고문헌

1. Anthropic Engineering — April 23 Postmortem — Claude 성능 저하 원인과 대응에 대한 공식 포스트모템
2. VentureBeat — Mystery solved: Anthropic reveals changes to Claude's harnesses — 하네스 변경이 성능 저하의 원인이었음을 보도
3. The Register — Anthropic says it has fixed the issues — 문제 해결과 재발 방지책에 대한 보도