하루아침에 Google Cloud 청구서가 37만 5천원. 평소에는 0원이던 대시보드에 갑자기 ₩375K가 찍혀있다면 어떤 기분일까. 실제로 Google Places API를 사용해 평점 데이터를 조회하다가 하루 만에 이 금액을 청구받은 개발자의 사례가 커뮤니티에서 화제가 됐다.
이런 일은 결코 드물지 않다. Reddit에서만 45만 달러(약 6억 5천만원) 청구 사례, GitHub에 API 키 노출 후 13분 만에 50만원 과금 사례, 학생 개발자의 Gemini API 키 유출로 5만 5천 달러(약 8,150만원) 청구 사례 등이 지속적으로 보고된다. 2024년 기준 GitHub에서만 연간 3,900만 건의 비밀정보(API 키, 토큰 등)가 유출되고 있다.
이 글에서는 Google API 요금 폭탄이 발생하는 정확한 메커니즘, 즉시 취해야 할 긴급 대처법, 그리고 다시는 같은 일을 겪지 않기 위한 예방 설정법을 단계별로 정리한다.
Google Places API 요금 체계와 폭탄이 터지는 원리
Google Places API는 종량제(pay-as-you-go) 모델로 운영된다. 요청을 보낼 때마다 사용한 기능(SKU)에 따라 과금이 발생하는 구조다. 문제는 이 과금 단위가 생각보다 복잡하고, 개발자가 의도치 않게 고가의 SKU를 호출하기 쉽다는 데 있다.
Places API의 SKU는 Essentials, Pro, Enterprise 세 등급으로 나뉜다. 평점(rating), 리뷰(reviews), 영업시간 같은 필드를 요청하면 요금이 올라간다. 특히 평점과 리뷰를 함께 조회하는 Place Details Enterprise + Atmosphere SKU는 1,000건당 25달러(약 3만 6천원)에 달한다.
| SKU 등급 | 요청 필드 예시 | 1,000건당 요금 | 월 1만 건 기준 |
|---|---|---|---|
| Essentials | place_id, 주소, 이름 | 무료 (월 10,000건) | 0원 |
| Pro | 영업시간, 전화번호, 웹사이트 | 약 7달러 | 약 10만원 |
| Enterprise | 평점, 리뷰, 사진 | 20 - 25달러 | 약 29 - 36만원 |
하루에 23만 5천원이 과금되었다는 것은, Enterprise급 필드를 포함한 요청이 약 9,000 - 12,000건 가량 발생했다는 뜻이다. 반복문 안에서 API를 호출했거나, 배치 스크립트에 딜레이 없이 연속 요청을 보낸 경우 이 정도 수치는 몇 시간이면 충분히 도달한다.
Place Details 요청 시 FieldMask(필드 마스크)를 반드시 지정해야 한다. 필드를 지정하지 않으면 모든 데이터가 반환되면서 가장 비싼 SKU로 과금된다. 예를 들어 평점만 필요하면 fields=rating만 요청하고, 리뷰가 필요 없다면 reviews 필드를 절대 포함하지 않아야 한다.
2025년 3월 이전에는 Google Maps Platform에서 매월 200달러의 무료 크레딧을 제공했다. 그러나 2025년 3월 1일부터 이 정책이 변경되어 SKU별 월간 무료 요청 건수로 대체되었다. Essentials 등급은 월 10,000건, Pro 등급은 월 5,000건이 무료이며, 이를 초과하면 바로 과금이 시작된다.
2025년 3월 가격 정책 변경 이후, 기존에 무료로 사용하던 수준의 호출량도 갑자기 유료가 될 수 있다. 기존 200달러 크레딧 체계에 익숙한 개발자라면 반드시 새로운 SKU별 무료 한도를 확인해야 한다.
요금 폭탄 발생 시 긴급 대처 5단계
청구서에 예상치 못한 금액이 찍혀 있다면, 패닉에 빠지기 전에 아래 순서를 따라야 한다. 빠른 대응이 피해 규모를 줄이는 핵심이다.
1단계: API 키 즉시 비활성화
Google Cloud 콘솔에 로그인한 뒤 APIs & Services > Credentials로 이동한다. 문제가 된 API 키를 찾아 비활성화하거나 삭제한다. 이 작업이 가장 먼저 이루어져야 추가 과금을 차단할 수 있다.
2단계: 결제 계정 확인 및 프로젝트 결제 비활성화
Cloud Billing 계정의 계정 관리 페이지로 이동한다. 해당 프로젝트를 찾아 결제 비활성화(Disable billing)를 선택한다. 이렇게 하면 프로젝트 내 모든 유료 서비스가 중단된다.
3단계: 사용량 분석
Billing > Reports 메뉴에서 어떤 API가 얼마나 호출되었는지 확인한다. SKU별 사용량과 비용을 파악하면 이의 제기 시 명확한 근거를 제시할 수 있다.
4단계: Billing Support에 이의 제기
Google Cloud 콘솔에서 도움말 및 지원 > 결제 지원으로 이동한다. 결제 도우미(Billing Assistant)를 통해 사유를 설명하고 크레딧 조정 또는 환불을 요청한다.
5단계: 결과 대기 및 추가 조치
Reddit 사례를 보면, Google은 의도치 않은 과금에 대해 일회성 크레딧 조정을 해주는 경우가 많다. 한 사용자는 5천 달러 청구를 취소받았고, 다른 사용자는 청구 금액의 75%를 환불받은 사례도 보고되었다.
이의 제기 시 "의도치 않은 사용이었음", "테스트/개발 중 실수", "향후 재발 방지를 위해 취한 조치"를 명확히 기술하면 크레딧 조정 가능성이 높아진다. 특히 처음 발생한 경우 호의적으로 처리되는 경향이 있다.
| 대처 단계 | 작업 | 소요 시간 | 우선순위 |
|---|---|---|---|
| 1단계 | API 키 비활성화 | 1분 | 최우선 |
| 2단계 | 프로젝트 결제 비활성화 | 3분 | 긴급 |
| 3단계 | 사용량 리포트 분석 | 10분 | 높음 |
| 4단계 | Billing Support 이의 제기 | 15분 | 높음 |
| 5단계 | 환불/크레딧 조정 대기 | 1 - 7일 | 대기 |
프로젝트를 삭제하면 사용량 기록까지 사라져서 이의 제기가 어려워질 수 있다. 반드시 결제 비활성화를 먼저 한 뒤, 리포트를 스크린샷으로 보관하고 나서 프로젝트 삭제를 진행해야 한다.
다시는 당하지 않기 위한 예방 설정 체크리스트
Google Cloud에서 API 요금 폭탄을 방지하려면, API를 사용하기 전에 반드시 세 가지 안전장치를 설정해야 한다. 이 중 하나라도 빠지면 동일한 사고가 언제든 재발할 수 있다.
예산 알림(Budget Alert) 설정
Google Cloud 콘솔에서 결제 > 예산 및 알림으로 이동한다. 예산 만들기를 클릭하고 대상 프로젝트와 목표 금액을 설정한다. 알림 기준은 50%, 90%, 100%로 단계별 설정이 가능하다. 실제 사용량(Actual)과 예측 사용량(Forecasted) 두 가지 모두에 알림을 걸어두는 것이 안전하다.
더 강력한 방법도 있다. Cloud Functions를 연동해서 예산 임계값 도달 시 자동으로 결제를 비활성화하는 스크립트를 설정할 수 있다. Google 공식 문서에서 이 방법을 안내하고 있으며, Pub/Sub 토픽을 통해 예산 알림이 트리거되면 Cloud Billing API를 호출해 프로젝트 결제를 자동 중단하는 구조다.
예산 알림만으로는 과금 자체를 막지 못한다. 알림은 말 그대로 "알림"일 뿐이다. 실제 과금을 차단하려면 Quota(할당량) 설정 또는 Cloud Functions 자동 비활성화 스크립트를 반드시 병행해야 한다.
API 할당량(Quota) 제한 설정
Google Cloud 콘솔에서 Google Maps Platform > 할당량으로 이동한다. 사용 중인 API를 선택하고, 일일 요청 한도와 분당 요청 한도를 원하는 수치로 낮춘다. 예를 들어 Places API의 일일 요청을 1,000건으로 제한하면, 아무리 코드에 버그가 있어도 그 이상 호출이 차단된다.
| 설정 항목 | 권장 값 (소규모 프로젝트) | 설정 경로 |
|---|---|---|
| 일일 예산 알림 | 10,000원 | 결제 > 예산 및 알림 |
| Places API 일일 요청 한도 | 500 - 1,000건 | Maps Platform > 할당량 |
| Places API 분당 요청 한도 | 10 - 50건 | Maps Platform > 할당량 |
| API 키 제한 (도메인/IP) | 프로젝트별 설정 | APIs & Services > Credentials |
API 키 보안 강화
API 키 보안은 요금 폭탄 예방의 가장 기본이다. Google의 공식 보안 가이드에 따르면, 모든 API 키에는 반드시 애플리케이션 제한(Application Restriction)과 API 제한(API Restriction) 두 가지를 동시에 적용해야 한다.
애플리케이션 제한은 해당 키를 사용할 수 있는 도메인, IP 주소, 또는 앱 번들 ID를 지정하는 것이다. API 제한은 해당 키로 호출할 수 있는 API 종류를 한정하는 것이다. 예를 들어 Places API만 사용하는 키에 Directions API, Translation API 등이 함께 열려 있으면, 키가 노출될 경우 피해 범위가 확대된다.
코드에 API 키를 직접 하드코딩하는 것은 절대 금지다. 환경 변수(.env) 또는 Secret Manager를 사용해야 하며, 절대로 GitHub 등 공개 저장소에 API 키가 포함된 코드를 푸시해서는 안 된다. 2024년 기준 GitHub에서 연간 3,900만 건의 시크릿이 유출된다는 통계가 이를 뒷받침한다. GitHub에 키를 올린 지 13분 만에 50만원이 과금된 실제 사례도 있다.
.gitignore에 .env 파일을 추가했더라도, 과거 커밋에 API 키가 남아있을 수 있다. git의 히스토리에서 완전히 제거하려면 git filter-branch 또는 BFG Repo-Cleaner를 사용해야 한다. 키가 한 번이라도 공개 저장소에 노출되었다면, 해당 키는 즉시 폐기하고 새 키를 발급받아야 한다.
코드 레벨에서 API 비용을 줄이는 실전 기법
예방 설정만큼 중요한 것이 코드 작성 방식이다. 같은 기능을 구현하더라도 호출 방식에 따라 비용 차이가 수 배에서 수십 배까지 벌어진다.
필드 마스크를 반드시 사용한다. Place Details 요청 시 필요한 필드만 정확히 지정하면 낮은 SKU 등급으로 과금된다. 평점만 필요하다면 fields=rating만 요청하고, 리뷰가 필요하면 Enterprise 비용을 각오해야 한다.
Place ID를 캐싱한다. Google의 약관상 Place Details 결과는 30일간 캐싱이 허용된다. Place ID 자체는 무제한 저장 가능하다. 동일한 장소 정보를 반복 조회하지 말고 로컬 DB에 캐싱해두면 호출 횟수를 극적으로 줄일 수 있다.
반복문에 딜레이를 삽입한다. for 루프 안에서 API를 연속 호출하면 수천 건이 순식간에 나간다. 최소 100 - 200ms 단위의 딜레이를 삽입하고, 가능하면 일일 호출 카운터를 코드 레벨에서도 관리해야 한다.
Autocomplete 세션 토큰을 활용한다. 자동완성 기능을 구현할 때 세션 토큰을 사용하면, 여러 번의 자동완성 요청과 한 번의 Place Details 요청이 하나의 세션으로 묶여 비용이 절감된다. 세션 토큰 없이 요청하면 건건이 별도 과금된다.
개발 환경과 프로덕션 환경의 API 키를 분리하는 것이 필수다. 개발용 키에는 일일 100건 같은 극단적으로 낮은 할당량을 설정해두면, 코드 버그로 인한 요금 폭탄 위험을 원천 차단할 수 있다.
Google API 요금 사고는 개발자라면 누구나 한 번쯤 겪을 수 있는 문제다. 하루 23만원은 뼈아프지만, 수백만원이나 수천만원 단위의 사례와 비교하면 오히려 빠르게 발견하고 차단한 것이 다행이다.
핵심은 사후 대처가 아니라 사전 예방이다. 예산 알림, 할당량 제한, API 키 보안이라는 세 가지 안전장치를 모두 갖추면 실수가 발생하더라도 피해를 최소화할 수 있다. 특히 Google Cloud의 예산 알림은 설정에 5분도 걸리지 않지만, 이 5분이 수십만원의 차이를 만든다.
지금 당장 Google Cloud 콘솔에 접속해서 결제 > 예산 및 알림으로 이동하고, 프로젝트별 예산을 설정하라. 이미 API를 사용 중이라면 할당량 메뉴에서 일일 요청 한도를 확인하고, 필요 이상으로 높게 잡혀있는 값을 낮추는 것이 첫 번째 할 일이다.
의도치 않은 과금이 이미 발생했다면, 프로젝트를 삭제하기 전에 반드시 사용량 리포트를 저장하고 Billing Support에 이의 제기부터 진행해야 한다. Google은 최초 1회에 한해 크레딧 조정에 비교적 관대한 편이다. 비싼 수업료를 낸 만큼, 같은 실수를 두 번 하지 않을 수 있는 환경을 지금 만들어두자.