AI를 붙였는데 CAC가 내려가기는커녕 올라가는 팀의 공통 실수는 간단합니다. “안전하니까”라는 이유로 모든 요청을 프론티어 모델(GPT-4/Claude Opus)에 태우는 것. dev.to의 멀티모델 라우팅 사례는 이 관성이 얼마나 비싼지 숫자로 보여줍니다. 프로덕션에서 요청의 약 76%는 빠른 오픈웨이트 모델로 돌려도 사용자가 차이를 못 느끼는데, 비용은 80~90%까지 떨어졌습니다(Why Multi-Model LLM Routing Beats Always Using GPT-4, dev.to).
핵심 이슈는 “모델 성능”이 아니라 “단위경제(Unit Economics)”입니다. 토큰 비용은 COGS이고, 레이턴시는 퍼널 마찰입니다. 프론티어 모델을 상시 사용하면 API 비용이 증가할 뿐 아니라 응답이 2~5초 느려져 대화/작업 흐름을 끊습니다. 사용자는 원인을 언어화하지 못해도 체감 지연에서 이탈합니다. 이탈은 곧 재방문 감소(D7/D30↓)로 이어지고, 결국 같은 매출을 만들기 위해 더 많은 유저를 사와야 하니 CAC가 구조적으로 상승합니다.
맥락을 성장 관점으로 해석하면, 멀티모델 라우팅은 ‘AI 기능’을 다시 설계하는 방법론입니다. 기능을 하나의 거대한 LLM 호출로 보지 말고, 난이도/리스크/비즈니스 임팩트에 따라 모델 티어를 나눕니다. 기사에서 제안한 3티어는 꽤 현실적입니다: (1) Mixtral/Llama 같은 초고속·저원가 모델이 대다수(약 76%)를 처리, (2) 중간 티어(Haiku/GPT-3.5)가 애매한 추론을 수습(약 19%), (3) 정말 중요한 5%만 GPT-4/Opus로 승격. 라우터 자체도 LLM(Mixtral)로 <100ms에 분류해 룰 기반보다 운영 패턴을 더 잘 학습합니다.
여기서 성장 레버는 두 가지입니다. 첫째, 실험 예산의 회수. 모델 비용이 내려가면 같은 트래픽에서 마진이 남고, 그 마진이 A/B 테스트와 채널 확장에 재투자됩니다. 둘째, 퍼널 품질의 보존(또는 개선). 저가 모델의 오답이 전환율을 깎는 순간 절감은 의미가 없습니다. 그래서 라우팅은 ‘티어링’만으로 끝나면 실패하고, 반드시 검증과 복구 설계가 붙어야 합니다.
시사점은 “완벽한 라우팅”이 아니라 “실패를 견디는 라우팅”입니다. 기사에서 실제로 발생한 문제는 단순합니다: 중요한 계약 분석이 저가 모델로 잘못 라우팅되어 환각을 냈고, 신뢰가 깨졌습니다. 해결책도 성장 친화적입니다. (1) Confidence band 승격: 확신이 애매한 구간(예: 45~55%)이면 한 단계 올려 품질 사고의 꼬리를 자릅니다. (2) Output validation: 중요 경로는 경량 검증(스키마 체크/불일치 탐지/환각 패턴 감지)을 별도 모델로 돌려 ‘침묵의 실패’를 잡습니다. (3) 사용자 피드백 루프: 사용자가 재질문/짜증/반복 입력을 하면 자동 승격해 이탈 전에 복구하고, 그 이벤트를 학습 데이터로 남깁니다. (4) Cascade on failure: 후속 파이프라인에서 실패하면 자동으로 상위 티어 재시도. 즉, 비용을 줄이되 “전환이 걸린 구간”에서는 안전장치를 두는 구조입니다.
이때 관찰성은 선택이 아니라 라우팅의 엔진입니다. LLM은 200 OK로도 망할 수 있기 때문에(그럴듯한 오답), 토큰/레이턴시/품질 신호를 함께 봐야 합니다. dev.to의 LLM observability 가이드는 전통 APM이 못 보는 것—프롬프트·응답 로그, 토큰 소모, 환각률, 멀티스텝 트레이싱—을 계측해야 비용 통제와 품질 통제가 동시에 된다고 정리합니다(What is LLM Observability?, dev.to). 성장팀 입장에선 “요청 유형별 cost per request, p95 TTFT, 재질문율, thumbs down, 승격률”이 라우터의 KPI가 됩니다.
전망: 멀티모델 라우팅은 곧 ‘AI 제품의 가격정책’으로 확장됩니다. 기능을 고정 가격으로 파는 게 아니라, 요청 난이도에 따라 내부 원가가 자동 최적화되면 Freemium에서도 손익이 무너지지 않습니다. 또한 동일한 예산으로 더 낮은 TTFT와 더 높은 안정성을 만들 수 있어, 온보딩 첫 경험(Activation)에서 경쟁 우위를 만들 여지가 큽니다. 결론은 명확합니다. “항상 GPT-4”는 개발 속도를 올리는 대신 성장의 연료(마진/실험 예산/전환율)를 태웁니다. 지금 필요한 건 더 좋은 모델이 아니라, 요청을 분해하고(티어링), 실패를 감지하고(검증), 사용자 행동으로 학습하는(피드백) 라우팅 루프입니다. 이것이 CAC를 ‘캠페인 최적화’가 아니라 ‘원가 구조’로 낮추는 길입니다.