Google 중단, 2025년 6월: 단 하나의 널 포인터가 Cloudflare를 다운시켰다
(dev.to)
2025년 6월 발생한 구글 클라우드 장애는 단순한 데이터 오류가 코드의 결함과 결합하여 전 세계적인 서비스 중단을 초래한 사례로, 피처 플래그와 에러 핸들링의 중요성을 시사하는 결정적 교훈을 제공합니다.
이 글의 핵심 포인트
- 12025년 6월 12일, 구글 클라우드 API 레이어의 장애로 약 3시간 동안 70개 이상의 구글 클라우드 제품과 10개 이상의 워크스페이스 앱이 중단됨.
- 2장애의 근본 원인은 정책 변경 시 발생한 '빈 필드'가 널 포인터 예외를 유발하여 Service Control 바이너리를 무한 크래시 루프에 빠뜨린 것임.
- 3해당 코드 경로는 5월 29일 배포되었으나, 특정 정책 변경이 필요했기에 피처 플래그 없이도 배포 과정에서 발견되지 않고 잠복해 있었음.
- 4정책 데이터가 Spanner를 통해 전 세계로 수 초 내에 복제되면서, 지역별 코드 배포와 달리 데이터 오류는 즉각적인 글로벌 장애로 확산됨.
- 5이번 장애는 Cloudflare의 Workers KV, Access, WARP 등 주요 서비스의 중단까지 초래하며 클라우드 간 의존성의 위험성을 드러냄.
이 글에 대한 공공지능 분석
왜 중요한가?
단 하나의 데이터 오류가 전 세계 인프라를 멈출 수 있음을 보여주며, 코드 배포뿐만기 데이터 변경(Data Change) 관리의 치명적 위험성을 경고합니다.
어떤 배경과 맥락이 있나?
구글의 Service Control은 모든 API 요청의 권한과 할당량을 검증하는 핵심 계층이며, 이 데이터는 글로벌 일관성을 위해 전 세계에 즉시 복제되는 구조를 가지고 있습니다.
업계에 어떤 영향을 주나?
클라우드 네이티브 환경에서 서비스 간 의존성(Dependency)이 얼마나 깊은지 보여주며, 단일 장애점(SPOF)이 될 수 있는 설정값 관리의 중요성을 부각시킵니다.
한국 시장에 어떤 시사점이 있나?
글로벌 클라우드 의존도가 높은 한국 스타트업들은 인프라 장애 시의 비즈니스 연속성 계획(BC점)과 함께, 설정값 변경 시의 점진적 데이터 전파 전략을 반드시 고려해야 합니다.
이 글에 대한 큐레이터 의견
이번 장애는 '완벽한 코드'보다 '안전한 배포 전략'이 시스템 안정성에 더 결정적임을 증명합니다. 구글과 같은 거대 기업조차 피처 플래그(Feature Flag)와 에러 핸들링이라는 기본적인 방어 기제를 갖추지 못했을 때 얼마나 취약해질 수 있는지 보여줍니다. 특히 데이터가 코드보다 빠르게 전파될 수 있다는 점은 현대 분산 시스템 설계에서 간과하기 쉬운 핵심 리스크입니다.
창업자들은 서비스의 확장성(Scalability)을 추구하면서도, 동시에 '실패를 허용하는 설계(Design for Failure)'를 구축해야 합니다. 물론 모든 코드에 에러 핸들링을 추가하고 피처 플래그를 도입하는 것은 개발 비용과 시스템 복잡성을 증가시키는 트레이드오프를 발생시킵니다. 하지만 이번 사례처럼 단 한 번의 실수로 서비스 전체가 중단되는 비용은 개발 비용보다 훨씬 막대합니다. 따라서 초기 단계부터 핵심 로직에는 반드시 'Fail-open' 전략과 점진적 데이터 전파 방식을 도입하는 설계 철학이 필요합니다.
관련 뉴스
댓글
아직 댓글이 없습니다. 첫 댓글을 남겨보세요.