클라우드가 당신을 차단할 때: Railway GCP 장애로부터 얻는 교훈
2026년 5월 19일, PaaS 제공업체인 Railway는 사용자들이 대시보드, API 및 호스팅된 워크로드에 접근할 수 없게 만드는 대규모 서비스 중단 사태를 겪었습니다. 원인은 갑작스러우면서도 치명적이었습니다. Railway의 주요 인프라 제공업체 중 하나인 Google Cloud Platform (GCP)이 그들의 계정을 차단한 것이었습니다.
이 사건은 현대 클라우드 스택의 취약성을 극명하게 보여주는 사례입니다. Platform-as-a-Service (PaaS) 제공업체가 다른 클라우드 제공업체 위에 전체 서비스를 구축할 경우, 자동화되었든 수동이든 단 한 번의 관리적 조치가 수천 명의 사용자 생태계를 통째로 날려버릴 수 있습니다.
장애의 구조
Railway의 상태 업데이트에 따르면, 장애는 5월 19일 22:29 UTC경에 시작되었습니다. 사용자들은 처음에 "no healthy upstream" 및 "unconditional drop overload"와 같은 일반적인 오류를 메시지를 보았습니다. 한 시간 이내에 Railway는 근본 원인이 Google Cloud에 의한 계정 차단임을 확인했습니다.
높은 매출을 기록하는 고객임에도 불구하고, Railway는 위태로운 상황에 처했습니다. 결국 일부 인프라에 대한 접근 권한을 되찾았지만, 복구는 즉각적이지 않았습니다. 컴퓨팅 리소스가 복구된 후에도 GCP 측의 네트워킹 이슈로 인해 서비스가 시작되지 못해 장애가 다음 날까지 이어졌습니다.
'클라우드 위의 클라우드' 딜레마
Hacker News에서의 커뮤니티 반응은 반복되는 아키텍처적 위험인 "cloud-on-a-cloud" 모델을 강조했습니다. Railway의 창업자는 이후 X를 통해 그들의 네트워크가 AWS, GCP, 그리고 bare metal 간의 메쉬 링(mesh ring) 구조라고 설명했습니다. 하지만 이번 사건은 결정적인 취약점을 드러냈습니다. 제어 평면(control plane)—대시보드, API, 내부 네트워크—이 GCP에 과도하게 의존하고 있었습니다.
한 댓글 작성자는 "단순히 다른 사람의 클라우드 위에 클라우드를 구축할 수는 없다"라고 언급했습니다. 이러한 의존성은 전통적인 고가용성(high availability)을 초월하는 단일 장애점(single point of failure)을 생성합니다. 데이터가 여러 리전에 따라 복제되어 있더라도, 계정 수준의 차단은 해당 복제본들을 무용지물로 만듭니다.
인간(및 자동화된) 요소
많은 논의는 왜 주요 계정이 경고 없이 차단되었는지에 집중되었습니다. 추측은 잘못된 AI 에이전트부터 남용 방지 트리거까지 다양했습니다.
한 특히 통찰력 있는 관찰은 Railway의 자체 사용자 기반을 지적했습니다. 일부 사용자들은 장애 직후 봇(bot) 및 토렌트 배포와 관련된 새로운 이용 약관을 확인했다고 보고했습니다. 이는 Railway의 IP가 암호화폐 채굴이나 스팸과 같은 남용 사례로 플래그가 지정되어 GCP의 자동화된 안전 프로세스를 트리거했을 가능성을 시사합니다.
"공공 API를 운영하는 사람으로서, Railway IP로부터 발생하는 스팸의 양은 엄청납니다. 그들은 남용 방지 조치가 끔찍합니다."
만약 PaaS 제공업체가 자신의 사용자를 제대로 관리하지 못한다면, 상위 제공업체(GCP)는 고객의 규모와 관계없이 자신의 네트워크를 보호하기 위해 "파괴적인(wrecking ball)" 방식을 취할 수 있습니다.
인프라에 대한 더 넓은 시사점
이 사건은 2024년 5월 UniSuper 사건과 같이 다른 고위험 GCP 장애 사례를 반영합니다. 당시에는 프로비저닝 과정에서의 설정 오류로 인해 여러 지역에 걸친 프라이빗 클라우드 구독이 삭제되었습니다.
엔지니어와 아키텍트에게 주는 교훈은 명확합니다:
- 폭발 반경 보호 (Blast Radius Protection): 모든 복제본이 단일 클라우드 계정 내에 존재한다면 전통적인 백업(3-2-1 규칙)은 불충분합니다. 계정 수준의 장애는 지역적 장애와는 별격의 위험 범주입니다.
- 벤더 다각화 (Vendor Diversification): 핵심 제어 평면을 단일 하이퍼스케일러(hyperscaler)에 의존하는 것은 스타트업에게 실존적 위험입니다.
- '누군가의 컴퓨터'라는 현실: 클라우드는 추상적인 유틸리티가 아닙니다. 그것은 법적 및 관리적 계약입니다. 제공업체가 그 계약을 계약 해지할 경우, 인프라는 사라집니다.
결론
Railway의 장애는 단순한 기술적 실패가 아니라 신뢰와 리스크 관리의 실패였습니다. 서비스는 결국 복구구되었지만, 이 사건으로 인해 여러 사용자가 Render 또는 Fly.io와 같은 경쟁사로 이전하기 시작했습니다. 클라우드를 기반으로 구축하는 이들에게 주는 교훈은 간단합니다: 의존성을 다각화하거나, 당신이 한 번도 대화해 본 적 없는 누군가에 의해 '꺼짐' 스위치가 내려갈 날을 대비하십시오.