MCP(Model Context Protocol)가 ‘연동 표준’ 단계를 지나 ‘유통채널’로 변하고 있습니다. dev.to의 TypeScript 튜토리얼은 MCP SDK가 월 9,700만 다운로드, 공개 서버 구현 1만+를 넘겼고 Claude·Cursor·Windsurf·OpenAI 등 주요 클라이언트가 네이티브로 지원한다고 짚습니다. 이제 MCP 서버를 만들면 “어디에 붙일까”보다 “어디서 발견될까”가 더 중요해졌습니다.
이 변화의 핵심은 분산된 AI 클라이언트가 MCP를 공통 언어로 채택하면서, 통합 비용이 급락했다는 점입니다. TypeScript 예제는 stdio 기반 로컬 서버를 아주 얇은 레이어(도구 정의+Zod 검증+JSON-RPC)로 완성합니다(dev.to). 즉, 개발자가 한 번 도구를 MCP로 포장하면 여러 클라이언트에서 재사용되며 배포면에서 ‘호환성 프리미엄’을 얻습니다. 성장은 여기서 시작합니다. “통합이 쉬움”은 곧 “채널 진입 장벽이 낮음”이기 때문입니다.
반대로, 진짜 비즈니스는 원격(Remote) MCP에서 터집니다. Rails 프로덕션 가이드는 로컬(stdio)이 개발자 도구에는 좋지만 SaaS에는 맞지 않고, 멀티테넌트·권한·과금 게이팅을 위해 HTTP+OAuth가 필수라고 말합니다(dev.to). 중요한 건 기술 스택이 Rails냐 Node냐가 아니라, MCP 엔드포인트가 곧 ‘외부 에이전트들이 들어오는 공식 입구’가 된다는 사실입니다. 이 입구에서 인증/플랜 제한/사용량 계측을 걸어두면, 유입→활성화→수익화가 한 번에 연결됩니다.
여기에 카카오 PlayMCP의 움직임이 결정타입니다. 카카오 보도자료에 따르면 PlayMCP에는 200여 개 MCP 서버가 등록돼 있고, Claude·ChatGPT에 이어 오픈소스 에이전트 OpenClaw까지 사용처가 넓어졌습니다(카카오). 사용자는 PlayMCP ‘도구함’에 담아둔 MCP 서버를 OpenClaw 에이전트가 직접 실행하게 만들 수 있고, 연동은 원타임 토큰(10분 유효)으로 보안을 올렸습니다. 이건 단순한 기능 추가가 아니라, “등록된 MCP 서버가 추가 채널로 자동 재배포되는 구조”에 가깝습니다.
성장 관점의 시사점은 명확합니다. 첫째, MCP는 새로운 상단 퍼널입니다. 검색/광고로 유저를 데려오는 대신, (1) MCP 서버를 표준 스키마로 공개하고 (2) PlayMCP 같은 카탈로그/도구함에 등록해 (3) 여러 에이전트 클라이언트에서 자연어 호출로 ‘발견’되게 만들면, CAC는 광고 단가가 아니라 “도구의 채택률”에 의해 결정됩니다. 둘째, 파트너 유통이 쉬워집니다. 클라이언트가 표준으로 도구를 탐색(tools/list)하고 호출(tools/call)하니, 파트너는 커스텀 SDK 없이도 붙습니다. 결과적으로 BD는 ‘개별 통합 프로젝트’가 아니라 ‘목록에 올리는 작업’으로 바뀝니다.
실행 체크리스트도 달라져야 합니다. (A) 로컬 stdio 서버로 빠르게 프로토타입을 만들어 데모/개발자 채택을 만들고(TypeScript 방식, dev.to), (B) 원격 HTTP MCP로 전환해 인증·멀티테넌트·요금제 게이트를 심고(Rails 방식, dev.to), (C) PlayMCP 같은 마켓플레이스에 등록해 유통을 확장합니다(카카오). 이때 트래킹은 ‘대화당 호출 수’가 아니라 연동 완료율(Activation), 도구 반복 호출(D7/D30 Retention), 호출당 가치(ARPU/LTV)로 잡아야 합니다. MCP는 “기능 사용”이 아니라 “워크플로우에 편입”될 때 재방문이 폭발합니다.
전망: MCP 생태계가 커질수록, 제품팀은 두 갈래로 갈립니다. (1) 도구를 많이 만드는 팀이 아니라, (2) 유통 가능한 형태로 도구를 패키징하고, 카탈로그 노출·온보딩·권한/과금·안전장치를 표준 인터페이스에 얹는 팀이 승리합니다. PlayMCP가 OpenClaw까지 확장한 것처럼, 앞으로는 “어느 모델이 더 똑똑하냐”보다 “어느 유통망에 기본 탑재되느냐”가 성장의 1차 변수가 될 가능성이 큽니다. MCP 서버는 이제 개발 산출물이 아니라, 스케일 가능한 유통 자산입니다.