Google이 내 회사의 Google Cloud 계정을 세 번째로 정지시켰다
(agwa.name)- SSLMate의 Google Cloud 계정이 세 번째로 예고 없이 정지되며, 서비스 통합 기능이 반복적으로 중단됨
- 고객의 Cloud DNS 및 Cloud Domains 통합을 위해 Google 문서에 따라 서비스 계정을 생성·위임하는 구조를 사용했으나, 이 방식이 지속적으로 정지 대상이 됨
- 첫 번째 정지(2024년)는 복구 과정의 비효율성과 불명확한 원인으로 큰 혼란을 초래했고, 이후 두 차례 정지도 사전 통보 없이 자동화된 이메일만 반복됨
- 대안으로 장기 키 기반 인증은 보안상 취약하고, OIDC(OpenID Connect) 는 설정 절차가 과도하게 복잡함
- 결과적으로 Google Cloud 통합에서는 보안·편의성·안정성 중 두 가지밖에 선택할 수 없는 구조적 한계가 드러남
Google Cloud 계정 반복 정지 사례
- SSLMate의 Google Cloud 계정이 2024년과 2025년 두 차례 연속된 금요일마다 사전 통보 없이 정지됨
- 이전에도 2024년에 동일한 정지가 있었으며, 세 번 모두 명확한 사유나 재발 방지 방법이 제공되지 않음
- SSLMate는 고객의 Google Cloud 계정과 통합하기 위해 서비스 계정 위임 방식을 사용
- 각 고객별로 SSLMate 프로젝트 하에 서비스 계정을 만들고, 고객이 해당 계정에 Cloud DNS 및 Cloud Domains 접근 권한을 부여
- SSLMate는 필요 시 해당 서비스 계정을 가상으로 가장(impersonate) 하여 접근
- 이 구조는 Google 공식 문서의 권장 방식에 기반하며, 장기 자격 증명 없이 안전하고 설정이 간단한 방식임
첫 번째 정지 (2024년)
- 첫 번째 정지 시 고객 통합 기능이 모두 실패하고 콘솔 접근이 차단됨
- Google 지원팀은 응답했으나, 계정이 비활성화되어 이메일이 반송되는 등 복구 절차가 비효율적이었음
- 프로젝트 ID를 요청받았으나 콘솔 접근이 불가해 제공할 수 없었음
- 전화번호 인증 후 일부 프로젝트만 복구되었고, 다음날 다시 자동 이메일로 접근 제한 통보를 받음
- 이후 여러 자동 이메일을 거쳐 약 19시간 후 전체 복구
- Google은 정지 사유를 밝히지 않았으며, 사전 이메일 통보도 없었음
- SSLMate는 이후 통합 오류 비율을 감시하는 헬스 체크 기능을 추가해 조기 감지를 시도
두 번째 정지 (2025년 10월경)
- 헬스 체크가 실패하며 대부분의 통합이 “Invalid grant: account not found” 오류를 반환
- 콘솔 로그인은 가능했으나, 각 프로젝트별로 “제공된 정보에 따라 복구됨”이라는 이메일만 수신
- 정지 통보 이메일은 여전히 수신되지 않음
- 이후 통합 기능이 정상화됨
세 번째 정지 (2025년 11월)
- 다시 헬스 체크 실패 후 콘솔 접근 시 새로운 유형의 오류 메시지 표시
- 대부분의 프로젝트가 정지되었으며, 고객 통합용 프로젝트도 포함
- 금요일에 이의 신청을 제출했으나, 일요일에는 전체 계정 정지 통보 이메일을 수신
- 월요일, 해당 글이 Hacker News에 올라온 직후 대부분의 프로젝트가 복구되고, 몇 시간 후 전체 접근이 회복
- 이번에도 정지 원인이나 예방 방법은 제공되지 않음
예외 고객 사례
- 모든 정지 기간 동안에도 한 고객의 통합만 정상 작동
- 동일한 프로젝트 내 서비스 계정을 사용했음에도 영향받지 않음
- 원인에 대한 추가 설명 없음
Google Cloud 의존성 문제와 대안
- SSLMate는 프로덕션 환경에서 Google 계정에 의존할 수 없다고 판단
- Google 시스템은 계정, 프로젝트, 또는 GCP 전체가 임의로 정지될 수 있는 구조
- 대안 1: 고객이 직접 서비스 계정을 만들고 장기 키(long-lived key) 로 SSLMate에 인증 제공
- 설정은 간단하지만, 키 유출 위험과 회전 불가능성으로 보안이 취약
- 대안 2: OpenID Connect(OIDC) 사용
- GitHub Actions나 Azure 통합에서 사용되는 표준 방식으로, 장기 자격 증명 없이 안전한 접근 가능
- 그러나 Google Cloud에서의 설정은 7단계 절차로 과도하게 복잡함
OIDC 설정의 복잡성
- OIDC를 사용하려면 다음 단계 필요
- IAM Service Account Credentials API 활성화
- 서비스 계정 생성
- Workload Identity Pool 생성
- Pool 내에 Workload Identity Provider 생성
- SSLMate가 서비스 계정을 가장할 수 있도록 권한 부여
- 서비스 계정에 역할(Role) 부여
- 생성된 서비스 계정 및 Provider ID를 SSLMate에 전달
- 각 단계가 이전 단계의 리소스 ID를 필요로 해 고객이 따라 하기 어려움
- 작성자는 다음 단계를 불필요한 절차로 지적
- 서비스 계정 생성 없이도 역할을 직접 부여할 수 있어야 함
- 대부분의 경우 Pool은 Provider 하나만 포함하므로 Pool 생성 자체가 불필요한 중복 작업
- Provider 생성 없이도 OIDC 발급자 URL과 주체(subject) 에 직접 역할을 부여할 수 있어야 함
구조적 문제와 결론
- 현재 Google Cloud 통합은 다음 세 가지 중 두 가지 선택만 가능
- 장기 자격 증명 없음
- 고객이 쉽게 설정 가능
- 임의 정지로부터 안전
- SSLMate의 서비스 계정 기반 방식은 보안과 편의성은 확보하지만 정지 위험 존재
- 서비스 계정+키 방식은 설정이 쉽고 정지 위험은 낮지만 보안이 약함
- OIDC 방식은 보안과 정지 안전성은 높지만 설정이 복잡함
- Google이 OIDC를 1급 통합 방식으로 단순화하지 않는 한, 안전하고 안정적인 통합은 어렵다는 결론
독자 댓글 요약
- 한 독자는 “다른 클라우드 제공자를 사용하라, GCP는 최악”이라고 언급
- 작성자는 “고객이 GCP를 사용하기 때문에 통합을 위해 필요하다”고 응답
- 또 다른 독자는 “보안과 신뢰성이 단순함과 충돌한다”며, 단순함을 우선하는 고객은 적합하지 않다고 지적
Hacker News 의견
-
사람들은 Google을 신뢰할 수 있는 파트너로 생각하지만, 실제로는 대규모 리테일 공장처럼 설계된 시스템임
수백만 명을 대상으로 하며, 잘못된 자동 보호 조치 하나로 수천 명의 삶이 망가질 수 있음
고객 지원 부재나 자동화된 무의미한 답변은 단순한 비용 절감이 아니라 법적 책임 최소화 전략으로 보임- “Google을 신뢰한다”는 말에 웃음이 나옴
대부분의 사람들은 Google 계정이 언제든 이유 없이 정지될 수 있다는 걸 알고 있음
실제로 주변에 계정 접근을 잃은 사람을 한두 명쯤은 다 알고 있음
수백만 달러 규모의 계약이 아닌 이상 Google을 진정한 파트너로 보는 사람은 거의 없다고 생각함
- “Google을 신뢰한다”는 말에 웃음이 나옴
-
모든 플랫폼이 규모 확장을 우선시함
개별 사용자와 인간적인 관계를 유지하면서도 마약상 수준의 수익성을 유지하는 건 불가능함
선량한 사람 한 명이 잘못 걸려도 ‘필요한 비용’으로 간주됨
어제는 Wise, 그 전에는 GitHub 계정이 이런 식으로 차단됨
기업은 민주주의가 아니라 봉건 영지처럼 운영됨
자동화된 시스템이 당신을 범죄자로 판단하면 재판 없이 바로 처벌함- 그래서 나는 항상 작은 회사를 선택하려 함
실제 사람과 대화할 수 있고, 단순한 챗봇이 아님
지금은 Tuta Mail을 쓰고 있는데, 양자 내성 암호화와 광고 없는 환경이 마음에 듦
내 도메인으로 원하는 만큼 별칭 주소도 만들 수 있음
- 그래서 나는 항상 작은 회사를 선택하려 함
-
몇 년 전 내 YouTube Premium 계정이 스팸 이유로 차단되었음
단순히 영상 시청만 했는데도 계정이 삭제되고 결제 페이지 접근도 막힘
3주마다 한 번씩만 가능한 로봇식 항소 절차를 거치는 동안 계속 요금이 청구됨
Google One의 유료 지원도 “다른 팀이라서 도움 불가”라며 무용지물이었음
결국 카드 해지를 통해 해결했는데, 몇 달 뒤 “실수였다”는 메시지를 받음
아이러니하게도 WeChat은 하루 만에 사람과 통화해 해결했음 — 검열국가의 고객지원이 더 낫다는 생각이 들었음 -
문제는 Google만이 아니라, 알고리즘 의존형 대기업 구조 전반에 있음
Reddit에서도 20년 된 내 계정이 이유 없이 섀도밴 당했음
항소는 묵살되고, 글과 댓글이 모두 필터링됨
Fediverse는 더 나은 대안 모델을 보여줌 — 작은 커뮤니티와 높은 모더레이터 비율이 핵심임- 하지만 Fediverse도 완벽하지 않음
#fediblock 태그 하나로 수백 개 서버에서 자동 차단되는 구조는 책임 없는 검열을 반복하게 만듦
실제로 우리 도시의 Mastodon 인스턴스가 그렇게 망했고, 모두 Bluesky로 옮겨감 - Google은 충분한 자금이 있음
이런 엣지 케이스를 처리할 인력을 100명쯤 두는 건 어렵지 않음
하지만 마진이 줄어들기 때문에 그렇게 하지 않음 - 수조 달러 규모의 기업들이 “알고리즘밖에 방법이 없다”고 말하는 건 핑계임
돈이 없어서가 아니라, 쓰지 않기로 선택한 것임
- 하지만 Fediverse도 완벽하지 않음
-
앞으로 Gemini API에서도 이런 문제가 생길 것 같음
고객이 규정을 어긴 이미지를 생성하면, 그 즉시 비즈니스 Gmail이나 개인 복구용 Gmail까지 영구 정지될 수 있음- 외부 고객이 데이터를 입력하거나 이미지를 생성한다면, 내장된 모더레이션 도구를 반드시 활성화해야 함
-
Android 개발자 인증도 이런 식으로 흘러갈 것 같음
많은 개발자가 이유 없이 개발자 자격 정지를 당할 가능성이 큼- 사실 이미 심각한 수준임
예전에 한 소규모 회사 직원들의 개인 계정이 “이전에 정지된 개발자 계정과 연관됨”이라는 이유로 함께 차단된 사례를 봤음 - 근본적으로, Android 개발은 남의 땅에서 농사짓는 소작농 같은 구조임
플랫폼에 종속된 상태에서 전문성을 유지하기 어렵다고 생각함
- 사실 이미 심각한 수준임
-
우리 서비스도 단순히 “Login with Google” 버튼만 사용했는데, 갑자기 계정이 차단됨
“약관 위반”이라는 모호한 이유뿐이었음
항소를 넣고 사용자 로그인 대안을 급히 마련하던 중, 다음날 갑자기 “항소 승인” 메일이 옴
결과적으로 복구되긴 했지만, 불신감이 남았음- 나 같으면 이제 “Login with Google” 지원을 중단할 것임
- 소셜 로그인 대신 사용자명/비밀번호, MFA, Passkey만 사용하는 게 낫다고 생각함
-
내 AdSense 계정은 광고에 느낌표 하나 넣었다는 이유로 세 번 정지됨
결국 계정을 닫았지만, 여전히 “잠재적 사기 계정”으로 추적되고 있을 것 같음- 말도 안 됨. 규칙 위반 광고를 자동으로 차단할 수 있는 시스템이 있다면, 광고 작성 중에 경고라도 줘야 함
새 사용자가 한 시간 만에 정지당하는 구조라면, 애초에 가입 절차를 왜 그렇게 쉽게 만든 건지 의문임 - 내 계정도 같은 이유로 영구 정지되었음. 수년 전 일이지만 아직도 황당함
- 느낌표가 문제라니, 인쇄 광고에선 예전부터 흔한 문장부호인데 납득이 안 됨
- 정말 느낌표가 금지된 건지, 아니면 단순한 시스템 오류인지 궁금함
- 말도 안 됨. 규칙 위반 광고를 자동으로 차단할 수 있는 시스템이 있다면, 광고 작성 중에 경고라도 줘야 함
-
이런 상황이라면 Google을 소송하거나 규제 강화를 요구해야 하는지 고민됨
- 하지만 “회사가 나와 거래를 거부했다”는 이유만으로는 소송 근거가 약함
- 그래도 소액 재판에서는 승산이 있음
Google이 출석하지 않거나, TOS를 근거로 변명하다가 판사에게 역효과를 내는 경우가 많다고 들음
-
정지된 이메일 계정으로 등록된 Passkey 전용 로그인 계정은 어떻게 되는지 궁금함
Google Password Manager에 동기화된 Passkey가 계정 정지 후에도 작동하는지,
혹은 이메일 접근이 막혀 복구가 불가능한지 테스트해본 사람은 거의 없을 것 같음