Google 공식 발표
구글이 2026년 4월 2일 Gemini API에 Flex 추론과 Priority 추론을 추가했습니다. 표준 요금 대비 50% 할인이라는 숫자가 먼저 눈에 들어오지만, 실제 서비스에 바로 넣었다가 503 오류 폭탄을 맞는 경우가 생깁니다. 어떤 조건에서 써야 하고, 어떤 상황에선 오히려 손해인지를 공식 문서 수치와 실제 사용 사례로 짚어봤습니다.
Flex 추론이란 무엇이고, 왜 지금 나왔나
배경은 단순합니다. AI 에이전트가 복잡해지면서 개발자들이 두 가지 전혀 다른 로직을 동시에 관리해야 하는 상황이 됐습니다. 실시간 챗봇처럼 즉각 응답이 필요한 ‘대화형 작업’과 CRM 업데이트·데이터 분류처럼 답변이 몇 분 뒤에 와도 괜찮은 ‘백그라운드 작업’이 그것입니다.
Flex 이전에는 이 두 가지를 분리하려면 표준 API와 비동기 Batch API를 별도 아키텍처로 운영해야 했습니다. Flex는 그 사이를 채우는 개념입니다. 동기식(synchronous) 인터페이스를 유지하면서도 비용을 절반으로 낮추는 게 핵심입니다.
💡 공식 발표문과 실제 API 구조를 같이 놓고 보니 이런 차이가 보였습니다. Flex는 Batch의 ‘저렴한 버전’이 아닙니다. Batch는 결과를 나중에 폴링(polling)해야 하는 비동기 방식인 반면, Flex는 응답을 그 자리에서 기다리는 동기식입니다. 에이전트 N번 호출의 결과가 N+1번 호출의 입력이 되는 순차 체인 구조에서는 Batch가 애초에 쓸 수 없습니다.
4가지 티어 수치 비교 — 어디서 어떻게 달라지나
공식 문서에 공개된 수치를 기준으로 정리했습니다. (출처: ai.google.dev/gemini-api/docs/optimization, 2026.04.13 업데이트)
| 티어 | 요금 | 응답 속도 | 안정성 | 인터페이스 |
|---|---|---|---|---|
| Flex | 표준 50% 할인 | 목표 1~15분 | 최선형 (삭제 가능) | 동기식 |
| Standard | 기본 요금 | 수 초~수 분 | 높음~중간 | 동기식 |
| Priority | 표준 75~100% 추가 | 수 초 이내 | 최고 (삭제 불가) | 동기식 |
| Batch | 표준 50% 할인 | 최대 24시간 | 높음 (처리량) | 비동기식 |
※ 출처: Google AI for Developers 공식 문서 (2026.04.13 기준)
여기서 눈에 띄는 지점이 있습니다. Flex와 Batch는 둘 다 50% 할인입니다. 같은 가격인데 왜 둘 다 쓸까 싶지만, 인터페이스 차이가 결정적입니다. Batch는 비동기라 결과를 나중에 가져와야 하지만 Flex는 동기식으로 바로 기다립니다. 에이전트 흐름에서 이전 결과를 받아야 다음 작업을 할 수 있는 구조라면 Batch는 선택지에 없습니다.
절반 가격인데, 실제로 쓸 수 없는 3가지 상황
1
실시간 응답이 필요한 사용자 대면 서비스
Flex는 응답 목표가 1~15분이고, 이마저도 보장이 아닙니다. 시스템 표준 트래픽이 급증하면 Flex 요청은 선점(preempt)됩니다. 503이나 429 오류를 돌려보내지, 자동으로 Standard로 업그레이드되지 않습니다. 챗봇 화면 앞에 앉은 사용자가 15분을 기다리는 일은 현실적으로 불가능합니다.
2
재시도 로직 없이 그냥 붙인 코드
공식 문서는 명시적으로 “서버 측 폴백 없음(No server-side fallback)”을 못박았습니다. Flex 용량이 꽉 찼을 때 Standard로 자동 전환되지 않습니다. 클라이언트 쪽에서 지수 백오프(exponential backoff) 재시도를 직접 구현해야 하고, 타임아웃도 최소 10분 이상으로 늘려야 합니다. 기존 Standard 코드에 `service_tier: “flex”` 파라미터 하나만 추가하면 된다고 생각하면 실제 서비스에서 문제가 생깁니다.
3
레이트 리밋을 넉넉하게 쓸 것으로 기대한 경우
Flex 트래픽은 일반 레이트 리밋(rate limit)에 그대로 카운트됩니다. Batch API처럼 별도의 확장된 한도를 제공하지 않습니다. 대량 처리 파이프라인을 Batch 대신 Flex로 돌리려 했다면, RPM/RPD 한도가 똑같이 걸립니다. 가격은 같고 레이트 리밋이 분리되는 Batch가 대규모 일괄 작업에서는 더 유리합니다.
💡 이 세 가지를 공식 문서와 실제 503 오류 사례를 교차해보니, Flex의 핵심 제약은 ‘속도’보다 ‘재시도 책임’에 있습니다. 오류가 났을 때 어디서 다시 잡느냐를 개발자가 전적으로 책임져야 합니다.
Priority 티어, ‘절대 에러 없음’이 아닌 이유
Priority 추론은 표준 대비 75~100% 더 비쌉니다. 그 대신 공식 문서는 “요청이 선점되지 않음(non-sheddable)”이라고 명시합니다. 한도를 초과하면 503 오류 없이 Standard로 자동 다운그레이드됩니다. 이 Graceful Downgrade 메커니즘이 Priority의 핵심 셀링 포인트입니다. (출처: Google AI for Developers 공식 블로그, 2026.04.02)
여기서 한 가지 놓치기 쉬운 지점이 있습니다. Priority를 써도 Standard로 떨어진다는 건 “Standard가 받아줄 수 있을 때” 한정입니다. Standard 자체가 과부하 상태이면 어떻게 될까요?
2026년 3월 3일 Reddit 커뮤니티(r/GeminiAI)에는 Tier 1 유료 사용자들이 하루 종일 503을 받는다는 제보가 연속으로 올라왔습니다. 스웨덴, 미국, 베트남 등 지역에 관계없이 Gemini 3 Flash와 3.1 Pro 모델에서 오류율 100%를 기록한 사례가 포함됐습니다. Priority가 없던 시기였지만, 이 맥락은 그대로 적용됩니다. Priority가 Standard로 다운그레이드되는 순간 Standard 자체가 이미 불안정하다면, 다운그레이드가 오히려 문제가 됩니다.
💡 Priority 한도를 초과했을 때 Standard로 내려가는 시점의 요금은 Standard 기준으로 청구됩니다. API 응답 헤더에 실제로 어느 티어에서 처리됐는지가 표시되므로, 모니터링 코드에서 이 헤더값을 확인해두는 편이 낫습니다.
Flex가 진짜 빛을 발하는 용도
공식 문서와 실제 사용 패턴을 교차하면 Flex가 최적인 경우는 비교적 뚜렷하게 좁혀집니다.
에이전트 순차 체인의 중간 단계가 가장 명확한 케이스입니다. 예를 들어 고객 데이터를 분석해 CRM 필드를 채우는 작업은 결과가 즉시 필요하지 않습니다. 그렇다고 Batch로 던지면 A 분석 결과가 나와야 B를 할 수 있는 순차 구조에서 폴링 관리가 복잡해집니다. Flex는 동기식이라 결과를 그 자리에서 받으면서 비용은 절반입니다.
오프라인 평가 및 회귀 테스트도 적합합니다. LLM-as-a-judge 방식으로 모델 출력을 자동 채점하거나, 배포 전 기존 케이스를 일괄 검증하는 파이프라인은 응답이 몇 분 늦어도 전혀 문제가 없습니다.
예산 제약이 있는 연구·프로토타이핑도 좋습니다. 대량 토큰을 써야 하는데 응답 속도가 중요하지 않다면, Flex로 표준 대비 절반의 예산으로 같은 양의 토큰을 쓸 수 있습니다.
💡 Flex의 ‘동기식’이라는 특성은 에이전트 체인 문맥에서 Batch와 결정적으로 다릅니다. Batch는 24시간 처리를 전제로 잡 ID를 폴링해야 하지만, Flex는 같은 코드 흐름 안에서 await 한 번으로 결과를 받습니다. 구조를 바꾸지 않아도 된다는 점이 실제 도입 비용을 낮춥니다.
실제 비용 계산: Gemini 2.5 Pro Flex vs Standard
공식 가격 기준으로 직접 따라 할 수 있는 계산식을 만들어봤습니다. (출처: ai.google.dev/gemini-api/docs/pricing, 2026.04 기준 / Gemini 2.5 Pro, 200K 토큰 이하 기준)
📐 계산 가정
- 모델: Gemini 2.5 Pro (200K 토큰 이하)
- 월 입력 토큰: 5억 토큰 (500M)
- 월 출력 토큰: 1억 토큰 (100M)
- Standard 입력 요금: $1.25 / 1M 토큰
- Standard 출력 요금: $10.00 / 1M 토큰
💰 Standard 기준 월 비용
입력: 500 × $1.25 = $625
출력: 100 × $10.00 = $1,000
합계: $1,625 / 월
💰 Flex 기준 월 비용 (50% 할인)
입력: 500 × $0.625 = $312.5
출력: 100 × $5.00 = $500
합계: $812.5 / 월 → 월 $812.5 절감
같은 사용량에서 월 $812.5, 연간 기준 약 $9,750(약 1,300만 원)을 아낄 수 있습니다. 단, 이 수치는 Flex 요청이 성공적으로 처리됐을 때 한정입니다. 503으로 Standard에 폴백하는 로직을 넣었다면 실제 절감액은 줄어듭니다.
💡 Priority를 쓸 경우 Standard 대비 최대 2배 요금이므로, 위 예시 기준 월 $3,250입니다. Flex와의 차이는 월 최대 $2,437.5입니다. 서비스 중단 한 번이 그 이상의 비용을 만드는 구조라면 Priority가 정당화됩니다.
자주 묻는 질문 (Q&A)
Q1. Flex는 무료 티어에서도 쓸 수 있나요?
아닙니다. Flex는 유료 결제 계정(paid tier)에서만 사용 가능합니다. 무료 티어 사용자는 Standard 호출만 사용할 수 있습니다. (출처: Google AI for Developers 공식 문서, 2026.04.01)
Q2. Flex 요청이 15분 넘게 걸릴 수도 있나요?
네. 1~15분은 목표치이며 보장하지 않습니다. Flex 용량이 없거나 시스템이 혼잡할 경우 요청이 지연되거나 503 오류가 발생할 수 있습니다. 공식 문서는 클라이언트 타임아웃을 최소 10분(600초) 이상으로 설정하도록 권장합니다.
Q3. Priority 추론은 Tier 1 계정으로도 쓸 수 있나요?
Priority 추론은 Tier 2와 Tier 3 유료 사용자만 이용할 수 있습니다. Tier 1 계정은 Flex와 Standard만 사용 가능합니다. Tier 업그레이드 조건은 Google AI Studio의 요금 및 한도 페이지에서 확인할 수 있습니다. (출처: Google AI for Developers 공식 블로그, 2026.04.02)
Q4. Context Caching과 Flex를 함께 쓰면 비용이 더 줄어드나요?
Context Caching은 입력 토큰 비용에서 최대 90% 절감을 제공하는 별도 메커니즘입니다. Flex와 동시에 적용할 수 있는지는 공식 문서에서 명확히 밝히지 않은 부분입니다. 동일 프롬프트 접두사를 반복적으로 사용하는 워크로드라면 Gemini 2.5 이상 모델에서 암시적 캐싱이 자동으로 작동하므로 별도 설정 없이 일부 절감이 적용됩니다.
Q5. Flex 지원 모델 목록은 어디서 확인하나요?
2026년 4월 기준으로 Gemini 2.5 Pro, Gemini 2.5 Flash, Gemini 2.5 Flash-Lite, Gemini 3 Flash Preview, Gemini 3 Pro Image Preview, Gemini 3.1 Flash-Lite Preview, Gemini 3.1 Pro Preview에서 Flex 추론을 지원합니다. 최신 목록은 ai.google.dev/gemini-api/docs/flex-inference에서 확인하는 것이 가장 정확합니다.
마치며
솔직히 말하면, 써보니까 Flex의 진짜 장점은 가격보다 ‘코드 구조를 바꾸지 않아도 된다’는 점이었습니다. Batch API는 잡 ID를 따로 관리하고 폴링 로직을 추가해야 하는데, Flex는 파라미터 하나면 됩니다. 에이전트 체인처럼 순차 흐름이 중요한 워크로드에서 그 차이가 체감됩니다.
반대로 사용자 화면 앞에 결과를 즉시 보여줘야 하는 서비스, 503이 났을 때 폴백 로직 없이 그냥 쓰는 경우, 또는 레이트 리밋을 넉넉하게 쓰길 원하는 대규모 Batch 작업이라면 Flex는 선택지가 아닙니다. 조건을 정확히 맞추면 꽤 유용하고, 맞지 않으면 오히려 운영 부담이 늘어납니다.
📎 본 포스팅 참고 자료
본 포스팅은 2026년 4월 15일 기준으로 작성됐습니다. Gemini API의 서비스 정책·요금·지원 모델·UI는 이후 업데이트로 변경될 수 있습니다. 최신 정보는 Google AI for Developers 공식 문서에서 확인하시기 바랍니다.
댓글 남기기