제미나이 API 파일 검색 비용 계산법의 핵심은 문서 색인 비용과 질문별 답변 생성 비용을 나누는 것이다. 문서를 한 번 등록한 뒤 같은 자료에 계속 질문한다면, 최초 임베딩 비용과 매번 발생하는 입력·출력 토큰 비용을 따로 계산해야 예산이 맞는다.
파일 크기와 질문 횟수만으로 견적을 내면 검색된 문서 조각의 입력 비용을 빠뜨리기 쉽다. 아래에서는 과금 구조를 먼저 정리하고, 최초 등록·문서 교체·반복 질문 계산을 거쳐 실제 등록 절차와 삭제 시 주의점까지 살펴본다.
제미나이 File Search 과금 구조: 색인과 질문 비용은 별도다
File Search는 문서를 가져와 조각으로 나누고 색인한 뒤, 질문과 관련된 내용을 찾아 모델에 전달하는 관리형 검색 기능이다. 비용을 이해할 때는 이 과정을 문서를 검색 가능하게 만드는 단계와 찾은 내용을 읽고 답변하는 단계로 나누면 편하다.
2026년 11월 3일 확인한 Google 공식 요금표는 File Search에서 Gemini Embedding을 사용하는 경우 임베딩 100만 토큰당 미화 0.15달러를 안내한다. 다만 현재 문서에는 Gemini Embedding 2를 사용하는 경로도 있으므로, 0.15달러를 모든 임베딩 모델의 공통 단가로 적용하면 안 된다. 아래 색인 계산은 gemini-embedding-001의 해당 유료 단가를 적용하는 경우를 전제로 한다. 출처: [Google Gemini API 공식 요금표](https://ai.google.dev/gemini-api/docs/pricing).
| 과금 항목 | 계산 기준과 적용 시점 |
|---|---|
| 문서 색인용 임베딩 | 문서 색인 시 임베딩 생성에 사용한 토큰 × 선택한 임베딩 단가 |
| File Search 파일 저장 | 무료 |
| 질문 시 임베딩 생성 | 무료 |
| 질문별 모델 입력 | 질문·지시문·대화 이력·검색 문맥 등 실제 입력 토큰에 모델 요금 적용 |
| 질문별 모델 출력 | 생성 토큰에 모델 요금 적용. 추론 토큰 포함 여부와 단가는 해당 모델 기준 확인 |
여기서 ‘질문 시 임베딩 생성 무료’는 질문에 대한 답변까지 무료라는 뜻이 아니다. Google은 파일 저장과 질문 시점의 임베딩 생성은 무료로 설명하면서도, 답변 생성에는 일반 Gemini 입력·출력 요금이 적용된다고 명시한다. 출처: [Google 공식 File Search 문서](https://ai.google.dev/gemini-api/docs/file-search).
문서 색인 비용 계산법: MB 대신 임베딩 토큰을 사용한다
문서 색인 비용의 기본식은 색인에 사용한 토큰 수 ÷ 1,000,000 × 임베딩 단가다. 0.15달러 단가가 적용되는 경로에서 100만 토큰을 색인하면 0.15달러, 1,000만 토큰이면 1.50달러다.
같은 10MB 파일이라도 이미지 비중, 추출되는 텍스트, 문서 구성에 따라 처리량이 달라질 수 있다. 페이지 수도 토큰 수를 대신하지 못하므로 ‘PDF 한 페이지당 얼마’처럼 고정 환산한 값은 예산의 확정 근거로 쓰기 어렵다.
최초 등록과 문서 교체를 나눈 계산 예시
다음 수치는 실제 기업의 사용 통계가 아니라, 공식 단가에 가정한 토큰 수를 대입한 계산 예시다. 최초 등록에 200만 토큰이 사용되고, 이후 교체 문서를 새로 색인하는 데 50만 토큰이 사용됐다고 가정한다.
- 최초 등록: 2,000,000 ÷ 1,000,000 × 0.15달러 = 0.30달러
- 교체 문서 등록: 500,000 ÷ 1,000,000 × 0.15달러 = 0.075달러
- 두 작업의 색인 비용 합계: 0.375달러
문서의 일부 문장만 수정했더라도 파일 전체를 다시 처리하는 방식이라면, 수정한 문장의 토큰 수만 넣어 계산해서는 안 된다. 예산에는 해당 등록 작업에서 실제로 임베딩을 생성한 처리량을 반영해야 한다.
한글 글자 수를 일정 비율로 나눠 토큰 수를 단정하는 것도 피하는 편이 좋다. 등록 전 추정치는 예산 범위를 잡는 데 사용하고, 처리 후에는 확인 가능한 사용량과 청구 내역으로 보정하는 방식이 현실적이다.
문서 색인 비용 계산법: MB 대신 임베딩 토큰을 사용한다 실시간 확인하기
질문별 토큰 과금 계산: 검색 문서 조각도 입력에 포함된다
질문이 짧아도 답변에 필요한 검색 문맥이 길면 입력 비용은 커질 수 있다. 예를 들어 질문과 지시문이 200토큰이고 검색된 문서 조각이 4,800토큰이라면, 두 항목만으로 이미 입력은 5,000토큰이다.
Google 공식 요금표는 검색된 문서 토큰을 모델의 일반 토큰 요금으로 과금한다고 명시한다. 따라서 질문 문장만 토큰으로 세어 질의 비용을 계산하면 검색 문맥만큼 견적이 누락된다. 출처: [Google Gemini API 공식 요금표](https://ai.google.dev/gemini-api/docs/pricing).
핵심 계산식
- 색인 비용 = 색인 토큰 ÷ 100만 × 임베딩 단가
- 질의 비용 = 과금 입력 토큰 ÷ 100만 × 입력 단가 + 과금 출력 토큰 ÷ 100만 × 출력 단가
- 기간 합계 = 최초·추가·교체 색인 비용 + 해당 기간의 모든 질의 비용
반복 질문 1,000회의 비용은 어떻게 계산할까
입력 단가를 P달러, 출력 단가를 Q달러로 두면 모델 변경에도 같은 계산식을 사용할 수 있다. 질문 한 번의 과금 입력이 5,000토큰, 과금 출력이 1,000토큰이고 이를 1,000회 반복한다면 총 입력은 500만 토큰, 총 출력은 100만 토큰이다.
이때 질의 합계는 5P + Q달러다. 앞서 계산한 최초·교체 색인 비용까지 더하면 총액은 0.375 + 5P + Q달러가 된다. P와 Q에는 실제 사용하는 Gemini 모델, 요금 구간, 처리 방식에 맞는 단가를 넣는다.
이 예시는 캐시 할인이나 다른 도구 비용 없이 같은 토큰 사용량이 반복된다는 조건이다. 추론 기능이 있는 모델은 화면에 보이는 답변 길이만으로 출력 과금량을 판단하지 말고, 응답 사용량에서 추론 관련 항목도 확인해야 한다.
운영 관점에서 중요한 변수는 문서 보관량보다 질문마다 모델이 읽는 문맥의 양과 질문 횟수다. 색인이 끝난 자료에 대한 질문이 누적될수록, 임베딩 단가를 조금 줄이는 것보다 불필요한 검색 문맥과 과도하게 긴 답변을 줄이는 일이 총비용에 더 큰 영향을 줄 수 있다.
File Search 문서 등록·질의 절차와 사용량 기록
계산식을 실제 서비스에 적용하려면 등록 작업과 질문 요청을 별도로 기록해야 한다. 아래 순서는 특정 SDK 버전의 실행 코드가 아니라, 구현과 비용 검증에 필요한 작업 흐름이다.
- 실행 환경을 기록한다. 사용 언어, SDK 패키지명과 설치 버전, API 버전, 임베딩 모델과 답변 모델 식별자를 남긴다.
- File Search 저장소를 만든다. 문서의 용도와 접근 범위를 정하고, 현재 API에서 지원하는 임베딩 설정을 확인한다.
- 파일을 업로드하거나 가져온다. 원본 파일 식별자와 저장소 안의 문서 식별자를 연결해 기록한다.
- 색인 작업 완료를 확인한다. 비동기 작업의 완료 여부와 오류를 확인한 뒤 검색 검증으로 넘어간다.
- 저장소를 지정해 질문한다. 관련 근거를 찾는지, 답변이 올바른 문서 버전을 인용하는지 확인한다.
- 응답 사용량을 저장한다. 사용 API와 SDK가 제공하는 usage_metadata 또는 대응 사용량 필드의 원본을 요청 식별자와 함께 보관한다.
Google 공식 문서의 예제도 저장소 생성, 파일 등록, 작업 완료 확인, 검색 도구를 사용한 질의 순서로 구성된다. API와 SDK에 따라 메서드명과 응답 구조가 달라질 수 있으므로, 예제 코드를 옮길 때는 설치한 버전과 맞는지 확인해야 한다. 출처: [Google 공식 File Search 문서](https://ai.google.dev/gemini-api/docs/file-search).
발행·배포 전 남겨야 할 검증 기록
재현 가능한 비용 검증에는 확인 날짜, SDK 버전, 모델명, 요청 조건, 응답 사용량이 함께 필요하다. 이 글에서는 SDK를 실행하지 않았으므로 특정 설치 버전이나 실제 usage_metadata 측정값을 제시하지 않는다.
- SDK 기록: Python의 google-genai 또는 JavaScript의 @google/genai 등 실제 패키지와 설치 버전
- 등록 기록: 문서 버전, 파일 해시, 저장소·문서 식별자, 작업 결과, 확인 가능한 색인 처리량
- 질의 기록: 요청 시각, 모델, 입력·출력·추론·캐시 관련 사용량, 사용량 응답 원본
- 대조 기록: 적용 단가와 적용일, 계산 금액, 청구 보고서에서 확인한 금액
질의 응답의 사용량을 문서 색인 토큰으로 재사용해서는 안 된다. 두 작업은 처리 목적과 과금 시점이 다르며, 사용량 필드만으로 검색 문맥의 세부 구성을 모두 분리할 수 있다고 가정해서도 안 된다.
File Search 문서 등록·질의 절차와 사용량 기록 바로가기
반복 색인과 문서 삭제 시 비용이 새는 지점
자동 배포나 정기 동기화가 실행될 때마다 같은 자료를 다시 등록하면 불필요한 색인 작업이 생길 수 있다. 파일명이 같다는 이유만으로 중복 등록이 자동 차단되거나 기존 색인이 재사용된다고 가정하지 않는 것이 안전하다.
원본 파일의 해시와 문서 버전을 비교해 변경된 자료만 처리하고, 등록 결과가 불확실할 때는 작업 상태부터 조회하는 방식이 좋다. 같은 요청을 무작정 재시도하면 중복 문서가 쌓여 검색 품질과 비용 추적이 함께 어려워질 수 있다.
원본 파일과 검색 저장소의 문서는 수명이 다르다
Google은 Files API로 업로드한 원본 파일은 48시간 뒤 삭제되지만, File Search 저장소에 가져온 데이터는 수동으로 삭제할 때까지 유지된다고 설명한다. 원본 파일의 만료를 검색 색인의 삭제로 이해하면 오래된 자료가 계속 검색될 수 있다. 출처: [Google 공식 File Search 문서](https://ai.google.dev/gemini-api/docs/file-search).
문서를 교체할 때는 새 버전의 색인 완료와 검색 결과를 확인한 뒤 이전 버전의 문서를 정리하는 절차가 필요하다. 전체 저장소 삭제는 연결된 검색 기능에 영향을 주므로, 개별 문서 정리로 충분한지 먼저 판단해야 한다.
삭제는 앞으로 검색할 대상을 정리하는 작업이다. 이미 수행한 색인이나 답변 생성 비용이 삭제만으로 없어지는 것으로 예산을 잡아서는 안 되며, 삭제 후 다시 등록한다면 새 색인 비용을 고려해야 한다.
비용 최적화의 기준도 단순히 ‘검색 문맥을 가장 짧게 만들기’에 두면 곤란하다. 근거가 부족해 재질문과 재생성이 늘면 오히려 총사용량이 커질 수 있으므로, 대표 질문에서 답변 품질과 질문당 비용을 함께 비교하는 편이 합리적이다.
제미나이 API 파일 검색 예산은 최초 등록·문서 교체·반복 질문으로 나누면 계산하기 쉽다. 색인에는 선택한 임베딩 단가를, 질문에는 검색 문맥을 포함한 실제 입력·출력 단가를 적용한다. 운영 전에는 SDK 버전과 응답 사용량을 남기고, 중복 색인과 이전 문서 잔존 여부를 확인하면 예상 비용과 실제 청구의 차이를 줄일 수 있다.