클로드 코드 품질 보고서 최신 업데이트

개발자 뉴스레터를 받아보세요

제품 업데이트, 사용 방법, 커뮤니티 소식 등 다양한 정보가 매월 당신의 받은편지함으로 찾아가요.

지난 한 달 동안, 앤트로픽 팀은 일부 사용자들로부터 클로드의 응답 품질이 나빠졌다는 보고를 면밀히 조사해왔어요. 이러한 보고의 원인을 클로드 코드, 클로드 에이전트 SDK, 그리고 클로드 코워크에 영향을 미친 세 가지 개별 변경사항에서 찾아냈네요. 다행히 API는 영향을 받지 않았어요.

이 세 가지 문제는 4월 20일 (v2.1.116) 기준으로 모두 해결되었어요.

이 게시물에서는 앤트로픽 팀이 무엇을 발견했고, 어떻게 고쳤으며, 앞으로 비슷한 문제가 재발할 가능성을 낮추기 위해 어떤 점들을 다르게 해나갈지 설명해 드릴게요.

성능 저하 보고에 대해서는 정말 심각하게 받아들이고 있어요. 앤트로픽 팀은 모델 성능을 의도적으로 저하시키는 일은 절대 없으며, API와 추론(Inference) 계층은 영향을 받지 않았다는 것을 즉시 확인할 수 있었어요.

조사 결과, 팀은 세 가지 다른 문제를 확인했어요.

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

이것은 클로드 코드 사용자분들이 기대해야 할 경험이 아니죠. 4월 23일부로 모든 구독자분들의 사용 제한을 재설정했어요.

1. 기본 추론 노력 수준

지난 2월, 클로드 코드에 Opus 4.6을 출시했을 때, 팀은 추론(reasoning) 노력 수준 기본값을 high로 설정했었어요.

얼마 지나지 않아, 사용자들로부터 high 노력 모드에서 클로드 Opus 4.6이 가끔 너무 오랫동안 '생각'해서 UI가 멈춘 것처럼 보이고, 사용자들에게 불균형적인 레이턴시와 토큰 사용량을 유발한다는 피드백을 받았어요.

일반적으로 모델이 더 오래 생각할수록 더 좋은 결과물을 내놓는데요. '노력 수준(effort levels)'은 클로드 코드가 사용자들에게 이러한 트레이드오프, 즉 더 많은 생각과 더 낮은 레이턴시 및 적은 사용량 제한 도달 사이에서 선택할 수 있게 해주는 방법이에요. 앤트로픽 팀이 모델의 노력 수준을 조정할 때, 사용자분들이 최적의 선택지를 가질 수 있도록 테스트 시간-연산 곡선을 따라 여러 지점을 고려해요. 그리고 제품 계층에서는 이 곡선 상의 어느 지점을 기본값으로 설정할지 정하고, 이 값을 노력(effort) 파라미터로 메시지 API에 전송하죠. 그 후 다른 옵션들은 /effort를 통해 사용할 수 있도록 제공하고 있어요.

내부 평가(evals)와 테스트 결과, medium 노력 수준은 대부분의 작업에서 훨씬 적은 레이턴시로 약간의 지능 저하를 보였어요. 또한, 가끔 발생하는 아주 긴 '생각' 시간으로 인한 레이턴시 문제도 없었고, 사용자들의 사용량 제한을 최대한 활용하는 데도 도움이 되었죠. 그 결과, 팀은 medium을 기본 노력 수준으로 변경하는 업데이트를 배포하고, 제품 내 대화창을 통해 그 이유를 설명했어요.

배포 직후, 사용자들은 클로드 코드가 덜 똑똑해진 것 같다고 보고하기 시작했어요. 앤트로픽 팀은 현재 노력 설정값을 더 명확하게 표시해서 사용자들이 기본값을 변경할 수 있다는 것을 알리기 위해 여러 디자인 개선사항을 적용했죠(시작 알림, 인라인 노력 선택기, 그리고 울트라띵크 기능 부활 등). 하지만 대부분의 사용자는 medium 노력 기본값을 유지했어요.

더 많은 고객의 피드백을 들은 후, 앤트로픽 팀은 4월 7일에 이 결정을 되돌렸어요. 이제 모든 사용자는 Opus 4.7의 경우 xhigh 노력, 그리고 다른 모든 모델의 경우 high 노력 수준을 기본값으로 사용하게 돼요.

2. 클로드 에이전트 SDK의 프롬프트 캐싱 버그

클로드가 어떤 작업을 추론(reason)할 때, 그 추론 과정은 일반적으로 대화 기록에 보관되어요. 그래서 이후의 모든 차례에서 클로드가 왜 그런 편집을 하고 도구 호출을 했는지 알 수 있도록 말이죠.

3월 26일, 앤트로픽 팀은 이 기능의 효율성을 개선하기 위한 업데이트를 배포했어요. 프롬프트 캐싱을 사용해서 사용자들의 연속적인 API 호출을 더 저렴하고 빠르게 만들려고 했죠. 클로드는 API 요청을 할 때 입력 토큰을 캐시에 쓰고, 비활성 기간이 지나면 프롬프트가 캐시에서 제거되어 다른 프롬프트가 들어설 공간을 만들어요. 캐시 활용은 팀이 신중하게 관리하는 부분이에요 (앤트로픽 팀의 접근 방식에 대해 더 자세히 알아보세요).

원래 설계는 간단했어요: 세션이 한 시간 이상 유휴 상태였다면, 오래된 '생각' 부분을 지워서 해당 세션을 재개하는 사용자 비용을 줄일 수 있을 거라고 생각했죠. 어차피 요청이 캐시 미스가 될 테니, 요청에서 불필요한 메시지를 제거해서 API로 전송되는 캐시되지 않은 토큰 수를 줄일 수 있었을 거예요. 그리고 나서는 전체 추론 기록을 다시 보내는 식이었죠. 이를 위해 clear_thinking_20251015 API 헤더와 keep:1을 사용했어요.

하지만 구현에 버그가 있었어요. '생각' 기록을 한 번만 지워야 하는데, 세션의 남은 시간 동안 모든 차례에서 지워버린 거죠. 세션이 유휴 임계값을 한 번 넘어가면, 그 과정의 남은 시간 동안 모든 요청은 API에게 가장 최근의 추론 블록만 유지하고 그 이전의 모든 것을 버리라고 지시했어요. 이게 계속 쌓였는데, 만약 클로드가 도구 사용 중간에 후속 메시지를 보내면, 손상된 플래그 아래에서 새로운 차례가 시작되어 현재 차례의 추론까지도 삭제되었어요. 클로드는 계속 실행되긴 했지만, 자신이 왜 그런 행동을 선택했는지에 대한 기억이 점점 사라졌어요. 이게 바로 사람들이 보고했던 건망증, 반복적인 행동, 그리고 이상한 도구 선택으로 나타난 거죠.

이 버그 때문에 이후 요청에서 '생각' 블록이 계속 삭제되면서, 해당 요청들은 캐시 미스를 유발했어요. 앤트로픽 팀은 이것이 사용량 제한이 예상보다 빨리 소진된다는 별도의 보고를 유발한 원인이라고 생각하고 있어요.

서로 관련 없는 두 가지 실험 때문에 처음에는 이 문제를 재현하기가 어려웠어요. 하나는 메시지 큐잉과 관련된 내부 전용 서버 측 실험이었고, 다른 하나는 '생각' 표시 방식의 독립적인 변경이었는데, 이 변경이 대부분의 CLI 세션에서 이 버그를 억제해서 외부 빌드를 테스트할 때도 잡지 못했죠.

이 버그는 클로드 코드의 컨텍스트 관리, 앤트로픽 API, 그리고 확장된 '생각' 기능의 교차점에 있었어요. 이 버그를 유발한 변경사항은 여러 번의 수동 및 자동 코드 검토뿐만 아니라 유닛 테스트, 종단 간(end-to-end) 테스트, 자동 검증, 그리고 자체 사용(dogfooding) 단계를 통과했었죠. 특정 코너 케이스(오래된 세션)에서만 발생하고 재현하기 어려웠다는 점과 겹쳐져서, 근본 원인을 발견하고 확인하는 데 일주일 이상이 걸렸어요.

조사의 일환으로, 앤트로픽 팀은 Opus 4.7을 사용해 문제의 풀 리퀘스트에 대해 코드 리뷰 기능을 역으로 테스트했어요. 완전한 컨텍스트를 수집하는 데 필요한 코드 저장소를 제공했을 때, Opus 4.7은 버그를 찾아냈지만 Opus 4.6은 그러지 못했네요. 이런 일이 다시 발생하지 않도록, 이제 코드 리뷰를 위한 추가 저장소 컨텍스트 지원을 추가하고 있어요.

앤트로픽 팀은 이 버그를 4월 10일 v2.1.101에서 수정했어요.

3. 클로드 코워크의 장황함 튜닝

앤트로픽 팀의 최신 모델인 클로드 Opus 4.7은 이전 모델에 비해 눈에 띄는 행동 특성이 하나 있어요. 출시 당시 설명했듯이, 상당히 말이 많은 경향이 있죠. 이 덕분에 어려운 문제에서는 더 똑똑해지지만, 동시에 더 많은 출력 토큰을 생성하게 돼요.

Opus 4.7 출시 몇 주 전, 앤트로픽 팀은 클로드 코드에 대한 튜닝을 시작했어요. 각 모델은 미묘하게 다르게 작동하기 때문에, 팀은 각 출시 전에 하니스(harness)와 제품을 해당 모델에 최적화하는 데 시간을 투자하죠.

장황함을 줄이기 위한 여러 도구를 가지고 있어요: 모델 훈련, 프롬프트 엔지니어링, 그리고 제품 내 '생각' UX 개선 등이죠. 궁극적으로 이 모든 것을 사용했지만, 시스템 프롬프트에 추가된 한 가지가 클로드 코드의 지능에 예상보다 큰 영향을 미쳤어요:

“길이 제한: 도구 호출 사이의 텍스트는 25단어 이하로 유지하세요. 작업에 더 자세한 내용이 필요하지 않는 한, 최종 응답은 100단어 이하로 유지하세요.”

수 주간의 내부 테스트와 실행했던 평가 세트에서 회귀(regression)가 없음을 확인한 후, 앤트로픽 팀은 이 변경사항에 대해 확신을 가지고 4월 16일 Opus 4.7과 함께 배포했어요.

이번 조사의 일환으로, 앤트로픽 팀은 더 광범위한 평가 세트를 사용해서 더 많은 어블레이션(ablation, 시스템 프롬프트에서 각 줄의 영향을 이해하기 위해 줄을 제거하는 테스트)을 실행했어요. 이 평가 중 하나에서 Opus 4.6과 4.7 모두 3%의 성능 저하가 나타났네요. 앤트로픽 팀은 4월 20일 출시와 함께 즉시 해당 프롬프트를 되돌렸어요.

앞으로 어떻게 다르게 할까요?

앤트로픽 팀은 이러한 문제들을 피하기 위해 몇 가지를 다르게 할 예정이에요. 먼저, 더 많은 내부 직원이 새로운 기능을 테스트하는 버전 대신 클로드 코드의 정확히 공개된 빌드를 사용하도록 할 거고요. 그리고 내부적으로 사용하는 코드 리뷰 도구를 개선하고, 이 개선된 버전을 고객들에게 제공할 거예요.

또한, 시스템 프롬프트 변경에 대한 통제를 더욱 강화하고 있어요. 클로드 코드의 모든 시스템 프롬프트 변경에 대해 모델별로 광범위한 평가(evals) 스위트를 실행할 거고, 각 줄의 영향을 이해하기 위한 어블레이션 테스트도 계속할 거예요. 프롬프트 변경을 더 쉽게 검토하고 감사할 수 있도록 새로운 도구도 개발했죠. 추가적으로, 모델별 변경사항이 대상 모델에만 적용되도록 CLAUDE.md에 지침을 추가했어요. 지능에 영향을 미칠 수 있는 모든 변경사항에 대해서는 '적용 기간(soak period)', 더 광범위한 평가 스위트, 그리고 점진적 배포를 도입해서 문제를 더 일찍 포착할 수 있도록 할 거예요.

최근 앤트로픽 팀은 X에 @ClaudeDevs 계정을 만들어서 제품 결정과 그 배경에 대한 심층적인 설명을 공유할 공간을 마련했어요. 동일한 업데이트를 GitHub의 중앙 집중식 스레드에서도 공유할 예정이에요.

마지막으로, 사용자분들께 감사의 말씀을 전하고 싶어요. /feedback 명령을 사용해서 문제를 공유해주셨거나 (또는 온라인에 구체적이고 재현 가능한 사례를 올려주신 분들) 덕분에 앤트로픽 팀이 이러한 문제들을 파악하고 해결할 수 있었어요. 오늘 모든 구독자분들의 사용량 제한을 재설정했어요.

피드백과 인내심에 진심으로 감사드려요.

제품 업데이트, 사용 방법, 커뮤니티 소식 등 다양한 정보가 매월 당신의 받은편지함으로 찾아가요.