# Google이 내 회사의 Google Cloud 계정을 세 번째로 정지시켰다 > Clean Markdown view of GeekNews topic #24125. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=24125](https://news.hada.io/topic?id=24125) - GeekNews Markdown: [https://news.hada.io/topic/24125.md](https://news.hada.io/topic/24125.md) - Type: GN+ - Author: [neo](https://news.hada.io/@neo) - Published: 2025-11-04T09:43:03+09:00 - Updated: 2025-11-04T09:43:03+09:00 - Original source: [agwa.name](https://www.agwa.name/blog/post/google_suspended_sslmates_cloud_account_again) - Points: 1 - Comments: 2 ## Topic Body - 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를 사용하려면 다음 단계 필요 1. IAM Service Account Credentials API 활성화 2. 서비스 계정 생성 3. Workload Identity Pool 생성 4. Pool 내에 Workload Identity Provider 생성 5. SSLMate가 서비스 계정을 가장할 수 있도록 권한 부여 6. 서비스 계정에 역할(Role) 부여 7. 생성된 서비스 계정 및 Provider ID를 SSLMate에 전달 - 각 단계가 이전 단계의 리소스 ID를 필요로 해 **고객이 따라 하기 어려움** - 작성자는 다음 단계를 **불필요한 절차**로 지적 - 서비스 계정 생성 없이도 역할을 직접 부여할 수 있어야 함 - 대부분의 경우 Pool은 Provider 하나만 포함하므로 **Pool 생성 자체가 불필요한 중복 작업** - Provider 생성 없이도 **OIDC 발급자 URL과 주체(subject)** 에 직접 역할을 부여할 수 있어야 함 ### 구조적 문제와 결론 - 현재 Google Cloud 통합은 다음 세 가지 중 **두 가지 선택만 가능** 1. 장기 자격 증명 없음 2. 고객이 쉽게 설정 가능 3. 임의 정지로부터 안전 - SSLMate의 **서비스 계정 기반 방식**은 보안과 편의성은 확보하지만 정지 위험 존재 - **서비스 계정+키 방식**은 설정이 쉽고 정지 위험은 낮지만 보안이 약함 - **OIDC 방식**은 보안과 정지 안전성은 높지만 설정이 복잡함 - Google이 **OIDC를 1급 통합 방식으로 단순화**하지 않는 한, 안전하고 안정적인 통합은 어렵다는 결론 ### 독자 댓글 요약 - 한 독자는 “**다른 클라우드 제공자를 사용하라, GCP는 최악**”이라고 언급 - 작성자는 “고객이 GCP를 사용하기 때문에 통합을 위해 필요하다”고 응답 - 또 다른 독자는 “**보안과 신뢰성이 단순함과 충돌한다**”며, 단순함을 우선하는 고객은 적합하지 않다고 지적 ## Comments ### Comment 45972 - Author: ndrgrd - Created: 2025-11-06T12:09:38+09:00 - Points: 1 "Android developer verification would end up just like this. Lots of people would be banned from developing for Android." Hacker News 의견 중 가장 기억에 남는 것이네요. 머지 않았다고 생각합니다. ### Comment 45837 - Author: neo - Created: 2025-11-04T09:43:03+09:00 - Points: 1 ###### [Hacker News 의견](https://news.ycombinator.com/item?id=45798827) - 사람들은 Google을 **신뢰할 수 있는 파트너**로 생각하지만, 실제로는 대규모 리테일 공장처럼 설계된 시스템임 수백만 명을 대상으로 하며, 잘못된 **자동 보호 조치** 하나로 수천 명의 삶이 망가질 수 있음 고객 지원 부재나 자동화된 무의미한 답변은 단순한 비용 절감이 아니라 **법적 책임 최소화 전략**으로 보임 - “Google을 신뢰한다”는 말에 웃음이 나옴 대부분의 사람들은 Google 계정이 언제든 이유 없이 정지될 수 있다는 걸 알고 있음 실제로 주변에 계정 접근을 잃은 사람을 한두 명쯤은 다 알고 있음 수백만 달러 규모의 계약이 아닌 이상 Google을 진정한 파트너로 보는 사람은 거의 없다고 생각함 - 모든 플랫폼이 **규모 확장**을 우선시함 개별 사용자와 인간적인 관계를 유지하면서도 마약상 수준의 수익성을 유지하는 건 불가능함 선량한 사람 한 명이 잘못 걸려도 ‘필요한 비용’으로 간주됨 어제는 Wise, 그 전에는 GitHub 계정이 이런 식으로 차단됨 기업은 민주주의가 아니라 **봉건 영지**처럼 운영됨 자동화된 시스템이 당신을 범죄자로 판단하면 재판 없이 바로 처벌함 - 그래서 나는 항상 **작은 회사**를 선택하려 함 실제 사람과 대화할 수 있고, 단순한 챗봇이 아님 지금은 Tuta Mail을 쓰고 있는데, **양자 내성 암호화**와 광고 없는 환경이 마음에 듦 내 도메인으로 원하는 만큼 별칭 주소도 만들 수 있음 - 몇 년 전 내 YouTube Premium 계정이 스팸 이유로 차단되었음 단순히 영상 시청만 했는데도 계정이 삭제되고 결제 페이지 접근도 막힘 3주마다 한 번씩만 가능한 **로봇식 항소 절차**를 거치는 동안 계속 요금이 청구됨 Google One의 유료 지원도 “다른 팀이라서 도움 불가”라며 무용지물이었음 결국 카드 해지를 통해 해결했는데, 몇 달 뒤 “실수였다”는 메시지를 받음 아이러니하게도 WeChat은 하루 만에 사람과 통화해 해결했음 — **검열국가의 고객지원이 더 낫다**는 생각이 들었음 - 문제는 Google만이 아니라, **알고리즘 의존형 대기업 구조** 전반에 있음 Reddit에서도 20년 된 내 계정이 이유 없이 **섀도밴** 당했음 항소는 묵살되고, 글과 댓글이 모두 필터링됨 **Fediverse**는 더 나은 대안 모델을 보여줌 — 작은 커뮤니티와 높은 모더레이터 비율이 핵심임 - 하지만 Fediverse도 완벽하지 않음 #fediblock 태그 하나로 수백 개 서버에서 자동 차단되는 구조는 **책임 없는 검열**을 반복하게 만듦 실제로 우리 도시의 Mastodon 인스턴스가 그렇게 망했고, 모두 Bluesky로 옮겨감 - Google은 충분한 자금이 있음 이런 **엣지 케이스**를 처리할 인력을 100명쯤 두는 건 어렵지 않음 하지만 마진이 줄어들기 때문에 그렇게 하지 않음 - 수조 달러 규모의 기업들이 “알고리즘밖에 방법이 없다”고 말하는 건 핑계임 돈이 없어서가 아니라, **쓰지 않기로 선택**한 것임 - 앞으로 **Gemini API**에서도 이런 문제가 생길 것 같음 고객이 규정을 어긴 이미지를 생성하면, 그 즉시 **비즈니스 Gmail**이나 개인 복구용 Gmail까지 영구 정지될 수 있음 - 외부 고객이 데이터를 입력하거나 이미지를 생성한다면, **내장된 모더레이션 도구**를 반드시 활성화해야 함 - Android 개발자 인증도 이런 식으로 흘러갈 것 같음 많은 개발자가 이유 없이 **개발자 자격 정지**를 당할 가능성이 큼 - 사실 이미 심각한 수준임 예전에 한 소규모 회사 직원들의 개인 계정이 “이전에 정지된 개발자 계정과 연관됨”이라는 이유로 함께 차단된 사례를 봤음 - 근본적으로, Android 개발은 **남의 땅에서 농사짓는 소작농** 같은 구조임 플랫폼에 종속된 상태에서 전문성을 유지하기 어렵다고 생각함 - 우리 서비스도 단순히 “Login with Google” 버튼만 사용했는데, 갑자기 계정이 차단됨 “약관 위반”이라는 모호한 이유뿐이었음 항소를 넣고 사용자 로그인 대안을 급히 마련하던 중, 다음날 갑자기 “항소 승인” 메일이 옴 결과적으로 복구되긴 했지만, **불신감**이 남았음 - 나 같으면 이제 “Login with Google” 지원을 중단할 것임 - **소셜 로그인** 대신 사용자명/비밀번호, MFA, Passkey만 사용하는 게 낫다고 생각함 - 내 AdSense 계정은 광고에 **느낌표 하나** 넣었다는 이유로 세 번 정지됨 결국 계정을 닫았지만, 여전히 “잠재적 사기 계정”으로 추적되고 있을 것 같음 - 말도 안 됨. 규칙 위반 광고를 자동으로 차단할 수 있는 시스템이 있다면, **광고 작성 중에 경고**라도 줘야 함 새 사용자가 한 시간 만에 정지당하는 구조라면, 애초에 가입 절차를 왜 그렇게 쉽게 만든 건지 의문임 - 내 계정도 같은 이유로 **영구 정지**되었음. 수년 전 일이지만 아직도 황당함 - 느낌표가 문제라니, 인쇄 광고에선 예전부터 흔한 문장부호인데 납득이 안 됨 - 정말 느낌표가 금지된 건지, 아니면 단순한 **시스템 오류**인지 궁금함 - 이런 상황이라면 Google을 **소송하거나 규제 강화**를 요구해야 하는지 고민됨 - 하지만 “회사가 나와 거래를 거부했다”는 이유만으로는 소송 근거가 약함 - 그래도 **소액 재판**에서는 승산이 있음 Google이 출석하지 않거나, TOS를 근거로 변명하다가 판사에게 역효과를 내는 경우가 많다고 들음 - 정지된 이메일 계정으로 등록된 **Passkey 전용 로그인 계정**은 어떻게 되는지 궁금함 Google Password Manager에 동기화된 Passkey가 계정 정지 후에도 작동하는지, 혹은 이메일 접근이 막혀 복구가 불가능한지 테스트해본 사람은 거의 없을 것 같음