Claude 5시간 오류, 에이전트 백업 경로를 묻는 장애

AI 요약

• 무슨 일: Claude Status는 2026년 6월 2일 Opus 4.6 elevated errors incident를 06:04-11:49 UTC로 기록했습니다.
  • 상태 업데이트는 06:39 identified, 10:42 monitoring, 11:49 resolved 순서로 이어졌고 전체 창은 5시간 45분입니다.
• 개발자 영향: Claude API, Claude.ai, Claude Code 의존 작업은 단일 모델 장애를 retry와 fallback 정책으로 흡수해야 합니다.
• 운영 쟁점: 실패 시점의 plan, diff, 로그, 승인 상태를 checkpoint로 남겨야 재실행 비용이 줄어듭니다.
• 주의점: 공식 페이지는 원인 세부를 공개하지 않았습니다. 시간표와 사용자 영향 범위만 분리해 읽어야 합니다.

Anthropic의 Claude Status 페이지가 2026년 6월 2일 Claude Opus 4.6 elevated errors incident를 기록했습니다. 상태 페이지의 시간표는 06:04 UTC 조사 시작, 06:39 원인 식별, 09:33 수정 작업 지속, 10:42 수정 적용 후 모니터링, 11:49 해결입니다. 전체 공개 incident 창은 5시간 45분입니다.

이 사건은 "Claude가 잠시 느렸다"는 소비자 서비스 장애로만 읽기 어렵습니다. Claude API와 Claude Code를 쓰는 팀에서는 모델 오류가 대화 중단보다 더 긴 꼬리를 남깁니다. PR을 만들던 에이전트는 half-written diff를 남길 수 있고, 데이터 분석 agent는 같은 query를 재실행할 수 있으며, 승인 대기 중이던 shell command는 사용자가 돌아왔을 때 이미 문맥을 잃을 수 있습니다.

출처: Claude Status.

같은 날짜의 Reddit r/ClaudeAI 자동 알림은 06:39 UTC에 "Claude Opus 4.7, 4.6 and Sonnet 4.6" across incident를 기록했고, 10:42 UTC에는 Opus 4.6 elevated errors 업데이트를 별도로 전달했습니다. 이 게시물들은 사용자 토론보다 상태 페이지 변화를 보존하는 자동 아카이브에 가깝습니다. 그래도 모델별 장애가 개발자 커뮤니티에서 추적 가능한 사건이 됐다는 점은 확인됩니다.

TechRadar는 같은 날 Claude Status의 partial outage와 Opus 4.6 elevated errors 업데이트를 보도했습니다. 기사에는 Claude.ai가 느리거나 "still working on it" 상태에 머무른 사용자 체감도 함께 언급됩니다. 이 체감은 API error rate 숫자와 다릅니다. 챗 UI에서는 hang으로 보이고, agent runner에서는 timeout, retry, incomplete transcript로 남습니다.

상태 페이지가 공개한 정보는 장애 원인을 설명하지 않습니다. 따라서 GPU 용량, 특정 모델 배포, routing bug 같은 원인 추정은 이 글의 범위를 벗어납니다. 확인 가능한 사실은 6월 2일 06:04-11:49 UTC incident 창과 상태 단계입니다. 같은 기간 사용자와 자동 상태 알림은 Opus 4.6, Opus 4.7, Sonnet 4.6 이름을 함께 관찰했습니다.

개발팀이 먼저 점검할 부분은 retry 정책입니다. LLM API 호출은 HTTP 500이나 timeout만 보는 일반 API retry와 다릅니다. 같은 prompt를 다시 보내면 token 비용이 다시 발생하고, tool call이 포함된 경우 외부 시스템에 같은 작업을 두 번 실행할 수 있습니다. 예를 들어 issue triage agent가 Jira ticket을 만들던 중 모델 오류를 만나면 단순 retry는 중복 ticket을 만들 수 있습니다.

두 번째 점검선은 checkpoint입니다. 장시간 코딩 에이전트는 plan, 현재 branch, 적용한 diff, 통과한 test, 실패한 command를 단계별로 저장해야 합니다. 사용자 승인 상태도 같은 checkpoint에 남아야 합니다. 모델이 20분 뒤 돌아왔을 때 "처음부터 다시"가 아니라 "마지막으로 검증된 diff부터 재개"가 가능해야 합니다. Claude Code, Codex, Gemini CLI 같은 도구를 교차 사용하는 팀이라면 checkpoint format을 특정 vendor transcript에만 묶어두지 않는 편이 낫습니다.

세 번째는 fallback 모델의 기준입니다. 장애가 발생했을 때 Opus 4.6에서 Sonnet 4.6이나 다른 provider 모델로 넘길 수 있다고 해서 모든 작업을 즉시 넘겨도 되는 것은 아닙니다. 코드 수정, migration 생성, 보안 리뷰, 고객 데이터 분석은 모델별 tool permission과 context window 차이를 가집니다. policy와 reasoning 품질 차이도 있습니다. fallback은 "아무 모델이나 계속 실행"이 아니라 task class별 허용 목록으로 설계해야 합니다.

• 읽기 전용 분석: 다른 모델로 재시도할 수 있지만 결론 drift와 비용 증가를 기록해야 합니다.
• 파일 수정 중: diff checkpoint 후 재개해야 하며 partial edit 충돌을 먼저 확인해야 합니다.
• 외부 API 호출 후: idempotency key를 확인하지 않으면 중복 ticket, 결제, 알림이 생길 수 있습니다.
• 승인 대기 중: 사람에게 상태 요약을 전달하고 권한 경계와 audit trail 손실을 막아야 합니다.

에이전트 제품을 만드는 팀에는 status page polling도 기능 요구사항이 됩니다. 사용자가 "왜 멈췄나"를 묻기 전에 provider status, 모델 이름, request id, retry count, 마지막 successful step을 화면에 보여줘야 합니다. 장애가 해결된 뒤에도 같은 작업을 자동 재개할지, 사람에게 review를 요청할지, fallback 모델로 plan만 다시 세울지 선택지가 필요합니다.

운영팀은 SLO를 모델 provider의 uptime 숫자와 동일하게 둘 수 없습니다. 실제 사용자 경험은 provider availability에 queue 처리량, rate limit, token budget, tool sandbox 상태, repo lock 상태가 곱해져 결정됩니다. Claude incident가 5시간 45분이었다고 해서 모든 agent 작업이 5시간 45분 멈춘 것은 아닙니다. 반대로 상태 페이지가 resolved로 바뀐 뒤에도 사용자 큐와 실패 재시도는 더 오래 남을 수 있습니다.

상태 페이지 연동은 단순 배너보다 세밀해야 합니다. Anthropic 상태 페이지는 incident 단계를 investigating, identified, monitoring, resolved로 나눠 기록했습니다. 에이전트 제품은 이 단계를 내부 상태와 매핑할 수 있습니다. investigating 단계에서는 새 장시간 작업을 보류하고, identified 단계에서는 이미 시작한 작업만 checkpoint 기준으로 이어가며, monitoring 단계에서는 낮은 위험 작업부터 재개하는 방식입니다.

작업 큐를 운영하는 팀은 "모델 장애 중 새 작업을 받을 것인가"를 별도로 정해야 합니다. 사용자가 200개 repository에 보안 패치를 요청한 뒤 provider 오류가 시작되면, queue는 단순 FIFO로 밀어붙이면 안 됩니다. 읽기 전용 scan, pull request 작성, 배포 파일 수정, 외부 ticket 생성은 side effect가 다릅니다. queue metadata에 task class, 외부 write 여부, idempotency key, 승인 필요 여부가 들어가야 장애 중 정지와 재개가 가능합니다.

관측성도 모델 호출 성공률 하나로 끝나지 않습니다. agent runner는 prompt id, model name, provider status snapshot, tool call id, branch name, commit hash, sandbox id를 같은 trace에 묶어야 합니다. 그래야 6월 2일 같은 incident 이후 "이 PR은 장애 중 fallback 모델이 만든 diff인가"를 reviewer가 확인할 수 있습니다. 단순 로그 검색으로는 모델 장애와 코드 변경의 인과관계를 나중에 복원하기 어렵습니다.

고객에게 보여줄 문구도 제품 신뢰에 영향을 줍니다. "AI가 생각 중입니다"라는 메시지는 모델 오류와 장시간 reasoning을 구분하지 못합니다. 더 나은 UI는 provider status가 degraded인지, 내부 retry가 몇 회 남았는지, 사용자가 지금 취소하면 어떤 diff와 log가 보존되는지 알려줍니다. Claude.ai 같은 일반 챗 UI에서는 hang이 답답함으로 끝날 수 있지만, 업무 agent UI에서는 취소 버튼 하나가 audit trail과 연결됩니다.

사후 리뷰에서는 provider 책임과 내부 설계 책임을 분리해야 합니다. 6월 2일 incident 자체는 Anthropic의 모델 서비스 문제로 기록됐습니다. 그러나 중복 ticket, branch 충돌, token 폭증, 잘못된 fallback 권한이 내부 제품에서 발생했다면 그것은 agent 운영 설계 문제입니다. postmortem에는 provider incident URL, 내부 영향 시간, 실패한 retry policy, 사용자에게 노출된 message, 수동 복구 작업 시간을 나눠 적는 편이 좋습니다.

문서화 기준도 바뀝니다. 일반 API 장애 runbook은 보통 status page 확인, retry 간격 조정, customer support 공지로 끝납니다. 에이전트 runbook에는 "작업 중인 branch를 lock할 것인가", "partial diff를 PR draft로 남길 것인가", "fallback 모델에게 기존 transcript를 어느 범위까지 넘길 것인가"가 들어가야 합니다. 이 항목들은 모델 품질 평가가 아니라 업무 시스템의 복구 절차입니다.

팀 단위 도입에서는 계약과 보안 검토에도 같은 질문이 들어갑니다. vendor status page가 resolved로 바뀌었을 때 내부 SLA clock도 바로 멈추는지, fallback provider로 prompt와 code context가 넘어갈 수 있는지, 장애 중 생성된 log를 얼마 동안 보관하는지 확인해야 합니다. Claude incident가 남긴 실무 체크리스트는 provider 선택표보다 운영 정책 문서에 더 가깝습니다.

이 문제는 비용 통제와도 이어집니다. 장애 중 aggressive retry를 걸면 실패한 요청에도 token 또는 request 비용이 붙을 수 있고, 성공한 뒤 중복 실행을 정리하는 사람의 시간이 들어갑니다. fallback 모델을 쓰면 단가가 낮아질 수도 있지만, 더 긴 prompt와 검증 step이 필요하면 전체 비용은 줄지 않습니다. AI agent 운영 비용은 모델 가격표보다 실패 경로의 재실행 횟수에서 커질 때가 많습니다.

보안팀 관점에서는 장애 시 fallback이 권한 상승 통로가 되지 않아야 합니다. 평소에는 Opus 4.6에만 허용하던 repository write 권한을 장애 중 다른 모델에 자동으로 넘기면 policy boundary가 바뀝니다. fallback은 provider 교체가 아니라 permission profile 교체이기도 합니다. 코드 작성 모델, review 모델, shell 실행 모델을 나눈 조직이라면 장애 정책도 그 경계를 따라가야 합니다.

Claude의 6월 2일 incident는 공식 원인 분석이 공개된 대형 사후 보고서는 아닙니다. 그래서 사건 자체보다 상태 페이지가 남긴 시간표가 더 중요합니다. 06:04에 조사가 시작되고 06:39에 식별됐으며 10:42에 monitoring으로 넘어간 278분 동안, agent runner는 어떤 화면과 로그를 사용자에게 보여줬어야 하는지 묻는 재료가 됩니다.

개발자가 오늘 바로 확인할 수 있는 질문은 네 가지입니다. 첫째, 모델 오류가 나면 마지막 tool call과 외부 side effect를 구분해 저장하는가. 둘째, 같은 작업을 재시작할 때 idempotency key나 branch checkpoint가 있는가. 셋째, fallback 모델은 작업 종류별로 허용돼 있는가. 넷째, provider status와 내부 queue 상태를 사용자에게 같은 화면에서 보여주는가.

이번 장애가 Claude만의 특수 사례라는 결론은 성급합니다. OpenAI, Google, Anthropic, Azure, AWS 같은 AI provider는 상태 페이지를 운영합니다. frontier model 서비스는 배포와 routing, capacity, abuse filtering, billing, tool integration이 함께 움직입니다. 에이전트가 제품 안에서 더 오래 일할수록 모델 장애는 "외부 API가 가끔 실패한다"가 아니라 workflow design의 일부가 됩니다.

따라서 이번 사건의 실무 결론은 provider를 바꾸라는 말이 아닙니다. 단일 provider, 단일 모델, 단일 transcript에 모든 실행 상태를 맡기는 설계를 줄이라는 쪽에 가깝습니다. Claude Status의 5시간 45분 창은 AI 에이전트 제품이 사용자에게 약속해야 할 범위를 숫자로 보여줬습니다. 답변 품질만큼이나 멈춘 뒤 어디서 다시 시작하는지가 제품 품질이 됩니다.