2026년 대부분의 기간 동안 WebMCP에 대한 솔직한 반론은 다음과 같았습니다: "멋진 API네요. 하지만 어떤 주류 에이전트도 실제로 navigator.modelContext를 호출하지 않는데, 왜 출시해야 하죠?"

저 또한 글로 그런 주장을 한 적이 있습니다. 그것은 사실이었고, 한 스프린트(sprint)를 쏟아붓기 전에 던져야 할 올바른 질문이었습니다.

Google이 방금 그 답변을 바꿨습니다. Google I/O 2026 요약에서 Chrome 팀은 명확하게 다음과 같이 작성했습니다:

"Chrome의 Gemini가 곧 WebMCP API를 지원할 것입니다."

자신의 사이트에 WebMCP를 구현한 한 개발자가 표현했듯이: "오늘날 해당 도구들을 소비하는 유일한 에이전트는 Chrome의 Gemini입니다." 따라서 2026년 중반의 그림은 다음과 같습니다: 이름이 알려져 있고, 주류이며, 수억 명의 설치 수를 가진 에이전트가 첫 번째 실제 소비자이며, 이는 여러분의 사용자들이 이미 실행하고 있는 브라우저 내부에서 제공됩니다.

이것이 WebMCP가 "완성되었다"는 뜻은 아닙니다. 하지만 반론의 내용을 _"어떤 에이전트도 이것을 호출하지 않을 것이다"_에서 _"이제 이름이 있는 에이전트가 있고, 곧 출시될 것이다"_로 바꿉니다. 이는 매우 다른 베팅입니다.

실제로 무엇이 변했는가

스펙(spec)에 관한 것은 아무것도 변하지 않았습니다. WebMCP는 여전히 오리진 트라이얼(origin trial, Chrome 149–156) 단계이며, 여전히 실험적이고, 여전히 WebKit의 반대에 부딪혀 있으며, 여전히 오늘날 대부분의 에이전트에 의해 호출되지 않고 있습니다. 만약 표준이 "안착"하기를 기다리고 있었다면, 아직 그렇지 않습니다.

변한 것은 리스크의 형태입니다. 이전에는: 무기한으로 관객이 0명인 대상을 위해 사이트를 준비(instrument)해야 했습니다. 이제는: Google이 공개적으로 출시를 약속했으며, 여러분 트래픽의 대부분이 사용하는 기본 브라우저에 탑재될 소비자(consumer)를 위해 준비하면 됩니다. 준비를 갖추었을 때의 기대 가치가 이동한 것입니다.

왜 일찍 시작하는 것이 저렴하고 (늦으면 비싼지)

소비자가 명시되면 판단이 쉬워지는 비대칭성은 다음과 같습니다:

• 도구를 노출하는 비용은 매우 적습니다. WebMCP 도구는 이미 보유하고 있는 핸들러(handler)—사이트 검색, 장바구니, 예약 양식 등—를 얇게 감싼 래퍼(wrapper)일 뿐입니다. 새로운 기능을 만드는 것이 아니라, 에이전트(agent)가 호출할 수 있는 방식으로 기존 기능을 설명하는 것입니다.
• 기능 감지(feature-detecting) 비용은 제로입니다. 만약 navigator.modelContext가 존재하지 않는다면, 귀하의 코드는 아무것도 하지 않습니다. 브라우저 내에 에이전트가 없더라도 동작의 변화도, 리스크도 없습니다.
• 늦었을 때의 비용은 실질적입니다. Chrome의 Gemini가 에이전트 준비가 된 사이트에서 작업 완료를 주도하기 시작할 때, 이미 검색/결제/예약 흐름을 노출해 둔 사이트들은 이탈(abandoned)되는 대신 '완료(completed)'되는 사이트가 될 것입니다. 경쟁사의 전환율(conversion numbers)을 보고 나서야 그 격차를 깨닫고 싶지는 않을 것입니다.

전체 상호작용은 수십 번의 '스크린샷 캡처-해석-클릭' 사이클을 단 한 번의 구조화된 도구 호출(structured tool call)로 대체합니다. 이것이 핵심 제안입니다. 에이전트에게는 신뢰성과 속도를 제공하고, 귀하에게는 에이전트가 헤매지 않고 끝마칠 수 있는 흐름을 제공하는 것입니다.

오늘 무엇을 출시해야 하는가 (솔직한 버전)

아무것도 새로 만들지 마세요. 기존의 것을 감싸고(wrap), 기능을 감지(feature-detect)하며, 만약 사양(spec)이 지연되더라도 잃을 것은 없습니다:

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

귀하의 비즈니스 핵심인 두세 가지 액션—검색, 장바구니 담기, "상담 예약", "견적 받기", "예약 가능 여부 확인"—을 선택하여 그것부터 노출하세요. 단일 진실 공급원(one source of truth)을 유지하십시오: 도구는 귀하의 버튼이 호출하는 것과 동일한 핸들러를 호출합니다.

아무도 말해주지 않는 부분: 계측(instrument)하기

"곧"이라는 막연한 시점을 실제로 관리 가능한 상태로 만드는 방법은 다음과 같습니다. 도구가 등록되면, 모든 에이전트 호출을 기록(log)하세요: 어떤 도구가, 어떤 인자(arguments)로 호출되었는지, 그리고 성공했는지 여부를 기록해야 합니다. Chrome의 Gemini(또는 그 어떤 에이전트라도)가 귀하의 도구 중 하나를 처음으로 호출하는 날, 귀하는 그것을 '직접 확인'할 수 있어야 합니다. 3개월 뒤에 이상한 분석 데이터의 급증을 보고 추측하는 것이 아니라 말입니다.

그 신호는 진정으로 유용합니다:

• 에이전트가 어떤 흐름(flow)을 가장 먼저 사용하는지 알려줍니다 (따라서 다음 흐름에 계측(instrument)을 적용할 수 있습니다).
• 도구 호출(tool calls)이 어디서 실패하는지 알려줍니다 (잘못된 스키마(schema), 모호한 설명, 누락된 파라미터 등) — 이는 눈을 감고는 할 수 없는 에이전트 UX 디버깅(agent UX debugging)입니다.
• 사이트로 유입되는 에이전트 주도 트래픽(agent-driven traffic)을 다른 어디에서도 나타날 만큼 커지기 전에 파악할 수 있는 가장 빠른 방법입니다.

몇 개의 fetch 비콘(beacons)만으로 이를 직접 연결할 수 있습니다. 솔직히 말씀드리면, 저는 Latch에서 일하고 있습니다 — 기존의 검색/장바구니/양식(forms)을 WebMCP 도구로 노출하는 한 줄짜리 오픈 소스 스크립트이며, 유료 티어에서는 정확히 이 정보(어떤 에이전트가 무엇을 호출했는지, 그리고 성공했는지 여부)를 기록합니다. 제가 편향되어 있으니 이 홍보는 가볍게 넘겨주시되 — 우리를 이용하든 본인만의 로깅 엔드포인트(logging endpoint)를 사용하든, 어떻게든 계측(instrument)은 해두십시오. "첫 번째 에이전트가 언제 우리 사이트를 호출했는지, 그리고 무엇을 시도했는지"에 답할 수 있는 팀은, 추측만 하는 팀보다 향후 6개월 동안 훨씬 더 나은 결정을 내리게 될 것입니다.

솔직하게 밝히는 주의사항

• "곧" 될 예정이지, "오늘" 되는 것이 아닙니다. 다음 주에 에이전트 트래픽이 생길 것이라고 PM에게 약속하지 마세요.
• 이것은 **오리진 트라이얼(origin trial)**입니다. API는 변경될 수 있습니다. 안정성을 가정하기보다는 트라이얼에 등록하세요.
• WebKit은 여전히 공식적으로 WebMCP에 반대하고 있습니다. 멀티 엔진의 보편성(ubiquity)은 보장되지 않습니다. 그렇기 때문에 기능 감지(feature-detection, 중단되더라도 잃을 것이 없는 방식)가 올바른 태도입니다.

하지만 핵심적인 상황은 변했으며, 이를 명확히 말할 가치가 있습니다: WebMCP를 도입하지 말아야 할 가장 강력한 이유인 "어떤 에이전트도 이를 호출하지 않을 것이다"라는 주장은 이제 그 유효 기간이 명시되었습니다. 비용이 저렴하고, 되돌릴 수 있으며, 기능 감지(feature-detected)가 가능한 버전을 구현하는 데는 오후 한나절이면 충분합니다. 저는 그 도박에 걸겠습니다.

에이전트 친화적인 사이트를 구축 중이신가요? 벤더 중립적인 설명은 latch.tools/webmcp에서 확인할 수 있으며, 오픈 소스 클라이언트는 GitHub (MIT)에 있습니다.