본문 바로가기
클라우드2026년 10월 20일15분 읽기

구글 클라우드 런던 리전 6시간 장애 — 발전기 자동 기동 실패로 레볼루트 결제 멈추고 영국 은행 줄줄이 흔들려

YS
김영삼
조회 16
구글 클라우드 런던 리전 6시간 장애 — 발전기 자동 기동 실패로 레볼루트 결제 멈추고 영국 은행 줄줄이 흔들려

구글 클라우드의 런던 리전(europe-west2)이 10월 20일(영국 현지시간) 오전 7시부터 6시간 10분 동안 장애를 겪었고, 이 여파로 레볼루트(Revolut)의 카드 결제·송금·ATM 출금이 멈추는 등 영국 금융·공공 서비스가 줄줄이 흔들렸다.

구글이 10월 22일 올린 예비 사고 보고서에 따르면 출발점은 가용 영역 europe-west2-b가 있는 데이터센터의 전력망 이상이었다. 비상 디젤 발전기를 켜야 할 PLC(프로그래머블 로직 컨트롤러)가 주·예비 모두 기동 명령을 내리지 못했고, UPS 배터리가 바닥나자 서버·네트워크·스토리지가 한꺼번에 꺼졌다. 정전은 한 영역에서 났지만 장애는 리전 전체로 번졌다.

3줄 요약
  • 원인은 europe-west2-b 데이터센터 정전 + 발전기 자동 기동 실패. UPS가 버티는 동안 발전기가 부하를 넘겨받지 못했고, 배터리 소진 시점(07:00 BST)부터 해당 영역이 통째로 꺼졌다.
  • 영향은 한 영역에 그치지 않았다. 남은 두 영역(a·c)으로 장애 조치 트래픽이 몰려 용량이 바닥났고, 꺼진 영역의 메타데이터에 동기식으로 묻는 제어 평면 호출이 타임아웃 나면서 BigQuery·GKE·Cloud SQL 등이 리전 단위로 흔들렸다.
  • 레볼루트는 구글 클라우드 장애와 연관됐다고 밝혔다. 핼리팩스·로이즈·HSBC·뱅크 오브 스코틀랜드·로열메일·DPD 등도 장애 신고가 몰렸지만, 이들 모두가 구글 장애 때문인지는 공식 확인되지 않았다.
6시간 10분
구글 집계 장애 시간
(07:00~13:10 BST)
40개
예비 보고서에 영향 받은 것으로 나열된 GCP 제품 수
99%+
13:10 BST 기준 정상 상태로 돌아온 Compute Engine VM 비율
1시간 이내
유틸리티 전원이 복구되기까지 걸린 시간(구글 보고서)

무슨 일이런던 데이터센터 정전, 발전기가 켜지지 않았다

구글 클라우드 상태 페이지의 사고 기록을 처음부터 따라가 보면 상황이 선명하다. 첫 공지는 영국 시간 오전 9시 35분쯤 올라왔다. "europe-west2 리전의 여러 서비스에서 오류율 상승과 간헐적 네트워크 장애가 발생하고 있다"는 짧은 문장뿐이었고, 우회 방법은 "현재 없음"이었다. 시작 시각은 태평양시 19일 23시 08분, 영국 시간으로 20일 07시 08분으로 적혀 있었다.

오후 12시를 조금 넘겨 원인이 처음 언급됐다. 구글은 "전력 이벤트(power event)로 europe-west2-b 영역에서 장애가 발생했고, 전력 문제는 완화됐다"고 적었다. 기존 워크로드 복구를 우선하고 있으며 새 워크로드는 아직 만들지 못할 수 있다는 안내도 붙었다.

그리고 10월 22일, 구글은 예비 사고 보고서(Preliminary Incident Report)를 공개했다. 보고서는 사고 시작을 07:00 BST, 종료를 13:10 BST로 못 박았다. 07:08은 감지 시각이다. 정전 자체는 그보다 앞선 06:53 BST에 일어났다.

발전기 앞에서 멈춘 자동화

보고서가 밝힌 경위는 이렇다. 06:53 BST, europe-west2-b를 수용한 시설에 전력망 장애가 들어왔다. 설계대로라면 UPS 배터리가 잠깐 부하를 받는 사이 비상 디젤 발전기가 기동해 전력을 넘겨받아야 한다. 그런데 발전기의 기동·전환을 맡은 PLC 자동화 시스템이 주 PLC와 예비 PLC 모두 논리적 자동 기동 명령을 내리지 못했다. 발전기는 부하를 받지 못했고, 7분 뒤인 07:00 BST부터 UPS 배터리가 바닥나기 시작했다.

그 결과 해당 영역의 물리 서버, 네트워크 스위칭 패브릭, 로컬 스토리지 어레이가 전원을 잃었다. 그 영역에 있던 VM 인스턴스, 데이터베이스 복제본, 워커 노드는 그 순간 닿지 않는 상태가 됐다. 주·예비 PLC가 왜 함께 실패했는지는 아직 설명되지 않았다. 구글은 전면적인 근본 원인 분석(RCA)을 시작했고, 재발 방지 대책이 담긴 최종 보고서를 따로 내겠다고 밝혔다.

한 영역 정전이 리전 장애가 된 과정

여기까지만 보면 "한 영역이 꺼졌으니 나머지 두 영역으로 버티면 된다"는 교과서적인 상황이다. 문제는 그다음이었다. 리전 트래픽 라우팅과 고객 애플리케이션이 자동으로 인접 영역(europe-west2-a, c)으로 장애 조치를 시작하자, 몰려든 쿼리 실행·DB 장애 조치·컴퓨트 워크로드가 남은 영역의 컴퓨트 슬롯과 처리 용량을 포화시켰다. 입장 대기열이 길어지고, DB 장애 조치 완료가 늦어지고, 리전 전반에서 HTTP 500·503 오류가 간헐적으로 튀었다.

두 번째 원인은 더 구조적이다. 리전 서비스의 제어 평면이 꺼진 영역에 있는 메타데이터·카탈로그 구성 요소로 영역 간 RPC를 보내고 있었는데, 그 호출이 타임아웃 나면서 작업 제출이 멈추고 API 지연이 치솟았다. 보고서는 이를 "영역 경계를 넘는 동기식 제어 평면 검증 의존성"이라고 표현했다. 살아 있는 영역에서만 돌던 고객도 예상치 못한 영향을 받은 이유로 구글은 이 두 가지, 즉 순간적인 수요 급증과 영역 간 동기 의존성을 꼽았다. BigQuery, Looker, Compute Engine, GKE, 리전 영구 디스크(Regional Persistent Disk), Cloud SQL이 여기에 해당한다고 명시했다.

구글 상태 페이지 업데이트 기록과 10월 22일 예비 사고 보고서 기준. 대부분 서비스는 12:29에 복구됐다.
시각(BST)구글 보고서·상태 페이지 기록
06:53europe-west2-b 시설 전력망 장애. PLC 기동 오류로 비상 발전기가 부하를 넘겨받지 못함
07:00UPS 배터리 소진 시작, 해당 영역 서버·네트워크·스토리지 전원 상실. 구글 집계상 사고 시작
07:08자동 모니터링·프로버가 API 오류율 상승, 작업 제출 타임아웃 감지
09:35상태 페이지 첫 공지(우회책 "없음")
12:12"전력 이벤트" 원인 첫 언급, 다른 영역·리전으로 이전 권고
13:10Compute Engine VM 99% 이상 정상, 사고 종료로 집계(총 6시간 10분)
15:03잔여 고객까지 정리 후 종료 공지 게시

누가 피해를 봤나레볼루트는 확인, 나머지 은행은 "신고 급증"

가장 크게 드러난 곳은 디지털 은행 레볼루트다. 아이리시 타임스에 따르면 레볼루트는 앱 로그인, 송금, 카드 결제, 현금 출금이 영향을 받았고, 이번 장애가 핵심 인프라를 제공하는 구글 클라우드의 장애와 연관돼 있다고 밝혔다. 레볼루트 대변인은 "고객의 돈과 데이터는 모두 안전하다"고 했다. 아일랜드에만 340만 명의 고객이 있다. AIB와 뱅크 오브 아일랜드는 영향이 없었다고 밝혔다.

다른 이름들은 조심해서 봐야 한다. 로이즈 뱅킹 그룹은 앱 로그인은 됐지만 일부 온라인 서비스에 문제가 있었다고 했고, 다른 기관들의 유사한 문제를 알고 있으며 지켜보고 있다고 밝혔다. 핼리팩스는 앱·온라인 뱅킹 문제를 인정했다. HSBC, 뱅크 오브 스코틀랜드, 로열 뱅크 오브 스코틀랜드, 로열메일, DPD, 라이트무브는 다운디텍터 신고가 몰린 곳으로 보도됐다. 다만 여러 매체가 이들 모두가 구글 장애와 연결돼 있는지는 확인되지 않았다고 짚었다. 헤드라인에 "HSBC·뱅크 오브 스코틀랜드가 다운됐다"고 나온 기사도 있지만, 이 두 곳이 구글 클라우드를 쓰다 장애가 났다는 공식 확인은 찾지 못했다.

금융 밖에서도 영향이 있었다. 영국 법원·심판소청(HMCTS)은 원격 재판용 화상 연결에 문제가 있음을 확인했고, 형사변호사협회는 잉글랜드·웨일스의 많은 법정 변호사가 오전 10시부터 일부 재판을 진행하지 못했다고 밝혔다. 핀뉴스는 독일 DPA 통신을 인용해 ING의 디지털 결제·계좌 서비스도 영향을 받았고, 유럽 여러 나라 사용자가 앱 접속·거래가 간헐적으로 막혔다고 보고했다고 전했다.

아이리시 타임스, 핀뉴스, 셰어캐스트(하그리브스 랜즈다운 게재), 유로위클리뉴스 보도 종합. "공식 확인 없음"은 해당 기업이 구글 장애를 원인으로 밝히지 않았다는 뜻이다.
기관보도된 영향구글 장애와의 연결
레볼루트로그인·송금·카드 결제·ATM 출금 장애레볼루트가 직접 연관성 언급, 블룸버그 소식통도 구글 원인 지목
로이즈·핼리팩스일부 온라인 서비스·앱 문제자사 문제 인정, 원인은 명시 안 함
HSBC·BoS·RBS·ING·로열메일·DPD장애 신고 급증·간헐 장애 보도공식 확인 없음
HMCTS(법원)원격 재판 화상 연결 장애HMCTS가 문제 확인, 원인 연결은 보도 기준
보도와 공식 기록이 엇갈리는 지점
① 시작 시각: 상태 페이지 공지는 07:08 BST, 예비 보고서는 07:00 BST를 사고 시작으로 본다. 07:08은 감지 시각이다. ② Looker Studio: 장애 당일 공지에는 "Looker Studio는 이번 장애의 영향을 받지 않는다"는 문장이 있었지만, 10월 22일 보고서의 영향 제품 목록에는 Looker Studio가 들어 있다. ③ 피해 기관: "유럽 은행 마비"라는 표현이 많이 쓰였지만, 구글 장애가 원인이라고 공개적으로 인정한 곳은 확인된 범위에서 레볼루트뿐이다.

왜 중요한가"멀티 영역이면 안전하다"는 가정이 깨졌다

클라우드 설계 교육에서 가장 먼저 배우는 문장 중 하나가 "가용 영역 하나는 언제든 죽을 수 있으니 여러 영역에 걸쳐 배치하라"다. 이번 사고에서 그 원칙 자체가 틀린 건 아니다. 장애 조치가 되는 DB는 실제로 넘어갔다. 그런데 구글이 직접 인정했듯이 살아 있는 영역에 있던 고객도 영향을 받았다. 이웃 영역이 꺼진 고객 전원의 장애 조치를 동시에 받을 만큼 남은 용량이 넉넉하지 않았고, 일부 관리형 서비스는 제어 평면이 꺼진 영역에 동기식으로 묻고 있었다.

앞쪽 문제는 예약(reservation)이나 평소 여러 영역에 부하를 나눠 두는 식으로 어느 정도 대비할 수 있다. 뒤쪽은 다르다. 관리형 서비스 내부의 영역 간 의존성은 고객이 볼 수도, 고칠 수도 없다. 리전 하나에 모든 것을 둔 서비스라면 "영역 장애 = 리전 부분 장애"가 될 수 있다는 걸 이번에 확인한 셈이다.

금융권 집중 위험 논의도 다시 불붙었다. 아이리시 타임스는 2025년 10월 AWS 장애와 그 일주일 뒤 마이크로소프트 애저의 설정 변경 사고를 함께 언급하며, 소수 클라우드 업체에 대한 의존 문제를 짚었다.

영삼
영삼의 한마디
내 서버들은 대부분 한 대, 한 곳에서 돈다. 그래서 "3개 영역에 나눠 두면 끝"이라는 대형 서비스의 구성이 늘 부러웠는데, 이번 보고서를 읽고 나니 그쪽도 결국 확률을 낮춘 것이지 0으로 만든 건 아니라는 생각이 든다. 눈에 걸린 건 PLC 두 대가 같이 실패했다는 대목이다. 이중화한 장치가 같은 방식으로 같이 죽는다면 그건 이중화가 아니라 복사본에 가깝다. 최종 보고서가 나오면 다시 정리해 볼 생각이다.

개발자가 할 일europe-west2를 쓰고 있다면 점검할 것

점검 체크리스트
  • 단일 영역(zonal) 리소스 목록 뽑기: europe-west2-b 하나에만 있던 VM·디스크·Filestore는 이번처럼 통째로 닿지 않는다. 영역 리소스와 리전 리소스를 구분해 정리한다.
  • 장애 조치 용량 확인: 한 영역이 빠졌을 때 남은 두 영역이 전체 부하를 받을 수 있는지, 그 용량을 예약으로 확보했는지 본다. 이번 사고의 2차 피해는 대부분 용량 부족에서 나왔다.
  • Cloud SQL·AlloyDB HA 설정 확인: 구글 보고서에 따르면 Cloud SQL, AlloyDB, Memorystore, Bigtable처럼 장애 조치가 되는 서비스는 인접 영역으로 넘어갔다. 단일 영역 인스턴스로 운영 중이라면 이번 같은 상황에서 6시간을 그대로 기다려야 한다.
  • 리전 간 대피 경로: 구글이 당일 안내한 우회책은 "다른 영역이나 리전으로 옮기라"였다. 실제로 그게 가능하려면 이미지·데이터·DNS가 다른 리전에 준비돼 있어야 한다.
  • 외부 모니터링: 상태 페이지 첫 공지는 장애 시작 약 2시간 35분 뒤에 올라왔다. 공지보다 먼저 알 수 있게 해 둔다.

자주 묻는 질문

구글 클라우드 런던 장애 원인은?

구글의 예비 사고 보고서에 따르면 europe-west2-b 영역 데이터센터의 전력망 장애가 시작이었다. 비상 발전기를 기동하는 PLC가 주·예비 모두 실패해 UPS 배터리가 소진됐고, 서버와 네트워크 장비가 전원을 잃었다. 근본 원인 분석은 진행 중이며 최종 보고서가 따로 나올 예정이다.

구글 클라우드 europe-west2 장애는 얼마나 지속됐나?

구글 집계로 2026년 10월 20일 07:00부터 13:10(영국 시간)까지 6시간 10분이다. 대부분 서비스는 12:29에 복구됐고, 나머지는 Compute Engine VM 복구가 늦어진 꼬리 구간이다. 잔여 고객 정리 뒤 15:03에 종료 공지가 올라왔다.

이번 장애로 어떤 은행이 영향을 받았나?

레볼루트는 로그인·송금·카드 결제·출금 장애를 겪었고 구글 클라우드 장애와 연관됐다고 밝혔다. 로이즈·핼리팩스도 일부 서비스 문제를 인정했다. HSBC, 뱅크 오브 스코틀랜드 등은 장애 신고가 몰렸다고 보도됐지만 구글 장애가 원인이라는 공식 확인은 없다.

여러 가용 영역에 나눠 두면 영역 장애에도 안전한가?

대부분의 경우 피해를 크게 줄이지만 완전히 막지는 못한다. 이번에는 남은 영역으로 장애 조치 트래픽이 몰려 용량이 포화됐고, 일부 관리형 서비스가 꺼진 영역에 동기식으로 의존하고 있어 다른 영역의 고객도 영향을 받았다. 장애 조치 용량을 미리 확보하고, 필요하면 리전 간 대피 경로까지 준비해야 한다.

구글 클라우드 장애 상태와 보고서는 어디서 확인하나?

status.cloud.google.com의 사고 페이지에서 업데이트 기록과 예비 사고 보고서를 볼 수 있다. 이번 사고 ID는 Xs2XTHzAVC9YnafnPyzj이고, 재발 방지 대책이 담긴 최종 보고서도 같은 페이지에 올라올 예정이다. 영향 범위가 보고서와 다르면 Google Cloud Support에 케이스를 열라고 구글은 안내했다.

출처

댓글 0

아직 댓글이 없습니다.
Ctrl+Enter로 등록