지난 9월 3일 밤, 챗GPT와 클로드와 그록이 거의 동시에 멈췄다. 처음 이 소식을 접했을 때 필자는 좀 의아했다. 세 회사는 서로 다른 클라우드를 쓰고, 서로 다른 모델을 돌리고, 서로 경쟁하는 사이다. 그런데 왜 하필 같은 시간대에 나란히 먹통이 됐을까.
더 흥미로운 건 따로 있다. 세 회사 중 누구도 “우리 때문에 다른 회사까지 영향을 받았다”고 인정하지 않았다는 점이다. 이 지점이 이번 사건의 핵심이라고 필자는 생각한다.
동시다발 장애, 무슨 일이 있었나
한국시간 기준 9월 3일 밤 11시 20분 무렵부터 다음날 새벽까지, 약 2시간 동안 주요 AI 서비스들이 줄줄이 이상 신호를 보냈다. 챗GPT 관련 장애 신고만 미국에서 3만 5천 건을 넘었다.
- ChatGPT: 오류율 급증, 응답 생성 실패
- Claude(Anthropic): 웹 서비스와 API 동시 영향
- Grok(xAI): 테네시주 멤피스 데이터센터 이슈와 연관된 것으로 알려짐
- Gemini(구글): 일부 이용자 접속 불안정 신고
공교롭게도 이번이 처음도 아니다. 관련 업계 분석에 따르면 주요 AI 사업자들은 2026년 한 해 동안만 비슷한 성격의 장애를 수십 차례 겪은 것으로 알려졌다. 그런데도 매번 원인 설명은 짧고 모호하다. 이 부분이 필자는 계속 걸린다.
원인은 확인됐나 — 사실과 추정을 구분해보자
결론부터 말하면, 이번 동시 장애를 하나의 원인으로 묶어 설명할 근거는 아직 없다. 각 회사가 공개한 내용과 외부에서 제기된 추정은 분명히 다르다.
xAI는 비교적 구체적으로 설명했다. 테네시주 멤피스 컴퓨팅센터 문제로 그록 이용에 차질이 생겼다고 공식적으로 밝혔다. 반면 앤트로픽은 “내부 인프라 문제로 부분 장애가 발생했다”는 짧은 설명에 그쳤다. 오픈AI는 상태 페이지에 “오류율 증가”라고만 표시했을 뿐, 구체적 원인은 공개하지 않았다.
일부 외신에서는 마이크로소프트 애저(Azure) 미 동부 리전의 문제가 배후에 있을 수 있다는 관측을 내놓았다. 하지만 이는 어디까지나 추정이다. 마이크로소프트의 공식 상태 페이지에는 이와 관련된 장애 표시가 없었다. 즉, 애저 원인설은 확인되지 않은 추측이라는 점을 분명히 해둘 필요가 있다.
필자가 보기엔 이 애매함 자체가 문제다. 공식 확인이 없으니 기업들은 각자 알아서 리스크를 평가할 수밖에 없다. 정보가 불충분한 상태에서 대응 전략을 짜야 하는 셈이다.
왜 “따로 노는 서비스”들이 같이 멈추는가
여기서 짚어볼 개념이 바로 AI 인프라의 구조다. 챗GPT와 클로드와 제미나이는 표면적으로는 완전히 다른 회사, 다른 모델이다. 하지만 그 밑단을 받치는 클라우드, DNS, CDN, 신원 인증(ID) 제공자는 상당 부분 겹칠 수 있다.
업계 전문 분석에서도 “단일 공통 장애점의 증거는 없다”면서도 “네 개 사업자가 인프라 구성요소를 공유할 가능성”을 지적한 바 있다. 말하자면 겉보기엔 분산돼 있지만, 속을 들여다보면 몇 개의 병목 지점에 의존하고 있을 수 있다는 얘기다.
이걸 다르게 표현하면 이렇다. AI 서비스가 늘어날수록 다양성이 커진 것처럼 보이지만, 실제로는 소수의 클라우드 사업자에게 다시 쏠리는 역설이 생긴다. 필자는 이 지점이 꽤 아이러니하다고 느낀다.
| 서비스 | 발생 시각(KST) | 지속시간 | 공식 원인 |
|---|---|---|---|
| ChatGPT (OpenAI) | 9월 3일 밤~4일 새벽 | 약 2시간 | 오류율 증가 (구체적 원인 미공개) |
| Claude (Anthropic) | 9월 3일 밤 | 약 25분~수시간대 | 내부 인프라 문제 (부분 장애) |
| Grok (xAI) | 9월 3일 밤 | 약 3시간 | 멤피스 데이터센터 이슈 (공식 확인) |
| Gemini (Google) | 9월 3일 | 약 2시간 | 공식 확인 없음 |
표로 정리해놓고 보니 한 가지가 눈에 띈다. 원인을 명확히 공개한 곳은 xAI뿐이다. 나머지는 “오류가 늘었다”거나 “내부 문제였다”는 식의 짧은 문장으로 넘어갔다. 이 정도 규모의 장애치고는 설명이 너무 인색하다는 인상을 지우기 어렵다.
기업들의 대응 — 멀티모델 전략은 답이 될까
이번 사태 이후 업계에서 자주 나오는 처방이 있다. 바로 멀티모델 전략이다. 하나의 AI 서비스에만 의존하지 말고, 여러 모델과 여러 클라우드를 동시에 활용하자는 접근이다.
이론적으로는 합리적이다. 그록이 멈추면 클로드로, 클로드가 멈추면 제미나이로 전환하면 되니까. 하지만 필자가 보기엔 여기에 함정이 하나 숨어 있다.
- 대체 서비스로 트래픭을 돌리는 순간, 그 서비스에 부하가 몰린다
- 부하가 몰리면 두 번째 서비스마저 불안정해질 위험이 있다
- 즉 진짜 복원력을 가지려면 대체 서비스들이 “완전히 독립적으로” 실패해야 한다
이 조건이 생각보다 까다롭다. 앞서 봤듯 여러 AI 서비스가 클라우드, DNS, 인증 인프라를 공유하고 있다면, 겉으로는 멀티모델이어도 실제로는 이중 장애 위험을 안고 가는 셈이다. 전문가들이 강조하는 지점도 여기에 있다. AI 업무를 비즈니스 영향도 순으로 분류하고, 의존 구조를 전체적으로 매핑한 뒤, 보조 제공자를 사전에 검증해두라는 조언이다.
참고로 이런 인프라 신뢰성 문제는 AI 서비스만의 얘기가 아니다. 앞서 마이크로소프트 365 아웃룩 장애를 다뤘을 때도 비슷한 문제를 지적한 바 있다. 인증서 만료라는 사소해 보이는 원인 하나가 전 세계 업무를 마비시켰다. 결국 핵심은 같다. 시스템이 복잡해질수록 작은 구멍 하나가 커다란 파장을 일으킬 수 있다는 것이다.
IT-SUE의 시각
필자는 이번 사건에서 가장 중요한 신호는 장애 자체가 아니라 설명의 부재라고 본다. 세 회사 모두 신속하게 복구했다는 점은 다행이지만, “왜 멈췄는지”를 투명하게 밝힌 곳은 사실상 한 곳뿐이었다.
AI는 이미 검색, 코딩, 고객 응대, 문서 작성의 기본값이 되어가고 있다. 이런 흐름을 생각하면, 이 정도의 설명 부족은 앞으로 더 큰 부메랑이 될 수 있다. 개인적으로는 AI 서비스 장애 공시가 클라우드 업계의 SLA(서비스수준협약) 수준으로 표준화돼야 한다고 생각한다.
또 하나, 멀티모델 전략이 유행어처럼 번지고 있지만 그 실효성은 “얼마나 독립적인 인프라를 확보했는가”에 달려 있다는 점도 짚고 싶다. 겉으로만 다른 서비스를 여러 개 붙여놓는 것은 진짜 복원력이 아니다. 이 부분을 착각하는 기업이 의외로 많을 것 같다는 게 필자의 예상이다.
결국 AI 인프라도 전기나 상수도처럼 사회 기반시설에 가까워지고 있다. 그렇다면 장애 대응 방식도 그에 걸맞게 성숙해져야 하지 않을까. 관련 외신 보도를 봐도 업계 전반이 아직 이 숙제를 풀지 못했다는 인상을 받았다.
답글 남기기