AI 에이전트가 웹을 “쓸 줄” 알게 되면서, 많은 팀이 자동화를 퍼널에 꽂기 시작했습니다. 그런데 막상 전환 구간(가입·결제·견적·예약)의 성공률은 기대만큼 안 나옵니다. 이유는 단순합니다. 에이전트가 지금까지 웹을 다루는 방식이 본질적으로 취약했기 때문입니다(CSS selector/XPath/DOM 파싱/비주얼 추론). UI가 조금만 바뀌어도 실패하고, 그때마다 유지보수·CS·세일즈 대응 비용이 튑니다. 이 비용은 결국 CAC에 재반영됩니다.
dev.to의 WebMCP 소개 글은 이 병목을 “브라우저 네이티브 표준”으로 푸는 방향을 제시합니다. Chrome 146 프리뷰로 등장한 WebMCP는, 웹페이지가 에이전트에게 ‘내가 제공하는 액션(툴)과 입력 스키마, 반환값’을 구조화해서 직접 노출하도록 설계됩니다. 즉 에이전트가 사람용 UI를 억지로 해석하는 게 아니라, 페이지가 기계가 쓸 수 있는 인터페이스를 내장하는 모델로 뒤집습니다.
이 변화가 성장 관점에서 중요한 이유는 “실패율 감소 = 퍼널의 마찰 제거”로 직결되기 때문입니다. 기존 방식은 폼 필드 추정, 날짜 피커 해석, 버튼 위치 탐색 같은 불확실성이 TTV(Time-to-Value)를 늘리고, 전환 실패를 만들고, 그 후속 비용(리트라이, 상담, CS, 핫픽스)을 발생시켰습니다. WebMCP는 폼을 선언적으로(toolname/tooldescription 등) 정의해 브라우저가 JSON Schema를 생성하게 만들고, submit 이벤트에 agentInvoked/respondWith 같은 훅을 붙여 “에이전트 호출”을 결정론적으로 처리합니다(출처: dev.to, WebMCP 글). 결과적으로 (1) 에이전트 자동화 성공률↑ (2) 유지보수 비용↓ (3) 온보딩/구매 전환 시간↓가 한 번에 일어날 여지가 큽니다.
여기서 한 단계 더 가면 CAC 레버가 열립니다. WebMCP가 ‘웹에서의 액션’을 안정화한다면, MCP는 ‘외부 시스템 호출(REST API 등)’을 표준화합니다. 문제는 많은 팀이 MCP 서버(=에이전트와 API를 잇는 브릿지)를 직접 만들다가 연동 비용과 리드타임에 막힌다는 점입니다. dev.to의 APIFold 사례는 OpenAPI 스펙만 있으면 REST API를 “즉시 MCP 서버로 변환”해 주는 접근을 제시합니다. glue code(파라미터 매핑, 인증 주입, 레이트리밋, 에러 처리, 배포)를 자동화해, 파트너/고객이 셀프서브로 연결을 끝내게 만들 수 있습니다(출처: dev.to, APIFold 글).
정리하면, WebMCP + APIFold 조합은 ‘전환 퍼널’에서 CAC를 깎는 전형적인 구조 개선입니다. ① 브라우저에서 에이전트-웹 상호작용 실패율을 낮춰 전환/CS 비용을 줄이고(WebMCP), ② API 연동을 자동화해 온보딩 리드타임과 세일즈 의존도를 낮춥니다(APIFold). 특히 B2B SaaS/플랫폼에서 “연동이 곧 가치”인 제품(핀테크, CRM, 백오피스, 예약/물류, DevTool)은 연동 난이도가 CAC를 결정합니다. 연동이 쉬워지면, 데모→POC→도입까지의 시간이 줄고, 셀프서브 채널(콘텐츠/마켓플레이스/커뮤니티)로도 전환이 가능합니다.
다만 실행에는 함정이 있습니다. 첫째, 표준은 초기엔 브라우저 지원/플래그/호환성 이슈가 있습니다(기사도 progressive enhancement를 강조). 따라서 WebMCP는 “핵심 전환 폼 몇 개부터” 부분 적용해 실험해야 합니다. 둘째, MCP 툴을 마구 늘리면 에이전트 컨텍스트 비용과 선택 오류가 생깁니다. dev.to의 ‘MCP Skills vs Tools’ 글이 지적하듯, 도구는 능력이고 스킬은 레시피이며, 너무 많은 툴은 토큰/지연/혼선을 키웁니다. 성장 팀의 정답은 ‘퍼널에 필요한 최소 툴’만 노출하고, 성공 경로를 스킬(플레이북)로 고정해 성공률을 올리는 것입니다.
전망은 명확합니다. 브라우저가 에이전트 상호작용을 표준화하면, “UI 자동화”는 유지보수 지옥에서 빠져나와 제품 기능이 됩니다. 그리고 OpenAPI→MCP 변환 같은 레이어가 보편화되면, API 생태계는 ‘문서 읽고 개발’에서 ‘스펙 붙이고 즉시 연결’로 이동합니다. 결국 CAC 경쟁은 광고비가 아니라, 실패율(전환/연동/지원)을 누가 더 낮추느냐로 재편됩니다. 다음 실험은 간단합니다: (1) 가장 이탈이 큰 폼 1개에 WebMCP 도입 → 에이전트 완료율/소요시간/CS 티켓 변화를 측정하고, (2) OpenAPI가 있는 핵심 연동 1개를 APIFold로 MCP 서버화 → 파트너 온보딩 시간을 ‘일’에서 ‘분’으로 줄이는지 확인하세요. CAC는 캠페인보다 퍼널의 구조에서 먼저 무너집니다.