최근 Claude Code 품질 보고에 대한 업데이트

• 최근 한 달간 체감된 Claude 품질 저하는 Claude Code, Claude Agent SDK, Claude Cowork에 걸친 서로 다른 세 가지 변경에서 발생했고, API는 영향받지 않음
• 기본 추론 강도를 medium으로 낮춘 뒤 지연 시간과 사용량 제한은 줄었지만, Claude Code가 덜 똑똑해진 것처럼 느껴져 4월 7일 기본값을 다시 되돌림
• 3월 26일 배포된 캐싱 최적화 버그는 유휴 임계값을 넘긴 세션에서 추론 기록을 매 턴 지우는 상태를 만들었고, 건망증·반복·이상한 도구 선택과 더 빠른 usage limits 소모로 이어짐
• 4월 16일 Opus 4.7과 함께 들어간 시스템 프롬프트 한 줄은 출력 장황함을 줄이려던 제한이었지만, 더 넓은 평가에서 일부 모델의 성능이 3% 하락해 4월 20일 되돌려짐
• 세 문제는 모두 수정돼 4월 20일 배포된 v2.1.116에 반영됐고, 내부와 공개 빌드의 차이 축소, 시스템 프롬프트 통제 강화, 더 넓은 평가와 점진적 롤아웃이 재발 방지의 핵심으로 잡힘

최근 품질 저하의 범위와 복구 상태

• 지난 한 달간 일부 사용자가 체감한 Claude 품질 저하는 Claude Code, Claude Agent SDK, Claude Cowork에 걸친 세 가지 별도 변경에서 비롯됐고, API는 영향받지 않음
• 세 문제는 모두 해결됐으며, 4월 20일 배포된 v2.1.116에 반영됨
• 각 변경은 서로 다른 일정과 서로 다른 트래픽 구간에 영향을 줘서, 전체적으로는 광범위하지만 일관되지 않은 성능 저하처럼 보이게 만듦
• 3월 초부터 관련 보고를 조사했지만, 초기에는 일반적인 사용자 피드백 변동과 구분하기 어려웠고, 내부 사용과 평가에서도 처음에는 같은 문제가 재현되지 않음
• 4월 23일 기준으로 모든 구독자의 usage limits를 초기화함

Claude Code 기본 추론 강도 변경

• 2월에 Claude Code에서 Opus 4.6를 출시할 때 기본 추론 강도는 high로 설정됨
• 곧이어 high 모드에서 지나치게 긴 사고 시간이 간헐적으로 발생해 UI가 멈춘 것처럼 보였고, 일부 사용자에게는 지연 시간과 토큰 사용량이 과도하게 커짐
• Claude Code의 effort 수준은 더 오래 생각하게 할지, 더 낮은 지연 시간과 더 적은 사용량 제한 소모를 택할지 조절하는 수단으로 쓰임
  • 제품 레이어에서는 테스트 시점 계산 곡선 중 기본값 하나를 정해 Messages API에 effort 파라미터로 전달함
  • 다른 선택지는 /effort로 제공됨
• 내부 평가와 테스트에서는 medium이 대다수 작업에서 지능은 약간 낮고 지연은 크게 줄어드는 결과를 냄
  • medium은 매우 긴 꼬리 지연 문제도 덜했고
  • 사용자의 usage limits를 최대화하는 데도 유리했음
• 이런 결과를 바탕으로 기본 effort를 medium으로 바꾸고, 제품 내 대화상자로 이유도 함께 알림
• 배포 직후 사용자는 Claude Code가 덜 똑똑해진 것처럼 느끼기 시작함
  • 현재 effort 설정을 더 잘 보이게 하려고 시작 시 알림, 인라인 effort 선택기, ultrathink 복구 같은 여러 디자인 변경을 넣었지만
  • 대부분 사용자는 여전히 medium 기본값에 머묾
• 추가 고객 피드백을 반영해 4월 7일 이 결정을 되돌림
  • 이제 모든 사용자는 Opus 4.7에서 xhigh가 기본값이고
  • 다른 모든 모델에서는 high가 기본값으로 적용됨
• 이 변경은 Sonnet 4.6과 Opus 4.6에 영향을 줌

이전 추론 기록을 떨어뜨린 캐싱 최적화

• Claude가 작업을 추론할 때 그 추론 기록은 대화 히스토리에 남아, 이후 턴마다 이전 수정과 도구 호출의 이유를 계속 참조하게 만듦
• 3월 26일에는 이 기능의 효율을 높이기 위한 변경이 배포됨
  • Anthropic은 연속된 API 호출을 더 싸고 빠르게 만들기 위해 prompt caching을 사용함
  • Claude는 API 요청 시 입력 토큰을 캐시에 쓰고, 일정 시간 비활성 상태가 지나면 해당 프롬프트는 캐시에서 제거되어 다른 프롬프트를 위한 공간을 비움
  • 캐시 활용도는 신중히 관리되며, 관련 접근 방식은 approach에 정리돼 있음
• 설계상으로는 세션이 한 시간 넘게 유휴 상태였다면, 이전 thinking 구간을 한 번 비워 세션 재개 비용을 낮추려 했음
  • 그 요청은 어차피 캐시 미스가 되므로, 요청에서 불필요한 메시지를 잘라 API로 보내는 uncached 토큰 수를 줄이려 했음
  • 이후에는 다시 전체 추론 히스토리를 보내도록 설계됨
  • 이를 위해 clear_thinking_20251015 API 헤더와 keep:1을 사용함
• 실제 구현에는 버그가 있었고, thinking 기록을 한 번만 지워야 하는데 세션이 끝날 때까지 매 턴마다 계속 지움
• 세션이 한 번 유휴 임계값을 넘으면, 그 이후 해당 프로세스의 모든 요청은 가장 최근 추론 블록만 남기고 이전 것은 버리도록 API에 전달됨
• 이 문제는 누적적으로 악화됨
  • Claude가 도구를 사용하는 도중 후속 메시지를 보내면 그 자체가 깨진 플래그 아래의 새 턴이 됨
  • 그 결과 현재 턴의 추론까지 떨어져 나갈 수 있음
• Claude는 계속 실행되지만, 왜 그런 행동을 선택했는지에 대한 기억 없이 점점 더 동작하게 됨
  • 사용자에게는 건망증, 반복, 이상한 도구 선택으로 드러남
• 후속 요청에서도 thinking 블록이 계속 사라지기 때문에, 그 요청들은 캐시 미스로 이어짐
  • usage limits가 예상보다 빨리 소모된다는 별도 보고는 이 현상에서 비롯된 것으로 봄
• 초기에 재현이 어려웠던 배경에는 관련 없는 두 실험이 있었음
  • 메시지 큐잉과 관련된 내부 전용 서버 측 실험
  • thinking 표시 방식의 별도 변경이 대부분의 CLI 세션에서 이 버그를 가려버림
• 이 버그는 Claude Code의 컨텍스트 관리, Anthropic API, 확장 thinking이 만나는 지점에 있었음
  • 여러 사람의 코드 리뷰와 자동 코드 리뷰
  • 단위 테스트와 종단간 테스트
  • 자동 검증과 dogfooding까지 통과함
• 이 문제는 낡은 세션이라는 코너 케이스에서만 발생했고 재현도 어려워서, 근본 원인을 발견하고 확인하는 데 1주일 넘게 걸림
• 조사 과정에서 문제를 일으킨 pull request들에 대해 Code Review를 Opus 4.7으로 백테스트함
  • 전체 맥락을 모으는 데 필요한 코드 저장소를 함께 제공하면 Opus 4.7은 버그를 찾아냈고
  • Opus 4.6은 찾아내지 못함
• 같은 일이 반복되지 않도록 코드 리뷰에 추가 저장소를 컨텍스트로 넣는 지원을 도입 중임
• 이 버그는 4월 10일 v2.1.101에서 수정됨
• 이 변경은 Sonnet 4.6과 Opus 4.6에 영향을 줌

장황함을 줄이려던 시스템 프롬프트 변경

• 최신 모델인 Claude Opus 4.7은 이전 모델보다 매우 장황한 출력을 보이는 특성이 있음
  • 출시 시점 안내에서도 이 특성을 다뤘고, 자세한 내용은 wrote about에서 확인 가능함
• 이런 장황함은 어려운 문제에서 더 똑똑하게 만들지만, 출력 토큰 수도 늘림
• Opus 4.7 출시 몇 주 전부터 Claude Code는 새 모델에 맞춰 조정 작업을 진행함
  • 각 모델은 조금씩 다르게 동작해서, 릴리스 전에는 harness와 제품을 모델별로 최적화함
• 장황함을 줄이는 수단으로는 모델 학습, 프롬프팅, 제품 내 thinking UX 개선을 함께 사용함
• 그중 시스템 프롬프트에 추가된 한 줄이 Claude Code의 지능에 과도한 영향을 줌
  • “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 도구를 개선하고, 이 개선판을 고객에게도 배포할 예정임
• 시스템 프롬프트 변경에는 더 엄격한 통제 절차를 추가함
  • Claude Code의 모든 시스템 프롬프트 변경에 대해 모델별로 폭넓은 평가를 수행함
  • 각 줄의 영향을 이해하기 위한 ablation을 계속 진행함
  • 프롬프트 변경을 더 쉽게 리뷰하고 감사할 수 있는 새 도구도 구축함
• CLAUDE.md에는 모델별 변경이 해당 모델에만 적용되도록 하는 가이드를 추가함
• 지능과 상충할 수 있는 모든 변경에는 soak period, 더 넓은 평가 세트, 점진적 롤아웃을 붙여 문제를 더 빨리 잡도록 함
• 제품 결정과 그 배경을 더 자세히 설명하기 위해 X에 @ClaudeDevs를 만들었고, 같은 업데이트를 GitHub의 중앙화된 스레드에도 공유할 예정임
• /feedback 명령이나 온라인의 구체적이고 재현 가능한 예시를 통해 전달된 정보가 문제 식별과 수정으로 이어짐
• 모든 구독자의 usage limits 초기화는 이날 다시 적용됨