Originally published at trustboundarystudio.com. The video version, with diagrams, is on YouTube.
주요 사실
- 시기: Anthropic이 2025년 9월 17일에 발표한 사후 분석 보고서에 따르면, 2025년 8월부터 9월 초 사이였습니다. 첫 번째 버그는 8월 5일에 발생했으며, 나머지 두 가지는 8월 25일과 26일 배포 과정에서 생겨났습니다.
- 최대 피해: 가장 심각한 영향을 미친 시간인 2025년 8월 31일에는 Sonnet 4 요청의 16%가 영향을 받았습니다. 이는 8월 29일에 정기적인 부하 분산(load balancing) 변경이 더 많은 짧은 컨텍스트(short-context) 요청을 1M 토큰 컨텍스트 창으로 설정된 서버로 보내면서 발생했습니다.
- Claude Code: 해당 기간 동안 요청을 보낸 Claude Code 사용자 중 약 30%가 적어도 하나의 메시지를 잘못된 유형의 서버로 라우팅되는 영향을 받았습니다. 이는 총 요청 건수의 비율이 아니라, 최소한 한 번이라도 문제가 있는 메시지를 받은 사용자의 비율입니다.
- 다른 플랫폼: Amazon Bedrock에서는 오라우팅 트래픽(misrouted traffic)이 모든 Sonnet 4 요청의 0.18%로 정점을 찍었으며; Google Cloud의 Vertex AI에서는 8월 27일부터 9월 16일 사이에 요청의 0.0004% 미만을 영향을 받았습니다. 나머지 두 가지 버그는 타사 플랫폼에는 영향을 주지 않았습니다.
- 감지: Anthropic의 말에 따르면, 자체적으로 실행한 평가(evaluations)로는 사용자들이 보고하는 성능 저하를 포착하지 못했으며, 개인 정보 보호 제어(privacy controls)가 엔지니어들이 해당 대화 기록에 접근하는 것을 제한했습니다.
- 주요 출처: Anthropic의
그들이 옳았다. 8월부터 9월 초까지 세 가지 별개의 인프라 버그로 인해 Claude의 응답 품질이 저하되었다. 아무것도 다운된 것이 아니었고, 공격받은 것도 아니었다. 최악의 순간인 8월 31일에는 Sonnet 4 요청 중 16%가 영향을 받았으며, 바로 이런 상황을 감지하도록 설계된 검사 시스템조차 통과했다.
Anthropic이 자체적으로 발표한 사후 분석 보고서(post-mortem)는 2025년 9월 17일자이며, 거의 전적으로 라우팅(routing), 서버 설정 오류(server misconfiguration), 그리고 컴파일러에 관한 내용이다. 이는 서비스가 '작동하고 있다(up)'는 것과 서비스가 '올바르게 작동한다(right)'는 것 사이의 차이를 보여주는 깔끔한 예시이다.
Claude를 제공하는 방식 (How Claude is served)
Anthropic은 자체 API, Amazon Bedrock, 그리고 Google Cloud의 Vertex AI를 통해 세 가지 종류의 하드웨어(AWS Trainium, NVIDIA GPU, Google TPU)에서 Claude를 서비스한다. 각각은 고유한 최적화가 필요하다. 사후 분석 보고서에 따르면 이 모든 환경에 적용되는 원칙은 다음과 같다: "이러한 변동성에도 불구하고, 모델 구현에는 엄격한 동등성 표준(strict equivalence standards)이 존재합니다."
따라서 플랜딩(plumbing)의 모든 변경 사항은 모든 곳에서 유지되어야 한다. 그러나 2025년 8월에 세 가지는 그렇지 못했다.
버그 1: 잘못된 서버로 전송된 요청들
8월 5일, 일부 Sonnet 4 요청이 "곧 출시될 1M 토큰 컨텍스트 창용으로 설정된 서버로 오라우팅(misrouted)되기 시작했다." 이는 Sonnet 4 요청의 약 0.8%에 영향을 미쳤으며, 이 정도는 노이즈처럼 보일 만큼 적은 수치였다.
그런 다음 8월 29일에는 "정기적인 로드 밸런싱 변경(routine load balancing change)이 의도치 않게 짧은 컨텍스트 요청을 1M 컨텍스트 서버로 라우팅되는 수를 증가시켰다." 가장 큰 영향을 받은 시간인 8월 31일에는 Sonnet 4 요청의 16%가 영향을 받았다.
이는 고르게 퍼지지 않았다. 라우팅은 '끈적한(sticky)' 특성을 가지고 있어서, "요청이 잘못된 서버에서 한 번 서비스되면, 후속 질문들 역시 같은 잘못된 서버에서 서비스될 가능성이 높았다." 일부 사용자들은 계속해서 품질이 저하된 답변을 받았다.
가장 오역되기 쉬운 수치는 다음과 같습니다. “이 기간 동안 요청을 보낸 Claude Code 사용자 중 약 30%가 잘못된 서버 유형으로 라우팅된 메시지를 하나 이상 받았고, 이로 인해 응답 품질이 저하되었습니다.” 이는 전체 요청의 30%를 의미하는 것이 아니라 사용자 점유율이며, 한 시간 동안 Sonnet 4 요청에서 나타난 16%와는 별개의 수치입니다. 사후 분석 보고서(post-mortem)에는 전체 총계가 제시되어 있지 않으며, 본 기사에도 그러한 내용이 없습니다.
Amazon Bedrock에서는 잘못 라우팅된 트래픽이 모든 Sonnet 4 요청의 0.18%를 기록했으며, Vertex AI에서는 8월 27일부터 9월 16일 사이에 발생한 요청 중 0.0004% 미만을 차지했습니다. 수정 사항은 9월 4일에 배포되었고, 사후 분석 보고서에 따르면 9월 18일까지 완전히 적용되었습니다.
버그 두 가지: 잘못된 토큰
두 번째 버그는 “Claude API TPU 서버의 오설정으로 인해 토큰 생성 과정에서 오류가 발생한 것”이었습니다. 모델은 답변을 한 번에 하나의 토큰씩 작성하며, 런타임 성능 최적화(runtime performance optimisation) 기능이 “문맥상 거의 생성되어서는 안 될 토큰에 때때로 높은 확률을 할당했습니다.”
그 결과 영어 프롬프트에 대해 태국어 또는 중국어 문자가 답변으로 나오거나 코드에서 명백한 구문 오류가 발생했습니다. 이 문제는 Opus 4.1과 Opus 4를 8월 25일부터 28일까지, 그리고 Sonnet 4는 변경 사항이 되돌려진 9월 2일까지 영향을 미쳤습니다. “제3자 플랫폼은 이 문제의 영향을 받지 않았습니다.” Anthropic은 이후 배포 프로세스에 “예상치 못한 문자 출력에 대한 감지 테스트를 추가했습니다.”
버그 세 가지: 컴파일러
모델은 다음 토큰을 선택하기 위해 후보들을 확률별로 순위를 매기며, 근사적 top-k(approximate top-k)를 사용하는 TPU에서는 더 빠른 단축 경로를 이용합니다.
Anthropic은 2024년 12월에 “온도가 0일 때 TPU 구현이 가장 확률 높은 토큰을 가끔 누락시키는 것”을 발견하고 임시 해결책(workaround)을 배포했습니다. 그리고 8월에는 Claude가 토큰을 선택하는 방식을 개선하기 위한 코드를 배포했습니다. 사후 분석 보고서의 표현에 따르면, “우리는 근본 원인을 해결했다고 믿었기 때문에 12월의 임시 해결책을 제거했습니다.”
변경 사항이 XLA:TPU 컴파일러의 잠재적 버그를 의도치 않게 유발했습니다. 근사화 과정은 '때로는 완전히 잘못된 결과를 반환했지만, 특정 배치 크기와 모델 구성에서만 발생했습니다.' 또한 '12월에 적용했던 임시 해결책이 이 문제를 우연히 가리고 있었습니다.' 그리고 '동일한 프롬프트가 한 요청에서는 완벽하게 작동할 수 있지만 다음 요청에서는 실패할 수도 있습니다.'
이는 Haiku 3.5에서 확인되었으며, 9월 4일에 되돌려졌습니다. Anthropic은 이 문제가 'Claude API의 Sonnet 4와 Opus 3 일부에 영향을 미쳤을 수 있다'고 믿습니다. Opus 3는 사용자들이 '이 버그와 호환된다'는 보고가 있은 후 9월 12일에 되돌려졌습니다. Sonnet 4의 경우, Anthropic의 말에 따르면 'Sonnet 4에서 이 버그를 재현할 수는 없었지만, 만일의 사태에 대비하여 제거하기로 결정했습니다.' 서드파티 플랫폼은 영향을 받지 않았습니다.
해결책은 단축 경로인 정확한 top-k와 일부 추가 연산을 fp32 표준으로 낮추는 것이었습니다. '모델 품질은 협상의 여지가 없었기 때문에, 우리는 사소한 효율성 저하를 감수했습니다.'
왜 몇 주가 걸렸는지
Anthropic은 네 가지 이유를 제시합니다.
검사 시스템이 통과함. '저희의 검증 프로세스는 일반적으로 벤치마크와 안전 평가, 성능 지표에 의존합니다. 엔지니어링 팀은 간헐적인 점검을 수행하고 먼저 소규모 '카나리' 그룹에 배포합니다.' 그리고 이러한 평가는 '사용자들이 보고하는 저하를 포착하지 못했는데, 이는 Claude가 고립된 실수로부터 종종 잘 복구되기 때문이기도 합니다.'
증상이 중첩됨. '각 버그는 서로 다른 플랫폼에서 다른 속도로 다른 증상을 만들어냈습니다.' 종합적으로 볼 때, '무작위적이고 일관성 없는 저하처럼 보였습니다.'
타이밍이 원인을 숨김. '8월 29일에 부정적인 보고가 급증했을 때, 우리는 이것을 그저 표준 부하 분산 변경과 연결하지 못했습니다.'
문은 닫혔다. 'Claude와의 사용자 상호작용에 대한 엔지니어의 접근은 우리의 내부 개인정보 보호 및 보안 통제에 의해 제한됩니다. 특히 그러한 상호작용이 피드백으로 저희에게 보고되지 않은 경우에는 더욱 그렇습니다. 이는 사용자 프라이버시를 보호하지만, 버그를 식별하거나 재현하는 데 필요한 문제적인 상호작용을 엔지니어가 검토하는 것을 방해합니다.'
그러한 통제는 당연히 필요합니다. 또한 증거를 가진 사람들이 바로 사용자였으며, Anthropic은 그들의 보고가 '문제를 격리하는 데 모두 도움이 되었다'고 말합니다.
명확한 진술
사후 분석(post-mortem)은 이 내용으로 시작합니다:
'간단히 말씀드리자면: 우리는 수요, 시간대 또는 서버 부하 때문에 모델 품질을 저하시키지 않습니다. 사용자들이 보고한 문제들은 오직 인프라 버그 때문이었습니다.'
이것이 Anthropic의 진술이며, 이 문서는 그들이 제시하는 증거입니다. 읽고 판단하고 싶은 분들을 위해 아래에 링크되어 있습니다.
Anthropic이 바꾼 것들
사후 분석 자체의 소제목 아래 세 가지 약속이 있었습니다. 더 민감한 평가(More sensitive evaluations): 작동하는 구현체와 고장 난 것을 구별할 수 있게 되었습니다. 더 많은 장소에서의 품질 평가: '실제 프로덕션 시스템에서 지속적으로 실행할 것입니다.' 더 빠른 디버깅 도구링(Faster debugging tooling): '사용자 프라이버시를 희생하지 않으면서 커뮤니티가 제공한 피드백을 더 잘 디버그하기 위함입니다.'
또한 사용자들에게 Claude Code의 /bug 명령이나 앱의 엄지손가락 아래 표시(thumbs down)를 통해 계속 보고해 줄 것을 요청했습니다.
인프라 팀을 위한 네 가지 교훈
상승은 옳지 않다. 이 버그들 각각이 서비스를 실행 상태로 남겨두었습니다. 만약 모니터링 시스템이 답변의 '정확성'이 아니라 시스템이 '답변하는지 여부'만을 측정한다면, 품질 실패는 그에게 보이지 않습니다.
작은 변화들이 쌓인다. 일상적인 부하 분산(load balancing) 변경이 Sonnet 4 요청 중 약 0.8%에 영향을 주던 버그를 최악의 한 시간 동안에는 16%에 영향을 주는 것으로 만들었습니다. 새로운 변경 사항을 깨끗하다고 부르기 전에, 무엇이 이미 고장 나고 있었는지 알아내야 합니다.
우회책은 무언가를 숨긴다. 하나를 제거하는 것은 그것이 조용히 가리고 있던 모든 것을 드러낼 수 있다. 그 제거 자체를 하나의 변화로 간주해야 한다.
검사할 수 없는 실패에 대해 사전에 어떻게 조사할지 결정하라. 개인정보 보호 문은 유지되어야 한다. 동의와 도구를 통해 통과하는 방법은 필요하게 되는 날 이전에 존재해야만 한다.
출처 (Sources)
수정 사항은 환영하며, 수정된 내용은 이 기사 끝에 목록으로 기재된다.
비디오 버전 (The video version)
답변하는 질문들 (Questions this answers)
2025년 8월에 Claude의 응답 품질이 떨어진 이유는 무엇인가?
Anthropic은 이를 세 가지 인프라 버그 때문이라고 설명한다: 일부 Sonnet 4 요청이 1M 토큰 컨텍스트 창으로 설정된 서버로 라우팅되었고, Claude API의 TPU 서버에 구성 오류가 있어 출력이 손상되었으며, Claude가 토큰을 선택하는 방식 변경으로 인해 촉발된 XLA:TPU 컴파일러의 잠재적 버그이다.
Anthropic이 비용 절감을 위해 Claude의 품질을 낮췄는가?
Anthropic의 사후 분석에 따르면 다음과 같다:
사후 분석에 따르면, 평가 시스템이 사용자들이 보고한 성능 저하를 포착하지 못했습니다. 각 버그는 서로 다른 플랫폼에서 다른 증상을 보였고, 발생률도 달랐습니다. 8월 29일 급증 현상은 표준 로드 밸런싱 변경과 즉각적으로 연결되지 않았으며, 개인 정보 보호 제어(privacy controls)가 엔지니어들의 영향을 받은 대화 내용 접근을 제한했습니다.
Claude는 Amazon Bedrock 또는 Google Vertex AI 중 어느 쪽이 영향을 받았나요?
라우팅 버그에 의해서만 영향받았고, 그 규모도 훨씬 작았습니다. Bedrock에서 Sonnet 4 요청 전체의 0.18%가 잘못 라우팅된 트래픽으로 최고치를 기록했으며, 8월 27일부터 9월 16일 사이 Vertex AI에서는 요청의 0.0004% 미만을 영향받았습니다. 나머지 두 버그는 타사 플랫폼에는 영향을 주지 않았습니다.