MCP(Model Context Protocol) 생태계에서 “서버가 동작하느냐”는 이제 합격선일 뿐입니다. 진짜 경쟁은 “LLM이 그 툴을 낮은 토큰으로, 헷갈리지 않고, 빠르게 쓰게 하느냐”에 있습니다. 이 차이가 에이전트의 성공률과 지연시간을 갈라놓고, 결국 셀프서브 온보딩 전환율을 흔들어 CAC를 결정합니다.
dev.to의 사례(0coceo, I Built a Tool That Grades MCP Servers. Notion's Got an F.)는 이 현실을 숫자로 드러냈습니다. MCP 툴 스키마 린터(‘agent-friend’)로 199개 서버/3,974개 툴을 감사해보니, Notion MCP는 “실행은 되지만 LLM 친화성은 낮다”는 이유로 F(19.8/100)를 받았습니다. 핵심은 기능 결함이 아니라 스키마 정의의 모호함·장황함·불충분함이 LLM의 “추측”을 유발한다는 점입니다.
맥락을 성장 지표로 번역해보면 간단합니다. 스키마가 지저분할수록 (1) 프롬프트에 실리는 정의 토큰이 늘고 (2) 툴 선택/파라미터 구성에서 실패 확률이 오르고 (3) 재시도·리커버리 대화가 늘어납니다. 즉, 토큰비용(COGS)과 실패율(Completion Rate)과 TTV(Time-to-Value)가 동시에 악화됩니다. 유저 입장에선 “연동했는데 안 된다/느리다/자꾸 되묻는다”로 체감되고, 이탈은 온보딩 1~2세션에서 발생합니다. 여기서 CAC는 마케팅이 아니라 표준의 품질로 새어나갑니다.
이 글이 흥미로운 포인트는 “런타임 최적화”보다 “빌드타임 린팅”을 강조한다는 점입니다. 많은 팀이 progressive discovery(초기에 이름/요약만 로드, 필요 시 상세 스키마 로드) 같은 런타임 트릭으로 토큰을 줄이려 합니다. 물론 효과는 큽니다. 하지만 소스 기사처럼 툴 설명이 6,000 토큰짜리 벽이라면, 로딩 전략은 테이프일 뿐입니다. 스키마 자체가 슬림하고 결정적이어야 discovery도 제대로 먹힙니다.
여기에 두 번째 기사(dev.to, angularfirebase, MCP Skills vs MCP Tools)의 “Tools vs Skills” 설계 원칙을 붙이면, CAC 관점에서 더 선명해집니다. MCP Tools는 외부 시스템에 대한 결정적 실행 레이어이고, Skills는 도메인 체크리스트/절차를 담는 저비용 지식 레이어입니다. 많은 팀이 스킬로 해결할 문제(절차/가이드)를 툴 스키마 설명에 과다 주입합니다. 그 결과는? 스키마 비대화 → 토큰세금 → 선택 오류 → 실패율 증가. 정답은 분리입니다. 툴은 최소·정확·타이핑(입출력 스키마)에 집중, 스킬은 “어떻게 쓸지”를 온디맨드로 불러오게 하세요.
시사점은 명확합니다. MCP 스키마 품질을 “엔지니어링 미학”이 아니라 퍼널 레버로 다뤄야 합니다. - (획득/CAC) 셀프서브 전환을 막는 최대 마찰은 ‘연동 후 첫 성공’입니다. 스키마 린팅을 CI에 넣고, 첫 작업 성공률(Activation/Task Completion)을 지키면 광고비보다 먼저 CAC가 내려갑니다. - (리텐션) D1은 “한 번이라도 성과를 봤는가”로 결정됩니다. 실패→재시도 루프가 길어질수록 D1/D7이 꺾입니다. 스키마 개선은 리텐션 개선과 직결됩니다. - (수익화) 토큰·지연·실패율이 내려가면, 더 공격적인 프리미엄/프리미엄 트라이얼을 설계할 여지가 생깁니다. 결국 LTV가 올라가 CAC 한계가 넓어집니다.
실험 가능한 다음 단계도 있습니다. 0coceo가 했던 것처럼 “품질 대시보드”를 만들 필요까지는 없습니다. 대신 2주짜리 성장 실험으로 쪼개면 됩니다. 1) 스키마 품질 점수(린팅): 툴당 토큰, 누락된 필드, 모호한 description, 파라미터 과다 등 지표화 2) 온보딩 KPI 연결: 첫 툴콜 성공률, 첫 가치 도달 시간(TTV), 1세션 내 완료율 3) A/B: (A) 기존 스키마 vs (B) 슬림 스키마+스킬 분리 버전 4) 성공 기준: 완료율 +X%, TTV -Y초, 토큰/세션 -Z% → 유료전환 또는 활성화 전환 상승
전망: MCP는 표준이 성숙할수록 “연동의 민주화”를 만들지만, 역설적으로 스키마 품질 격차가 성장 격차가 됩니다. 스타가 많은 서버도 품질이 낮을 수 있다는(인기와 품질 무상관) 소스 기사 관찰은 경고입니다. 앞으로는 ‘툴 스키마 린팅/등급’이 ESLint처럼 보편화되고, 마켓플레이스/디렉터리에서도 “툴당 토큰·품질 등급·LLM 성공률”이 배포 전 신뢰 지표가 될 겁니다. 결론은 하나: MCP에서 CAC를 줄이는 가장 빠른 길은 광고 크리에이티브가 아니라 스키마를 고치는 것입니다.