# 장애 보고서: 2026년 5월 19일 – GCP 계정 중단 > Clean Markdown view of GeekNews topic #29740. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=29740](https://news.hada.io/topic?id=29740) - GeekNews Markdown: [https://news.hada.io/topic/29740.md](https://news.hada.io/topic/29740.md) - Type: GN+ - Author: [neo](https://news.hada.io/@neo) - Published: 2026-05-22T05:39:25+09:00 - Updated: 2026-05-22T05:39:25+09:00 - Original source: [blog.railway.com](https://blog.railway.com/p/incident-report-may-19-2026-gcp-account-outage) - Points: 1 - Comments: 1 ## Topic Body - **Railway 플랫폼 전반 장애**가 2026년 5월 19일 22:20 UTC부터 약 8시간 이어졌고, 직접 원인은 Google Cloud의 프로덕션 계정 중단이었음 - 대시보드와 API는 즉시 **503 오류**를 반환했고, Google Cloud에 호스팅된 컴퓨트, 데이터베이스, 제어 평면, burst-compute 인프라가 오프라인으로 전환됨 - Railway Metal과 AWS 워크로드는 계속 실행됐지만, 엣지 프록시가 Google Cloud의 **제어 평면 API**에 의존해 라우트 캐시 만료 뒤 404 오류가 확산됨 - 계정 접근 복구 뒤에도 **영구 디스크, 컴퓨트 인스턴스, 네트워킹**은 각각 따로 복구해야 했고, GitHub OAuth와 webhook 속도 제한이 로그인과 빌드를 추가로 막음 - Railway는 단일 상위 제공자의 조치가 전체 장애로 번진 **아키텍처 결정**의 책임을 인정하고, Google Cloud를 데이터 평면 핫 패스에서 제거하는 재설계를 진행 중임 --- ### [영향](https://blog.railway.com/p/incident-report-may-19-2026-gcp-account-outage#impact) - 2026년 5월 19일 22:20 UTC부터 5월 20일 약 06:14 UTC까지 약 **8시간** 동안 Railway에 플랫폼 전반 장애가 발생함 - Google Cloud가 Railway의 **프로덕션 계정** 서비스를 중단하면서 API, 제어 평면, 데이터베이스, Google Cloud에 호스팅된 컴퓨트 인프라가 오프라인으로 전환됨 - 사용자는 대시보드와 API에서 즉시 **503 오류**를 겪었고, `"no healthy upstream"` 및 `"unconditional drop overload"` 메시지와 함께 로그인이 불가능해짐 - Google Cloud 컴퓨트에 호스팅된 모든 워크로드가 오프라인이 됨 - Railway Metal과 AWS burst-cloud 환경의 워크로드 자체는 계속 실행됐지만, Railway의 **엣지 프록시**가 라우팅 테이블을 채우기 위해 Google Cloud에 호스팅된 제어 평면 API에 의존하고 있었음 - 캐시된 네트워크 라우트가 만료되자 Google Cloud 외부 워크로드도 도달 불가능해졌고, 네트워크 제어 평면이 활성 인스턴스의 라우트를 해석하지 못해 **404 오류**를 반환함 - 최대 영향 시점에는 모든 리전의 Railway 워크로드가 도달 불가능한 상태가 됨 - Google Cloud 환경 복구 중에는 개별 서비스를 복구하는 동안 플랫폼 전반의 빌드와 배포가 차단됨 - 전체 인프라가 복구된 뒤에는 대기 중이던 배포 작업의 큰 백로그를 플랫폼에 과부하를 주지 않도록 점진적으로 처리함 - 동시에 GitHub가 Railway의 **OAuth 및 webhook 통합**을 속도 제한하면서 로그인과 빌드가 일시적으로 차단됨 - 호출량 증가는 Google Cloud 장애로 캐시가 비워진 결과였음 - 서비스 약관 동의 기록도 재설정되어 사용자가 다음 대시보드 방문 시 다시 동의해야 했음 - Railway는 단일 상위 제공자의 조치가 플랫폼 전반 장애로 확산되도록 만든 **아키텍처 결정**에 대한 책임을 인정함 ### [장애 타임라인](https://blog.railway.com/p/incident-report-may-19-2026-gcp-account-outage#incident-timeline) - 5월 19일 22:10 UTC: 자동 모니터링이 API 상태 확인 실패를 감지하고 온콜 담당자에게 알림 - 5월 19일 22:11 UTC: 대시보드가 **503 오류**를 반환하고 사용자가 로그인할 수 없게 됨 - 5월 19일 22:19 UTC: Google Cloud Platform이 Railway의 프로덕션 계정을 중단한 것이 근본 원인으로 확인됨 - 5월 19일 22:22 UTC: Google Cloud에 **P0 티켓**을 제출하고 Railway의 GCP 계정 매니저가 직접 관여함 - 5월 19일 22:29 UTC: 장애가 선언됨 - 5월 19일 22:29 UTC: GCP 계정 접근은 복구됐지만 모든 컴퓨트 인스턴스는 계속 중지 상태였고 영구 디스크는 접근 불가능했음 - 5월 19일 22:35 UTC: 캐시된 네트워크 라우트가 만료되기 시작하면서 Railway Metal과 AWS 워크로드가 404 오류를 반환함 - 5월 19일 23:09 UTC: 첫 번째 **영구 디스크**가 온라인으로 돌아옴 - 5월 19일 23:54 UTC: 모든 영구 디스크가 ready 상태로 복구됐지만 네트워크는 여전히 다운 상태였음 - 5월 20일 00:39 UTC: 디스크 ready 상태가 확인됐고, 복구가 Google Cloud 네트워킹 복구에 막힘 - 5월 20일 01:30 UTC: 컴퓨트 인스턴스가 복구되기 시작함 - 5월 20일 01:38 UTC: 엣지 트래픽이 다시 제공되기 시작했고 네트워킹이 복구됨 - 5월 20일 01:57 UTC: 오케스트레이션 및 빌드 인프라가 복구됐으며, 대기 작업이 동시에 실행돼 시스템을 압도하지 않도록 배포를 일시 중단함 - 5월 20일 02:04 UTC: 컴퓨트 호스트가 점진적으로 온라인 상태로 복구됨 - 5월 20일 02:47 UTC: GitHub가 Railway의 OAuth 및 webhook 통합을 속도 제한하기 시작해 일부 사용자가 로그인할 수 없고 빌드가 차단됨 - 5월 20일 02:55 UTC: 대시보드에 다시 접근 가능해짐 - 5월 20일 03:59 UTC: 모든 티어에서 배포 처리가 다시 시작됨 - 5월 20일 04:00 UTC: API, 대시보드, OAuth 엔드포인트가 동작 중임이 확인됐고 남은 워크로드 복구가 계속됨 - 5월 20일 06:14 UTC: 장애가 모니터링 단계로 전환됨 - 5월 20일 07:58 UTC: 장애가 해결됨 ### [발생 원인과 복구 과정](https://blog.railway.com/p/incident-report-may-19-2026-gcp-account-outage#what-happened) - ## Google Cloud 계정 중단 - 5월 19일 22:20 UTC에 Google Cloud가 자동 조치의 일부로 Railway의 프로덕션 계정을 잘못 **중단 상태**로 전환함 - 이 조치는 Google Cloud 내 여러 계정에 영향을 미침 - 플랫폼 전반의 조치였기 때문에 제한 전에 개별 고객에게 사전 연락이 없었음 - 중단 상태는 Railway Dashboard, API, 네트워크 인프라 일부, Google Cloud에 호스팅된 추가 burst-compute 인프라를 포함한 GCP 관련 인프라를 비활성화함 - ## 제어 평면 의존성 - Railway의 **제어 평면**은 대시보드를 제공하고, 빌드와 배포를 처리하며, 엣지가 사용하는 라우팅 테이블을 채우는 핵심 의존성 집합임 - Google Cloud의 모든 워크로드에는 영향이 즉시 발생함 - Railway의 엣지 프록시는 Google Cloud 내부에 호스팅된 네트워크 제어 평면의 라우팅 테이블 캐시를 유지함 - 캐시가 유지되는 동안 Railway Metal과 AWS의 워크로드는 계속 트래픽을 처리함 - 캐시가 만료되자 엣지가 활성 인스턴스의 라우트를 더 이상 해석할 수 없게 됐고, Metal과 AWS를 포함한 모든 리전의 워크로드가 404 오류를 반환하기 시작함 - 워크로드 자체는 온라인 상태였지만, 네트워크 장애 영향이 Google Cloud 밖의 리전으로 확산됨 - ## 고가용성 설계의 한계 - Railway 인프라는 고가용성을 목표로 설계되어 있으며, 데이터베이스는 여러 가용 영역에 걸쳐 실행되고 네트워크는 AWS, GCP, Railway Metal 사이의 중복 연결을 사용함 - 계정 접근이 복구되어도 개별 서비스가 자동으로 복구되지는 않았음 - **영구 디스크, 컴퓨트 인스턴스, 네트워킹**이 각각 별도 복구를 필요로 했고, 이 복구 특성 때문에 장애가 몇 시간 더 이어짐 - 디스크는 23:54 UTC에 ready 상태로 복구됐지만, 핵심 네트워킹과 엣지 라우팅은 5월 20일 약 01:30 UTC까지 완전히 복구되지 않음 - Railway는 이 지연과 관련 오류가 Google 측에서 발생했는지 확인을 기다리고 있음 - ## 단계적 복구와 2차 영향 - 네트워킹이 복구되면서 Railway 핵심 서비스와 최종 사용자 워크로드 검증이 계층별로 진행됨 - 빌드 시스템 과부하를 막기 위해 배포를 일시 중지했고, 이후 점진적으로 재개함 - 핵심 시스템 복구와 병행해 GitHub가 Railway의 OAuth 및 webhook 통합을 속도 제한함 - 모든 재시도 요청의 **볼륨과 burst 특성** 때문에 사용자 로그인과 빌드가 일시적으로 차단됨 - 5월 20일 약 04:00 UTC에는 API, 대시보드, OAuth 엔드포인트가 동작 중임이 확인됐고, 남은 워크로드 복구가 계속됨 ### [예방 조치](https://blog.railway.com/p/incident-report-may-19-2026-gcp-account-outage#preventative-measures) - ## 기존 복원력 설계 - Railway의 네트워크 제어 평면은 **multi-AZ, multi-zone** 구성으로 설계되어 여러 머신과 컴포넌트를 잃어도 사용자 영향 없이 계속 동작할 수 있음 - 이 설계는 몇 달 전 출시 전에 스테이징과 실제 트래픽에서 테스트됨 - 이전 장애 이후 복원력에 투자해 왔고, 그 결과 사용자 GitHub 설치를 2차 속도 제한 없이 안정적으로 복구한 경험이 있음 - ## 단일 의존성 제거 - Railway 네트워크는 Metal <> GCP <> AWS 사이의 고가용성 광섬유 상호 연결로 구성된 **mesh ring**임 - 이 링 안에서도 워크로드 발견 가능성이 Google Cloud 머신에서 실행되는 네트워크 제어 평면 API에 묶인 강한 의존성이 남아 있었음 - 메시는 약 한 시간 동안 계속 동작했지만, 라우트 캐시가 만료되자 라우팅 테이블을 다시 채울 수 없어 실패함 - Railway는 이 의존성을 즉시 제거해 실제 **mesh**로 만드는 작업을 진행 중임 - 목표는 어떤 상호 연결이 끊어져도 클라우드 사이에 항상 경로가 남도록 하는 것임 - ## 데이터베이스와 장애 조치 개선 - Railway는 고가용성 데이터베이스 샤드를 AWS와 Metal 전반으로 확장할 예정임 - 향후 특정 클라우드의 모든 인스턴스가 즉시 사라져도 데이터베이스 **quorum**이 서비스를 계속 유지하고, 더 이상 실행 중이 아닌 워크로드를 즉시 장애 조치하도록 만드는 방향임 - ## 데이터 평면과 제어 평면 재설계 - Google Cloud 서비스를 데이터 평면의 **핫 패스**에서 제거하고 보조 또는 장애 조치 용도로만 유지하는 계획이 진행 중임 - 호스트 연결을 가능하게 하는 데이터 평면과, 사용자가 Railway에 접근하고 관리하는 대시보드를 구동하는 제어 평면에 새 아키텍처를 구현하는 작업과 병행됨 - 이 업그레이드는 핵심 서비스, 특히 사용자 대면 컴포넌트가 어떤 단일 벤더나 플랫폼에도 의존하지 않도록 만들기 위한 것임 ### 책임과 결론 - 벤더 선택에 대한 책임은 Railway에 있으며, 이번 선택도 궁극적으로 Railway의 책임임 - 고객은 실패 원인이 Google인지 Railway인지보다 제품 자체를 보며, Railway의 가동 시간은 Railway의 책임임 ## Comments ### Comment 58031 - Author: neo - Created: 2026-05-22T05:39:26+09:00 - Points: 1 ###### [Hacker News 의견들](https://news.ycombinator.com/item?id=48204770) - 흥미롭고 아직 설명되지 않은 부분은 **Google이 왜 계정을 플래그했는지**임 사후 분석에 관측한 타임스탬프를 아무리 넣어도, 근본 원인은 다루지 않았음 이야기에서 “말이 안 된다”는 부분에는 아직 아무도 공개하고 싶어 하지 않는 실제 설명이 있을 가능성이 큼 - 2017년쯤 [https://www.fatherly.com/]()를 운영할 때 정확히 같은 일을 겪었음 Google이 예고 없이 계정을 꺼버렸고, 당시 월 **1만 달러** 정도를 쓰고 있었음 심지어 프리미엄 지원 계정까지 잠겨서, 지원팀에 “우리가 잠겼다”는 사실조차 알릴 수 없었음 약 8시간 뒤 임의의 Google 지원 엔지니어가 우리가 비트코인을 채굴했기 때문이라고 했는데, 완전히 말도 안 됐음 전체 기간의 CPU 사용량 그래프와 로그가 있었고 스파이크도 없었음 12시간쯤 지나서 다시 켜주면서 “남용 탐지 설정 오류”였다고 했고, 크레딧으로 100달러 정도를 줬음 AWS에 대해 뭐라 하든, AWS라면 담당자가 먼저 연락하지 않고 고객에게 이런 짓을 하지는 않았을 것임 그 이후로 **GCP**를 신뢰하지 않음 - Google이 이 사고 보고서가 마음에 안 든다면 직접 답해야 하는 것 아닌가? 애초에 Railway가 이유를 알고 있는지도 확실하지 않음 - 보통 이런 일은 왜 그런지 알려주지 않는 것 같고, 보기엔 대부분 **자동화**되어 있음 자동화 시스템은 실수도 하지만, 더 큰 문제는 완전히 불투명하다는 점임 Google조차도 그 시스템이 정확히 어떻게 동작하는지 모를 가능성이 큼 - “근본 원인을 다루지 않았다”에서 “당신”이 누구를 뜻하는지 모르겠음 Railway에게 GCP를 떠나는 대신 여기에 힘을 쓰라는 뜻이라면, 브랜드와 장기 고객 유지 손해를 회수하려고 GCP를 상대로 소송할 생각이 아닌 이상 왜 그래야 하는지 모르겠음 GCP가 아무 사전 경고 없이 꺼버린 순간 이미 끝난 일이고, 더 물을 필요도 없다고 봄 - 늘 그렇듯 상위 댓글은 Google에 대한 깊은 반감 속에 묻혀 있고, 이게 Railway가 이 문제를 다루도록 압박할 것 같지는 않음 - Railway는 이번 달 기술 언론에서 이미지가 좋지 않았던 듯함 두 경우 모두 다른 쪽의 **자동화된 절차**가 원인이 되어 평판이 손상됐음 원래 Google 담당자에게 Gemini CLI를 죽인 문제를 이야기하려 했는데, 이 건이 훨씬 더 걱정됨 - AI에 관리자 자격 증명을 줘서 프로덕션 데이터베이스를 지우게 했고, 실제로 프로덕션 데이터베이스가 지워진 사건이라면 그건 자기 책임 관리자 계정 자격 증명을 AI에 넣은 건 그들뿐이었음 그리고 개인적 책임도 지지 않았고, 그게 확실히 평판을 망쳤음 이번에는 적어도 어느 정도 책임을 인정하고 있으니 개선한 점은 인정함 또한 **GCP의 안정성 문제**와 Google의 고객 지원 문제는 실제로 심각함 수정: 아래에서 처음 두 문단이 잘못 귀속됐고 Railway가 아니라 Railway 고객의 일이었다는 걸 알게 됐음. 미안, Railway! - 남의 플랫폼 위에 만드는 건 언제나 위험하고, 남의 플랫폼 위에 다시 **플랫폼을 만드는 것**은 더 위험함 우리 회사는 예전에 AWS에 몇 가지 추가 보장을 얹은 형태의 호스팅 업체를 썼음 이제 AWS가 필요한 기능을 직접 제공해서 일반 AWS로 마이그레이션을 끝냈음 - 안타깝게도 이 일 때문에 어제 **Azure로 긴급 마이그레이션**해야 했음 다행히 데이터베이스는 Railway에 두지 않아서 몇 시간 안에 복구됐음 Railway가 제공하던 단순함은 정말 좋았지만, B2B 엔터프라이즈 앱을 그 인프라에서 계속 돌리기엔 사고와 한계가 너무 많았음 슬픈 날임 :( - Railway가 당신에게서 잃은 수입에 대해 Google을 상대로 소송할 수 있을 듯함. 재미있겠음 - 애초에 Railway를 선택한 이유가 무엇이었는지 궁금함 잘 아는 서비스는 아닌데, 독특한 기능 때문에 골랐는지 아니면 사실상 가상 머신 용도였는지? 독특한 기능 때문이었다면 빠져나오는 마이그레이션은 얼마나 힘들었는지도 궁금함 - Azure도 계정을 정지시켰다는 뜻인가? - 작은 SaaS 도구나 내부 제품 기준으로, 팀이 AWS나 다른 **IaaS 제공자**를 직접 관리하고 싶지 않다면 다음의 대안은 무엇이 좋을까? 1) Vercel - 이번 달 상태가 안 좋음 2) Supabase - 이번 달 상태가 안 좋음 3) Railway - 이제 이번 달 상태가 안 좋음 - **DigitalOcean**. 진지하게 말해서, 아주 오래전부터 있었고 매일 의존하는 핵심 인프라를 많이 만들었음. 예를 들면 Ceph - IaaS를 직접 쓸 수 없다면, 서비스가 내려갈 수 있다는 걸 받아들여야 함 AWS 같은 걸 써도 여러 **가용 영역**에 걸친 중복 구성을 하지 않으면 가끔 다운타임이 생김 여러 가용 영역으로 중복 구성을 해도 AWS가 완전히 격리된 구조는 아니라 일부 서비스가 실패할 수 있고, 다운타임이 생길 수 있음 그러니 다운타임을 받아들이고 자신에게 가장 맞는 도구를 쓰면 됨. 단 GitHub 수준으로 심하게 나쁜 경우는 제외함 다운타임을 전혀 받아들일 수 없다면, 다운타임이 없을 거라고 기대할 정도의 신뢰를 얻기 위해 수백만 달러와 수개월의 작업이 필요함 Netflix의 **Chaos Monkey**와 그 인프라 정도면 충분할 것임 - 여기서 얻을 메시지는 단일 클라우드 제공자를 믿을 수 없다는 것 같음 최소한 완전한 운영 능력을 갖춘 제공자 **두 곳**은 필요함 - 왜 아무도 **베어메탈 서버**나 VPS를 살 수 있다는 점을 고려하지 않는지 모르겠음 종량제 요금 없이도 꽤 멀리 갈 수 있음 - 중간 사업자는 가치를 줄 수 있지만 위험도 있으니, AWS, GCP 등을 직접 쓰고 싶지 않은 이유를 먼저 따져보겠음 주요 클라우드 제공자들은 Railway가 하는 것보다 약간만 더 어려운 서비스를 제공하고, 필요가 커질수록 더 고급 기능으로 확장할 수 있음 기능, 보안, 가용성을 통제하는 제3자를 추가하지 않아도 됨 예를 들어 이 타임라인에 따르면 GCP는 7분 안에 응답했음 **Cloud Run**을 쓰고 있었다면 다운타임을 7시간 넘게 줄였을 것이고, 알 수 없는 트리거가 다른 고객 활동이나 Railway의 이상한 동작과 관련 있었다면 애초에 내려가지 않았을 가능성도 큼 복잡성도 있음 Railway가 고쳐야 했다고 적은 복잡한 인프라 중 상당수는 자기 계정만 쓴다면 필요 없었을 것임 그 코드는 분명 유용한 일을 하겠지만, 호스팅 제공자에게는 필요하고 일반 사용자에게는 필요 없는 움직이는 부품이 많음 이번 장애는 모두를 같이 쓰러뜨렸지만, 개별 AWS 사용자나 베어메탈 사용자는 원래 영향받지 않았을 것임 모두에게 같은 전역 최적해는 없지만, 개발자들은 배포 단계 몇 개를 줄여서 아끼는 시간에 비해 직접 비용과 남의 환경 안에서 일하는 덜 보이는 비용을 크게 과소평가하는 경향이 있음 - “5월 19일 22:10 UTC - 자동 모니터링이 API 상태 확인 실패를 감지하고 온콜을 호출했으며, 담당자들이 조사에 착수했다” “5월 19일 22:20 UTC - Google Cloud가 자동 조치의 일부로 Railway의 프로덕션 계정을 잘못 정지 상태로 전환했다” 타임스탬프가 정확하다면, 계정 정지 **10분 전**의 오류는 무엇이 일으킨 걸까? 가장 단순한 설명은 둘 중 하나의 타임스탬프가 틀렸다는 것이고, 그 자체는 큰일이 아님 하지만 타임스탬프를 확실히 모른다면, 서로 명백히 모순되는데도 확정된 것처럼 보고서에 넣은 건 꽤 이상함 - 타임스탬프가 정확하다고 가정하면, Google이 계정이 “정지” 상태가 되기 전에 리소스 종료를 시작했고, 모든 리소스가 비활성화된 뒤에야 그 상태가 완료됐을 가능성이 있음 - 본문에 있는 22:20 타임스탬프가 틀렸음 22:10이 나온 타임라인 섹션은 자체적으로 일관되고, 다음 내용도 포함 “5월 19일 22:19 UTC - 근본 원인 확인: Google Cloud Platform이 Railway의 프로덕션 계정을 정지함” 발생하기 전에 근본 원인을 확인할 수는 없음 - 그 10분은 꽤 정상적일 가능성이 큼 예를 들어 Google 직원이 설정을 잘못 건드려 이전 사고들처럼 정지가 필요해 보이는 신호를 만들고, 그게 정지 절차로 흘러가는 데 10분이 걸렸을 수 있음 또는 Railway 고객이 부정하거나 부정해 보이는 일을 했고, Google 시스템이 접근 제한을 시작한 뒤 10분 동안 정지로 올릴지 판단했을 수 있음 승인 과정에 사람이 끼어 있었다면 더 그럴듯함 다만 그 사람은 그렇게 하면 안 된다는 걸 볼 만큼 충분히 파고들지 않은 게 분명함 - GCP를 운영 중인 누구에게나 이건 경고가 되어야 함 GCP는 자신들이 뭘 하는지 생각도 안 하고 계정을 여기저기 정지시키는 듯함 프로덕션 의사결정을 Gemini 3.1 Pro로 돌리는 것 같음 TK는 OCI에서처럼 조직 문화를 완전히 망가뜨린 이력이 있고, 들은 바로는 GCP에서도 비슷한 일을 한 듯함 GCP와 Google은 일하는 방식이 완전히 다른 조직임 이름만 보고 Google 품질을 기대하면 안 됨 Nokia처럼 지금은 값싼 라이선스 제품에 붙는 오래된 브랜드와 비슷함. 과장인 건 알지만 진실에서 멀지 않음 그뿐 아니라 서비스를 무작위로 종료하면서 마이그레이션 기간을 6개월 정도 주는 것으로도 알려져 있음 할 일이 없는 엔지니어가 많으니 내부 사용자를 그 서비스에서 빼내는 데 투입하지만, 고객 대부분은 그렇게 못 함 전직 GCP 직원이 쓴 훌륭한 글이 있었는데 지금은 찾을 수 없음 사업을 진지하게 한다면 **GCP는 역병처럼 피해야 함** 수정: Gemini가 아이러니하게도 그 글을 찾아줬음. 읽을 만함: [https://steve-yegge.medium.com/dear-google-cloud-your-deprec...]() - 심지어 이건 Railway임 HN 메인 페이지 상단에 오를 만큼 이름이 있고, 어느 시점엔 Google에서 개입할 사람을 찾을 수 있을 법한 규모임 내가 만든 작은 제품이었다면 구제 수단이 전혀 없었을 것임 - “이름만 보고 Google 품질을 기대하지 말라”는 말은 지난 수십 년 동안 내가 겪은 **Google 품질**과 정확히 맞아떨어짐 - GCP는 지원으로 유명했던 적이 없고, 서비스 종료도 항상 큰 위험이었음 실제 제품 품질은 좋은 편이라 더 안타까움 쉽게 2위 제공자가 될 수 있었을 텐데, **Azure**는 매우 불안정하고 문서도 수준 이하임 GCP가 3위인 건 상당 부분 스스로 만든 결과임 - 밖에서 보기엔 TK가 GCP 성장세를 보면 잘하고 있는 것처럼 보임 완전히 근거 없는 내 평가는, Google의 느슨한 엔터프라이즈 접근을 바로잡기 위해 규율 있는 어른 역할로 들어왔다는 것임 이 사고가 보여주듯 아직 갈 길은 있지만, “진지한” 엔터프라이즈 조직이 되려면 아마 필요했을 수 있음 다만 그 과정에서 Google 나머지 조직과 충돌하는 문화를 만들었을 수는 있음 그렇다 해도 Oracle 부문인 OCI에 파괴할 만한 문화가 있었을까? 반대로 TK가 그 문화를 Google로 들여왔을 가능성은 보임 - 모든 Google 제품이 이런 식으로 동작함 중요한 일에는 절대 쓰면 안 됨 - Google Cloud가 고객 계정을 심각하게 망친 게 이번이 처음은 아님: [https://cloud.google.com/blog/products/infrastructure/detail...]() - “Railway는 벤더 선택에 대한 책임을 지며, 결국 이번 선택도 우리의 책임이다. 고객은 장애가 Google 때문인지 Railway 때문인지 신경 쓰지 않는다. 고객에게 보이는 건 우리 제품이다. 여러분의 가동 시간은 우리의 책임이고, 우리는 계속 그것을 제공하겠다” PR식 표현이 아니라 이를 인정한 점은 칭찬할 만함 GCP를 믿은 것이 Railway 측의 **아키텍처 실패**였고, 이를 고치려 하고 있음을 보여줌 미리 예견했어야 했나? 그렇다. 그래도 안 하는 것보단 늦게라도 하는 게 낫다 - 어디선가 UVic ESS 사무실 템플릿 문구처럼 들림 :P - “마지막으로, Google Cloud 서비스를 데이터 플레인의 핫 패스에서 제거하고 보조/장애 조치 용도로만 유지하는 계획을 세우고 있다” 꽤 명확함 Google은 더 이상 **B2B 서비스 제공자**로 신뢰할 수 없음 - Meta도 다르지 않음 어떤 회사는 개발자 직원 한 명의 개인 Facebook 계정이 이유 없이 Meta에 의해 차단됐다는 이유만으로 Meta의 OAuth 앱이 완전히 쓸 수 없는 상태가 됐음 여러 번 에스컬레이션했지만 아무 데도 닿지 못했음 Meta는 계정이 “개인”이어야 해서 더 나쁨 Business Manager가 있어도 거기에 추가된 사용자는 모두 개인 Meta/Facebook 계정에 묶임 터무니없음 - 더 많은 기업이 이 메시지를 들어야 함 Google은 바로 이런 문제 때문에 서비스 제공자로 믿을 수 없다는 걸 여러 번 증명했음 - 그래도 돈은 계속 줄 정도로는 믿는다는 뜻이니, 거대 기술 기업이 얼마나 깊게 자리 잡았는지 보여줌 그래서 수십 조각으로 쪼개야 함 - Google이 설명 없이 계정을 정지하거나 종료한 역사는 오래전부터 있음 사용자가 분노를 공개하고 사건이 퍼진 뒤에야 뒤늦게 되돌리는 일이 자주 있었음 Google은 유료 고객에게 아무런 의무도 없다는 듯 항상 행동해왔음 - 계정이 **왜 정지됐는지** 설명하지 않았음 내 생각엔 그게 가장 중요한 부분임 클라우드 제공자가 아무 이유 없이 계정 전체를 정지하지는 않음