같은 날, swyx와 emollick이 모델 라우팅에 관한 통념 두 가지를 동시에 반박했다.

swyx(@swyx)는 Fusion API를 소개하며 이렇게 말했다. 컴파운드 모델은 단일 프론티어 모델과 같은 성능을 약 절반 비용으로 낸다. “단일 모델 지배”가 아니라 “모델 다양성 + 라우팅”이 맞는 프레임이라고.

emollick(@emollick)은 반대 방향에서 통념을 깼다. 비핵심 업무라도 큰 모델이 보완재로 작동하는 경우가 있다는 것. “작은 모델은 싸다”는 단순 공식이 깨진 자리에 “어떤 작업에 어떤 모델이 맞는가”라는 설계 문제가 들어선다.

두 신호가 가리키는 방향은 같다. 라우팅은 “제일 싼 모델”을 고르는 작업이 아니다.

통념 1: 단일 프론티어 모델이 답이다

에이전트를 설계할 때 자주 듣는 조언은 이렇다. “GPT-5.5를 쓰세요, 아니면 Claude Opus 4.8을 쓰세요.” 최신 프론티어 모델 하나를 선택하고 거기에 모든 작업을 맡기는 방식이다.

swyx가 소개한 Fusion API 데이터는 이 통념을 정면으로 반박한다. 여러 모델을 작업 유형에 따라 조합하는 컴파운드 구성이 프론티어 단일 모델과 동등한 품질을 절반 비용에 낸다는 것이다. 단일 모델 지배가 아니라 모델 다양성과 라우팅의 결합이 실제로 더 효율적인 선택지라는 외부 데이터가 나온 셈이다.

이 신호가 중요한 이유는 비용 절감보다 더 깊은 곳에 있다. 단일 모델 종속이 가진 공급 리스크를 드러내기 때문이다. 지난 6월 13일, 미국 수출통제로 Fable 5의 외국인 접근이 하루 만에 전면 차단됐다. 모델 성능은 그대로였지만 ‘쓸 수 있느냐’가 0이 됐다. 단일 벤더에 의존하던 팀들이 가장 먼저 멈췄다.

단일 모델 전략은 비용 문제이기 전에 공급 연속성 문제다. 컴파운드 구성이 비용 효율만의 이유로 주목받는 게 아닌 이유가 여기 있다.

통념 2: 작은 모델은 싸다

두 번째 통념은 더 뿌리 깊다. “간단한 작업은 작은 모델, 복잡한 작업은 큰 모델.” 얼핏 합리적으로 들린다.

emollick의 반박은 이 구도를 흔든다. 비핵심 업무라도 큰 모델이 보완재로 작동하는 경우가 있다는 것이다. 작업의 복잡도만이 아니라, 오류 비용과 맥락 이해 깊이가 함께 라우팅 변수에 들어가야 한다는 말이다.

Claude Opus 4.8의 운영 데이터가 이를 보완한다. fast mode(약 2.5배 빠르고 3배 저렴)와 xhigh(더 정확하지만 느린) 사이의 선택은 단순히 “어떤 작업이냐”의 문제가 아니다. 이 작업에서 오류가 downstream에 미치는 영향이 얼마인가, 다음 단계 에이전트에 어떤 맥락이 넘어가는가까지 고려돼야 한다. 코딩은 xhigh, 요약·초안·검토는 fast mode라는 경험 규칙이 나온 배경이다.

다시 말해, 같은 모델 안에서도 reasoning tier 선택이 라우팅 변수다. 라우팅은 모델 간 선택에서 끝나지 않는다.

라우팅의 실제 설계 축 세 가지

두 통념이 무너지고 나면, 라우팅의 실제 설계 변수가 드러난다.

조합(Composition): 작업 유형별로 다른 모델을 묶는 설계. 프론티어 모델을 오케스트레이터로 쓰고, 반복 실행 단계는 빠른 모델에 위임하는 계층형 구성이 비용과 성능을 동시에 잡는 첫 번째 축이다. Fusion API 데이터가 보여주듯, 이 조합이 단일 프론티어 대비 절반 비용에 같은 성능을 낼 수 있다.

Effort 제어: 같은 모델이라도 reasoning level을 작업 단위로 조정한다. 초안 생성과 코드 리팩터링에 같은 effort를 쓰는 것은 비효율이다. “한 모델 = 한 비용”이 아니라 “한 모델 × 다중 reasoning tier”의 매트릭스로 설계해야 실제 비용이 예측 가능해진다.

공급 분산(Supply Diversification): 단일 벤더 종속을 줄이고, 오픈웨이트 모델을 워크플로우 일부에 통합하는 전략. 코히어(Cohere)는 H100 2장으로 에이전트 워크플로와 RAG를 자체 인프라에서 운영하는 사례를 보여줬다. LangSmith 데이터에서도 오픈웨이트 모델이 코딩 워크플로에서 빠르게 채택되는 추세다. 수출통제나 약관 변경이 예고 없이 오는 환경에서, 공급 분산 옵션을 설계해두지 않으면 대응 수단이 없어진다.

이 세 축을 설계하지 않으면 비용이 예상보다 빠르게 오르거나, 공급 중단 상황에서 팀 전체가 멈춘다.

PM이 라우팅 설계에서 결정해야 할 것

라우팅 설계는 엔지니어만의 문제가 아니다. PM이 결정해야 할 영역이 분명히 있다.

첫 번째는 오류 비용의 정의다. 어떤 작업에서 AI 오류가 downstream에 미치는 영향이 큰가를 PM이 판단해야 큰 모델을 써야 할 구간이 결정된다. 이 판단 없이 “작은 모델로 비용 줄여”라고 지시하면, 잘못된 라우팅이 품질 문제로 되돌아온다.

두 번째는 공급 리스크 허용 범위의 판단이다. 단일 벤더 종속이 사업에 허용 불가한 리스크인지를 결정하는 것은 PM의 역할이다. Fable 5 차단처럼 수출통제나 약관 변경은 예고 없이 온다. 어느 구간에 오픈웨이트를 병행 운영할 것인지를 미리 설계해두지 않으면 대응이 늦어진다.

세 번째는 라우팅 기준의 문서화다. 어떤 작업 유형에 어떤 모델·effort 조합을 쓰는지가 팀 전체의 공유 기준으로 정착돼야 한다. 이것이 없으면 개발자마다 다른 판단을 하게 되고, 비용 예측과 품질 일관성 모두 무너진다.

라우팅은 선택이 아니라 아키텍처다

swyx와 emollick이 같은 날 보낸 신호의 본질은 하나다. 라우팅을 “어떤 모델이 요즘 1등인가”로 결정하는 방식은 이미 한계에 부딪혔다.

컴파운드 모델 조합이 절반 비용에 같은 성능을 낸다는 것, 비핵심 업무에도 큰 모델이 보완재가 된다는 것, Opus 4.8의 fast/xhigh 분기가 한 모델 안에서도 라우팅이 작동한다는 것 — 세 신호 모두 같은 방향을 가리킨다.

라우팅은 모델 선택이 아니라 조합·effort·공급분산을 동시에 설계하는 아키텍처 결정이다.

지금 당신의 에이전트 스택에서 이 세 축이 명시적으로 설계돼 있습니까?