Anthropic April 23 Postmortem: 3 Confounding Changes Behind Claude Code's Month-Long Quality Drop

개요

Anthropic의 Claude Code에서 발생한 한 달간의 품질 저하 현상은 세 가지 동시 배포된 변경 사항이 복합적으로 작용한 결과이며, 이는 AI 시스템의 사고 대응 및 거버넌스에 대한 중요한 시사점을 제공한다.

주요 내용

* 영향받은 제품: Claude Code, Claude Agent SDK, Claude Cowork 세 가지 제품에 영향을 미쳤으며, Anthropic API 자체는 영향을 받지 않았다.
* 품질 저하 증상: 응답 길이 감소, 세션 중 맥락 손실, 사용량 제한 초과 속도 증가 등의 문제가 보고되었다.
* 주요 원인 1: 기본 'Effort' 설정 변경 (3월 4일): Sonnet 4.6 및 Opus 4.6의 기본 'thinking effort'가 'high'에서 'medium'으로 하향 조정되었다. 이는 응답 속도 향상을 통한 사용자 경험 개선을 위한 조치였으나, 사용자는 정확도를 위해 더 긴 응답 시간을 선호하는 것으로 나타났다. 4월 7일 'high'로 복구되었으며, Opus 4.7은 'xhigh'를 기본값으로 사용한다.
* 주요 원인 2: 캐싱 버그 (3월 26일): 1시간 이상 유휴 세션 후 stale한 'thinking section'을 제거하려던 캐싱 최적화 로직이 오작동하여, 임계값을 넘은 후 매 턴마다 캐싱을 제거하는 현상이 발생했다. 이로 인해 Claude는 세션 중 이전 결정 사항을 잊고, 동일한 접근 방식을 반복하며, 맥락 없이 잘못된 도구를 선택하는 문제가 발생했다. 이 버그는 여러 검증 단계를 통과했으나, 두 가지 독립적인 실험(서버 측 메시지 큐 실험, 사고 표시 변경 실험)에 의해 가려졌었다. Opus 4.7 모델이 이 버그를 탐지했으며, 이는 차세대 모델을 활용한 감사(auditing)의 중요성을 보여준다. 버그는 v2.1.101에서 수정되었다.
* 주요 원인 3: 시스템 프롬프트 변경 (4월 16일): Opus 4.7의 토큰 비용 절감을 위해 시스템 프롬프트에 "도구 호출 간 텍스트를 25단어 이하로 유지" 및 "최종 응답을 100단어 이하로 유지 (세부 정보 필요 시 제외)"라는 두 줄의 제약 조건이 추가되었다. 이 변경은 내부 테스트에서 회귀(regression)를 발견하지 못했으나, 특정 평가에서 3%의 성능 저하를 야기한 것으로 확인되었다. 4월 20일 이 변경 사항은 롤백되었다.
* 단기 개발자를 위한 5가지 교훈:
1. 다중 복합적 변경 지양: 여러 변경 사항을 동시에 배포하면 사고 대응 및 원인 규명이 어려워지므로, 한 번에 하나의 변수만 변경하는 것이 중요하다.
2. 평가(Eval)의 맹점 인지: 포괄적인 평가 시스템이라도 맹점이 존재할 수 있으므로, 주기적인 평가 검증(ablation test, 타 모델 활용 비교, 실제 사용자 데이터 비교)이 필요하다.
3. 시스템 프롬프트의 중요성: 시스템 프롬프트는 프로덕션 코드처럼 취급되어야 하며, 버전 관리, ablation test, 점진적 출시, 회귀 테스트가 필요하다.
4. 사용자 피드백 경청: 사용자의 기본값에 대한 반발은 defaults 변경의 신호이며, 사용자는 테스트에서 측정되지 않는 부분을 평가하는 역할을 한다.
5. 차세대 모델로 현재 모델 감사: 새로운 모델 출시 시, 기존 코드 검토 및 문서 등을 새 모델로 다시 검증하는 것은 잠재적 문제를 발견하는 데 효과적이다.
* Anthropic의 향후 약속: 내부 직원의 공개 빌드 사용, 시스템 프롬프트 변경에 대한 엄격한 검증 강화, 모델별 변경 가이드라인 마련, 지능 trade-off 변경 시 점진적 출시 및 광범위한 평가, 제품 결정 맥락 설명 X 계정 운영, GitHub 스레드 공유, 4월 23일 구독자 사용량 제한 초기화 등이 포함된다.

시사점

AI 시스템의 사고 대응 및 거버넌스는 기존 소프트웨어와 다르며, 불완전한 평가 범위, 모델의 비결정성, 프롬프트 및 캐싱 레이어의 복잡한 상호작용으로 인해 디버깅이 더욱 어렵기 때문에, ablation, back-testing, 점진적 출시, 사용자 피드백 채널, 평가 시스템 자체 검증 등이 표준 절차로 진화해야 한다.