Gemini API Flex·Priority·Batch 업데이트가 말하는 LLM 비용 운영법: 캐시와 지연 시간을 같이 봐야 한다

Google Gemini API 문서와 변경 로그를 보면 최근 개발자용 운영 기능의 방향이 분명합니다. Batch API는 대량 비동기 요청에 맞춰 설계되어 있고, 문서에는 batch request에서도 context caching을 사용할 수 있다고 명시되어 있습니다. Gemini 2.5 이상에서는 implicit caching이 기본 활성화되어 비용 절감이 자동 적용될 수 있다는 설명도 있습니다. 변경 로그에는 Flex와 Priority inference 같은 추론 계층이 등장합니다.

이 변화는 “새 모델이 나왔다”보다 실무적으로 더 중요합니다. LLM 서비스 비용은 단순히 input/output 토큰 단가로 결정되지 않습니다. 같은 모델을 써도 캐시 적중률, 배치 처리 비율, 피크 시간 지연, 재시도율에 따라 월 비용이 크게 갈립니다. 이제 AI 기능을 운영하는 팀은 모델 선택표만 볼 게 아니라 요청 형태를 설계해야 합니다.

참고 자료: Gemini Batch API(https://ai.google.dev/gemini-api/docs/batch-api), Context caching 문서(https://ai.google.dev/gemini-api/docs/caching), Gemini API 변경 로그(https://ai.google.dev/gemini-api/docs/changelog).

Flex와 Priority가 중요한 이유: 모델보다 SLA를 고르는 문제

LLM API를 운영하다 보면 모든 요청이 같은 중요도를 갖지 않습니다. 사용자가 버튼을 누르고 기다리는 채팅 응답은 지연 시간이 짧아야 합니다. 반면 밤에 5만 개 문서를 요약하는 작업은 몇 분 늦어도 됩니다. Flex와 Priority 같은 추론 계층이 의미 있는 이유는 이 두 요청을 같은 가격·같은 경로로 처리할 필요가 없기 때문입니다.

많은 팀이 초기에 모든 요청을 실시간 API로 보냅니다. 구현은 쉽지만 비용 구조가 나쁩니다. 배치로 밀 수 있는 요청까지 실시간으로 처리하면 피크 시간에 재시도가 늘고, 큐가 밀리고, 사용자가 보는 기능까지 영향을 받습니다. 운영 설계의 핵심은 “빠른 모델”을 고르는 것이 아니라 “빠르지 않아도 되는 요청”을 분리하는 것입니다.

예를 들어 고객 상담 로그 분석, 상품 설명 재작성, 내부 문서 임베딩 전처리, 코드베이스 대량 요약은 배치나 낮은 우선순위 경로가 적합합니다. 반대로 IDE 자동완성, 실시간 고객 응대, 결제 오류 안내처럼 사용자가 대기 중인 요청은 Priority 성격으로 봐야 합니다.

Batch API와 context caching을 같이 쓰는 구조

Batch API는 대량 요청을 비동기로 처리할 때 유리합니다. 하지만 배치만으로 비용이 충분히 줄어드는 것은 아닙니다. 같은 긴 컨텍스트를 반복해서 넣는다면 context caching을 같이 설계해야 합니다. Gemini 문서가 batch request에서 cached_content를 사용할 수 있다고 설명하는 지점이 중요합니다.

예를 들어 사내 규정 200페이지를 기준으로 1,000개 질문에 답변을 생성한다고 합시다. 매 요청마다 규정 전문을 다시 넣으면 입력 토큰 비용이 반복됩니다. 반대로 규정 전문을 캐시하고, 각 요청에는 짧은 질문과 필요한 메타데이터만 넣으면 비용과 지연 시간이 줄어듭니다.

실무 설계는 이렇게 나눌 수 있습니다. 첫째, 자주 반복되는 긴 컨텍스트를 식별합니다. 둘째, 캐시 TTL과 갱신 조건을 정합니다. 셋째, 배치 요청마다 cached_content 참조를 붙입니다. 넷째, 캐시 적중률과 실패율을 로그로 남깁니다. 캐시를 쓰면 비용이 줄 수 있지만, 오래된 컨텍스트를 계속 재사용하는 품질 리스크도 생깁니다.

implicit caching을 믿되, 비용 계측은 직접 해야 한다

Gemini 2.5 이상에서 implicit caching이 기본 활성화되어 있다는 설명은 반가운 기능입니다. 하지만 운영팀이 “자동으로 싸지겠지”라고 끝내면 안 됩니다. 자동 캐시는 요청 패턴이 안정적일 때 효과가 큽니다. 매번 시스템 프롬프트가 조금씩 바뀌거나, 컨텍스트 순서가 달라지거나, 불필요한 타임스탬프가 앞부분에 섞이면 캐시 효율이 떨어질 수 있습니다.

캐시 친화적인 프롬프트는 구조가 고정되어 있습니다. 공통 지침은 앞에 두고 자주 바뀌는 사용자 입력은 뒤로 보냅니다. 날짜, request_id, 실험 플래그처럼 매번 변하는 값은 캐시 대상 컨텍스트와 분리합니다. 문서 묶음도 정렬 기준을 고정합니다. 작은 차이가 캐시 키를 깨는 경우가 많습니다.

비용 계측은 최소 세 가지를 봐야 합니다. 총 입력 토큰, 캐시된 입력 토큰 또는 캐시 적중 추정치, 요청당 지연 시간입니다. 여기에 재시도 횟수와 실패 코드를 붙이면 “비싼 요청”과 “느린 요청”을 분리해서 고칠 수 있습니다.

개발자가 바로 적용할 수 있는 요청 분류표

AI 기능을 운영한다면 먼저 요청을 네 그룹으로 나누는 것이 좋습니다. A그룹은 실시간·고가치 요청입니다. 사용자가 대기 중이고 실패하면 바로 이탈하는 기능입니다. B그룹은 실시간이지만 저가치 요청입니다. 자동 태그 추천처럼 실패해도 핵심 플로우가 멈추지 않는 기능입니다. C그룹은 비동기·대량 요청입니다. 배치 처리 후보입니다. D그룹은 내부 품질 개선 요청입니다. 평가, 로그 분석, 데이터 정제처럼 낮은 우선순위로 돌릴 수 있습니다.

이 분류표를 만들면 모델 선택도 쉬워집니다. A그룹은 안정성과 지연 시간이 우선입니다. B그룹은 비용 상한이 중요합니다. C그룹은 Batch API와 캐시가 핵심입니다. D그룹은 스케줄링과 실패 재처리만 잘하면 됩니다.

문제는 제품팀이 모든 요청을 A그룹처럼 취급할 때 생깁니다. “사용자 경험”이라는 말로 모든 AI 요청을 실시간 처리하면 비용은 빠르게 늘고, 정작 중요한 요청의 성능도 흔들립니다. SLA를 기능별로 나누는 것이 AI 비용 최적화의 출발점입니다.

장애 대응 관점에서 봐야 할 지표

LLM 비용 최적화는 장애 대응과 분리할 수 없습니다. 배치 큐가 밀리면 다음 날 리포트가 늦어지고, 캐시가 깨지면 비용이 튀고, Priority 요청이 실패하면 사용자 경험이 무너집니다. 그래서 대시보드에는 비용뿐 아니라 처리량과 지연 시간을 같이 올려야 합니다.

추천 지표는 요청 수, 성공률, p50/p95 지연 시간, 입력 토큰, 출력 토큰, 캐시 적중률, 배치 큐 대기 시간, 재시도율입니다. 여기에 기능명과 고객 플랜을 태그로 붙이면 “어떤 고객군에서 어떤 기능이 비용을 쓰는지”가 보입니다.

특히 월말 비용만 보는 방식은 늦습니다. 캐시 설정 하나가 깨져도 하루 안에 큰 비용 차이가 날 수 있습니다. 비용 알림은 월간 예산이 아니라 일별 예상치와 기능별 급증률 기준으로 걸어야 합니다.

실행 체크리스트

• 모든 LLM 요청을 실시간/비동기, 고가치/저가치로 4분류한다.
• 긴 공통 컨텍스트는 cache 후보로 분리하고 TTL·갱신 조건을 문서화한다.
• Batch API 후보 작업은 사용자 대기 플로우에서 제거한다.
• 시스템 프롬프트 앞부분을 안정적으로 유지해 implicit caching 효율을 높인다.
• 요청 로그에 기능명, 모델, 토큰, 지연 시간, 캐시 여부, 재시도 횟수를 남긴다.
• 월 비용이 아니라 일별 비용 급증률로 알림을 건다.