# 사고 보고서: Google Cloud에 의해 차단된 Railway [해결됨] > Clean Markdown view of GeekNews topic #29725. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=29725](https://news.hada.io/topic?id=29725) - GeekNews Markdown: [https://news.hada.io/topic/29725.md](https://news.hada.io/topic/29725.md) - Type: GN+ - Author: [neo](https://news.hada.io/@neo) - Published: 2026-05-21T09:58:21+09:00 - Updated: 2026-05-21T09:58:21+09:00 - Original source: [status.railway.com](https://status.railway.com/incident/I23M92U0) - Points: 1 - Comments: 1 ## Topic Body - **Railway**의 광범위한 서비스 장애는 해결됐으며, 원인은 Railway의 Google Cloud 계정 차단으로 확인됨 - 장애 중 사용자는 `"no healthy upstream"`, `"unconditional drop overload"`, **로그인 실패**, 대시보드 접근 불가를 겪을 수 있었음 - Railway는 **Google Cloud 지원팀**과 직접 연락해 계정 접근을 복구하고, 제어 평면과 워크로드 복구를 진행함 - 복구 과정에서 Google Cloud의 **네트워킹 문제**가 남아 일부 서비스 시작이 막혔고, 비엔터프라이즈 빌드는 일시 제한됨 - 서비스는 완전히 복구됐지만 비정상으로 감지된 일부 **워크로드**는 자동 재배포 중이며, 필요하면 사용자가 직접 재배포해야 함 --- ### 장애 개요와 최종 상태 - Railway는 광범위한 서비스 장애를 해결했으며, 사후 분석은 [Incident Report](https://blog.railway.com/p/incident-report-may-19-2026-gcp-account-outage)에서 확인 가능함 - 장애 기간 동안 사용자는 `"no healthy upstream"`, `"unconditional drop overload"`, 로그인 실패, 대시보드 접근 불가를 겪을 수 있었음 - 원인은 Railway의 **Google Cloud 계정 차단**이며, 일부 Railway 서비스가 사용할 수 없는 상태가 됨 - Railway는 **Google Cloud 지원팀**과 직접 연락해 계정 접근을 복구하고 워크로드 복구를 진행함 - 서비스는 완전히 복구됐지만, 비정상 상태로 감지된 일부 워크로드는 자동 재배포 중이며 응답이 정상적이지 않은 서비스는 사용자가 직접 재배포해야 할 수 있음 ### 복구 경과와 사용자 영향 - ## 초기 조사와 원인 확인 - Railway는 대시보드, API, 내부 네트워크의 **제어 평면**을 구동하는 Google Cloud 인프라를 복구함 - 상위 클라우드 제공자 접근이 복구된 뒤에도 Railway 대시보드와 클라우드 인프라에서 실행되는 서비스는 수정 배포 전까지 계속 영향을 받을 수 있었음 - Google Cloud 계정 차단 이후 Railway 플랫폼 팀은 일부 Google Cloud 호스팅 인프라 접근을 확인하고 나머지 서비스 접근을 복구함 - ## Google Cloud와 네트워크 문제 - Railway는 Google Cloud상의 컴퓨트를 복구했지만, Google Cloud 측 **네트워킹 문제**가 남아 일부 서비스가 시작되지 못함 - 복구 중에는 Google Cloud에서 호스팅되는 워크로드가 간헐적 문제를 계속 겪을 수 있었음 - Railway 인프라 팀은 영향을 받은 서비스를 다시 온라인 상태로 만들기 위한 **대체 경로**도 함께 검토함 - ## 빌드와 배포 제한 - Railway metal 워크로드는 점진적으로 복구되기 시작함 - 복구 과정에서 빌드 인프라 과부하를 피하기 위해 모든 **비엔터프라이즈 빌드**가 일시적으로 제한됨 - 이후 비엔터프라이즈 배포는 일시 중단 상태로 남았고, **엔터프라이즈 배포**는 영향을 받지 않음 - 배포가 다시 가능해진 뒤에도 Google Cloud에 남아 있는 워크로드는 복구 완료 전까지 간헐적 문제를 겪을 수 있었음 - ## 현재 조치 - Railway 서비스는 완전히 복구됐으며, 응답이 정상적이지 않은 서비스는 대시보드나 CLI에서 **재배포**해야 함 - 추가 맥락은 [FAQ](https://station.railway.com/community/what-we-know-so-far-may-19th-2026-86354cdd)에서 확인 가능하고, 직접 지원이 필요하면 [Railway Station](https://station.railway.com)에 스레드를 열 수 있음 ## Comments ### Comment 57970 - Author: neo - Created: 2026-05-21T09:58:22+09:00 - Points: 1 ###### [Hacker News 의견들](https://news.ycombinator.com/item?id=48201484) - Railway가 이 장애를 해결했고 사후 분석을 공개함 [https://blog.railway.com/p/incident-report-may-19-2026-gcp-a...]() 5월 20일 07:57 UTC 기준 상태 페이지도 올라옴 [https://status.railway.com/incident/I23M92U0]() - 이런 경우에는 **Google에 손해배상 청구**가 가능해야 한다고 봄. 네트워크 장애나 서비스 실패처럼 약관에 포함될 만한 문제가 아님 - Railway는 장애가 해결됐다고 하지만 아직 많은 서비스가 **502**를 반환하며 내려가 있음. 우리 쪽은 수동으로 재배포를 트리거해야 복구됐고, Railway가 자동으로 했어야 한다고 봄 전체적으로 우리 쪽 다운타임은 **11시간 초과**였음 - GCP가 또 스타트업을 내려버린 지 0일째임 이런 일은 적어도 1년에 한 번은 보는 것 같고, AWS나 Azure에서는 들어본 적이 없음 진지하게 말하면 그래서 GCP를 쓰지 않음. 빅3 중 가장 쓰기 편한 클라우드인데, 이런 평판 때문에 스스로 망쳐버림 - 반대로 GCP에서 심각한 장애가 난 건 기억이 잘 안 남. AWS/Azure는 1년에 몇 번씩 재앙적으로 내려가는 것 같음 - AWS는 더 효율적으로 함. **us-east-1**이 내려가면 스타트업 여러 곳을 한꺼번에 내려버림 - [https://en.wikipedia.org/wiki/Timeline_of_Amazon_Web_Service...]() Azure도 작년에 Azure와 O365 서비스 전체의 프런트도어를 망가뜨렸음 이 회사들은 각자 잘하는 영역이 있지만, 가끔 크게 망침 - AWS가 우리 서비스를 너무 심하게 **스로틀링**해서 운영할 수 없었던 적이 있음. 그들이 한 달 동안 우리 성장을 멈췄다는 글을 쓰려 했지만 이제는 큰 의미가 없어 보임 - 우리도 같은 이유로 GCP는 건드리지 않음 - 다들 Google을 탓하고 싶어 하지만, Railway를 꽤 오래 써본 입장에서는 결론을 내리기 전에 **GCP의 입장**도 들어보고 싶음. Railway에서도 이런 문제가 전에도 있었고, 그 팀이 처리하는 방식은 신뢰를 주지 못했음 어쨌든 이번 일이 나에게는 마지막 한계였음 - 나도 일화 수준이지만 동의함. Railway 개발팀은 여기저기 **바이브 코딩**을 섞어가며 꽤 느슨하게 움직이는 느낌임. “아직 스타트업이라 좀 봐달라”는 수준이 있고, Railway는 그 선을 넘음 - 맞음. 다른 스레드에서는 클라우드 제공자를 강하게 비판하는 계정들이 많이 보이는데, 정작 이 분노의 흐름에서 **근본 원인**을 궁금해하거나 그 가능성을 따져보려는 태도가 거의 없는 게 이상함 - 2년 전에 지원이 필요했는데 너무 독해서 그냥 Vercel로 옮기고 꺼지라고 했음 다른 서비스에도 비슷한 게 필요해서 찾다가 **coolify**를 발견함. coolify를 쓸 수 있는데 Railway를 쓸 이유는 전혀 없음 - 구체적인 과거 사례를 알려줄 수 있으면 읽어보고 싶음 - 내가 알아서는 안 될 세부 내용을 들었음. 이번 건은 **100% Google 책임**이라고 자신 있게 말할 수 있고, Railway가 더 공유하지 못한다면 실망할 것 같음 GCP를 아예 피하는 것 말고는 Railway가 막을 방법이 정말 없었음 - 2024년 5월 **UniSuper 장애**도 있었음: [https://cloud.google.com/blog/products/infrastructure/detail...]() [https://www.unisuper.com.au/about-us/media-centre/2024/a-joi...]() UniSuper CEO Peter Chun과 Google Cloud CEO Thomas Kurian의 공동 성명에 따르면, UniSuper의 Private Cloud 서비스를 프로비저닝하는 과정에서 부주의한 설정 오류가 발생했고 결국 UniSuper의 Private Cloud 구독이 삭제됨 Google Cloud는 전 세계 어떤 Google Cloud 고객에게도 전례가 없던 고립된 “단 한 번뿐인 사건”이라고 했지만, 이 구독 삭제가 두 지역 모두의 삭제를 유발해 복구에 수백 대의 가상 머신, 데이터베이스, 애플리케이션 복구가 필요했음 - 당시 UniSuper 문제에 대해 글을 썼음: [https://danielcompton.net/google-cloud-unisuper]() 꽤 심각한 버그였고, 그들의 VMWare 환경이 **1년 만료일**을 가진 상태로 생성됐는데 Google Cloud 관점에서는 하나의 “리소스”였음 - “Private Cloud 구독 삭제가 두 지역 모두의 삭제를 유발했다”는 건 **단일 장애점**이라고 부르는 것이고, 안전을 책임져본 사람이라면 누구나 악몽처럼 여길 일임 - 구독을 닫거나 삭제하자마자 전 세계적으로 연쇄 삭제되는 구조는 재앙의 조리법처럼 들림. 왜 삭제 표시만 해두고 하루나 일주일 뒤에 지우지 않는지 모르겠음 - 월 사용액이 큰 회사에서 대체 이런 일이 어떻게 생기는지 모르겠음. 이전 직장에서 AWS에서 의심스러운 워크로드가 돌았을 때는 **TAM**이 조치 전에 먼저 연락했음 이번 건은 뭔가 잘못된 AI 자동화였고, GCP가 사람에게 실제로 연락해 응답받는 걸 싫어하는 듯해서 외주 인력이 몇 시간 뒤 지원 큐에서 보고 정형 답변만 보낸 상황 아니었을까 싶음 - GCP 지원과 관련된 일이라면 이제 아무것도 놀랍지 않음. 우리에게는 전혀 필요 없지만 지난 6년 동안 **Account Executive**가 12명 넘게 바뀌었고, 모두 완전히 쓸모없었음 매번 자기소개를 하고 엔지니어링 인력과 미팅을 잡아달라고 하며, 우리와 전혀 상관없는 정형 슬라이드 덱을 들고 와서 웃음만 나왔고, 다음 연락은 새 AE가 배정됐을 때였음 GCP와 그 서비스들은 좋아하고 수년간 만족했지만, 사람 쪽은 정말 형편없고 왜 굳이 운영하는지도 모르겠음 - 다른 스레드에도 의미 있는 답변이 있었던 것 같음. 우리도 계정을 다시 되찾긴 했지만, **Account Rep**과 CSM이 있어도 무슨 일이 벌어진 건지 파악하는 데 시간이 걸렸음 담당자가 없었다면 더 나빴을 수도 있음 - Google이니까 그럼. 서비스를 쓰게 해주다가, 네가 규범에서 벗어나는 순간 정지시킴 - 공개 API를 운영하는 입장에서 **Railway IP**에서 오는 스팸이 말도 안 되게 많음. 남용 방지가 형편없고, 이번 일이 운영을 개선하는 계기가 됐으면 함 - 호스팅 회사를 운영할 때 핵심 충돌이 바로 이거임. 가입을 쉽게 만들면 신규 사용자가 많이 오지만 **남용**도 많이 들어옴 남용 방지책을 넣으면 시끄러운 오탐이 생기고, 이번 GCP 건도 그럴 수 있음 호스팅 회사를 운영하는 사람은 부럽지 않음. 인터넷은 표면 아래가 정말 지저분함 덧붙이면 AWS는 이 부분을 정말 잘함. 약 30년간의 소매 사기와 남용 대응 경험 덕분일 듯함 - 잠깐, Railway가 GCP 위에서 돌아가는 거였나? “다른 클라우드 위에 클라우드를 만들지 않는다”고 크게 말하지 않았나? 아니면 VPS를 빌리는 게 아니라 클라우드 제공자에게서 베어메탈만 빌린다는 뜻이었나? 적어도 하이퍼스케일러 중 하나에 돈만 내는 게 아니라 코로케이션을 하고 스택을 더 많이 소유하는 다른 제공자가 생겼다고 생각해서 기대했음 [https://blog.railway.com/p/heroku-walked-railway-run]() - Wayback Machine으로 본 연결된 글에는 이렇게 되어 있음 “첫날부터 이 생각을 최전선에 두고 있었다. 또 우리가 직감한 건 다른 클라우드 위에 **클라우드**를 만들 수 없다는 것이다. Railway의 비즈니스, 결국 고객의 비즈니스가 가능한 한 견고하도록 자체 서버를 운영하고 다른 클라우드와 잘 공존하는 실무에 수년을 쏟았다.” - 맞고, 그래서 화남. 그들은 거짓말했음. GCP에 완전히 의존하고 있었음 이제 조사를 좀 해야겠음. 이것보다 좀 더 안정적이고, 한 회사의 변덕에 덜 의존하는 게 필요함 Railway 입장에서도 안 좋은 일인 게, 그들의 큰 주장인 **평화로운 소프트웨어 배포**의 핵심을 바로 찌르기 때문임. 이건 혼돈임 - Railway가 자체 데이터센터를 만들고 있는 줄 알았음 [0] “사실상, 다른 사람의 클라우드 위에 클라우드를 만들 수는 없다.” 정말 그렇네… [0] [https://blog.railway.com/p/launch-week-02-welcome]() - Vercel은 그걸 해내는 것처럼 보임. PlanetScale도 데이터베이스 한정으로는 그렇고, 어차피 모든 것은 데이터베이스임 - Railway에 가입할 때 시스템 남용, 암호화폐 채굴 등에 관한 약관을 읽고 이해했는지 확인하는 방식이 특이함 추측하자면 많은 사용자가 **무료 티어**를 남용해서 서비스 제공자와 문제를 일으키는 듯함 경쟁사 입장이어도 Railway가 이런 타격을 받는 걸 즐겁게 보진 않지만, 무료 컴퓨트는 온갖 이상한 사용자를 끌어들임. 우리도 겪어봤고, 유입 상단이 줄어들더라도 초기에 무료 컴퓨트를 피하기로 했음 - Google만 탓하기는 어렵다고 봄. Railway는 플랫폼 안정성을 유지하는 데 점점 더 어려움을 겪는 것처럼 보임 이런 일이 **전체 서비스**를 내려서는 안 됨. 말 그대로 안정적인 백엔드를 제공하는 게 사업이라면 백업이 있어야 함. 내 눈에는 부실한 계획으로 보임 - 무슨 뜻인지 잘 모르겠음. Railway가 모든 고객 프로젝트를 호스팅하기 위해 **멀티 클라우드 아키텍처**를 써야 한다고 정말 기대하는 건가? 전체적으로 보면 그게 오히려 가용성을 낮출 것 같음 - 재해 복구는 꽤 비싸지 않나? 특히 Railway 규모에서는 더 그럴 듯함