AI 제품/에이전트 SaaS에서 “성장이 막혔다”는 신호는 종종 모델 성능의 한계가 아니라, 보이지 않는 두 지표—토큰 비용(COGS)과 운영 실패율—이 퍼널을 잠식한 결과로 나타납니다. 같은 기능이라도 요청이 비싸게 처리되거나(과한 고급 모델 고정), 조용히 실패하고(모호한 에러), 복구 과정이 폭주하면(무지성 재시도) 전환은 떨어지고 CAC는 올라갑니다.
dev.to의 모델 라우팅 글은 이 현실을 숫자로 때립니다. gpt-4o-mini와 gpt-4o의 토큰 단가가 15~17배 차이인데, 단순 분류 같은 작업을 상위 모델에 고정 라우팅하면 “안전”이 아니라 “신뢰성 세금+현금 유출”입니다. 특히 ‘저비용 작업→저비용 모델’로만 바꿔도 요청당 비용이 10배 이상 줄 수 있고, 워크로드 믹스가 있는 서비스라면 누적 차이는 성장 재투자 예산 그 자체가 됩니다(출처: dev.to, Devon A. Kelley).
여기서 중요한 맥락 해석은 “비용 최적화=엔지니어링 최적화”가 아니라 “비용 최적화=성장 레버”라는 점입니다. 라우팅은 단순히 마진을 올리는 게 아니라, (1) 가격 저항을 낮춰 유료 전환을 늘리고, (2) 동일 CAC에서 더 많은 무료 체험/온보딩 트래픽을 받아내고, (3) 레이턴시까지 줄여 활성화를 당길 수 있습니다. 즉 AARRR의 Acquisition/Activation/Revenue를 동시에 건드립니다.
두 번째 소스는 MCP(Model Context Protocol) 도입 이후의 ‘컨텍스트/토큰 누수’라는 새로운 COGS 폭탄을 보여줍니다. MCP 서버를 여러 개 붙이는 순간, 툴 스키마가 대화 시작 전부터 수만 토큰을 먹어 치울 수 있고, 개발자는 그 사실을 모른 채 “요즘 왜 비싸고 느려졌지, 왜 멍청해졌지”를 겪습니다. mcp-checkup은 서버/툴별 토큰 소모를 측정하고 중복 툴을 찾아내어, 비용·속도·품질을 한 번에 회수할 관측 수단을 제공합니다(출처: dev.to, mcp-checkup 소개 글).
세 번째 소스(‘MCP 운영의 7가지 죄’)는 운영 실패율이 어떻게 매출 지표로 번지는지 언어화합니다. Sloth(나태)는 모호한 에러와 약한 검증으로 장애를 숨겨 사용자의 신뢰를 깎고, Wrath(분노)는 무지성 재시도로 장애를 증폭시켜 비용과 레이턴시를 동시에 폭발시킵니다. 특히 에이전트/툴 호출은 “실패해도 사용자에겐 조용히 넘어가는” 경우가 많아, 실질적으로는 ‘성공률 하락→재시도 증가→토큰 증가→더 많은 실패’의 악순환이 생깁니다(출처: dev.to, Riferrei).
시사점은 명확합니다. 이제 팀이 최적화해야 할 것은 ‘모델 IQ’보다 ‘단가×해결률(성공률)’의 곱입니다. 실행 전략은 세 줄로 정리됩니다. 첫째, 라우팅을 제품 기능이 아니라 실험 플랫폼으로 만들기: 룰 기반→경량 분류 호출→성과 기반(예: Thompson Sampling)으로 고도화하며 “만족/성공” 신호를 학습시키세요(출처: dev.to 라우팅 글). 둘째, 컨텍스트를 자산이 아니라 예산으로 관리하기: MCP 툴 스키마 토큰을 측정하고, 중복 제거·스키마 슬림화로 ‘대화 시작 전 고정비’를 깎으세요(출처: mcp-checkup). 셋째, 실패를 ‘정직하게’ 만들기: 에러 코드를 표준화하고 retryable을 계약으로 노출하며, 재시도는 상한·백오프·지터·취소 신호를 기본값으로 두어 폭주를 막으세요(출처: 운영의 죄).
전망은 “비용/운영 관측 가능성(Observability)이 곧 그로스 스택”으로 수렴합니다. 다음 분기 실험으로는 (A) 라우팅 도입 전후 ARPU/LTV 변화(가격 정책 여지 포함), (B) MCP 스키마 다이어트 전후 D1/D7 리텐션(레이턴시·응답 품질 동반 개선 가설), (C) 재시도 정책 변경 전후 전환 퍼널의 ‘조용한 실패율’(툴 호출 성공률, 사용자 재시도 행동, CS 티켓)을 묶어 A/B를 걸 수 있습니다. 결론: 토큰과 실패율을 잡는 순간, 모델을 바꾸지 않고도 성장 지표가 움직입니다. 이건 비용 절감이 아니라, 성장을 다시 스케일 가능하게 만드는 엔진 수리입니다.