Gemini API Flex·Priority 티어, 수치 4개로 직접 따져봤습니다

2026년 4월 1일, 구글이 Gemini API에 Flex 추론 티어와 Priority 추론 티어를 동시에 출시했습니다. “Flex는 50% 할인”이라는 문장 하나만 보고 Batch API와 같다고 생각하면 안 됩니다. 동기식이라는 점, 레이트 리밋을 공유한다는 점, Priority가 초과됐을 때 생기는 일 — 공식 문서에 나와 있는데 주목받지 못한 수치들을 직접 비교했습니다.

4가지 추론 티어를 한눈에 — 수치로 먼저 보기

Gemini API에는 이제 Standard, Batch, Flex, Priority 총 4가지 추론 티어가 존재합니다. 결론부터 말씀드리면, Flex 추론 티어는 기존 Batch API와 가격이 동일하지만 동작 방식이 완전히 다릅니다. Batch는 비동기(Asynchronous)로 24시간 내 처리인 반면, Flex는 동기(Synchronous)로 요청한 즉시 응답을 기다립니다. 이 차이가 어떤 상황에서 중요한지는 뒤에서 자세히 다룹니다.

※ 출처: ai.google.dev/gemini-api/docs/flex-inference, ai.google.dev/gemini-api/docs/priority-inference (2026.04.01 기준)

▲ 목차로 돌아가기

Flex 티어, Batch API와 같은 50% 할인인데 다른 게 있습니다

Flex 추론 티어가 출시됐을 때 가장 먼저 눈에 들어오는 것은 “50% cost reduction”이라는 문구입니다. Batch API도 50% 할인이라 같은 거 아닌가 싶지만, 사용 맥락이 완전히 다릅니다.

공식 문서의 표현을 그대로 옮기면 이렇습니다. “Flex inference bridges the gap between the standard API and the 24-hour turnaround of the Batch API.” (출처: ai.google.dev/gemini-api/docs/flex-inference, 2026.04.01 기준) 즉 Flex는 표준 API와 Batch API 사이의 공백을 채우기 위해 설계됐습니다. 실시간 사용자 응답은 필요 없지만, 비동기 Job 관리 복잡도도 피하고 싶을 때 쓰는 티어입니다.

Flex가 실용적인 시나리오는 구체적입니다. 오프라인 평가에서 LLM-as-a-judge 방식으로 회귀 테스트를 돌릴 때, 백그라운드에서 CRM 데이터를 요약하는 에이전트, 또는 연구 목적으로 고토큰 처리를 저예산으로 수행할 때가 공식 문서에서 명시한 적합한 용도입니다. 반면 사용자가 화면 앞에서 기다리는 실시간 챗봇이나 코파일럿 기능에는 맞지 않습니다. 응답이 1~15분까지 걸릴 수 있기 때문입니다.

▲ 목차로 돌아가기

Flex의 레이트 리밋이 일반 한도를 공유하는 이유

Flex 티어는 저렴한 대신 레이트 리밋이 더 넉넉할 것이라 생각하기 쉬운데, 공식 문서는 반대로 설명합니다. “Flex inference traffic counts towards your general rate limits; it doesn’t offer extended rate limits like the Batch API.” (출처: ai.google.dev/gemini-api/docs/flex-inference, 2026.04.01 기준) 일반 레이트 리밋을 공유하기 때문에 Flex 요청이 쌓이면 Standard 요청도 영향받습니다.

또 하나 놓치기 쉬운 부분이 있습니다. Flex 요청이 서버 부하로 처리 불가 상태가 됐을 때 Google은 자동으로 Standard 티어로 올려주지 않습니다. 공식 문서에 이렇게 나옵니다. “To prevent unexpected charges, the system won’t automatically upgrade a Flex request to the Standard tier if Flex capacity is full.” 그래서 503이 반환되면 클라이언트가 직접 재시도 로직(exponential backoff)을 구현해야 합니다. 타임아웃 설정도 기본값보다 길게 잡아야 합니다. 공식 권장치는 600초(10분) 이상입니다.

실제로 2025~2026년 사이 Gemini API에서 503 오류는 꽤 자주 보고됐습니다. Google AI Studio 커뮤니티에는 “일 50회 요청 중 47회가 503″이라는 사례(discuss.ai.google.dev, 2025.11)도 있었습니다. Flex가 “sheddable” 트래픽을 쓰기 때문에 표준 트래픽 폭증 시 가장 먼저 밀려납니다. 비용은 절반이지만 안정성은 best-effort입니다.

▲ 목차로 돌아가기

Priority 티어, 초과하면 에러가 아니라 다운그레이드됩니다

Priority 티어에서 가장 주목해야 할 부분은 한도 초과 시 처리 방식입니다. 유료 프리미엄 티어라 한도를 넘으면 429 에러가 날 것 같지만, 실제로는 그렇지 않습니다. “If Priority limits are exceeded due to congestion, overflow requests are automatically and gracefully downgraded to Standard processing instead of failing with a 503 or 429 error.” (출처: ai.google.dev/gemini-api/docs/priority-inference, 2026.04.01 기준) 서비스가 끊기지 않도록 Standard로 자동 처리합니다.

다만 다운그레이드된 요청은 Standard 요금으로 청구됩니다. Priority 프리미엄 요금이 아니라 일반 Standard 가격이 적용되는 것은 개발자 입장에서 오히려 합리적인 구조입니다. 하지만 이 다운그레이드를 모르고 있으면 성능이 기대치 이하로 떨어지는 상황이 반복될 수 있습니다. 공식 문서에서는 응답 헤더의 `x-gemini-service-tier` 값을 모니터링해 다운그레이드 빈도를 추적하도록 권장합니다.

Priority 티어의 기본 레이트 리밋은 Standard의 0.3배입니다. Standard에서 분당 100 RPM이 허용된다면 Priority는 30 RPM만 쓸 수 있다는 뜻입니다. 트래픽이 적을 때는 빠른 응답을 보장받지만, 트래픽 집중 시 30 RPM을 금방 채울 수 있습니다. 이 설계의 의도는 Priority 트래픽 자체를 소수의 고가치 요청으로 제한해 서버 우선순위를 실질적으로 보장하는 데 있습니다.

▲ 목차로 돌아가기

Priority는 Tier 2·3 사용자만 쓸 수 있습니다

Priority 티어를 쓰려면 Gemini API 계정이 Tier 2 또는 Tier 3에 있어야 합니다. 공식 문서에 “Priority inference is available to Tier 2 & Tier 3 users across the GenerateContent API and Interactions API endpoints”라고 명시돼 있습니다. (출처: ai.google.dev/gemini-api/docs/priority-inference, 2026.04.01 기준) Tier 1 계정이나 무료 플랜에서는 `service_tier: priority`로 요청해도 처리되지 않습니다.

Tier 2는 Google Cloud 결제 계정의 누적 지출이 일정 기준을 넘어야 자동으로 올라갑니다. 공식 레이트 리밋 문서에는 Tier 2·3 승격 기준이 “총 누적 지출 기반”이라 명시돼 있지만 정확한 금액은 공개되지 않았습니다. API를 막 시작한 개발자나 소규모 프로젝트라면 Priority 티어 자체에 접근이 안 됩니다.

Flex 티어는 Tier 제한이 없습니다. 유료 플랜(paid tier)이면 누구나 `service_tier: flex`를 파라미터 하나만 추가해 사용할 수 있습니다. 설정 비용이나 추가 신청 절차 없이 기존 API 코드에 파라미터 한 줄을 더하는 것으로 전환됩니다. 이 접근성 차이가 Flex의 실질적인 강점입니다.

▲ 목차로 돌아가기

Gemini 3.1 Pro Preview 기준 티어별 실제 가격 계산

가격 차이를 체감하려면 실제 수치로 계산하는 게 빠릅니다. Gemini 3.1 Pro Preview를 기준으로 프롬프트 200K 토큰 이하 조건에서 비교합니다. (출처: ai.google.dev/gemini-api/docs/pricing, 2026.04.01 기준)

※ Gemini 3.1 Pro Preview, 프롬프트 ≤200K 토큰 기준. 출처: ai.google.dev/gemini-api/docs/pricing (2026.04.01 기준)

이 계산에서 보이는 게 있습니다. Standard 대비 Priority는 입력 기준 1.8배($2→$3.60), 출력 기준 1.8배($12→$21.60)입니다. 즉 “75~100% 더 비싸다”는 문구가 실제로는 약 80% 추가 부담입니다. 1M 토큰 단위 입출력 기준으로 Standard와 비교하면 $11.20 차이입니다.

Flex는 응답 속도를 희생하는 대신 Batch와 동일한 비용으로 순차적 워크플로우를 유지할 수 있습니다. 예를 들어, 10만 개 문서를 에이전트로 요약·분류하는 파이프라인을 Flex로 돌리면 Standard 대비 비용이 절반입니다. 단 각 요청당 최대 15분을 허용하는 타임아웃 설정이 필요하고, 503 재시도 로직도 직접 구현해야 합니다. 비용 절감이 개발 오버헤드를 감수할 만한지 판단이 필요합니다.

▲ 목차로 돌아가기

자주 묻는 질문 5개

▲ 목차로 돌아가기

마치며 — 어떤 상황에서 어느 티어가 맞는지

Flex와 Priority는 각각 명확한 사용 대상이 있는 티어입니다. “싸다고 Flex”도, “비싸다고 Priority”도 아닙니다. 직접 비교하면 이렇게 요약됩니다. Flex는 사용자 대면이 아닌 백그라운드 처리에, Priority는 사용자가 실시간으로 기다리는 프로덕션 응용에 적합합니다.

솔직히 말하면, 지금 시점에서 Flex는 에이전틱 파이프라인을 저예산으로 굴려보는 개발자에게 꽤 매력적인 선택지입니다. 파라미터 하나만 추가하면 되고, 비용은 절반입니다. 다만 503 재시도 로직과 긴 타임아웃 설정은 직접 챙겨야 하고, 프로덕션 워크로드에 섞어 쓰면 일반 레이트 리밋을 같이 소모한다는 점은 꼭 기억해야 합니다.

Priority는 Tier 2·3 접근 조건 때문에 소규모 개발자에게는 당장 현실적이지 않습니다. 하지만 트래픽이 늘어나 Tier가 올라가는 시점에는 “서비스 중단 없는 graceful downgrade”라는 설계 방식이 실질적으로 의미있어집니다. 두 티어 모두 2026년 4월 1일 출시된 신기능이라 실제 서비스 안정성은 앞으로 더 검증이 필요합니다.

▲ 목차로 돌아가기

본 포스팅 참고 자료

1. Gemini API 공식 문서 — Flex inference
   https://ai.google.dev/gemini-api/docs/flex-inference (2026.04.01 기준)
2. Gemini API 공식 문서 — Priority inference
   https://ai.google.dev/gemini-api/docs/priority-inference (2026.04.01 기준)
3. Gemini API 공식 가격 정책
   https://ai.google.dev/gemini-api/docs/pricing (2026.04.01 기준)
4. Gemini API Changelog — April 1, 2026
   https://ai.google.dev/gemini-api/docs/changelog