LLM/에이전트 제품의 유닛 이코노믹스에서 가장 빨리 체감되는 레버는 의외로 ‘더 좋은 모델’이 아니라 ‘어떤 모델을 언제 쓰는가(라우팅)’와 ‘토큰 비용을 실시간으로 보이는가’다. 이 두 가지가 잠기면, ARPU를 올리기 전에 먼저 마진이 깎이고(토큰 COGS), 그 결과 CAC 회수기간이 길어져 성장 실험 자체가 느려진다.
dev.to의 WhichModel 사례는 이 문제를 가격 데이터 레이어로 정면 돌파한다. 100개+ 상용 모델의 가격이 주 단위로 바뀌고, 공급사별 입력/출력/캐시 토큰 과금이 제각각인 상황에서, “모델 하나 하드코딩→분기마다 재검토”는 사실상 비용 누수의 자동화다. WhichModel은 4시간마다 가격을 스크래핑·정규화·교차검증하고, 이를 MCP 서버로 노출해 에이전트가 실시간으로 “요구 기능(툴콜/128K/JSON) 만족하는 최저가 모델”을 질의하게 만든다. 핵심은 엑셀을 없애는 게 아니라 ‘의사결정 주기’를 없애는 것.
여기에 멀티에이전트의 비용 구조를 얹으면, 라우팅의 의미가 더 커진다. 또 다른 dev.to 글이 지적하듯 멀티에이전트는 상호 메시징, 메모리 재주입, 평가 루프 때문에 토큰이 선형이 아니라 ‘증폭’된다. 플래너-실행자-비평가 같은 3에이전트 구조에서 한 번의 질의가 몇 배의 토큰 흐름으로 커지는 건 구조적 속성이다. 즉 “고급 모델을 한 번 더”가 아니라 “고급 모델이 불필요하게 여러 번 호출되는 구조”가 진짜 비용 폭탄이다.
그래서 라우팅은 단순한 비용 최적화가 아니라 LTV를 올리는 성장 장치다. 첫째, 동일 가격에서 마진이 개선되면(토큰 COGS↓) 유저당 기여이익이 늘고 LTV가 즉시 상승한다. 둘째, 가격/패키징 실험의 안전지대가 생긴다. 예를 들어 ‘Pro 플랜에 고급 추론 200회 포함’ 같은 번들링을 하더라도, 백엔드에서 80% 트래픽을 저가 모델로 처리하고 20%만 상향 에스컬레이션하면 변동비를 예측 가능하게 고정할 수 있다. 셋째, CAC 회수기간이 단축된다. 광고비를 줄여서가 아니라, 같은 매출에서 원가가 내려가 현금 회수 속도가 빨라지는 방식이다.
실전에서는 “태스크-티어-검증-에스컬레이션”이 한 묶음이어야 한다. Claude Code 에이전트 운영 경험을 공유한 글처럼, 커밋 메시지/체크리스트형 리뷰/문서 갱신 같은 ‘구조화 입력→구조화 출력’은 저가 모델이나 로컬로 내려도 충분하고, 실패 시 상위 모델로 폴백하면 리스크를 통제할 수 있다. 중요한 건 라우팅 규칙이 아니라 ‘검증 게이트’다. 포맷/길이/환각 마커/스키마 준수 같은 자동 검증을 통과하지 못하면 즉시 상향 라우팅하고, 그 사유를 로깅해 어떤 업무가 정말로 비싼 모델을 “필요로 하는지” 데이터로 확정해야 한다.
시사점은 명확하다. (1) 모델 라우팅을 ‘성능 최적화’가 아니라 ‘비용-품질 커브를 설계하는 가격 엔진’으로 보라. (2) 가격 데이터는 스프레드시트가 아니라 운영 데이터여야 한다. WhichModel처럼 실시간 가격/스펙을 에이전트가 질의 가능해야, 가격 변동과 공급사 디프리케이션이 곧바로 라우팅 정책에 반영된다. (3) 멀티에이전트는 토큰 예산을 1급 제약으로 올려야 한다. 반복/비평 루프의 깊이를 제한하고, 컨텍스트를 압축·프루닝하는 ‘토큰 엔지니어링’을 라우팅과 함께 묶지 않으면, 절감분을 구조가 다시 태워버린다.
전망을 한 줄로 요약하면: 앞으로의 LLM 제품 경쟁은 “어떤 모델을 쓰나”가 아니라 “모델을 언제, 얼마나, 어떤 증거로 바꾸나”로 이동한다. 가격이 주 몇 회씩 바뀌는 시장에서, 실시간 가격 추적(WhichModel) + 작업 단위 라우팅(티어링) + 검증 기반 에스컬레이션이 갖춰진 팀은 ‘원가를 줄이는 팀’이 아니라 ‘실험을 더 많이 돌릴 수 있는 팀’이 된다. 그 차이가 결국 LTV와 스케일 구간에서의 생존을 가른다.