구글 × 마이크로소프트 공동 발표
Chrome 146 탑재
WebMCP 완전 정복: AI 에이전트 웹 혁명,
지금 안 알면 뒤처진다
WebMCP는 AI 에이전트가 웹사이트를 스크린샷·DOM 추론 없이 직접 조작할 수 있게 해주는
새로운 브라우저 표준입니다. 구글과 마이크로소프트가 W3C 커뮤니티 그룹에서 공동 개발했으며,
2026년 2월 Chrome 146 카나리 버전에 최초 탑재됐습니다.
이 글 하나로 개념·구조·실전 구현·보안 쟁점까지 완전히 정복할 수 있습니다.
스크린샷 방식의 1회 처리 비용
WebMCP 도구 계약으로 대체
선언적 + 명령형 이중 구조
WebMCP가 왜 지금 터졌는가 — 등장 배경
2026년은 AI 에이전트가 단순 대화를 넘어 실제 웹 작업을 수행하는 원년으로 기록될 가능성이 높습니다.
항공권 예약, 쇼핑 체크아웃, 고객 지원 티켓 작성처럼 수십 단계의 클릭이 필요한 작업을
에이전트가 대신 처리하는 시대가 현실로 다가왔기 때문입니다. 문제는 기존 웹이
‘인간 사용자’를 전제로 설계되어 있다는 점입니다. 에이전트가 버튼을 클릭하려면
그 버튼이 ‘무엇을 하는 버튼인지’를 스스로 추론해야 했고, 이 과정에서 엄청난 비용과 오류가 발생했습니다.
구글 크롬 팀은 2026년 2월 10일 공식 개발자 블로그를 통해 WebMCP의 얼리 프리뷰를 공개했습니다.
마이크로소프트가 공동 기여자로 참여했으며, W3C 웹 머신러닝 커뮤니티 그룹 산하에서 표준화 과정을
밟고 있습니다. Chrome 146 카나리 버전에 실험 기능(플래그) 형태로 탑재되었고,
Hacker News에서 1,000여 개의 댓글이 달릴 만큼 개발자 커뮤니티의 폭발적인 반응을 이끌어냈습니다.
“웹사이트가 에이전트에게 자신을 설명하는 방식”을 근본적으로 바꾸는 패러다임 전환입니다.
에이전트가 웹을 ‘읽는’ 시대에서, 웹이 에이전트에게 ‘말하는’ 시대로의 이행입니다.
AI 에이전트의 기존 웹 접근 방식과 한계
지금까지 AI 에이전트가 웹사이트를 조작하는 방법은 크게 두 가지였습니다.
첫 번째는 스크린샷 방식입니다. 페이지를 이미지로 캡처한 뒤
Claude나 Gemini 같은 멀티모달 모델에 입력해 “이 화면에서 무엇을 클릭해야 하는가”를 판단합니다.
이미지 한 장을 처리할 때마다 수천 개의 토큰이 소모되고, 응답 속도도 현저히 느려진다는 치명적 단점이 있습니다.
두 번째는 DOM 파싱 방식입니다. 웹페이지의 HTML 구조를 그대로 모델에 전달하는 방법입니다.
그러나 실제로 필요한 정보 외에도 수많은 태그와 스크립트가 함께 전달되어 컨텍스트 창을 낭비하고
비용을 크게 키웁니다. 또한 UI가 조금만 변경되어도 에이전트가 엉뚱한 버튼을 누르거나
잘못된 필드에 값을 입력하는 오작동이 빈번히 발생했습니다.
| 방식 | 토큰 비용 | 속도 | UI 변경 내성 | 정확도 |
|---|---|---|---|---|
| 스크린샷 방식 | 수천 토큰/회 | 느림 | 낮음 | 중간 |
| DOM 파싱 방식 | 높음 | 보통 | 낮음 | 중간 |
| WebMCP 방식 | 최소화 | 빠름 | 높음 | 높음 |
사람이라면 몇 초면 끝낼 상품 검색도, AI 에이전트에게는 여러 번의 클릭, 스크롤, 데이터 분석,
추론 호출을 거쳐야 하는 복잡한 작업이었습니다. WebMCP는 이 구조적 비효율을 해결하기 위해
등장한 완전히 새로운 접근 방식입니다.
WebMCP 핵심 구조: 도구 계약이란 무엇인가
WebMCP의 핵심 개념은 ‘도구 계약(Tool Contract)’입니다.
웹사이트가 AI 에이전트에게 “이 페이지에서 할 수 있는 일은 이것이고, 입력값은 이런 형태이며,
결과는 이렇게 나온다”고 명시적으로 선언하는 구조입니다. 에이전트는 더 이상 버튼의 의미를 추측할 필요가 없습니다.
이 계약은 세 가지 핵심 요소로 구성됩니다. 첫째는 Discovery입니다.
페이지가 지원하는 도구(예: checkout, filter_results)를
에이전트가 표준화된 방식으로 조회할 수 있습니다. 둘째는 JSON Schema입니다.
입력과 예상 출력의 형태를 명시적으로 정의하여 환각(Hallucination)이나 오입력을 줄입니다.
셋째는 State입니다. 현재 페이지 컨텍스트를 에이전트와 공유하여
에이전트가 실시간으로 사용 가능한 리소스를 파악할 수 있게 합니다.
기술적으로는 브라우저 API인 navigator.modelContext를 통해 구현됩니다.
이 API가 WebMCP의 진입점으로, 웹사이트 측 JavaScript가 이를 통해 도구를 등록하고
브라우저 내 AI 에이전트가 이를 호출하는 방식입니다. 헤드리스 환경에서는 동작하지 않으며,
반드시 가시적인 브라우징 컨텍스트(실제 크롬 창)가 필요합니다.
WebMCP는 ‘식당이 번역된 메뉴판과 주문 방법을 직접 건네주는 것’에 해당합니다.
웹사이트가 에이전트의 언어로 직접 말을 거는 구조입니다.
선언적 API vs 명령형 API — 차이와 사용 시점
WebMCP는 두 종류의 API를 제공하며, 상황에 따라 적절한 방식을 선택해야 합니다.
둘의 차이를 정확히 이해하는 것이 WebMCP 구현의 첫걸음입니다.
선언적 API (Declarative API)
이미 존재하는 HTML 폼 요소에 toolname과 tooldescription 속성만
추가하면 도구로 변환됩니다. 브라우저가 폼 구조를 자동으로 JSON Schema로 변환해 에이전트에게 전달합니다.
회원가입 폼, 검색창, 기본 조회 기능처럼 이미 HTML로 구조가 잡혀 있는 상호작용에 적합합니다.
기존 코드를 거의 수정하지 않고도 에이전트 친화적 사이트로 전환할 수 있다는 것이 가장 큰 장점입니다.
<form
toolname="searchProducts"
tooldescription="상품을 키워드, 카테고리, 가격대로 검색합니다"
action="/search"
method="GET"
>
<input name="query" type="text" placeholder="검색어" />
<select name="category">
<option value="all">전체</option>
<option value="electronics">전자제품</option>
</select>
<input name="maxPrice" type="number" placeholder="최대 가격" />
<button type="submit">검색</button>
</form>
명령형 API (Imperative API)
JavaScript로 직접 도구를 등록하는 방식입니다. registerTool(), provideContext(),
unregisterTool() 등의 API를 제공합니다. SPA(Single Page Application)처럼
JavaScript로 동작하는 복잡한 인터페이스, 여러 단계를 거치는 체크아웃 플로우, 실시간 데이터 필터링 등
선언적 API로는 표현하기 어려운 동적 상호작용에 적합합니다.
// WebMCP 명령형 API — 도구 등록 예시
navigator.modelContext.registerTool({
name: "orderPrints",
description: "사진 인화 주문: 매수, 용지 크기, 마감 방식을 지정합니다.",
parameters: {
type: "object",
properties: {
copies: { type: "integer", description: "인화 매수 (1~100)" },
page_size: { type: "string", enum: ["4x6", "5x7", "8x10"] },
finish: { type: "string", enum: ["glossy", "matte"] }
},
required: ["copies", "page_size"]
},
handler: async ({ copies, page_size, finish }) => {
const result = await placeOrder({ copies, page_size, finish });
return { orderId: result.id, status: result.status };
}
});
실전 구현: 내 웹사이트에 WebMCP 적용하는 법
현재 WebMCP는 Chrome 146 이상의 카나리 버전에서 실험 플래그를 활성화해야 사용할 수 있습니다.
프로덕션 배포는 아직 이른 단계지만, 지금부터 구현을 준비하면 표준화 이후 빠르게 대응할 수 있습니다.
아래는 단계별 적용 절차입니다.
Chrome Canary를 설치한 뒤 주소창에
chrome://flags를 입력하고,“WebMCP for testing” 플래그를 활성화(Enabled)합니다.
사이트의 핵심 기능 중 에이전트가 수행하면 사용자에게 가치 있는 작업을 선별합니다.
단순 폼은 선언적 API, 복잡한 동적 로직은 명령형 API를 사용합니다.
각 도구의 입력 파라미터와 출력 형태를 JSON Schema 형식으로 명확히 정의합니다.
파라미터 설명이 구체적일수록 에이전트의 정확도가 높아집니다.
폼이 사람에 의해 제출됐는지, 에이전트에 의해 호출됐는지를
agentInvoked 플래그로구분할 수 있습니다. 이를 활용해 에이전트 전용 응답 형식(JSON)을 별도로 반환하는 로직을 구성합니다.
기존 프런트엔드 JavaScript 코드 위에 도구 등록 레이어만 추가하면 되기 때문에,
이미 API가 있는 서비스라면 구현 비용이 매우 낮습니다. 이커머스나 여행·예약 서비스처럼
에이전트가 직접 구매를 완료해 주면 매출이 늘어나는 업종에서 빠른 ROI를 기대할 수 있습니다.
MCP와 WebMCP의 결정적 차이 — 무엇을 언제 쓸까
Anthropic이 제안한 MCP(Model Context Protocol)와 WebMCP는 이름이 비슷하지만 작동 방식이 완전히 다릅니다.
이 둘을 혼동하면 엉뚱한 도구를 선택하는 실수로 이어질 수 있으므로 정확히 구분해야 합니다.
| 구분 | MCP (Anthropic) | WebMCP (Google + MS) |
|---|---|---|
| 동작 위치 | 서버 사이드 (백엔드) | 클라이언트 사이드 (브라우저) |
| 주요 용도 | AI 플랫폼 ↔ 기업 내부 시스템 연결 | 브라우저 에이전트 ↔ 웹사이트 직접 연동 |
| 서버 필요 여부 | 별도 MCP 서버 배포 필요 | 서버 불필요, 프런트엔드에 통합 |
| 표준화 주체 | Anthropic 제안, 업계 확산 중 | W3C 커뮤니티 그룹 (구글·MS 공동) |
| 대표 사용 시나리오 | 사내 DB 조회, 파일 시스템 접근 | 쇼핑 체크아웃, 항공권 예약, 폼 자동 작성 |
| 현재 성숙도 | 프로덕션 적용 사례 다수 | 얼리 프리뷰 단계 (Chrome 146) |
결론적으로 두 표준은 경쟁 관계가 아니라 상호 보완 관계입니다.
내부 시스템이나 AI 플랫폼과의 연동은 기존 MCP 서버로 유지하고,
소비자가 이용하는 웹사이트 인터페이스에는 WebMCP를 적용하는 투 트랙 전략이
가장 현실적인 접근 방식입니다.
보안 쟁점과 시맨틱 웹 실패의 교훈
WebMCP에 대한 개발자 커뮤니티의 반응이 극명하게 갈린 이유가 있습니다.
기대만큼이나 날카로운 우려가 동시에 제기됐기 때문입니다.
이 두 가지 쟁점을 솔직하게 짚어야 WebMCP의 미래를 냉정하게 평가할 수 있습니다.
보안: 신뢰 모델의 근본적 전환
로컬 MCP 환경에서는 사용자가 어떤 서버를 신뢰할지 직접 선택하고, 모든 도구 호출을 확인합니다.
하지만 WebMCP에서는 웹사이트가 도구를 정의하고 브라우저가 호출을 결정합니다.
악의적인 사이트가 겉으로는 유용해 보이는 도구를 노출하면서 실제로는 에이전트 세션의 컨텍스트를
빼돌리는 시나리오는 충분히 현실적입니다. 기존 웹 보안(CORS, CSP, 샌드박싱)에
‘에이전트를 악의적 사이트로부터 보호하는 레이어’가 추가되어야 합니다.
시맨틱 웹의 전철을 밟을 것인가
20년 전 시맨틱 웹이 실패한 핵심 이유는 사이트 운영자에게 추가 작업을 요구하면서
직접적인 보상이 없었기 때문입니다. WebMCP도 동일한 구조적 문턱에 서 있습니다.
그러나 결정적으로 다른 맥락이 존재합니다. LLM이라는 ‘불완전한 입력도 이해하는 소비자’가 등장했습니다.
시맨틱 웹은 모든 사이트가 동일한 온톨로지를 따라야 했지만,
LLM 에이전트는 일부만 구조화되어 있어도 나머지를 추론으로 메울 수 있습니다.
네트워크 효과의 임계점이 훨씬 낮아진 것이 이번의 결정적 차이입니다.
그리고 AMP 전철을 밟지 않으려면 W3C 개방형 표준화 과정이 반드시 투명하게 진행되어야 합니다.
대형 이커머스 플랫폼과 항공사 등 직접적 매출 인센티브가 있는 사업자들이 먼저 채택할 가능성이 높고,
이 초기 성공 사례가 쌓여야 나머지 생태계도 따라올 것입니다.
❓ Q&A — WebMCP에 대해 자주 묻는 질문 5가지
Q1. WebMCP는 지금 당장 내 사이트에 적용할 수 있나요?
Chrome 146 이상의 카나리(Canary) 버전에서 실험 플래그를 활성화해야만 작동합니다.
일반 사용자에게 배포된 Chrome 안정 버전에서는 아직 지원되지 않습니다.
프로덕션 적용을 위해서는 표준화 진행 상황을 주시하고,
얼리 프리뷰 프로그램에 가입해 미리 테스트 환경을 구성해 두는 것이 현명합니다.
Q2. WebMCP를 사용하면 토큰 비용이 얼마나 절감되나요?
스크린샷 방식에서 이미지 처리에 소모되는 수천 토큰을 단 한 번의 JSON 도구 호출로 대체할 수 있습니다.
구글의 공식 자료에 따르면 구조화된 도구 호출 방식은 비정형 DOM 파싱 방식 대비
토큰 사용량을 크게 낮출 수 있으며, 응답 지연 시간도 단축됩니다.
특히 반복적으로 동일 작업을 수행하는 에이전트 워크플로우에서 비용 절감 효과가 극대화됩니다.
Q3. 기존에 MCP 서버를 구축했다면 WebMCP로 교체해야 하나요?
기업 내부 시스템, 데이터베이스, 파일 시스템에 대한 접근은 기존 MCP 서버 방식이 적합합니다.
반면 일반 사용자가 이용하는 웹사이트 인터페이스에서 에이전트가 직접 작업을 수행해야 할 때는
WebMCP를 추가로 구현하는 방식이 이상적입니다. 두 가지를 병행하는 것이 권장됩니다.
Q4. WebMCP는 파이어폭스나 사파리에서도 지원되나요?
WebMCP는 W3C 웹 머신러닝 커뮤니티 그룹에서 표준화 과정을 밟고 있지만,
파이어폭스(Mozilla)와 사파리(Apple)의 공식 지원 여부는 아직 확정되지 않았습니다.
W3C 표준으로 확정된 이후에야 다른 브라우저들의 구현이 뒤따를 것으로 예상됩니다.
현재로서는 ‘크롬 생태계 중심’이라는 한계가 분명히 존재합니다.
Q5. WebMCP가 구글의 웹 지배력을 더 강화하는 것 아닌가요?
자사 생태계에 유리한 방향으로 웹을 재편할 가능성을 배제할 수 없습니다.
이를 방지하기 위해서는 W3C나 WHATWG 같은 개방형 표준화 기구를 통한 투명한 거버넌스가
필수적입니다. 개발자 커뮤니티가 표준화 과정에 적극 참여하고 크로스 브라우저 구현을 촉구하는 것이
건강한 웹 생태계를 위한 핵심 과제입니다.
마치며 — 웹의 다음 레이어가 시작되다
WebMCP는 단순한 기술 스펙 하나가 아닙니다.
지금까지 웹이 ‘인간을 위해’ 설계되어 왔다면, 이제는 ‘AI 에이전트를 위한 레이어’를
동시에 갖추는 시대가 열리고 있다는 신호입니다.
스크린샷을 찍고 DOM을 파싱하며 추론하던 시대에서,
웹사이트가 에이전트에게 직접 말을 거는 시대로의 전환이 시작된 것입니다.
물론 현재는 얼리 프리뷰 단계로, 보안 모델과 크로스 브라우저 지원 문제가 해결되지 않았습니다.
시맨틱 웹처럼 좋은 의도로 시작한 표준이 채택 실패로 끝난 역사도 있습니다.
그러나 이번에는 다릅니다. LLM 에이전트라는 강력한 소비자가 이미 존재하고,
대형 이커머스·여행 서비스처럼 직접적 수익 인센티브가 있는 사업자들이 빠르게 움직일 준비가
되어 있기 때문입니다.
웹 개발자라면 지금 당장 얼리 프리뷰 프로그램에 가입하고, 자신의 사이트에 어떤 도구를
에이전트에게 노출할 수 있을지 설계하는 시간을 갖는 것을 강력히 권합니다.
WebMCP 표준이 확정되는 시점에 이미 준비된 상태로 있는 것과
그때서야 시작하는 것 사이에는 큰 격차가 생길 것입니다.
※ 본 포스팅은 공개된 정보(구글 Chrome 개발자 블로그, W3C 문서, AI Times 등)를 바탕으로
작성된 정보 제공 목적의 콘텐츠입니다. WebMCP는 현재 얼리 프리뷰 단계로, API 사양 및 지원 범위는
정식 출시 시점에 변경될 수 있습니다. 최신 정보는 공식 Chrome for Developers 문서를 반드시 확인하시기 바랍니다.
작성 기준일: 2026년 3월 9일.
댓글 남기기