ChatGPT·Claude·Grok이 같은 날 멈춘 이유: 확인된 사실과 추정의 경계

2026년 9월 3일, 주요 생성형 AI 서비스들이 몇 시간 사이 잇따라 접속·응답 문제를 겪었다. OpenAI의 ChatGPT와 Codex, Anthropic의 Claude 제품군, xAI의 Grok에서 사용자 장애가 확인됐다. 다만 여기서 확실히 말할 수 있는 범위는 “장애 시점이 겹쳤다”는 것까지다. 공개된 자료는 각기 다른 원인 설명을 제시하며, 단 하나의 공통 장애가 있었다고 입증하지는 않는다. 334148

무엇이 언제 발생했나

사업자별 상태 공지와 외부 보도의 시각 기준이 달라 정확한 타임라인에는 일부 차이가 있다. 그래도 사용자들이 동시 장애로 인식한 이유는 충분히 확인된다.

• Grok: xAI의 장애 기록은 13:30 UTC에 시작해 17:05 UTC에 끝난 것으로 보도됐다. xAI는 이후 테네시주 멤피스의 컴퓨팅 센터 장애가 서비스 중단으로 이어졌다고 설명했다. 48
• Claude: Anthropic은 Claude 모델 전반과 Claude.ai, API, Claude Code, Claude Cowork에서 요청 오류가 증가했다고 공지했다. 장애는 약 3시간 뒤인 16:16 UTC까지 해소됐다. 104148
• ChatGPT·Codex: OpenAI는 07:43 PT부터 내부 라우팅 오류로 일부 사용자가 여러 플랫폼에서 ChatGPT와 Codex를 이용하지 못했다고 밝혔다. 약 08:17 PT에 해결책을 적용한 뒤 복구 상태를 모니터링했다. 41

이용자들은 로그인 실패, 대화 불러오기 불가, 프롬프트 실패, 웹·앱 접속 문제 등을 호소했다. 장애 신고 집계 서비스인 다운디텍터 기준으로 인도 표준시(IST) 오후 8시 무렵 ChatGPT 관련 신고는 4만 3,000건을 넘었다. Claude는 일반 사용자용 서비스뿐 아니라 개발자 도구에도 영향을 미쳤다. 2339

각사가 밝힌 원인은 달랐다

공개된 원인 설명을 보면, 이 사건을 ‘AI 서비스 전체의 단일 장애’로 단정하기는 어렵다.

OpenAI: 회사 대변인은 ChatGPT와 Codex 문제를 OpenAI 인프라 내부의 라우팅 오류라고 설명했다. 41

Anthropic: 공개 상태 정보는 Claude의 문제를 인프라 이슈로 규정했고, 여러 모델과 서비스에서 오류 증가가 있었다고 확인했다. 다만 어떤 세부 구성 요소가 실패했는지는 공개 자료에 나오지 않았다. 3948

xAI: 사후 보도에 따르면 xAI는 Grok 장애를 멤피스 컴퓨팅 센터의 장애와 연결 지었고, 영향을 받은 컴퓨팅 파트너들에게 사과했다. 48

이 설명들은 공유 의존성이 전혀 없었다는 뜻은 아니다. 그러나 공통된 단일 원인을 뒷받침하는 근거도 제공하지 않는다.

Azure나 다른 공유 인프라가 원인이었나

제공된 공개 자료만으로는 Microsoft Azure, 네트워크 사업자, CDN(콘텐츠 전송 네트워크), 인증 서비스 등 특정 공통 공급자가 9월 3일의 모든 장애를 일으켰다고 확인할 수 없다.

당시 보도는 세 기업에 클라우드 서비스를 제공하는 Azure를 주목할 지점으로 언급했다. 그러나 이는 인과관계의 증거가 아니다. 42 사용자 신고를 기반으로 측정된 장애 시간대가 겹친다고 해서, 동일한 기술적 사고 기록이 존재한다는 뜻은 아니다.

따라서 현재로서 타당한 결론은 명확하다. 공유 인프라가 공통 원인이었는지는 확인되지 않았다. Azure의 특정 리전 장애가 세 사건 모두를 초래했다는 주장은 각사의 직접 확인이나 기술 사후 분석 보고서가 나오기 전까지 사실로 받아들여서는 안 된다.

Anthropic의 Colossus 1 접근이 Claude 장애를 설명하나

현재 자료로는 Anthropic이 xAI/SpaceXAI의 Colossus 1 시설을 어느 범위에서 이용했는지, 또 장애 당시 Claude의 실제 서비스 경로가 해당 설비에 의존했는지를 확정할 수 없다. 멤피스 장애가 Grok에 영향을 줬다는 사실만으로 Claude 장애의 원인까지 증명되지는 않는다. 48

신뢰성 분석에서는 이 구분이 중요하다. 상업적 컴퓨팅 계약이 사실이라고 해도, 장애가 발생한 바로 그 시점에 사용자 대상 서비스가 해당 용량에서 운영되고 있었다는 증거가 되지는 않는다.

9월 7일 인도에서 제기된 ChatGPT 문제는 무엇이었나

9월 7일 별도 보도에서는 콘텐츠 생성 기능을 중심으로 ChatGPT 문제 제보가 나왔고, 일부 이용자는 브라우저와 앱 문제도 겪었다고 전했다. 한 보도는 약 261건의 이용자 신고를 집계했으며, 신고의 대부분은 콘텐츠 생성 관련 문제였다고 했다. 19

하지만 이 자료만으로 인도 전역의 지속적인 장애, 확정된 원인, 또는 9월 3일 사건과의 연결고리를 확인할 수는 없다. 외부 모니터링 서비스는 이날 03:07 UTC에 비정상적인 응답 시간이나 오류 코드 없이 ChatGPT에 접속할 수 있었다고 기록했다. 이는 전국적·연속적 장애라기보다 부분적, 간헐적 또는 지역별 편차가 있는 문제일 가능성과 부합한다. 22

기업에 주는 교훈: 멀티벤더가 곧 복원력은 아니다

이번 장애는 고객 지원, 소프트웨어 개발, 리서치, 문서 처리, 에이전트 업무처럼 AI에 의존하는 흐름이 얼마나 빠르게 멈출 수 있는지를 보여준다. 여러 AI 서비스에 구독하는 것은 특정 공급자 한 곳의 장애 위험을 줄일 수 있다. 하지만 브라우저, 인증, 네트워크, 연동 서비스, 클라우드 계층 등을 함께 쓰는 경우까지 막아주지는 못한다.

더 견고한 AI 업무 체계를 위해서는 다음이 필요하다.

• 수동 대체 절차와 영속적 작업 대기열: 중요한 요청이 실패와 함께 사라지지 않도록 보존한다.
• 공급자 장애 전환: 적합한 작업은 다른 모델 사업자로 넘기되, 상관된 동시 장애 가능성은 별도로 고려한다.
• 방어적인 API 처리: 제한된 타임아웃, 지수 백오프 재시도, 서킷 브레이커, 멱등성 작업 처리를 적용해 일시 장애가 중복 실행으로 번지지 않게 한다.
• 성능 저하 모드: 최고성능 모델을 쓸 수 없을 때도 무엇을 계속할지 정한다. 규칙 기반 분류, 캐시된 답변, 처리 지연, 사람의 검토가 예가 될 수 있다.
• 독립 모니터링과 장애 기록: 공급자 상태 페이지와 자체 점검을 함께 보고, 어떤 사업자·모델·연동 구간에서 실패했는지 로그를 남긴다.

핵심은 동시에 일어난 모든 장애에 숨은 공통 원인이 있다고 단정하는 데 있지 않다. 그런 가능성까지 포함해 업무를 설계하고, 다음 장애가 오기 전에 대체 경로가 실제로 작동하는지 검증하는 데 있다.