Gemini API Flex Inference 운영법: 동기 요청 비용을 낮추는 기준과 Batch API 분리 전략

요약: 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 API 비용은 예상보다 빨리 커지는가

개발팀이 처음 AI 기능을 붙일 때는 보통 한두 개 요청만 본다. “요약 요청 1회에 몇 원” 수준으로 계산한다. 하지만 서비스에 들어가면 비용 구조가 달라진다. 사용자는 재시도하고, 긴 문서를 넣고, 같은 내용을 여러 번 묻고, 백그라운드 작업이 쌓인다. 운영자는 품질을 올리려고 더 큰 모델을 쓰고, 로그와 평가를 위해 추가 호출을 만든다.

이때 비용 최적화는 모델을 무조건 작은 것으로 바꾸는 문제가 아니다. 응답 시간이 중요한 요청과 그렇지 않은 요청을 나누는 문제다. 사용자가 화면 앞에서 기다리는 요청은 빠르게 처리해야 한다. 반면 문서 일괄 분류, 데이터 정제, 리포트 생성, 임베딩 교체 같은 작업은 몇 분에서 몇 시간 늦어도 괜찮다.

Google Gemini API 문서에 따르면 Flex Inference는 opportunistic, off-peak compute capacity를 활용해 표준 요금 대비 50% 할인을 제공하는 방식으로 설명된다. Batch API 역시 대량 요청을 비동기 처리하며 표준 비용 대비 50% 수준의 비용 절감과 24시간 내 처리를 목표로 한다고 안내된다. 숫자만 보면 둘 다 “절반 가격”이지만, 운영 방식은 다르다.

Flex Inference와 Batch API의 차이

Flex Inference는 동기 요청이다. 기존 generate 요청 흐름을 크게 바꾸지 않고, 지연 시간이 조금 늘거나 처리 가능성이 capacity에 영향을 받을 수 있음을 감수하는 방식으로 이해하면 된다. 사용자는 결과를 기다리고 있고, 애플리케이션은 응답을 받아 다음 화면을 만든다.

Batch API는 비동기 요청이다. 입력을 모아 job으로 제출하고, 나중에 결과를 가져온다. 사용자가 화면 앞에서 즉시 기다릴 필요가 없는 작업에 맞다. 대량 데이터 처리, nightly job, 콘텐츠 검사, 고객 문의 분류, 로그 요약 같은 곳에 적합하다.

기준은 간단하다.

• 5~15초 안에 사용자에게 보여줘야 한다면 일반 요청 또는 Flex Inference를 검토한다.
• 몇 분 이상 늦어도 된다면 Batch API를 검토한다.
• 실패 시 사용자가 즉시 재시도할 수 있어야 한다면 동기 요청이 낫다.
• 실패 시 운영자가 재처리해도 된다면 Batch API가 낫다.
• 요청마다 컨텍스트가 크게 다르고 상호작용이 있다면 동기 요청이 낫다.
• 동일한 작업을 수천 건 반복한다면 Batch API가 낫다.

실무에서 먼저 분리할 작업 유형

첫 번째 후보는 관리자용 자동 분석이다. 예를 들어 매일 새로 쌓인 CS 문의 5,000건을 주제별로 분류하고, 상위 불만 원인을 뽑는 작업은 사용자가 기다릴 필요가 없다. Batch API로 넘기고 다음 날 리포트에서 보면 된다.

두 번째 후보는 콘텐츠 후처리다. 블로그 글 초안 품질 검사, 금칙어 검사, SEO 메타 설명 생성, 제목 후보 10개 생성 같은 작업은 실시간보다 비용이 중요할 수 있다. 작성자가 버튼을 누르고 기다리는 기능은 Flex Inference로, 밤에 전체 콘텐츠를 재검사하는 기능은 Batch API로 나눌 수 있다.

세 번째 후보는 데이터셋 라벨링이다. 모델 평가용 데이터셋을 만들거나 기존 로그를 의도별로 태깅하는 작업은 전형적인 비동기 대량 작업이다. 이 작업을 실시간 API로 돌리면 rate limit과 비용이 동시에 문제가 된다.

네 번째 후보는 캐시 워밍이다. 자주 묻는 질문, 상품 설명, 문서 요약을 미리 만들어두는 작업은 사용자 요청 전에 처리할 수 있다. Batch API로 만들어두면 실제 사용자 요청에서는 캐시를 읽기만 하면 된다.

Flex Inference를 쓸 때의 설계 포인트

Flex Inference는 “코드 변경이 적다”는 장점이 있지만, 운영 기준 없이 켜면 사용자 경험이 흔들릴 수 있다. 먼저 latency budget을 정해야 한다. 예를 들어 검색 보조 응답은 3초를 넘기면 이탈이 커질 수 있지만, 보고서 초안 생성은 20초까지도 허용될 수 있다.

두 번째는 fallback이다. Flex capacity가 부족하거나 지연이 길어질 때 표준 요청으로 재시도할지, 작은 모델로 낮출지, 사용자에게 “잠시 후 다시 시도”를 보여줄지 정해야 한다. 비용 절감 기능은 실패 전략이 있어야 안전하다.

세 번째는 요청 우선순위다. 결제 직후 온보딩, 사용자가 직접 누른 버튼, 백그라운드 추천 생성의 중요도는 다르다. 모든 요청에 Flex를 적용하지 말고, 사용자 체감이 낮은 동기 작업부터 적용하는 편이 좋다.

네 번째는 측정이다. 평균 응답 시간만 보면 안 된다. p95, p99 latency, timeout rate, fallback rate, 사용자 재시도율을 함께 봐야 한다. 비용은 줄었는데 재시도율이 늘면 실제 비용 절감은 줄어든다.

Batch API 파이프라인 예시

가장 단순한 구조는 네 단계다.

1. 입력 수집: 처리할 문서나 로그를 JSONL 형태로 만든다.
2. 작업 제출: Batch API에 job을 제출하고 job id를 저장한다.
3. 상태 확인: 일정 주기로 완료 여부를 확인한다.
4. 결과 반영: 결과를 DB에 저장하고 실패 건만 재시도 큐에 넣는다.

여기서 중요한 것은 idempotency다. 같은 입력을 두 번 처리해도 결과가 중복 저장되지 않아야 한다. 각 요청에 request_id를 붙이고, 결과 저장 시 upsert를 사용하면 운영이 쉬워진다.

또 하나는 부분 실패 처리다. Batch job 전체가 성공해도 일부 항목은 실패할 수 있다. 실패 이유를 분류해야 한다. 입력이 너무 길었는지, JSON 형식이 깨졌는지, 안전 정책에 걸렸는지, 모델 출력 파싱이 실패했는지에 따라 재시도 방식이 달라진다.

비용 계산은 이렇게 시작하면 된다

정확한 비용은 모델 가격과 입력 길이에 따라 달라진다. 하지만 초기 산정은 간단한 표로 충분하다.

• 작업명: 고객 문의 주제 분류
• 월 처리량: 300,000건
• 건당 평균 입력: 1,200 tokens
• 건당 평균 출력: 80 tokens
• 실시간 필요 여부: 아니오
• 허용 지연: 12시간
• 추천 처리: Batch API

이렇게 작업별로 표를 만들면 어떤 요청을 어디로 보내야 할지 보인다. 실시간 요청은 latency와 전환율을 기준으로 판단하고, 비동기 요청은 월간 처리량과 재처리 비용을 기준으로 판단한다.

절감 효과를 과대평가하지 않는 것도 중요하다. Batch로 50%를 아껴도, 프롬프트가 불필요하게 길면 여전히 비싸다. 먼저 입력을 줄이고, 중복 문서를 캐싱하고, 결과를 재사용한 다음 Flex나 Batch를 적용해야 한다.

운영 체크리스트

• 사용자 화면 앞에서 기다리는 요청과 백그라운드 요청을 분리했는가?
• 각 요청 유형별 latency budget을 정했는가?
• Flex Inference 적용 대상의 p95, timeout, fallback rate를 측정하는가?
• Flex 실패 시 표준 요청, 작은 모델, 사용자 안내 중 어떤 fallback을 쓸지 정했는가?
• Batch API 입력에 request_id를 붙여 중복 저장을 막는가?
• Batch 결과의 부분 실패를 분류하고 재시도 큐로 보내는가?
• 대량 작업 전에 샘플 100건으로 출력 형식과 파싱 안정성을 검증했는가?
• 비용 절감 전에 프롬프트 길이, 캐시, 중복 호출부터 줄였는가?

Gemini API Flex Inference와 Batch API는 비용 절감 버튼이 아니다. 실시간성과 비동기성을 나눠서 운영하는 도구다. 요청을 이 기준으로 분류하면 모델 비용은 내려가고, 사용자는 더 안정적인 응답을 받는다.