Gemini API를 운영하다 보면 대부분의 팀이 같은 문제를 만납니다. 실시간 기능은 느리면 안 되고, 백그라운드 작업은 비싸면 안 됩니다. 그런데 지금까지는 이 둘을 같은 방식으로 처리하거나, 반대로 너무 복잡하게 나눠서 운영하는 경우가 많았습니다. Google이 2026년 4월 발표한 Flex와 Priority inference는 이 딜레마를 꽤 실용적으로 풀어줍니다. 핵심은 배치와 실시간의 중간 지대를 메우는 것입니다.
공식 설명에 따르면 Flex는 지연시간을 조금 양보하는 대신 비용을 낮춘 tier이고, Priority는 중요한 앱에서 가장 높은 신뢰성과 응답성을 얻기 위한 tier입니다. 중요한 포인트는 둘 다 같은 동기식 인터페이스 안에서 다룰 수 있다는 점입니다. 즉, 예전처럼 “느린 대량 작업은 완전히 다른 비동기 배치 시스템으로 따로 짜야 한다”는 부담을 줄여줍니다.
이 글은 단순 소개가 아니라, 실제 서비스 운영에서 Flex와 Priority를 어떻게 나눠 써야 비용과 사용자 경험을 동시에 잡을 수 있는지 정리합니다.
문제는 모델이 아니라 요청 분류를 안 한 데서 시작됩니다. 실무에서 흔한 패턴은 아래 둘 중 하나입니다.
첫째, 모든 요청을 같은 고품질·고비용 경로에 태웁니다. 이 경우 초기 데모는 좋아 보이지만, 사용량이 늘면 비용이 급격히 커집니다.
둘째, 무조건 저렴한 방식으로 몰아넣습니다. 이 경우 지연시간과 실패율이 올라가고, 사용자는 기능 자체를 덜 쓰게 됩니다.
Google이 Flex와 Priority를 내놓은 배경도 여기에 있습니다. 공식 발표에서 예시로 든 구분은 꽤 명확합니다.
이 구분을 서비스 설계에 반영하지 않으면 모델을 바꿔도 운영 문제는 그대로 남습니다.
Flex는 Google 발표 기준으로 Standard API 대비 50% 가격 절감을 노릴 수 있는 cost-optimized tier입니다. 대신 신뢰성과 latency를 일부 양보합니다. 여기서 흔한 오해가 하나 있습니다. “느리면 아무 데도 못 쓰는 것 아닌가?” 아닙니다. 느려도 되는 요청은 생각보다 많습니다.
대표적인 Flex 적합 사례는 다음과 같습니다.
공통점은 사용자가 화면 앞에서 초를 세며 기다리지 않는다는 점입니다. 결과가 2초가 아니라 8초 걸려도 큰 문제는 없지만, 요청량이 많기 때문에 단가 차이는 크게 쌓입니다.
예를 들어 하루 5만 건의 내부 정리 작업이 있다고 가정해보겠습니다. 요청당 비용이 절반으로 줄면 월간 비용 구조가 완전히 달라집니다. 이런 작업을 여전히 최고 신뢰 tier로만 돌리고 있다면, 성능이 아니라 설계가 낭비를 만들고 있는 셈입니다.
Priority는 반대로 사용자 경험 방어용입니다. Google은 highest reliability가 필요한 critical app에 맞춘다고 설명했습니다. 여기서 중요한 건 “고객이 돈 내는 핵심 순간”과 “실패했을 때 곧바로 불만이 생기는 순간”을 우선 붙이는 것입니다.
Priority 적합 사례는 보통 이렇습니다.
이 구간은 1~2초 차이가 기능 만족도를 바꿉니다. 게다가 실패 재시도가 길어지면 사용자는 시스템을 신뢰하지 않게 됩니다. 그래서 Priority는 단순히 “좋은 품질”이 아니라 “이탈을 막는 보험”에 가깝습니다.
운영 관점에서 보면 비용이 조금 더 들더라도 전환율, 상담 처리 시간, 유지율에 미치는 영향이 크다면 값어치를 합니다.
많은 팀이 놓치는 포인트는 한 기능이 항상 한 tier만 써야 하는 건 아니라는 점입니다. 예를 들어 “AI 영업 어시스턴트”라는 하나의 기능도 실제로는 세 단계로 나눌 수 있습니다.
사전 조사 단계 계정 정보, 이전 대화, 경쟁사 뉴스, 내부 문서를 읽고 초안을 만든다. → Flex 후보
실시간 대화 보조 단계 영업 담당자에게 회의 중 답변 초안을 준다. → Priority 후보
회의 후 정리 단계 회의록 정리, CRM 업데이트, 후속 메일 초안 작성. → Flex 후보
즉, 기능 단위가 아니라 요청 단계 단위로 tier를 나누는 게 핵심입니다. 이렇게 해야 “사용자가 체감하는 구간”에만 비싼 리소스를 쓰고, 나머지는 저비용으로 흘릴 수 있습니다.
Google은 Flex가 동기식 인터페이스라서 Batch API보다 운영이 단순하다고 강조합니다. 이건 분명 장점입니다. 입력 파일 만들고, 비동기 잡 생성하고, 완료 폴링하고, 실패 재처리하는 관리 비용이 줄기 때문입니다.
하지만 이 말이 배치를 버리라는 뜻은 아닙니다. 대규모 오프라인 처리, 밤새 도는 초대량 작업, 긴 허용 지연시간을 가진 파이프라인은 여전히 배치가 맞을 수 있습니다. Flex가 특히 유용한 곳은 “배치로 가기엔 번거롭고, 표준 실시간으로 돌리기엔 비싼 작업”입니다.
즉 선택 기준은 이렇게 정리할 수 있습니다.
이 기준을 문서로 고정해두면 팀이 커져도 라우팅 혼란이 줄어듭니다.
Flex와 Priority를 붙였는데도 비용이 안 내려가거나 UX가 안 좋아지는 팀이 있습니다. 이유는 측정이 부족해서입니다. 최소한 아래 지표는 tier별로 따로 봐야 합니다.
단순 list price가 아니라 재시도 포함 총비용을 봐야 합니다.
평균이 아니라 긴 꼬리 구간이 중요합니다. Priority는 특히 여기를 봐야 합니다.
Flex는 저렴해도 실패 재시도가 많아지면 실제 비용이 다시 오릅니다.
Priority가 빠르더라도 결과 품질이 낮아 채택되지 않으면 의미가 없습니다.
Flex 작업이 몰릴 때 후속 파이프라인 전체가 지연되지 않는지 확인해야 합니다.
이 다섯 가지를 안 보면 “싸서 좋다”거나 “빠르니 좋다” 수준의 감각 평가에 머물게 됩니다.
처음 도입할 때는 복잡한 머신러닝 라우터보다 단순한 정책 기반 분기가 낫습니다. 예를 들어 아래처럼 시작할 수 있습니다.
이 정도만 지켜도 대부분의 서비스에서 처음부터 꽤 큰 차이가 납니다.
첫째, “중요한 기능이니까 전부 Priority”로 넣습니다. 기능 전체가 중요한 게 아니라 그중 어느 순간이 중요한지 쪼개야 합니다.
둘째, Flex를 테스트 환경에서만 써보고 운영에는 못 씁니다. 실제로는 운영 백그라운드 작업이 Flex 최적 구간일 때가 많습니다.
셋째, 비용만 보고 Flex를 선택합니다. 재시도율과 downstream 지연을 같이 안 보면 착시가 생깁니다.
넷째, 사용자 경험 지표 없이 인프라 지표만 봅니다. 응답이 빨라도 채택이 안 되면 운영 최적화는 실패입니다.
Gemini API의 Flex와 Priority는 단순한 요금제 추가가 아닙니다. 실무적으로는 “같은 모델을 더 똑똑하게 배치하는 운영 도구”에 가깝습니다. 모델 교체보다 먼저 해야 할 일은 요청을 분류하는 것입니다. 그걸 해두면 비용도 내려가고, 정말 중요한 순간에만 비싼 성능을 쓰는 구조를 만들 수 있습니다.
