Gemini API 비용 최적화: 캐싱·모델 선택·배치 작업을 나누는 실무 기준

Gemini API를 서비스에 붙일 때 가장 흔한 실수는 “어떤 모델이 제일 좋은가”부터 고르는 것입니다. 운영 비용을 보면 질문을 바꿔야 합니다. “이 요청은 즉시 응답이 필요한가, 반복되는 컨텍스트가 있는가, 긴 출력이 필요한가, 실패했을 때 재시도해도 되는가”가 먼저입니다. 모델 선택은 그 다음입니다.

Google의 Gemini API pricing 문서는 무료 시작, 생산 환경의 유료 사용, 모델별 입력·출력 비용, 캐싱, 배치성 작업을 구분합니다. 세부 숫자는 변할 수 있으므로 배포 전 공식 가격표를 다시 확인해야 하지만, 비용 구조를 이해하는 방식은 거의 변하지 않습니다. 입력 토큰, 출력 토큰, 캐시된 입력, 대기 가능한 작업을 분리해서 설계하면 같은 기능도 훨씬 안정적으로 운영할 수 있습니다.

먼저 요청을 네 종류로 나눈다

Gemini API 비용 최적화는 코드보다 분류에서 시작합니다. 모든 AI 호출을 하나의 endpoint로 보내면 관측도 어렵고 최적화도 어렵습니다. 최소한 다음 네 종류로 나누세요.

1. 실시간 짧은 응답: 채팅 답변, 짧은 분류, 자동완성
2. 실시간 긴 응답: 보고서 초안, 긴 요약, 다단계 추론
3. 반복 컨텍스트 요청: 같은 정책 문서, 매뉴얼, 코드베이스 설명을 계속 넣는 요청
4. 지연 가능 작업: 야간 리포트, 대량 분류, 백오피스 정리, 색인 보강

첫 번째는 빠른 모델과 짧은 max output이 핵심입니다. 두 번째는 출력 토큰 관리가 중요합니다. 세 번째는 캐싱 후보입니다. 네 번째는 batch 또는 flex 성격의 처리로 옮길 수 있습니다.

이 분류 없이 “Gemini 2.5 Flash가 싸다더라” 같은 식으로 접근하면 비용이 줄지 않습니다. 싼 모델로 긴 출력을 무제한 생성하면 여전히 비쌉니다.

캐싱은 긴 system prompt보다 반복 문서에 먼저 적용한다

캐싱을 도입할 때 가장 먼저 떠올리는 대상은 system prompt입니다. 하지만 실제 비용 절감 효과가 큰 곳은 반복적으로 들어가는 긴 문서입니다. 예를 들어 고객센터 챗봇이 매번 환불 정책, 배송 정책, 계정 정책 전문을 넣는다면 입력 토큰 대부분이 “매번 같은 텍스트”입니다. 이 부분이 캐싱 후보입니다.

캐싱 적용 기준은 다음과 같습니다.

• 같은 컨텍스트가 여러 요청에서 반복된다.
• 컨텍스트 길이가 충분히 길다.
• 문서 변경 빈도가 낮다.
• 캐시 만료와 갱신 전략을 정의할 수 있다.
• 캐시가 틀렸을 때 사용자에게 잘못된 답을 줄 위험을 관리할 수 있다.

반대로 사용자별로 계속 바뀌는 짧은 정보, 검색 결과처럼 freshness가 중요한 데이터, 권한별로 내용이 달라지는 데이터는 무리하게 캐싱하지 않는 편이 낫습니다. 캐싱은 비용 최적화 도구이지만, 잘못 쓰면 오래된 정책을 근거로 답하는 장애가 됩니다.

출력 토큰이 비용과 지연 시간을 동시에 만든다

LLM 비용에서 입력만 보는 팀이 많습니다. 하지만 실제 서비스에서는 출력 토큰이 비용과 지연 시간을 동시에 키웁니다. “자세히 답해줘”를 기본값으로 두면 모든 요청이 긴 답변을 만들고, 사용자도 읽지 않는 문단에 돈을 씁니다.

실무에서는 기능별 출력 예산을 정해야 합니다.

프롬프트에도 길이 제한을 명시해야 하지만, API 파라미터의 max output token도 함께 설정해야 합니다. 프롬프트 지시만 믿으면 모델이 상황에 따라 길게 답할 수 있습니다.

모델 라우팅은 성공률과 비용을 같이 봐야 한다

저렴한 모델을 먼저 호출하고 실패하면 비싼 모델로 승격하는 routing은 유효합니다. 다만 실패 판정 기준이 없으면 오히려 비용이 늘어납니다. 낮은 모델이 애매한 답을 만들고, 사람이 다시 시키고, 결국 높은 모델까지 호출하면 두 번 돈을 씁니다.

라우팅 기준은 기계적으로 만들어야 합니다.

• JSON schema 검증 실패
• confidence가 기준 이하
• 필수 필드 누락
• 금지된 문장 포함
• 테스트 실패
• 검색 근거 부족

예를 들어 문서 분류 작업은 빠른 모델로 시작하고, schema validation이 실패한 건만 상위 모델로 보냅니다. 반대로 법무 검토, 보안 정책, 결제 오류 원인 분석처럼 실패 비용이 큰 작업은 처음부터 상위 모델을 쓰는 편이 낫습니다.

지연 가능한 작업은 사용자 요청 경로에서 빼라

비용 최적화에서 가장 효과가 큰 결정 중 하나는 “지금 답해야 하는가”입니다. 많은 AI 작업은 사용자가 기다리는 HTTP 요청 안에서 처리할 필요가 없습니다. 예를 들어 다음 작업은 queue로 넘겨도 됩니다.

• 하루치 리뷰 감성 분석
• 고객 문의 태그 재분류
• 문서 색인 보강
• 영업 리드 요약
• 주간 리포트 생성
• 실패한 답변 재평가

이런 작업은 batch 성격으로 묶을 수 있고, 재시도도 쉽습니다. 실시간 endpoint에서 처리하면 timeout, 중복 호출, 사용자의 새로고침, 서버리스 cold start가 비용을 키웁니다.

구조는 단순합니다. API 서버는 작업 요청을 큐에 넣고 job id를 반환합니다. worker가 Gemini API를 호출하고 결과를 저장합니다. 사용자는 polling이나 webhook으로 결과를 받습니다. 중요한 것은 AI 호출을 사용자 요청 생명주기와 분리하는 것입니다.

관측 지표 없이는 최적화가 불가능하다

Gemini API 비용을 줄이려면 요청별 로그가 필요합니다. 단순히 월말 청구서를 보고 “많이 나왔다”는 건 늦습니다. 최소한 다음 필드를 남기세요.

• feature name
• model name
• input token
• cached input token
• output token
• latency
• retry count
• cache hit 여부
• validation success 여부
• user visible 여부
• estimated cost

이 중 user visible 여부가 중요합니다. 사용자에게 실제로 보여주지 않은 응답, 실패해서 버린 응답, 재시도 중간 결과가 비용의 상당 부분을 차지할 수 있습니다. 이런 호출을 줄이는 게 모델 가격 비교보다 먼저입니다.

프롬프트도 비용 최적화 대상이다

프롬프트가 길수록 안정적이라고 생각하기 쉽지만, 반복되는 설명과 예시가 많으면 비용과 latency가 늘어납니다. 좋은 운영 프롬프트는 길이가 아니라 구조가 명확합니다.

권장 구조는 다음입니다.

역할: 무엇을 판단하는지
입력: 어떤 데이터가 들어오는지
출력: JSON schema 또는 bullet 형식
규칙: 금지 사항과 우선순위
예외: 판단 불가 시 어떻게 답할지

few-shot 예시는 2~3개면 충분한 경우가 많습니다. 10개 이상의 예시가 필요하다면 프롬프트가 아니라 fine-tuning, retrieval, rule engine, 후처리 검증 중 하나를 검토해야 합니다.

오늘 적용할 체크리스트

• 모든 Gemini API 호출을 실시간 짧은 응답, 실시간 긴 응답, 반복 컨텍스트, 지연 가능 작업으로 분류한다.
• 반복 문서가 들어가는 요청부터 캐싱 후보로 검토한다.
• 기능별 max output token과 응답 형식을 정한다.
• 저렴한 모델에서 상위 모델로 승격하는 validation 기준을 만든다.
• 야간 처리 가능한 작업은 queue와 worker로 분리한다.
• 요청별 input, cached input, output, latency, retry, estimated cost를 로그로 남긴다.
• 월말 비용이 아니라 기능별 단가와 실패 호출 비율을 본다.

Gemini API 비용 최적화의 핵심은 “가장 싼 모델 찾기”가 아닙니다. 요청을 분류하고, 반복 컨텍스트를 캐싱하고, 출력 길이를 제한하고, 지연 가능한 작업을 사용자 경로 밖으로 빼는 것입니다.