목차
이 글은 Anthropic 엔지니어링 블로그에 2025년 9월 17일 게재된 “A postmortem of three recent issues” 를 읽고, 내용을 정리한 글입니다. 원문: https://www.anthropic.com/engineering/a-postmortem-of-three-recent-issues
한 줄로 말하면 #
벤치마크는 통과했는데 사용자는 이상하다고 했다. 그 격차 자체가 진짜 사고의 본질이었다.
어떤 문제를 해결하려 했나 #
2025년 8~9월, Claude 사용자들이 비슷한 불평을 올리기 시작했습니다.
“오늘따라 Claude가 영어 답변에 갑자기 태국어 ‘สวัสดี’를 끼워 넣어요.” “Sonnet 응답 품질이 어제부터 이상한데, 우연인가요?”
내부 벤치마크는 멀쩡했습니다. 그런데도 사용자 신호는 명확했죠. 알고 보니 세 개의 인프라 버그가 겹쳐, 일부 요청만 조용히 망가지고 있었습니다. 사용자는 알았고 평가는 몰랐던 거예요.
이 글은 그 세 사고와, “왜 내부 평가가 못 잡았는가” 에 대한 자기 분석입니다.
세 가지 사고 요약 #
1. 컨텍스트 창 라우팅 오류 (8/5 ~ 9/4) #
곧 출시될 1M 토큰 컨텍스트용 서버로 짧은 요청이 잘못 라우팅됐습니다.
- 8/5 도입 → 8/29 부하분산 변경으로 악화
- 8/31 피크: Sonnet 4 요청의 16% 영향
- Claude Code 사용자 약 30%가 한 번 이상 잘못된 서버로 향함
- 라우팅이 “sticky"라서 후속 요청도 같은 잘못된 서버로 유지됨
2. 출력 손상 — 토큰 확률 오배정 (8/25 ~ 9/2) #
Claude API TPU 서버 설정 오류로, 거의 안 나와야 할 토큰에 높은 확률이 배정됐습니다. 영어 답변에 태국어가 섞이거나, 코드에 문법 오류가 끼는 사례 발생.
3. 근사 top-k의 XLA:TPU 컴파일러 버그 (8/25 ~ 9/12) #
이게 가장 까다로웠습니다. Claude는 다음 토큰 확률을 bf16(16비트) 로 계산하는데, TPU 벡터 프로세서는 fp32(32비트) 네이티브입니다. 컴파일러의 xla_allow_excess_precision 플래그가 기본값 true라, 연산이 서로 다른 정밀도로 돌면서 “최고 확률 토큰이 뭔지” 합의 안 되는 상황이 벌어졌습니다.
배치 사이즈와 모델 구성에 따라 다르게 나타나서 재현조차 어려웠습니다.
왜 내부 평가가 못 잡았나 #
원문에서 가장 중요한 부분입니다. 평범한 모니터링·평가·카나리 배포가 다 있었는데도 못 잡았어요. 이유는 네 가지.
| 격차 | 내용 |
|---|---|
| 프라이버시 ↔ 디버깅 충돌 | 내부 프라이버시 정책상 엔지니어가 사용자 대화를 못 봐서 문제 재현 어려움 |
| 벤치마크 둔감 | 평가 셋이 사용자가 느낀 미묘한 품질 저하를 못 잡음 |
| 자가 복구 | Claude가 작은 실수에서 잘 회복하니 사고가 가려짐 |
| 혼재된 신호 | 세 버그가 플랫폼·시간대마다 다른 증상을 내서 신고가 서로 모순 |
핵심 인용: “평가와 모니터링은 중요하다. 그러나 이번 사고는 우리에게 사용자의 지속적인 신호가 필요하다는 걸 분명히 했다.”
무엇을 바꿨나 #
- 민감한 평가셋: 작동/고장 차이를 명확히 가르는 평가로 교체
- 상시 운영 모니터링: 배포 전이 아니라 운영 중인 실서버에서 평가를 계속 돌림
- 더 빠른 디버깅 도구: 프라이버시를 지키면서 커뮤니티 피드백을 추적할 수 있도록 인프라 보강
- 정확한 top-k 사용: 효율을 약간 손해 보더라도 정확성 우선 (“Model quality is non-negotiable”)
- 사용자 피드백 채널 강화:
/bug명령, 👎 버튼, [email protected] 명시적 안내
핵심 결론 #
품질이 떨어졌다는 신고가 들어왔을 때 본능적으로 “모델이 이상한가?“를 봅니다. 이 글의 결론은 다릅니다.
“모델 문제인 줄 알았는데, 사실은 인프라 버그를 평가가 못 잡고, 사용자 신호를 우리가 못 들은 게 문제였다.”
벤치마크가 잡지 못하는 사고가 있고, 그 사고는 사용자만 가장 먼저 압니다. 그래서 사용자 피드백을 신호로 다루는 체계가 모니터링만큼 중요합니다.
내 작업에 적용한다면 #
시나리오 1 — 일반적인 데이터 분석 과정 #
데이터 분석에서도 똑같은 사일런트 실패가 벌어집니다. 결과는 그럴듯한데 사실은 어딘가 미세하게 어긋난 상태입니다.
[흔한 사일런트 실패]
- 정제 단계에서 일부 행만 잘못 캐스팅돼 평균이 살짝 어긋남
- 데이터 갱신 누락으로 특정 기간만 비어있음
- 단위(원/달러) 혼재로 합계가 이상한데 그래프상 티 안 남
→ 단위 테스트는 통과, 분석가 눈에만 띔
[postmortem 정신 적용]
- 신뢰 구간·이상치 자동 알람 (벤치마크 외 사용자 감각에 가까운 신호)
- 갱신 모니터링: "데이터 신선도가 깨진 순간"을 매일 확인
- 결과 리뷰어(사람·LLM)에게 자유 서술형 이상 신고 받기
- "결과가 이상해 보였던 적 있나?"를 분석 회고에 정례화핵심: 자동 검증만 믿지 말고, 분석을 보는 사람의 미묘한 위화감을 신호로 수집하세요.
시나리오 2 — 웹 사이트를 자동으로 운영할 때 #
웹 운영에서 가장 무서운 건 “상태 페이지는 초록불인데 사용자는 안 된다” 상황입니다.
[흔한 사일런트 장애]
- CDN 일부 지역 캐시 오염 → 특정 국가만 이상한 페이지 표시
- 배포 후 폼 전송이 30% 확률로 실패 (로그엔 5xx 안 잡힘)
- 검색 인덱스 갱신 누락 → 새 글이 안 보임
→ uptime 모니터링은 통과
[postmortem 정신 적용]
- 합성 모니터링(synthetic test): 실제 사용자 흐름 흉내내 5분마다 점검
- 사용자 피드백 채널 명시 (사이트 모든 페이지에 "이상해요?" 버튼)
- 실시간 에러 트래킹 + 사용자 신고 대시보드 통합
- 인시던트마다 짧은 포스트모템 글로 남겨, 같은 종류 사고 재발 방지핵심: 자동 모니터링이 보여주는 초록불은 “테스트한 것만 멀쩡하다” 는 뜻입니다. 사용자가 알려주는 위화감 신호를 1급 입력으로 다뤄야 진짜 안정 운영입니다.
Anthropic 엔지니어링 블로그를 오래된 순서대로 읽고 정리합니다.
