Anthropic 사후 분석: 2025년 8월부터 9월 초까지 클로드 응답 품질에 영향을 준 인프라 버그

2025년 8월부터 9월 초까지, 클로드의 응답 품질을 간헐적으로 저하시킨 세 가지 별개의 인프라 버그가 발생했습니다. 앤트로픽은 이후 이 문제들을 해결했으며, 모델 품질이 수요, 시간대 또는 서버 부하에 따라 의도적으로 낮춰지지 않는다는 점을 확인했습니다.

세 가지 겹치는 인프라 문제

앤트로픽은 시간이 겹치는 세 가지 별개의 버그를 확인했으며, 이로 인해 진단이 복잡해졌습니다. 8월 29일에 시행된 로드 밸런싱 변경으로 인해 영향을 받는 트래픽의 양이 증가하면서 문제는 악화되었습니다.

1. 컨텍스트 창 라우팅 오류

8월 5일에 도입된 라우팅 버그로 인해 일부 Sonnet 4 요청이 1M 토큰 컨텍스트 창을 위한 서버로 잘못 라우팅되었습니다.

영향: 처음에는 요청의 0.8%에 영향을 주었으나, 로드 밸런싱 변경 이후 8월 31일에 Sonnet 4 요청의 최대 16%까지 영향을 받았습니다. 이 기간 동안 약 30%의 클로드 코드 사용자가 적어도 한 번 이상 잘못 라우팅된 메시지를 경험했습니다. 아마존 베드록의 영향은 최대 0.18%에 달했고, 구글 클라우드의 Vertex AI는 요청의 0.0004% 미만에 영향을 받았습니다.
지속성: "스티키" 라우팅의 특성상, 한 번 잘못 라우팅된 사용자는 후속 메시지도 동일한 잘못된 서버로 라우팅될 가능성이 높았습니다.
해결: 9월 4일까지 라우팅 로직이 수정되었으며, 1차 플랫폼 전체에 완전히 배포되었고, Vertex AI(9월 16일), AWS 베드록(9월 18일)에도 완료되었습니다.

2. 출력 손상

8월 25일에 클로드 API TPU 서버에 배포된 잘못된 구성으로 인해 런타임 성능 최적화 과정에서 토큰 생성 오류가 발생했습니다.

영향: 이 버그는 거의 생성되지 않을 토큰에 높은 확률을 할당하여, 예기치 않은 문자(예: 영문 프롬프트에 타이 문자 또는 중국어 문자가 포함됨) 또는 코드에서 구문 오류를 유발했습니다. 8월 25일부터 9월 초까지 클로드 API에서 Opus 4.1, Opus 4, Sonnet 4 요청에 영향을 주었으며, 제3자 플랫폼은 영향을 받지 않았습니다.
해결: 9월 2일에 변경 사항이 롤백되었으며, 예기치 않은 문자 출력을 탐지하기 위한 검사 테스트가 배포 프로세스에 추가되었습니다.

3. 근사 top-k XLA:TPU 컴파일 오류

8월 25일에 배포된 코드는 토큰 선택을 개선하려는 목적을 가졌으나, XLA:TPU 컴파일러 내 잠재적 버그를 유발했습니다.

영향: 이 버그는 클로드 하이쿠 3.5 및 일부 Sonnet 4, Opus 3 요청에 영향을 주었으며, 클로드 API에서 발생했습니다. 제3자 플랫폼은 영향을 받지 않았습니다.
해결: 하이쿠 3.5는 9월 4일, 오퍼스 3은 9월 12일에 버그가 롤백되었습니다. 사전 조치로 Sonnet 4도 롤백되었습니다.

기술적 심층 분석: XLA 컴파일러 버그

XLA 컴파일러 버그는 텍스트 생성 중 가장 높은 확률을 가진 토큰을 찾는 데 사용되는 성능 최적화인 "근사 top-k" 연산의 실패를 포함합니다.

정밀도 불일치와 토큰 손실

클로드 모델은 bf16(16비트 부동소수점)에서 확률을 계산하지만, TPU 벡터 프로세서는 fp32 기반입니다. XLA 컴파일러는 xla_allow_excess_precision 플래그를 통해 일부 연산을 fp32(32비트)로 변환하여 런타임 성능을 최적화합니다. 이로 인해 다양한 연산 간에 정밀도 불일치가 발생하여, 높은 확률을 가진 토큰에 대해 서로 다른 판단을 내리게 되었고, 온도가 0일 때 가장 확률이 높은 토큰이 완전히 제거되는 경우가 있었습니다.

근사 top-k의 실패

2025년 8월, 샘플링 코드가 재작성되면서 2024년 12월에 도입된 임시 조치가 제거되었습니다. 이로 인해 기존 컴파일러 버그를 가리던 가림막이 제거되었고, approximate top-k 연산이 특정 배치 크기와 모델 구성에서 완전히 잘못된 결과를 반환하는 문제가 노출되었습니다. 이 버그의 동작은 일관되지 않았으며, 이전 연산이나 활성화된 디버깅 도구와 같은 관련 없는 요인에 따라 달라졌기 때문에 재현이 어려웠습니다.

최종 해결

앤트로픽은 근사 top-k에서 정확한 top-k로 전환하고, 추가 연산을 fp32 정밀도로 표준화했습니다. 모델 품질을 보장하기 위해 약간의 효율성 저하를 감수했습니다.

탐지 및 복구의 어려움

이 버그들이 지연되어 탐지된 이유는 다음과 같은 여러 요인이 복합적으로 작용했기 때문입니다:

평가 갭: 표준 벤치마크와 안전성 평가에서는 클로드가 고립된 실수를 자주 회복하기 때문에 품질 저하를 포착하지 못했습니다.
개인정보 제약: 내부 보안 제어로 엔지니어는 사용자 상호작용에 대한 접근이 제한되어 실제 문제 상호작용을 사용해 버그를 재현할 수 없습니다.
잡음 있는 신호: 버그들이 겹치고 플랫폼 간 영향이 달라져, 무작위 품질 저하처럼 보이는 혼란스러운 보고서가 발생했습니다.
평가에 과도하게 의존: 8월 29일에 부정적인 보고가 급증했지만, 이는 일반적인 로드 밸런싱 변경과 연결되지 않았습니다.

향후 예방 조치

앤트로픽은 유사한 인프라 실패를 방지하기 위해 다음과 같은 조치를 시행하고 있습니다:

더 민감한 평가 도구 개발: 작동 중인 구현과 고장난 구현을 더 신뢰성 있게 구분할 수 있는 새로운 평가 도구 개발
지속적인 프로덕션 모니터링: 실시간 프로덕션 시스템에서 품질 평가를 지속적으로 수행하여 컨텍스트 창 라우팅 버그와 같은 오류를 조기에 탐지
강화된 디버깅 도구 개발: 사용자 개인정보를 훼손하지 않으면서 커뮤니티에서 제출된 피드백을 더 효율적으로 디버깅할 수 있는 인프라 구축