화면 스크래핑은 끝났다 — 웹과 AI 에이전트가 대화하는 새로운 계약, WebMCP
브라우저 안에서 움직이는 AI 에이전트가 빠르게 늘고 있습니다. 사용자가 “이 항공권 예약해줘”, “이 티셔츠 장바구니에 담아줘”라고 말하면, 에이전트는 화면을 스크린샷으로 찍거나 DOM 트리를 분석해서 어떤 버튼을 누르고 어떤 칸에 무엇을 입력해야 하는지 스스로 “추측”해왔습니다. 사람이 마우스를 움직이고 키보드를 두드리는 행동을 그대로 흉내 내는 방식입니다.
문제는 이 추측이 늘 정확하지는 않다는 점입니다. 웹사이트의 레이아웃이 조금만 바뀌어도 에이전트는 엉뚱한 버튼을 누르거나 잘못된 필드에 값을 채워 넣게 됩니다. 개발자 입장에서도 답답하기는 마찬가지죠. 애초에 사람을 위해 설계된 UI를 기계가 완벽히 이해하도록 만드는 건 근본적으로 어려운 일이기 때문입니다.
지난 2026년 2월, Google Chrome 팀이 제안한 WebMCP(Web Model Context Protocol) 는 이 간극을 메우기 위해 등장했습니다. 웹사이트가 스스로 “나는 이런 기능을 제공하고, 이렇게 호출하면 된다”고 명확히 선언하도록 만드는 제안 표준입니다. 에이전트가 UI를 추론하는 대신, 웹사이트가 먼저 계약(contract) 형태로 자신의 기능을 공개하는 방식으로 패러다임을 바꾸어 놓고 있습니다. 이 글에서는 WebMCP가 무엇이고 왜 필요한지, 어떻게 구현하는지, 그리고 비슷한 목적으로 쓰이던 Playwright 같은 브라우저 자동화 도구와는 어떻게 다른지 차례로 설명하겠습니다.
WebMCP란 무엇인가
WebMCP는 AI 에이전트를 위한 구조화된 도구(tool)를 웹사이트가 직접 빌드하고 노출할 수 있게 해주는 제안된 웹 표준입니다. 개발자는 JavaScript를 작성하거나 기존 HTML 양식 요소에 속성을 추가하는 것만으로, 에이전트가 페이지의 어떤 기능과 어떻게 상호작용해야 하는지 정확히 알려줄 수 있습니다. 그 결과 에이전트 작업의 성능과 안정성이 크게 향상됩니다.
여기서 “작동(act)“이라는 개념이 중요합니다. 이는 에이전트가 마치 사람인 것처럼 마우스 클릭이나 텍스트 입력을 시뮬레이션하는 행위를 뜻하는데, WebMCP는 바로 이 시뮬레이션 방식에서 벗어나 명시적인 함수 호출 방식으로 전환하는 것을 목표로 합니다.
2026년 5월 공개된 이 표준은 현재 Chrome 149부터 오리진 트라이얼(Origin Trial) 형태로 실험 중이며, GitHub의 WebMCP 저장소를 통해 사양 논의가 활발히 진행되고 있습니다. 로컬 개발 환경에서는 chrome://flags/#enable-webmcp-testing 플래그를 켜서 미리 테스트해볼 수 있습니다.
WebMCP가 필요한 이유
WebMCP는 세 가지 핵심 요소로 웹 애플리케이션과 에이전트 사이의 상호작용 규칙을 제공합니다.
- 탐색(Discovery): 페이지가 어떤 도구를 제공하는지 표준화된 방식으로 알려줍니다. 예를 들어 checkout이나 filter_results 같은 이름의 도구를 등록해두면 에이전트가 이를 찾아 사용할 수 있습니다.
- JSON 스키마: 입력값과 예상 출력값을 명시적으로 정의해 에이전트의 환각(hallucination)이나 오해를 줄입니다.
- 상태(State): 현재 페이지 컨텍스트를 공유해 에이전트가 실시간으로 사용할 수 있는 리소스를 파악하게 합니다.
웹사이트는 이렇게 도구를 정의함으로써 검색이나 구매 같은 명시적인 목적을 에이전트와 공유할 수 있습니다. 도구가 실행되는 과정은 화면에 눈에 띄게 나타나기 때문에 사용자는 작업이 예상대로 진행되고 있다는 신뢰를 가질 수 있고, 동시에 사이트는 브랜드와 인간 중심 디자인을 그대로 유지할 수 있습니다.
두 가지 API: 명령형과 선언형
WebMCP는 목적에 따라 두 가지 API를 제공합니다.
명령형 API(Imperative API) 는 표준 JavaScript로 도구를 정의하는 방식입니다. document.modelContext.registerTool()을 사용해 이름, 설명, 입력 스키마, 실행 함수를 가진 도구를 등록합니다.
await document.modelContext.registerTool({
name: 'toggle_layer',
description: 'Control pizza layers (sauce, cheese). Use "add", "remove", or "toggle".',
inputSchema: {
type: 'object',
properties: {
layer: { type: 'string', enum: ['sauce-layer', 'cheese-layer'] },
action: { type: 'string', enum: ['add', 'remove', 'toggle'] },
},
required: ['layer'],
},
execute: async ({ layer, action }) => {
await toggleLayer(layer, action);
return `Performed ${action || 'toggle'} on layer: ${layer}`;
},
});
복잡한 로직, 조건 분기, 비동기 처리가 필요한 SPA나 고급 웹 애플리케이션에 적합하며, getTools()로 사용 가능한 도구를 조회하거나 executeTool()로 직접 실행할 수도 있습니다. React는 usewebmcp 패키지로, Angular는 자체 신호(signal) 기반 폼 연동으로 각각 실험적 지원을 제공합니다.
선언형 API(Declarative API) 는 기존 HTML <form> 요소에 속성만 추가해 도구로 변환하는 방식입니다. toolname과 tooldescription 속성으로 도구의 의미를 선언하면, 폼 필드는 자동으로 도구의 입력 파라미터가 됩니다.
<form toolname="search_cars"
tooldescription="Search for cars based on various criteria such as type, seats, year, fuel, and features."
toolautosubmit>
<label for="seats">Min Seats</label>
<input type="number" id="seats" name="seats" min="1" max="9"
toolparamdescription="Minimum number of seats required">
<button type="submit">Search Cars</button>
</form>
브라우저가 이 폼을 자동으로 JSON 스키마로 변환해주기 때문에, 별도의 자바스크립트 작성 없이도 단순하고 반복적인 작업을 빠르게 도구화할 수 있습니다. 에이전트가 도구를 호출하면 브라우저가 해당 폼에 자동으로 초점을 맞추고 필드를 채우며, :tool-form-active 같은 CSS 의사 클래스로 사용자에게 시각적 피드백을 줍니다.
실제 활용 사례
WebMCP는 특히 다음과 같은 사용자 여정(CUJ)에서 힘을 발휘합니다.
- 쇼핑 지원: 여러 매장에서 최저가를 찾아 위시리스트를 구성하거나, 지난달 주문 이력을 바탕으로 같은 상품을 재주문하는 흐름을
search_products(),add_to_wishlist(),get_order_history()같은 도구로 지원합니다. - 복잡한 양식 작성: 근무시간표 입력, 중고차 검색, 보증 청구, 행사 서비스 요청처럼 여러 단계와 조건이 얽힌 양식을 에이전트가 정확히 채우도록 돕습니다.
- 정보 필터링: 부동산 매물, 호텔 예약처럼 대규모 목록에서 사용자의 세부 조건(대중교통 접근성, 가격대, 편의시설 등)에 맞는 결과를 찾아주는 검색·필터 도구를 제공합니다.
보안과 설계 원칙
WebMCP는 프롬프트 인젝션 같은 위협에 대응하기 위한 보안 장치도 함께 마련하고 있습니다.
- 오리진 격리(origin isolation)된 문서에서만 동작하며,
document.domain이 활성화된 문서에서는 API 자체가 비활성화됩니다. tools권한 정책(Permissions Policy)으로 관리되어, 교차 출처 iframe에서는 기본적으로 도구 등록이 차단되고allow="tools"를 명시해야 허용됩니다.- 도구가 사용자 제작 콘텐츠나 외부 데이터를 반환할 때는
untrustedContentHint를, 상태를 변경하지 않는 도구에는readOnlyHint를 붙이도록 권장합니다. exposedTo옵션으로 도구를 신뢰할 수 있는 특정 출처에만 노출할 수 있습니다.- 도구 설명은 500자, 매개변수 설명은 150자 이내로 간결하게 작성하는 등 “문자 예산”을 지킬 것을 권장합니다.
이 밖에도 각 도구는 하나의 단일 기능만 담당하도록 설계하고, 부정문 대신 긍정문으로 도구 설명을 작성하며, 사용자가 입력한 원시 값을 그대로 받아들이고 계산이나 변환은 에이전트에게 맡기지 않는 것이 권장 사항으로 제시됩니다.
WebMCP vs MCP: 프런트엔드와 백엔드의 역할 분담
WebMCP라는 이름 때문에 기존의 모델 컨텍스트 프로토콜(MCP)을 대체하는 것으로 오해하기 쉽지만, 둘은 서로 다른 문제를 해결합니다. 비유하자면 MCP는 언제 어디서나 이용할 수 있는 고객센터 콜센터이고, WebMCP는 매장 안에 있는 전문 상담원입니다.
| 구분 | MCP | WebMCP |
|---|---|---|
| 목적 | 언제 어디서나 에이전트가 데이터와 작업을 사용하도록 함 | 사용자가 사이트를 방문한 순간 실시간으로 상호작용 |
| 수명 주기 | 영구적(서버·데몬) | 일시적(탭에 종속) |
| 연결 범위 | 전역(데스크톱·모바일·클라우드·웹) | 해당 브라우저 세션에 한정 |
| UI 상호작용 | 헤드리스, 외부 실행 | 브라우저에 통합, DOM 인식 |
| 위치 | 백엔드 | 프런트엔드 |
MCP는 브라우저 기반 여부와 상관없이 에이전트를 외부 데이터 소스나 서비스에 연결하는 범용 표준으로, JSON-RPC와 언어별 SDK로 구현됩니다. 반면 WebMCP는 브라우저에 내장된 에이전트와만 상호작용하는 두 개의 API로 구성되며, 브라우저가 웹사이트와 에이전트 사이의 중개자 역할을 합니다. WebMCP는 MCP를 그대로 JavaScript로 옮긴 것이 아니라 “MCP에서 영감을 받은” 별개의 API 집합에 가깝습니다. 가장 이상적인 형태는 MCP로 핵심 비즈니스 로직과 데이터를 처리하고, WebMCP로 그 위에 사용자가 지금 보고 있는 화면과의 실시간 접점을 만드는, 둘을 함께 쓰는 방식입니다.
WebMCP vs Playwright: “추측”에서 “선언”으로
WebMCP를 이해하는 또 하나의 좋은 방법은 Playwright 같은 기존 브라우저 자동화 도구와 비교해보는 것입니다. Playwright는 원래 테스트 자동화나 웹 스크래핑을 위해 만들어진 도구로, 최근에는 AI 에이전트가 웹을 조작하는 백엔드로도 널리 쓰이고 있습니다. 둘 다 “브라우저 안에서 무언가를 하게 만든다”는 점은 같지만, 접근 방식은 근본적으로 다릅니다.
- 동작 방식: Playwright는 CSS 선택자나 텍스트, 접근성 트리 등을 근거로 DOM 요소를 찾아 클릭, 입력, 스크롤 같은 사용자 행동을 코드로 시뮬레이션합니다. 즉 사이트 입장에서는 “사람인 척하는 로봇”이 화면을 조작하는 것과 다르지 않습니다. 반면 WebMCP는 사이트가 스스로 “이 기능은 이런 입력을 받아 이렇게 실행된다”고 명시적으로 선언한 함수를 에이전트가 직접 호출합니다. UI 요소를 뒤져서 의미를 추론할 필요 자체가 없습니다.
- 사이트의 협조 필요 여부: Playwright는 대상 웹사이트가 별도로 협조하지 않아도 동작합니다. 이미 존재하는 어떤 페이지든 셀렉터만 알아내면 자동화할 수 있습니다. 반대로 WebMCP는 웹사이트 개발자가 직접 도구를 등록해야만 작동합니다. 사이트의 자발적 참여가 전제 조건이라는 점에서 확산 속도나 적용 범위에 제약이 있을 수 있습니다.
- 안정성: Playwright 스크립트는 페이지의 레이아웃, 클래스명, DOM 구조가 조금만 바뀌어도 쉽게 깨집니다. 이는 “취약한 셀렉터” 문제로 잘 알려져 있습니다. WebMCP 도구는 애플리케이션의 디자인이 아니라 로직에 연결되기 때문에, 개발자가 UI를 자유롭게 리디자인해도 도구 계약만 유지되면 에이전트의 동작은 안정적으로 유지됩니다.
- 실행 환경: Playwright는 헤드리스 브라우저에서도 문제없이 동작해 서버에서 대규모 자동화나 테스트 파이프라인에 활용하기 좋습니다. WebMCP는 명세상 표시되는 브라우저 탭이나 웹뷰가 반드시 열려 있어야 하며, 헤드리스 상태에서의 호출은 지원되지 않습니다. 이는 WebMCP가 “사람이 실제로 웹사이트를 열어 두고 에이전트에게 대신 시키는” 상황을 전제로 설계됐기 때문입니다.
- 성격 및 목적: Playwright는 범용 브라우저 제어·테스트 도구에 가깝고, 대상 사이트의 의도와 무관하게 원하는 모든 조작을 시도할 수 있습니다. WebMCP는 사이트가 “이 기능만 이렇게 써주세요”라고 명확히 허용 범위를 정해 두는 구조여서, 사이트 소유자가 에이전트에게 노출할 기능과 노출하지 않을 기능을 통제할 수 있다는 차이가 있습니다.
결과적으로 Playwright는 “웹사이트가 협조하지 않아도 강제로 자동화하는” 범용 도구이고, WebMCP는 “웹사이트가 먼저 손을 내밀어 에이전트와 안전하고 예측 가능하게 협업하는” 표준이라고 정리할 수 있습니다.다. 실제로 WebMCP 공식 문서 역시 도구 호출이 반드시 화면이 표시되는 브라우저 컨텍스트를 필요로 한다는 점, 그리고 도구를 제공하는 사이트인지 여부를 사전에 알 방법이 아직 없다는 점을 스스로의 한계로 명시하고 있습니다. 두 기술은 경쟁 관계라기보다, 사이트가 WebMCP를 지원하면 그 사이트에서는 WebMCP가 더 안정적인 선택지가 되고, 지원하지 않는 사이트에서는 여전히 Playwright류의 시뮬레이션 자동화가 필요한 상호 보완적 관계에 가깝습니다.
결론
WebMCP는 “에이전트가 사람 흉내를 내며 UI를 추측하는 시대”에서 “웹사이트가 스스로 기능을 선언하고 에이전트가 이를 신뢰성 있게 호출하는 시대”로 넘어가기 위한 다리 역할을 담당합니다. 명령형 API와 선언형 API라는 두 가지 진입 경로를 제공해 이미 복잡한 SPA를 운영하는 팀도, 단순한 HTML 폼만 있는 사이트도 각자의 방식으로 점진적으로 도입할 수 있게 설계되어 있습니다. 또한 오리진 격리, 권한 정책, 신뢰 힌트 같은 보안 장치를 함께 마련해 프롬프트 인젝션 같은 새로운 위협에도 대비하고 있습니다.
MCP와는 프런트엔드·백엔드로 역할이 나뉘어 서로 보완적으로 사용되고, Playwright와 같은 브라우저 자동화 도구와는 “추론 기반 시뮬레이션”과 “명시적 계약”이라는 근본적으로 다른 철학을 가진다는 점에서, WebMCP는 완전히 새로운 대체재라기보다는 에이전트 생태계에 빠져 있던 한 조각을 채우는 표준에 가깝습니다.
맺음말
물론 WebMCP는 아직 초기 논의 단계에 있는 제안 표준입니다. Chrome 오리진 트라이얼로 실험되는 수준이고, 사양 자체도 GitHub에서 활발히 바뀌고 있으며, 도구를 제공하는 사이트를 자동으로 찾아내는 디스커버리 메커니즘조차 아직 마련되어 있지 않습니다. 무엇보다 이 표준이 의미를 가지려면 결국 웹사이트 개발자들이 자발적으로 도구를 노출해야 하는데, 그 확산에는 시간이 걸릴 수밖에 없습니다.
그럼에도 불구하고 “웹이 에이전트를 위해 스스로를 설명한다”는 방향성 자체는 눈여겨볼 만합니다. Google 주도로 시작된 이 표준이 다른 브라우저로 확산될지, 실제 상용 서비스들이 얼마나 빠르게 도구를 등록하기 시작할지, 그리고 Playwright 같은 범용 자동화 도구와 어떤 균형점을 찾아갈지는 앞으로 계속 지켜볼 부분입니다. 관심 있는 개발자라면 지금 단계에서는 로컬 플래그로 데모를 직접 체험해보거나, GitHub 저장소의 논의에 의견을 남겨보는 것도 이 흐름에 참여하는 좋은 방법이 될 것입니다.
참고 자료
https://developer.chrome.com/docs/ai/webmcp?hl=ko
https://news.hada.io/topic?id=26597
https://www.youtube.com/watch?v=JofF3nw4lyg
https://github.com/webmachinelearning/webmcp
답글 남기기