ChatGPT, Claude, Grok은 왜 동시에 죽었나? 대규모 AI 장애 뒤의 기술적 이유

2026년 9월 3일 오전(미국 동부) ChatGPT, Claude, Grok이 같은 창에서 쓸 수 없게 됐다. 대략 9:30부터 Grok은 웹, iOS, Android, X에서 「This model is overloaded」를 반환했다. Anthropic은 인프라 문제로 불렀고 Claude 채팅, Claude Code, API가 함께 나빠졌다가 12:15쯤 회복했다. OpenAI 상태 페이지는 11:00쯤부터 ChatGPT와 Codex의 elevated errors라 했고 로그인, 업로드, 음성, 검색, Deep Research, 이미지 생성이 지목됐으며 12:55쯤 완화를 표시했다. 대중 프론트도어 모델의 겹친 정지는 거의 없다. The Verge는 절제했다. 세 곳에서 무엇이 깨졌는지, 관련인지는 불명이라고. 이 글은 「Azure가 했다」를 서명된 RCA로 쓰지 않는다. 공식 타임라인, 공유 클라우드 단서, 캐스케이드를 가르고 당신이 바꿀 곳——오류 JSON, 멀티 벤더 페일오버, 클라우드 모델이 함께 꺼져도 로컬 도구가 남는 이유——로 떨어뜨린다. 이어서 AI JSON 오류 가이드, A2A vs MCP.

9월 3일 타임라인: 각사가 실제로 보고한 것

「공유 사고」를 만들기 전에 각사 상태 페이지에 맞춘다. xAI가 먼저였다. 동부 9:30쯤 Grok은 Android, iOS, 웹에서 동시에 깨졌고 X의 답은 과부하이니 잠시 후 또는 다른 모델을 고르라는 것이었다. 이후 xAI는 모호한 조사 중이 아니라 Memphis 데이터센터에 묶었다. 이 문장은 남겨라. 적어도 한 곳은 전산실 수준 설명을 냈고, 뒤늦은 Azure 서사에 통째로 삼켜지면 안 된다.

Anthropic은 인프라 문제로 인한 부분 장애라고 했다. 소비자 Claude, 개발자 Claude Code, 공개 API가 같은 구간에서 오류가 올랐다. 공개 타임라인은 약 15분 만에 원인을 찾았다고 했고 12:15쯤 회복, 이후 단일 모델에서 짧은 elevated errors가 있었다. OpenAI는 조금 늦다. 10:43–11:00쯤 상태 페이지는 ChatGPT와 Codex의 오류율 상승과 성능 저하를 썼다. 영향은 채팅 창만이 아니라 로그인, 파일 업로드, 음성, 검색, Deep Research, 이미지 생성이 열거됐다. 그날 OpenAI는 새 모델 Astra를 예고 중이어서 기본 트래픽이 이미 높았다. 완화 후 12:55쯤 복구로 표시됐다.

같은 오전 Claude와 Grok에 의존하는 Cursor 같은 코딩 에이전트도 장애를 냈다. 네 번째 프론티어 모델이 죽은 것이 아니라 다운스트림 런타임이 백엔드를 둘 잃었다. Gemini는 민원 급증이 있었으나 공식 확인 장애는 없다. Ars Technica가 네 이름을 겹친 것은 민원 곡선이 겹쳤기 때문이지 Google이 사고 통보를 내서가 아니다. 겹침은 하나의 근인이 아니다. DownDetector 급증은 공식 확인이 아니다.

공식 사실, 인프라 단서, 근인으로 쓰면 안 되는 추측

「왜 동시인가」 전에 증거를 세 층으로 가른다. 첫째는 공식이다. 세 곳 모두 자기 창의 장애를 확인했다. Grok은 Memphis, Claude는 infrastructure issue, ChatGPT / Codex는 elevated errors. 이 글을 쓰는 시점까지 공동 RCA도, 서로를 지목한 일도 없다. The Verge 업데이트는 복구와 통일 설명이 없다는 것만 확인했다.

둘째는 인프라 단서다. 여러 매체와 모니터링 집계는 비슷한 시간에 Microsoft Azure 민원 급증을 적었다. 일부는 태평양 시간 약 10:26(동부 약 13:26) Azure East US ingress 실패를 썼다. East US는 기업 AI 트래픽의 주 지역이고 OpenAI, Anthropic, xAI 모두 Azure에서 의미 있는 추론과 네트워크를 돌린다. 입구, 로드밸런싱, 지역 라우팅이 흔들리면 앱이 달라도 502, 타임아웃, 로그인 실패로 함께 보인다. 「동시에 보인」 이유는 될 수 있다. 그래도 단서이지 서명된 RCA가 아니다.

셋째는 설계에 쓰면 안 되는 추측이다. Azure가 경쟁을 고의로 조였다, 세 회사가 합동 점검을 했다, Memphis와 East US를 한 사고로 확정했다. 공개 자료는 이를 뒷받침하지 않는다. 남는 공학 문장은 둘이다. 첫째, 대중 AI의 운명은 이미 소수 클라우드 지역과 소수 입구에 묶여 있다. 둘째, 첫 브랜드가 쓰러진 뒤 사용자 전환과 클라이언트 재시도는 다음 전산실이 멀쩡해도 다음 브랜드로 부하를 민다.

공유 클라우드와 입구: 왜 「동시」로 보였나

2026년 프론트도어 모델은 세 회사, 세 제품, 세 Tokenizer로 보인다. 아래에서는 계정, 지역, GPU 쿼터, 글로벌 anycast 입구, 신원, 계량을 자주 공유한다. 학습은 자체 전산실이어도 된다. 추론은 사용자 가까이, 탄력, 조달이 가능해야 해서 Microsoft Azure가 가장 흔한 공약수가 됐다. Gemini가 거의 안 죽은 가장 깨끗한 설명은 「Google 모델이 더 안정」이 아니다. 주 경로가 Google Cloud이고 같은 East US 입구를 다투지 않았다는 사실이다.

층	깨지면 무엇이 보이나	세 곳이 함께 맞나
가중치 / GPU 클러스터	특정 모델 과부하, 특정 스냅샷 500	보통 아니다. 진짜로 같은 전산실을 쓰지 않는 한
지역 네트워크 / ingress	로그인 실패, 사이트 전체 타임아웃, API와 웹이 함께 죽음	그렇다. 공유 지역에서 가장 「동시」로 보이는 층
신원 / 쿼터 제어면	연결은 되나 못 보낸다. 토큰 갱신이 죽는다	그렇다. 제어면은 데이터면보다 더 집중된다
클라이언트 재시도 + 사용자 전환	둘째, 셋째 브랜드가 갑자기 맞는다	그렇다. 근인이 달라도 겹친다

그래서 「동시 장애」는 세 Transformer가 한꺼번에 계산이 붕괴한 언어가 아니라 입구와 제어면의 언어인 경우가 많다. ChatGPT가 Codex, 업로드, 음성, Deep Research를 함께 적은 것은 공유 게이트웨이 또는 신원 층 고장에 가깝다. Claude가 채팅, Claude Code, API를 하나의 infrastructure issue에 묶은 것도 같은 신호다. 제품 이름은 많고 입구는 적다. 공식 RCA를 기다리지 않아도 설계는 바꿀 수 있다. 입구 층은 지역 단위로 함께 실패한다고 가정하면 충분하다.

캐스케이드, 재시도 폭풍, Memphis

공유 클라우드는 「왜 겹치나」를 설명하고, 캐스케이드는 「둘째, 셋째가 왜 더 참혹한가」를 설명한다. ChatGPT가 불통이면 다음 기본 동작은 대기가 아니라 Claude나 Grok을 여는 것이다. 수천만 세션이 몇 분 만에 벤더를 바꾸는 것은 이미 다쳤을지 모르는 공유 입구에 대한 돌발이다. 클라이언트와 Agent 프레임은 더 나쁘다. 타임아웃 즉시 재시도, 키 회전, 모델 교체, jitter 없고 「인프라이니 치지 마라」 신호도 없다. 고전적 재시도 폭풍이다. 첫 벤더의 장애는 둘째 로그에서 「이유 없는 과부하」가 된다.

Grok의 Memphis 설명은 별도 칸에 남겨라. xAI는 자체 데이터센터에 묶었고 시간도 ChatGPT 상태 페이지보다 이르다. 독립 사고가 겹친 것일 수도, 더 넓은 전력·상류 연결과 관련됐을 수도 있다. 공동 타임라인이 나오기 전에는 병렬로 쓰고 합치지 마라. 공학적 함의는 오히려 분명하다. 페일오버 명단이 「OpenAI가 죽으면 xAI」뿐이라면 그날 아침 그 정책은 먼저 Grok에서 죽는다.

Cursor의 장애는 그날 캐스케이드의 제품 형태다. 에디터는 모델을 학습하지 않는다. Claude와 Grok을 런타임으로 쓴다. 상류가 흔들리면 완성, Agent, 도구 호출이 함께 멈춘다. 2026년 내부 Agent 대부분이 이렇게 보인다. MCP 도구, A2A 작업, 자체 HTTP JSON, 마지막은 두세 클라우드 모델로 떨어진다. 단일 점은 업무 코드가 아니라 기본 model 필드다. 배경은 MCP와 JSON Schema, 무상태 MCP.

제어면이 모델 자체보다 더 약하다

GPU 클러스터가 건강해도 사용자 요청은 성공하지 않는다. 로그인, 업로드, 음성, 검색이 함께 실패하면 깨진 것은 게이트웨이, 신원, 오브젝트 스토리지 입구, 공유 에지이지 한 decoder가 아니다. 화면의 「모델 과부하」는 종종 가짜 증상이다. 진짜 과부하는 입구 연결 수, 인증서 검사, 토큰 서비스다. 상태 페이지는 늦다. 사용자는 먼저 DownDetector 급증을 본다. 분리할 때는 모델 이름만 보지 마라. 오류 봉투의 httpStatus, code, retryable 여부다.

벤더의 흩어진 오류를 하나의 봉투로 정규화하는 편이 「AI가 실패했다」 토스트보다 쓸모 있다. 아래 JSON은 어느 곳인지, 무슨 상태인지, 재시도 가능한지만 말한다. 업무 층은 각사 원문을 파싱하지 마라. 원문은 로그로. 봉투는 차단기로.

{
  "ok": false,
  "provider": "openai",
  "httpStatus": 503,
  "code": "elevated_errors",
  "retryable": true,
  "occurredAt": "2026-09-03T15:00:00Z",
  "message": "ChatGPT and Codex are returning elevated errors"
}

같은 오전에 OpenAI elevated errors, Anthropic infrastructure issue, xAI overloaded가 동시에 올 수 있다. 필드 이름은 다르다. 결정은 같아야 한다. 재시도 가능은 냉각, 불가는 벤더 전환, Schema에 안 맞는 봉투는 경실패. HTML 오류 페이지를 정규식으로 긁지 마라. 실제 실패 샘플을 JSONVue에 넣어라. 포맷으로 필드를 보고, 검증으로 문법을 보고, JSON Schema로 필수 키를 고정하고, Diff로 세 봉투가 무엇을 빼는지 본다. 클라우드 생성 층이 꺼져도 로컬 파싱은 돈다. 브라우저 안 도구의 가치가 거기 있다.

Agent / JSON 파이프라인: 멀티 벤더는 슬로건이 아니다

슬라이드의 「멀티 클라우드」는 그날 아침 도움이 안 된다. 유효한 멀티 벤더는 런타임 정책이다. 주 경로, 명시적 fallback 순서, 차단 임계, 모든 벤더가 채울 하나의 오류 봉투. 같은 벤더를 스무 번 치지 마라. fallback을 「살아 있는 임의 선택」으로 구현하지 마라. Gemini가 그날 쓸 수 있었던 것은 같은 입구 운명에 있지 않아서다. 그래서 예비 명단에는 주 경로가 다른 한 곳이 있어야 하며, Azure East US에 모두 떨어지는 세 이름이 아니다.

정책 자체를 JSON으로 두고 업무 Schema와 버전을 분리하라. 아래 설정은 모델 상표를 신경 쓰지 않는다. 먼저 누구를 치는지, 실패 후 누구인지, 어느 오류율에서 끊는지, 봉투의 어느 키가 단단한 문인지다.

{
  "policy": "failover",
  "primary": "openai",
  "fallbacks": ["anthropic", "xai", "google"],
  "circuitBreaker": {
    "errorThreshold": 0.3,
    "windowSeconds": 60,
    "cooldownSeconds": 120
  },
  "errorEnvelope": {
    "required": ["ok", "provider", "code", "retryable"]
  }
}

빠지기 쉬운 점. 도구 인자 JSON과 최종 답 JSON은 다른 홉이다. MCP tools/call, OpenAI function arguments, 자체 HTTP body는 모델이 사라졌을 때 다른 모양으로 실패한다. 「모델 불가」와 「인자가 Schema 불합」을 같은 토스트로 만들면 사후는 잘못된 손잡이를 돌린다. 로컬 검증은 여전히 필요하다. 이유는 Structured Output과 같다. 모양 층과 가용성 층은 다르다. 클라우드가 돌아오면 그날 아침 실패 봉투를 픽스처로 남겨라. 회고 메일보다 낫다.

자주 묻는 질문

Microsoft가 경쟁을 조였나?

공개 자료는 그 읽기를 뒷받침하지 않는다. 더 가까운 설명은 공유 지역 입구와 캐스케이드 트래픽이다. Azure 민원 급증은 단서이지 세 곳이 공동 서명한 근인이 아니다. 설계는 「입구 층은 지역 단위로 실패한다」에 두고 동기 창작에 두지 마라.

당장 자체 모델을 학습하고 클라우드를 떠나야 하나?

층이 다르다. 그날 보여 준 것은 추론 입구와 벤더 집중이지 「천억 모델을 직접 학습하라」가 아니다. 대부분의 팀은 주 경로가 다른 예비, 차단기, 통일 오류 봉투가 더 급하다. 자체 학습은 모든 트래픽을 같은 지역 ingress에 넣는 문제를 풀지 않는다.

Gemini가 괜찮았으면 더 신뢰할 수 있나?

그날의 주 경로가 같은 공유 운명에 있지 않았다는 것만 증명한다. Google Cloud에도 지역 사고는 있다. 한 번의 겹침을 모델 품질 순위로 읽지 마라. 의존 그래프로 읽어라. 예비는 정말 예비인가.

내일 최소로 무엇을 바꾸나?

하루에 끝낼 셋. 모든 모델 호출에 통일 오류 봉투를 씌운다. 주 경로 실패 후 다른 클라우드의 모델로 넘기고 같은 벤더의 다른 스냅샷으로 넘기지 않는다. 재시도에 jitter와 차단기를 붙여 스스로를 다음 장애의 공격 트래픽으로 만들지 않는다. 세 벤더 실패 샘플을 그 봉투 Schema와 JSONVue에서 맞춘다.

요약과 다음 단계

9월 3일은 한 줄로 눌린다. 대중 AI는 이미 공유 클라우드 위의 입구 서비스다. 상표는 다르다. 운명은 같은 지역 경로에서 겹칠 수 있다. Memphis, East US ingress, 사용자 전환은 세 줄기일 수도, 맞닿을 수도 있다. 공식 RCA 전에는 음모로 뭉개지 말고, 무관한 불운으로도 두지 마라.

다음 단계는 구체적이다. 실패를 JSON으로 모으고, 페일오버를 정책으로 쓰고, 차단 임계를 재생 가능한 설정으로 둬라. 모델은 돌아오고 상태 페이지는 초록이 된다. 다음 지역 입구 흔들림에 Agent가 다시 전부 침묵할지는 지금 "model": "유일한 한 곳"이 코드에 박혀 있는지에 달렸다.