Gemini API 비용을 줄이고 싶다면 모델 단가표만 보면 부족합니다. 2026년 6월 기준 Gemini 관련 문서와 가격 가이드에서 반복적으로 확인되는 실무 포인트는 Batch API입니다. 비동기 처리에 적합한 workload를 batch로 보내면 input과 output 비용을 크게 줄일 수 있고, 여러 가격 가이드에서는 50% 할인 구조를 핵심 장점으로 설명합니다. 다만 모든 요청을 batch로 옮기는 것은 답이 아닙니다. 실시간 응답이 필요한 기능과 기다려도 되는 기능을 먼저 나눠야 합니다.
이 글은 Gemini API Batch API를 “싸게 쓰는 옵션”이 아니라 “AI 기능을 sync와 async로 분리하는 설계 기준”으로 정리합니다. 검색 의도는 명확합니다. Gemini API 비용을 줄이고 싶지만 사용자 경험을 망치지 않으려는 개발자, 운영자, PM을 위한 글입니다.
Batch API의 본질은 지연 시간을 비용과 교환하는 것입니다. 즉시 답을 줘야 하는 채팅, IDE autocomplete, 실시간 상담, 음성 인터랙션에는 맞지 않습니다. 반대로 사용자가 기다리지 않아도 되는 작업에는 잘 맞습니다.
좋은 후보는 다음과 같습니다.
공통점은 사용자가 화면 앞에서 기다리지 않는다는 것입니다. 처리 결과가 몇 분에서 몇 시간 뒤에 나와도 괜찮고, 실패한 항목을 재처리할 수 있으며, 결과 품질을 샘플링해서 검수할 수 있습니다.
많은 팀이 AI 비용을 줄일 때 먼저 더 싼 모델을 찾습니다. 물론 중요합니다. 하지만 더 큰 절감은 요청을 분류하는 데서 나옵니다. 같은 기능 안에서도 모든 요청이 같은 SLA를 요구하지 않습니다.
예를 들어 채용 서비스의 이력서 분석 기능을 봅시다. 사용자가 업로드 직후 보는 첫 화면에는 5초 이내 요약이 필요할 수 있습니다. 하지만 전체 직무 적합도 분석, 키워드 추출, 면접 질문 생성, 포트폴리오 개선 제안은 10분 뒤에 나와도 됩니다. 이때 첫 요약만 synchronous API로 처리하고 나머지는 batch queue로 보냅니다.
이 구조를 쓰면 사용자 경험은 유지하면서 비용을 줄일 수 있습니다. 또한 batch 작업은 재시도, backoff, 샘플 QA, 결과 캐싱을 적용하기 쉽습니다. 실시간 요청보다 운영 통제가 쉽다는 것도 장점입니다.
Batch API를 도입하기 전에는 다음 네 가지를 실제 로그로 계산해야 합니다.
첫째, 요청 수입니다. 하루 100건이면 batch 전환으로 얻는 절감보다 구현 비용이 더 클 수 있습니다. 하루 10만 건이라면 이야기가 달라집니다.
둘째, 평균 token이 아니라 p95 token입니다. 긴 문서 몇 개가 비용 대부분을 만들 수 있습니다. batch 전환 대상은 평균보다 긴 tail을 먼저 봐야 합니다.
셋째, deadline입니다. “언젠가 처리”와 “30분 안에 처리”는 다른 시스템입니다. 24시간 turnaround가 가능한 작업인지, 사용자에게 진행 상태를 보여줘야 하는지 정해야 합니다.
넷째, 재처리 가능성입니다. 일부 항목 실패 시 전체 batch를 다시 돌릴지, 실패 row만 재시도할지 설계해야 합니다. 대량 작업에서 재처리 단위가 크면 할인분을 재시도 비용으로 날릴 수 있습니다.
실무 구조는 단순해야 합니다. 사용자 요청이 들어오면 즉시 job row를 만듭니다. job에는 input 위치, 모델, schema version, deadline, 상태를 저장합니다. batch worker는 일정 주기마다 pending job을 모아 Gemini Batch API로 제출합니다. 완료 결과는 result store에 저장하고, 프론트엔드는 polling 또는 webhook으로 상태를 보여줍니다.
중요한 것은 원본 입력과 모델 출력을 분리 저장하는 것입니다. 나중에 프롬프트 버전이 바뀌면 같은 입력으로 재처리해야 할 수 있습니다. 또한 결과 schema가 바뀌면 과거 output을 migration하거나 재생성해야 합니다.
상태값은 최소한 다음 정도가 필요합니다.
이 상태가 없으면 운영자는 “AI가 느립니다”라는 말밖에 할 수 없습니다. batch 시스템에서는 진행률과 실패 원인 노출이 사용자 신뢰를 만듭니다.
Batch 작업은 실시간 응답보다 품질 관리를 적용하기 좋습니다. 결과가 사용자에게 바로 보이지 않기 때문입니다. 다만 검증 로직 없이 대량 output을 그대로 저장하면 나중에 더 큰 문제가 됩니다.
추천하는 검증은 세 가지입니다. 첫째, schema 검증입니다. JSON 결과라면 required field, enum, array length를 체크합니다. 둘째, business rule 검증입니다. 예를 들어 점수는 0100 사이여야 하고, 추천 태그는 허용 목록 안에 있어야 합니다. 셋째, sampling QA입니다. 매 batch마다 13%를 사람이 보거나, 별도 judge 모델로 이상치를 표시합니다.
특히 Gemini의 긴 컨텍스트를 활용해 문서 분석을 batch로 돌릴 때는 hallucination 검사가 중요합니다. 결과에 원문 근거 문장이나 page reference를 포함시키면 검수 비용을 줄일 수 있습니다.
Gemini API Batch API의 50% 할인은 매력적입니다. 하지만 진짜 효과는 할인율이 아니라 제품 구조를 실시간과 비동기로 나누는 데서 나옵니다. 모든 AI 요청을 같은 길로 보내는 서비스는 비용도 높고 장애 대응도 어렵습니다. Batch API는 비용 최적화 도구이면서 동시에 AI workload를 정리하게 만드는 운영 도구입니다.
