지금 Claude가 다운되었나요? 불완전한 응답의 함정 (2026 실시간 상태, 해결 방법 및 폴백)

원문은 twarx.com에서 처음 게시되었습니다 - 전체 대화형 버전은 그곳에서 읽을 수 있습니다.

최종 업데이트: 2026년 6월 22일

지금 Claude가 다운되었나요? 만약 당신이 2026년 6월 21일 오후 8시 15분에 이를 검색했다면, 당신은 2,000명 이상의 개발자[\u200d\u200d1\u200d] 중 한 명이었을 것입니다. 이들은 모든 단계가 단일 Claude API 호출에 의존하는 6단계 에이전트 워크플로 (agentic workflow)가 95%의 신뢰성을 갖는 것이 아니라, 단 한 번의 토큰 스트림 (token stream) 절단만으로도 완전한 실패로 이어질 수 있다는 사실을 뼈아프게 깨달았습니다.

Claude는 단순히 다운된 것이 아닙니다. 이는 Anthropic이 공개적으로 다루지 않은 인프라 신뢰성 위기를 드러내고 있으며, 이를 일시적인 결함으로 취급하는 모든 개발자는 단 한 번의 운영 중단만으로도 치명적인 고객 실패를 겪게 될 것입니다. Google과 Asbury Park Press에서 트렌드가 되고 있는 '응답 불완전 (response incomplete)' 오류는 단순한 버그 보고가 아닙니다. 이는 AI 도입 속도가 이를 지원하기 위해 구축된 신뢰성 아키텍처 (reliability architecture)를 앞지를 때 어떤 일이 발생하는지에 대한 경고 신호입니다.

이 글을 마칠 때쯤이면 당신은 Claude가 지금 다운되었는지 진단하는 방법, 불완전한 응답을 수정하는 방법, 그리고 LangChain 폴백 라우팅 (fallback routing)을 사용하여 Claude에 탄력적인 스택을 설계하는 방법을 막연한 설명이 아닌 실제 코드를 통해 정확히 알게 될 것입니다. 단일 제공자 의존성이 왜 위험한지에 대한 더 넓은 맥락은 우리의 AI 에이전트 오케스트레이션 (AI agent orchestration) 가이드를 참조하십시오.

2026년 6월 21일, 수천 명의 Claude 사용자를 막다른 길로 몰아넣었던 '응답 불완전 (response incomplete)' 오류 — 이것은 우리가 '불완전한 응답의 함정 (The Incomplete Response Trap)'이라 부르는 현상의 전형적인 증상입니다. 출처: Asbury Park Press / Gannett

조어된 프레임워크 (Coined Framework)

불완전한 응답의 함정 (The Incomplete Response Trap) — Claude의 토큰 스트림 (token-stream) 중단, API 타임아웃 (timeout) 설정 오류, 그리고 상태 페이지 (status-page)의 지연이 결합되어 기업 사용자들이 상황을 파악하지 못하고, 작업이 차단되며, 오류가 발생한 출력물에 대해서도 비용을 지불하게 만드는 연쇄적 장애 패턴

이 용어는 Claude가 겉으로 보이는 동작(깔끔한 에러 반환)과 실제로 수행하는 동작(에러 경계 없이 과금 대상인 출력을 조용히 잘라버림) 사이의 시스템적 간극을 명명합니다. 이 '함정'은 일시적인 네트워크 이벤트를 몇 시간 동안의 잘못된 디버깅(debugging)으로 변질시키는데, 이는 개발자가 해당 장애가 자신의 잘못인지, 네트워크의 문제인지, 아니면 Anthropic의 문제인지 구분할 수 없기 때문입니다. 이를 수치로 환산해 보면: 시니어 엔지니어의 평균 시급인 시간당 $120를 기준으로, 평균적인 개발자가 유령 버그\5를 쫓으며 허비하는 23분은 사고당 엔지니어 1인당 약 $46의 비용을 발생시킵니다. 그리고 최근 90일 동안 발생한 약 9건의 Claude 장애를 겪은 3인 규모의 팀은, 낭비된 토큰(token)이나 손실된 리테이너(retainer) 비용을 제외하고도 순수하게 오진(misdiagnosis)에 투입된 노동력만으로 분기당 거의 $1,200를 지불하게 됩니다.

속보: 지금 Claude에 무슨 일이 일어나고 있는가

2026년 6월 21일 일요일, Claude의 장애가 대규모로 발생하기 시작했습니다. Asbury Park Press에 따르면, 이 AI 프로그램은 단 하루 만에 Downdetector\2에 2,000건 이상의 문제 보고를 기록했으며, 혼란에 빠진 사용자들이 답을 찾기 위해 검색하면서 Google에서 'response incomplete claude'라는 문구가 트렌드에 올랐습니다.

확인된 보고 및 장애 규모 — 수치가 말해주는 것

최초 보고에 따르면, 문제는 '오후 8시 직후에 시작되었습니다'[[1]]되었으며, 대부분의 불만은 Claude Chat 및 Claude Code에 집중된 반면, 일부 사용자들은 앱에 아예 접속할 수 없다고 보고했습니다. 보고서에는 '수정 일정은 없으나, 이러한 문제는 종종 빠르게 해결된다'라고 명시되었습니다. 마지막 부분은 사실입니다. 하지만 오후 8시 15분에 파이프라인(pipeline)이 중단되었고 문제가 본인 측에 있는지 알 수 없는 상황에서는 그 말이 별로 위로가 되지 않습니다.

가장 명확한 직접적인 사례 중 하나는 r/ClaudeAI 사고 스레드에서 나왔습니다. 핀테크 기업의 리드 플랫폼 엔지니어(Lead Platform Engineer)인 Marcus Feld는 장애 발생 중 r/ClaudeAI에 다음과 같이 작성했습니다. '우리 리트리벌 레이어(retrieval layer)가 컨텍스트(context)를 손상시키고 있다고 확신하며 40분을 보냈다. 우리 문제가 아니었다. Sonnet이 토큰 중간에 스트림(stream)을 끊어버리면서도 깨끗한 200 상태 코드를 반환하고 있었다. 기술적으로 에러가 발생한 것이 없었기 때문에 알림(alert)도 전혀 울리지 않았다.'[[5]] Anthropic을 의심하기 전까지 거의 한 시간 동안 자신의 스택(stack)을 디버깅(debugging)해야 했던 그 경험은, 단 한 문장으로 요약하자면 바로 '함정(Trap)'입니다.

2,000+
Downdetector에 하루 동안 보고된 Claude 문제
[Asbury Park Press, 2026 [1]](https://www.app.com/story/news/2026/06/21/is-claude-down-response-incomplete-claude-claude-api-error/90638546007/)
...

Anthropic 공식 상태 페이지 vs 실제 사용자 보고 경험

여기 불편한 진실이 있습니다. status.anthropic.com은 역사적으로 실제 사용자가 보고하는 장애보다 뒤처져 왔습니다. 이전 사고들 동안, Downdetector의 크라우드 소싱(crowd-sourced) 보고는 Anthropic의 자체 대시보드가 '성능 저하(Degraded Performance)'를 표시하기 15~45분 전에 이미 장애를 드러냈습니다. CI/CD 파이프라인을 운영하는 개발자에게 이 지연 시간은 트래픽을 재라우팅(rerouting)하느냐, 아니면 망가진 릴리스(release)를 배포하느냐의 차이를 만듭니다. 저는 이 두 가지 상황이 모두 발생하는 것을 목격해 왔습니다.

가장 최근의 Claude 장애 이벤트 타임라인

6월 21일의 이벤트는 고립된 이상 현상이 아닙니다. 언론 보도와 커뮤니티 기록은 수일간 지속되는 불안정성의 반복적인 패턴을 가리키고 있습니다. 인접한 날짜에 수백 건의 보고가 기록된 별개의 사건들이 발생했으며, 웹 앱(Web App), API, 그리고 Claude Code 전반에 걸쳐 로그인 실패, 불안정한 응답, API 중단이 동시에 발생했습니다. 이러한 동시성이 핵심입니다. 이는 세 가지 서비스 모두에서 상관관계가 있는 실패 위험을 생성하는 공유 인프라 의존성(shared infrastructure dependency)이 있음을 시사하며, 이는 여러분의 폴백(fallback) 전략이 단순히 엔드포인트(endpoint)를 교체하는 것에 그쳐서는 안 되고, 제공업체(provider) 자체를 교체해야 함을 의미합니다. 우리는 LangGraph 멀티 에이전트 시스템 (multi-agent systems) 분석에서 이 패턴을 더 자세히 파헤칩니다.

웹 앱, API, Claude Code가 동일한 분(minute)에 모두 실패한다면, 그것은 세 개의 버그를 보고 있는 것이 아닙니다. 폭발 반경 격리(blast-radius isolation)가 없는 하나의 아키텍처를 보고 있는 것입니다.

정의: 비전문가를 위한 'Claude 응답 불완전(Response Incomplete)' 설명

만약 여러분이 소규모 비즈니스를 운영하고 있고, 고객 지원 챗봇이나 송장 초안 작성 도구가 Claude를 기반으로 작동한다면, '응답 불완전(response incomplete)'이 무엇을 의미하는지 쉬운 용어로 설명해 드리겠습니다. 즉, Claude가 답변을 쓰기 시작했으나 문장 중간에 끊겼고 결코 완료하지 못했다는 뜻입니다. 하지만 시스템이 항상 실패 사실을 알려주지는 않았습니다. 여러분은 어쨌든 절반만 완성된 답변에 대해 비용을 청구받았을 수도 있습니다.

말하는 도중에 전화가 끊기는 상황을 생각해 보세요. 다만 전화 요금은 전체 통화 시간에 대해 그대로 청구되고, 상대방은 생각을 마무리하기 위해 다시 전화를 걸어주지 않는 상황과 같습니다. 비즈니스 소유자에게 이는 고객이 잘린 답변을 받게 되거나, 자동화된 워크플로(workflow)가 문서의 절반만 저장한 채 아무 일도 없었던 것처럼 다음 단계로 넘어갈 수 있음을 의미합니다.

'응답 불완전(response incomplete)' 상태가 항상 HTTP 에러 코드를 트리거하는 것은 아닙니다. 즉, 여러분의 에러 모니터링(error monitoring) 시스템에는 실패가 0건으로 표시되는 동안, 애플리케이션은 가치가 없는 출력물에 대해 토큰(token) 비용을 청구받을 수 있습니다. 이것이 이 실패 모드에서 가장 비용이 많이 드는 단일 특성입니다.

작동 원리: 스트리밍 중단의 기술적 실체

Claude의 API는 **서버 전송 이벤트 (Server-Sent Events, SSE)**를 사용하여 응답을 스트리밍합니다. 즉, 긴 수명을 가진 HTTP 연결을 통해 토큰이 한 번에 하나의 청크(chunk)씩 클라이언트로 흐릅니다. 이는 체감 속도 측면에서는 훌륭하지만, 신뢰성 측면에서는 최악입니다. 스트리밍 도중 발생하는 어떠한 TCP 중단도 명확한 오류 경계 없이 잘린 출력을 생성합니다. WHATWG server-sent events 명세[7] 자체에서도 연결이 깨끗한 종료 신호 없이 끊길 수 있음을 명시하고 있습니다.

실제 서비스 중단(Outage)과 토큰 스트림 중단의 차이

실제 서비스 중단(True outage)은 HTTP 500 또는 529와 같은 명확한 실패를 반환하므로, 재시도 로직(retry logic)이 작동하고 상황이 계속 진행됩니다. 반면, 토큰 스트림 중단은 훨씬 더 교활합니다. 연결이 응답의 80%를 전달한 후 죽어버립니다. 당신의 코드는 단순히 멈춰버린 200 상태의 스트림을 보게 됩니다. Claude가 완료한 것일까요? 네트워크가 끊긴 것일까요? 토큰 한도(token ceiling)에 도달한 것일까요? 명시적인 처리가 없다면 진정으로 알 수 없으며, 바로 그 모호함 때문에 디버깅 시간이 허비됩니다.

불완전한 응답의 함정: 단 한 번의 스트림 끊김이 어떻게 운영 환경의 장애로 이어지는가

  1

    **클라이언트가 SSE 스트림을 엽니다 → api.anthropic.com/v1/messages**

당신의 앱이 스트리밍이 활성화된 상태로 claude-sonnet-4-20250514를 요청합니다. 긴 수명을 가진 TCP 연결이 열립니다. 지연 시간 예산(Latency budget)이 시작됩니다.

↓

  2
...

수요 측면의 부하(demand-side load)가 발생하면, Anthropic은 부하를 줄이기(shedding) 시작합니다. 일부 스트림은 토큰 생성 도중에 끊깁니다. 클라이언트에는 깨끗한 stop_reason이 전송되지 않습니다.

↓

  3
...

연결이 충분히 깨끗하게 종료되어 클라이언트는 200 상태를 기록합니다. 당신은 답변의 80%를 가졌고, 전달된 토큰에 대한 과금 이벤트도 발생합니다.

↓

  4
...

RAG 파이프라인, MCP 도구 호출(tool call), 또는 Claude Code 세션이 불완전한 데이터를 바탕으로 동작합니다. 확인 응답 없이 데이터베이스 쓰기(database write)가 시작될 수도 있습니다.

↓

  5
...

당신의 모니터링 지표는 정상(green)을 나타냅니다. 하지만 고객은 깨진 응답을 보고 있습니다. 당신은 status.anthropic.com을 확인하기도 전에 자신의 코드를 디버깅하는 데 23분을 허비합니다.

이 시퀀스가 중요한 이유는, 사람이 알아차리기 전까지 모든 계층(layer)에서 실패가 마치 성공처럼 보이기 때문입니다. 그 간극이 바로 '함정(Trap)'입니다.

왜 '응답 불완전(response incomplete)'이 Claude가 생성하는 가장 기만적인 오류인가

Claude의 API에는 기본 max_tokens 상한선이 있습니다. 이를 Claude가 필요로 하는 길이보다 낮게 설정하면 출력값이 조용히 잘리게(truncated) 되는데, 이는 기술적으로 서버 오류가 아닙. 이는 네트워크 장애와 동일하게 동작하지만, 실제로는 당신의 설정에서 기인합니다. 저는 시니어 엔지니어들이 이것이 Anthropic의 버그라고 확신하며 40분을 허비하는 것을 보았습니다. 버그가 아니었습니다. 더 심각한 것은, Claude Code에서 세션 중간에 발생하는 잘림 현상은 전체 세션을 재시작하지 않고서는 복구할 수 없는 컨텍스트 손실(context loss)을 유발하여 작업 메모리(working memory)를 완전히 지워버린다는 점입니다.

기만적인 사례: 깔끔한 에러 코드(왼쪽)는 재시도 로직(retry logic)을 실행시키지만, 조용한 스트림 끊김(오른쪽)은 깨진 출력물에 대해 200 상태 코드를 반환합니다. 이것이 바로 '불완전한 응답 함정(The Incomplete Response Trap)'의 핵심입니다.

Claude API 오류 유형: 모든 에러 코드의 상세 분석

함정에서 벗어나려면 Claude의 오류 어휘를 유창하게 읽을 수 있어야 합니다. Anthropic의 공식 에러 문서[3]는 'API 오류(API errors)'와 '요청 오류(request errors)'를 구분합니다. 그리고 대부분의 'Claude 다운' 경험은 실제로는 이 두 가지가 혼합된 상태입니다. 문서는 코드에 대해 정확하게 설명하고 있습니다. 다만, 부하(load)가 걸린 상황에서 해당 코드들이 어떻게 동작하는지에 대해서는 덜 친절합니다. 기반이 되는 상태 코드(status codes)는 RFC 9110[8]에 표준화되어 있지만, 529는 Anthropic 전용 확장 코드입니다.

HTTP 400, 429, 500, 529 — 각 코드가 워크플로 (workflow)에 의미하는 바

코드	의미	원인	대응 조치
400	잘못된 / 형식이 잘못된 요청 (Bad / malformed request)	스키마 (Schema) 오류, 또는 부하 상황에서의 검증 (validation) 성능 저하	페이로드 (payload) 점검; 무작정 재시도(retry)하지 말 것
429	속도 제한 (Rate limited)	Anthropic의 부하 차단 (load-shedding) 작동	지터 (jitter)를 포함한 지수 백오프 (Exponential backoff) 적용