AI 에이전트를 프로덕션에 올리면 이상하게도 ‘기능’이 아니라 ‘운영비’와 ‘신뢰성’이 먼저 발목을 잡습니다. 유저가 한 번 써보고 “오 괜찮네”까지 가기 전에, 우리는 토큰을 태우고(=원가 상승), 스턱/루프/오류로 시간을 태웁니다(=전환 하락). 이 조합은 CAC를 올리고 LTV를 깎는 최악의 구조예요.
dev.to의 MCP 워크숍 글은 이 문제를 정면으로 찌릅니다. LLM이 코드베이스를 “파일 단위로 크롤링”하며 맥락을 수집하는 순간, 5만 토큰이 그냥 증발한다는 거죠. Claude Opus 기준 태스크당 약 $0.75 수준이라는 예시까지 나옵니다. 하루 20회면 월 수백 달러. 여기서 “와 이거다!” 포인트는 단순합니다: 모델에게 파일을 주지 말고, 답을 주자.
그 방법이 MCP(Model Context Protocol) 서버 + 5개 툴 패턴입니다(출처: dev.to, ‘Build a 5-Tool MCP Server…’). 프로젝트 요약/의존성 맵/관련 파일 찾기/컨벤션 추출/스키마·타입 제공을 사전 분석(pre-compute) 해서 JSON으로 짧게 내려주면, 모델이 탐색에 쓰는 토큰을 60~75% 즉시 절감하고, 구조를 잘 잡으면 95%까지도 노린다고 합니다. 즉 “추론 시간(inference time)에 모델이 알아내야 할 것”을 “빌드/CI 시간에 컴파일”해버리는 발상이에요.
맥락을 그로스 관점으로 번역하면: 토큰 절감은 단순 비용 절감이 아니라 퍼널의 변동비를 내리는 레버입니다. 체험 유저가 늘어날수록 원가가 기하급수로 늘어나는 제품(에이전트형 SaaS)에서, 토큰/태스크를 1/10로 만들면 CAC가 같은 채널에서도 내려갈 여지가 생깁니다. 특히 무료 체험/프리미엄 퍼널에서는 “체험 구간 원가”가 곧 실험 속도를 결정하거든요. 빨리 테스트해봐야 돼요.
하지만 비용만 줄이면 끝일까요? 아니요. 두 번째 dev.to 글(‘How to Detect When Your AI Agent Is Stuck…’)이 말하듯, 에이전트는 에러 없이도 스턱 상태로 토큰을 태우며 ‘정상처럼 보이는 실패’를 합니다. 리피터(같은 행동 반복), 원더러(바쁘지만 목표와 무관), 루퍼(A↔B 순환). 이건 전환율을 직접 깎습니다. 유저 입장에서는 “안 됨/느림/끝이 없음”이니까요.
해법은 의외로 운영 패턴입니다. 각 액션마다 “진짜 진척”을 나타내는 progress metric을 기록하고, N회 반복/ N회 무진척이면 복구 모드로 전환합니다(다른 접근 시도, 목표 재정의). 그래도 3번 연속이면 사람에게 에스컬레이션. 여기에 파일 기반 킬 스위치까지 붙이면 runaway 비용을 즉시 끊을 수 있어요(출처: dev.to stuck detection 글). 이거 바이럴 될 것 같은데? ‘에이전트가 멈추는 버튼’은 팀 모두가 사랑합니다.
시사점은 “MCP로 토큰 최적화”와 “스턱 감지·복구”를 같은 KPI로 묶어 운영해야 한다는 겁니다. 추천 측정치는 단순합니다: ① tokens per successful task(성공 태스크당 토큰), ② task success rate(완료율), ③ time-to-done(완료 시간). MCP는 ①을, 스턱 운영은 ②·③을 때립니다. 결국 성공당 원가가 내려가고, 이게 CAC/LTV에 직결됩니다. Conversion rate가 얼마나 오를까요? 최소한 ‘끝까지 못 가는 체험’이 줄어드는 만큼은 바로 반영됩니다.
전망으로는, 멀티 에이전트가 늘수록 이 패턴은 더 중요해집니다. 에이전트가 늘면 토큰도 늘고, 한 놈이 루프 돌면 전체 시스템이 느려집니다. 그래서 토큰 최적화는 “성능 튜닝”이 아니라 “스케일 설계”가 되고, 스턱 감지는 “디버깅”이 아니라 “프로덕션 SRE”가 됩니다. 결론: 에이전트 그로스는 기능 로드맵보다 먼저 원가(토큰)와 신뢰성(스턱/복구) 로드맵을 깔아야 합니다. 이 두 개 잡으면, 같은 제품이 갑자기 ‘유닛 이코노믹스가 되는 제품’으로 변합니다.