article cover image

구글 장애로 본 클라우드 리스크

작성일 : 이소현 June 26, 2025

6월 13일, 모든 것이 멈췄다

Intro


2025년 6월 12일, Google Cloud에서 발생한 전 세계적 장애는 총 70개 이상의 서비스에 영향을 주었고, 구글 서비스인  Gmail, Google Drive, Calendar, Meet 등 Google Workspace 뿐만 아니라 여기에 Cloudflare, OpenAI, Spotify, Shopify, Discord, Snapchat 같은 외부 플랫폼까지 포함됐습니다. 국내의 경우 오전 4시 경이라 큰 피해는 없었는데요. 

 

IMG_0845.jpg


대부분의 지역은 약 3시간 내 복구됐지만, 그보다 훨씬 긴 시간 동안 장애가 이어진 곳들도 있었습니다. 결과적으로 전 세계 수많은 기업과 사용자가 동시에 혼란을 겪은 셈입니다.
 


WHY? 사태의 원인


문제의 핵심은 Google Cloud의 API 관리 시스템인 Service Control에 있었습니다.
Service Control은 API 호출을 통제하고, 쿼터(Quota) 제한과 정책 체크를 담당하는 중요한 모듈입니다.

2025년 5월 29일, Google은 더 정교한 쿼터 정책을 적용하기 위해 이 시스템에 새로운 기능을 추가했는데요, 이 업데이트에는 두 가지 큰 문제가 숨어 있었습니다:

 

  1. 기능 플래그(Feature Flag) 없이 배포됨
    → 문제가 생겼을 때 즉시 롤백하거나 차단할 수 있는 장치가 없었습니다.
  2. 예외 처리가 없는 null 포인터 버그 포함
    → 테스트 환경에서는 문제가 드러나지 않았지만, 실제 운영에서는 빈 필드가 입력되면서 에러가 발생했습니다.

 

그리고 결국, 6월 12일 자동 쿼터 업데이트에서 예상치 못한 공란(blank 필드)이 입력되면서 이 오류 코드가 실행되었고, Service Control 바이너리들이 전 세계적으로 무한 충돌(crash loop) 상태에 빠졌습니다.

 


이로 인해 발생한 피해

 

Google Cloud 장애가 끼친 영향은 단순한 "일부 서비스 이용 불가" 수준이 아니었습니다.
이번 사태는 수많은 SaaS 및 플랫폼 비즈니스에 업무 마비 수준의 정지 상태를 야기했습니다.

주요 기업들의 사례를 살펴보면:

 

  • Cloudflare: 인증 API가 중단되며 Zero Trust Access, Workers, WARP 등 주요 서비스에 장애 발생
  • Spotify, Snapchat, Discord, Twitch: 사용자 인증, 음악 스트리밍, 실시간 메시징, 방송 기능 등 핵심 기능 불가
  • GitLab, Shopify: 배포 자동화(CI/CD), 결제 및 제품 등록 기능 일부 중단
  • Workspace 앱(Gmail, Drive, Meet): 내부 커뮤니케이션 및 협업 도구 전면 마비

 

이 외에도 비즈니스 관점에서의 피해는 다음과 같습니다:

 

  • CI/CD 파이프라인 중단으로 인한 신규 코드 배포 실패
  • AI/ML 모델 서빙 중지, API 엔드포인트 불가
  • 데이터 처리 파이프라인 정지로 인해 업무 지연
  • 복구 전까지 서비스 SLA 이슈, 고객 불만 급증, 운영 인력 과부하

이러한 피해는 대부분 단일 서비스에 대한 의존성이 심화된 조직일수록 더욱 크게 나타났습니다.

 

왜 중요한가요?
단 하나의 오타로 인해 수많은 핵심 서비스가 멈췄다는 사실은, 오늘날 클라우드 시스템이 얼마나 긴밀하게 연결되어 있는지를 보여줍니다.
이번 장애는 하이퍼스케일 클라우드조차 절대 안전하지 않으며, 하나의 오류가 전체 디지털 스택에 연쇄적인 장애를 일으킬 수 있음을 여실히 드러냈습니다.

또한 내부 복구는 빠르게 진행되었지만, 외부 상태 페이지 업데이트는 최대 1시간 가까이 지연되면서 사용자들은 오랫동안 아무 정보 없이 기다려야만 했습니다.


그럼 이런 사태를 어떻게 예방해야 할까요?

다양한 대응 방안이 있지만, 먼저 가장 중요한 세 가지를 소개합니다.

 

1️⃣ 이중화 및 분산 배포 구성 – 멀티 리전·멀티 존 기반으로 서비스 중단 시 다른 리전이 자동으로 트래픽을 넘겨받을 수 있도록 설계합니다.
2️⃣ 자동 장애 전환 및 로드밸런싱 – 장애를 자동 감지하고 백업 리소스로 전환하며, 트래픽을 건강한 리소스로 분산시켜 성능 저하를 막습니다.
3️⃣ 재해 복구 및 복구 훈련 체계화 – 정기적인 복구 시나리오 점검과 테스트를 통해 실제 장애 상황에서도 빠르게 회복할 수 있는 대응력을 갖춥니다.

등의 이 세 가지는 단순한 기술적 옵션이 아닌, 복원력 있는 클라우드를 위한 기본 설계 요소입니다.

 


마치며

 

복원력 있는 아키텍처는 ‘선택’이 아닌 ‘필수’

이번 사태는 ‘클라우드도 멈춘다’는 현실을 다시금 보여주었습니다.
지금 우리가 고민해야 할 것은 복잡한 기술보다, 위기 속에서도 멈추지 않는 구조입니다.

위에서 소개한 세 가지 대응 전략 외에도,
NDS와 함께 인프라 종속성 점검, 이중화 설계, 복구 시뮬레이션까지 진단해보세요.

서비스가 궁금하신 분들은 하단의 문의하기를 통해 문의해주시기 바랍니다.

 

참고자료:

presentation