Anthropic: 세 가지 최근 이슈의 사후 분석

https://www.anthropic.com/engineering/a-postmortem-of-three-recent-issues

기술적으로, 이 보고서는 Claude의 응답 품질을 간헐적으로 저하시킨 세 가지 버그에 관한 것입니다. 아래에서는 어떤 일이 있었는지, 왜 해결에 시간이 걸렸는지, 그리고 우리가 무엇을 바꾸고 있는지 설명합니다.

8월부터 9월 초까지, 세 가지 인프라 버그로 인해 Claude의 응답 품질이 간헐적으로 저하되었습니다. 현재는 이 문제들을 모두 해결했으며, 어떤 일이 있었는지 설명하고자 합니다.

8월 초, 여러 사용자들이 Claude의 응답 품질 저하를 보고하기 시작했습니다. 이러한 초기 보고는 평소 사용자 피드백의 변동과 구분하기 어려웠습니다. 8월 말에는 보고 빈도와 지속성이 증가하여, 조사를 시작했고 세 가지 별도의 인프라 버그를 발견하게 되었습니다.

명확히 말씀드리면: 우리는 수요, 시간대, 서버 부하로 인해 모델 품질을 낮추지 않습니다. 사용자들이 보고한 문제는 오직 인프라 버그 때문이었습니다.

사용자들은 Claude로부터 일관된 품질을 기대하며, 우리는 인프라 변경이 모델 출력에 영향을 주지 않도록 매우 높은 기준을 유지합니다. 최근 사건에서는 이 기준을 충족하지 못했습니다. 아래의 포스트모템에서는 무엇이 잘못되었는지, 탐지와 해결이 왜 예상보다 오래 걸렸는지, 그리고 앞으로 유사한 사고를 방지하기 위해 무엇을 바꾸고 있는지 설명합니다.

평소에는 인프라에 대해 이 정도의 기술적 세부사항을 공유하지 않지만, 이번 문제의 범위와 복잡성이 더 포괄적인 설명을 정당화했습니다.

Claude를 대규모로 서비스하는 방법

우리는 Claude를 수백만 명의 사용자에게 자사 API, Amazon Bedrock, Google Cloud의 Vertex AI를 통해 제공합니다. Claude는 AWS Trainium, NVIDIA GPU, Google TPU 등 여러 하드웨어 플랫폼에 배포됩니다. 이러한 방식은 전 세계 사용자에게 서비스를 제공할 수 있는 용량과 지리적 분산을 보장합니다.

각 하드웨어 플랫폼은 특성이 다르며, 별도의 최적화가 필요합니다. 이러한 차이에도 불구하고, 우리는 모델 구현에 대해 엄격한 동등성 기준을 적용합니다. 사용자는 어떤 플랫폼에서 요청을 처리하든 동일한 품질의 응답을 받아야 합니다. 이 복잡성 때문에, 모든 인프라 변경은 모든 플랫폼과 구성에서 신중한 검증이 필요합니다.

사건의 타임라인

Claude API에서의 사건 타임라인 예시. 노란색: 문제 감지, 빨간색: 품질 저하 심화, 초록색: 수정 배포.

이 버그들이 겹쳐 발생해 진단이 특히 어려웠습니다. 첫 번째 버그는 8월 5일에 발생해 Sonnet 4 요청의 약 0.8%에 영향을 미쳤습니다. 이후 8월 25일과 26일에 두 개의 추가 버그가 배포되었습니다.

초기 영향은 제한적이었으나, 8월 29일의 로드 밸런싱 변경으로 인해 영향을 받는 트래픽이 증가했습니다. 이로 인해 더 많은 사용자가 문제를 경험했고, 다른 사용자들은 정상적인 성능을 보였습니다. 이로 인해 혼란스럽고 상반된 보고가 이어졌습니다.

세 가지 겹친 문제

아래에서는 품질 저하를 일으킨 세 가지 버그와 발생 시점, 해결 방법을 설명합니다:

1. 컨텍스트 윈도우 라우팅 오류

8월 5일, 일부 Sonnet 4 요청이 예정된 1M 토큰 컨텍스트 윈도우 로 설정된 서버로 잘못 라우팅되었습니다. 이 버그는 처음에 요청의 0.8%에 영향을 미쳤습니다. 8월 29일, 정기적인 로드 밸런싱 변경으로 인해 짧은 컨텍스트 요청이 1M 컨텍스트 서버로 더 많이 라우팅되었습니다. 8월 31일 가장 영향이 컸던 시간에는 Sonnet 4 요청의 16%가 영향을 받았습니다.

이 기간 동안 Claude Code 사용자 중 약 30%가 적어도 한 번 이상 잘못된 서버 유형으로 메시지가 라우팅되어 응답 품질이 저하되었습니다. Amazon Bedrock에서는 8월 12일 Sonnet 4 요청의 0.18%가 잘못 라우팅되었습니다. Google Cloud의 Vertex AI에서는 8월 27일부터 9월 16일까지 요청의 0.0004% 미만이 잘못 라우팅되었습니다.

라우팅이 “스티키”하게 동작하기 때문에, 한 번 잘못된 서버에서 응답을 받으면 이후 요청도 같은 잘못된 서버로 처리될 가능성이 높았습니다.

해결: 라우팅 로직을 수정해 짧은/긴 컨텍스트 요청이 올바른 서버 풀로 전달되도록 했습니다. 9월 4일에 수정 배포를 완료했고, 자사 플랫폼과 Google Cloud Vertex에는 9월 16일까지 롤아웃을 완료했습니다. Bedrock에는 현재 롤아웃 중입니다.

2. 출력 손상

8월 25일, Claude API TPU 서버에 잘못된 설정이 배포되어 토큰 생성 중 오류가 발생했습니다. 런타임 성능 최적화로 인해, 컨텍스트상 거의 생성되지 않아야 할 토큰에 높은 확률이 할당되는 문제가 발생했습니다. 예를 들어, 영어 질문에 대해 태국어나 중국어 문자가 응답 중간에 나타나거나, 코드에 명백한 문법 오류가 포함되는 경우가 있었습니다. 일부 영어 질문을 한 사용자는 응답 중간에 “สวัสดี”와 같은 문자를 볼 수 있었습니다.

이 손상은 8월 2528일 Opus 4.1 및 Opus 4 요청, 8월 259월 2일 Sonnet 4 요청에 영향을 미쳤습니다. 서드파티 플랫폼은 영향을 받지 않았습니다.

해결: 문제를 확인하고 9월 2일에 변경 사항을 롤백했습니다. 배포 과정에 예기치 않은 문자 출력 감지 테스트를 추가했습니다.

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

8월 25일, Claude가 텍스트 생성 중 토큰을 선택하는 방식을 개선하는 코드를 배포했습니다. 이 변경으로 인해 XLA:TPU¹ 컴파일러의 잠재적 버그가 발생했고, Claude Haiku 3.5 요청에 영향을 미쳤음이 확인되었습니다.

Sonnet 4와 Opus 3의 일부 요청에도 영향을 미쳤을 것으로 추정됩니다. 서드파티 플랫폼은 영향을 받지 않았습니다.

해결: Haiku 3.5에서 버그가 확인되어 9월 4일에 롤백했습니다. 이후 Opus 3에서 유사한 문제 보고가 있어 9월 12일에 롤백했습니다. Sonnet 4에서는 재현되지 않았으나, 안전을 위해 롤백했습니다.

동시에 (a) XLA:TPU 팀과 컴파일러 버그 수정 작업을 진행 중이고, (b) 향상된 정밀도의 정확한 top-k를 사용하도록 수정했습니다. 자세한 내용은 아래 심층 설명을 참고하세요.

XLA 컴파일러 버그 자세히 보기

문제의 복잡성을 설명하기 위해, XLA 컴파일러 버그가 어떻게 나타났고 진단이 왜 어려웠는지 설명합니다.

Claude가 텍스트를 생성할 때, 가능한 다음 단어 각각의 확률을 계산한 뒤, 이 확률 분포에서 무작위로 샘플을 선택합니다. 우리는 “top-p 샘플링”을 사용해 말이 안 되는 출력을 방지합니다—누적 확률이 임계값(보통 0.99 또는 0.999)에 도달하는 단어만 고려합니다. TPU에서는 모델이 여러 칩에 걸쳐 실행되며, 확률 계산이 서로 다른 위치에서 이루어집니다. 이 확률을 정렬하려면 칩 간 데이터 조율이 필요하며, 이는 복잡합니다.²

2024년 12월, TPU 구현에서 temperature가 0일 때 가장 높은 확률의 토큰이 가끔 누락되는 현상을 발견했습니다. 이 경우를 해결하기 위해 우회 패치를 배포했습니다.

temperature = 0일 때 예기치 않게 토큰이 누락되는 버그를 우회하는 2024년 12월 패치 코드 스니펫.

근본 원인은 혼합 정밀도 산술에 있었습니다. 모델은 다음 토큰 확률을 bf16 (16비트 부동소수점)으로 계산합니다. 하지만 벡터 프로세서는 fp32-native이므로, TPU 컴파일러(XLA)는 일부 연산을 fp32(32비트)로 변환해 런타임을 최적화할 수 있습니다. 이 최적화는 기본값이 true인 ⁠xla_allow_excess_precision⁠ 플래그로 제어됩니다.

이로 인해 불일치가 발생했습니다: 가장 높은 확률의 토큰을 결정해야 하는 연산들이 서로 다른 정밀도로 실행되어, 어떤 토큰이 가장 높은 확률인지 일치하지 않았습니다. 이로 인해 가장 높은 확률의 토큰이 아예 고려 대상에서 사라지는 경우가 있었습니다.

8월 26일, 정밀도 문제를 해결하고 top-p 임계값에 도달하는 확률 처리 방식을 개선하는 샘플링 코드 재작성본을 배포했습니다. 하지만 이 과정에서 더 까다로운 문제가 드러났습니다.

August 11일 변경의 일부로 병합된 최소 재현 코드 스니펫으로, 2024년 12월에 우회 처리했던 “버그”의 근본 원인이 된 부분을 보여줍니다. 실제로는, 이는 xla_allow_excess_precision 플래그의 예상된 동작입니다.

2024년 12월 우회 패치의 근본 원인을 해결했다고 판단해 우회 코드를 제거했으나, 근사 top-k 연산에서 더 깊은 버그가 발생했습니다—성능 최적화를 위해 가장 높은 확률의 토큰을 빠르게 찾는 연산입니다.³ 이 근사 연산은 특정 배치 크기와 모델 구성에서 완전히 잘못된 결과를 반환하기도 했습니다. 12월 우회 패치가 이 문제를 가리고 있었던 셈입니다.

알고리즘을 개발한 XLA:TPU 엔지니어에게 공유한 근본적인 근사 top-k 버그 재현 코드. CPU에서는 올바른 결과를 반환합니다.

이 버그의 동작은 매우 불규칙했습니다. 이전/이후에 어떤 연산이 실행되는지, 디버깅 도구가 활성화되어 있는지 등과 같은 무관한 요인에 따라 달라졌습니다. 동일한 프롬프트가 한 번은 완벽하게 동작하고, 다음 요청에서는 실패할 수 있었습니다.

조사 과정에서, 정확한 top-k 연산이 더 이상 성능상 큰 페널티가 없다는 사실도 발견했습니다. 근사 top-k에서 정확한 top-k로 전환하고, 추가 연산을 fp32 정밀도로 표준화했습니다.⁴ 모델 품질은 타협할 수 없으므로, 약간의 효율성 저하를 감수했습니다.

탐지가 어려웠던 이유

평소에는 벤치마크, 안전 평가, 성능 지표를 활용해 검증합니다. 엔지니어링 팀은 스팟 체크를 하고, 소규모 “카나리아” 그룹에 먼저 배포합니다.

이번 문제들은 우리가 더 일찍 발견했어야 할 중요한 검증의 빈틈을 드러냈습니다. 우리가 실행한 평가가 사용자들이 보고한 품질 저하를 포착하지 못했는데, Claude가 개별 실수에서 잘 회복하는 특성 때문이기도 합니다. 또한, 내부 프라이버시 정책으로 인해 엔지니어가 Claude와의 사용자 상호작용을 조사할 수 있는 권한이 제한되어, 문제를 식별하거나 재현하는 데 어려움이 있었습니다.

각 버그는 플랫폼마다, 발생률마다 증상이 달라 혼란스러운 보고가 이어졌고, 단일 원인을 가리키지 않았습니다. 무작위적이고 일관성 없는 품질 저하처럼 보였습니다.

더 근본적으로, 우리는 노이즈가 많은 평가에 지나치게 의존했습니다. 온라인에서 부정적 보고가 증가한 것은 인지했지만, 최근 변경 사항과 명확히 연결할 방법이 부족했습니다. 8월 29일 부정적 보고가 급증했을 때도, 평범한 로드 밸런싱 변경과 즉시 연결하지 못했습니다.

앞으로의 변화

인프라를 개선하는 동시에, Claude를 서비스하는 모든 플랫폼에서 위와 같은 버그를 평가·방지하는 방식을 개선하고 있습니다. 주요 변화는 다음과 같습니다:

• 더 민감한 평가: 문제의 근본 원인을 더 잘 발견할 수 있도록, 정상/비정상 구현을 더 확실히 구분하는 평가를 개발했습니다. 앞으로도 평가 방식을 계속 개선해 모델 품질을 더 면밀히 모니터링할 예정입니다.
• 더 많은 곳에서 품질 평가: 기존에도 정기적으로 평가를 실행했지만, 앞으로는 실제 프로덕션 시스템에서 지속적으로 평가를 실행해 컨텍스트 윈도우 로드 밸런싱 오류와 같은 문제를 잡아낼 것입니다.
• 더 빠른 디버깅 도구: 사용자 커뮤니티 피드백을 더 잘 디버깅할 수 있는 인프라와 도구를 개발할 예정입니다. 사용자 프라이버시를 해치지 않으면서, 향후 유사 사고 발생 시 복구 시간을 줄일 수 있는 맞춤형 도구도 도입할 계획입니다.

평가와 모니터링은 중요합니다. 하지만 이번 사건은 Claude의 응답이 평소와 다를 때, 사용자로부터 지속적인 신호가 필요하다는 점도 보여줬습니다. 구체적인 변화, 예기치 않은 행동 사례, 다양한 사용 사례에서의 패턴 보고가 문제를 격리하는 데 큰 도움이 되었습니다.

사용자 여러분의 직접적인 피드백은 앞으로도 매우 중요합니다. Claude Code에서는 ⁠/bug⁠ 명령어를, Claude 앱에서는 “엄지손가락 아래” 버튼을 통해 피드백을 보낼 수 있습니다. 개발자와 연구자들은 내부 테스트를 보완하는 새로운 모델 품질 평가 방법을 자주 개발합니다. 본인의 평가 방법을 공유하고 싶다면 feedback@anthropic.com으로 연락해 주세요.