Google Cloud 계정 제한이 촉발한 5월 19일 Railway 대규모 장애

2026년 5월, 개발자 플랫폼 Railway는 몇 시간 동안 대시보드·API·배포 시스템·호스팅 애플리케이션이 모두 접근 불가능해지는 대규모 장애를 겪었다. 사건의 직접적인 원인은 Google Cloud가 Railway의 프로덕션 계정을 자동으로 ‘restricted(제한)’ 상태로 전환한 것이었다. 이 조치로 핵심 인프라 리소스에 대한 접근이 즉시 차단되었다.

서비스는 결국 복구됐지만, 이 사건은 현대 클라우드 아키텍처에서 단일 클라우드 계정이 얼마나 큰 단일 장애 지점(single point of failure)이 될 수 있는지를 보여주는 사례가 됐다.

장애 발생 타임라인

장애는 5월 19일 22:20~22:29 UTC 사이 시작된 것으로 보고됐다. 이 시점에 Railway 시스템이 Google Cloud의 핵심 리소스에 접근하지 못하기 시작했다. 곧바로 사용자들이 문제를 보고했다.

• 대시보드가 로드되지 않음
• 로그인 실패
• 운영 중이던 애플리케이션에서 upstream 오류 발생
• 일부 도메인에서 404 또는 “no healthy upstream” 오류

Railway 엔지니어들은 이후 업데이트에서 Google Cloud 계정이 ‘restricted’ 상태로 전환되면서 여러 리소스가 동시에 제거되었다고 설명했다.

복구에는 몇 시간이 걸렸고, Railway 팀은 Google Cloud 지원팀과 협력해 계정 접근을 복구해야 했다. 커뮤니티 보고에 따르면 계정 담당자와 엔터프라이즈 지원 채널이 있었음에도 제한이 발생한 원인을 파악하는 데 시간이 걸렸다고 한다.

왜 핵심 서비스가 동시에 멈췄나

계정 제한은 Railway 플랫폼의 고객 워크로드와 내부 제어 시스템 모두가 의존하던 인프라에 영향을 줬다.

Railway가 밝힌 바에 따르면 다음과 같은 주요 구성요소가 한 번에 사라졌다.

• CloudSQL: 플랫폼 데이터 저장
• Railway API: 플랫폼 핵심 서비스
• Overflow VM: 추가 컴퓨팅 용량을 제공하던 가상머신

특히 플랫폼 API가 제거되면서 제어 시스템(control plane)의 핵심 의존성이 사라졌고, 그 위에 구축된 여러 시스템이 동시에 영향을 받았다.

이 때문에 다음 기능들이 정상적으로 동작하지 않았다.

• 대시보드 및 로그인 시스템
• 애플리케이션 배포
• 실행 중인 서비스 라우팅
• 빌드 및 새 인프라 프로비저닝

결과적으로 개발자 인터페이스와 실제 운영 중인 애플리케이션 모두가 불안정하거나 접근 불가능한 상태가 됐다.

장애가 플랫폼 전체로 확산된 이유

문제는 단순히 몇 개의 VM이 사라진 것이 아니었다. 플랫폼의 오케스트레이션과 라우팅 시스템 자체가 영향을 받은 것이 핵심이었다.

Railway는 일부 사용자에게 애플리케이션을 다시 배포(redeploy)하면 정상 머신으로 라우팅될 수 있다고 안내했다. 이는 워크로드 스케줄링과 라우팅을 담당하는 제어 시스템이 완전히 자동 복구되지 않았음을 시사한다.

커뮤니티 분석에서는 Google Cloud 외부에서 실행되던 워크로드—예를 들어 AWS나 Railway 자체 하드웨어—도 영향을 받았을 가능성이 제기됐다. 이는 플랫폼의 라우팅 상태나 제어 데이터가 갱신되지 못했기 때문일 수 있다. 다만 정확한 기술적 메커니즘은 공식 포스트모템이 공개되지 않아 아직 확정된 것은 아니다.

“멀티클라우드”의 한계가 드러난 사건

이번 사건에서 가장 많이 언급된 교훈은 아키텍처 설계와 관련된 부분이다.

Railway는 실제로 AWS, Google Cloud, 그리고 자체 하드웨어 등 여러 환경에 인프라를 분산해 운영하고 있다. 하지만 장애는 여전히 플랫폼 전체에 영향을 미쳤다.

이유는 간단하다.

제어 시스템(control plane)이 어디에 있느냐가 진짜 회복력을 결정하기 때문이다.

배포 관리, 라우팅 설정, 인증 시스템, 플랫폼 데이터베이스가 특정 클라우드 계정에 의존한다면 그 계정은 사실상 전체 플랫폼의 핵심 장애 지점이 된다.

계정이 제한되자 단순히 컴퓨팅 리소스만 잃은 것이 아니라 다음 시스템도 동시에 영향을 받았다.

• 배포 상태 관리
• 서비스 라우팅
• 인프라 프로비저닝
• 장애 복구 로직

그 결과 단 하나의 계정 제한 이벤트가 전체 플랫폼 장애로 이어졌다.

자동화된 클라우드 계정 제한에 대한 우려

이번 사건은 또 하나의 논쟁을 불러왔다. 바로 대형 클라우드 서비스의 자동 계정 제재 시스템이다.

클라우드 제공자는 다음과 같은 신호에 따라 계정을 자동으로 제한하거나 정지할 수 있다.

• 결제 문제
• 정책 위반
• 보안 이상 징후

하지만 이번 사건에서 Google Cloud가 계정을 제한한 정확한 이유는 공개되지 않았다. 자동 정책 집행인지, 실수인지, 다른 운영 이슈인지도 아직 확인되지 않았다.

이 때문에 두 가지 운영 리스크가 다시 강조됐다.

• 자동화된 계정 조치가 핵심 인프라를 즉시 중단시킬 수 있다
• 엔터프라이즈 지원 계약이 있어도 원인 파악과 복구에 시간이 걸릴 수 있다

아직 밝혀지지 않은 부분

Railway의 업데이트와 커뮤니티 보고가 있었지만 몇 가지 핵심 정보는 여전히 공개되지 않았다.

• Google Cloud가 계정을 제한한 정확한 이유
• CloudSQL, API, 라우팅, 컴퓨팅 인프라 사이의 정확한 내부 의존 구조
• 일부 확산 효과(예: 라우팅 캐시 문제)가 공식적으로 확인된 것인지 여부

따라서 현재까지의 설명은 Railway 발표와 커뮤니티 분석을 기반으로 한 부분적인 재구성에 가깝다.

이번 사건이 남긴 가장 큰 교훈

5월 19일 Railway 장애는 현대 클라우드 인프라의 중요한 현실을 보여준다.

여러 클라우드를 사용한다고 해서 자동으로 높은 회복력이 보장되는 것은 아니다.

배포·라우팅·오케스트레이션을 담당하는 제어 시스템이 하나의 클라우드 계정에 의존한다면, 그 계정이 잠시라도 사라지는 순간 전체 플랫폼이 동시에 멈출 수 있다.

스타트업과 인프라 플랫폼 모두에게 이번 사건은 익숙하지만 종종 과소평가되는 문제를 다시 상기시켰다.

“모든 것을 관리하는 시스템” 자체에 숨은 단일 장애 지점이 없는지 확인하는 것.