가장 신중한 결론부터 말하면, ChatGPT·Codex, Claude, Grok에서 비슷한 시간대에 오류가 발생한 것은 사실이다. 그러나 공개된 기록은 세 서비스가 하나의 인프라 장애로 연쇄 마비됐다는 결론까지 뒷받침하지 않는다.

각 사업자가 밝힌 원인은 서로 다르다. Grok은 멤피스 컴퓨트 센터 장애와 연결됐고, OpenAI는 ChatGPT·Codex의 원인을 라우팅 오류로 설명했다. Claude는 오류 증가와 복구 사실은 확인됐지만, 세부 근본 원인은 공개되지 않았다. 즉, 장애 시간의 겹침은 확인됐지만 공통 원인은 입증되지 않았다.

공급자별로 확인된 사실

Grok: 멤피스 컴퓨트 센터 장애는 확인

SpaceXAI는 Grok 문제가 멤피스 컴퓨트 센터의 장애 뒤에 발생했다고 밝히고, 영향을 받은 ‘컴퓨트 파트너’에게도 사과했다. 보도에 따르면 Grok 장애는 태평양시간(PT) 오전 6시 30분께 시작돼 3시간 이상 이어진 뒤 복구됐다. 3941

이는 멤피스 시설에서 사건이 발생했고 Grok 외에도 영향이 있었음을 보여주는 직접적인 근거다. 다만 공개 자료에는 영향을 받은 파트너가 누구인지, 구체적인 고장 방식이 무엇인지, 외부 서비스 가운데 어떤 서비스가 이 시설을 사용했는지는 나오지 않는다.

ChatGPT·Codex: OpenAI가 확인한 라우팅 오류

OpenAI는 9월 3일 태평양시간 오전 7시 43분경 시작된 라우팅 오류 때문에 일부 사용자가 여러 플랫폼에서 ChatGPT와 Codex를 이용하지 못했다고 밝혔다. 회사는 오전 8시 17분경 해결책을 적용한 뒤 복구 상황을 계속 모니터링했다고 설명했다. 39

이는 OpenAI 내부 측의 라우팅 문제를 뒷받침하는 설명이다. 반대로 멤피스 사건이 OpenAI 장애를 일으켰다는 근거는 아니다.

Claude: 오류 증가는 확인, 세부 원인은 비공개

Anthropic 상태 페이지는 여러 Claude 모델에서 오류가 늘어났으며, 영향이 태평양시간 오전 9시 16분(UTC 16시 16분)에 종료됐다고 기록했다. 당시 보도에서는 인프라 문제로 인한 부분 장애로 설명됐다. 2833

하지만 제공된 공개 자료에는 Claude 장애의 상세 근본 원인이 나오지 않으며, 멤피스 시설과 연결된다는 증거도 없다. 따라서 현 시점에서 타당한 결론은 Claude에서도 실제 장애가 있었고 해결됐지만, 원인은 공개 정보만으로 특정할 수 없다는 것이다.

시간이 겹쳤다고 원인이 같은 것은 아니다

세 서비스가 하나의 시각에 동시에 멈췄다고 보기도 어렵다. Grok은 더 이른 시점에 장애가 시작된 것으로 보도됐고, OpenAI는 오전 7시 43분~8시 17분의 라우팅 오류 대응 시간을 제시했다. Claude의 영향 종료 시각은 오전 9시 16분이다. 3339

이 겹침은 운영 관점에서 중요하다. 여러 AI 서비스를 대안으로 사용하던 고객도 같은 시간대에 선택지들이 함께 흔들릴 수 있었기 때문이다. 하지만 시간적 상관관계는 인과관계가 아니다. 공통 의존성, 트래픽 쏠림, 다른 서비스 장애에 따른 연쇄 효과는 모두 가능한 가설일 뿐, 공급자의 근거나 기술 자료가 나오기 전까지는 사실로 단정할 수 없다.

아직 입증되지 않은 주장들

현재 공개된 증거로는 다음을 확정할 수 없다.

• Grok, ChatGPT·Codex, Claude 전반에 걸친 단일 연쇄 장애
• OpenAI 또는 Anthropic의 프로덕션 추론 워크로드가 멤피스의 영향을 받은 시설에 있었다는 주장
• Azure, Cloudflare 또는 특정 클라우드·CDN·네트워크 사업자가 공통 원인이었다는 주장
• 장애 신고 사이트의 보고 건수를 근거로 한 감사 가능한 실제 영향 사용자 수
• 특정 Cursor 오류, 코딩 에이전트 중단, 후속 업무 실패가 공급자 장애 하나 때문에 발생했다는 주장

Cursor 상태 페이지는 OpenAI 및 Anthropic 모델의 업스트림 오류 증가를 보고했다. 이는 일부 Cursor 사용 사례에서 공급자 측 이슈가 영향을 줬을 가능성을 뒷받침한다. 그러나 실패한 모든 에이전트 실행이나 고객 업무의 원인을 증명하지는 못한다. 통합 설정, 인증, 대기열, 요청 제한, 네트워크, 클라이언트 문제도 별도로 있을 수 있다. 30

진짜 교훈: 멀티 모델이 곧 복원력은 아니다

멤피스 사건에서 언급된 이름 없는 ‘컴퓨트 파트너’는 인프라 의존성이 종종 외부에서 보이지 않는다는 점을 환기한다. 애플리케이션이 여러 모델 사업자의 API를 호출하더라도, 실제로는 다음과 같은 기반을 공유할 수 있다.

• 인증 서비스
• DNS 또는 CDN 경로
• 클라우드 리전과 GPU 호스트
• 모델 게이트웨이
• 코드 호스팅 서비스
• 모니터링·관측 도구
• 외부 도구 연동 백엔드

결국 API 층에서 공급자를 분산했다고 해서 인프라까지 분산된 것은 아니다. 백업 모델 엔드포인트가 있어도, 그 주변의 의존 요소가 같은 장애 시나리오를 견디지 못하면 실질적인 대안이 되기 어렵다.

다시간 AI 공급자 장애에 대비하는 방법

1. 전체 의존성 지도를 만든다

모델 API, 게이트웨이, 클라우드 리전, DNS·CDN, 인증, 벡터 데이터베이스, 대기열, 코드 호스트, 도구 연동, 관측성 스택을 서비스 맵에 기록해야 한다. 확인된 하위 공급자뿐 아니라 아직 알 수 없는 핵심 의존성도 별도로 관리할 필요가 있다.

2. 실제 업무 조건에서 대체 경로를 시험한다

대체 공급자나 소형·로컬 모델을 미리 통합해 두고, 현실적인 프롬프트와 구조화된 출력, 도구 호출, 안전 정책, 처리량 제한, 비용 통제를 적용한 상태에서 장애 전환을 테스트해야 한다. 단순한 데모 요청 성공은 프로덕션 업무를 대신 처리할 수 있다는 증거가 아니다.

3. 에이전트가 안전하게 멈추고 재개하도록 설계한다

타임아웃, 지터를 포함한 제한적 재시도, 서킷 브레이커, 멱등성 키, 영속 체크포인트, 명시적 일시정지·재개 규칙을 적용해야 한다. 되돌릴 수 없는 작업은 사람의 승인을 거치게 하는 편이 안전하다. 장애가 끝난 뒤 에이전트가 배포·구매·티켓 생성·외부 API 호출을 중복 실행하는 대신, 기록된 상태에서 이어서 작업할 수 있어야 한다.

4. 장애 전 ‘저하 운영 모드’를 정한다

모델에 접속할 수 없을 때도 가능한 기능을 문서화해야 한다. 예를 들어 검색, 입력 양식, 규칙 기반 분류, 초안 대기열 적재, 읽기 전용 접근, 수동 담당자 전환, 고객 안내 메시지 등이 있다. 최대 대기열 적체 시간, 수동 처리 가능 물량, 고객 공지 기준, 자율 실행을 중지할 시점도 미리 정해둘 필요가 있다.

5. 공급자 소통과 사고 증거 보존을 체계화한다

공급자 상태 피드를 구독하고, 에스컬레이션 경로, 알림 기준, 사고 후 보고서 요구, 계약상 가능한 범위의 데이터 이동성 조건을 마련해야 한다. 장애 중에는 UTC 타임스탬프, 요청 ID, 응답 헤더, 오류 본문, 트레이스, 라우팅 기록, 에이전트 상태, 대기열 로그, 상태 페이지 캡처를 보존하는 것이 중요하다. 그래야 나중에 업스트림 공급자 장애와 자사 통합 문제를 구분할 수 있다.

6. 중요한 업무일수록 ‘진짜 독립성’을 확보한다

고위험 업무의 대안은 모델 브랜드만 달라서는 부족하다. 공급자, 리전, 클라우드, 네트워크 경로, 인증 의존성, 운영 제어 영역까지 달라야 한다. 같은 게이트웨이 뒤에 있거나 같은 리전에 놓인 두 모델 엔드포인트는 의미 있는 이중화가 아닐 수 있다.

결론

9월 3일의 사건을 ‘전 세계 AI가 한꺼번에 멈춘 사고’나 ‘멤피스발 3사 연쇄 장애’의 증거로 해석해서는 안 된다. 다만 이 사건은 겉으로는 독립적으로 보이는 AI 서비스들이 같은 시간대에 함께 흔들릴 수 있음을 보여준다.

기업이 가져가야 할 태도는 성급한 원인 단정이 아니라, 증거가 확인되기 전에도 안전하게 업무를 지속할 수 있도록 시스템을 설계하는 것이다. 333941

가장 신중한 결론부터 말하면, ChatGPT·Codex, Claude, Grok에서 비슷한 시간대에 오류가 발생한 것은 사실이다. 그러나 공개된 기록은 세 서비스가 하나의 인프라 장애로 연쇄 마비됐다는 결론까지 뒷받침하지 않는다.

각 사업자가 밝힌 원인은 서로 다르다. Grok은 멤피스 컴퓨트 센터 장애와 연결됐고, OpenAI는 ChatGPT·Codex의 원인을 라우팅 오류로 설명했다. Claude는 오류 증가와 복구 사실은 확인됐지만, 세부 근본 원인은 공개되지 않았다. 즉, 장애 시간의 겹침은 확인됐지만 공통 원인은 입증되지 않았다.

공급자별로 확인된 사실

Grok: 멤피스 컴퓨트 센터 장애는 확인

SpaceXAI는 Grok 문제가 멤피스 컴퓨트 센터의 장애 뒤에 발생했다고 밝히고, 영향을 받은 ‘컴퓨트 파트너’에게도 사과했다. 보도에 따르면 Grok 장애는 태평양시간(PT) 오전 6시 30분께 시작돼 3시간 이상 이어진 뒤 복구됐다. 3941

이는 멤피스 시설에서 사건이 발생했고 Grok 외에도 영향이 있었음을 보여주는 직접적인 근거다. 다만 공개 자료에는 영향을 받은 파트너가 누구인지, 구체적인 고장 방식이 무엇인지, 외부 서비스 가운데 어떤 서비스가 이 시설을 사용했는지는 나오지 않는다.

ChatGPT·Codex: OpenAI가 확인한 라우팅 오류

OpenAI는 9월 3일 태평양시간 오전 7시 43분경 시작된 라우팅 오류 때문에 일부 사용자가 여러 플랫폼에서 ChatGPT와 Codex를 이용하지 못했다고 밝혔다. 회사는 오전 8시 17분경 해결책을 적용한 뒤 복구 상황을 계속 모니터링했다고 설명했다. 39

이는 OpenAI 내부 측의 라우팅 문제를 뒷받침하는 설명이다. 반대로 멤피스 사건이 OpenAI 장애를 일으켰다는 근거는 아니다.

Claude: 오류 증가는 확인, 세부 원인은 비공개

Anthropic 상태 페이지는 여러 Claude 모델에서 오류가 늘어났으며, 영향이 태평양시간 오전 9시 16분(UTC 16시 16분)에 종료됐다고 기록했다. 당시 보도에서는 인프라 문제로 인한 부분 장애로 설명됐다. 2833

하지만 제공된 공개 자료에는 Claude 장애의 상세 근본 원인이 나오지 않으며, 멤피스 시설과 연결된다는 증거도 없다. 따라서 현 시점에서 타당한 결론은 Claude에서도 실제 장애가 있었고 해결됐지만, 원인은 공개 정보만으로 특정할 수 없다는 것이다.

시간이 겹쳤다고 원인이 같은 것은 아니다

세 서비스가 하나의 시각에 동시에 멈췄다고 보기도 어렵다. Grok은 더 이른 시점에 장애가 시작된 것으로 보도됐고, OpenAI는 오전 7시 43분~8시 17분의 라우팅 오류 대응 시간을 제시했다. Claude의 영향 종료 시각은 오전 9시 16분이다. 3339

이 겹침은 운영 관점에서 중요하다. 여러 AI 서비스를 대안으로 사용하던 고객도 같은 시간대에 선택지들이 함께 흔들릴 수 있었기 때문이다. 하지만 시간적 상관관계는 인과관계가 아니다. 공통 의존성, 트래픽 쏠림, 다른 서비스 장애에 따른 연쇄 효과는 모두 가능한 가설일 뿐, 공급자의 근거나 기술 자료가 나오기 전까지는 사실로 단정할 수 없다.

아직 입증되지 않은 주장들

현재 공개된 증거로는 다음을 확정할 수 없다.

• Grok, ChatGPT·Codex, Claude 전반에 걸친 단일 연쇄 장애
• OpenAI 또는 Anthropic의 프로덕션 추론 워크로드가 멤피스의 영향을 받은 시설에 있었다는 주장
• Azure, Cloudflare 또는 특정 클라우드·CDN·네트워크 사업자가 공통 원인이었다는 주장
• 장애 신고 사이트의 보고 건수를 근거로 한 감사 가능한 실제 영향 사용자 수
• 특정 Cursor 오류, 코딩 에이전트 중단, 후속 업무 실패가 공급자 장애 하나 때문에 발생했다는 주장

Cursor 상태 페이지는 OpenAI 및 Anthropic 모델의 업스트림 오류 증가를 보고했다. 이는 일부 Cursor 사용 사례에서 공급자 측 이슈가 영향을 줬을 가능성을 뒷받침한다. 그러나 실패한 모든 에이전트 실행이나 고객 업무의 원인을 증명하지는 못한다. 통합 설정, 인증, 대기열, 요청 제한, 네트워크, 클라이언트 문제도 별도로 있을 수 있다. 30

진짜 교훈: 멀티 모델이 곧 복원력은 아니다

멤피스 사건에서 언급된 이름 없는 ‘컴퓨트 파트너’는 인프라 의존성이 종종 외부에서 보이지 않는다는 점을 환기한다. 애플리케이션이 여러 모델 사업자의 API를 호출하더라도, 실제로는 다음과 같은 기반을 공유할 수 있다.

• 인증 서비스
• DNS 또는 CDN 경로
• 클라우드 리전과 GPU 호스트
• 모델 게이트웨이
• 코드 호스팅 서비스
• 모니터링·관측 도구
• 외부 도구 연동 백엔드

결국 API 층에서 공급자를 분산했다고 해서 인프라까지 분산된 것은 아니다. 백업 모델 엔드포인트가 있어도, 그 주변의 의존 요소가 같은 장애 시나리오를 견디지 못하면 실질적인 대안이 되기 어렵다.

다시간 AI 공급자 장애에 대비하는 방법

1. 전체 의존성 지도를 만든다

모델 API, 게이트웨이, 클라우드 리전, DNS·CDN, 인증, 벡터 데이터베이스, 대기열, 코드 호스트, 도구 연동, 관측성 스택을 서비스 맵에 기록해야 한다. 확인된 하위 공급자뿐 아니라 아직 알 수 없는 핵심 의존성도 별도로 관리할 필요가 있다.

2. 실제 업무 조건에서 대체 경로를 시험한다

대체 공급자나 소형·로컬 모델을 미리 통합해 두고, 현실적인 프롬프트와 구조화된 출력, 도구 호출, 안전 정책, 처리량 제한, 비용 통제를 적용한 상태에서 장애 전환을 테스트해야 한다. 단순한 데모 요청 성공은 프로덕션 업무를 대신 처리할 수 있다는 증거가 아니다.

3. 에이전트가 안전하게 멈추고 재개하도록 설계한다

타임아웃, 지터를 포함한 제한적 재시도, 서킷 브레이커, 멱등성 키, 영속 체크포인트, 명시적 일시정지·재개 규칙을 적용해야 한다. 되돌릴 수 없는 작업은 사람의 승인을 거치게 하는 편이 안전하다. 장애가 끝난 뒤 에이전트가 배포·구매·티켓 생성·외부 API 호출을 중복 실행하는 대신, 기록된 상태에서 이어서 작업할 수 있어야 한다.

4. 장애 전 ‘저하 운영 모드’를 정한다

모델에 접속할 수 없을 때도 가능한 기능을 문서화해야 한다. 예를 들어 검색, 입력 양식, 규칙 기반 분류, 초안 대기열 적재, 읽기 전용 접근, 수동 담당자 전환, 고객 안내 메시지 등이 있다. 최대 대기열 적체 시간, 수동 처리 가능 물량, 고객 공지 기준, 자율 실행을 중지할 시점도 미리 정해둘 필요가 있다.

5. 공급자 소통과 사고 증거 보존을 체계화한다

공급자 상태 피드를 구독하고, 에스컬레이션 경로, 알림 기준, 사고 후 보고서 요구, 계약상 가능한 범위의 데이터 이동성 조건을 마련해야 한다. 장애 중에는 UTC 타임스탬프, 요청 ID, 응답 헤더, 오류 본문, 트레이스, 라우팅 기록, 에이전트 상태, 대기열 로그, 상태 페이지 캡처를 보존하는 것이 중요하다. 그래야 나중에 업스트림 공급자 장애와 자사 통합 문제를 구분할 수 있다.

6. 중요한 업무일수록 ‘진짜 독립성’을 확보한다

고위험 업무의 대안은 모델 브랜드만 달라서는 부족하다. 공급자, 리전, 클라우드, 네트워크 경로, 인증 의존성, 운영 제어 영역까지 달라야 한다. 같은 게이트웨이 뒤에 있거나 같은 리전에 놓인 두 모델 엔드포인트는 의미 있는 이중화가 아닐 수 있다.

결론

9월 3일의 사건을 ‘전 세계 AI가 한꺼번에 멈춘 사고’나 ‘멤피스발 3사 연쇄 장애’의 증거로 해석해서는 안 된다. 다만 이 사건은 겉으로는 독립적으로 보이는 AI 서비스들이 같은 시간대에 함께 흔들릴 수 있음을 보여준다.

기업이 가져가야 할 태도는 성급한 원인 단정이 아니라, 증거가 확인되기 전에도 안전하게 업무를 지속할 수 있도록 시스템을 설계하는 것이다. 333941