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

지난 한 달간, 일부 사용자로부터 Claude의 응답 품질이 저하됐다는 제보가 이어졌습니다. 조사 결과, 이 문제는 각각 Claude Code, Claude Agent SDK, Claude Cowork에 영향을 미친 세 가지 별개의 변경 사항에서 비롯된 것으로 확인됐습니다. API에는 영향이 없었습니다.

세 가지 문제 모두 4월 20일(v2.1.116) 기준으로 해결되었습니다.

이 글에서는 발견한 내용, 수정 사항, 그리고 유사한 문제의 재발 방지를 위해 앞으로 달라질 점을 설명합니다.

저희는 성능 저하 관련 제보를 매우 심각하게 받아들입니다. 모델 품질을 의도적으로 낮춘 적은 없으며, API와 추론 레이어에는 영향이 없었음을 즉시 확인할 수 있었습니다.

조사를 통해 세 가지 문제를 파악했습니다.

1. 3월 4일, 일부 사용자가 high 모드에서 UI가 멈춘 것처럼 보일 만큼 지연 시간이 길어지는 현상을 겪고 있어, Claude Code의 기본 추론 노력(reasoning effort) 수준을 high에서 medium로 낮췄습니다. 이는 잘못된 트레이드오프였습니다. 이후 사용자들로부터 기본값은 높은 지능 수준으로 유지하고, 간단한 작업에 한해 낮은 노력 수준을 선택할 수 있도록 해달라는 의견을 받아, 4월 7일 해당 변경을 되돌렸습니다. 이 문제는 Sonnet 4.6과 Opus 4.6에 영향을 미쳤습니다.
2. 3월 26일, 1시간 이상 유휴 상태였던 세션을 재개할 때의 지연을 줄이기 위해 오래된 사고(thinking) 기록을 삭제하는 변경 사항을 배포했습니다. 그런데 버그로 인해 이 삭제가 세션 재개 시 한 번만 이루어지지 않고 이후 모든 턴마다 반복되었고, 결과적으로 Claude가 건망증이 있거나 같은 말을 반복하는 것처럼 보이는 문제가 발생했습니다. 4월 10일에 수정했으며, Sonnet 4.6과 Opus 4.6에 영향을 미쳤습니다.
3. 4월 16일, 출력 길이를 줄이기 위한 시스템 프롬프트 지침을 추가했습니다. 그런데 다른 프롬프트 변경 사항과 맞물려 코딩 품질이 저하되었고, 4월 20일에 되돌렸습니다. 이 문제는 Sonnet 4.6, Opus 4.6, Opus 4.7에 영향을 미쳤습니다.

각 변경 사항이 서로 다른 일정으로 서로 다른 트래픽 구간에 영향을 미쳤기 때문에, 전체적으로는 광범위하고 일관성 없는 성능 저하처럼 보였습니다. 3월 초부터 제보를 조사하기 시작했지만, 초기에는 일반적인 사용자 피드백의 변동과 구별하기 어려웠고, 내부 사용 환경이나 평가(eval)에서도 처음에는 문제가 재현되지 않았습니다.

이는 사용자가 Claude Code에서 경험해야 할 수준이 아닙니다. 4월 23일부로 모든 구독자의 사용 한도를 초기화합니다.

Claude Code 기본 추론 노력 수준 변경

2월에 Claude Code에 Opus 4.6을 출시할 때, 기본 추론 노력 수준을 high로 설정했습니다.

출시 직후, 높은 노력 수준 모드에서 Claude Opus 4.6이 간헐적으로 너무 오래 사고하여 UI가 멈춘 것처럼 보이고 일부 사용자에게 과도한 지연과 토큰 사용이 발생한다는 피드백을 받았습니다.

일반적으로 모델이 오래 사고할수록 출력 품질이 높아집니다. 노력 수준은 Claude Code에서 사용자가 이 트레이드오프—더 깊은 사고 대 낮은 지연 및 사용 한도 절약—를 직접 조정할 수 있는 수단입니다. 저희는 모델별로 노력 수준을 조율할 때 이 트레이드오프를 고려하여 테스트 타임 컴퓨트 곡선상에서 사용자에게 최적의 선택지를 제공하는 지점들을 선별합니다. 그런 다음 제품 레이어에서 이 곡선 위의 어느 지점을 기본값으로 설정할지 결정하고, 해당 값을 Messages API에 effort 파라미터로 전달합니다. 나머지 옵션은 /effort.를 통해 이용할 수 있습니다.

내부 평가와 테스트 결과, medium 노력 수준은 대다수의 작업에서 지능 수준이 소폭 낮아지는 대신 지연이 크게 줄어들었습니다. 또한 높은 노력 수준에서 간헐적으로 발생하는 긴 꼬리 지연 문제도 없었고, 사용자의 사용 한도를 더 효율적으로 활용할 수 있었습니다. 이에 따라 medium을 기본 노력 수준으로 변경하는 업데이트를 배포하고, 인앱 다이얼로그를 통해 그 이유를 안내했습니다.

배포 직후 사용자들은 Claude Code가 이전보다 덜 똑똑하게 느껴진다는 피드백을 보내기 시작했습니다. 저희는 현재 노력 수준 설정을 더 명확하게 표시하여 사용자가 기본값을 바꿀 수 있다는 사실을 알 수 있도록 여러 디자인 개선을 했습니다(시작 시 알림 표시, 인라인 노력 수준 선택기 추가, ultrathink 재도입). 그러나 대부분의 사용자는 medium 노력 수준 기본값을 그대로 유지했습니다.

더 많은 고객의 피드백을 수렴한 끝에 4월 7일 이 결정을 번복했습니다. 이제 Opus 4.7은 기본값이 xhigh 노력 수준이며, 그 외 모든 모델은 high 노력 수준이 기본값입니다.

이전 추론 기록을 삭제한 캐싱 최적화 문제

Claude가 작업을 추론하면, 그 추론 내용은 대화 기록에 유지되어 이후 모든 턴에서 Claude가 자신이 왜 해당 편집과 툴 호출을 했는지 참조할 수 있습니다.

3월 26일, 이 기능의 효율을 높이기 위한 개선을 배포했습니다. 저희는 프롬프트 캐싱을 활용해 연속적인 API 호출의 비용과 속도를 개선합니다. Claude는 API 요청 시 입력 토큰을 캐시에 기록하고, 일정 시간 비활성 상태가 되면 프롬프트가 캐시에서 제거되어 다른 프롬프트를 위한 공간이 확보됩니다. 캐시 활용은 저희가 세심하게 관리하는 영역입니다(접근 방식에 대한 자세한 내용은 링크 참고).

설계는 단순했습니다. 세션이 1시간 이상 유휴 상태였다면, 오래된 사고 섹션을 삭제함으로써 세션 재개 비용을 줄일 수 있습니다. 어차피 캐시 미스가 발생하는 요청이므로, 불필요한 메시지를 요청에서 제거하여 API로 전송되는 비캐시 토큰 수를 줄이는 방식입니다. 이후에는 전체 추론 기록을 다시 전송하도록 했습니다. 이를 위해 clear_thinking_20251015 API 헤더와 keep:1.를 함께 사용했습니다.

구현에 버그가 있었습니다. 사고 기록이 한 번만 삭제되어야 했는데, 세션이 끝날 때까지 매 턴마다 반복적으로 삭제되었습니다. 세션이 유휴 임계값을 한 번 넘으면, 이후 해당 프로세스의 모든 요청에서 가장 최근 추론 블록만 유지하고 그 이전 내용은 모두 폐기하도록 API에 지시했습니다. 이는 복합적으로 작용했습니다. Claude가 툴을 사용하는 도중에 후속 메시지를 보내면 손상된 플래그 아래 새로운 턴이 시작되어, 현재 턴의 추론까지 삭제되었습니다. Claude는 계속 실행을 이어갔지만, 자신이 왜 그 작업을 하고 있었는지에 대한 기억은 점점 사라졌습니다. 이것이 사용자들이 보고한 건망증, 반복, 이상한 툴 선택으로 나타났습니다.

이 버그로 인해 후속 요청에서 사고 블록이 지속적으로 제거되면서 캐시 미스도 반복 발생했습니다. 이것이 예상보다 빠르게 사용 한도가 소진된다는 별도의 제보와 연관된 원인으로 추정됩니다.

두 가지 무관한 실험이 초기에 문제 재현을 어렵게 만들었습니다. 하나는 메시지 큐잉과 관련된 내부 전용 서버사이드 실험이었고, 다른 하나는 CLI 세션에서 사고 표시 방식을 변경한 사항으로, 이 변경이 대부분의 CLI 세션에서 버그를 숨겨 외부 빌드를 테스트할 때조차 발견하지 못했습니다.

이 버그는 Claude Code의 컨텍스트 관리, Anthropic API, 확장 사고(extended thinking)가 교차하는 지점에서 발생했습니다. 해당 변경 사항은 여러 차례의 사람 및 자동화 코드 리뷰, 유닛 테스트, 엔드투엔드 테스트, 자동화 검증, dogfooding을 모두 통과했습니다. 여기에 문제가 특수한 상황(유휴 세션)에서만 발생하는 데다 재현 자체가 어려워, 근본 원인을 발견하고 확인하는 데 일주일 이상이 걸렸습니다.

조사 과정에서 Opus 4.7을 활용해 문제의 풀 리퀘스트를 코드 리뷰로 역검증했습니다. 완전한 컨텍스트 확보에 필요한 코드 저장소를 제공했을 때, Opus 4.7은 버그를 찾아냈지만 Opus 4.6은 찾지 못했습니다. 재발 방지를 위해, 코드 리뷰 시 추가 저장소를 컨텍스트로 제공하는 기능 지원을 도입하고 있습니다.

이 버그는 4월 10일 v2.1.101에서 수정되었습니다.

출력 길이 축소를 위한 시스템 프롬프트 변경

최신 모델인 Claude Opus 4.7은 전작 대비 두드러지는 행동적 특성이 있습니다. 출시 당시 공개한 글에서 밝혔듯, 이 모델은 상당히 장황한 경향이 있습니다. 이는 어려운 문제를 더 잘 풀게 하지만, 동시에 더 많은 출력 토큰을 생성합니다.

Opus 4.7 출시 몇 주 전부터 Claude Code 준비 작업을 시작했습니다. 모델마다 동작 방식이 조금씩 다르기 때문에, 출시 전 모델에 맞게 하네스와 제품을 최적화하는 데 시간을 투자합니다.

출력 길이를 줄이기 위한 수단으로는 모델 학습, 프롬프트 조정, 제품 내 사고 UX 개선 등 여러 방법을 사용합니다. 결과적으로 이 모든 방법을 활용했지만, 시스템 프롬프트에 추가한 한 가지 항목이 Claude Code의 지능 수준에 과도한 영향을 미쳤습니다.

"길이 제한: 툴 호출 사이의 텍스트는 25단어 이하로 유지하세요. 최종 응답은 작업에 더 많은 세부 정보가 필요한 경우가 아니라면 100단어 이하로 유지하세요."

수 주간의 내부 테스트를 거치고, 실행한 평가 항목에서 회귀가 발견되지 않아, 4월 16일 Opus 4.7과 함께 이 변경 사항을 자신 있게 배포했습니다.

이번 조사에서 더 넓은 평가 항목을 활용해 어블레이션(시스템 프롬프트의 각 항목을 제거해 영향을 파악하는 작업)을 추가로 진행했습니다. 그 결과 Opus 4.6과 4.7 모두에서 3%의 성능 하락을 보이는 평가 항목이 발견되었고, 저희는 4월 20일 릴리즈에서 해당 프롬프트를 즉시 되돌렸습니다.

앞으로의 방향

이러한 문제를 방지하기 위해 몇 가지를 달리 운영할 예정입니다. 내부 직원 중 더 많은 비율이 새 기능 테스트용 버전이 아닌 실제 공개 빌드의 Claude Code를 사용하도록 하고, 내부적으로 활용하는 코드 리뷰 도구를 개선한 뒤 해당 개선 버전을 고객에게도 제공할 것입니다.

시스템 프롬프트 변경에 대한 통제도 강화합니다. Claude Code의 모든 시스템 프롬프트 변경에 대해 모델별 광범위한 평가를 실행하고, 각 항목의 영향을 파악하기 위한 어블레이션을 지속하며, 프롬프트 변경 사항의 검토와 감사를 용이하게 하는 새로운 도구를 구축했습니다. 또한 모델별 변경 사항이 해당 모델에만 적용되도록 CLAUDE.md에 가이드라인을 추가했습니다. 지능 수준과의 트레이드오프가 발생할 수 있는 변경의 경우, 소크 기간 설정, 더 광범위한 평가 항목 적용, 점진적 배포를 통해 문제를 더 빠르게 발견할 수 있도록 하겠습니다.

최근 X에 @ClaudeDevs 계정을 개설했습니다. 제품 결정 사항과 그 이면의 이유를 더 깊이 있게 설명하기 위한 공간으로 활용할 예정입니다. 동일한 업데이트는 GitHub의 중앙화된 스레드를 통해서도 공유하겠습니다.

마지막으로 사용자 여러분께 감사드립니다. /feedback 명령어로 문제를 직접 공유해 주신 분들, 그리고 구체적이고 재현 가능한 사례를 온라인에 게시해 주신 분들 덕분에 이 문제들을 파악하고 해결할 수 있었습니다. 오늘 모든 구독자의 사용 한도를 초기화합니다.

피드백과 인내심에 깊이 감사드립니다.