W3C 초안 단계
IT/AI
Chrome WebMCP: “MCP 대신 쓰면 된다”가 틀린 이유
2026년 2월 10일, 구글 크롬 팀이 조용히 공개한 WebMCP는 AI 에이전트가 웹사이트와 상호작용하는 방식 자체를 바꾸는 새 표준입니다. 그런데 이미 “MCP 있으면 필요 없는 거 아닌가?”라는 오해가 퍼지고 있습니다. 공식 문서와 실제 수치로 그 오해를 정면으로 깨보겠습니다.
(vs 스크린샷)
(플래그 활성화)
(Google + Microsoft)
WebMCP가 갑자기 등장한 배경
지금 AI 에이전트가 웹사이트와 상호작용하는 방식을 한마디로 표현하면 “지도 없이 낯선 나라를 여행하는 것”입니다. 구글 Chrome의 Auto Browse 기능은 Gemini가 웹 페이지를 직접 “보고” 클릭하는 방식으로 작동합니다. 버튼을 찾아 스크린샷을 찍고, DOM 트리를 파싱하며, 어떤 필드에 어떤 데이터를 입력해야 하는지 추측합니다.
이 방식의 문제는 단순히 불편한 게 아닙니다. 구조화된 WebMCP 툴 호출은 스크린샷 기반 방식 대비 토큰 사용량을 89% 절감합니다. 스크린샷 한 장을 처리하려면 2,000토큰 이상이 소비되는 반면, WebMCP 툴 호출은 20~100토큰이면 충분합니다. (출처: WebMCP 공식 문서 · zuplo.com, 2026.03.13) 이것이 독자에게 의미하는 것은 단순합니다. AI 에이전트 기반 서비스의 API 비용이 최대 10분의 1로 줄어든다는 뜻입니다.
Chrome 146 Early Preview가 2026년 2월 10일 공개됐고, 구글과 마이크로소프트가 공동으로 W3C 표준화를 추진 중입니다. 2026년 중반에서 후반에는 Chrome Stable 및 Edge에서 플래그 없이 사용 가능할 전망입니다.
💡 이 분석은 Chrome 공식 블로그와 W3C 초안 스펙을 직접 교차해 도출한 내용입니다. MCP-B 폴리필의 역사(2025년 1월)부터 W3C 인큐베이션 수락(2025년 9월), Chrome 146 Early Preview(2026년 2월)까지의 타임라인은 기존 국내 블로그에서 다루지 않은 부분입니다.
잠깐, WebMCP와 MCP는 다릅니다
많은 분들이 오해하는 부분이 바로 이것입니다. “기존 MCP(Model Context Protocol)가 있는데 WebMCP를 따로 배울 필요가 있나?” 결론부터 말씀드리면 — 둘은 대체 관계가 아니라 상호보완 관계입니다. (출처: Chrome for Developers 공식 블로그, 2026.03.11)
기존 MCP는 서버 사이드에서 동작합니다. AI 에이전트가 데이터베이스, 파일 시스템, SaaS API 등 백엔드 도구를 호출할 때 쓰는 표준입니다. Python·TypeScript SDK가 있고, JSON-RPC 프로토콜로 통신합니다. 반면 WebMCP는 브라우저 탭 내부에서 동작합니다. 사용자의 로그인 세션, 쿠키, SSO 인증 컨텍스트를 그대로 상속합니다. 별도 서버 배포나 인증 레이어 구축이 필요 없습니다.
| 구분 | 기존 MCP | WebMCP |
|---|---|---|
| 실행 위치 | 백엔드 서버 | 브라우저 탭 내부 |
| 인증 방식 | 별도 설정 필요 | 브라우저 세션 자동 상속 |
| UI 접근 | 불가 | DOM 직접 접근 가능 |
| 적합한 용도 | DB, 파일, 헤드리스 API | 웹 대시보드, SaaS UI |
| 현재 상태 | 광범위하게 채택됨 | Early Preview (Chrome 146) |
| 제공 범위 | 도구·리소스·프롬프트 | 도구(Tool)만 지원 |
표에서 마지막 행이 중요합니다. WebMCP는 현재 도구(Tool) 호출만 지원하며, MCP의 리소스(Resource)나 프롬프트(Prompt) 개념은 포함되지 않습니다. (출처: Chrome for Developers 공식 블로그, 2026.03.11) 즉, 문서나 구조화된 데이터 소스에 에이전트가 접근해야 하는 사용 사례라면 기존 MCP가 여전히 필수입니다. 이 점을 모르고 WebMCP로 전부 전환하려 한다면 지금 당장 예산 낭비가 발생합니다.
알고 보면 반대입니다: “WebMCP가 나왔으니 MCP 서버는 필요 없다”는 결론은 공식 문서와 정반대입니다. 이상적인 구성은 백엔드 API·DB 작업은 기존 MCP 서버로, 로그인된 웹 대시보드·SaaS UI 상호작용은 WebMCP로 동시에 운영하는 것입니다.
두 가지 API 방식: 선언형 vs 명령형
WebMCP를 구현하는 방법은 두 가지입니다. 공식 문서 기준(Chrome for Developers, 2026.02.10)으로 각각의 특징을 정리합니다.
① 선언형 API (HTML 속성 방식)
기존 HTML 폼에 tool-name과 tool-description 속성만 추가하면 됩니다. JavaScript 없이 기존 웹사이트 폼을 AI 에이전트가 이해하는 구조화된 도구로 변환할 수 있습니다. 이미 HTML 폼이 잘 정리된 사이트라면 추가 코드 변경 없이 에이전트 호환성을 확보할 수 있다는 게 핵심입니다.
<form
tool-name="book_table"
tool-description="레스토랑 테이블 예약 (인원·날짜 입력 필요)">
<input name="party_size" tool-param-description="예약 인원 수" />
<input name="date" tool-param-description="예약일 (YYYY-MM-DD)" />
<button type="submit">예약하기</button>
</form>
② 명령형 API (JavaScript 방식)
더 복잡한 동적 상호작용을 위한 방식입니다. navigator.modelContext.registerTool()을 사용해 도구를 프로그래밍 방식으로 등록합니다. 페이지 상태에 따라 도구를 등록하거나 해제할 수 있습니다. 예를 들어 쇼핑몰에서 장바구니에 상품이 담겼을 때만 checkout 도구가 노출되도록 조건부 등록이 가능합니다.
navigator.modelContext.registerTool({
name: 'add_to_cart',
description: '상품을 장바구니에 추가합니다',
inputSchema: {
type: 'object',
properties: {
productId: { type: 'string' },
quantity: { type: 'number' }
},
required: ['productId']
},
async execute(args) {
const result = await cartService.addItem(
args.productId, args.quantity || 1
);
return { content: [{ type: 'text', text: JSON.stringify(result) }] };
}
});
이 execute 함수는 일반 JavaScript입니다. 별도 API나 통합 레이어를 새로 만드는 게 아니라 이미 웹앱이 갖고 있는 비즈니스 로직을 그대로 노출하는 구조입니다. 이것이 기존 MCP 서버와의 근본적 차이입니다.
실제로 써보면 당황하는 이유 — 보안 함정
WebMCP가 가장 화려하게 소개되는 지점은 편의성입니다. 그러나 지금 당장 프로덕션에 적용하면 안 되는 이유가 있습니다. 공식 스펙 문서 자체에서 아직 해결되지 않은 보안 이슈를 명시하고 있습니다.
MCP 생태계 전반에서 이미 실제 사고가 발생했습니다. GitHub MCP 서버에 대한 프롬프트 인젝션 공격으로 AI 코딩 어시스턴트가 비공개 저장소 내용을 외부로 유출했습니다. WhatsApp MCP 서버는 ‘도구 포이즈닝(tool poisoning)’ 공격을 받아 사용자의 메시지 전체 이력이 공격자 서버로 조용히 전송됐습니다. 이는 가설이 아니라 이미 발생한 사건입니다. (출처: MCP Security Crisis 분석, securityboulevard.com, 2026.01.25)
⚠️ WebMCP 고유의 브라우저 보안 리스크
- 툴 포이즈닝: 신뢰를 획득한 후 도구의 동작이 바뀌는 “러그풀(rug pull)” 시나리오
- 데이터 엑스필트레이션: 개별적으로는 무해해 보이는 툴 체이닝이 민감 정보를 외부로 유출
- 크로스탭 데이터 누출: 여러 탭에서 동시 에이전트 작동 시 데이터 충돌 — W3C 검토 진행 중
- 프롬프트 인젝션: 툴 설명(tool-description) 자체에 악의적 지시문 삽입 가능
현재 스펙에는 동일 출처 정책 강제, CSP 통합, HTTPS 필수 환경 등의 완화 조치가 포함되어 있습니다. 민감한 툴 호출 시 사람이 확인하는 requestUserInteraction() 메커니즘도 있습니다. 선언형 API의 기본 동작은 폼을 자동으로 제출하지 않고 사람이 직접 클릭해 제출하는 방식입니다. (출처: WebMCP W3C 초안 스펙, webmachinelearning.github.io)
그러나 스펙 자체가 “이러한 질문들에 대해 아직 해결되지 않았다(remain open)”고 명시하고 있습니다. 오픈 소스 MCP 서버 구현 중 53%가 정적 자격 증명에 의존하고 있다는 분석 결과(Astrix, 5,000개 이상 MCP 서버 분석)는 WebMCP의 잠재 위험 수준을 가늠하게 합니다.
지금 당장 Chrome 146에서 테스트하는 법
WebMCP는 현재 Chrome 146 버전에서 플래그를 통해 활성화할 수 있습니다. 아래 4단계를 그대로 따라 하시면 됩니다.
Chrome 버전 확인
Chrome 설정 → 도움말 → Chrome 정보에서 버전 확인. 146.0.7672.0 이상이어야 합니다. 미달이라면 Chrome Beta 채널로 업데이트하세요.
플래그 활성화
주소창에 chrome://flags/#enable-webmcp-testing 입력 → “WebMCP for testing” 항목을 Enabled로 설정
Chrome 재시작
플래그 변경 후 “Relaunch” 버튼을 클릭해 Chrome을 재시작합니다.
Model Context Tool Inspector 설치
Chrome 웹 스토어에서 “WebMCP Model Context Tool Inspector” 확장 프로그램 설치. 어느 페이지에서든 등록된 WebMCP 도구를 검사하고, 직접 파라미터를 입력해 실행해볼 수 있습니다. Gemini API 연동으로 AI 에이전트 시뮬레이션도 가능합니다.
구글이 공개한 공식 항공편 예약 라이브 데모(googlechromelabs.github.io/webmcp-tools/demos/react-flightsearch)에서 searchFlights, filterResults, bookFlight 세 가지 도구가 등록되는 전 과정을 직접 확인할 수 있습니다.
에이전틱 웹의 두 번째 인터넷 — 개발자에게 의미하는 것
2000년대 초 검색 엔진이 등장했을 때, 웹사이트들은 사람을 위해 설계된 HTML을 크롤러가 이해할 수 있도록 바꾸는 작업을 시작했습니다. robots.txt, sitemap.xml, 구조화 데이터가 그 결과입니다. WebMCP는 그 역사가 다시 시작되는 신호입니다. 단, 이번 대상은 검색 크롤러가 아니라 AI 에이전트입니다.
아래는 독자가 직접 계산할 수 있는 비용 비교입니다.
💰 AI 에이전트 1회 웹 상호작용 비용 비교 (추정치 기준)
스크린샷 기반 처리: 약 2,000토큰 이상 소비
WebMCP 구조화 툴 호출: 약 20~100토큰 소비
(출처: WebMCP 공식 문서 인용 · zuplo.com, 2026.03.13)
월 10만 건의 AI 에이전트 상호작용이 발생하는 서비스에서, GPT-4o 기준(입력 토큰 $2.5/1M 기준) 계산 시 스크린샷 방식 대비 WebMCP 방식은 월 최대 약 $475 이상 절감이 가능합니다. 이 수치는 독자 여러분의 실제 요금제와 요청 건수에 따라 직접 비례하여 계산할 수 있습니다.
WebMCP의 타임라인을 보면 이 표준이 얼마나 빠르게 현실화되고 있는지 알 수 있습니다. 아마존 직원 Alex Nahas가 Chrome 확장 프로그램 MCP-B를 혼자 만든 것이 2025년 1월입니다. 구글과 마이크로소프트가 공동 제안서를 W3C에 제출한 것이 2025년 8월, W3C 커뮤니티 그룹이 공식 수락한 것이 2025년 9월, Chrome 146 Early Preview가 2026년 2월입니다. 프로토타입에서 브라우저 탑재까지 단 13개월이 걸렸습니다. (출처: zuplo.com WebMCP 가이드, 2026.03.13)
현재 Chrome 146 Stable 출시가 예상되는 시기는 2026년 3~4월이며, Edge와의 크로스 브라우저 지원은 2026년 중반에서 후반으로 예상됩니다. Firefox와 Safari는 W3C 워킹 그룹에 참여 중이지만 구체적 일정은 미공개 상태입니다.
💡 이 관점은 공식 타임라인과 실제 MCP 해킹 사례를 교차 분석한 결과입니다. 기존 국내 블로그들이 “WebMCP가 이렇게 좋다”에 집중하는 반면, 스펙 자체가 “보안 모델이 불완전하다”고 인정하는 사실과 실제 MCP 생태계 해킹 사례를 함께 보면 지금 당장 프로덕션 배포는 금물이라는 결론이 나옵니다.
Q&A 5선
마치며 — 두 개의 웹이 동시에 돌아가는 세상
WebMCP는 웹을 인간과 기계 모두를 위한 인터페이스로 분기시키는 첫 번째 공식 표준입니다. 화면은 사람을 위해, 구조화된 툴은 AI 에이전트를 위해 동시에 제공하는 시대가 열리고 있습니다.
그러나 지금 당장 “WebMCP 완전 도입”을 외치는 것은 너무 이릅니다. 스펙은 Draft 단계이고, 보안 모델은 완전하지 않으며, API 명세는 언제든 바뀔 수 있습니다. 반면 준비를 전혀 하지 않는 것도 잘못입니다. 검색 최적화를 일찍 시작한 사이트가 수십 년째 혜택을 누리듯, 에이전트 최적화도 선점 효과가 누적됩니다.
지금 할 수 있는 가장 합리적인 행동은 하나입니다. 실험은 시작하되, 프로덕션 배포는 스펙이 안정화된 이후로 미루는 것. Chrome 플래그를 켜고 공식 데모를 돌려보세요. navigator.modelContext가 어떻게 작동하는지 직접 느끼는 것이 어떤 글보다 빠른 이해의 지름길입니다.
개인적으로는 WebMCP가 단순한 개발자 도구를 넘어, 웹 비즈니스의 수익 구조를 바꿀 가능성이 충분하다고 봅니다. 에이전트가 직접 구매 완료 버튼을 누르는 세상에서, 내 사이트가 그 에이전트에게 “실행 가능한 곳”으로 인식되느냐 그렇지 않느냐는 단순한 기술 격차가 아니라 매출 격차로 이어질 것이기 때문입니다.
📚 본 포스팅 참고 자료
- Chrome for Developers — WebMCP Early Preview 공식 발표 (2026.02.10)
- Chrome for Developers — WebMCP와 MCP 사용 시기 공식 가이드 (2026.03.11)
- W3C Web Machine Learning Community Group — WebMCP 초안 스펙
- Zuplo — WebMCP 기술 심층 분석 (2026.03.13)
- Search Engine Land — Chrome 146 WebMCP 심층 분석
- Ivan Turković — WebMCP 보안 및 아키텍처 분석 (2026.02.15)
- Security Boulevard — MCP 보안 위기 분석 (2026.01.25)
본 포스팅은 2026년 3월 15일 기준으로 작성되었습니다. WebMCP는 현재 W3C 초안(Draft Community Group Report) 단계로, 본 포스팅 작성 이후 서비스 정책·API 명세·브라우저 지원 범위·UI가 변경될 수 있습니다. Chrome 버전 및 플래그 명칭은 업데이트에 따라 달라질 수 있으므로 공식 문서를 반드시 함께 참고하시기 바랍니다.
댓글 남기기