Gemini 3.1 Pro의 입력 토큰 단가는 $2/백만이다. GPT-5.4 Pro와 같은 멀티모달 벤치마크에서 경쟁하면서 가격은 그 3분의 2다.

이 수치 하나가 모델 선택 논의 전체를 바꿔놓고 있다.

2026년 상반기까지 AI 팀의 모델 선택 기준은 대체로 벤치마크 순위였다. SWE-bench, HumanEval, MMLU — 1위 모델을 고르면 됐다. 그런데 지금은 같은 벤치마크 안에서도 4개 모델이 과제마다 다른 1위를 낸다. UI 생성 과제에서는 Kimi K2.5가 98점이었고, 도구 호출 과제에서는 Step 3.5 Flash가 동급 성능을 50배 저렴한 비용으로 냈다. “단일 최고 모델”이라는 개념이 실측에서 무너지고 있다.

Anthropic이 이미 선택한 방법

Anthropic은 이 구조를 내부 운영 전략으로 공식화했다. Advisor 전략이라 불리는 이 방식은 Claude Opus 4.7을 복잡한 판단과 멀티스텝 추론에만 배치하고, 반복 실행과 배치 처리는 저비용 모델에 위임한다. 두 모델이 같은 파이프라인 안에서 다른 임무를 맡는다.

결과적으로 전체 API 비용은 낮아지고 품질은 유지된다. 이것은 모델 하나를 더 잘 쓰는 기술이 아니라, 작업을 쪼개는 설계 결정이다.

SambaNova SN40과 Nvidia B200의 하이브리드 추론 사례도 같은 방향을 가리킨다. 프리필 단계는 B200에, 디코드 단계는 SN40에 분산해 처리 속도를 2배 높였다. 하드웨어 라우팅이 단계별로 분리된 것이다. Google TurboQuant는 KV-Cache 압축으로 추론 메모리를 6배 절감하면서 동일 출력 품질을 유지했다. 이 두 사례의 공통 메시지는 하나다 — 비용 구조는 모델 선택 이전, 아키텍처 선택 단계에서 결정된다.

라우팅 정책을 설계할 때 먼저 정해야 하는 것

팀 단위로 라우팅 정책을 만든다면 세 가지를 먼저 명문화해야 한다.

첫째, 작업 유형 분류다. 복잡한 판단이 필요한 호출과 반복 실행 호출을 구분하지 않으면 고가 모델이 단순 작업에 지속적으로 투입된다.

둘째, 호출당 허용 단가 상한이다. 이 기준이 없으면 모델 선택이 개발자 개인의 판단에 맡겨지고, 같은 팀 안에서도 선택 기준이 제각각이 된다.

셋째, 측정 방법론이다. 동일 하네스에서 같은 작업을 각 모델로 실행하고 토큰 수와 응답 품질을 나란히 기록하는 실측이 없으면 벤치마크 순위가 대체 기준으로 남는다. skillassay가 동일 하네스, 동일 토크나이저 측정을 강조하는 이유다. 프롬프트 하나에 모델을 교체해 실행하면 내부 비교 기준이 생긴다.

가장 피해야 할 함정

라우팅 정책에서 한 가지 실수는 모델 이름을 고정값으로 쓰는 것이다. Gemini 3.7 Flash가 출시 3주 만에 상위 버전으로 교체된 사례처럼, 특정 모델 이름이 코드나 정책 문서에 하드코딩돼 있으면 교체 비용이 전체 시스템으로 전파된다.

정책은 모델 이름이 아니라 조건으로 작성해야 한다. “추론 집중 작업에는 비용 대비 SWE-bench 점수 상위 1개를, 반복 실행에는 동일 품질 기준 최저가를 선택한다”처럼 조건 문장으로 쓰면, 모델이 교체돼도 정책은 유지된다.

“1달러당 성능”은 단일 수치가 아니다. 같은 작업을 다른 모델로 실행했을 때 비용 차이와 품질 차이를 함께 기록한 내부 데이터다. 이 데이터를 만들어가는 팀과 벤치마크 순위를 참고하는 팀의 라우팅 품질은 분기가 지날수록 벌어진다.

지금 여러분 팀의 라우팅 정책에 호출당 허용 단가 기준이 명시돼 있습니까?