구글 Gemini API, 이제 모델보다 요청 우선순위를 팝니다

구글 Gemini API, 이제 모델보다 요청 우선순위를 팝니다

구글 Gemini API, 이제 모델보다 요청 우선순위를 팝니다

모델은 그대로인데 가격표가 갈라졌습니다

Google이 2026년 4월 2일 Gemini API에 Flex와 Priority를 넣었는데요. 새 모델 발표보다 더 크게 보이는 이유는 같은 Gemini를 써도 요청 성격에 따라 가격, 대기시간, 실패 방식까지 따로 설계하라고 신호를 준 점입니다. 이제 AI API는 모델 성능표만 보는 시장이 아니라, 어떤 요청을 먼저 살리고 어떤 요청을 뒤로 미룰지까지 상품이 되는 단계로 들어갔어요.

Flex가 메운 건 Batch의 불편함입니다

공식 블로그에서 Google은 Flex를 Standard 대비 '50% price savings'라고 적었고, 동시에 Batch API처럼 파일 입출력이나 polling 없이 같은 synchronous endpoint(동기 호출 엔드포인트)를 쓴다고 설명했어요. Flex 문서는 이 티어를 variable latency(가변 지연)와 best-effort availability(최선형 가용성)를 전제로 한 옵션으로 두고, 지연 목표를 1~15분으로 적었습니다. 여기에 클라이언트 timeout도 10분 이상으로 잡으라고 권하는데요. 이건 단순 할인 요금제가 아니라, 배경 작업을 기존 호출 체인 안으로 밀어 넣을 수 있게 해주는 운영 편의성 패키지에 가깝습니다.

Priority는 실패를 등급 하향으로 바꿉니다

반대로 Priority는 비싼 대신 실패 방식을 바꿉니다. Google 문서는 Priority를 Standard 대비 75~100% 비싼 premium tier로 두면서, 한도를 넘긴 요청은 503이나 429로 죽이는 대신 graceful downgrade(등급 하향)로 Standard에 태운다고 적어뒀어요. 또 응답에 실제 어떤 tier가 요청을 처리했는지 표시해준다고 했고, 기본 호출 한도는 standard rate limit(호출 한도)의 0.3배라고 명시했죠. SaaS 팀 입장에선 장애를 줄이는 기능이라기보다, 어떤 기능에 비싼 보장을 붙일지 제품 가격표와 직접 연결되는 옵션입니다.

숫자를 놓고 보면 방향이 더 선명해집니다

예를 들어 Gemini 3.1 Pro Preview 기준으로 Standard는 입력 100만 토큰당 2달러, 출력 12달러인데요. 같은 모델을 Flex로 보내면 1달러와 6달러로 내려가고, Priority는 3.6달러와 21.6달러로 올라갑니다. 모델 자체가 바뀌지 않았는데도 요청 라우팅만으로 원가 구조가 세 갈래로 갈리는 셈이죠. 제일 큰 문제는 우선순위를 못 잡는 거라서, 이 발표를 그냥 프롬프트 비용 절감 뉴스로만 읽으면 운영 판단을 놓치게 됩니다.

에이전트 시대엔 프롬프트보다 큐 설계가 먼저 옵니다

Google 블로그가 Flex의 대표 사례로 background CRM updates, research simulations, agentic workflows를 넣은 것도 그래서예요. 에이전트는 한 번의 답변보다 여러 단계의 호출 묶음이 많아서, 모두를 실시간으로 처리하려 들면 비용도 튀고 병목도 바로 옵니다. 반대로 사용자 앞에 보이는 단계만 Priority나 Standard에 남기고 뒤쪽 thinking, enrichment, moderation을 Flex로 보내면 체감 품질은 지키면서 총원가를 줄일 수 있거든요. 실제로 해보면 모델 교체보다 이 라우팅 한 장이 뒤를 거의 정리해줍니다.

구글이 팔기 시작한 건 속도 옵션이 아니라 운영권입니다

이 발표가 크게 보이는 이유는 Google이 더 이상 좋은 모델만 파는 회사처럼 움직이지 않기 때문입니다. 같은 Gemini를 놓고도 어떤 요청은 우선 보장하고 어떤 요청은 밀려나도 되게 나눠 파는 순간, API 사업은 클라우드 큐잉과 SLO(서비스 수준 목표) 상품에 가까워져요. OpenAI나 Anthropic도 비슷한 방향으로 갈 가능성이 높은데, 그때 비교 포인트는 벤치마크가 아니라 downgrade 정책, timeout 권장치, overflow 처리 방식이 될 겁니다. 모델 점수표보다 장애 시나리오 문서가 더 중요해지는 구간이 벌써 왔어요.

링크보다 더 남는 건 운영 습관 변화입니다

이번 글은 2026년 4월 2일 게시된 Google 블로그 원문과 같은 날 갱신된 가격 문서, Flex 문서, Priority 문서를 기준으로 썼습니다. 다음 분기부터는 모델 선택 회의보다 요청 분류 회의가 더 길어질 가능성이 커 보여요. 끝까지 지켜볼 포인트는 하나예요, 실제 서비스들이 Priority를 어디에 붙이고 어디를 Flex로 내리는지입니다.

댓글 쓰기

다음 이전