모델 선택과 비용·지연시간 설계

모델 이름보다 먼저 정해야 할 것

AI Studio에서 프롬프트를 몇 번 실행해 보면 자연스럽게 이런 질문이 생긴다. "그래서 어떤 모델을 쓰면 되지?" 많은 팀이 이 질문에 "가장 똑똑한 모델"로 답하려 한다. 하지만 실제 서비스에서는 그 답이 자주 틀린다. 모델 선택은 취향의 문제가 아니라 제품의 비용 구조, 응답 속도, 실패 허용 범위, 사용자 경험을 동시에 결정하는 아키텍처 결정이다.

예를 들어 고객지원 챗봇을 만든다고 해 보자. 사용자가 "배송은 언제 오나요?"라고 묻는 순간마다 최고급 추론 모델을 호출하면 답변 품질은 좋아 보일 수 있다. 그러나 하루 10만 건의 문의가 들어오면 비용이 빠르게 불어난다. 게다가 사용자는 완벽한 논문식 답변보다 1초 안에 도착하는 짧고 정확한 답변을 더 좋아할 때가 많다. 반대로 복잡한 계약서 300쪽에서 위험 조항을 찾는 업무에 가장 저렴한 모델만 쓰면, 몇 센트 아낀 대가로 중요한 조항을 놓칠 수 있다.

Gemini 2.5 계열을 실무 기준선으로 삼으면 선택지는 크게 세 갈래로 정리된다. Pro는 어려운 추론과 코딩, 긴 문서 분석에 강하다. Flash는 품질과 속도, 비용의 균형점이다. Flash-Lite는 대량 분류, 단순 추출, 초저지연 응답처럼 "많이, 빨리, 싸게" 처리해야 하는 일에 맞다. Google은 Gemini 2.5 계열을 사고할 수 있는 모델군으로 설명하며, 특히 Flash와 Flash-Lite에서는 개발자가 사고 예산을 조절해 품질·비용·지연시간의 균형을 맞출 수 있다고 안내한다.¹

이 장에서 배울 핵심은 단순하다. 모델은 기능 이름으로 고르는 것이 아니라 다음 다섯 가지 설계 변수로 고른다.

• 품질: 틀렸을 때 손실이 얼마나 큰가.

• 속도: 사용자가 몇 초까지 기다릴 수 있는가.

• 비용: 요청 수와 토큰 수가 늘어났을 때 월 비용이 감당 가능한가.

• 컨텍스트: 문서, 대화 기록, 파일, 검색 결과를 얼마나 많이 넣어야 하는가.

• 사고 예산: 답변 전에 모델이 얼마나 깊게 추론해야 하는가.

이 다섯 가지를 잡으면 "Pro가 좋다", "Flash가 빠르다" 같은 막연한 판단에서 벗어나 "이 경로는 Flash-Lite, 이 경로는 Flash, 이 경로만 Pro"라는 설계를 할 수 있다.

Pro, Flash, Flash-Lite의 역할을 다시 정의하기

Gemini 모델 이름은 자동차 등급표처럼 보이지만, 실무에서는 주방의 도구에 가깝다. Pro는 셰프의 칼이다. 복잡한 재료를 다듬고 섬세한 판단을 해야 할 때 필요하다. Flash는 바쁜 점심시간의 주력 화구다. 빠르고 안정적으로 많은 주문을 처리한다. Flash-Lite는 대량 손질용 기계다. 감자 1만 개를 같은 크기로 자르는 데 셰프의 칼을 쓰지 않는 것과 같다.

Gemini 2.5 Pro는 복잡한 추론, 코딩, 멀티모달 이해, 긴 컨텍스트가 함께 필요한 작업에 어울린다. Gemini 2.5 기술 보고서는 Pro가 코딩과 추론 벤치마크에서 강점을 보이고, 긴 컨텍스트와 멀티모달 입력을 결합해 새로운 에이전트형 워크플로를 가능하게 한다고 설명한다.² 제품으로 번역하면 "한 번 틀리면 비싼 일"에 Pro를 배정한다는 뜻이다. 예를 들어 법무 검토 초안, 복잡한 코드 리팩터링 계획, 다단계 데이터 분석, 긴 회의록의 의사결정 추출, 여러 문서의 상충 내용 비교가 여기에 들어간다.

Gemini 2.5 Flash는 대부분의 제품에서 기본값이 될 가능성이 높다. 일상적인 질의응답, 요약, 초안 작성, 일반 챗봇, RAG 답변 생성, 간단한 코드 보조처럼 품질도 중요하지만 지연시간과 비용도 함께 중요한 경로에 잘 맞는다. Google은 2.5 Flash를 안정 모델로 공개하면서 단일 가격 체계를 안내했고, 사고 예산을 조절할 수 있는 모델로 설명했다.¹ 실무 감각으로 말하면 Flash는 "일단 여기서 시작하고, 병목이 생기면 Lite나 Pro로 갈라지는" 모델이다.

Gemini 2.5 Flash-Lite는 가장 오해받기 쉬운 모델이다. Lite라는 이름 때문에 "품질이 낮은 보급형"처럼 느껴지지만, 실제 역할은 "처리량과 지연시간 최적화 모델"에 가깝다. Google의 모델 문서는 Flash-Lite를 비용 효율적인 멀티모달 모델로 소개하며, 고빈도·경량 작업, 대량 분류, 단순 데이터 추출, 초저지연 애플리케이션에 적합하다고 설명한다.³ 대량 고객 문의 분류, 스팸 판단, 상품 속성 태깅, 감정 분류, 짧은 문장 번역, 간단한 JSON 추출 같은 작업에서는 Pro보다 Flash-Lite가 더 올바른 선택일 수 있다.

다음 표는 모델을 기능이 아니라 업무 경로에 매핑한 것이다.

중요한 점은 "하나의 제품에 하나의 모델"이라는 생각을 버리는 것이다. 하나의 고객지원 제품 안에서도 인사말은 Flash-Lite, 일반 답변은 Flash, 복잡한 클레임 분석은 Pro가 맡을 수 있다. 모델 선택은 정적 설정이 아니라 라우팅 정책이다.

토큰은 곧 돈이고 시간이다

LLM 비용을 이해하는 첫 번째 단위는 토큰이다. 토큰은 모델이 텍스트를 처리하기 위해 잘게 나눈 조각이다. 영어에서는 대략 1토큰이 4자 또는 0.75단어 정도로 설명되지만, 한국어·코드·JSON·표·파일 형식에서는 체감이 달라진다. 그래서 실무에서는 "대략 몇 글자"보다 SDK의 토큰 계산 기능과 응답의 사용량 메타데이터를 기준으로 보는 편이 안전하다.

요청 하나의 비용은 보통 다음 구조로 계산한다.

요청 비용 = 입력 토큰 비용 + 출력 토큰 비용 + 추가 기능 비용

여기에 사고 토큰, 캐시 읽기·쓰기, Batch 할인, 검색 그라운딩, 파일 처리, 오디오 입력 같은 요소가 붙으면 실제 비용이 달라진다. 처음에는 복잡해 보이지만, 운영 관점에서는 다음 네 종류만 구분하면 된다.

특히 출력 토큰은 과소평가하기 쉽다. 많은 팀이 입력 문서 크기만 보고 비용을 추정한다. 그러나 요약 모델이 매번 3,000토큰짜리 장문 답변을 생성하면 출력 비용이 더 큰 비중을 차지할 수 있다. 챗봇이 "짧게 답하세요"라는 지시 없이 매번 친절한 서론과 결론을 붙이면, 품질이 아니라 비용만 부풀어 오른다.

멀티모달 입력도 마찬가지다. PDF 한 개, 이미지 몇 장, 30분짜리 회의 녹음은 사용자에게는 "파일 하나"지만 모델에게는 많은 입력 토큰과 처리 시간을 의미한다. Agent Platform의 Gemini 2.5 Flash-Lite 문서는 이 모델이 텍스트, 코드, 이미지, 오디오, 동영상 입력을 지원하고 최대 입력 1,048,576토큰과 최대 출력 65,535토큰을 제공한다고 안내한다.⁴ 숫자만 보면 매우 넉넉하지만, 실제 제품에서는 "넣을 수 있다"와 "매번 넣어도 된다"를 구분해야 한다.

긴 컨텍스트는 강력한 무기다. 하지만 무기는 꺼낼 때마다 비용이 든다. 100만 토큰 창이 있다고 해서 모든 요청에 전체 문서를 넣는 것은, 택배 상자 하나 보내는 데 매번 이삿짐 트럭을 부르는 것과 비슷하다.

사고 예산은 품질 스위치이자 비용 스위치다

Gemini 2.5 계열의 중요한 특징 중 하나는 사고 예산이다. 쉽게 말해 모델이 답변하기 전에 얼마나 깊게 생각할지를 조절하는 장치다. 사람에게도 비슷한 일이 있다. "서울의 수도는?" 같은 질문에는 즉시 답한다. 반면 "세 명의 엔지니어를 두 팀으로 나누되, 각자의 일정과 전문성을 고려해 4주짜리 개발 계획을 짜라"는 요청에는 잠깐 멈춰 생각한다. LLM에서도 이 멈춤이 비용과 지연시간으로 나타난다.

사고 예산을 높이면 모델이 복잡한 문제를 더 신중히 풀 가능성이 커진다. 수학, 알고리즘, 복잡한 코드 분석, 다단계 계획, 모호한 정책 해석 같은 작업에서는 도움이 된다. 그러나 단순 분류, 짧은 번역, FAQ 답변, 인사말 생성에는 오히려 낭비가 될 수 있다.

Google은 2.5 Flash-Lite를 소개하면서 이 모델이 2.5 계열의 사고 모델이지만 비용과 속도에 최적화되어 사고가 기본적으로 꺼져 있으며, API 파라미터로 사고 예산을 동적으로 제어할 수 있다고 설명했다.¹ 이 문장은 실무적으로 매우 중요하다. 모델이 "생각할 수 있다"는 것과 "항상 생각하게 해야 한다"는 것은 다르다.

고객지원 시스템을 예로 들어 보자. 모든 문의에 깊은 사고를 켜면 비용과 지연시간이 올라간다. 하지만 실제 문의의 대부분은 배송 상태, 비밀번호 초기화, 영수증 발급처럼 정형적이다. 이런 요청은 Flash-Lite나 Flash에서 낮은 사고 예산으로 처리한다. "이미 환불된 주문의 부분 교환과 쿠폰 재발급이 충돌한다"처럼 규칙이 엮인 예외 상황만 Pro 또는 높은 사고 예산으로 올린다.

이것을 업무 복잡도에 따라 나누면 다음처럼 설계할 수 있다.

사고 예산은 "정확도를 높이는 마법 버튼"이 아니다. 예산을 늘린다고 항상 더 좋은 답이 나오지는 않는다. 애매한 프롬프트, 잘못된 문서, 불명확한 출력 형식, 모순된 시스템 지시는 사고 예산으로 해결되지 않는다. 그래서 사고 예산을 올리기 전에 먼저 해야 할 일은 프롬프트를 명확히 하고, 필요한 근거를 넣고, 출력 형식을 제한하는 것이다. 즉, 생각을 많이 시키기 전에 무엇을 생각해야 하는지부터 정해야 한다.

지연시간은 평균이 아니라 p95로 본다

개발 중에는 응답이 빠른 것처럼 보였는데, 출시 후 사용자가 "느리다"고 말하는 일이 많다. 이유는 평균 지연시간만 봤기 때문이다. 사용자는 평균을 경험하지 않는다. 사용자는 자기 요청 하나를 경험한다. 100명 중 95번째로 느린 요청, 즉 p95 지연시간이 나쁘면 서비스는 느리게 느껴진다.

지연시간을 볼 때는 최소한 세 지표를 나눠야 한다.

스트리밍 응답은 TTFT를 줄이는 데 큰 도움이 된다. 전체 답변이 5초 걸리더라도 0.7초 안에 첫 문장이 보이면 사용자는 시스템이 살아 있다고 느낀다. 반대로 3초 동안 아무것도 보이지 않다가 완성된 답이 한 번에 나타나면, 사용자는 멈췄다고 생각할 수 있다.

음성 인터페이스에서는 이 차이가 더 극단적이다. 한 개발자가 Gemini 모델들을 대상으로 음성 AI 지연시간을 측정한 비공식 벤치마크에서는 2.5 Flash-Lite가 가장 빠른 TTFT를 보였고, 2.5 Flash의 기본 사고 설정은 훨씬 느리게 나타났으며, 사고를 최소화하면 지연시간이 크게 줄었다고 보고했다.⁵ 단일 벤치마크를 절대값으로 받아들이면 안 되지만, 교훈은 분명하다. 실시간 UX에서는 모델 이름보다 첫 토큰 시간, 사고 설정, 출력 길이, 네트워크 위치가 더 중요하다.

실무에서는 다음처럼 지연시간 목표를 먼저 정한다.

모든 기능을 실시간으로 만들 필요는 없다. 사용자가 기다릴 이유가 있는 작업은 비동기로 돌리는 편이 낫다. "계약서 위험 분석 중입니다. 완료되면 알림을 보내겠습니다"라는 UX가, 40초 동안 회전 아이콘을 보여 주는 UX보다 더 정직하고 안정적이다.

비용을 계산하는 가장 작은 예제

이제 간단한 계산을 해 보자. 실제 가격은 시점과 플랫폼, 지역, 모델 버전, 사용량 등급에 따라 달라질 수 있으므로 배포 전 공식 가격 페이지를 다시 확인해야 한다.⁶ 여기서는 계산 방법을 익히기 위한 예제라고 생각하자.

가상의 고객지원 챗봇이 하루 50,000건의 요청을 처리한다고 하자. 요청당 평균 입력은 1,200토큰, 출력은 250토큰이다. 한 달을 30일로 잡으면 월 요청 수는 1,500,000건이다.

월 입력 토큰 = 1,500,000 × 1,200 = 1,800,000,000토큰
월 출력 토큰 = 1,500,000 × 250 = 375,000,000토큰

만약 이 모든 요청을 Pro로 처리하면 비용은 빠르게 커진다. 반대로 모든 요청을 Flash-Lite로 처리하면 비용은 낮지만 복잡한 예외 문의의 품질이 부족할 수 있다. 그래서 보통은 혼합한다.

예를 들어 전체 문의의 80%는 Flash-Lite로 라우팅하고, 18%는 Flash, 2%는 Pro로 올린다고 하자. 이때 비용은 다음 단계로 계산한다.

Flash-Lite 요청 = 1,500,000 × 80% = 1,200,000건
Flash 요청      = 1,500,000 × 18% = 270,000건
Pro 요청        = 1,500,000 × 2%  = 30,000건

각 경로의 입력·출력 토큰을 따로 구한 뒤 모델별 단가를 곱하면 된다. 이 계산에서 중요한 것은 단가 자체보다 구조다. 요청 2%만 Pro로 올려도 어려운 문제는 챙기면서 전체 비용은 크게 낮출 수 있다. 반대로 라우팅 없이 모든 요청을 Pro에 보내면 "쉬운 질문을 비싼 모델이 푸는" 구조가 된다.

대량 분류 작업은 더 극단적이다. 예를 들어 상품 리뷰 1,000만 건을 긍정·부정·중립으로 분류한다고 하자. 입력 150토큰, 출력 5토큰이면 출력 비용은 거의 작고 입력 비용이 핵심이다. 이런 작업은 Flash-Lite와 Batch 처리의 후보가 된다. 사용자가 실시간으로 기다리지 않기 때문이다. 반면 "분류 기준을 새로 설계하고, 애매한 리뷰의 판단 근거를 설명하라"는 요청은 Flash나 Pro가 필요할 수 있다.

이처럼 비용 설계의 첫 번째 질문은 "어떤 모델이 좋은가?"가 아니다. "이 요청은 몇 건이고, 입력과 출력은 얼마나 길며, 사용자는 기다리고 있는가?"가 먼저다.

하이브리드 모델 라우팅 패턴

가장 실용적인 모델 선택 전략은 하이브리드 라우팅이다. 하나의 요청이 들어왔을 때 곧바로 Pro로 보내지 않고, 요청의 난도와 위험도를 판단해 모델을 고른다.

기본 구조는 다음과 같다.

이 패턴의 장점은 비용과 품질을 동시에 관리할 수 있다는 점이다. 쉬운 요청은 빠르고 싸게 처리한다. 어려운 요청은 상위 모델로 올린다. 모델이 자신 없어 하거나 출력 검증에 실패하면 다시 올린다.

라우터는 처음부터 거창한 머신러닝 모델일 필요가 없다. 초기에는 규칙 기반으로 충분하다. 입력 길이, 키워드, 사용자 등급, 업무 유형, 예상 손실을 기준으로 분기할 수 있다.

if 입력_토큰 > 100_000:
    model = "gemini-2.5-pro"
elif 업무유형 in ["분류", "태깅", "짧은 번역"]:
    model = "gemini-2.5-flash-lite"
elif 위험도 == "높음":
    model = "gemini-2.5-pro"
else:
    model = "gemini-2.5-flash"

조금 더 발전하면 1차 모델이 스스로 난도를 평가하게 할 수 있다. 예를 들어 Flash-Lite에 "이 요청은 단순 FAQ인가, 정책 판단인가, 전문가 검토가 필요한가?"만 JSON으로 분류하게 한다. 그 결과에 따라 본 요청을 Flash나 Pro에 보낸다. 이때 1차 분류 출력은 매우 짧아야 한다. 라우터가 비용을 줄이려고 만든 장치인데, 라우터 자체가 장문 추론을 하면 의미가 없다.

하이브리드 라우팅의 핵심은 실패 경로를 설계하는 것이다. 낮은 모델이 잘못 답하면 상위 모델로 올릴 수 있어야 한다. 구조화 출력 검증에 실패하면 재요청하거나 폴백해야 한다. 안전 필터나 할당량 오류가 발생하면 사용자에게 정직하게 알려야 한다. 모델 선택은 성공 경로가 아니라 실패 경로에서 진짜 실력이 드러난다.

출력 토큰 제한은 가장 쉬운 비용 절감 장치다

비용을 줄이기 위해 가장 먼저 할 일은 모델을 바꾸는 것이 아니다. 출력 길이를 제한하는 것이다. 많은 서비스가 모델에게 "자세히 답하라"고 해 놓고, 나중에 비용이 높다고 놀란다. 출력 토큰은 대개 비싸고, 전체 응답 시간에도 직접 영향을 준다.

고객지원 챗봇이라면 답변을 3문장으로 제한할 수 있다. 분류 작업이라면 JSON만 출력하게 한다. 요약 작업이라면 "핵심 5개, 각 1문장"처럼 구조를 고정한다. 코드 생성 작업이라면 "변경된 함수만 출력"하거나 "diff 형식으로 출력"하게 할 수 있다.

나쁜 지시와 좋은 지시는 비용에서 차이를 만든다.

나쁜 지시:
다음 문서를 자세히 요약해 주세요.

좋은 지시:
다음 문서를 5개의 핵심 항목으로 요약하세요.
각 항목은 120자 이내로 작성하세요.
마지막에 위험 신호가 있으면 최대 3개만 JSON 배열로 출력하세요.

두 번째 지시는 품질도 더 안정적이고 비용도 예측 가능하다. 특히 p95 지연시간을 관리하려면 출력 길이 제한이 필수다. 입력이 길어지는 것은 사용자의 문서 때문이라 어느 정도 피할 수 없지만, 출력이 끝없이 길어지는 것은 대부분 설계 문제다.

코드 리뷰에서도 같은 원리가 적용된다. 전체 파일을 다시 출력하게 하지 말고, 문제 위치와 수정 diff만 요청한다. 보고서 생성에서도 "전체 보고서"와 "요약 카드"를 분리한다. 사용자는 처음부터 20쪽짜리 보고서를 원하지 않을 때가 많다. 먼저 짧은 요약을 보여 주고, 필요할 때 상세 보고서를 비동기로 생성하면 비용과 UX가 모두 좋아진다.

요청 분할과 긴 컨텍스트의 균형

Gemini의 긴 컨텍스트는 강력하다. 1M 토큰 규모의 입력은 계약서 묶음, 긴 회의록, 코드베이스, 동영상·오디오 분석 같은 작업을 단순하게 만든다. 그러나 긴 컨텍스트가 항상 최선은 아니다. 입력이 길어질수록 비용과 지연시간이 늘고, 모델이 모든 부분을 똑같이 깊게 추론한다고 보장하기도 어렵다.

긴 문서 작업에는 세 가지 방식이 있다.

예를 들어 500쪽짜리 정책 문서를 "전체 요약"하려면 분할 요약 후 통합하는 방식이 더 저렴하고 빠를 수 있다. 반면 "4장과 17장의 규정이 서로 충돌하는가?"처럼 문서 전체 관계를 봐야 하는 질문은 긴 컨텍스트가 유리하다.

코드베이스 분석도 비슷하다. "이 저장소의 전체 아키텍처를 설명하라"는 요청에는 긴 컨텍스트가 도움이 된다. 그러나 "이번 PR에서 바뀐 부분을 리뷰하라"는 요청에 전체 저장소를 매번 넣는 것은 낭비다. 이때는 변경 diff, 관련 파일, 테스트 결과만 넣고, 공통 아키텍처 설명은 캐싱하는 편이 낫다.

요청 분할의 좋은 규칙은 "모델이 지금 답하는 데 필요한 최소 맥락만 넣는다"이다. 사람에게도 전체 회사 문서함을 던져 주고 질문하지 않는다. 필요한 문서 몇 개를 펼쳐 놓고 묻는다. LLM에도 같은 예의를 지켜야 한다.

캐싱은 반복 맥락에 붙이는 할인 쿠폰이다

프롬프트에는 반복되는 부분이 많다. 시스템 지시, 회사 정책, 상품 카탈로그 요약, 코드베이스 개요, 문서 원문, 출력 스키마, 예시 몇 개가 그렇다. 같은 큰 맥락을 매 요청마다 다시 보내면 입력 비용과 지연시간이 낭비된다. 이때 캐싱이 필요하다.

캐싱은 자주 쓰는 입력 맥락을 저장해 두고, 이후 요청에서 다시 활용하는 방식이다. Google의 가격 문서와 관련 자료는 Gemini API에서 캐시 입력과 Batch 같은 비용 최적화 수단을 제공한다고 안내한다.⁶ 캐싱의 경제성은 단순하다. 큰 문서를 한 번 올리고 여러 번 질문할수록 유리하다. 반대로 한 번만 물어볼 문서라면 캐시 관리 비용과 구현 복잡도가 이득보다 클 수 있다.

캐싱을 적용하기 좋은 후보는 다음과 같다.

• 사내 규정집이나 제품 매뉴얼처럼 여러 사용자가 반복해서 묻는 문서.

• 코드 리뷰 에이전트가 매번 참고하는 저장소 구조 설명.

• 고객지원 챗봇의 정책 설명, 말투 지침, 응답 금지 규칙.

• RAG 답변 생성에서 반복적으로 들어가는 긴 시스템 프롬프트.

캐싱을 설계할 때는 TTL, 즉 캐시가 살아 있는 시간을 정해야 한다. 문서가 자주 바뀌면 오래 캐싱하면 안 된다. 법률·가격·재고처럼 최신성이 중요한 정보는 캐시 무효화 전략이 필요하다. "비용을 줄이려고 오래 캐싱했더니 오래된 정책으로 답했다"는 사고는 충분히 일어날 수 있다.

캐싱은 비용 최적화 기능이지만, 동시에 데이터 관리 기능이다. 무엇을 캐싱했는지, 언제 만들었는지, 어떤 버전의 문서인지, 언제 폐기되는지를 추적해야 한다. 특히 개인정보나 민감정보가 들어간 문서는 15장에서 다룰 보안·프라이버시 원칙에 맞춰 별도 정책을 세워야 한다.

폴백 모델은 장애 대응이 아니라 제품 정책이다

운영 환경에서는 모델 호출이 항상 성공하지 않는다. 할당량 제한, 일시적 503, 네트워크 문제, 안전 필터 차단, 출력 스키마 불일치, 응답 지연이 발생한다. 이때 폴백 모델이 필요하다. 폴백은 단순히 "안 되면 다른 모델 호출"이 아니다. 사용자에게 어떤 품질과 속도를 보장할지 정하는 제품 정책이다.

예를 들어 실시간 챗봇에서 Pro가 느리거나 실패하면 Flash로 낮춰 짧은 답을 먼저 줄 수 있다. 반대로 Flash가 구조화 출력 검증에 실패하면 Pro로 올려 다시 시도할 수 있다. 대량 배치 작업에서 Flash-Lite가 일부 항목을 애매하다고 표시하면 그 항목만 Flash나 Pro로 재처리한다.

폴백 방향은 두 가지다.

상향 폴백은 정확도를 지킨다. 하향 폴백은 서비스 가용성을 지킨다. 둘 다 필요하다. 다만 하향 폴백에서는 사용자에게 과도한 확신을 주면 안 된다. "정확한 분석을 완료하지 못했습니다. 우선 확인 가능한 범위에서 답변드립니다"처럼 답변의 신뢰 수준을 표시해야 한다.

폴백을 구현할 때는 재시도 폭풍을 조심해야 한다. 실패한 요청을 같은 큰 컨텍스트로 즉시 여러 번 재시도하면 비용이 몇 배로 늘어난다. 재시도는 오류 종류에 따라 달라야 한다. 429나 503처럼 일시적 오류는 지수 백오프를 적용하고, 400처럼 요청 자체가 잘못된 오류는 재시도하지 말고 입력을 고쳐야 한다. 이 내용은 16장에서 에러 코드와 함께 더 자세히 다룬다.

제품별 모델 선택 설계 예시

이제 실제 제품에 모델을 배치해 보자. 첫 번째는 문서 분석 서비스다. 사용자는 PDF 계약서를 업로드하고 "위험 조항을 찾아 달라"고 요청한다. 여기서 모든 단계에 Pro를 쓰면 단순 추출까지 비싸진다. 더 나은 구조는 단계별 모델 분리다.

Flash-Lite는 조항 유형을 태깅한다. Flash는 섹션별 요약을 만든다. Pro는 정말 중요한 위험 판단에만 투입된다. 마지막 사용자 설명은 다시 Flash로 정리할 수 있다. 이렇게 하면 Pro의 장점을 가장 가치 있는 구간에 집중시킬 수 있다.

두 번째는 고객지원 챗봇이다. 여기서는 속도와 비용이 매우 중요하다.

세 번째는 코드 생성 도구다. 개발자는 응답 속도도 중요하지만, 잘못된 코드가 들어가면 손실이 크다. 따라서 작업 종류를 나눠야 한다. 함수 주석 생성, 테스트 케이스 초안, 간단한 정규식 설명은 Flash로 충분할 수 있다. 다중 파일 버그 분석, 아키텍처 변경 제안, 보안 취약점 검토는 Pro가 낫다. 코드 리뷰에서는 전체 파일보다 diff를 우선 넣고, 필요할 때 관련 파일만 추가한다.

네 번째는 실시간 음성 UX다. 여기서는 첫 반응이 생명이다. 사용자가 "예약 가능한 시간 알려줘"라고 말했는데 3초 동안 침묵하면, 모델이 아무리 좋은 답을 하더라도 경험은 이미 망가진다. 이 경우 Flash-Lite로 즉시 "확인해 볼게요" 같은 짧은 응답을 생성하고, 뒤에서 도구 호출이나 Flash/Pro 분석을 이어가는 구조가 좋다. 즉, 빠른 모델은 대화의 리듬을 지키고, 강한 모델은 어려운 판단을 맡는다.

p95와 월 비용을 함께 관리하는 운영 대시보드

모델 선택은 한 번 정하고 끝나는 일이 아니다. 출시 후에는 실제 로그를 보며 계속 조정해야 한다. 운영 대시보드에는 최소한 다음 지표가 있어야 한다.

비용만 보면 품질이 무너질 수 있고, 품질만 보면 비용이 폭증할 수 있다. 그래서 모델 라우팅의 목표 함수는 하나가 아니다. "월 비용 500만 원 이하, 고객지원 자동 해결률 70% 이상, p95 3초 이하"처럼 동시에 잡아야 한다.

처음부터 완벽한 라우터를 만들 필요는 없다. 2주 정도 실제 트래픽을 수집하면 패턴이 보인다. 어떤 요청이 Pro로 갈 필요가 없었는지, 어떤 Flash-Lite 답변이 불만족을 만들었는지, 어떤 프롬프트가 출력 토큰을 과도하게 쓰는지 드러난다. 그때 모델 분기 규칙을 조정한다.

좋은 팀은 모델을 바꾸기 전에 로그를 본다. 더 좋은 팀은 로그를 보기 쉽게 남긴다.

모델 선택 워크시트

새 기능을 설계할 때 다음 질문에 답하면 모델 선택이 훨씬 쉬워진다.

이 워크시트를 채우면 "일단 Pro로 해 보자"는 말이 줄어든다. 대신 "초기 응답은 Flash, 예외만 Pro, 분류는 Flash-Lite, 긴 문서는 캐싱"처럼 구체적인 설계가 나온다.

이번 장의 결론

Gemini 모델 선택의 핵심은 가장 강한 모델을 찾는 것이 아니다. 가장 적절한 경로를 찾는 것이다. Pro는 어려운 추론과 고위험 판단에 쓰고, Flash는 대부분의 사용자-facing 경로에서 균형점으로 사용하며, Flash-Lite는 대량·저지연·저비용 작업에 배치한다. 여기에 사고 예산, 출력 제한, 스트리밍, 요청 분할, 캐싱, 폴백을 더하면 비용과 사용자 경험을 함께 관리할 수 있다.

이 장의 실무 규칙은 다음처럼 요약할 수 있다.

• 기본값은 Flash에서 시작하고, 병목에 따라 Flash-Lite 또는 Pro로 분기한다.

• Pro는 "좋아서" 쓰는 것이 아니라 "틀리면 비싸서" 쓴다.

• Flash-Lite는 "약한 모델"이 아니라 "고빈도·초저지연 경로의 모델"이다.

• 출력 토큰 제한은 가장 쉬운 비용 절감 장치다.

• 긴 컨텍스트는 가능하다고 매번 쓰는 것이 아니라, 필요할 때만 쓴다.

• p95 지연시간과 월 비용을 함께 봐야 제품이 산다.

다음 장에서는 이렇게 고른 모델을 제대로 움직이게 하는 프롬프트 설계와 구조화 출력으로 넘어간다. 모델이 아무리 좋아도 지시가 흐릿하면 결과는 흔들린다. 이제 모델 선택이라는 엔진을 골랐으니, 다음에는 그 엔진에 어떤 운전대를 달지 살펴볼 차례다.

참고

¹Gemini 2.5 thinking model updates

²Gemini 2.5 technical report

³Gemini 2.5 Flash-Lite model documentation

⁴Vertex AI Gemini 2.5 Flash-Lite model card

⁵Gemini voice AI latency benchmark

⁶Gemini API pricing