클라우드 거인이 한 회사를 지웠다: Railway가 겪은 GCP 계정 정지의 충격

어느 날 아침, 회사 인프라가 통째로 사라진다면 어떨까요. 영화 속 이야기 같지만, 최근 클라우드 호스팅 스타트업 Railway가 실제로 겪은 일입니다. 단 한 통의 통보 메일과 함께 Google Cloud Platform(GCP) 계정이 정지되면서, 수많은 고객 서비스까지 함께 흔들렸습니다. 이 사건은 “클라우드에 올렸으니 안전하다"는 우리의 막연한 믿음에 정면으로 의문을 던집니다.

무슨 일이 있었나

Railway는 개발자들이 코드를 푸시하면 자동으로 배포까지 처리해주는 PaaS(Platform-as-a-Service) 회사입니다. 비유하자면, AWS·GCP 같은 거대 인프라 위에 한 겹 더 얹어 “개발자가 인프라를 신경 쓰지 않게 해주는” 중간 계층 사업자입니다.

문제는 바로 그 “한 겹 아래"에 있었습니다. Railway의 사업 기반 일부가 GCP 위에 올라가 있었는데, 어느 날 GCP가 사전 경고 없이 계정을 정지시켜 버렸습니다. Railway의 서비스를 쓰던 수많은 스타트업과 사이드 프로젝트들이 동시에 영향을 받았습니다. 사용자 입장에서는 “내가 쓴 적도 없는 GCP가, 왜 내 서비스를 죽이는가"라는 황당한 상황이 벌어진 셈입니다.

왜 이게 무서운 일인가

이 사건이 단순한 장애와 다른 이유는 복구 주체가 자신이 아니라는 데 있습니다. 서버가 다운되면 엔지니어가 새벽에라도 일어나 고칠 수 있습니다. 그런데 클라우드 사업자가 “당신 계정을 닫았다"고 하면, 할 수 있는 일은 고객센터 메일을 보내고 답장을 기다리는 것뿐입니다.

더 심각한 건 도미노 구조입니다. 내가 Railway를 쓰고, Railway는 GCP를 쓴다고 합시다. GCP가 Railway 계정을 끊으면, 나는 아무 잘못이 없어도 서비스가 멈춥니다. 클라우드 시대의 의존성 사슬은 이렇게 길고, 그 사슬의 어느 한 마디만 끊겨도 끝단의 작은 회사는 흔적도 없이 사라질 수 있습니다.

거인의 변덕, 자동화된 정지

업계에서 구글의 계정 정지는 악명이 높습니다. 개인 Gmail부터 YouTube 채널, GCP 프로젝트까지, 알고리즘이 한 번 “이상하다"고 판단하면 사람과의 대화는 끼어들 틈이 없습니다. 항소 절차가 있긴 하지만, 답변은 형식적이고 복구까지 며칠에서 몇 주가 걸리는 경우도 흔합니다.

기업 고객이라고 크게 다르지 않다는 게 이번에 드러난 핵심입니다. 결제 이슈, 보안 이슈, 약관 해석 이슈, 어떤 이유든 알고리즘이 트리거되면 비즈니스 전체가 인질로 잡힙니다. 그리고 그 사이 매출은 0으로 수렴합니다.

스타트업이 던져야 할 진짜 질문

이번 사태를 본 개발자 커뮤니티의 반응은 둘로 갈립니다. “그러니까 AWS로 옮겨야 한다"는 쪽과 “AWS도 본질은 같다"는 쪽입니다. 후자가 더 정확합니다. 문제는 GCP가 특별히 나빠서가 아니라, 단일 사업자에게 모든 것을 맡긴 구조에 있습니다.

그래서 진짜 질문은 이겁니다. “우리 회사가 내일 클라우드 계정이 정지된다면, 며칠 만에 다른 곳에서 서비스를 띄울 수 있는가?” 데이터 백업은 클라우드 바깥에 있는지, 인프라 구성을 코드로 관리(IaC)해서 다른 환경에 복제 가능한지, 결제와 도메인과 인증서가 한 계정에 묶여 있지는 않은지. 답이 “잘 모르겠다"라면, 그게 바로 가장 큰 리스크입니다.

클라우드는 전기가 아니다

우리는 종종 클라우드를 “전기” 같은 인프라로 여깁니다. 켜면 들어오고, 끄면 나가는. 하지만 전기회사는 요금만 내면 당신을 끊지 않습니다. 클라우드 사업자는 약관 해석 하나로 당신을 끊을 수 있고, 그 결정을 내리는 건 사람이 아니라 자동화된 시스템입니다.

Railway 사태는 작은 회사의 운영 사고가 아니라, 클라우드 시대 비즈니스의 구조적 취약점을 드러낸 사건입니다. 여러분의 서비스는 지금 몇 개의 계정 정지 한 통에 매달려 있습니까. 한 번쯤은, 진지하게 물어볼 시간입니다.