에이전트 제품에서 CAC를 올리는 주범은 의외로 ‘모델 단가’가 아니다. 진짜 비용은 매 세션마다 자동 주입되는 툴 스키마의 토큰 세금, 그리고 그로 인해 발생하는 성공률 저하(재시도/루프/환각)다. 운영 지표로 번역하면 “첫 작업 성공률”과 “TTV(첫 가치 도달 시간)”이 무너지고, 그 결과 셀프서브 전환이 떨어져 CAC가 상승한다.
dev.to의 글 The #1 Most Popular MCP Server Gets an F는 이 문제를 정면으로 보여준다. 인기 1위급 MCP 서버인 Context7가 스키마 품질 점수 7.5/100(F)를 받았는데, 결정타는 기능 수가 아니라 스키마 비만이다. 툴 2개뿐인데 스키마가 1,020 tokens를 태운다. 툴 설명란에 매뉴얼(선택 프로세스, 응답 포맷, 경고)을 통째로 밀어 넣는 바람에, 유저 메시지 한 줄 받기 전부터 컨텍스트 창을 깎아먹는 구조다.
이게 왜 성장 문제냐. 컨텍스트는 곧 “작업을 수행할 수 있는 작업대”다. 스키마가 두꺼워지면 1) 모델이 실제 사용자 요청을 볼 공간이 줄고 2) 추론이 흔들리며 3) 잘못된 툴 호출/형식 오류가 늘고 4) 재시도 턴이 증가한다. 결국 한 유저가 ‘첫 성공’에 도달하기까지 더 많은 토큰·시간·실패를 겪는다. 이때 발생하는 비용은 매출원가(COGS)로만 끝나지 않고, 온보딩 이탈을 통해 CAC로 되돌아온다.
비교가 더 잔인하다. 같은 글에서 PostgreSQL MCP 서버는 툴 1개에 46 tokens로 A+에 가깝다. “도구가 많아서 비싸다”가 아니라 “도구가 토큰 예산을 벌어오느냐”의 문제다. 리더보드에서도 상위권 서버는 총 토큰이 작고(평균 수백 토큰), 하위권은 수천 토큰을 소비한다. 이 격차는 곧 대화당 비용뿐 아니라 대화당 실패 확률의 격차로 누적된다.
두 번째 dev.to 글 24 Custom MCP Tools Later…는 해결 방향을 반대로 증명한다. 자연어로 “파일 열고 45번째 줄 봐줘”라고 길게 설명하는 대신, read_file(path, offset, limit) 같은 툴 호출로 바꾸면 토큰이 줄고 해석/환각이 사라진다. 여기서 핵심은 “프롬프트를 잘 쓰자”가 아니라, 자연어 지시를 툴 스키마(구조화된 인터페이스)로 이전해 프롬프트 비용과 오해 비용을 동시에 깎는 것이다.
실무적으로는 이렇게 연결된다: MCP 품질 = 퍼널 최적화 레버. (1) 스키마 토큰을 줄이면 첫 턴부터 컨텍스트 여유가 생겨 성공률이 오르고, (2) 성공률이 오르면 재시도 턴이 줄어 COGS가 감소하며, (3) 무엇보다 “첫 작업 완료”까지 걸리는 턴이 줄어 TTV가 감소한다. TTV는 에이전트의 ‘활성화(Activation)’에 직결되고, Activation이 오르면 유료 전환/리텐션이 올라 결과적으로 CAC 회수 기간이 짧아진다.
따라서 성장팀 관점에서의 체크리스트는 모델 벤치마크가 아니라 운영 지표다. 예: schema_tokens_per_tool, session_boot_tokens(도구 주입 토큰), tool_call_success_rate, invalid_json_rate, avg_turns_to_first_success, cost_to_first_value, dropoff_before_first_success. 그리고 정책은 명확하다. 툴 설명은 200자 내외로 ‘무엇을 하는지’만, 멀티스텝 절차는 시스템 프롬프트나 문서로, 네이밍/타이핑은 컨벤션 준수. dev.to의 ‘AI가 MCP 스키마를 채점한다’ 글이 말하듯, 정합성(correctness)은 기본값이고 경쟁은 효율/품질에서 난다.
전망은 단순하다. MCP 생태계가 커질수록 “작동함”만으로는 부족해지고, 스키마 린팅/CI 게이팅/토큰 예산 관리가 표준 운영이 된다. 인기(스타/다운로드)가 품질을 보장하지 않는 시장에서는, 제품이 자체적으로 “좋은 MCP만 기본 탑재/추천”하거나 “스키마를 자동 최적화(압축·정규화)해 주입”하는 순간, 경쟁사 대비 CAC 우위가 구조적으로 발생한다. 에이전트 성장의 승부처는 이제 모델 선택이 아니라, MCP 품질로 운영 비용과 첫 성공률을 관리하는 팀이다.