제한 없는 Firebase browser key로 Gemini API를 호출해 13시간 만에 €54k가 급증

기존 Firebase 프로젝트에 Firebase AI Logic를 붙인 직후, 실제 사용자와 무관한 자동화 트래픽이 13시간 동안 몰리며 €54,000+ 청구가 발생했다.

프로젝트는 원래 Firebase Authentication 용도로만 쓰이던 상태였고, 브라우저용 API key에 적절한 제한이 없었던 점이 문제가 됐다. 이상 트래픽은 밤사이 집중됐고, API와 자격 증명을 중단·교체한 뒤에야 멈췄다.

운영 측면에서도 대응이 늦었다.

• €80 예산 알림과 비용 이상 탐지 알림이 있었지만 몇 시간 지연됐다.
• 대응 시점에는 이미 비용이 €28,000 수준까지 올라가 있었다.
• 최종 청구액은 지연 반영으로 **€54,000+**까지 확정됐다.

작성자는 Google Cloud 지원과 로그를 공유했지만, 요청은 유효한 사용량으로 분류돼 billing adjustment가 거절됐다. 즉, 서비스 의도와 무관한 이상 사용이었더라도, 프로젝트에서 발생한 트래픽이라는 이유로 비용 책임이 유지된 셈이다.

이에 대해 Google 측 응답도 붙었다. 핵심은 다음과 같다.

• Gemini API에는 tier spend caps와 project spend caps가 있으며, 둘 다 보고에 약 10분 지연이 있다.
• 앞으로는 unrestricted API keys 사용을 막는 방향으로 바뀌고 있다.
• 새 사용자에게는 더 안전한 Auth keys를 기본 생성한다.
• 키가 공개 웹에 노출되면 자동 차단되는 경우도 있다.
• Google AI Studio에서 생성한 키는 기본적으로 Gemini API 전용으로 제한되지만, 다른 Google Cloud 경로에서 만든 키는 cross-service 사용이 가능할 수 있어 재확인이 필요하다.
• 가능하면 client-side code에 키를 두지 말고, 필요한 경우 server-side로 옮기라고 권고했다.
• 신규 미국 billing account에는 prepaid billing도 도입 중이라고 안내했다.

결국 이 사례는, 브라우저에 노출된 key와 느린 비용 가시성이 결합되면 짧은 시간 안에 대규모 비용 사고가 날 수 있다는 점을 보여준다. App Check, quota, server-side 전환만으로는 충분하지 않을 수 있고, Gemini API에서는 spend cap과 키 제한 설정이 사실상 필수라는 경고성 사례다.