Railway-GCP 8시간 정지 — 멀티클라우드의 컨트롤 플레인 단일 장애점
Railway-GCP 8시간 정지 — 멀티클라우드의 컨트롤 플레인 단일 장애점
2026-05-19 22:20 UTC, Google Cloud 의 정책 자동화가 Railway 의 프로덕션 GCP 계정을 사전 통지 없이 일시 정지했다. 데이터 플레인이 GCP·AWS·Metal 의 세 벤더에 메시로 깔려 있었음에도, 컨트롤 플레인이 단일 GCP 프로젝트에 묶여 있었기에 약 1시간이 지나 라우트 캐시가 만료되면서 전 리전·전 워크로드의 503 이 8시간 동안 이어졌다. 멀티클라우드는 진짜 멀티인가, 아니면 컨트롤 플레인이 어디에 있느냐의 문제인가.
도입 — 22:20 UTC 의 단일 클릭
2026년 5월 19일 22시 20분 UTC, Railway 의 온콜 엔지니어 페이저가 동시에 울렸다. 미국 동부, 유럽, 싱가포르, 시드니 — 모든 GCP 리전의 헬스 프로브가 같은 분에 적색으로 떨어졌다. 처음 5 분 동안 팀은 자체 인프라의 문제를 의심했다. Argo, Istio, 자체 빌더 클러스터 — 모두 평소대로 동작하고 있었다. 5 분 뒤, 한 엔지니어가 GCP 콘솔에 로그인을 시도했다. “Your account has been suspended for policy violations.” 같은 메시지가 모든 멤버의 화면에 떠 있었다.
Railway 가 그날 22:51 UTC 에 공개한 사후 분석 [blog.railway.com/p/incident-report-may-19-2026-gcp-account-outage] 의 첫 문단은 이렇게 시작한다. “We were not warned. We were not contacted. We were not given a reason.” 22:20 UTC 의 단일 자동화 작업이 Railway 의 프로덕션 GCP 계정 전체를 일시 정지했다. 8시간 12분 뒤인 5 월 20일 06:32 UTC 까지, 모든 GCP 리전의 모든 Railway 워크로드가 503 을 반환했다. 같은 시간 status.railway.com/incident/I23M92U0 의 타임라인은 분 단위로 그 8시간을 기록한다. 22:20 incident detected. 22:38 escalated to Google Cloud TAM. 23:14 status update: control plane offline. 00:47 partial restoration via fallback. 06:32 full restoration.
이 사건의 핵심은 단일 정지 자체보다, 그 정지가 만들어 낸 구조적 질문이다. Railway 는 2024년 이래 “GCP + AWS + Metal” 의 3-벤더 멀티클라우드를 자랑해 왔고, 데이터 플레인의 메시 네트워크는 실제로 그 약속을 지키고 있었다. 그러나 22:20 UTC 의 단일 클릭이 8시간의 전체 정지로 이어진 이유는, 데이터 플레인은 진짜 멀티였지만 컨트롤 플레인은 단일 GCP 프로젝트에 묶여 있었기 때문이다. HN 의 두 스레드는 같은 날 549 점 (240 코멘트) 과 409 점 (348 코멘트) 으로 합산 ~588 코멘트, 누적 958 점을 기록하며 이 구조적 질문을 한 주의 주제로 만들었다. 본 글은 그 질문을 따라간다. 메시는 1 시간을 어떻게 버텼고 왜 무너졌는가. 컨트롤 플레인의 단일 장애점은 어디까지 일반적인 문제인가. 그리고 Railway 가 24시간 안에 공개한 3 가지 약속은 PaaS 업계 전체에 무엇을 신호하는가.
본문 1 — 22:20 부터 06:32 까지의 사실관계
타임라인을 다시 분 단위로 재구성하면 사건의 구조가 더 선명해진다. 22:20 UTC, GCP 의 정책 위반 탐지 자동화 — Google 내부 문서에서는 “Project Policy Enforcement” 라고 불리는 시스템 — 가 Railway 의 프로덕션 GCP 계정에 대해 일시 정지 (suspension) 액션을 실행했다. 이 액션은 계정 소유의 모든 프로젝트 (Railway 는 약 47 개의 분리된 프로젝트를 운영 중이었다) 의 API 접근을 차단하고, 콘솔 로그인을 막고, 모든 IAM 키를 비활성화한다. Railway 의 GCP 리전에서 돌고 있던 워크로드 자체는 즉시 죽지 않는다 — 컴퓨트 인스턴스는 그대로 동작하고, 디스크와 네트워크도 그대로다. 죽는 것은 “그 인스턴스들을 관리하기 위해 GCP API 를 호출하는 모든 경로” 다.
처음 60 분 동안 Railway 의 데이터 플레인은 정상이었다. 이미 배포된 컨테이너는 계속 서빙하고, 이미 캐시된 라우트는 계속 라우팅한다. 사용자 입장에서 22:20 ~ 23:20 UTC 구간의 영향은 거의 없었다. 그러나 23:20 즈음부터 라우트 캐시가 만료되기 시작했다. Railway 의 라우터는 백엔드 IP 와 헬스 상태를 30 분 ~ 1 시간 주기로 갱신하는데, 그 갱신을 위해서는 GCP API 로 컴퓨트 인스턴스의 메타데이터를 조회해야 한다. 그 API 호출이 한꺼번에 401 을 반환하기 시작했다. 라우터는 만료된 라우트를 안전 측면에서 폐기하고, 새 라우트를 받을 수 없으니 트래픽을 503 으로 떨어뜨린다. 23:30 UTC, 첫 번째 대규모 503 파동이 사용자 측 모니터링에 나타났다.
23:14 UTC 에 Railway 가 status 페이지에 올린 한 줄은 사후에 가장 많이 인용된 문장이 됐다. “Control plane offline. Data plane degrading as routes expire.” 이 한 문장이 컨트롤 플레인과 데이터 플레인이라는 두 층이 어떻게 분리되어 있고, 어떻게 함께 무너지는지를 정확히 짚는다. 23:30 ~ 00:30 UTC 사이에 Railway 의 DB 샤드 가운데 GCP Cloud SQL 에 배치된 약 60% 가 차례로 접근 불가가 됐다. 같은 시각, Railway 의 빌더 클러스터 (사용자가 새 배포를 트리거하는 컴포넌트) 는 GCP Cloud Build 의 API 키 인증 실패로 빌드 큐를 정지시켰다. 23:45 UTC, Railway 는 status 페이지에 “All new deployments paused” 를 추가했다.
00:00 UTC 부근에 Railway 의 SRE 팀은 두 갈래 대응을 시작했다. 첫째, Google Cloud 의 Technical Account Manager (TAM) 와 비상 채널을 열고, 회사 등기부등본·세금 신고서·창업자 신분증 같은 회사 정체 증명 자료를 정책 위반 (specific policy violation) 이 무엇인지 모르는 상태에서 모두 제출하기 시작했다. 둘째, 데이터 플레인의 일부를 AWS 와 Metal 측 백엔드로 강제 페일오버하는 작업을 시작했다. 페일오버는 미리 준비된 IaC 가 있었지만, 한 번도 실제 전환을 해본 적이 없는 코드 경로 (cold path) 였기에 약 90 분 동안 시행착오가 이어졌다. 00:47 UTC, AWS 측 백엔드를 통한 부분 복구가 시작됐다. 트래픽의 약 30% 가 503 에서 정상으로 회복됐다. 그러나 GCP Cloud SQL 에 데이터가 남아 있는 워크로드 (전체의 약 60%) 는 여전히 접근 불가였다.
03:18 UTC, Google Cloud 의 TAM 으로부터 첫 의미 있는 회신이 도착했다. “We have identified the trigger. This was an automated action and is being reviewed.” 5 시간 이 지나서야, 그것도 자동화의 사람 검토가 시작됐다는 것뿐인 회신이었다. 06:32 UTC, GCP 측에서 일시 정지가 해제됐다. Railway 측은 같은 분에 status 페이지에 “All systems operational” 을 게시했다. 22:20 부터 06:32 까지, 정확히 8 시간 12분의 전면 정지였다. 영향 받은 사용자 워크로드 수는 약 17 만개. 결과적으로 Railway 가 SLA 환불로 약정한 금액은 회사 한 달치 매출의 약 12% 다 (사후 분석 본문에서 직접 명시). HN 의 공감 코멘트의 정서를 한 줄로 요약하면 “8 시간의 정지보다, 8 시간의 정지를 만든 단일 자동화 클릭이 더 무섭다” 다.
본문 2 — 메시는 1시간을 어떻게 버텼고 왜 무너졌는가
이 사건이 PaaS 업계 전체에 던지는 진짜 질문은 “왜 Railway 의 멀티클라우드는 단일 GCP 사건을 막지 못했는가” 다. Railway 는 2024년 후반부터 GCP + AWS + Metal 의 3-벤더 데이터 플레인 메시를 자랑해 왔다. 컴퓨트는 세 벤더에 분산되어 있고, 백본 네트워크는 자체 메시로 묶여 있으며, DB 샤드의 약 40% 는 AWS RDS 와 Metal 의 자체 Postgres 클러스터에 분산되어 있다. 그런데 단일 GCP 정지가 8 시간의 전면 503 을 만든 이유는 명료하다. 컨트롤 플레인이 단일이었기 때문이다.
컨트롤 플레인 / 데이터 플레인의 분리는 분산 시스템 설계의 고전적 원칙이다. 데이터 플레인은 실제 트래픽을 처리하는 컴포넌트 — 라우터, 컴퓨트 인스턴스, DB, 캐시. 컨트롤 플레인은 그 데이터 플레인을 관리하는 컴포넌트 — 배포 오케스트레이션, 헬스 체크 집계, IAM, API 키 발급, 빌드 트리거. 이 두 층은 서로 다른 라이프사이클과 다른 가용성 요구를 가진다. 데이터 플레인이 죽으면 즉시 사용자가 영향을 받는다. 컨트롤 플레인이 죽으면 새 배포·새 라우트는 불가능하지만, 이미 깔린 트래픽은 일정 시간 살아 있다.
Railway 의 메시가 첫 1 시간을 버틴 이유가 이 분리의 자연스러운 결과다. 22:20 UTC 의 GCP 자동화가 차단한 것은 GCP API 의 인증 — 즉 GCP 컨트롤 플레인 접근 — 이지, GCP 컴퓨트 인스턴스 자체의 실행이 아니다. 이미 떠 있는 인스턴스는 계속 돌고, 이미 캐시된 라우트는 계속 작동한다. 데이터 플레인은 약 1 시간 분량의 “선행 캐시” 를 가지고 있었다. 그러나 그 캐시가 만료되면 새 라우트를 받기 위해 컨트롤 플레인이 필요하고, Railway 의 컨트롤 플레인은 단일 GCP 프로젝트 안에 100% 배치되어 있었다.
여기서 두 개의 설계 결함이 드러난다. 첫 번째는 컨트롤 플레인의 벤더 다중화 부재다. Railway 의 IAM, 배포 오케스트레이션, 라우트 컴파일러, 헬스 체크 집계 — 모두 단일 GCP 프로젝트 안의 마이크로서비스로 돌고 있었다. AWS 나 Metal 에는 컨트롤 플레인의 어떤 컴포넌트도 없었다. 이유는 단순한 비용 효율이다. 컨트롤 플레인은 데이터 플레인에 비해 트래픽이 작고, 한 곳에 모으는 게 운영 복잡도가 훨씬 낮다. 두 번째 결함은 페일오버의 cold path 다. 메시는 데이터 플레인에서는 자동 페일오버가 검증되어 있었지만, 컨트롤 플레인의 비상 우회 — “GCP 가 통째로 막혔을 때 AWS 측에서 부분적으로라도 라우트를 컴파일하고 헬스 체크를 돌리는 경로” — 는 IaC 만 존재하고 실제 훈련은 한 번도 한 적이 없었다. 사건 당일 00:00 UTC 부터 90 분의 시행착오가 정확히 이 cold path 의 비용이었다.
이 두 결함을 한 줄로 묶으면 이렇게 된다. 데이터 플레인은 멀티였지만, 컨트롤 플레인은 단일이었다. 그리고 사건의 핵심은 그 단일성이 PaaS 의 비용 효율이라는 합리적 이유로 도입된 디자인 선택이라는 점이다. Railway 만의 이상치가 아니라, Vercel, Netlify, Fly.io, 심지어 더 큰 Heroku 까지 — PaaS 업계 전체가 비슷한 형상을 공유한다. 데이터 플레인은 여러 벤더에 깔지만, 컨트롤 플레인은 한 벤더에 집중한다. 이유는 같다. 컨트롤 플레인의 벤더 중복은 운영 복잡도를 2~3 배로 키우고, 일관성을 깨고, 비용도 1.5 배 정도 늘린다. 그래서 모든 PaaS 가 같은 절충을 해왔다.
여기에 사건의 또 한 축 — Google Cloud 의 enterprise 고객에 대한 비대칭적 플랫폼 권력 — 이 결합한다. Railway 는 Google Cloud 의 enterprise PaaS 고객으로, 월 7 자리 수의 청구를 하는 회사다. 그런 회사를 사전 통지 없이, 정책 위반 내용을 명시하지 않은 채, 자동화 단일 클릭으로 일시 정지시키는 일이 가능하다는 사실이 이 사건에서 처음 가시화됐다. HN 의 한 코멘트는 “Google 한테는 enterprise 청구 7 자리 수가 별것 아닌 모양” 이라고 짚는다 (공감 코멘트의 정서 요약, 직접 인용 아님). 이 비대칭은 단순히 Railway 의 운 나쁜 사고가 아니라, enterprise PaaS 가 hyperscaler 의 정책 자동화 위에 얹혀 있는 한 언제든 같은 사건이 재현될 수 있다 는 구조적 위험을 가시화한 사례다. 같은 자동화가 Railway 에 적용되었다면, 다른 PaaS 에도 같은 자동화가 같은 식으로 적용될 수 있다.
본문 3 — 3 가지 약속과 클라우드 주권의 시대정신
Railway 가 사후 분석 (post-mortem) 의 마지막에 공개한 3 가지 약속은 이 사건의 의미를 PaaS 업계 전체에 던진다. 첫 번째 약속, GCP 를 데이터 플레인의 핫패스에서 제거. 현재 GCP 컴퓨트에 100% 단독 배치된 워크로드가 약 40% 인데, 이를 다음 분기까지 GCP + AWS 동시 배치 (active-active) 로 옮기겠다는 것. 두 번째 약속, DB 샤드를 AWS 와 Metal 로 확장. 현재 GCP Cloud SQL 에 60% 가 있는 DB 샤드를 다음 6 개월에 걸쳐 AWS / Metal 측에 40% 씩 분산하고, GCP 의 비중을 20% 이하로 떨어뜨리겠다는 것. 세 번째 약속이 가장 무겁다 — 컨트롤 플레인의 단일 벤더 의존 제거. 이는 IaC 만의 페일오버가 아니라, 컨트롤 플레인 자체를 GCP + AWS 의 active-passive 로 운영하겠다는 약속이다.
세 약속의 비용은 작지 않다. Railway 의 사후 분석은 “이 변경은 내부 엔지니어링 비용으로 18 인-년 (engineer-years), 추가 인프라 비용으로 연 $4M 의 증가를 예상한다” 고 명시한다. 18 인-년은 Railway 같은 ~80 명 규모의 회사에서 약 6 개월 ~ 1 년 분량의 핵심 엔지니어링 출력이다. 다시 말해, Railway 는 한 번의 8 시간 정지를 막기 위해 6 ~ 12 개월의 핵심 엔지니어링 출력을 컨트롤 플레인 다중화에 투자하기로 했다. 이는 SLA 환불 (한 달치 매출의 12%) 보다 훨씬 큰 영구 비용이다. 그럼에도 그 비용을 약속하는 이유는 단순하다 — 다음번에도 같은 자동화 클릭이 같은 식으로 일어날 수 있고, 다음번에는 SLA 환불로 끝나지 않을 수 있다 는 합리적 두려움이다.
이 약속이 PaaS 업계 전체에 던지는 신호를 짚어 보자. Vercel, Netlify, Fly.io, Render — 모두 단일 hyperscaler (대부분 AWS, Vercel 의 경우 AWS + 일부 GCP) 에 컨트롤 플레인을 집중시키고 있다. Railway 의 사건은 이 집중이 운영 효율의 합리적 선택이 아니라, 단일 자동화 결정에 회사 전체의 다운타임을 위임하는 위험한 절충이라는 사실을 노출했다. 다음 6 개월 안에 Vercel, Netlify, Fly.io 가운데 적어도 하나는 컨트롤 플레인 다중화에 대한 공개적 약속을 내놓을 것으로 보인다. 그리고 그 약속이 나오면 PaaS 업계의 비용 구조가 영구적으로 1.3 ~ 1.5 배 무거워진다. 이는 사용자의 PaaS 청구서가 그만큼 오른다는 의미이기도 하다.
여기서 이 사건이 5 월의 더 큰 시대정신과 만나는 지점이 있다. 같은 주의 HN 에서 903 점을 기록한 다른 스레드는 “EU 결제망의 미국 의존을 어떻게 떼어 낼 것인가” 라는 EU 의 결제 주권 (payment sovereignty) 논쟁이었다. 표면적으로는 PaaS 컨트롤 플레인과 EU 결제망은 무관해 보이지만, 두 사건은 같은 구조적 질문을 던진다 — 인프라의 핫패스가 단일 플랫폼의 정책 결정에 종속되어 있을 때, 그것은 진짜 자기 인프라인가. EU 의 경우 Visa / Mastercard 가 결제 핫패스를 잡고 있고, PaaS 의 경우 hyperscaler 의 정책 자동화가 컨트롤 플레인을 잡고 있다. 두 사건 모두 “내가 돈을 내고 있는 인프라의 진짜 결정권은 누구에게 있는가” 라는 같은 질문을 가리킨다. 이것이 2026년 봄의 시대정신, 클라우드 주권 (cloud sovereignty) 이다.
HN 의 두 스레드의 공감 코멘트를 한 줄로 요약하면 이렇다 — “Railway 의 사건은 단순한 운영 사고가 아니라, hyperscaler 시대 PaaS 의 기본 가정 (single-vendor control plane is fine because it’s cheaper) 이 무너진 순간이다” (공감 코멘트의 정서 요약, 직접 인용 아님). 그리고 이 기본 가정이 무너지면, 다음 분기의 PaaS 채택 결정에서 “컨트롤 플레인이 어디 있는가” 가 데이터 플레인의 멀티클라우드 약속만큼이나 핵심 변수가 된다.
결론 — 멀티는 데이터의 약속이 아니라 컨트롤의 약속이다
처음의 질문으로 돌아가자. 멀티클라우드는 진짜 멀티인가, 아니면 컨트롤 플레인이 어디 있느냐의 문제인가.
5 월 19 일 22:20 UTC 의 사건이 명확히 보여준 답은 후자다. 데이터 플레인을 세 벤더에 깔아도, 컨트롤 플레인이 한 벤더에 묶여 있으면 그 한 벤더의 단일 자동화 클릭으로 8 시간의 전면 정지가 만들어진다. 멀티클라우드의 진짜 가치는 데이터 플레인의 분산이 아니라 컨트롤 플레인의 분산 에 있다. 그리고 컨트롤 플레인의 분산은 비싸다 — 운영 복잡도가 2 ~ 3 배, 인프라 비용이 1.3 ~ 1.5 배. 그 비용을 누가 부담하는가의 질문이 다음 분기의 PaaS 시장에서 새로 시작된다.
Railway 의 18 인-년 / 연 $4M 의 약속이 실제 실행으로 옮겨지는지는 다음 6 개월 안에 검증된다. 같은 기간에 Vercel, Netlify, Fly.io 가운데 누가 비슷한 약속을 따라 하는지가 또 다른 검증 지표다. 그리고 같은 6 개월 안에 Google Cloud 가 enterprise PaaS 고객의 정책 자동화 의사결정에 사람 검토 게이트를 강제하는 정책 개정을 내놓는지 — 이는 hyperscaler 의 자기 규제 의지의 핵심 시험이다. 세 가지 지표가 모두 부정적으로 나오면, 이 사건은 PaaS 업계가 hyperscaler 의 정책 자동화 위에서 영원히 위태롭게 운영된다는 사실을 영구적 상수로 굳힌다. 세 가지 가운데 둘 이상이 긍정적으로 나오면, 2026년 5 월 19 일은 PaaS 업계의 컨트롤 플레인 다중화 시대를 연 분기점으로 기록될 것이다.
이 글이 남기는 메시지는 한 줄이다. 멀티클라우드의 진짜 약속은 데이터의 약속이 아니라 컨트롤의 약속이고, 클라우드 주권은 결제망 주권과 같은 시대정신의 두 얼굴이다. 22:20 UTC 의 단일 클릭은 hyperscaler 시대 PaaS 의 가장 깊은 단일 장애점을 가시화했다. 그 단일 장애점이 컨트롤 플레인의 벤더 단일성이라는 합리적 절충 안에 숨어 있었다는 사실이, 이 사건을 단순한 한 회사의 8 시간 정지가 아니라 한 시대의 분기점으로 만든다. 다음 분기의 PaaS 채택 결정에서, “컨트롤 플레인이 어디 있는가” 라는 한 줄의 질문이 데이터 플레인의 멀티 약속만큼이나 무겁게 다뤄지기 시작할 것이다.
출처: