Railway가 GCP에서 갑자기 계정 정지를 당했을 때 벌어진 일

클라우드를 빌려 쓴다는 것의 리스크

2026년 5월 19일, 인기 PaaS(Platform as a Service, 코드만 올리면 배포해주는 서비스)인 Railway가 자사 블로그에 충격적인 인시던트 리포트를 올렸어요. 자신들의 Google Cloud Platform(GCP) 계정이 사전 경고 없이 정지됐고, 그 결과 일부 고객 서비스가 다운됐다는 내용이었거든요. 이런 일이 왜 중요하냐면, Railway는 수많은 스타트업과 인디 개발자들이 "AWS는 복잡하니까 Railway 쓸래" 하면서 의존하고 있는 인프라거든요. 그 인프라가 또 다른 인프라(GCP)에 올라가 있다는 사실이 이번 사건으로 노출된 거예요.

클라우드 시대의 위험성을 정확히 드러내는 사건이라 한 번 짚고 넘어갈 가치가 있어요. 우리가 "클라우드에 올린다"고 할 때, 사실 그 클라우드 위에 또 클라우드가 있고, 그 위에 또 우리 서비스가 있는 다층 구조거든요. 그중 어느 한 층이 흔들리면 다 같이 흔들려요.

무슨 일이 일어났을까

Railway가 공개한 인시던트 리포트를 보면, GCP가 보낸 정지 통보의 이유는 "의심스러운 활동(suspicious activity)" 이었어요. 구체적으로는 Railway 플랫폼에서 돌아가던 일부 고객 워크로드가 GCP의 자동 위협 탐지 시스템에 걸린 거예요. 문제는 Railway 같은 PaaS는 본질적으로 "수많은 고객의 알 수 없는 코드를 대신 돌려주는" 비즈니스라는 점이에요. 어떤 고객은 크롤러를 돌리고, 어떤 고객은 봇을 만들고, 어떤 고객은 미디어 인코딩을 해요. 이게 자동화된 시스템 입장에선 "비정상 패턴"으로 보일 수 있거든요.

더 큰 문제는 사전 경고가 없었다는 점이에요. 보통 엔터프라이즈 계약을 맺으면 "이런 활동이 감지됐으니 며칠 안에 해명해주세요" 같은 절차가 있어야 하는데, Railway는 통보를 받자마자 일부 리소스에 접근이 막혔다고 해요. 그래서 영향받은 고객들의 데이터베이스, 빌드 시스템, 일부 워크로드가 같이 멈춰버린 거예요.

Railway 팀은 사건 발생 후 GCP의 담당자들과 긴급 연락을 취해서 단계적으로 복구를 진행했고, 동시에 영향받은 워크로드를 다른 리전이나 다른 클라우드 제공자로 옮기는 작업도 시작했어요. 인시던트 리포트에서 Railway는 "단일 클라우드 의존도를 줄이고 멀티 리전·멀티 클라우드 전략을 가속화하겠다"고 밝혔어요.

이게 처음이 아니에요

사실 이런 사건은 처음이 아니에요. 2022년에는 한 인디 개발자가 구글 포토에 아이 사진을 올렸다가 "아동 학대 의심"으로 분류돼서 전체 구글 계정이 정지된 사건이 있었어요. 2024년엔 UniSuper라는 호주 연금 회사의 GCP 계정이 GCP 내부 오류로 통째로 삭제되는 일도 있었고요. 모두 공통점은 "플랫폼 사업자의 일방적 결정으로 사용자 비즈니스가 중단된다" 는 거예요.

그래서 업계에서는 "플랫폼 리스크(platform risk)" 라는 표현을 쓰기 시작했어요. AWS, GCP, Azure 같은 하이퍼스케일러에 모든 걸 맡기면 운영은 편하지만, 그쪽에서 "안 됩니다" 한마디면 비즈니스가 끝날 수 있다는 거죠. 그래서 일부 회사들은 의도적으로 멀티 클라우드를 가져가거나, 핵심 데이터는 자체 데이터센터에 두는 "리패트리에이션(repatriation, 다시 자기 인프라로 가져오기)" 전략을 쓰고 있어요. 대표적으로 37signals(Basecamp 만든 곳)가 AWS에서 자체 서버로 옮기면서 비용도 절감하고 플랫폼 리스크도 줄였다고 공개했었죠.

PaaS 모델의 본질적 딜레마

Railway나 Vercel, Render, Fly.io 같은 PaaS들이 매력적인 이유는 "인프라를 신경 쓰지 않아도 된다"는 거예요. 하지만 그 매력의 이면에 "이 PaaS도 어딘가의 클라우드를 빌리고 있다" 는 사실이 있어요. PaaS 입장에선 자체 데이터센터를 짓는 건 너무 비싸니까 AWS나 GCP 위에 올라타는 게 현실적이거든요. 그런데 그 위에 또 고객들이 올라타면, 한 층이 무너질 때 도미노처럼 다 무너지는 거예요.

이번 Railway 사건은 PaaS 사업자들에게 멀티 클라우드 아키텍처가 선택이 아니라 필수라는 신호를 보낸 셈이에요. 한 클라우드 제공자에 종속되면 그쪽의 정책 변화, 자동화 오탐, 가격 인상에 무방비로 노출되거든요.

한국 개발자가 챙겨야 할 포인트

첫째, 자기 서비스가 어떤 인프라 위에 올라가 있는지 정확히 파악하세요. Railway, Vercel, Supabase 같은 서비스를 쓴다면, 그 서비스가 다시 어떤 클라우드를 쓰는지, 어느 리전을 쓰는지까지 알고 있는 게 좋아요. 장애가 났을 때 "왜 안 되지?"의 추적 범위가 그만큼 넓어지거든요.

둘째, 백업과 데이터 export 전략을 미리 세워두세요. PaaS는 편리하지만, 그곳에 데이터가 묶이면 옮기기 어려워요. 정기적으로 데이터베이스 덤프를 받아두거나, 코드와 환경 변수를 별도 저장소에 보관해두는 것만으로도 큰 차이가 나요. 진짜 위기 상황에서 "우리 데이터 어디 있죠?"가 안 되도록요.

셋째, 인프라 결정을 할 때 "플랫폼 리스크"를 한 줄이라도 검토 항목에 넣으세요. 스타트업 초기엔 속도가 중요하니까 PaaS를 쓰는 게 맞아요. 하지만 매출이 발생하기 시작하면, 핵심 워크로드만이라도 멀티 클라우드나 자체 인프라로 분산하는 시점을 정해두는 게 좋아요.

마무리

Railway 인시던트는 "클라우드는 마법이 아니다" 라는 걸 다시 일깨워준 사건이에요. 우리가 빌려 쓰는 인프라 위에서 우리 서비스가 돌아간다는 사실, 그 인프라 사업자도 또 다른 누군가의 결정에 따라 움직인다는 사실을 잊으면 안 돼요.

여러분의 서비스는 지금 어떤 클라우드 의존도를 갖고 있나요? 만약 메인 클라우드가 갑자기 막힌다면, 며칠 안에 복구할 수 있는 시나리오를 갖고 있으세요?