Gemini Flex inference 공개: 50% 비용 절감이 가능한 워크로드와 위험 구간

Google이 Gemini API에 Flex inference tier를 공개했습니다. 공식 문서 기준 Flex는 standard rate 대비 50% 비용 절감을 제공하지만, 대신 지연 시간이 가변적이고 best-effort availability로 동작합니다. 한 줄로 정리하면 “빠르지 않아도 되는 동기식 작업을 싸게 처리하는 옵션”입니다.

개발자 입장에서 중요한 변화는 Batch API와 Standard API 사이에 새로운 선택지가 생겼다는 점입니다. Batch API는 최대 24시간 처리 지연을 받아들이는 비동기 대량 처리에 맞고, Standard API는 일반적인 실시간 요청에 맞습니다. Flex는 그 중간입니다. 다음 요청이 이전 출력에 의존해서 완전한 비동기로 보내기 어렵지만, 1~15분 정도의 지연은 받아들일 수 있는 작업에 맞습니다.

Flex inference가 해결하는 실제 문제

LLM 비용은 대부분 “고정 기능”보다 “반복 실행”에서 터집니다. 예를 들어 매일 수천 개의 고객 프로필을 요약하거나, 문서 QA 회귀 테스트를 돌리거나, 운영 로그를 분류하는 작업은 사용자 화면 뒤에서 조용히 실행됩니다. 이 작업은 3초 안에 끝날 필요가 없습니다. 하지만 기존에는 Standard API를 써서 비용을 내거나, Batch API로 구조를 완전히 바꿔야 했습니다.

Flex는 이 회색지대를 겨냥합니다. 요청 방식은 거의 그대로 두고 service_tier: flex만 추가합니다. Python, JavaScript, REST 예시 모두 같은 패턴입니다. 기존 Gemini 호출 코드를 크게 갈아엎지 않아도 실험할 수 있다는 점이 도입 장벽을 낮춥니다.

가격보다 먼저 봐야 할 것은 실패 모델

Flex의 핵심은 할인율이 아니라 실패 모델입니다. Google 문서는 Flex traffic이 lower priority로 처리되고, standard traffic이 급증하면 preempted 또는 evicted될 수 있다고 설명합니다. capacity가 부족하면 503 Service Unavailable이 나올 수 있고, rate limit이나 resource exhaustion 상황에서는 429 Too Many Requests가 나올 수 있습니다.

즉 Flex를 붙이는 순간 애플리케이션은 “가끔 밀리고, 가끔 실패하는 요청”을 정상 경로로 다뤄야 합니다. 이걸 예외 상황으로만 보면 운영에서 문제가 생깁니다. 특히 cron, background worker, agent workflow는 실패 재시도 정책이 없으면 하루 처리량이 조용히 밀립니다.

Flex에 맞는 작업과 맞지 않는 작업

적합한 작업은 명확합니다. 첫째, LLM-as-a-judge 회귀 테스트입니다. 프롬프트 변경 후 500개 샘플을 평가하는 작업은 10분 늦어져도 괜찮습니다. 둘째, 백오피스 데이터 보강입니다. CRM 메모 요약, 태그 추천, 리드 스코어링 보조처럼 사람이 즉시 기다리지 않는 작업이 여기에 들어갑니다. 셋째, 콘텐츠 초안 생성이나 내부 검색 인덱스 보강도 후보입니다.

반대로 사용자 입력에 즉시 답해야 하는 챗봇, 결제 전환 화면, 실시간 코드 자동완성, 장애 대응 봇에는 맞지 않습니다. Flex는 싸지만 latency SLO를 보장하지 않습니다. “사용자가 보고 있는 화면”에 붙이면 비용은 줄어도 체감 품질이 깨질 수 있습니다.

구현할 때 필요한 운영 기준

가장 먼저 timeout을 늘려야 합니다. Google 문서는 Flex 요청이 queue에 머무를 수 있으므로 client-side timeout을 10분 이상으로 잡는 것을 권장합니다. 기본 HTTP timeout이 30초인 환경에서는 Flex를 붙여도 계속 premature timeout이 발생합니다.

다음은 retry입니다. 서버가 Flex 요청을 Standard tier로 자동 승격하지 않는다고 명시되어 있습니다. 예상치 못한 과금을 막기 위한 설계입니다. 따라서 fallback을 직접 결정해야 합니다. 예를 들어 503이 3회 반복되면 다음 실행 주기로 넘기거나, 업무 우선순위가 높은 경우에만 Standard로 재시도하는 방식입니다.

마지막은 큐 분리입니다. Flex 작업은 별도 queue로 빼는 편이 안전합니다. Standard 요청과 같은 worker pool을 쓰면 Flex 요청이 오래 대기하면서 실시간 작업까지 막을 수 있습니다.

도입 전 체크리스트

• 이 작업은 사용자 화면에서 즉시 기다리는가? 그렇다면 Flex 제외
• 1~15분 지연을 제품 요구사항으로 받아들일 수 있는가?
• 503, 429를 정상적인 재시도 대상으로 처리하는가?
• client timeout을 600초 이상으로 조정했는가?
• Flex 실패 시 Standard fallback 기준을 명확히 정했는가?
• Flex queue와 실시간 queue를 분리했는가?
• 비용 절감액과 지연 증가를 로그로 비교하고 있는가?

팀 내부 도입 순서

처음부터 모든 비실시간 작업을 Flex로 옮기면 원인 분석이 어려워집니다. 가장 좋은 시작점은 비용은 크지만 실패 영향은 낮은 작업입니다. 예를 들어 매일 밤 도는 프롬프트 회귀 테스트, 내부 문서 분류, 검색 색인용 요약처럼 결과가 늦어져도 사용자 경험이 깨지지 않는 작업을 고릅니다.

1주일 동안은 Standard와 Flex를 나란히 기록하는 편이 좋습니다. 같은 입력 유형에서 latency, 실패율, 재시도 횟수, 최종 비용을 비교합니다. 할인율만 보면 Flex가 항상 좋아 보일 수 있지만, 재시도와 fallback 비용을 포함하면 실제 절감률이 달라집니다. 운영팀이 봐야 하는 숫자는 “요청당 단가”가 아니라 “성공한 작업 1건당 총비용”입니다.

또한 product requirement에 Flex 허용 여부를 명시해야 합니다. “이 기능은 최대 10분 지연 가능”, “이 기능은 10초 안에 응답 필요”처럼 적어두면 모델 tier 선택이 개인 취향이 아니라 제품 기준이 됩니다.

Flex inference의 가치는 “무조건 싸게 호출”이 아닙니다. 동기식 흐름을 유지하면서도, 지연을 감수할 수 있는 작업의 단가를 낮추는 데 있습니다. 먼저 eval, 데이터 보강, 백그라운드 agent처럼 실패 모델을 제어하기 쉬운 작업부터 붙이는 것이 안전합니다.