▲

세 가지 최근 Claude 품질 저하 이슈의 사후 분석

 (anthropic.com)
1P by GN⁺ 3일전 | ★ favorite | 댓글 1개
  • 8월부터 9월 초까지 Claude 응답 품질 저하 현상이 세 가지 인프라 버그로 인해 발생함
  • 문제의 주요 원인은 각각 컨텍스트 윈도우 라우팅 오류, 출력 손상, 그리고 XLA:TPU 근사 top-k 미컴파일 오류임
  • 각 버그는 다양한 하드웨어 및 배포 경로에서 서로 겹쳐서 진단이 더욱 어려웠음
  • 탐지 및 해결이 지연된 원인에는 검증 프로세스의 허점, 프라이버시 정책에 따른 접근 제약 등이 있었음
  • Anthropic는 평가 및 모니터링 강화, 더 빠른 디버깅 도구 개발 등으로 유사 사고 예방에 나섬

개요 및 배경

  • 8월부터 9월 초까지 Claude의 응답 품질이 간헐적으로 저하되는 현상이 보고되었음
  • 초기에는 사용자 피드백 내에서 정상적 변동으로 여겨졌으나, 보고가 지속적으로 증가하면서 조사가 시작됨
  • Anthropic는, 수요나 서버 부하 때문이 아니라 인프라 버그만이 문제 원인임을 명확히 밝힘
  • Claude는 수백만 사용자에게 여러 플랫폼(APIs, Amazon Bedrock, Google Vertex AI 등)을 통해 서비스되고, AWS Trainium, NVIDIA GPU, Google TPU 등 다양한 하드웨어에서 동등한 결과를 보장하기 위해 엄격한 검증 기준을 가짐
  • 이번 사후 분석에서는 버그 원인, 진단 및 해결 지연 이유, 그리고 재발 방지 대책을 설명함

Claude의 대규모 서비스 방안

  • Claude 서비스는 여러 하드웨어(Trainium, GPU, TPU)를 통해 글로벌 배포를 유지함
  • 각 플랫폼별 동일 품질 보장을 위한 구현 동등성 기준이 엄격함
  • 인프라 변경 시, 모든 플랫폼 및 설정에서 정밀한 검증 과정 필요함

주요 이슈 발생 연표

  • 8월 5일: 첫 번째 버그, Sonnet 4 요청의 약 0.8%에 영향
  • 8월 25, 26일: 두 번째, 세 번째 버그 각각 배포됨
  • 8월 29일: 로드 밸런싱 변경으로 인해 문제 트래픽이 급증, 더 많은 사용자가 영향을 받게 됨
  • 각 버그는 증상이 중첩되어 진단 난이도가 매우 높았음

세 가지 중첩 버그 및 해결 과정

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

  • 8월 5일, 일부 Sonnet 4 요청이 1M 토큰 컨텍스트 윈도우를 위한 서버로 잘못 라우팅됨
  • 로드 밸런싱 변경 이후 최대 16%의 Sonnet 4 요청에 영향, Amazon Bedrock과 Google Vertex AI에도 미미하게 영향 발생
  • 라우팅 방식이 "sticky"이어서 잘못된 서버에 한 번 연결되면 이후에도 동일 서버에 계속 연결되는 문제가 있었음
  • 해결: 라우팅 로직 개선, 9월 4일 자사 플랫폼에 패치 적용, Google Cloud에는 9월 16일까지 배포, Bedrock에는 순차 적용 진행 중임

2. 출력 손상(bug)

  • 8월 25일, Claude API의 TPU 서버에 잘못된 설정 적용되어 토큰 생성 시 에러 발생
  • 영어 질문에 태국어나 중국어 등 엉뚱한 문자가 섞여 나오는 등, 코드에 명백한 문법 오류가 삽입되는 현상 발생
  • Opus 4.1 및 Opus 4, Sonnet 4에만 영향, 서드파티 플랫폼은 영향 없음
  • 해결: 9월 2일에 변경분 롤백, 비정상 문자 출력 탐지 테스트를 배포 프로세스에 추가함

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

  • 8월 25일, 토큰 선택 방식 고도화 중 XLA:TPU 컴파일러의 잠재적 버그가 드러남
  • Claude Haiku 3.5, 일부 Sonnet 4, Opus 3에 영향
  • 서드파티 플랫폼은 영향 없음
  • 해결: Haiku 3.5는 9월 4일, Opus 3은 9월 12일 각각 롤백, Sonnet 4에는 직접 재현되진 않았으나 예방조치로 롤백함
  • 병행하여 XLA:TPU 팀과 협력해 컴파일러 버그를 수정 중, 정확한 top-k 방식 사용으로 전환

XLA 컴파일러 버그 상세 분석

  • Claude는 토큰 생성 과정에서 각 후보에 대한 확률 계산과 표본 추출 작업을 수행함
  • TPUs는 분산 환경에서 동작, 토큰 확률 계산을 동기화해야 하며 복잡함 동반
  • 2024년 12월, bf16-32비트 혼합 정밀도 사용에 따른 오차로 최상위 확률 토큰이 누락되는 문제 발견, 이에 대한 임시 수정 배포
  • 8월 26일, 근본 원인을 해결하기 위한 샘플링 코드 개편 중, 근사 top-k 연산에서 특정 경우에 완전히 잘못된 결과가 출력되는 더 심층적인 버그가 노출됨
  • 이 버그는 이전 임시 수정이 문제를 가렸음
  • 또한, 근사 top-k 연산의 버그는 운영 환경 및 배치 크기에 따라 증상이 불규칙하게 달라졌음
  • 근사 top-k 대신, 최근에는 성능 부담이 크게 줄어든 exact top-k로 전환했으며 주요 연산들을 fp32 표준화로 개선함

탐지 지연 원인

  • 주기적인 자동화 평가와 사전 그룹 배포 등의 절차 사용 중
  • 이번 사건들은 평가 프로세스의 허점이 드러났음. 예를 들어, 문제 상황을 잘 탐지하지 못하는 평가 항목, 내부 개인정보보호 정책(엔지니어가 구체적인 사용자 요청 접근 불가) 때문에 신속한 분석이 어려움
  • 증상이 플랫폼 및 버전에 따라 다양하게 나타나 단일한 원인 규명이 힘들었음
  • 온라인 보고 급증 시에도, 표준적 로드밸런싱 변경과 연관성을 즉시 인지하지 못함

향후 개선 및 대응책

  • 민감도 높은 평가 항목 개발, 손상 상태와 정상 구현을 더 명확히 판별할 수 있는 자동화 평가 강화
  • 실제 운영 환경 전체에 평가 및 모니터링 시스템 확대, 예를 들어 컨텍스트 윈도우 라우팅 에러와 같은 운영 환경 중심 평가 수행
  • 더 빠르고 정교한 디버깅 도구 신설, 커뮤니티 피드백을 프라이버시 유지 하에 신속히 분석할 수 있도록 인프라와 커스텀 도구 개발
  • 내부 평가뿐 아니라, 사용자 피드백의 지속적 수집 신뢰 강조: 예측하기 어려운 에러나 버그는 실제 사용자 신고가 중요 신호 역할을 함
  • "/bug" 명령어 혹은 'thumbs down' 기능 활용, 이메일 통한 모델 품질 평가 방법 제보를 적극 장려함

참고 설명

  • XLA:TPU는 XLA 고수준 최적화 언어 코드를 TPU 명령어로 변환하는 컴파일러임
  • 모델 사이즈가 크기 때문에 하나의 칩이 아닌 여러 칩에 분할 배치, sorting 오퍼레이션 등은 벡터화 형태로 구현 필요
  • 근사 top-k 연산은 성능 향상을 위해 사용되지만, 확률이 가장 높은 토큰을 누락하는 등의 심각한 문제를 내포할 수 있음
  • 현재 정확한 top-k 방식을 도입하였으며, top-p 임계값에 근접하는 토큰 포함 양상에 미세한 변화가 있을 수 있음. 경우에 따라 사용자는 top-p 값을 조정해야 할 수도 있음
▲
GN⁺ 3일전  [-]
Hacker News 의견
  • 최근 주목할 만한 점은 유닛 테스트의 부재임을 발견함. XLA 컴파일러 버그에 대한 테스트도 단순히 출력을 프린트하는 수준이라, 실제 테스트 하니스로 실행되어 커버리지를 추적하는 진짜 유닛 테스트와는 거리가 있음. 처리 방안으로는 Eval에 더 많이 의존하라는 식임. 현재 LLM 전체에 대한 유닛 테스팅은 비현실적이지만, 지금까지 드러난 버그들은 대부분 시스템의 작은 결정적 부분에 있었음. 예를 들어 로드 밸런싱, top-k 확률 계산 등은 모두 다른 소프트웨어와 다를 바 없이 엔지니어링된 부분이라 원칙적으로 유닛 테스트가 가능함. 필요하다면 주입 가능한 PRNG 하나 정도면 충분함. 비결정적 최적화 버그는 확실히 골칫거리이지만, 기존 앱 테스트 슈트로도 과거에 컴파일러 및 데이터베이스 버그를 찾아낸 경험이 있음. CI로 많은 테스트를 반복 실행하면, 희귀한 이벤트도 드러날 수 있음. 개인적으로 진행하는 프로젝트 중엔 모든 유닛 테스트를 같은 프로세스에서 병렬로 돌리고 있고, 이 방법으로 드물게 나타나는 쓰레드 세이프티 이슈나 데이터베이스 데드락도 효과적으로 찾아낼 수 있었음. 며칠 전 Java 런치 관련 스레드에서, Java가 Python보다 '엔터프라이즈'스럽게 여겨지는 이유가 코드가 유닛 테스트에 중점을 두고 작성되기 때문이라고 언급한 바 있음. 의존성 주입 등의 욕구로 인해 추상화가 많이 이뤄짐. 반면 스크립팅 언어 문화에서는 테스트가 아예 없거나 표면적으로만 진행되는 경우가 많았음(예: 타입만 어설션). PyTorch를 배울 때도 비슷한 인상을 받았고, 튜토리얼은 점진적으로 복잡한 것까지 다루지만 테스트나 코드 구조에 대한 언급이 거의 없음. 이는 ML 리서치에서는 평가 점수 올리는 것이 목표지만, 대규모 프로덕션 배포엔 어울리지 않는 접근임. AI 연구실에도 SRE나 HA 소프트웨어 엔지니어 배경의 인력이 더 필요하지 않을까 고민함. 개인적으로 프로덕션에서 Eval만 공격적으로 돌리는 방식이 버그 방지에 최선인지는 회의적임
    • AI가 Python에서 내가 원하는 형태의 유닛 테스트를 작성하도록 상세한 프롬프트와 예시를 제공해야만 했던 경험이 있음. 타입에 대한 어설션만 쓰는 것도 자주 봤음. 내가 원하는 건 값 자체에 대한 어설션임. AI가 모든 걸 너무 모킹(mocking)하는 경향이 있는데, 모킹도 유용하지만 유닛 테스트에서 실제 코드 전체를 호출할수록 코드 상호작용이나 인터페이스의 위험까지 커버할 수 있음. 그런데 AI가 생성한 Python 유닛 테스트는 너무 모킹에 집착해서, 자기충족적인(tautological) 코드만 확인하고 끝내는 경우가 많음. 그래서 모킹을 경계하라는 경고와 꼼꼼한 테스트 예시를 적극적으로 프롬프트에 포함시킴. 참고로 Python도 의존성 주입 같은 구조화된 코드 작성에 훌륭한 도구들이 많음
  • Anthropic가 AWS Bedrock 인프라에 직접적으로 영향을 줄 수 있다는 내용이 기사에 나온 것이 놀라움. 이는 AWS의 원래 약속과도 어긋남. Google Vertex AI도 마찬가지라고 생각되나, 아직 컴플라이언스 측면에서 확인해보진 못했음. <br> > 내부 프라이버시 및 보안 정책상, 엔지니어가 Claude의 사용자 상호작용에 접근하는 것은 제한적이라는 내용에는 공감함. <br> > 사용자가 직접 피드백을 보내는 것이 여전히 가장 도움이 된다는 점과, Claude Code에서 /bug 명령어를 사용할 수 있다는 안내엔 동의함. 해당 커맨드로 신고하면 맥락을 엔지니어가 확인할 수 있을 테지만, 사용자 입장에선 이 절차를 아주 명확히 고지해주길 바람(나는 Claude Code 유저가 아님). <br> > Claude 앱의 "thumbs down" 버튼 사용 안내는 다소 우려됨. 대부분의 사용자가 이 버튼 클릭이 프라이버시 포기와 같은 무게감을 갖는다고 생각하진 않을 것임
    • (Anthropic 직원, 개인 입장으로 발언) <br> > AWS Bedrock 인프라를 Anthropic가 직접 관리한다는 얘기는 사실과 다름. 현재는 AWS가 직접 운영함. <br> > "thumbs down" 버튼의 프라이버시 안내에 대해선, 해당 모달에 "이 피드백 제출 시, 현재 대화 전체가 Anthropic에 전달되어 모델 개선에 활용됨"이란 내용을 명시함. 혹시 이 안내 문구를 더 쉽게 개선할 방안이 있는지 궁금함
    • "thumbs down" 클릭 시, "이 피드백 제출 시, 대화 전체가 Anthropic에 전달됨"이라는 메시지가 안내되므로, 안내가 꽤 명확하다고 생각함
  • Anthropic 정도의 연구소에서 인프라 세부 내용을 공유할 정도면 상황이 꽤 어려운 듯함. 실제 FMA(곱셈-누산) 쪽 정밀도 버그는 상당히 안타깝고, 수치적 문제는 종종 매우 혼란스러운 경우가 많으며 아직 AI로는 풀 수 없는 영역임. 경쟁자가 실시간으로 시장 점유율을 뺏어가는 초압박 상황에선, 결국 사람의 개입이 필수이고 원인 규명에 몇 주 걸릴 수도 있음
  • "8월 29일 로드 밸런싱 변경이 우연히 1M 컨텍스트 서버에 더 많은 짧은 컨텍스트 요청을 보내게 되었고, 8월 31일 한 시간 동안 Sonnet 4 요청의 16%가 영향을 받았다"는 설명이 있는데, 이 말은 1M 컨텍스트 서버가 짧은 컨텍스트 입력에서 오히려 성능이 더 떨어지는 것처럼 보임. 아마도 이 서버들에서 KV 캐시 압축, 에빅션, sparse attention 등 별도의 방안이 적용된 결과일 수도 있겠음?
    • 이것은 RoPE(회전적 위치 임베딩) 스케일링 때문임. 유명한 오픈소스 프레임워크들은 대부분 static YaRN을 구현하는데, 이건 입력 길이에 상관없이 스케일링 팩터가 고정되어서 짧은 텍스트 처리 시 성능에 영향을 줄 수 있음. 긴 컨텍스트가 필요할 때만 rope_scaling 설정 추가를 권장하고, 애플리케이션 평균 입력 길이에 맞춰 팩터도 조정하는 게 좋음. 예를 들어 52만 토큰 전후라면 factor 2.0으로 설정하는 게 더 나음 <br> 출처 (Qwen3-Next-80B 설명 페이지)
    • 이들의 포스트모템 보고서에서, 세 가지 문제 중 두 개는 정확한 원인이 나오지 않았다는 게 핵심임. 내가 아는 바로는 내 요청이 지금 세 가지 완전히 다른 코드 경로 중 아무 데로나 보내질 수 있는데, 각각 별도의 스택과 튜닝이 적용됨. 이 최적화가 모델 버전 업그레이드와 무관하게 갑자기 바뀔 수도 있어서, 어제 잘되던 게 오늘 깨질 수도 있음. 이런 포스트모템에 대해서 칭찬이 나오는 게 이해가 안될 정도로 오히려 더 답답함
  • Anthropic 팀을 존중하는 마음으로, Claude status 페이지의 품질은 내부적으로 코드 레드(경고)를 울릴 수준임. 7월에 50건, 8월에 40건, 9월엔 21건의 인시던트가 있었음. 예전에 이런 숫자의 절반만 돼도 모두 업타임과 품질에 집중하라고 강하게 방향을 튼 경험이 있음. 그래도 아직 Claude가 훌륭한 제품이라 유료 결제를 계속하고 있음. API 써보고 Max 멤버십 바로 결제함. 그 덕분에 생산성이 급상승했음. 하지만 최근 몇 주간 계속 반복된 품질 저하 때문에 구독을 계속 해야 할지 고민이 생김. 솔직하게 문제 현황을 공유해준 것은 고맙지만, 고객 입장에서는 불만이 큼. 아직 로드 밸런싱 문제 등은 완전히 검출되지도, 해결되지도 않았다고 봄. 구체적으로 12시(동부)/9시(서부) 무렵이 되면 Claude Code 품질이 체감상 많이 떨어짐. 팀이 계속 문제를 찾고 해결해 주길 바람. 집에서 로컬 모델 돌릴 때도 복잡한 버그 많이 맞닥뜨린 경험이 있어서 이 문제들이 쉽지 않다는 건 이해함. <br> status 페이지 링크
    • 다른 회사들과 비교해 Claude가 더 낫거나 못하다고 단정지을 수는 없지만, 한 가지 확실한 건 많은 회사들 status 페이지에 거짓말이 많다는 점임. 실제로는 자주 장애가 발생하는데, status 페이지엔 표시가 안 되는 경우가 허다함. 오히려 요즘은 문제를 솔직하게 알릴 때 더 놀라움. 개인적으로 Claude에서 심각한 이슈를 겪진 않았지만, 내가 운이 좋았을 수도 있음. 내 관점에서는, 오히려 Claude가 장애 보고를 더 충실히 하고 있는 것 같음. 물론 이게 단순히 우연일 수도 있음
    • 더욱 우려스러운 점은 status page에서 작은 사고는 다수 누락된다는 점임. 모든 AI 제공업체가 비슷함. 실시간 토큰 대기시간, 실패 요청, 초당 토큰 처리 속도 같은 통계 그래프를 공개한다면 상당히 충격적일 것임. OpenRouter 데이터를 보면 API의 업타임이 결코 좋지 않다는 걸 알 수 있음. Claude Code도 종종 매우 느려져서 수동으로 중단시키고 재시도해야 하는 경우가 잦음. 특히 오후 4~6시(영국 기준)에 심하게 느려짐(유럽, 동부, 서부 미국 전부 몰리는 타임). 오늘도 Gemini AI studio에서 모델 과부하로 503 에러가 발생했지만, status page에는 아무 표시 없었음. Claude 등이 오프피크 타임에 싸게 제공하는 요금제를 도입한다면 수요를 고르게 할 수 있지 않을까 생각해봄. 다만 그런 요금제는 외형상 부정적으로 보일 수도 있음. 추가로, GB200 GPU가 도입이 생각보다 훨씬 느렸고 하드웨어/소프트웨어 결함도 다수 있었던 걸로 보임. 액체 냉각 문제도 만만치 않았던 듯(실패하면 치명적)
    • "그래도 Claude가 너무 좋아서 결제한다"는 말 자체가 중요한 시사점임. 현 시점에서는 AI 품질이 서비스 신뢰성보다 고객(나 포함)에게 더 중요한 요소임. 물론 업체도 장차 신뢰성에 집중하겠지만, 왜 지금 품질보다 신뢰성을 우선순위에 둬야 할까?
    • 최근 품질 급락 현상으로 상당히 불안해짐. 다행히 나는 아직 프로덕션 서비스에 AI를 안 쓰고 있지만, 개발 과정에서 모델이 갑자기 '멍청해진다'는 상황은 우회하기 정말 힘듦. 현 시점에서 openrouter의 여러 벤더들이 신뢰를 저버리고 몰래 컨텍스트를 줄이거나, 양자화 수치를 낮추거나, 전문가 수를 줄이는 등 슬쩍 컴퓨팅 리소스를 줄이는 트릭을 쓰는 게 아닌지 의심스럽기도 함
    • 이런 이유로 status 페이지 표기 인시던트 수를 최소화해야 한다는 전략을 씀. 고객 평가는 일시적으로 나빠지지만, 시간이 지나면 부정적 영향이 사라짐. 하지만 status 페이지를 꾸준히 운영하면 문제의 '증거'가 명확히 남음. 차라리 속이는 게 장기적으로 더 유리함. 실제로 S3는 여러 차례 에러 등 장애가 있었지만 공개하지 않았고, 아무도 문제삼지 않았음. 사람들은 많은 말을 하지만, 실제 행동은 숨긴 쪽에 보상을 주는 구조임. 모든 스타트업 성장 해커들은 이미 이 사실을 잘 알고 있음
  • 8월 25일 Claude API TPU 서버에서 잘못된 설정이 배포되어, 토큰 생성 중 오류가 발생했다고 설명됨. 코드 버그는 익숙하지만, LLM은 인간이 직접 작성하는 게 아니라 대규모 자동 훈련으로 탄생하는데, 이런 버그가 어떻게 발생할 수 있는지 궁금함. 예를 들어 모델에서 영어 질의에 대해 한가운데 'สวัสดี'(태국어)가 튀어나오는 경우엔, 사람 입장에서 구조상 어떻게 그런 버그가 주입될 수 있는지 궁금함
    • LLM은 결국 인간이 작성한 코드에 의해 실행됨. 마지막 단계에서는 모델이 전체 토큰(vocab 약 20만 개)에 대한 확률 분포를 생성함. 그 후 실제 다음 토큰을 어떤 방식으로 뽑을지 사람이 결정함. 예를 들어, 항상 가장 확률이 높은 토큰을 고르거나, top-k 중에서 랜덤으로 선택해 창의성을 높임. 이 top-k 샘플링을 효율적으로 처리하기 위해 XLA로 커널을 컴파일하는데, 이 커널에서 버그가 나서 가끔 top-k 밖의 토큰이 선택되는 문제가 있었던 것으로 보임
    • LLM은 다음 토큰에 대한 확률 분포를 뱉고, 실제 결과는 샘플링 방식예시에 따라 달라짐. 예를 들어 '가장 확률 높은 4개 중에서 랜덤'을 고르는데 연산자(부등호)가 잘못되면 본문과 같은 현상이 나옴
    • 사용자와 모델 파라미터 사이에는 인간이 작성한 코드 레이어가 여러 겹 있음
    • 간단히 설명하면, 트레이닝과 인퍼런스 두 단계가 있음. 트레이닝은 오랜 시간 자동화되나 인퍼런스는 사용자의 프롬프트 입력이 들어오면 즉시 실행되는 별도의 소프트웨어 스택임. 이 스택이 지속적으로 성능 개선 업데이트를 받으면서, 그 과정에서 이런 인퍼런스 관련 이슈가 생김
    • AI 커널은 부동소수점 연산이기 때문에, 기존 실수 범위에서는 음수가 아닌 값이 특이하게 음수가 되기도 함. 성능상 오버플로 체크 같은 걸 꺼버리고, 음수가 튀어나오면 이를 아주 큰 수로 처리하는 경우가 있음(마치 -1번째 배열 인덱스를 요청해도 마지막 원소가 나오는 식)
  • LLM 추론 과정에서 결정론적(deterministic)으로 만드려고 고민하는 것이 문제 추적에 도움이 될 수 있겠단 생각임. 최근 '부동소수점 결합 순서 때문이라는 통설이 사실은 완전히 핵심 원인이 아니라는' 논문도 나왔음 <br> 관련 논문 소개
    • 네트워크 트래픽이나 머신 부하는 본질적으로 비결정론적임. 근 시일 내에 완전한 결정론(예: 감사를 위해)은 비용 민감하지 않은 배치 작업 정도에서만 현실적임. 실제로 구글 검색도, 소셜미디어 추천수 로딩도 전혀 결정론적이지 않음. 분산 시스템에서는 graceful degradation(부분 서비스 유지)이 핵심 조언인데, 완전히 결정론적 시스템에서는 이런 대응이 불가능함
    • 결정론적 설계는 성능에 부정적 영향을 줌. 결국 모델을 또 하나 만들어서, 기존 모델의 품질을 모니터링, 알림하는 'IQ 테스트' 식 접근이 남음
  • "Google Cloud Vertex AI에서 8월 27~9월 16일 사이 잘못된 라우팅은 0.0004% 미만이었다"는 내용에 공감함. 실제로 업무상 해당 계정으로 CC를 쓰며 질 저하를 체감한 적 없음. 전반적으로 이런 버그들이 심각하긴 해도, 온라인 후기에서 언급된 것보단 훨씬 드물었다고 느꼈음. 이슈 발생 기간도 실은 1~2주에 대부분 집중됨. 전체 요청 대비 영향받은 비율도 상대적으로 작음
    • 하지만 회사 기사 자체에도 "Claude Code 유저의 30%가 최소 한 번 잘못된 서버로 라우팅되어 응답 품질 저하를 겪었다"고 나옴. 라우팅이 'sticky'해서 한 번 잘못된 서버로 배정된 뒤에는 연속해서 같은 서버로 요청이 전달됨. Claude Code 이용자 30%가 품질 저하를 겪었다면 엄청난 버그임
    • 최근엔, 전세계적 장애가 발생해도 기업들이 "일부 소수 사용자에게 오류가 증가했다"는 식의 완곡한 표현만 쓰고, CTO가 승인하고 나서야 status 페이지를 수정하는 경우가 많다는 점에서 기업을 쉽게 신뢰하지 않음. 진짜 솔직한 커뮤니케이션을 하는 기업이 있다면 시장에서 강점이 있을 것임
  • LLM 서비스에서 결정론적으로 동작하도록 만들면, 문제 추적에 도움이 될 것이라는 의견임. 최근 floating point 연산의 결합 순서에만 귀속시키던 원인을 실제로는 더 다양한 결정론 붕괴 요인이 있다는 논문도 언급함. 논문 링크
  • 웹앱 디자인에서 최근 claude가 DOM에 아무 텍스트나 랜덤하게 보이도록 만드는 현상이 심각히 발생하는 것을 경험함. 이는 svelte와 결합해 사용할 때 특정하게 발생한 거 같으며, 이 문제가 본문의 현상들과 연관됐는지는 확신이 없으나 이전에는 이런 심각한 품질 저하는 겪지 못했었음
  • 실제 실패 케이스가 무엇인지 포스팅에 포함해줬으면 좋겠다고 바람. Claude Code에서 도구 호출 이후 아예 멈추는 현상을 자주 겪었는데, 이게 이번에 언급된 버그 중 하나 때문이었는지 궁금함
    • 나도 최근 며칠 사이 똑같은 문제를 점점 더 많이 경험하고 있음. 아마 본문의 버그와는 별개(그래도 여전히 버그)일 수도 있다 생각하지만, 내 예상이 틀렸으면 좋겠음. "왜 멈췄나요? 계속 진행하세요"와 같은 요청을 재차 보내는 빈도가 눈에 띄게 늘어남
답변달기