구글 클라우드, 7시간 넘는 전 세계 장애로 50개 이상 서비스 중단···기업에게 주는 시사점은?

이번 장애는 협정세계시(UTC) 기준 13일 오후 2시 51분에 발생해 오후 10시 18분에야 복구됐으며, 총 7시간 이상 지속됐다. 구글 클라우드 서비스 상태 페이지에 따르면, API 게이트웨이(API Gateway), 에이전트 어시스트(Agent Assist), 클라우드 데이터 퓨전(Cloud Data Fusion), 클라우드 워크스테이션(Cloud Workstations), 컨택센터 AI 플랫폼(Contact Center AI Platform), 데이터베이스 마이그레이션 서비스(Database Migration Service), 구글 앱 엔진(Google App Engine), 구글 클라우드 콘솔(Google Cloud Console), 버텍스 제미니 API(Vertex Gemini API) 등 총 54개 구글 클라우드 플랫폼 제품이 영향을 받았다.

구글 대변인은 “구글 클라우드의 여러 서비스에 발생한 장애는 현재 전면 복구됐다”라고 13일전했다. 구글 클라우드 CEO 토머스 쿠리안은 X 계정을 통해 “오늘 발생한 장애 복구를 위해 총력을 기울였고, 현재 모든 리전과 제품에서 완전한 복구가 완료됐다”라며 “이번 사태로 고객에게 불편을 끼친 점을 유감스럽게 생각한다”라고 밝혔다.

구글 클라우드 측은 미니 사고 보고서를 통해 “이번 사고는 API 관리 시스템에 잘못된 자동 할당량 업데이트가 글로벌하게 전파되며, 외부 API 요청이 거부되는 문제가 발생했다”라고 설명했다. 구글은 문제 해결을 위해 해당 할당량 확인 절차를 우회하는 방식으로 대응했으며, 이로 인해 대부분의 리전에서는 2시간 내 복구가 이뤄졌다. 그러나 미국 중부 리전에서는 할당량 정책 데이터베이스가 과부하되며 복구가 더디게 진행됐다.

구글 클라우드는 이러한 사고가 발생해서는 안 됐다며, 향후 재발 방지를 위해 ▲API 관리 플랫폼의 오류 데이터로 인한 장애 차단, ▲메타데이터 글로벌 전파 시 보호 장치 강화, ▲보다 정교한 테스트 및 모니터링 체계 마련, ▲시스템 오류 처리 및 비정상 데이터에 대한 전방위 테스트 체계 강화 등의 조치를 취하고 있다고 밝혔다.

데이터 솔루션 기업 코크로치랩스(Cockroach Labs)의 CEO이자 공동 설립자인 스펜서 킴벌은 “복원력은 단순히 추가하는 기능이 아니라 설계 차원의 약속”이라며 “최적의 상태가 아닌 악조건에서 얼마나 잘 작동하는지가 진정한 기준이다. 시스템이 실패를 흡수하지 못하고 고객까지 피해를 입힌다면, 2025년 AI 시대에는 운영 준비가 된 시스템이라 할 수 없다”라고 말했다.

인터넷 인프라의 취약한 연결 고리 드러나

이번 장애는 구글 클라우드 내부 인프라에서 시작됐지만, 전 세계 주요 플랫폼에 영향을 미치며 하이퍼스케일러 생태계의 구조적 취약성을 부각시켰다.

컨설팅 기업 그레이하운드리서치(Greyhound Research)의 수석 애널리스트이자 CEO인 산치트 비르 고기아는 “구글 클라우드의 IAM 내부 오류가 클라우드플레어, 스포티파이, 스냅챗, 디스코드 등 주요 플랫폼에도 도미노처럼 영향을 미쳤다”라며 “이는 하드웨어 문제가 아니라 제어 평면의 의존성이 주요 관리 기능을 마비시킨 결과”라고 지적했다.

클라우드플레어는 자사 블로그를 통해 이번 장애로 워커 KV, WARP, 액세스, 게이트웨이, 이미지, 스트림, 워커 AI, 턴스타일, 챌린지, 오토RAG(AutoRAG), 자라즈(Zaraz), 대시보드 일부 등 핵심 서비스가 영향을 받았다고 설명했다. 총 2시간 28분 동안 장애가 발생했고, 해당 서비스를 이용하는 전 세계 고객이 영향을 받았다. 클라우드플레어는 “이들 서비스 중 일부는 외부 클라우드 벤더의 인프라를 기반으로 하고 있으며, 이번 장애는 해당 벤더의 장애로 인해 직접 영향을 받았다”고 밝혔다.

인텔리전스 플랫폼 기업 테크인사이트(TechInsights) 애널리스트 마니시 라와트는 “이번 사건은 오늘날 인터넷 인프라가 얼마나 상호 의존적인지를 보여준다”FK며 “클라우드 벤더들이 기술적으로는 독립적인 것처럼 보이지만, 라우팅 프로토콜, DNS, 엣지 딜리버리 시스템 등 핵심 구성 요소를 공유하면서 시스템 전체에 리스크가 확산될 수 있다”라고 분석했다. 그는 “클라우드 이중화가 존재하더라도, 핵심 인터넷 프로토콜에 오류가 발생하면 전체 시스템의 취약성이 드러날 수 있다”라고 덧붙였다.

서비스 장애 모니터링 플랫폼 다운디텍터(Downdetector)는 같은 시간대 아마존웹서비스(AWS)와 마이크로소프트 애저(Microsoft Azure)에서 사용자 불만이 증가했다고 전했다. 그러나 양사의 공식 서비스 상태 페이지에는 어떠한 장애도 기록되지 않았다.

AWS는 파운드리 산하 언론사 네트워크월드(Network World)의 문의에 대해 “AWS는 이번에 어떠한 장애도 겪지 않았으며, 현재도 정상 운영 중”이라며 “AWS 서비스 상태에 대한 정확한 정보는 AWS 헬스 대시보드에서 확인할 수 있다”라고 밝혔다.

고기아는 “초기에는 멀티 클라우드 장애처럼 보였지만, 실제로는 인터넷 전반의 혼선과 CDN 계층의 연쇄 반응이 원인이었다”라며 “현대 클라우드 복원력은 단순한 인프라 가동률을 넘어, 오케스트레이션 시스템의 구조적 안정성에 달려 있다”라고 강조했다.

한편, 최근 IBM 클라우드도 2주간 세 차례의 장애를 겪은 바 있다.

기업은 ‘장애를 전제로 한 설계’ 필수적으로 고려해야

클라우드 장애는 인프라에 크게 의존하는 기업에 치명적인 영향을 줄 수 있다. 특히 멀티 클라우드나 엣지 계층의 이중화가 부족한 경우, 수익 손실, 브랜드 신뢰 하락, 운영 차질, 데이터 무결성 훼손 등 심각한 결과로 이어진다. 핀테크, 헬스케어, 이커머스와 같이 실시간성이 중요한 산업에서는 그 피해가 즉각적이고 치명적이다. 이에 따라, 기업은 시스템 복원력을 시급히 강화할 필요가 있다.

테크인사이트의 라와트는 “진정한 디지털 복원력을 갖추기 위해서는 단일 클라우드나 동일 벤더 기반의 장애 대응 전략에서 벗어나야 한다”라며 “멀티 클라우드, 하이브리드 클라우드, 분산형 서비스 모델 도입이 필요하다”고 강조했다. 그는 핵심 워크로드를 여러 클라우드에 분산 배치하고, 지리적으로 분산된 장애 대응 체계를 구축하며, DNS, 인증, 모니터링에는 독립적인 서드파티 서비스를 활용하는 것이 주요 전략이라고 설명했다.

아울러, 기업은 실환경 수준의 장애 상황을 검증할 수 있도록 카오스 엔지니어링(chaos engineering)을 검토하고, 복원력을 점검할 수 있는 시뮬레이션 훈련을 주기적으로 시행하는 방안을 고려할 수 있다. 중앙 집중형 클라우드에 대한 의존을 줄이기 위한 대안으로 엣지 컴퓨팅이나 로컬 캐싱 기술의 도입도 하나의 방법이 될 수 있다.
dl-ciokorea@foundryco.com