▲

Google이 내 회사의 Google Cloud 계정을 세 번째로 정지시켰다

 (agwa.name)
1P by GN⁺ 14시간전 | ★ favorite | 댓글 1개
  • 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를 사용하기 때문에 통합을 위해 필요하다”고 응답
  • 또 다른 독자는 “보안과 신뢰성이 단순함과 충돌한다”며, 단순함을 우선하는 고객은 적합하지 않다고 지적
▲
GN⁺ 14시간전  [-]
Hacker News 의견

  • 사람들은 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가 계정 정지 후에도 작동하는지,
    혹은 이메일 접근이 막혀 복구가 불가능한지 테스트해본 사람은 거의 없을 것 같음

답변달기