모델 선택을 벤치마크 순위로 하고 있다면, 이미 틀린 방법론을 쓰고 있는 것입니다.

2026년 상반기 AI 모델 시장을 한 문장으로 요약하면 이렇습니다. 경쟁의 축이 “더 똑똑하게”에서 “1달러로 얼마나 똑똑하게”로 이동하고 있습니다. Gemini 3.1 Pro는 16개 주요 벤치마크 중 13개 1위를 기록하면서 가격은 $2/M 토큰 — GPT-5.4 대비 3분의 2 수준입니다. Google TurboQuant는 KV-Cache 압축으로 같은 품질을 6분의 1 비용으로 달성했습니다. DeepSeek V4 Flash는 오픈소스로 400K 컨텍스트와 추론(reasoning) 모드를 동시에 지원합니다.

이 세 신호가 같은 방향을 가리키고 있습니다. 모델 성능 경쟁이 포화되면서 비용 효율이 실질 차별화 축으로 올라오고 있다는 것입니다.

모델 선택의 기준이 바뀌고 있다

모델 성능 경쟁이 치열해질수록 프론티어 간 격차는 좁아집니다. Claude Opus 4.7은 SWE-bench Verified에서 87.6%를 기록하며 에이전트 코딩 벤치마크를 리드하고 있고, GPT-5.5는 “더 정직한 답변”이라는 차별화 축으로 이동했습니다. 두 모델 모두 뛰어납니다. 하지만 이 사실 자체가 역설을 만들어냅니다.

최고 모델 간 성능 차이가 줄어들면, 팀이 실제로 내려야 할 결정은 “어느 모델이 더 좋은가”가 아니라 “이 작업에 이 비용이 정당한가”로 바뀝니다.

에이전트 시스템에서 모델은 전구가 아니라 연료입니다. 전구는 교체 주기가 길지만 연료는 매 호출마다 소비됩니다. 하루 10만 건의 에이전트 호출이 발생하는 시스템에서 1달러당 처리량 차이는 운영 비용 수십 배의 차이로 직결됩니다. “이 모델이 가장 좋다”는 판단은 비용 변수가 빠진 불완전한 판단입니다.

가장 설득력 있는 증거는 Anthropic 자신에게서 나옵니다. Anthropic의 Advisor 전략을 보면, Claude Opus 4.7은 복잡한 판단이 필요한 케이스에만 투입하고 일반 실행은 저비용 모델이 담당합니다. 가장 비싼 모델을 만드는 회사가 스스로 “항상 최고 모델을 쓰지 말라”고 자사 제품 운영 전략에 못을 박고 있는 것입니다.

이것이 모델 라우팅입니다.

라우팅은 기술이 아니라 설계다

라우팅이란 작업 유형에 따라 적절한 모델을 보내는 운영 전략입니다. 쉽게 들리지만, 대부분의 팀은 이것을 하지 않습니다.

이유는 단순합니다. 모델 도입 초기에는 “일단 제일 좋은 것으로”가 가장 빠른 의사결정입니다. 파일럿 단계에서는 비용이 작아서 문제가 안 됩니다. 하지만 스케일이 붙기 시작하면 — 사용자가 늘고, 에이전트 호출이 누적되고, 운영팀이 청구서를 보기 시작하면 — 그제야 라우팅의 부재가 비용 폭탄으로 드러납니다.

라우팅은 기술 문제가 아닙니다. 작업을 분류하는 설계 결정입니다. 어떤 작업이 고성능 모델이 필요하고, 어떤 작업은 저비용 모델로 충분한지를 판단하는 것 — 이것은 모델 스펙을 읽는 능력이 아니라 자기 제품의 워크로드를 이해하는 능력입니다. 그래서 이것이 PM의 레버리지입니다.

3축 라우팅 설계

실전에서 라우팅 설계는 세 가지 축에서 시작합니다.

1축: 추론 복잡도

가장 기본적이면서 가장 큰 절감 효과를 냅니다.

에이전트 시스템의 호출을 분류해보면, 실제로 복잡한 멀티스텝 추론이 필요한 작업은 전체의 1020%에 불과합니다. 나머지는 분류, 요약, 정보 추출, 반복적인 도구 호출입니다. 이 8090%에 Claude Opus 4.7이나 GPT-5.5 같은 프론티어 모델을 쓰는 것은 스포츠카로 출퇴근 배달을 하는 것과 같습니다.

Step 3.5 Flash는 도구 호출(tool calling) 벤치마크에서 상위 모델과 대등한 성능을 내면서 비용은 50배 저렴합니다. GLM 5.1은 Opus를 제외한 최고 수준의 에이전틱 벤치마크를 기록하면서 비용은 3분의 1입니다. 에이전트의 반복적 실행 노드에 이런 모델을 라우팅하는 것이 비용 최적화의 첫 번째이자 가장 큰 레버입니다.

2축: 모달리티

텍스트만 처리하는 파이프라인과 이미지·영상이 개입되는 파이프라인은 최적 모델이 다릅니다.

Gemini 3.1 Pro는 텍스트·이미지·오디오·비디오를 단일 모델에서 동시 처리하며 할루시네이션을 30% 줄였습니다. 멀티모달 파이프라인에서 모달리티별로 모델을 쪼개서 라우팅하는 방식보다, Gemini 3.1 Pro 하나로 처리하는 것이 비용-성능 균형에서 현재 유리한 지점입니다. Claude Opus 4.7도 비전 모델로 확장되면서 멀티모달 라우팅에서 Anthropic이 Gemini와 정면 경쟁 구도를 형성하고 있습니다.

모달리티 축의 핵심 질문은 이것입니다. “이 작업이 진짜 멀티모달인가, 아니면 텍스트 파이프라인에 이미지 전처리 하나가 붙은 것인가?” 전처리 하나를 위해 멀티모달 전용 모델 전체를 쓰는 것과, 전처리는 특화 도구에 맡기고 이후 추론만 텍스트 모델로 넘기는 것은 비용이 크게 다릅니다.

3축: 지연(Latency)

모든 노드가 응답 속도를 필요로 하지 않습니다.

Gemini 3.1 Flash Live는 음성·영상 실시간 처리에서 0.5초 이하 응답을 달성하면서 기존 Flash 대비 30% 저렴합니다. 사용자가 직접 대화하는 인터랙티브 노드에서는 응답 지연이 사용자 경험을 결정하므로 저지연 모델이 1차 기준입니다. 하지만 야간 배치, 보고서 생성, 데이터 파이프라인 처리처럼 지연 요구사항이 없는 작업에 실시간 고성능 모델을 쓰고 있다면 불필요한 비용을 지불하는 것입니다.

지연 × 추론 복잡도의 2×2 매트릭스로 작업을 분류하고, 각 사분면에 적합한 모델을 배정하는 것이 라우팅 설계의 시작점입니다.

라우팅의 두 가지 함정

라우팅 설계에는 반대 방향의 두 가지 실수가 있습니다.

함정 1: 모든 작업에 최고 모델

앞서 말한 것입니다. 파일럿에서 스케일로 넘어갈 때 이 함정이 비용 폭탄으로 드러납니다.

함정 2: 구버전 기준으로 저비용 모델 고정

이것이 덜 알려진 함정입니다. Andrej Karpathy는 “AI capability gap = recency × tier of use”라고 정리했습니다. 무료 모델로 1년 전 경험을 기준으로 최신 유료 에이전트 모델의 능력을 판단하는 팀이 많다는 것입니다. 마찬가지로 저비용 모델을 6개월 전 성능 기준으로 “이 작업엔 충분하지 않다”고 고정해둔 라우팅도 존재합니다.

모델 벤치마크는 매 분기 크게 바뀝니다. “저비용 모델로는 안 된다”고 판단했던 작업이 6개월 후에는 그 저비용 모델이 충분히 처리할 수 있게 되었을 수 있습니다. 라우팅 설계는 한 번 결정하고 굳히는 것이 아니라, 분기마다 재검증하는 운영 루틴이 필요합니다.

실전 결과로 보면: 사이냅소프트는 OCR 파이프라인에 벡터 양자화를 적용해 LLM 운영 비용을 70% 절감했습니다. 최신 모델로 교체한 것이 아니라 작업을 재분류하고 라우팅을 최적화한 결과입니다. 모델 성능이 아니라 배치 전략이 비용을 결정했습니다.

PM이 해야 할 것

라우팅 설계는 엔지니어링 문제이기도 하지만, 그 이전에 제품 설계 문제입니다.

어떤 작업이 복잡한 추론이 필요한지, 어디에서 사용자 지연이 경험 품질을 결정하는지, 어떤 파이프라인이 비용 누수의 원인인지 — 이것들은 모델 스펙이 아니라 제품 워크로드 분석에서 나옵니다. PM이 이 분류 없이 엔지니어에게 “좋은 모델 써주세요”만 전달하면, 엔지니어는 가장 안전한 선택인 최고 모델을 전 노드에 씁니다. 합리적인 판단이지만, 비용 최적화의 기회를 처음부터 날리는 것입니다.

100 Agents 프로젝트에서 우리가 실제로 쓰는 기준은 이렇습니다.

복잡한 판단이 필요한 노드(에이전트 간 조율, 멀티스텝 추론, 사용자 대면 핵심 응답)는 Claude Opus 4.7이나 GPT-5.5. 반복 실행 노드(도구 호출, 분류, 요약, 배치 처리)는 GLM 5.1이나 DeepSeek V4 Flash. 멀티모달이 개입되면 Gemini 3.1 Pro. 실시간 음성 인터랙션은 Gemini 3.1 Flash Live.

한 가지 모델이 모든 것을 담당하는 아키텍처에서는 절대 나올 수 없는 비용-성능 조합입니다.

모델 전쟁보다 중요한 것

GPT vs Claude vs Gemini 비교 기사는 계속 나옵니다. 어느 달에는 OpenAI가 앞서고, 그다음 달에는 Anthropic이 앞섭니다. 이 경쟁을 추적하는 것 자체는 의미가 있습니다. 하지만 그것이 자기 시스템의 모델 선택 기준이 되어서는 안 됩니다.

실제 운영에서 중요한 것은 어느 모델이 가장 똑똑한가가 아닙니다. 내 워크로드에서 어떤 작업이 얼마의 비용을 정당화하는가, 그리고 그 경계를 어떻게 설계할 것인가입니다.

1달러당 성능이 새로운 모델 선택 기준입니다. 이 기준을 갖지 않으면 모델 전쟁의 소음 속에서 비용 최적화의 기회를 계속 놓치게 됩니다.

당신의 에이전트 시스템에서 가장 비싼 모델이 처리하는 작업 중, 실제로 그 성능이 필요한 비율은 얼마입니까?