Gemini Flex inference: 50% 할인 추론 티어가 바꾸는 AI 비용 구조

Google이 Gemini API에 Flex inference를 공개하면서 AI 추론 비용을 설계하는 방식이 조금 더 세분화됐습니다. Flex는 표준 요금 대비 50% 비용 절감을 제공하는 대신, 지연 시간이 가변적이고 best-effort 가용성을 전제로 하는 추론 티어입니다. 사용자 대화처럼 즉시 응답해야 하는 작업에는 맞지 않지만, 동기식 흐름을 유지하면서도 몇 분 정도의 지연을 받아들일 수 있는 작업에는 실질적인 선택지가 됩니다.

Flex inference의 핵심 요약

공식 문서 기준 Flex inference는 Preview 상태의 서비스 티어입니다. 요청에 service_tier: flex를 지정하면 사용할 수 있고, 필드를 생략하면 기본적으로 Standard 티어가 적용됩니다. Google은 Flex를 “synchronous processing이 필요하지만 standard API의 실시간 성능은 필요 없는 latency-tolerant workload”에 적합하다고 설명합니다.

핵심 조건은 세 가지입니다.

• 가격: Standard 대비 50% 할인
• 지연 시간: 분 단위, 문서상 1~15분 목표
• 신뢰성: best-effort, 필요 시 sheddable

여기서 sheddable은 트래픽이나 자원 상황에 따라 요청이 표준 티어만큼 강하게 보장되지 않는다는 뜻으로 이해하면 됩니다. 따라서 결제 완료, 인증, 실시간 채팅, 고객 응대처럼 실패나 지연이 곧 사용자 불만으로 이어지는 작업에는 어울리지 않습니다.

왜 중요한가

AI API 비용은 단순히 모델 단가만의 문제가 아닙니다. 실제 서비스에서는 같은 모델을 쓰더라도 작업 종류에 따라 요구사항이 다릅니다. 사용자가 버튼을 누르고 기다리는 요청, 백오피스에서 밤새 처리해도 되는 요청, 정기적으로 대량 파일을 분석하는 요청, 매번 같은 문서를 참고하는 요청이 모두 같은 티어를 쓰면 비용 최적화 여지가 사라집니다.

Gemini 문서의 최적화 표는 선택지를 비교적 명확하게 나눕니다.

• Standard: 일반 애플리케이션 흐름, 초~분 단위 지연
• Flex: 비긴급 순차 체인, Standard 대비 50% 할인, 1~15분 목표
• Priority: 사용자 대면 프로덕션 요청, Standard 대비 75~100% 추가 비용
• Batch: 대량 비동기 처리, 24시간 내 완료 목표, Standard 대비 50% 할인
• Context caching: 반복되는 초기 컨텍스트에 대해 최대 90% 할인과 저장 비용

이 표가 의미하는 것은 “모든 요청을 더 싼 모델로 보내자”가 아닙니다. 요청의 SLA를 먼저 나누고, 그 SLA에 맞는 추론 티어를 골라야 한다는 뜻입니다.

Flex가 맞는 작업 예시

Flex는 비동기 Batch와 실시간 Standard 사이에 있는 선택지입니다. Batch는 최대 24시간 지연을 감수하는 대량 처리에 적합합니다. 반면 Flex는 다음 요청이 이전 출력에 의존하는 순차 작업에도 사용할 수 있습니다. 완전히 비동기로 던져놓고 기다리는 구조가 아니라, 동기식 API 체인을 유지하면서 비용을 낮출 수 있다는 점이 차이입니다.

실무에서 어울리는 예시는 다음과 같습니다.

• 비프로덕션 평가셋 채점
• 야간 리포트 초안 생성
• 내부 문서 요약과 태깅
• 상품 설명 대량 개선 전 샘플 처리
• 백오피스 데이터 보강
• 개발자 도구의 느슨한 코드 리뷰 보조
• 고객에게 바로 노출되지 않는 콘텐츠 분류

예를 들어 커뮤니티 게시글 1만 개를 카테고리별로 분류해야 한다고 가정해봅시다. 사용자가 화면에서 기다리는 작업이 아니라 관리자 리포트에 반영되는 작업이라면 Standard를 쓸 이유가 약합니다. 하지만 각 게시글의 결과를 받아 다음 게시글 묶음을 동적으로 조정해야 한다면 완전한 Batch보다 Flex가 편할 수 있습니다.

Flex가 맞지 않는 작업

반대로 Flex를 쓰면 안 되는 작업도 분명합니다. 사용자가 응답을 기다리는 챗봇, 콜센터 상담 보조, 실시간 코드 자동완성, 결제 후 영수증 생성, 장애 대응 자동화처럼 초 단위 반응이 중요한 곳에는 맞지 않습니다. 비용 50% 절감보다 지연으로 잃는 사용자 신뢰가 더 큽니다.

또한 재시도 설계 없이 Flex를 붙이는 것도 위험합니다. best-effort 티어는 실패나 지연을 애플리케이션이 받아들일 수 있어야 합니다. 요청 상태 저장, 타임아웃, 재시도, 대체 티어 승격 정책이 없으면 운영 중 원인 파악이 어려워집니다.

권장 패턴은 다음과 같습니다.

1. 기본은 Flex로 실행
2. 지정 시간 안에 결과가 없으면 상태를 pending으로 저장
3. 사용자 대면 결과가 필요해진 순간 Standard 또는 Priority로 승격
4. 실패한 요청은 멱등 키로 재시도
5. 작업 큐에 티어와 비용 태그를 함께 기록

이렇게 설계하면 Flex를 비용 절감 장치로 쓰면서도 서비스 품질을 통제할 수 있습니다.

비용 모델을 어떻게 다시 짜야 하나

Flex의 등장은 AI 비용 계산표를 단가 중심에서 워크로드 중심으로 바꿔야 한다는 신호입니다. 월간 토큰 사용량에 평균 단가를 곱하는 방식은 너무 거칩니다. 최소한 다음 네 가지 축으로 나누는 편이 좋습니다.

• 사용자 대면 실시간 요청
• 사용자 대면이지만 지연 허용 요청
• 내부 운영용 순차 요청
• 대량 오프라인 요청

각 축마다 허용 지연, 실패 허용률, 재처리 가능성, 결과 노출 범위가 다릅니다. 같은 100만 토큰이라도 실시간 상담에서 쓰는 100만 토큰과 야간 데이터 보강에서 쓰는 100만 토큰의 가치는 다릅니다. Flex는 세 번째 축, 즉 내부 운영용 순차 요청에서 특히 효과가 큽니다.

예산 관리도 바뀌어야 합니다. 팀별로 “모델별 비용”만 보는 대신 “티어별 비용”을 봐야 합니다. Standard 비중이 과하게 높다면 Flex나 Batch로 옮길 수 있는 작업을 찾고, Flex 실패율이 높다면 해당 작업의 SLA가 애초에 Flex와 맞지 않았는지 점검해야 합니다.

구현할 때 확인할 지표

Flex를 도입했다면 단순히 월 비용이 줄었는지만 보면 부족합니다. 최소한 다음 지표를 같이 봐야 합니다.

• p50, p95, p99 지연 시간
• Flex 요청 성공률과 타임아웃 비율
• Standard로 승격된 요청 비율
• 요청당 평균 토큰과 비용
• 작업 유형별 재시도 횟수
• 사용자에게 노출된 지연 건수

특히 p95 지연 시간이 중요합니다. 평균이 괜찮아도 상위 5% 요청이 너무 늦으면 운영팀은 불신하게 됩니다. Flex는 “싸니까 무조건 쓰는 티어”가 아니라 “느려도 되는 작업을 싸게 처리하는 티어”입니다. 이 차이를 지표로 확인해야 합니다.

실행 체크리스트

• 모든 AI 요청을 실시간, 지연 허용, 내부 운영, 대량 오프라인으로 분류합니다.
• Flex 후보는 사용자 화면을 직접 막지 않는 작업부터 고릅니다.
• service_tier: flex 적용 전 타임아웃과 재시도 정책을 먼저 만듭니다.
• 결과가 늦어질 때 보여줄 pending 상태나 관리자 알림을 준비합니다.
• 1~15분 지연 목표를 기준으로 업무 SLA와 맞는지 확인합니다.
• 비용 리포트에는 모델명뿐 아니라 Standard, Flex, Batch, Caching 비중을 기록합니다.
• 첫 달에는 Flex 절감액보다 실패율, 승격률, p95 지연 시간을 더 자주 봅니다.

Gemini Flex inference의 가치는 “반값”이라는 문구에만 있지 않습니다. 중요한 건 추론 인프라를 하나의 단일 통로가 아니라 SLA별 라우팅 문제로 보게 만든다는 점입니다. AI 기능이 실험 단계를 지나 운영비 항목이 되는 팀이라면, 이제 모델 선택만큼 서비스 티어 선택도 아키텍처 결정으로 다뤄야 합니다.