챗GPT·클로드·그록 동시 먹통, AI 인프라의 민낯

무슨 일이 있었나

오픈AI의 챗GPT, 앤스로픽의 클로드, 일론 머스크가 이끄는 xAI의 그록이 한때 일제히 접속 장애를 겪었다. 국내외 매체가 동시에 보도할 만큼 이용자 불편이 컸고, 서비스는 이후 복구됐지만 "왜 하필 세 곳이 동시에"라는 의문이 남았다.

각 사가 서로 다른 회사이고, 원칙적으로 별개의 모델과 서비스 스택을 운영한다는 점을 감안하면 이런 동시다발 장애는 이례적이다. 개별 서비스의 일시적 오류는 흔하지만, 경쟁 관계인 3사가 같은 시간대에 멈추는 상황은 자주 관측되지 않는다.

왜 중요한가 — '경쟁사'라도 바닥은 공유한다

챗봇 브랜드는 다르지만, 이들이 올라타 있는 하부 구조는 상당 부분 겹친다. 클라우드 리전, 네트워크 백본, CDN, DNS, 인증 서비스 같은 공통 인프라 계층은 소수 사업자에 집중돼 있다. 과거 AWS 특정 리전 장애나 클라우드플레어·패스틀리 같은 CDN 사고 때 서로 무관한 수많은 서비스가 한꺼번에 멈췄던 사례가 이를 잘 보여준다.

정확한 원인이 공식 확인되기 전까지 단정할 수는 없지만, 여러 AI 서비스가 같은 시간대에 영향을 받았다는 사실 자체가 공통 병목의 존재 가능성을 시사한다. AI 경쟁이 모델 성능 싸움처럼 보여도, 실제 가용성은 그 아래 인프라 사업자 몇 곳의 안정성에 좌우된다는 뜻이다.

비교: 예전의 '먹통'과 지금의 '먹통'은 다르다

몇 년 전이라면 챗봇이 멈춰도 대부분의 이용자에게는 불편한 장난감이 잠깐 꺼진 정도였다. 지금은 다르다. 개발자는 코드 작성과 리뷰에, 마케터는 카피 초안에, 고객센터는 응대 자동화에 AI를 실제 업무 경로에 넣어두고 있다. 업무 흐름 자체가 멈추는 종류의 장애로 성격이 바뀐 것이다.

기업 입장에서 더 뼈아픈 지점은 흔히 쓰던 리스크 분산 전략이 이번 사례에서는 잘 작동하지 않았을 수 있다는 것이다. "오픈AI가 죽으면 앤스로픽으로 폴백"이라는 멀티 벤더 설계는 두 서비스가 동시에 멈추면 무의미해진다. 벤더를 나눴다고 해서 인프라까지 분리된 것은 아니다.

무엇이 달라지나 — 이용자와 기업의 실전 대응

개인 이용자라면 대응은 단순하다. 마감이 걸린 작업을 특정 챗봇 한 곳에만 의존하지 않고, 중요한 대화·결과물은 로컬에 따로 저장해두는 습관이 실효성 있다. 장애 발생 시 각 사의 상태 페이지(status page)와 다운디텍터류 서비스를 먼저 확인하면 "내 계정 문제인가" 하는 시간 낭비를 줄일 수 있다.

AI를 제품에 넣은 기업이라면 점검 항목이 더 구체적이다. 첫째, 폴백 대상 모델이 다른 클라우드·다른 리전에 떠 있는지 확인해야 한다. 둘째, API 호출 실패 시 사용자에게 무엇을 보여줄지 — 무한 로딩이 아니라 명확한 안내와 재시도 경로 — 를 미리 설계해야 한다. 셋째, AI 기능이 없어도 핵심 서비스는 굴러가도록 기능을 분리(degrade gracefully)해두는 편이 안전하다.

남는 질문

이번 사건의 근본 원인이 공통 인프라였는지, 혹은 우연히 겹친 별개의 문제였는지는 각 사의 사후 보고서(postmortem)로 확인해야 한다. 다만 분명한 것은, AI가 전기·수도처럼 취급되기 시작한 시점에서 가용성은 모델 성능만큼 중요한 스펙이 됐다는 사실이다. 벤치마크 점수 옆에 가동률(uptime) 수치를 나란히 놓고 서비스를 고르는 시대가 이미 왔다.