Gemini Search Grounding, 실제로는 얼마나 드는가 — 흔한 "토큰 인플레이션" 오해 바로잡기
생성형 AI 서비스에 실시간성과 사실 정확도를 더하고 싶을 때 가장 먼저 떠오르는 옵션이 Google의 **Gemini Search Grounding(구글 검색 그라운딩)**입니다. 이 블로그의 팩트체크 파이프라인도 매일 이 기능을 실제로 호출합니다.
문제는 이 기능의 비용 구조에 대해 인터넷에 퍼진 설명 중 상당수가 부정확하다는 점입니다. 특히 “검색 결과가 프롬프트에 통째로 주입되니 입력 토큰 비용이 몇 배로 뛴다”는 식의 설명을 자주 보게 되는데, 이는 Google의 공식 과금 정책과 다릅니다. 실제 요금 체계를 정확히 짚어보겠습니다.
Grounding 비용은 딱 하나, “검색 쿼리당 정액 요금”
Gemini Search Grounding의 과금 구조는 생각보다 단순합니다. 검색이 실제로 수행된 횟수에 대해서만 정액 요금이 부과되며, 모델 세대에 따라 단가와 무료 제공량이 다릅니다.
| 모델 세대 | 무료 제공량 | 초과분 단가 |
|---|---|---|
| Gemini 3.x 계열 | 월 5,000건 (Gemini 3 제품군 공유) | 1,000건당 $14 |
| Gemini 2.5 계열 | 일 1,500건 (공유 쿼터) | 1,000건당 $35 |
주목할 부분은 최신 Gemini 3.x 계열로 넘어오면서 단가가 절반 이하로 인하되고, 무료 제공량도 일 단위에서 월 단위(5,000건)로 넉넉해졌다는 점입니다. 이 블로그의 팩트체크 스크립트가 기본값으로 쓰는 모델도 gemini-3.5-flash, 즉 Gemini 3.x 계열이라 이 요금 체계가 그대로 적용됩니다.
흔히 오해하는 “입력 토큰 폭탄”은 실제로 존재하지 않는다
Grounding을 켜면 Gemini가 검색한 웹 문서 스니펫이 모델의 컨텍스트로 들어가는 것은 맞습니다. 여기서 “그러니 입력 토큰 비용도 같이 올라가는 것 아니냐”는 추측이 자연스럽게 나옵니다.
하지만 Google 공식 가격 정책은 이 부분을 명시적으로 다르게 규정합니다. Grounding with Google Search를 통해 유입된 참조 컨텍스트(Retrieved Context)는 입력 토큰으로 과금되지 않습니다. 검색으로 가져온 텍스트가 아무리 길어도, 그 부분 때문에 입력 토큰 단가가 추가로 청구되지는 않는다는 뜻입니다. (참고로 OpenAI의 웹 검색 도구는 반대로 검색 컨텍스트도 입력 토큰에 포함해 과금하는 방식이라, 이 지점에서 두 플랫폼의 비용 구조가 갈립니다.)
정리하면, Grounding 비용에서 신경 써야 할 변수는 사실상 하나뿐입니다. 검색이 몇 번 실행됐는가. 검색 결과가 얼마나 길게 딸려 왔는지는 청구서에 영향을 주지 않습니다.
작은 프로젝트라면 사실상 무료 구간 안에 들어온다
이 사실은 이 블로그 같은 소규모 자동화 파이프라인 입장에서는 꽤 중요합니다. 팩트체크 스크립트는 하루에 새 초안이 나올 때 딱 한 번 Grounding을 호출합니다. 한 달로 치면 30회 안팎입니다.
Gemini 3.x 계열의 월 5,000건 무료 제공량과 비교하면, 이 정도 호출량은 무료 구간의 1%도 채우지 못합니다. 즉 이 블로그의 팩트체크 기능 자체는 Grounding 요금만 놓고 보면 사실상 비용이 발생하지 않는 구간에서 돌아가고 있습니다. (실제 청구되는 API 비용은 Grounding 요금이 아니라 모델 자체의 텍스트 생성 토큰 비용에서 대부분 발생합니다.)
물론 이는 “하루 한 번, 초안 한 건”이라는 낮은 호출 빈도 덕분입니다. 실시간 챗봇처럼 사용자 요청마다 Grounding을 켜는 서비스라면 이야기가 완전히 달라집니다.
그럼 비용이 실제로 문제 되는 지점은 어디인가
Grounding 요금이 정액제라고 해서 무한정 저렴하다는 뜻은 아닙니다. 트래픽 규모가 커지면 다음 두 가지 지점에서 실제로 비용이 쌓입니다.
- 호출 빈도 자체가 많아지는 경우. 사용자 요청마다 매번 Grounding을 켠다면, 하루 수만 건 단위로 정액 요금이 그대로 곱해집니다. 이때는 “정말 실시간 검색이 필요한 질문인지”를 먼저 걸러내는 것이 비용을 줄이는 가장 확실한 방법입니다.
- 중복 질문에 매번 새로 검색을 실행하는 경우. 같은 질문이 반복되는데도 매번 새로 Grounding을 호출하면 불필요한 정액 요금이 중복 지출됩니다. 짧은 시간 내 반복되는 질문은 이전 응답을 캐시해 재사용하는 편이 유리합니다.
이 두 가지를 관리하면, Grounding은 “검색 결과가 딸려 와서 입력 토큰이 폭증하는” 위험 없이 검색 쿼리 수만 통제하면 되는 비교적 예측 가능한 비용 구조를 갖습니다.
도입 전 체크할 것
Grounding을 프로젝트에 붙이기 전에 확인해 볼 만한 질문은 다음과 같습니다.
- 사용자 요청마다 실시간 검증이 정말 필요한가, 아니면 일부 요청에만 필요한가?
- 어떤 Gemini 모델 세대를 쓰느냐에 따라 단가와 무료 제공량이 다르므로, 최신 세대(Gemini 3.x)로 맞출 수 있는가?
- 예상 호출 빈도가 무료 제공량(3.x 기준 월 5,000건) 안에 들어오는가, 아니면 초과분에 대한 예산이 필요한가?
- 반복 질문에 대한 캐싱 레이어를 둘 수 있는 구조인가?
정리하면, Gemini Search Grounding의 비용은 “검색 결과가 프롬프트를 부풀려서 생기는 숨은 비용”이 아니라 “검색을 몇 번 실행했는가”에 달린 단순한 정액 요금 구조입니다. 이 차이를 알고 나면, 하루 몇 건 수준의 소규모 자동화 파이프라인은 무료 제공량 안에서 충분히 운영할 수 있고, 트래픽이 큰 서비스는 호출 빈도와 캐싱만 관리하면 예측 가능한 범위에서 비용을 통제할 수 있습니다.