IL-0022 Anthropic · 2025-08-05ai-infra
Anthropic 은 2025년 8월부터 9월 초까지 인프라 버그 세 개 때문에 Claude 의 응답 품질이 간헐적으로 떨어졌다고 밝혔다. Claude 는 자사 API, Amazon Bedrock, Google Cloud Vertex AI 로 제공되며 AWS Trainium, NVIDIA GPU, Google TPU 에서 돈다. 세 버그는 시기가 겹쳤고 플랫폼마다 다른 증상을 냈다.
첫째는 컨텍스트 윈도우 라우팅 오류였다. 8월 5일부터 Sonnet 4 요청 일부가 곧 내놓을 1M 토큰 컨텍스트 윈도우용으로 설정된 서버로 잘못 보내졌다. 처음 영향은 요청의 0.8% 였지만, 8월 29일 평범한 로드 밸런싱 변경으로 짧은 컨텍스트 요청이 그 서버로 더 많이 갔다. 8월 31일 최악의 한 시간에는 Sonnet 4 요청의 16% 가 영향을 받았다. Amazon Bedrock 에서는 8월 12일부터 잘못 라우팅된 트래픽이 전체 Sonnet 4 요청의 최대 0.18% 였고, Vertex AI 에서는 8월 27일부터 9월 16일까지 요청의 0.0004% 미만이었다. 라우팅 로직 수정은 9월 4일 배포했고, 자사 플랫폼과 Vertex AI 는 9월 16일, Bedrock 은 9월 18일에 적용을 마쳤다.
둘째는 출력 손상이었다. 8월 25일 Claude API 의 TPU 서버에 잘못된 설정이 배포됐고, 런타임 성능 최적화 때문에 토큰 생성 중 오류가 났다. 맥락상 거의 나오지 않아야 할 토큰이 가끔 높은 확률을 받아, 영어 질문에 태국어나 중국어 글자가 섞이거나 코드에 뻔한 문법 오류가 생겼다. Opus 4.1 과 Opus 4 는 8월 25일부터 28일까지, Sonnet 4 는 8월 25일부터 9월 2일까지 영향을 받았고, 외부 플랫폼은 영향이 없었다. 9월 2일 이 변경을 롤백했다.
셋째는 XLA:TPU 컴파일러가 근사 top-k 연산을 잘못 컴파일한 문제였다. 근사 top-k 는 확률이 가장 높은 토큰을 빨리 찾는 성능 최적화 연산이다. 2024년 12월 Anthropic 은 TPU 구현이 temperature 가 0 일 때 가장 확률이 높은 토큰을 가끔 빠뜨리는 것을 발견하고 우회 코드를 넣었다. 원인은 혼합 정밀도였다. 모델은 다음 토큰 확률을 bf16 으로 계산하지만, XLA 는 기본값이 true 인 xla_allow_excess_precision 플래그 때문에 일부 연산을 fp32 로 바꿔 돌렸다. 그래서 정밀도가 다른 연산들이 어느 토큰의 확률이 가장 높은지 서로 다르게 판단했다.
8월 25일과 26일 Anthropic 은 이 정밀도 문제를 고치려고 샘플링 코드를 다시 써서 배포했고, 근본 원인을 해결했다고 믿어 12월의 우회 코드를 지웠다. 그 우회 코드가 근사 top-k 의 더 깊은 버그를 가리고 있었다. 근사 top-k 는 특정 배치 크기와 모델 설정에서 완전히 틀린 결과를 냈다. Haiku 3.5 에서 영향이 확인됐고, Claude API 의 Sonnet 4 와 Opus 3 일부도 영향을 받았을 수 있었다. Haiku 3.5 는 9월 4일, Opus 3 는 9월 12일에 롤백했고, 재현되지 않은 Sonnet 4 도 만약을 위해 롤백했다. 이후 근사 top-k 대신 정확한 top-k 를 쓰고 일부 연산을 fp32 정밀도로 통일했다.
2025년 8월 초부터 일부 사용자가 Claude 의 응답이 나빠졌다고 알리기 시작했다. 처음 들어온 보고는 평소에도 늘 오르내리는 사용자 피드백과 구분하기 어려웠다. 8월 말이 되자 보고가 더 잦아지고 끊이지 않아 조사가 시작됐다.
증상은 버그마다 달랐다. 영어로 물었는데 응답 중간에 "สวัสดี" 같은 태국어나 중국어 글자가 섞여 나왔고, 코드에 뻔한 문법 오류가 들어갔다. 다른 요청은 컨텍스트가 짧은데도 1M 토큰 컨텍스트 윈도우용 서버로 잘못 보내져 품질이 떨어진 응답을 받았다. 라우팅은 한번 정해진 서버를 계속 쓰는 방식이라, 한 번 잘못된 서버로 간 사용자는 이어지는 요청도 같은 서버로 가기 쉬웠다.
8월 29일 평범한 로드 밸런싱 변경 뒤로 영향받는 트래픽이 크게 늘었다. 최악이었던 8월 31일 한 시간 동안 Sonnet 4 요청의 16% 가 영향을 받았고, 이 기간에 요청을 보낸 Claude Code 사용자의 약 30% 는 적어도 메시지 하나가 잘못된 서버로 갔다. 어떤 사용자는 문제를 겪고 다른 사용자는 멀쩡해서 보고끼리 서로 어긋났다. 팀은 8월 29일 부정적인 보고가 치솟았을 때도 이를 로드 밸런싱 변경과 바로 연결하지 못했다.
평소 쓰던 벤치마크와 평가는 사용자가 겪는 품질 저하를 잡아내지 못했다. Claude 가 한 번씩 하는 실수에서는 잘 회복한다는 점도 한 이유였다. 개인정보 보호와 보안 통제 때문에 엔지니어가 사용자 대화를 볼 수 있는 때와 방법이 제한됐고, 피드백으로 보고되지 않은 대화는 더 그랬다. 세 버그는 플랫폼마다 다른 증상을 다른 빈도로 냈고, 하나의 원인을 가리키지 않는 무작위 저하처럼 보였다. XLA 컴파일러 버그는 앞뒤에 어떤 연산이 돌았는지, 디버깅 도구를 켰는지에 따라 동작이 달라져서, 같은 프롬프트가 한 번은 잘 되고 다음 요청에서는 실패했다.
8월 초부터 사용자 보고가 들어왔지만 평소에도 늘 오르내리는 피드백과 구분되지 않았다. 8월 말 보고가 잦아지고 끊이지 않자 조사를 시작했고, 그 조사에서 버그 세 개가 드러났다. 벤치마크, 안전성 평가, 성능 지표, 소규모 카나리 배포는 이 저하를 잡지 못했다. XLA 버그는 Haiku 3.5 에서 먼저 관찰했고, Opus 3 의 문제는 나중에 이 버그와 맞아떨어지는 사용자 보고가 들어온 뒤에 알았다.
이번 세 버그는 잡음이 많은 평가에 크게 기대는 검증으로는 잡히지 않았다. Claude 가 한 번씩 하는 실수에서는 잘 회복해서 문제가 평가 점수에 드러나지 않았다. 온라인 보고가 늘어도 그 보고를 최근 변경 하나하나와 연결할 방법이 없었다. 겹친 버그가 플랫폼마다 다른 증상을 다른 빈도로 내면 원인 없는 무작위 저하처럼 보인다. 근본 원인을 고쳤다고 믿고 오래된 우회 코드를 지우면 그 코드가 가리던 다른 버그가 드러날 수 있다. 문제를 좁히는 데 결국 도움이 된 것은 사용자가 알려 준 구체적인 변화와 예상 밖 동작의 예시, 그리고 여러 사용 사례에 걸쳐 나타난 패턴이었다.
https://incidentlib-mcp.benchlet.com/mcpAPI 는 키가 필요 없습니다. MCP 서버는 search_incidents, get_incident, list_incidents, get_topic, vocab 도구를 내놓습니다. 사용법은 API 와 MCP.