13시간 만에 €54,000 과금 폭증: API 제한 없는 Firebase 브라우저 키로 Gemini API 호출 발생

• Firebase 브라우저 키가 API 제한 없이 노출되어 외부에서 Gemini API 요청이 자동 발생, 단시간 내 막대한 과금이 발생
• 실제 사용자 트래픽과 무관하게 13시간 동안 €54,000 이상의 비용이 청구되었으며, 비용 경보가 지연 발동되어 대응이 늦어짐
• Google Cloud 지원팀은 해당 요청을 정상 사용(valid usage) 으로 분류해 요금 조정 요청을 거부함
• Google은 지출 한도, 인증 키, 자동 키 차단, 선불 결제 등 보호 기능을 도입하고, 무제한 키 사용을 단계적으로 중단할 예정
• 개발자는 클라이언트 코드에 키를 포함하지 말고, API 키 제한 및 예산 한도 설정을 반드시 적용해야 함

---

Firebase 브라우저 키 노출로 인한 Gemini API 과금 급등 사례

• 사건 개요

  • 기존 Firebase Authentication만 사용하던 프로젝트에서 Firebase AI Logic을 활성화한 직후 Gemini API 사용량이 급증
  • 실제 사용자 트래픽과 무관한 자동화된 요청이 단시간 내 발생해 약 13시간 동안 €54,000 이상의 과금이 발생
  • API를 비활성화하고 자격 증명(credential)을 회전한 후 비정상 트래픽이 중단됨
  • 예산 경보(€80) 및 비용 이상 탐지 경보가 수 시간 지연되어 발동, 대응 시점에는 이미 €28,000 수준의 비용 발생
  • 최종 청구 금액은 지연된 비용 보고로 €54,000 이상으로 확정됨

• Google Cloud 지원 결과

  • 로그와 분석 자료를 제출했으나, 요청이 프로젝트에서 발생한 유효 사용(valid usage) 으로 분류되어 요금 조정 요청이 거부됨
  • 해당 사용은 비정상적이며 사용자 주도 트래픽이 아님에도 불구하고, 시스템상 정상 과금으로 처리됨

• 사용자 문의 사항

  • Firebase AI Logic 또는 Gemini 활성화 후 유사 사례 존재 여부를 질문
  • App Check, 쿼터, 서버사이드 호출 이전 외에 추가적인 보호 수단이 있는지 문의
  • 이러한 경우에 대한 추가 이의 제기 경로(escalation path) 존재 여부 질의

Google 측 응답 (Logan Kilpatrick)

• 과금 및 사용 제한 기능

  • Gemini API 사용자용 과금 한도(billing account caps) 가 도입되어 있으며, Tier 1 사용자는 월 $250 한도 이후 자동 차단
  • 프로젝트 단위 지출 한도(project spend caps) 설정 가능, 예시로 개인 계정은 $50로 제한 설정
  • 모든 과금 보고에는 약 10분의 지연 시간 존재

• API 키 보안 및 변경 사항

  • 제한 없는 API 키(unrestricted key)사용은 곧Gemini API에서 비활성화 예정

    • 신규 사용자는 기본적으로 인증 키(Auth key) 가 생성되며, 이는 과거보다 보안성이 강화된 형태
    • 클라이언트 코드에 키를 포함하지 말 것, 노출 시 비용이 발생할 수 있음
    • 공개 웹에서 키가 노출되면 자동 감지 후 비활성화되는 기능이 존재하며, 실제로 몇 분 내 차단된 사례 있음

• 키 제한 및 서비스 범위

  • Google AI Studio에서 생성된 키는 기본적으로Gemini API 전용으로 제한

    • 반면 Google Cloud Console 등 다른 경로에서 생성된 키는 여러 서비스 접근 가능, 필요 시 서비스별 제한 설정 필요

• 추가 조치 및 향후 계획

  • 문제 사례 검토를 위해 직접 이메일([e-mail]) 로 연락 요청
  • 선불 과금(prepaid billing) 제도가 도입되어 사용 전 결제 방식으로 전환 중
  • 현재 미국 신규 계정에 적용 완료, 전 세계로 단계적 확대 중
  • 이러한 조치는 개발자의 비용 통제 및 예기치 않은 과금 방지 강화를 목표로 함

[GN⁺]

Hacker News 의견들

• 우리는 예산 알림(€80) 과 비용 이상 알림을 설정했지만, 둘 다 몇 시간 지연되어 발동됨
  우리가 대응했을 때는 이미 비용이 €28,000에 달했고, 최종적으로 지연된 비용 보고로 인해 €54,000 이상이 청구되었음
  이런 상황에서 “하드 스펜딩 캡은 기술적으로 불가능하다”는 세 회사의 변명은 설득력이 없음

  • 그래서 나는 Google Cloud 같은 서비스를 가급적 사용하지 않음
    하드 캡이 불가능하다는 건 말이 안 되고, 최소한 사용자에게 선택권은 줘야 함
  • 정말 말도 안 되는 일임. 좋은 프로젝트를 만들다가 실수 한 번으로 €30,000~€50,000을 물게 되는 건 삶을 바꿀 정도의 타격임
    과거엔 이런 실수가 단순한 버그였지만, 이제는 파산으로 이어질 수 있음
  • 이런 건 불법이어야 함
    욕실 타일 교체를 맡겼는데 정원 리모델링 비용을 청구받는다면, 당연히 거부할 권리가 있음
  • 나는 매니저로서 이런 고객 서비스 재앙 때문에 Google Cloud를 피함
    하지만 통신사 과금 시스템을 다뤄본 경험상, TB 단위의 로그를 집계하는 데 시간이 걸리는 건 이해함
    다만 통신사는 보통 2~3%의 부실채권을 감안하고 고객을 배려함
    Google도 이런 상황에서는 더 우아한 대응을 해야 함
    특히 AI 키가 공개된 직후 이런 일이 발생했다면, Google이 키 스캐닝을 감지하고 차단했어야 함
  • Gemini API 문서에 따르면, 프로젝트 단위와 결제 계정 단위 모두에서 월별 지출 한도를 설정할 수 있다고 함
    하지만 실제로는 이 기능이 제대로 작동하지 않는 듯함

• 나도 비슷한 경험이 있음
  GCP에서 $100 예산을 설정했는데, 초과 후 5시간 뒤에야 이메일 알림을 받았음
  이런 기능이 우선순위가 아니라는 게 놀라움
  단기적으로는 Google의 수익이 줄겠지만, 이런 경험을 한 개발자는 다시는 추천하지 않을 것임

  • 이런 얘기가 나올 때마다 화가 남
    우리 2인 팀이 runaway job 때문에 거의 망할 뻔했음
    GCP 권장 방식대로 알림과 kill switch를 연결했지만, 알림이 6시간 늦게 옴
    결국 증거를 제시해야만 환불받을 수 있었음
    Google은 “라인 아이템이 너무 많아서 파이프라인이 밀렸다”고 했는데, 바로 그 상황을 대비하라고 만든 시스템 아닌가
  • 알림 지연이 어떻게 용납되는지 이해할 수 없음
    결국 Google과 비용 정산은 어떻게 되었는지 궁금함
  • 사실 AWS도 이런 기능을 우선순위로 두지 않음
    어느 클라우드도 돈줄을 끊는 기능을 먼저 만들지 않음
  • “단기 수익을 위해 장기 신뢰를 버린다”는 말이 딱 맞음
    후기 자본주의의 전형적인 모습임

• GitHub 검색 결과를 보면, 공개 저장소에 Gemini API 토큰이 그대로 노출된 경우가 많음
  Google은 오랫동안 API 키를 비밀로 취급하지 않았고, LLM 키부터 갑자기 비밀로 바뀜
  아마 작성자가 프런트엔드나 코드 공유 과정에서 키를 노출했을 가능성이 큼

  • 예전부터 이 문제는 보고되었고, Google이 유출된 키를 Gemini API에서 차단하기로 했다고 했음
    관련 HN 스레드와 공식 문서에도 명시되어 있음
    그런데 왜 또 이런 사례가 나오는지 의문임
  • 실제로 검색 결과에는 진짜 키가 없음
  • 유출된 키는 즉시 무효화된다는 메시지가 뜸
    “Your API key was reported as leaked. Please use another API key.”
    즉, 대부분 자동으로 차단되는 듯함
  • API 키를 비밀로 취급하지 않는다는 게 말이 안 됨

• Google Cloud에는 하드 캡을 설정할 쉬운 방법이 없음
  나도 한 시간 넘게 설정을 찾다가 결국 Reddit에서 Pub/Sub → Cloud Function → 결제 비활성화 방식으로 알아냄
  완전히 광기 같은 구조임

  • 내가 좋아하는 테스트는 Gemini 모델에게 “프로젝트의 API 사용량을 가져오는 스크립트 작성”을 시키는 것임
    100% 실패율을 자랑함
  • 이런 건 사실상 사용자 함정(antifeature) 임
  • 아마도 의도된 설계일 것임
    사용자가 직접 만든 보호장치가 실패하면 “우리 책임 아님”이라고 말하기 쉬움
  • 이런 기능이 없다는 건, 회사가 사용자 보호에 인센티브가 부족함을 의미함
  • AWS나 Azure도 마찬가지임
    사용량이 임계치를 넘으면 자동으로 kill-switch가 작동하는 기능이 있으면 좋겠음
    5시간 다운타임은 괜찮지만, 거대한 청구서는 감당 불가임

• 이 글을 읽고 바로 내 Firebase 요금제를 다운그레이드했음
  한 달 동안 내가 호출하지도 않은 API로 $6,909가 청구되었다는 사례를 보고 충격받음
  나도 예전에 교육 세션 중에 API 키를 만들었는데, 혹시 사진으로 찍혔을 수도 있겠다는 생각이 듦

  • 정말 그 세션에서 누군가 키를 찍은 걸까? 원인이 궁금함

• 2020~21년에 학생들에게 클라우드 서비스를 가르치며 AWS Free Tier를 사용했음
  MediaWiki 서버를 띄웠는데, 스팸 계정이 계속 생기고 보안이 불안했음
  네트워크 포트가 항상 공격받는 느낌이었음
  결국 예산을 $20~30으로 제한할 방법이 없다는 걸 깨닫고 AWS를 포기함
  클라우드는 관리가 편해 보여도, 무제한 비용 폭탄이라는 점에서 개인이나 기업 모두에게 위험함

• 1인 개발자나 소규모 팀에게 퍼블릭 클라우드는 무섭고 불안한 환경임
  안전장치가 없고, 비용이 무한대로 치솟을 수 있음
  그래서 프로젝트의 상당 시간을 비용 감시와 차단 로직에 씀
  예전엔 단순 VPS를 썼지만, 요즘은 Google이나 AWS 서비스를 써야 할 때가 많음
  그래도 GCP는 프로그래밍적으로 결제 계정 연결을 끊을 수 있는 점이 조금 낫다고 느낌

  • 만약 그냥 돈을 안 내면 어떻게 될까 궁금함
    미국에서는 법적 문제가 생기겠지만, 다른 나라에서는 어떨지 모르겠음

• 이런 과금 시스템은 고객 경험(CX) 관점에서 설계가 엉망임
  과금은 이벤트 기반이라, 사용량이 큐에 쌓이고 집계가 지연됨
  알림도 집계 후에야 오기 때문에, 지연이 생기면 이미 한참 초과된 상태임
  이런 구조는 회사만 보호하고 고객은 보호하지 않음
  진짜 고객 중심이라면, 하드 리밋에 도달한 순간 그 금액 이상은 청구되지 않게 해야 함
  그래야 회사가 스스로 집계 시스템을 개선할 동기가 생김

  • 사실 이벤트 기반 자체는 문제 아님
    선불 요금제나 데이터 한도 서비스처럼 미리 차감하는 방식이면 충분히 가능함
    결국 Google의 비즈니스 관행 문제임

• Google Cloud 공식 문서에 따르면, 긴급 시 결제 계정을 비활성화해 과금을 멈출 수 있음
  공식 가이드에는 “복구 불가능한 리소스 손실 위험” 경고가 있음
  하지만 테스트나 내부용 앱에는 좋은 비상 브레이크임
  다른 대안 문서와 예산 알림 설정 문서도 참고할 만함

  • 다만 비용 발생과 알림 사이에 몇 시간~며칠의 지연이 있을 수 있음
    나는 5분 만에 $400을 쓴 적이 있음

• 우리도 같은 문제를 겪었음
  원래 비밀이 아니던 키가 Gemini API 활성화 후 비밀로 전환되었는데, 경고가 없었음
  다행히 알림으로 일찍 발견해서 피해가 $26,000으로 제한됨
  Google 지원팀에 환불을 요청했지만 처음엔 거절당했고, 지금은 재검토 중임
  이런 경우는 최대한 상위 부서까지 이슈를 escalate해야 함