Railway가 Google Cloud에 차단당한 사건, 클라우드 의존의 그림자

무슨 일이 있었나요?

인프라 호스팅 플랫폼으로 잘 알려진 Railway가 어느 날 갑자기 Google Cloud로부터 차단을 당하는 사건이 벌어졌어요. Railway를 모르시는 분들을 위해 잠깐 설명드리면, Heroku나 Vercel처럼 개발자가 코드를 푸시하면 알아서 배포해주는 PaaS(Platform as a Service) 서비스예요. 스타트업이나 개인 개발자들이 복잡한 인프라 설정 없이 빠르게 서비스를 띄우려고 많이 쓰는 플랫폼이거든요.

그런데 이 Railway의 status 페이지에 "Blocked by Google Cloud"라는 무시무시한 제목이 올라왔습니다. 한 마디로 우리가 빌려 쓰던 집주인이 갑자기 문을 잠가버린 상황이 된 거예요. 그것도 사전 통보나 명확한 사유 설명 없이 말이죠.

왜 이게 큰 문제일까요?

Railway 같은 PaaS 회사들은 자체 데이터센터를 직접 운영하기보다는 AWS, GCP, Azure 같은 거대 클라우드 위에 자기네 서비스를 올려두는 경우가 많아요. 이게 뭐냐면, 여러분이 카페를 차리는데 건물을 새로 짓지 않고 임대 건물에 입주하는 것과 비슷해요. 빠르고 효율적이지만, 건물주가 "나가"라고 하면 답이 없는 거죠.

이번 사건이 보여주는 건 하이퍼스케일러(거대 클라우드 사업자)에 대한 의존도 리스크예요. Railway 위에서 돌아가던 수많은 고객사의 서비스가 동시에 영향을 받았고, Railway는 즉시 트래픽을 다른 인프라로 옮기는 작업을 시작해야 했어요. 이게 단순히 한 회사의 문제가 아니라, 그 회사를 신뢰하고 서비스를 올린 수천 개의 다른 개발자, 스타트업까지 도미노처럼 흔들린다는 게 핵심입니다.

비슷한 사례, 그리고 업계 흐름

이런 일은 이번이 처음이 아니에요. 예전에 AWS가 특정 고객사의 계정을 일방적으로 정지시켜서 서비스가 통째로 멈춘 사례도 있었고, Cloudflare가 특정 사이트의 보호를 끊으면서 그 사이트가 사실상 인터넷에서 사라진 일도 있었죠. "클라우드는 결국 누군가의 컴퓨터다(The cloud is just someone else's computer)"라는 농담 같은 진실이 자꾸 현실이 되고 있어요.

그래서 요즘은 멀티 클라우드 전략, 그리고 하이브리드 클라우드 전략이 다시 주목받고 있어요. 한 클라우드에 모든 걸 걸지 않고, AWS와 GCP를 동시에 쓰거나, 핵심 서비스는 자체 베어메탈 서버에 올려두는 식이죠. Railway도 이번 사건 이후로 인프라 다변화 작업을 가속화할 것으로 보입니다. 비슷한 PaaS인 Fly.io나 Render도 이런 리스크에 대한 자체 대응책을 강화하고 있는 추세고요.

한국 개발자에게 주는 시사점

한국에서도 NHN Cloud, 네이버 클라우드, KT 클라우드 같은 국내 클라우드와 AWS, GCP를 같이 쓰는 멀티 클라우드 구성이 점점 늘어나고 있어요. 특히 금융이나 공공 분야는 규제 때문에라도 단일 벤더 종속을 피하는 경향이 강하죠.

실무에서 당장 점검해볼 만한 것들을 정리해드리면, 첫째로 DR(Disaster Recovery, 재해 복구) 계획이 단순히 "백업 잘 받아두자" 수준이 아니라 "다른 클라우드로 30분 안에 옮길 수 있는가" 수준까지 가야 한다는 점이에요. 둘째로, 우리 서비스가 의존하는 PaaS, SaaS가 어떤 인프라 위에서 돌아가는지 한 번쯤 확인해보는 게 좋습니다. 셋째로, 도메인이나 DNS는 가능한 한 클라우드 벤더와 분리해서 관리하세요. 그래야 인프라를 옮길 때 트래픽을 빠르게 전환할 수 있거든요.

마무리

이번 Railway 사건은 결국 "내 서비스의 운명을 다른 회사 손에 얼마나 맡길 것인가"라는 본질적인 질문을 다시 던져줍니다. 편리함과 통제력 사이에서 우리는 어디쯤 서 있어야 할까요?

여러분의 프로젝트는 지금 어떤 클라우드에 얼마나 종속되어 있나요? 만약 내일 그 클라우드가 갑자기 막힌다면, 몇 시간 안에 복구 가능한가요?