AI가 대신 홈페이지를 조작하게 하는 WebMCP, 무엇이 달라지나

AI가 대신 홈페이지를 조작하게 하는 WebMCP, 무엇이 달라지나

---

웹사이트가 더 이상 "사람이 읽는 화면"만이 아니라 "AI 에이전트가 직접 조작하는 대상"으로 바뀌고 있습니다. 지금까지 AI 챗봇이 웹사이트 정보를 가져오려면 화면을 스크린샷처럼 읽거나 크롤링에 의존해야 했지만, WebMCP가 등장하면서 이야기가 완전히 달라졌습니다.

2026년 9월 17일 기준 최신 초안에 따르면 WebMCP는 웹 애플리케이션이 AI 에이전트에 JavaScript 기반 도구를 제공하는 API로 정의됩니다. 즉 웹사이트 운영자가 "이 사이트에서는 이런 작업을 이렇게 실행할 수 있다"는 설명서를 코드로 직접 작성해두면, 브라우저나 확장 프로그램에 내장된 AI 에이전트가 그 문서를 방문했을 때 이를 발견하고 호출할 수 있게 되는 구조입니다.

다만 9월 20일 현재 WebMCP는 W3C 표준이나 표준화 트랙의 규격이 아니라 제안된 웹 표준이자 초기 미리보기 단계라는 점을 먼저 짚고 가야 합니다. Chrome은 2026년 6월 9일 Chrome 149에서 WebMCP Origin Trial을 시작한다고 발표했지만, 이는 정식 기능 출시가 아니라 기간이 제한된 실험적 조기 접근 프로그램입니다. 이 글에서는 WebMCP가 실제로 어떤 방식으로 동작하는지, HTML 폼 설계와 보안 측면에서 무엇을 준비해야 하는지 하나씩 풀어드리겠습니다. 🚀

---

시작 전에 확인해야 할 준비물과 전제조건

WebMCP를 실험하려면 무엇보다 "실험 단계 기술"이라는 전제를 먼저 받아들여야 합니다. 정식 안정 기능이 아니기 때문에 프로덕션 환경에 성급하게 적용하기보다는 개발 환경에서 먼저 검증하는 태도가 필요합니다.

준비물은 크게 세 가지입니다.
먼저, Chrome 149 이상 버전이 필요합니다. Origin Trial 참여 없이 로컬에서 테스트하고 싶다면 `chrome://flags/#enable-webmcp-testing` 플래그를 켜면 되는데, 이 역시 안정 기능 지원을 뜻하지 않는다는 점을 문서가 명시하고 있습니다.
다음으로, JavaScript와 HTML form 요소에 대한 기본 이해가 있어야 합니다. Imperative API는 순수 JavaScript로 도구를 등록하고, Declarative API는 HTML 속성을 활용하기 때문에 두 방식 모두 프런트엔드 기초 지식이 전제됩니다.
마지막으로, DevTools를 다뤄본 경험이 있으면 훨씬 수월합니다. Chrome 149 DevTools에는 실험적 WebMCP 기능이 포함돼 있어 도구 등록 여부와 실행 결과를 눈으로 확인할 수 있습니다.

전제조건도 명확히 해두어야 합니다.
MCP(Model Context Protocol)와 WebMCP는 다른 계층의 기술입니다. MCP는 지속적이고 플랫폼 범용적인 연결에 초점을 두는 반면, WebMCP는 지금 열려 있는 브라우저 페이지의 실시간 상호작용을 담당합니다. 이 둘을 같은 개념으로 혼동하면 설계 방향 자체가 틀어질 수 있으니 처음부터 구분해서 접근하시길 권합니다.

---

Step 1: Imperative API로 첫 도구 등록해보기

Imperative API는 `document.modelContext.registerTool()`이라는 하나의 함수 호출로 AI 에이전트가 사용할 도구를 등록하는 방식입니다. 2026년 5월 18일 공개된 공식 문서에 따르면 이 방식으로 도구 이름, 설명, 입력 스키마, 실행 로직(`execute` 함수)을 한 번에 정의할 수 있습니다.

예를 들어 쇼핑몰에서 "장바구니에 상품을 추가하는" 기능을 AI 에이전트에 노출하고 싶다면, 개발자는 `registerTool()`을 호출하면서 도구 이름을 지정하고, 자연어로 된 설명(예: "지정한 상품 ID와 수량으로 장바구니에 항목을 추가합니다")을 작성하며, 입력값의 구조를 JSON Schema 형태로 정의합니다. 그리고 실제 장바구니에 담는 로직을 `execute` 함수 안에 구현하면 됩니다.

여기서 주의할 점이 몇 가지 있습니다.
첫째, 도구 이름 규칙을 반드시 지켜야 합니다. 2026년 9월 17일 초안에 따르면 도구 이름은 1~128자여야 하며, ASCII 영숫자와 밑줄(`_`), 하이픈(`-`), 마침표(`.`)만 사용할 수 있습니다. 한글이나 공백, 특수문자를 이름에 넣으면 등록 단계에서 오류가 날 수 있으니 처음부터 영문 규칙에 맞춰 설계하시길 권합니다.
둘째, `AbortSignal`을 활용한 실행 취소 지원을 염두에 두어야 합니다. 도구 실행이 오래 걸리거나 사용자가 중간에 페이지를 떠나는 경우를 대비해 취소 가능한 구조로 만들어야 실제 서비스에서 안정적으로 동작합니다.
셋째, 2026년 9월 11일 갱신된 문서는 Chrome 153부터 도구 해제 시 진행 중인 실행을 취소하지 않는 방식도 가능하다고 설명합니다. 즉 도구가 사라져도 이미 시작된 작업은 끝까지 완료되게 만들 수 있다는 뜻인데, 이는 결제나 예약처럼 중간에 끊기면 안 되는 작업에서 특히 중요한 선택지가 됩니다.

Imperative API는 자유도가 높은 만큼 상태 관리를 개발자가 직접 책임져야 합니다. 도구가 여러 개 등록될수록 이름 충돌이나 스키마 불일치가 발생하지 않도록 초기 설계 단계에서 네이밍 컨벤션을 먼저 정해두는 습관이 중요합니다.

---

Step 2: Declarative API로 HTML 폼을 AI 도구로 바꾸기

Declarative API는 이미 존재하는 HTML form에 몇 가지 속성만 추가하면 AI 에이전트가 호출할 수 있는 도구로 바뀌는 방식입니다. JavaScript를 새로 작성할 필요 없이 기존 폼 구조를 그대로 활용할 수 있다는 점이 가장 큰 장점입니다.

구체적으로는 form 태그에 `toolname`과 `tooldescription` 속성을 추가하는 것부터 시작합니다. `toolname`은 앞서 설명한 이름 규칙(1~128자, ASCII 영숫자·밑줄·하이픈·마침표)을 그대로 따라야 하고, `tooldescription`에는 이 폼이 어떤 작업을 수행하는지 자연어로 풀어 씁니다.

폼 내부의 입력 필드는 자동으로 JSON Schema의 매개변수로 변환되는데, 여기에 `toolparamdescription` 속성을 추가하면 각 입력값이 무엇을 의미하는지 AI 에이전트에 더 구체적으로 설명할 수 있습니다. 예를 들어 배송지 입력 필드에 `toolparamdescription="수령인이 실제로 물건을 받을 도로명 주소"`라고 적어두면, AI 에이전트가 이 필드에 어떤 값을 넣어야 하는지 훨씬 정확하게 판단하게 됩니다.

여기서 실무적으로 눈여겨봐야 할 속성이 하나 더 있습니다. `toolautosubmit`을 폼에 추가하면 에이전트가 도구를 호출한 뒤 자동으로 제출과 내비게이션까지 이어지도록 구성할 수 있습니다. 이는 검색 폼처럼 "입력 후 즉시 결과 페이지로 이동해야 하는" 흐름에 특히 유용합니다.

Declarative API를 설계할 때 주의할 점은 다음과 같습니다.
먼저, 필드마다 의미가 명확하게 드러나도록 `toolparamdescription`을 꼼꼼히 채워야 합니다. 설명이 부실하면 AI 에이전트가 엉뚱한 값을 채워 넣을 가능성이 커집니다.
다음으로, 자동 제출이 필요 없는 폼에 `toolautosubmit`을 무분별하게 붙이지 않아야 합니다. 결제나 회원 탈퇴처럼 사용자 확인이 필수적인 작업에 자동 제출을 적용하면 의도치 않은 실행으로 이어질 위험이 있습니다.
마지막으로, 기존에 이미 검증 로직(required, pattern 등)이 걸려 있는 폼이라면 그 검증 규칙이 AI 에이전트의 입력값에도 동일하게 적용되는지 반드시 테스트해봐야 합니다.

Declarative API는 새로운 코드를 작성하는 부담이 적은 대신, 복잡한 다단계 흐름이나 조건부 로직에는 한계가 있습니다. 이런 경우에는 Imperative API와 병행하는 설계가 더 적합합니다.

---

Step 3: MCP와 WebMCP의 역할 차이를 명확히 구분하기

WebMCP는 MCP를 대체하는 기술이 아니라 서로 다른 계층에서 보완적으로 동작하는 별개의 개념입니다. 2026년 5월 19일 갱신된 공식 비교 문서는 이 둘의 차이를 명확히 구분하고 있는데, 이를 제대로 이해하지 못하면 설계 방향 자체가 어긋날 수 있습니다.

MCP는 AI 에이전트가 다양한 외부 시스템(데이터베이스, API, 파일 시스템 등)에 지속적이고 플랫폼 범용적으로 연결되도록 설계된 프로토콜입니다. 즉 에이전트가 어떤 환경에 있든 동일한 방식으로 도구에 접근할 수 있게 해주는 것이 목표입니다.

반면 WebMCP는 현재 열려 있는 브라우저 페이지의 실시간 상호작용만을 담당합니다. 공식 문서는 WebMCP 도구가 페이지가 열려 있을 때만 존재하며, 탭을 닫거나 다른 사이트로 이동하면 그 도구는 더 이상 사용할 수 없다고 명시합니다. 이 차이는 실무에서 굉장히 중요한데, 예를 들어 여러 사이트를 넘나들며 정보를 종합해야 하는 복잡한 작업은 WebMCP만으로는 처리할 수 없고 MCP 같은 지속적 연결 구조가 별도로 필요하다는 뜻이기 때문입니다.

이를 도식으로 정리하면 다음과 같은 대응 관계가 성립합니다.
먼저, MCP는 "여러 시스템을 넘나드는 장기 세션"에 적합합니다.
다음으로, WebMCP는 "지금 보고 있는 이 페이지 안에서의 즉각적인 작업"에 적합합니다.
그리고, 두 기술은 함께 쓰일 수도 있습니다. 예를 들어 MCP로 연결된 AI 에이전트가 브라우저 확장 프로그램을 통해 특정 웹페이지에 진입한 뒤, 그 페이지에 등록된 WebMCP 도구를 호출하는 조합도 가능합니다.

이 차이를 설계에 반영할 때 주의할 점이 있습니다.
WebMCP로 노출한 도구는 "그 페이지를 실제로 방문해야만" 발견될 수 있다는 한계가 있습니다. 공식 문서 역시 이 점을 WebMCP의 한계로 명시하고 있는데, 사이트를 직접 방문해야 도구를 발견할 수 있고, 사람의 개입이 있는 로컬 브라우저 흐름에 주로 맞춰져 있으며, 복잡한 인터페이스에는 추가 JavaScript와 상태 관리가 필요할 수 있다는 점입니다. 따라서 "우리 사이트에 WebMCP 도구를 등록해두면 AI가 알아서 찾아와 실행해줄 것"이라는 기대는 현재로선 성립하지 않습니다. 사용자가 브라우저로 그 페이지에 있어야 하고, 그 안에서 에이전트가 동작해야만 도구가 발동합니다.

---

Step 4: 동일 출처·교차 출처 보안 조건과 DevTools 점검법 익히기

WebMCP 도구는 기본적으로 origin isolation과 Permissions Policy의 적용을 받기 때문에, 교차 출처 환경에서는 별도의 허용 설정 없이는 동작하지 않습니다. 이는 보안 설계에서 가장 먼저 확인해야 할 조건입니다.

공식 문서에 따르면 WebMCP의 `tools` Permissions Policy 기본값은 `self`입니다. 즉 기본적으로는 같은 출처 내에서만 도구가 노출되고, 교차 출처 iframe에서 WebMCP 도구를 사용하려면 `allow="tools"` 속성을 명시적으로 추가해야 합니다. 2026년 9월 17일 초안은 여기서 한 걸음 더 나아가, 도구 등록 시 허용 출처 목록도 함께 지정하도록 규정하고 있습니다. 즉 "이 도구는 어느 출처에서 호출될 수 있는지"를 도구를 만든 쪽이 직접 통제할 수 있는 구조입니다.

보안 힌트도 함께 알아두어야 합니다. 2026년 9월 1일 Chrome 보안 문서는 WebMCP의 대표적 공격 벡터로 두 가지를 제시합니다.
하나는 '악성 매니페스트'로, 도구 이름·설명·매개변수 안에 숨은 지시문을 심어 AI 에이전트를 의도치 않은 방향으로 유도하는 방식입니다.
다른 하나는 '오염된 출력'으로, 외부 데이터가 실행 결과에 섞여 들어가 에이전트가 잘못된 정보를 신뢰하게 만드는 방식입니다.

이를 막기 위해 문서는 세 가지 힌트 속성을 제공합니다.
첫째, `readOnlyHint`는 이 도구가 데이터를 읽기만 하고 변경하지 않는다는 것을 표시합니다.
둘째, `untrustedContentHint`는 도구의 결과물이 신뢰할 수 없는 외부 콘텐츠를 포함할 수 있다는 것을 명시합니다.
셋째, `consequentialHint`는 예약이나 송금처럼 되돌리기 어려운 중대한 작업임을 표시합니다.

이 세 가지 힌트를 도구 등록 시 정확히 붙여두면, AI 에이전트나 이를 감독하는 시스템이 "이 작업은 사용자 확인이 필요하다"는 판단을 내리는 데 도움이 됩니다.

실제 점검은 Chrome 149 DevTools의 실험적 WebMCP 기능으로 진행하면 됩니다. 2026년 6월 2일 발표된 이 기능은 Application 패널에서 등록된 도구와 스키마를 확인할 수 있고, 사용자가 지정한 매개변수로 직접 실행해볼 수 있으며, 호출 상태와 반환된 payload까지 점검할 수 있습니다. 다만 이 기능을 쓰려면 `#devtools-webmcp-support`와 `#enable-webmcp-testing` 두 플래그를 모두 켜야 한다는 점을 잊지 마시길 바랍니다.

---

자주 발생하는 오류와 해결 방법

WebMCP를 처음 적용할 때 가장 흔한 실수는 도구 이름 규칙 위반과 Permissions Policy 설정 누락입니다. 실험 단계 기술이다 보니 문서를 꼼꼼히 확인하지 않으면 사소한 지점에서 막히는 경우가 많습니다.

가장 자주 발생하는 오류들을 정리하면 다음과 같습니다.
첫째, 도구 이름에 한글이나 공백을 사용해 등록이 실패하는 경우입니다. 앞서 설명했듯 도구 이름은 1~128자의 ASCII 영숫자, 밑줄, 하이픈, 마침표만 허용되므로 한글 서비스명을 그대로 도구 이름에 쓰면 오류가 납니다. 도구 이름은 영문으로, 사용자에게 보여줄 설명은 `tooldescription`이나 도구 설명 필드에 따로 작성하는 방식으로 분리하시길 권합니다.
둘째, 교차 출처 iframe에서 도구가 보이지 않는 경우입니다. 이는 대부분 `allow="tools"` 속성을 빠뜨렸기 때문입니다. iframe으로 삽입된 결제 위젯이나 외부 위젯에 WebMCP 도구를 노출하려 한다면 이 속성부터 확인해야 합니다.
셋째, 플래그를 켰는데도 DevTools에 WebMCP 패널이 보이지 않는 경우입니다. `#devtools-webmcp-support`와 `#enable-webmcp-testing` 두 플래그 중 하나만 켜져 있으면 패널이 나타나지 않으므로, 두 플래그 모두 활성화됐는지 다시 확인해야 합니다.
넷째, 도구 실행 중 페이지를 이동했더니 작업이 갑자기 끊기는 경우입니다. 이는 AbortSignal 처리 방식과 관련된 문제로, Chrome 153 이전 버전에서는 도구 해제 시 진행 중인 실행이 함께 취소되는 것이 기본 동작이기 때문입니다. 결제나 예약처럼 중단되면 안 되는 작업이라면 이 동작 차이를 반드시 고려해서 설계해야 합니다.

이런 오류들은 대부분 공식 문서의 최신 갱신 내용을 놓쳤을 때 발생합니다. WebMCP는 아직 초안 단계라 스펙이 자주 바뀌므로, 적용 전 항상 최신 문서를 다시 확인하는 습관이 중요합니다.

---

실무에 적용할 때 알아두면 좋은 활용 팁

WebMCP를 도입할 때 가장 중요한 원칙은 "완성된 기능"이 아니라 "실험적 미리보기"로 접근하는 태도입니다. 이 전제를 바탕으로 몇 가지 실무 팁을 정리해보겠습니다.

먼저, 도구 설명은 AI 에이전트가 읽는 문서라는 사실을 항상 기억해야 합니다. 사람이 읽는 UI 라벨과 AI 에이전트가 읽는 `tooldescription`은 역할이 다릅니다. 사람에게는 "장바구니 담기" 버튼 하나면 충분하지만, AI 에이전트에는 이 버튼이 정확히 어떤 입력을 받고 어떤 결과를 내는지 자연어로 상세히 설명해줘야 오작동을 줄일 수 있습니다.

다음으로, Imperative API와 Declarative API를 상황에 맞게 병행하는 것이 효율적입니다. 단순한 검색 폼이나 문의 폼처럼 기존 HTML form 구조를 그대로 활용할 수 있는 경우에는 Declarative API로 빠르게 전환하고, 복잡한 상태 관리나 다단계 로직이 필요한 기능(예: 재고 확인 후 조건부로 장바구니 담기)은 Imperative API로 세밀하게 제어하는 방식이 합리적입니다.

그리고, 보안 힌트 속성을 처음부터 습관적으로 붙이는 것이 좋습니다. `readOnlyHint`, `untrustedContentHint`, `consequentialHint` 세 가지는 나중에 추가하려면 기존 도구 전체를 다시 점검해야 하는 번거로움이 생기므로, 도구를 처음 설계하는 단계부터 각 도구의 성격을 분류해두는 습관을 들이시길 권합니다.

마지막으로, DevTools의 실험적 WebMCP 패널을 배포 전 검증 도구로 적극 활용하시길 바랍니다. 도구 스키마가 의도한 대로 노출되는지, 매개변수 이름과 설명이 명확한지, 실행 결과 payload가 예상과 일치하는지를 실제 AI 에이전트 없이도 DevTools 안에서 미리 확인할 수 있다는 점은 개발 생산성 측면에서 큰 이점입니다.

이 네 가지 원칙을 지키면 아직 표준화되지 않은 기술이라도 안정적으로 실험하고 점진적으로 확장해나갈 수 있습니다.

---

앞으로 더 넓게 활용할 수 있는 방향

WebMCP는 지금 당장 완성형 기능으로 쓰기보다, 점진적으로 도구를 하나씩 늘려가며 실험하는 접근이 현실적입니다. 표준화가 진행 중인 기술이기 때문에 처음부터 사이트 전체를 WebMCP 도구로 뒤덮으려 하기보다는 핵심 기능 한두 개부터 시작하는 것이 안전합니다.

응용 방향을 생각해보면, 우선 검색이나 필터링처럼 되돌리기 쉬운 읽기 전용 기능부터 WebMCP 도구로 노출하는 것이 첫걸음으로 적합합니다. `readOnlyHint`를 붙인 도구는 상대적으로 위험도가 낮기 때문에 초기 실험 대상으로 삼기 좋습니다.

다음 단계로는 폼 기반의 반복 작업을 Declarative API로 전환하는 것을 고려해볼 수 있습니다. 문의하기, 뉴스레터 구독, 예약 조회처럼 이미 HTML form으로 구현돼 있는 기능이라면 `toolname`과 `tooldescription`만 추가해도 AI 에이전트가 접근 가능한 도구로 바뀝니다.

교차 출처 시나리오도 염두에 둘 만합니다. 여러 서비스가 iframe으로 조합된 구조(예: 결제 위젯, 리뷰 위젯)에서는 `allow="tools"`와 허용 출처 목록을 통해 어떤 외부 도구까지 AI 에이전트에 노출할지 세밀하게 통제하는 설계가 가능해집니다. 이는 서비스 간 경계를 지키면서도 필요한 기능만 선택적으로 개방하는 유연한 구조로 이어질 수 있습니다.

다만 이 모든 확장은 WebMCP가 아직 Origin Trial 단계이고 표준화가 완료되지 않았다는 전제 위에서 이뤄져야 합니다. 프로덕션에 전면 적용하기보다는 개발 환경이나 일부 베타 사용자 대상으로 먼저 검증하는 신중한 접근을 권합니다.

---

적용 전 마지막 점검 체크리스트

WebMCP를 실제로 적용하기 전, 아래 항목들을 하나씩 확인하고 넘어가시길 권합니다.

도구 이름이 1~128자이며 ASCII 영숫자, 밑줄, 하이픈, 마침표만 사용했는지 확인합니다.
`tooldescription`과 `toolparamdescription`이 AI 에이전트 입장에서 명확하게 이해되도록 작성됐는지 점검합니다.
동일 출처와 교차 출처 각각의 Permissions Policy 설정이 의도한 대로 돼 있는지 확인합니다(`allow="tools"` 포함).
`readOnlyHint`, `untrustedContentHint`, `consequentialHint` 중 도구 성격에 맞는 힌트를 붙였는지 검토합니다.
Chrome 버전이 149 이상인지, 필요한 경우 플래그(`enable-webmcp-testing`, `devtools-webmcp-support`)가 켜져 있는지 확인합니다.
결제·예약처럼 중대한 작업에는 `AbortSignal`과 도구 해제 시 실행 취소 여부를 명확히 설계했는지 점검합니다.
DevTools의 Application 패널에서 실제 등록된 도구와 스키마가 의도한 대로 표시되는지 최종 확인합니다.

---

자주 묻는 질문 FAQ

Q1. WebMCP는 지금 바로 운영 중인 서비스에 적용해도 되나요?
아직은 신중해야 합니다. 2026년 9월 20일 현재 WebMCP는 W3C 표준이나 표준화 트랙의 규격이 아니라 제안된 웹 표준·초기 미리보기 단계이고, Chrome 149의 Origin Trial 역시 정식 기능이 아닌 기간 한정 실험 프로그램입니다. 개발·테스트 환경에서 먼저 검증하시길 권합니다.

Q2. WebMCP를 도입하면 MCP는 더 이상 필요 없나요?
아닙니다. 공식 비교 문서는 두 기술이 대체 관계가 아니라고 명확히 밝히고 있습니다. MCP는 지속적이고 플랫폼 범용적인 연결을, WebMCP는 현재 열린 페이지의 실시간 상호작용을 담당하는 서로 다른 역할입니다.

Q3. Imperative API와 Declarative API 중 무엇부터 시작해야 하나요?
이미 HTML form으로 구현된 기능이 있다면 Declarative API로 속성만 추가해 빠르게 실험해보는 것이 진입 장벽이 낮습니다. 복잡한 상태 관리가 필요한 기능은 Imperative API가 더 적합합니다.

Q4. 도구 이름에 한글을 쓸 수 없나요?
네, 2026년 9월 17일 초안 기준으로 도구 이름은 1~128자의 ASCII 영숫자, 밑줄, 하이픈, 마침표만 허용됩니다. 사용자에게 보여줄 한글 설명은 `tooldescription` 등 별도 필드에 작성해야 합니다.

Q5. 탭을 닫으면 등록해둔 도구는 어떻게 되나요?
사라집니다. WebMCP 도구는 페이지가 열려 있을 때만 존재하며, 탭을 닫거나 다른 사이트로 이동하면 더 이상 사용할 수 없다고 공식 문서가 명시하고 있습니다.

---

WebMCP는 아직 표준화 트랙에 오르지 않은 초기 단계 기술이지만, 웹사이트를 "읽히는 화면"에서 "호출 가능한 기능의 집합"으로 재정의한다는 방향성 자체는 분명해 보입니다. Imperative API와 Declarative API, 보안 힌트와 출처 정책까지 하나씩 이해해두면 향후 표준이 확정됐을 때 훨씬 수월하게 대응할 수 있을 것입니다. 공식 문서(developer.chrome.com/docs/ai/webmcp, webmachinelearning.github.io/webmcp)를 주기적으로 확인하며 변화를 따라가보시길 바랍니다. 🙂