요약: Gemini API의 Flex Inference와 Batch API는 “모델을 더 싸게 쓰는 기능”처럼 보이지만, 실제로는 작업 유형을 나누는 운영 전략에 가깝다. Flex Inference는 동기 요청 코드를 크게 바꾸지 않고 off-peak capacity를 활용해 비용을 낮추는 선택지이고, Batch API는 24시간 내 처리를 목표로 대량 비동기 작업을 처리하는 선택지다. 중요한 것은 둘을 섞어 쓰는 기준이다.
검색 의도: Gemini API Flex Inference, Gemini Batch API, AI API 비용 최적화, LLM 비용 절감
개발팀이 처음 AI 기능을 붙일 때는 보통 한두 개 요청만 본다. “요약 요청 1회에 몇 원” 수준으로 계산한다. 하지만 서비스에 들어가면 비용 구조가 달라진다. 사용자는 재시도하고, 긴 문서를 넣고, 같은 내용을 여러 번 묻고, 백그라운드 작업이 쌓인다. 운영자는 품질을 올리려고 더 큰 모델을 쓰고, 로그와 평가를 위해 추가 호출을 만든다.
이때 비용 최적화는 모델을 무조건 작은 것으로 바꾸는 문제가 아니다. 응답 시간이 중요한 요청과 그렇지 않은 요청을 나누는 문제다. 사용자가 화면 앞에서 기다리는 요청은 빠르게 처리해야 한다. 반면 문서 일괄 분류, 데이터 정제, 리포트 생성, 임베딩 교체 같은 작업은 몇 분에서 몇 시간 늦어도 괜찮다.
Google Gemini API 문서에 따르면 Flex Inference는 opportunistic, off-peak compute capacity를 활용해 표준 요금 대비 50% 할인을 제공하는 방식으로 설명된다. Batch API 역시 대량 요청을 비동기 처리하며 표준 비용 대비 50% 수준의 비용 절감과 24시간 내 처리를 목표로 한다고 안내된다. 숫자만 보면 둘 다 “절반 가격”이지만, 운영 방식은 다르다.
Flex Inference는 동기 요청이다. 기존 generate 요청 흐름을 크게 바꾸지 않고, 지연 시간이 조금 늘거나 처리 가능성이 capacity에 영향을 받을 수 있음을 감수하는 방식으로 이해하면 된다. 사용자는 결과를 기다리고 있고, 애플리케이션은 응답을 받아 다음 화면을 만든다.
Batch API는 비동기 요청이다. 입력을 모아 job으로 제출하고, 나중에 결과를 가져온다. 사용자가 화면 앞에서 즉시 기다릴 필요가 없는 작업에 맞다. 대량 데이터 처리, nightly job, 콘텐츠 검사, 고객 문의 분류, 로그 요약 같은 곳에 적합하다.
기준은 간단하다.
첫 번째 후보는 관리자용 자동 분석이다. 예를 들어 매일 새로 쌓인 CS 문의 5,000건을 주제별로 분류하고, 상위 불만 원인을 뽑는 작업은 사용자가 기다릴 필요가 없다. Batch API로 넘기고 다음 날 리포트에서 보면 된다.
두 번째 후보는 콘텐츠 후처리다. 블로그 글 초안 품질 검사, 금칙어 검사, SEO 메타 설명 생성, 제목 후보 10개 생성 같은 작업은 실시간보다 비용이 중요할 수 있다. 작성자가 버튼을 누르고 기다리는 기능은 Flex Inference로, 밤에 전체 콘텐츠를 재검사하는 기능은 Batch API로 나눌 수 있다.
세 번째 후보는 데이터셋 라벨링이다. 모델 평가용 데이터셋을 만들거나 기존 로그를 의도별로 태깅하는 작업은 전형적인 비동기 대량 작업이다. 이 작업을 실시간 API로 돌리면 rate limit과 비용이 동시에 문제가 된다.
네 번째 후보는 캐시 워밍이다. 자주 묻는 질문, 상품 설명, 문서 요약을 미리 만들어두는 작업은 사용자 요청 전에 처리할 수 있다. Batch API로 만들어두면 실제 사용자 요청에서는 캐시를 읽기만 하면 된다.
Flex Inference는 “코드 변경이 적다”는 장점이 있지만, 운영 기준 없이 켜면 사용자 경험이 흔들릴 수 있다. 먼저 latency budget을 정해야 한다. 예를 들어 검색 보조 응답은 3초를 넘기면 이탈이 커질 수 있지만, 보고서 초안 생성은 20초까지도 허용될 수 있다.
두 번째는 fallback이다. Flex capacity가 부족하거나 지연이 길어질 때 표준 요청으로 재시도할지, 작은 모델로 낮출지, 사용자에게 “잠시 후 다시 시도”를 보여줄지 정해야 한다. 비용 절감 기능은 실패 전략이 있어야 안전하다.
세 번째는 요청 우선순위다. 결제 직후 온보딩, 사용자가 직접 누른 버튼, 백그라운드 추천 생성의 중요도는 다르다. 모든 요청에 Flex를 적용하지 말고, 사용자 체감이 낮은 동기 작업부터 적용하는 편이 좋다.
네 번째는 측정이다. 평균 응답 시간만 보면 안 된다. p95, p99 latency, timeout rate, fallback rate, 사용자 재시도율을 함께 봐야 한다. 비용은 줄었는데 재시도율이 늘면 실제 비용 절감은 줄어든다.
가장 단순한 구조는 네 단계다.
여기서 중요한 것은 idempotency다. 같은 입력을 두 번 처리해도 결과가 중복 저장되지 않아야 한다. 각 요청에 request_id를 붙이고, 결과 저장 시 upsert를 사용하면 운영이 쉬워진다.
또 하나는 부분 실패 처리다. Batch job 전체가 성공해도 일부 항목은 실패할 수 있다. 실패 이유를 분류해야 한다. 입력이 너무 길었는지, JSON 형식이 깨졌는지, 안전 정책에 걸렸는지, 모델 출력 파싱이 실패했는지에 따라 재시도 방식이 달라진다.
정확한 비용은 모델 가격과 입력 길이에 따라 달라진다. 하지만 초기 산정은 간단한 표로 충분하다.
이렇게 작업별로 표를 만들면 어떤 요청을 어디로 보내야 할지 보인다. 실시간 요청은 latency와 전환율을 기준으로 판단하고, 비동기 요청은 월간 처리량과 재처리 비용을 기준으로 판단한다.
절감 효과를 과대평가하지 않는 것도 중요하다. Batch로 50%를 아껴도, 프롬프트가 불필요하게 길면 여전히 비싸다. 먼저 입력을 줄이고, 중복 문서를 캐싱하고, 결과를 재사용한 다음 Flex나 Batch를 적용해야 한다.
Gemini API Flex Inference와 Batch API는 비용 절감 버튼이 아니다. 실시간성과 비동기성을 나눠서 운영하는 도구다. 요청을 이 기준으로 분류하면 모델 비용은 내려가고, 사용자는 더 안정적인 응답을 받는다.
