2026년 10월의 WebMCP: 웹사이트를 AI 에이전트가 쓸 수 있게 만들기, 그리고 오리진 트라이얼의 실제 의미

WebMCP를 쓰면 웹 페이지가 AI 에이전트에게 할 수 있는 일의 짧은 목록을 건네줄 수 있습니다. 각 항목에는 이름, 설명, 입력 스키마가 있습니다. 에이전트가 스크린샷과 DOM만 보고 페이지를 해석해야 하는 상황을 없애는 것입니다. check_order_status 도구를 찾은 에이전트는 주문 번호를 넣어 바로 호출할 수 있습니다. 도구가 없으면 에이전트는 알맞은 입력란을 찾고 알맞은 버튼을 눌러야 합니다.

이것이 약속입니다. 2026년 10월 22일 현재 실제 상황은 대부분의 글이 말하는 것보다 좁습니다. WebMCP는 W3C 커뮤니티 그룹의 제안일 뿐 표준이 아닙니다. Chrome은 이것을 오리진 트라이얼로 운영하고 있으며, 정식 탑재를 결정하지는 않았습니다. 도구를 호출하는 일반 소비자용 에이전트는 하나(ChatGPT 데스크톱 앱에 내장된 브라우저)이고, 이 에이전트는 10월 8일 사양에서 빠진 선언형 폼 방식을 무시합니다. Safari의 엔진 팀은 이 제안에 반대하고, Mozilla는 중립입니다.

이 글은 지금 WebMCP를 도입할지 판단하는 개발자와 제품 책임자를 위한 것입니다. API가 무엇인지, 누가 호출하는지, 실제 방문자에게 어떻게 켜는지, 에이전트에게 장전된 총을 쥐여 주지 않는 도구를 어떻게 작성하는지, 에이전트가 귀사 사이트를 쓰게 하려면 무엇부터 고쳐야 하는지를 다룹니다.

WebMCP란 무엇인가

사양은 document.modelContext에 JavaScript API를 정의하고, 페이지는 이 API로 도구를 등록합니다. “WebMCP API는 웹 애플리케이션이 AI 에이전트에게 JavaScript 기반 도구를 제공할 수 있게 한다.” 도구에는 name, description, execute 콜백이 있고, 선택적으로 title, inputSchema(JSON Schema), annotations를 둘 수 있습니다. 에이전트가 도구를 호출하면 페이지 자체의 코드가 사용자의 세션으로 실행됩니다.

이에 대해 잘못 알기 쉬운 점이 세 가지 있습니다.

• 표준이 아닙니다. 이 문서는 Web Machine Learning 커뮤니티 그룹의 커뮤니티 그룹 초안 보고서이고, 스스로 이렇게 밝힙니다. “W3C 표준이 아니며 W3C 표준 트랙에 올라 있지도 않다.” Chrome 자체 문서도 이를 “제안된 웹 표준”이라고 부릅니다. 보고서 날짜는 10월 내내 며칠마다 바뀌었고, 편집자는 Microsoft와 Google 소속입니다.
• MCP가 들어 있지 않습니다. 사양은 이를 사용하는 페이지를 “클라이언트 측 스크립트로 도구를 구현하는 Model Context Protocol 서버로 볼 수 있다”고 하면서도, 곧이어 “도구를 브라우저 에이전트에 노출하는 형식을 규정하지는 않는다”고 말합니다. Mozilla의 검토는 이를 직설적으로 표현했습니다. “이름이 오해를 부른다 … 여기에 MCP는 없다.” WebMCP 도구는 귀사의 백엔드 MCP 서버에 연결되지 않으며, 그것을 대체하지도 않습니다.
• 귀사를 발견하게 해 주지 않습니다. Chrome 문서가 한계로 직접 적어 두었습니다. “클라이언트와 브라우저는 사이트에 직접 방문해야 호출 가능한 도구가 있는지 알 수 있다.” WebMCP는 이미 귀사 페이지에 와 있는 에이전트를 돕습니다. 발견되는 데에는 아무 도움이 되지 않습니다.

이 API는 보안 컨텍스트로 제한되며, 기본 허용 목록이 'self'인 tools Permissions Policy로 통제됩니다. 따라서 교차 출처 iframe은 이를 포함한 페이지가 허용하지 않는 한 도구를 등록할 수 없습니다.

2026년 10월 22일 현재 상황

원래 트라이얼 기간의 마지막 릴리스인 Chrome 156은 2026년 10월 20일 안정 채널에 올라왔습니다. 연장 요청의 종료 시점인 Chrome 162는 2027년 2월 2일 안정 채널에 오를 예정입니다. 연장이 실제로 적용되었는지는 트라이얼 콘솔에서 확인할 수 없었으므로, 가능성은 높지만 확실하지는 않다는 전제로 계획을 세우십시오.

연장 요청은 Chrome이 시간을 더 원하는 이유를 설명합니다. “OT 피드백에서 API 개선 제안이 나왔고, 우리는 이를 구현하고 있다.” 같은 스레드에서 Google의 도미닉 파롤리노(Dominic Farolino)는 팀이 “연장 기간 안에 I2S로 넘어가기를 바라고” 있다고, 즉 정식 탑재를 요청하려 한다고 썼으며, “명령형 API가 선언형보다 훨씬 많이 쓰이므로 사용자 요구에 맞춰 그쪽에 더 투자하고 있다”고 덧붙였습니다. 그는 이어서 프로토타입 중인 것으로 컨티뉴에이션 API, 도구 안정성 API, 도구 크기 제한도 언급했습니다. 오늘 작성하는 API는 앞으로 바뀝니다.

실제로 도구를 호출하는 것은 누구인가

도구를 등록하는 데는 아무것도 필요하지 않습니다. 도구를 사용하려면 에이전트가 필요한데, 에이전트의 목록은 짧습니다.

Chrome의 자체 테스트 확장 프로그램. Chrome 문서는 데모와 자체 페이지에서 도구를 시험해 볼 수 있는 확장 프로그램 두 가지를 소개하며, 그중 하나가 Model Context Tool Inspector입니다. 이를 쓰려면 자체 모델 API 키가 필요하고, Chrome은 이렇게 적어 두었습니다. “이 확장 프로그램은 Chrome의 Gemini와는 별개이다.” 이것은 개발자용 도구이지 고객이 아닙니다.

ChatGPT의 내장 브라우저. OpenAI 직원이 2026년 8월 25일 개발자 포럼에 올린 글은 “사이트 도구는 제안된 WebMCP 표준을 ChatGPT가 구현한 것이다”라고 밝혔습니다. 문서에는 조건이 있습니다. 특정 모델, 최신 데스크톱 앱, Enterprise 워크스페이스에서는 관리자의 허용, Edu 워크스페이스 제외, 그리고 “제공 여부는 롤아웃에도 달려 있다”는 것입니다. 지원하지 않는 것도 명시합니다. “선언형 API: HTML 폼 속성으로 정의한 도구는 사이트 도구로 사용할 수 없다”, 그리고 같은 출처 iframe을 포함해 iframe 안에 등록된 도구도 지원하지 않습니다. OpenAI의 지침은 분명합니다. “최상위 페이지에서 JavaScript로 도구를 등록하라.” ChatGPT가 페이지의 도구를 보려면 Chrome 오리진 트라이얼 토큰이 필요한지는 문서에 나와 있지 않습니다.

Chrome의 Gemini. Google은 5월에 “곧 WebMCP API를 지원할 예정”이라고 했습니다. 그 뒤로 지원한다고 밝힌 1차 자료는 찾지 못했습니다. 아직 이를 전제로 계획을 세우지 마십시오.

나머지는 모두 기존 방식으로 돌아갑니다. 모든 브라우저의 모든 에이전트는 여전히 예전 방식으로 페이지를 읽습니다. Chrome도 자체 위험 평가에서 그렇게 말합니다. “Chrome의 브라우저 에이전트는 이전처럼 사용자 행동을 흉내 내 사이트를 조작할 수 있다.” OpenAI도 마찬가지입니다. “적합한 도구가 없어도 에이전트는 일반 브라우저 기능으로 처리할 수 있다.” WebMCP가 없는 사이트가 에이전트에게 보이지 않는 것은 아닙니다. 버튼이 고장 나 있고 입력란에 레이블이 없는 사이트는 어떤 에이전트에게나 다루기 어렵습니다.

명령형 API

사양이 정의하고, ChatGPT가 지원하며, Chrome이 개발자들이 더 선호한다고 말하는 것이 이 방식입니다. 도구는 페이지에 이미 있는 로직을 감쌉니다. 다음은 로그인한 고객을 위한 읽기 전용 조회 도구로, Chrome 문서의 형태와 OpenAI의 기능 감지 방식을 따랐습니다.

if (typeof document.modelContext?.registerTool === 'function') {
  const tools = new AbortController();

  await document.modelContext.registerTool({
    name: 'check_order_status',
    description: 'Look up the status and tracking link of one of the signed-in customer\'s orders by its order number.',
    inputSchema: {
      type: 'object',
      properties: {
        orderNumber: { type: 'string', description: 'Order number as printed in the confirmation email' },
      },
      required: ['orderNumber'],
    },
    annotations: { readOnlyHint: true },
    execute: async ({ orderNumber }, { signal }) => {
      const res = await fetch(`/api/orders/${encodeURIComponent(orderNumber)}`, { signal });
      if (!res.ok) return `No order ${orderNumber} was found on this account.`;
      const order = await res.json();
      return `Order ${orderNumber}: ${order.status}. Tracking: ${order.trackingUrl ?? 'not available yet'}.`;
    },
  }, { signal: tools.signal });

  // When the page state no longer fits the tool:
  // tools.abort();
}

중요한 점은 다음과 같습니다.

• 모델이 읽는 것은 이름, 설명, 스키마입니다. Chrome은 도구 설명은 500자, 매개변수 설명은 150자, 도구와 매개변수 이름은 30자, 도구 출력은 1.5K자 이내를 권장하며 “이 권장 사항은 바뀔 수 있다”고 덧붙입니다. 사양의 설명서는 “도구를 너무 많이(수십 개, 수백 개) 노출하면 에이전트 성능이 심각하게 떨어질 수 있다”고 경고합니다. 현재 페이지 상태에 필요한 것만 등록하고, 나머지는 AbortController 시그널로 제거하십시오.
• execute의 두 번째 인수에는 AbortSignal이 들어 있어 취소된 호출이 진행 중인 요청을 멈출 수 있습니다.
• 어노테이션은 힌트입니다. readOnlyHint는 조회용임을 나타냅니다. consequentialHint는 예약, 구매, 전송, 삭제, 이체처럼 결과가 따르는 모든 작업에 붙이며, Chrome 문서에 따르면 이것이 “에이전트와 브라우저가 필수 사용자 확인 창을 강제할 수 있게 한다”고 합니다. untrustedContentHint는 후기, 사용자 콘텐츠, 제3자 데이터가 들어 있는 출력에 붙입니다. debugging 어노테이션은 Chrome 156부터 있습니다.
• 페이지 코드도 도구를 나열하고 실행할 수 있습니다. document.modelContext.getTools()와 executeTool()을 쓰며, 목록이 바뀌면 toolchange 이벤트가 발생합니다. executeTool()에 JSON 문자열로 바꾼 인수를 넘기는 방식은 Chrome 155부터 사용이 권장되지 않습니다.

React, Angular, Vue에는 각각 실험적 도우미가 있고, webmcp-types npm 패키지는 TypeScript 타입을 제공합니다. navigator.modelContext를 호출하는 예전 튜토리얼은 낡았습니다. 사양이 2026년 5월 27일 이 API를 document로 옮겼기 때문입니다.

선언형 API: Chrome 트라이얼에는 있고 사양에서는 빠졌다

선언형 방식은 속성 두 개로 기존 HTML 폼을 도구로 바꿉니다. 다른 것을 전혀 바꿀 필요가 없으므로 오래된, 폼 위주의 사이트에는 매력적입니다.

<form toolname="request_quote"
      tooldescription="Send a request for a quote. The user reviews the form and submits it."
      action="/quote" method="post">
  <label for="email">Work email</label>
  <input id="email" name="email" type="email" required>
  <label for="details">What you need</label>
  <textarea id="details" name="details" required></textarea>
  <button type="submit">Send</button>
</form>
<script>
  document.querySelector('form[toolname]').addEventListener('submit', (e) => {
    e.preventDefault();
    const sent = sendQuoteRequest(new FormData(e.target)); // your existing submit, returning a promise
    if (e.agentInvoked) e.respondWith(sent.then(() => 'Quote request sent.'));
  });
</script>

Chrome 트라이얼에서는 “에이전트가 toolname을 호출하면 브라우저가 폼에 포커스를 맞추고 필드를 채운다. 폼은 사용자에게 계속 보인다.” 브라우저는 컨트롤의 이름, <label>, required, <select>의 옵션으로 매개변수를 만듭니다. 폼에 toolautosubmit이 없으면 “작업을 마치려면 사용자가 직접 제출을 눌러야 한다”는데, 주문이나 리드를 보내는 폼이라면 바로 이것이 필요한 동작입니다. SubmitEvent.agentInvoked는 에이전트가 폼을 채웠음을 핸들러에 알려 주고, preventDefault() 뒤에 respondWith()를 호출하면 결과를 에이전트에게 돌려줍니다. toolactivated와 toolcancel 이벤트는 document.modelContext에서 addEventListener로 수신하십시오. window.ontoolactivated와 window.ontoolcancel은 Chrome 156부터 지원되지 않습니다.

문제는 이 방식의 위상입니다. 설명서에 가장 최근 올라온 변경 사항(2026년 10월 8일)의 제목은 “Remove declarative API from the spec for now”이고, 지금은 선언형 대응 방식이 “별도로 검토되고 있지만 현재는 사양의 일부가 아니다”라고 적혀 있습니다. ChatGPT는 이를 지원하지 않습니다. Chrome은 여전히 트라이얼 문서에 이를 싣고 있으며, Google의 파롤리노는 Mozilla의 스레드에서 “특히 폼 기반인 레거시 웹사이트에는 선언형 제안에 가치가 있다고 본다”고 주장했습니다. 실험 안의 Chrome 실험으로 보십시오. 시험해 볼 만하지만 유일한 경로로 삼기에는 현명하지 않습니다.

실제 방문자에게 켜기

플래그(chrome://flags/#enable-webmcp-testing)는 자신의 브라우저에서 WebMCP를 켜서 시험하게 해 줍니다. 방문자에게는 아무 효과가 없습니다. 방문자에게 켜려면 페이지에 오리진 트라이얼 토큰이 있어야 합니다.

1. Chrome의 WebMCP 트라이얼 페이지에서 오리진을 등록합니다. 오리진 트라이얼은 “공개되어 있고 모든 개발자가 참여할 수 있으며”, 토큰은 “해당 오리진의 모든 사용자에게 기능을 활성화한다”고 합니다.
2. 도구를 노출할 모든 페이지에서 토큰을 제공합니다. <head>의 <meta http-equiv="origin-trial" content="...">로 하거나 Origin-Trial: 응답 헤더로 보냅니다. 스크립트에서 토큰을 주입할 수도 있습니다. 토큰 하나는 오리진 하나에 적용되며, 한 페이지에 토큰 여러 개를 둘 수 있습니다.
3. 갱신하십시오. 트라이얼이 연장되면 Chrome은 등록자에게 “트라이얼에 등록된 오리진마다 새 토큰을 제공하라”고 요청하며, “Chrome은 유효하지 않거나 만료된 토큰을 무시한다”고 합니다. 토큰이 만료되면 아무 경고 없이 실패합니다. 도구가 그냥 나타나지 않게 됩니다.
4. Edge는 Edge의 트라이얼 페이지에서 따로 등록합니다. 약관은 “가능한 경우 기능 감지와 점진적 성능 저하 처리를 적용하는 데 동의한다”고 요구합니다.

Lighthouse의 WebMCP 감사도 트라이얼 등록이 필요하므로, 토큰 없이 시험하는 사이트에서는 이 감사가 실패하는 것으로 나옵니다.

안전하게 호출할 수 있는 도구 작성하기

사양의 보안 절은 규범이 아니며, 부담이 어디에 있는지를 솔직하게 밝힙니다. 에이전트가 조종당하지 않도록 막는 일은 “이 사양이 규범적으로 강제할 수 있는 것이 아니라 주로 에이전트 자체 보안 모델의 책임이다”라고 합니다. 그래도 조종당한 에이전트가 얼마나 큰 피해를 줄 수 있는지는 귀사의 도구가 정합니다.

• 힌트는 거짓일 수 있으므로 에이전트는 믿지 않습니다. 사양은 “악의적인 사이트는 이 힌트를 생략하거나 허위로 표시할 수 있다”고 합니다. OpenAI는 “도구의 이름이나 데이터를 읽기만 한다는 주장은 그 도구가 실제로 하는 일의 증거가 아니다”라고 하며, 자사 브라우저의 모든 호출에 안전 검토를 거치고 구매와 같은 작업에는 계속 확인을 요구합니다. 그래도 정직하게 어노테이션을 붙이십시오. 신중한 에이전트는 이것으로 사용자에게 언제 물어볼지 정합니다.
• 효과를 정확하게 설명하십시오. 사양이 직접 든 나쁜 예는 “현재 장바구니를 확정한다”고 설명된 도구가 “실제로는 구매를 일으키는” 경우입니다. “사용자는 아무것도 사려고 하지 않았다.” 도구가 카드를 결제한다면 설명에 그렇게 적고 consequentialHint를 true로 설정하십시오.
• 권한 확인은 매번 서버에서 하십시오. 도구는 사용자의 세션으로 실행됩니다. 사양은 “에이전트는 브라우저로부터 사용자 신원과 인증 컨텍스트를 물려받을 수 있다”고 밝힙니다. 도구 호출은 그 사용자가 보낸 요청이므로 같은 검증을 거쳐야 합니다. 설명서의 조언이 유효합니다. “스키마에서는 느슨하게, 코드에서는 엄격하게 검증하라.” 스키마 검증이 엄격하면 에이전트가 멈출 수 있기 때문입니다.
• 프롬프트 인젝션에 대비하십시오. 사양은 이것을 맨 앞에 두고 세 가지 형태를 듭니다. 도구 메타데이터에 숨긴 지시, 도구 출력에 숨긴 지시, 그리고 도구를 공격 대상으로 삼는 공격입니다. 다른 사람이 쓴 텍스트(후기, 메시지, 상품 문의)가 들어 있는 출력은 untrustedContentHint 아래에 두고, 에이전트가 지시로 받아들일 수 있는 문장이 아니라 데이터로 반환해야 합니다.
• 페이지를 의도적으로 제외하십시오. Permissions-Policy: tools=() 헤더를 쓰면 해당 문서와 그 안에 포함된 모든 것에서 API를 쓸 수 없게 됩니다. 계정 설정, 결제 페이지, 관리자 화면이 후보입니다.

Chrome 문서에 관해 한 가지 주의할 점이 있습니다. 보안 페이지는 초안에 도구 실행 중 사용자에게 묻는 requestUserInteraction() 메서드가 있다고 하지만, 2026년 10월 20일자 사양 초안에는 그런 메서드가 없고, 설명서도 사용자 확인을 여전히 미해결 질문으로 남겨 두고 있습니다. 이를 전제로 설계하지 마십시오.

Safari와 Firefox 엔지니어들이 반대하는 이유

Chrome만 대상으로 개발한다 해도 이들의 반론은 읽어 볼 만합니다. WebMCP가 실제로 어떻게 잘못될 수 있는지를 보여 주기 때문입니다.

2026년 6월 3일 게시된 WebKit의 입장은 사용하기 어려운 페이지는 HTML과 ARIA로 고쳐야 한다고 주장합니다. 그래야 “사용자, 보조 기술, 에이전트가 모두 혜택을 받기” 때문이며, 도구를 쓰면 “취약성이 DOM에서 도구 설명으로 옮겨 갈 뿐”이라는 것입니다. WebKit은 에이전트를 특별히 구별해서는 안 되는 보조 기술로 봅니다. “WebMCP는 정반대로 ‘에이전트가 조작 중이다’를 관찰 가능한 사실로 만든다.” 또 이 제안에는 “결과가 따르는 작업에 대한 동의 및 되돌리기 모델이 없다”고 지적합니다.

Mozilla는 8월에 중립으로 정리했습니다. WebMCP는 “잠재적으로 가치 있는 추상화를 도입”하지만 “실제 동작 양상에 대한 미해결 질문이 너무 많아 선뜻 지지하기 어려운 영역을 연다”는 것입니다. 사이트가 “페이지에 있는 사용자의 경험과 일치하지 않는 도구를 제공”할 수 있다고, 예를 들어 “일반 사용자에게는 보이지 않는 프롬프트 인젝션을 제공”할 수 있다고 경고합니다. Mozilla의 일부 엔지니어는 명령형 함수 호출 기본 요소에 관심을 보였지만, 이는 Mozilla의 지지가 아닙니다.

Chrome 자체는 다른 엔진이 WebMCP를 채택하지 않을 위험이 사용자에게는 낮다고 평가합니다. 이를 뒤집어 말하면, 오늘 도구를 추가해도 Safari나 Firefox에서는 얻는 것이 없다는 뜻입니다.

지금 모든 에이전트에 통하는 것

모든 브라우저 에이전트는 스크린샷, HTML, 접근성 트리를 읽습니다. 에이전트 친화적인 사이트에 대한 Google의 web.dev 가이드는 에이전트가 “DOM과 접근성 트리로 상호작용 가능한 요소의 깔끔한 구조화된 목록을 얻은 다음, 이를 시각적 렌더링과 교차 확인한다”고 말합니다. 실무 목록은 짧습니다.

• 클릭 가능한 <div>와 <span>이 아니라 진짜 <button>과 <a> 요소를 쓰십시오.
• 모든 <label>을 for로 입력란에 연결하십시오.
• 상호작용 요소 위에 투명한 오버레이를 두지 말고, 8제곱픽셀보다 작은 상호작용 요소를 만들지 마십시오.
• 에이전트가 클릭하려는 순간에 흔들리지 않는 안정적인 레이아웃을 쓰십시오.

가이드의 결론은 이렇습니다. “사이트를 ‘에이전트 대응’으로 만들려고 우리가 제안하는 모든 것은 사이트를 사람에게도 더 낫게 만든다.” 이것은 WebKit이 WebMCP 대신 요구하는 바와 거의 한 글자도 다르지 않습니다. 귀사의 체크아웃이 접근성 감사를 통과하지 못한다면, 도구를 하나 작성하기 전에 그것부터 고치십시오.

Lighthouse에는 버전 13.2.0(2026년 5월 1일)부터 Agentic Browsing 카테고리가 있으며 Chrome에서는 버전 150부터, PageSpeed Insights API에서는 Lighthouse 13.4.1(2026년 7월 20일)부터 사용할 수 있습니다. 이 카테고리는 기계에 중요한 접근성 감사의 일부, 레이아웃 안정성, 등록된 WebMCP 도구와 도구가 없는 폼, 스키마 유효성, llms.txt 파일의 존재 여부를 검사합니다. Chrome은 이를 “참고용이며 벤치마크가 없다”고 부릅니다. 0에서 100까지의 점수는 없습니다. llms.txt에 대해 Google 검색 자체의 가이드는 그런 파일을 무시한다는 것입니다. 추가해도 “Google 검색에서 사이트의 노출이나 순위에 해가 되지도 도움이 되지도 않는다”고 합니다. Lighthouse가 그 파일을 검사한다고 해서 이 사실이 바뀌지는 않습니다.

지금 WebMCP를 도입해야 할까

Liquid 테마를 쓰는 Shopify라면: 할 일이 없습니다. Shopify의 스토어프론트, 장바구니, 체크아웃 도구는 이미 제공되고 있고 “설치하거나 설정할 것이 없습니다”. 다만 Shopify 자체의 단서가 붙습니다. “에이전트 지원은 현재 오리진 트라이얼을 통한 Chromium 기반 브라우저로 제한된다.” 헤드리스 스토어프론트는 Hydrogen 개발자 프리뷰에서만 지원됩니다. 고객을 위해 WebMCP를 켜 주는 다른 커머스 플랫폼, 결제 서비스 업체, CDN은 찾지 못했습니다.

자체 개발, 헤드리스, 레거시 사이트라면: 사용자가 누구인지에 따라 다릅니다.

• 고객이나 직원이 ChatGPT 데스크톱 앱의 브라우저를 쓴다면, 그들에게 닿는 것은 최상위 페이지의 명령형 도구뿐입니다. 가장 흔한 작업(주문 상태, 재고 확인, 견적)에 대한 읽기 전용 도구 두세 개로 시작하십시오. 기능 감지를 걸고, 오리진 트라이얼 토큰을 붙이고, 누군가 호출하는지 측정하십시오.
• Chrome에서 비용을 적게 들여 실험해 보고 싶다면, 기존 폼에 선언형 속성을 붙이는 데는 몇 시간이면 충분합니다. 거기서 멈추지는 마십시오. ChatGPT는 이를 보지 못하고, 사양에도 더 이상 들어 있지 않습니다.
• 에이전트가 귀사를 방문한다는 근거가 없다면 시맨틱, 레이블, 레이아웃부터 고치십시오. 이 작업은 모든 에이전트와 보조 기술을 쓰는 모든 사람에게 도움이 되며, API가 바뀌어도 버려지는 것이 하나도 없습니다.

어느 경우에도 일반 인터페이스는 온전하게 유지하십시오. OpenAI의 조언은 이렇습니다. “WebMCP를 지원하지 않는 사람과 브라우저를 위해 일반 인터페이스를 그대로 유지하라.”

바뀔 수 있는 것

• Intent to Ship. Chrome 팀은 연장 기간 안에 이를 요청하기를 바라고 있으며, 연장이 유지된다면 그 기간은 Chrome 162(2027년 2월 2일)로 끝납니다. 탑재가 이루어지면 Chrome에서는 토큰이 필요 없어집니다.
• API의 형태. 컨티뉴에이션 API(탐색 뒤 다음 페이지에 도착하는 결과), 도구 안정성 API, 크기 제한이 프로토타입 단계에 있습니다. 최근 릴리스에서는 이미 window.ontoolactivated와 문자열로 바꾼 인수를 제거했습니다.
• 선언형 API의 운명. 사양에서는 “당분간” 빠졌고, Chrome 트라이얼에는 남아 있습니다.
• 호출 주체. Chrome의 Gemini 지원은 발표되었지만 출시되지는 않았습니다. 사양의 구현 현황 페이지는 Meta의 Ray-Ban Display 안경에서 웹 앱용 WebMCP가 곧 제공된다고, 그리고 Brave의 Leo 어시스턴트에서 실험적 지원이 이루어진다고 적고 있습니다.

지금 도구를 추가한다면 하나의 모듈에 모으고 기능 감지 뒤에 두십시오. 그러면 다음 변경이 한 번의 수정으로 끝납니다.

도움이 필요하시면

저희는 웹사이트와 백엔드 가운데 에이전트가 건드리는 부분을 구축합니다. 기존 주문, 예약, 계정 로직을 감싸는 도구, 에이전트의 호출을 해당 사용자의 다른 요청과 똑같이 취급하는 권한 확인, 도구가 생기기 전에 사이트를 쓸 수 있게 만드는 시맨틱과 접근성 개선입니다. 저희의 AI 에이전트 개발 및 MCP 서버 연동 서비스는 WebMCP 도구와 백엔드 MCP 서버를 모두 다룹니다. 이름은 비슷하지만 두 가지는 다른 것입니다.

지금 에이전트가 귀사 사이트에서 무엇을 보는지, 도구가 고객에게 달라지는 점이 있을지 알고 싶으시면 office@c9group.dev로 문의해 주십시오.