흥미롭고 아직 설명되지 않은 부분은 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 제공자를 직접 관리하고 싶지 않다면 다음의 대안은 무엇이 좋을까?

Vercel - 이번 달 상태가 안 좋음

Supabase - 이번 달 상태가 안 좋음

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로 들여왔을 가능성은 보임

“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은 유료 고객에게 아무런 의무도 없다는 듯 항상 행동해왔음

계정이 왜 정지됐는지 설명하지 않았음
내 생각엔 그게 가장 중요한 부분임
클라우드 제공자가 아무 이유 없이 계정 전체를 정지하지는 않음