AI 3사 동시 다운, 기업 재해복구 계획의 사각지대 드러나
AI 시대를 맞은 기업이 불안한 새 질문에 직면했다. AI 에이전트가 갑자기 작동을 멈추면 어떻게 될까?
목요일, 오픈AI의 챗GPT, 앤트로픽의 클로드, 스페이스XAI의 그록이 거의 동시에, 다소 의문스러운 방식으로 장시간 대규모 서비스 장애를 일으키면서 가상의 시나리오가 현실이 됐다.
미국 동부시간 오전부터 시작해 챗GPT 일부 모델은 약 2시간, 클로드 모델은 약 4시간, 그록 모델은 약 3시간 30분 동안 서비스가 중단됐다. 세 기업 모두 “급증”한 오류 문제를 인정하고 수정 조치를 취했다.
사용자가 온라인 포럼에서 불만을 쏟아내고 IT 팀이 복구에 분주한 가운데, 이번 사태는 일부 기업이 광범위한 장애의 잠재적·필연적 영향을 고려하지 않은 채 얼마나 성급하게 생성형 AI 워크플로를 도입했는지 여실히 보여줬다.
기술 애널리스트 겸 저널리스트 카미 레비는 AI 에이전트가 자동화 및 대규모 워크플로를 점점 더 많이 담당하면서 AI가 멈출 때 기업이 “심각하게 무방비 상태”에 놓일 수 있다고 말했다. 레비는 “갈수록 중요해지는 이 플랫폼들이 갑자기 중단됐을 때 치러야 할 대가를 대체로 외면해온 IT 리더에게 경종을 울려야 할 상황이다. 위험은 더 이상 가상의 이야기가 아니다”라고 덧붙였다.
수 시간 지속 장애, 핵심 서비스 마비
챗GPT 장애는 오픈AI가 새 프런티어 모델 GPT-6 아스트라(GPT-6 Astra) 출시를 예고한 당일에 발생했다. 오픈AI는 GPT-6 아스트라가 인공일반지능(AGI)에 근접하며, 인간을 능가하는 자율 시스템 개발이라는 목표에 한 걸음 더 다가선 모델이라고 밝혔다.
오픈AI 장애는 목요일 미국 동부시간 오전 11시경 시작해 검색, 파일 업로드, 에이전트, GPT, 음성 모드, 이미지 생성, 챗GPT 워크, 컴플라이언스 API(Compliance API), 딥 리서치(Deep Research), 챗GPT 아틀라스 등 다수의 서비스에 영향을 미쳤다. 일부 사용자는 로그인 자체가 차단됐고, 대화 목록이 불러와지지 않거나 메시지 전송 시 오류가 발생하는 현상도 나타났다. 웹, API, 명령줄 인터페이스(CLI), 비주얼 스튜디오 코드(VS Code) 확장 기능을 포함한 오픈AI의 코덱스 서비스도 영향권에 들었다.
오픈AI는 미국 동부시간 오후 12시 55분까지 문제를 해결했으며, 코덱스 원격 제어 사용자에게는 모바일 기기를 재연결하도록 안내했다.
클로드는 미국 동부시간 오전 7시 37분경부터 장애가 시작됐으며, 앤트로픽은 이후 몇 시간 동안 오류가 급증한 영향 모델의 “광범위한 목록”을 공개했다. 영향을 받은 모델은 미토스 및 페이블 5.1과 5, 소네트 5, 오퍼스 5, 4.8, 4.6이었다.
장애는 미국 동부시간 오전 11시 27분에 해소됐다. 이번 장애는 전날에도 소네트 5 요청에서 오류가 급증해 약 27분간 서비스가 중단된 데 이어 발생한 것이었다.
그록은 미국 동부시간 오전 9시 30분경부터 장애가 시작됐다. 그록 웹(Grok Web), 빌드(Build), API, 오피스·워크스페이스 플러그인(Office/Workspace plugins), 안드로이드(Android), X 등이 모두 영향을 받았다. 서비스는 미국 동부시간 오후 1시 8분에 “정상” 트래픽으로 복귀했다.
인포테크 리서치 그룹(Info-Tech Research Group) 수석 리서치 디렉터 브라이언 잭슨은 “서로 다른 여러 서비스 업체가 동시에 장애를 겪는 것은 특이한 상황”이라고 짚었다. 잭슨은 콘텐츠 전송 네트워크(CDN) 계층, 도메인 네임 시스템(DNS), 공유 클라우드 인프라 등 공통 인프라와 관련이 있을 수 있다고 분석했다.
장애 대비 계획의 필요성
레비는 불과 몇 달 전만 해도 일반적인 기업에서 AI 활용 범위는 직원이 챗봇으로 기본적인 질문에 답을 구하거나 간단한 이메일을 작성하는 수준에 그쳤다고 말했다. 당시 대규모 AI 플랫폼 장애가 발생해도 기업 전체 생산성에 미치는 영향은 비교적 미미했다. 레비는 “하지만 상황은 빠르게 변하고 있다”라고 말했다.
레비는 기업이 이제 AI 에이전트가 일상적인 워크플로에 미치는 영향과, 자동화된 클라우드 기반 도구에 주도권을 넘긴 뒤 직원이 복잡한 업무를 완수하는 데 어느 정도 차질이 생기는지를 더 정확히 파악해야 한다고 말했다.
목요일과 같은 사태가 발생하면 직원은 스프레드시트를 직접 업데이트하거나 보고서를 수작업으로 취합하는 등 전통적인 수동 워크플로에 의존하게 될 수 있다. 레비는 AI 에이전트에 너무 많은 업무를 맡겨온 결과 자동화 의존도가 지나치게 높아져 “인지 능력이 예전만큼 날카롭지 않을 수 있다”는 사실을 직원이 깨닫게 될 수도 있다고 말했다.
레비는 AI 에이전트의 확산에 따라 기업이 재해복구 및 비즈니스 연속성 계획을 재검토하고 서비스 중단의 생산성 영향을 평가해야 한다고 말했다. 구글 워크스페이스나 마이크로소프트 365같은 클라우드 기반 생산성 플랫폼은 로컬 저장 데이터를 활용한 제한적 ‘오프라인 모드’ 기능을 제공하며, 드롭박스나 구글 독스 데스크톱을 통해 문서를 하드 드라이브에 동기화할 수도 있다. 반면 AI 에이전트 플랫폼은 적어도 현재 형태에서는 오프라인 대안이 거의 없다.
레비는 기업이 워크플로를 더 상세히 문서화하고, AI 플랫폼 장애가 장기화될 경우 단기 복구 방안이 어떤 모습이어야 할지 시나리오 계획을 세워야 한다고 말했다. 또한, 시간이 지나도 직원이 수동 역량을 유지하고 서비스 장애 시 즉시 활용할 수 있도록 더 나은 교육 훈련이 필요하다고 지적했다. 기업이 에이전트에 핵심 업무를 맡기고 “생산성을 위해 인간을 루프 밖으로 밀어낼수록” 불가피한 서비스 중단 시 직원이 다시 나서기는 더 어려워진다는 이유에서다.
레비는 “선의의 기업이라도 AI 자동화에 지나치게 의존하는 상황은 충분히 일어날 수 있다”라고 말했다. 또한 “백업 요금제를 마련하지 않은 결과를 뼈저리게 배우게 될 기업이 너무 많다”라고 덧붙였다.
인포테크의 잭슨은 LLM에 모듈형 아키텍처를 적용할 것도 권고했다. 기업은 모델을 “대체품으로 즉시 교체 가능한 범용 자원”으로 바라봐야 한다는 것이다. 대안으로는 다른 클라우드 서비스 업체(동시에 장애를 겪고 있지 않다는 전제 하에)나 오픈 웨이트(open-weights) 모델 같은 자체 호스팅 옵션을 활용할 수 있다.
