아직 WebMCP를 호출하는 에이전트는 없습니다. 그럼에도 오늘 바로 도입해야 하는 솔직한 이유와 변화의 시점을 아는 법

WebMCP에 대한 모든 열광 이면에는 불편한 사실이 있으며, 회의론자들이 이를 계속해서 제기하는 것은 정당합니다:

2026년 6월 현재, 주요 AI 에이전트 중 그 어느 것도 귀하의 사이트에서 navigator.modelContext를 실제로 호출하지 않습니다. ChatGPT Agent, Claude, Gemini, Perplexity 모두 마찬가지입니다. 이들은 여전히 DOM 스크래핑 (DOM-scraping)을 하거나 스크린샷을 찍고 픽셀을 클릭하는 방식으로 페이지를 읽습니다. Patrick Brosset의 업데이트와 studiomeyer의 "Reality Check" 모두 이 사실을 명확히 밝히고 있으며, 이는 반복할 가치가 있습니다. 왜냐하면 대개 하이프 (hype)는 이 부분을 건너뛰기 때문입니다: WebMCP는 표준 (standard)이 아니라 W3C 커뮤니티 그룹 초안 (W3C Community Group draft)이며, Chrome의 플래그 (flag)와 Chrome 149 오리진 트라이얼 (Chrome 149 origin trial) 뒤에서 배포되고 있습니다. 그리고 이를 소비할 에이전트들은 아직 연결 작업을 완료하지 않았습니다.

그렇다면 왜 지금 귀하의 사이트에 WebMCP 도구들을 추가해야 할까요?

저는 솔직한 답변이 있다고 생각하며, 그것은 "미래이기 때문이니 저를 믿으세요"가 아닙니다. 대부분의 "지금 설치하세요" 게시물들이 생략하는 부분, 즉 설치한 기능이 조용히 부식되지 않도록 하기 위해 무엇을 해야 하는지를 포함하여 실제 근거를 제시해 보겠습니다.

비용 측면은 진정으로 제로에 가깝습니다

"지켜보자"는 태도가 안전하게 느껴지는 이유는 조기 도입이 비용이 많이 든다는 가정 때문입니다. WebMCP의 경우, 제대로 한다면 비용이 거의 들지 않습니다:

• 기능 감지(Feature-detection) 방식이므로 무엇도 망가뜨리지 않습니다. 전체 인터페이스가 if ("modelContext" in navigator) 뒤에 존재합니다. 이 API를 탑재하지 않은 모든 브라우저(현재로서는 거의 모든 브라우저가 해당됨)에서 귀하의 코드는 아무런 동작도 하지 않는 no-op 상태가 됩니다. 런타임 비용도 없고, 기존 사용자에게 미치는 리스크도 제로입니다.
• 두 번째 코드베이스를 추가할 필요가 없습니다. WebMCP 도구는 UI가 이미 호출하고 있는 함수에 대한 얇고 타입이 지정된(typed) 프런트 도어(front door)여야 합니다. 귀하의 search_products 도구는 검색창이 호출하는 것과 동일한 productSearch()를 호출합니다. 만약 에이전트를 만족시키기 위해 새로운 비즈니스 로직을 작성하고 있다면, 즉시 멈추십시오. 그것은 비용이 많이 드는 방식이며, 기존 로직과 동기화되지 않고 어긋나게 되는 방식입니다.
• 되돌려야 할 마이그레이션이 없습니다. 추가적(additive)이고 감지되는 방식이기 때문에, "너무 일찍 도입했다"라고 해도 정리 비용이 들지 않습니다. 스크립트 태그 하나만 삭제하면 됩니다.

이런 방식으로 진행한다면, 오늘 WebMCP를 출시하는 실제 비용은 로드맵 전체를 거는 도박이 아니라 단지 오후 한때의 시간일 뿐입니다.

이점(Benefit) 측면은 약속이 아니라, 유효기간이 있는 옵션입니다

귀하가 그 오후의 시간을 투자하여 실제로 구매하는 것은, **불확실성이 가장 높을 때 가장 가치가 있는 옵션(option)**입니다.

에이전트가 실제로 타입이 지정된 도구(typed tools)를 호출하기 시작할 때 — 그리고 브라우저를 만드는 곳(Google, Microsoft)과 에이전트를 만드는 곳이 동일한 기업들이 이 사양(spec)을 밀어붙이고 있다는 점을 고려하면 — 이미 도구를 노출하고 있는 사이트들은 허둥지둥 준비할 필요 없이 에이전트 트래픽의 첫 번째 파도를 선점하게 됩니다. 귀하가 메우고 있는 격차는 "에이전트가 내 페이지를 읽을 수 있는가"(DOM 스크래핑이 이미 절반은 작동함)가 아닙니다. 그것은 "에이전트가 열 번의 추측 섞인 클릭 대신, 단 한 번의 호출로 내 페이지에서 _내가 판매하는 것을 신뢰할 수 있게 완료할 수 있는가"입니다.

그 시점이 6개월 뒤인지 18개월 뒤인지 믿을 필요는 없습니다. 옵션의 핵심은 그 날짜를 알 필요가 없다는 것입니다. 옵션을 보유하는 비용은 낮아야 하고(실제로 낮습니다), 적중했을 때의 보상은 높아야 합니다(트랜잭션이 발생하는 모든 서비스의 경우 그렇습니다).

"지금 설치하세요"라는 게시물들이 생략하는 부분: 그것이 중요해지는 순간을 당신은 알아차리지 못할 것입니다

"배포하고 잊어버리기(ship it and forget it)" 방식의 실패 모드는 다음과 같습니다. 도구(tools)를 추가해 두었지만, 아직 아무도 사용하지 않는 에이전트(agent)를 위한 브라우저의 피처 플래그(feature flag) 뒤에 방치되어 있고, 그러다 보면... 그 상황이 언제 변하는지 알려주는 것은 아무것도 없게 됩니다. 6개월 후, 어떤 에이전트가 실제로 search_products를 호출하기 시작했을 때 — 당신은 결제 이상 징후나 고객 지원 티켓을 통해서야 알게 되거나, 혹은 영영 모른 채 지나가게 됩니다.

WebMCP가 선택지라면, 당신은 그것이 수익(money)으로 연결되는 순간을 즉시 알고 싶을 것입니다. 이는 첫날부터 당신의 도구들에 계측(instrumenting)을 적용해야 함을 의미합니다. 최소한, 모든 호출(invocation)을 직접 로그로 남기세요:

if ("modelContext" in navigator) {
  navigator.modelContext.registerTool({
    name: "search_products",
...

그 beacon() 하나가 "어딘가에 WebMCP가 있다"와 "지난 화요일에 에이전트가 우리 검색 도구를 240번 호출했고, 그중 12건이 장바구니 담기로 이어졌다"의 차이를 만듭니다. 두 번째 문장은 다음 분기 예산안에 WebMCP 항목을 올리게 만드는 문장입니다. 첫 번째 문장은 정리(cleanup) PR에서 조용히 삭제되게 만드는 문장입니다.

호출당 캡처할 가치가 있는 정보는 다음과 같습니다: 어떤 도구인지, 인자(arguments, 개인정보(PII)는 정제할 것), execute가 성공했는지 여부, 지연 시간(latency), 그리고 얻을 수 있는 모든 사용자 에이전트(user-agent) / 클라이언트 힌트(client hints)입니다. 당신은 "에이전트들이 벌써 왔는가, 그리고 그들이 도착했을 때 무엇을 하는가?"라는 질문에 답할 수 있는 대시보드를 구축하고 있는 것입니다. 이것이 추측 대신 선택지를 관리하는 유일하고 정직한 방법입니다.

결론 (Bottom line)

회의론자(skeptics)와 찬성론자(boosters)는 둘 다 옳으며, 이들은 실제로 충돌하고 있지 않습니다:

• 회의론자: 오늘날 WebMCP를 호출하는 에이전트는 없다. 사실입니다. 로봇들이 이미 당신의 상점에서 쇼핑을 하고 있다고 말하는 사람은 믿지 마세요. 아직은 아닙니다.
• 찬성론자: 어쨌든 배포하라. 이 또한 사실입니다 — 왜냐하면 비용이 저렴하고, 기능 감지(feature-detected)가 가능하며, 부가적인(additive) 기능이기 때문이며, 그 보상이 정확히 예측할 수 없는 날에 찾아오기 때문입니다.

이 둘의 종합은 다음과 같습니다: 조기에 배포하고, 기능이 어긋나지 않도록(drift) 기존의 핸들러(handlers)를 재사용하며, 첫 번째 실제 에이전트 호출이 발생하는 날(분기 뒤가 아닌 바로 그날)을 볼 수 있도록 계측을 적용하십시오. 선택지(option)를 채택할 때 계측기(meter)도 함께 채택하십시오. 그렇지 않다면 둘 다 채택하지 않은 것과 같습니다.

고지(Disclosure): 저는 Latch에서 일하고 있습니다. Latch는 위에서 언급한 지루한 작업의 절반을 대신 해주는 오픈 소스 (MIT) 한 줄 스크립트입니다. 이 도구는 귀하의 사이트에 이미 존재하는 검색/장바구니/양식(forms)을 WebMCP 도구로 노출하며(기능 감지(feature-detected), 기존 핸들러(handlers) 재사용, 유효한 스키마(schemas) 적용), 선택 사항인 호스팅 티어(hosted tier)는 정확히 그 "계측기(meter)" 역할을 합니다. 즉, 어떤 에이전트가 귀하의 도구를 호출하고 무엇을 하는지 보여줌으로써, 결제 이상 현상을 통해 뒤늦게 알게 되는 대신 첫 번째 에이전트의 방문을 확인할 수 있게 해줍니다. 만약 표준(standard) 자체를 이해하고 싶다면, WebMCP 가이드는 특정 벤더에 종속되지 않으며(vendor-neutral), 코드는 GitHub에서 확인할 수 있습니다. 댓글을 통해 트레이드오프(trade-offs)에 대해 논의할 준비가 되어 있습니다.