WebMCP, HTML 속성 2개로 된다고요?
이건 확인이 필요합니다

2026년 2월 10일, 구글 크롬 팀이 조용히 블로그 포스트를 하나 올렸습니다. WebMCP — AI 에이전트가 웹페이지에서 버튼을 찾아 클릭하는 대신, 사이트가 직접 제공하는 함수를 호출하게 만드는 브라우저 표준 제안입니다. 인터넷이 30년간 사람을 위해 설계되어 왔다면, WebMCP는 그 옆에 기계를 위한 두 번째 인터페이스 레이어를 만들려는 시도입니다. 생각보다 빠르게 진행되고 있고, 생각보다 조건이 까다롭습니다.

AI 에이전트는 지금 뭘 보고 있나요?

솔직히 말하면, 현재 AI 에이전트의 웹 탐색 방식은 꽤 낭비적입니다. 화면을 스크린샷으로 캡처하고, DOM 트리를 파싱하고, “이게 예약 버튼인가?”를 추론합니다. 항공권 검색 하나에 수천 개의 토큰이 소모되고, 사이트가 A/B 테스트로 버튼 위치를 바꾸면 에이전트는 바로 멈춥니다. 현재 크롬의 자동 탐색 기능은 Gemini가 페이지를 “시각적으로 보면서” 조작하는 방식인데, 이게 작동하긴 하지만 느리고 불안정합니다.

WebMCP는 이 문제의 출발점을 다르게 잡습니다. 에이전트가 사람처럼 행동하게 만드는 대신, 사이트가 에이전트에게 직접 함수 목록을 건네주는 방식입니다. “이 페이지에서 할 수 있는 것, 필요한 입력값, 반환 형식”을 구조화된 스키마로 미리 선언합니다. 에이전트는 버튼을 찾을 필요 없이 함수를 호출하면 됩니다.

이게 단순한 편의 기능처럼 들린다면, 조금 달리 생각해볼 필요가 있습니다. 웹이 사람용 레이어 하나로 30년을 달려왔다면, WebMCP는 기계용 두 번째 레이어를 동일한 코드베이스 위에 추가하는 제안입니다. 두 개의 인터넷이 한 사이트 안에서 동시에 서비스되는 구조입니다.

WebMCP가 하는 일 — 함수 호출로 웹을 바꾼다

WebMCP는 크롬 브라우저에 navigator.modelContext라는 새 API를 추가합니다. 이 API를 통해 웹사이트는 AI 에이전트가 발견하고 호출할 수 있는 도구(tool)를 등록합니다. (출처: Chrome for Developers 공식 블로그, 2026-02-10)

구현 방법은 두 가지입니다. 선언형(Declarative) API는 기존 HTML 폼에 toolname과 tooldescription 속성만 추가하면 브라우저가 자동으로 스키마를 생성합니다. 명령형(Imperative) API는 JavaScript로 navigator.modelContext.registerTool()을 호출해 복잡한 다단계 워크플로우를 직접 등록합니다. 두 방식을 같은 페이지에서 함께 쓸 수 있습니다.

실제 적용 시나리오를 보면 감이 잡힙니다. 여행 예약 사이트가 search_flights({ origin: "ICN", destination: "LAX", date: "2026-05-10" })를 툴로 등록해두면, 에이전트는 날짜 선택 캘린더 위젯을 클릭할 필요 없이 이 함수를 바로 호출합니다. 구글이 공식 여행 예약 데모를 이미 공개했습니다. (출처: Chrome for Developers, 2026-03-11)

HTML 속성 2개면 충분하다는 말, 절반만 맞습니다

기대했던 것과 달랐습니다. 선언형 API 자체는 정말 간단합니다. 폼 태그에 toolname="searchFlights"와 tooldescription="항공편 검색" 두 줄만 추가하면, 나머지는 브라우저가 자동으로 스키마를 생성합니다. 시멘틱 HTML과 접근성을 이미 신경 써서 폼을 잘 만들어 둔 사이트라면 진입 비용이 매우 낮습니다.

명령형 API로 넘어가면 장점이 역전됩니다. 툴 이름, 설명, JSON 입력 스키마, 실행 콜백을 직접 정의하는데, 핵심은 execute 함수가 그냥 기존 JavaScript라는 점입니다. 별도 API나 통합 레이어를 새로 만들 필요 없이 이미 있는 비즈니스 로직을 그대로 노출합니다. 기존 인증 컨텍스트, 세션 상태도 모두 상속됩니다. 단, 여기서도 조건이 있습니다. UI와 로직이 깔끔하게 분리된 아키텍처여야 의미 있는 툴을 만들 수 있습니다. 스파게티 코드로는 WebMCP도 스파게티가 됩니다.

지금 당장 테스트해보려면 크롬 146.0.7672.0 이상 버전에서 chrome://flags/#enable-webmcp-testing으로 이동해 “WebMCP for testing” 플래그를 활성화하고 재시작하면 됩니다. 크롬 웹 스토어에서 Model Context Tool Inspector 확장 프로그램을 설치하면 페이지에 등록된 툴을 직접 확인하고 실행해볼 수 있습니다. (출처: Search Engine Land, 2026-03-04)

MCP를 이미 쓰고 있다면 WebMCP도 써야 할까요?

이게 핵심입니다. 많은 개발자가 “WebMCP가 MCP를 대체하는 건가?” 묻는데, 구글 공식 문서는 2026년 3월 11일 업데이트에서 이를 명시적으로 부정합니다. “WebMCP is not an extension or a replacement of MCP.” (출처: Chrome for Developers 공식 블로그, 2026-03-11) 두 기술은 다른 문제를 풀고 있습니다.

실전 패턴은 이렇습니다. MCP 서버가 핵심 비즈니스 로직과 데이터 접근을 처리하고(언제나 가용), WebMCP는 사용자가 해당 사이트를 브라우저로 열고 있을 때 실시간으로 맥락에 맞는 툴을 노출합니다. 두 기술을 함께 쓸 때 가장 강력한 에이전틱 경험이 나옵니다. 둘 중 하나를 고르는 게 아닙니다.

탭이 닫히면 사라집니다 — 이 특성이 왜 중요한가

이게 단순한 제약이 아닙니다. 두 가지 의미가 있습니다. 첫째, 보안 측면에서 유리합니다. 툴이 살아있는 세션 밖으로 나가지 않기 때문에, 사용자가 로그아웃하거나 탭을 닫으면 에이전트도 자동으로 차단됩니다. MCP 서버처럼 상시 실행 중인 데몬이 탈취되는 위험은 없습니다. 둘째, 설계 관점에서 제약입니다. “백그라운드에서 에이전트가 알아서 처리해줬으면”이라는 기대에는 부응하지 못합니다. 사용자가 해당 페이지를 보고 있어야만 작동하는 실시간 보조 도구에 가깝습니다.

생각보다 간단합니다. 이 에페머럴 특성 때문에 WebMCP는 “사용자가 지금 이 사이트에 있을 때” 에이전트가 최대한 빠르고 정확하게 돕게 만드는 용도에 최적화됩니다. 예약 완료, 폼 자동 입력, 장바구니 조작 같은 단일 세션 내 작업이 주요 유스케이스입니다.

보안 구멍은 이미 실제로 뚫렸습니다

이 부분이 좀 아쉬웠습니다. WebMCP는 MCP 생태계의 보안 문제를 그대로 상속합니다. 그리고 MCP의 실제 사고는 이미 기록되어 있습니다.

GitHub MCP 서버에 대한 프롬프트 인젝션 공격으로 AI 코딩 어시스턴트가 비공개 저장소 내용을 유출했습니다. WhatsApp MCP 서버는 “툴 포이즈닝” 공격으로 사용자의 전체 메시지 기록이 외부 서버로 전송됐습니다. 악성 MCP 패키지가 이메일 BCC 사본을 공격자 서버로 조용히 보내는 사례도 있었습니다. (출처: Security Boulevard, 2026-01-30; Palo Alto Unit42, 2026-03-03)

현재 안전 장치는 오리진 기반 권한(등록한 도메인에서만 작동)과 requestUserInteraction()이라는 사용자 확인 메커니즘이 있습니다. 기본 설정에서는 폼이 시각적으로 채워진 뒤 사용자가 직접 제출 버튼을 누르게 되어 있어 인간이 루프 안에 있습니다. 이 기본값을 바꾸는 순간부터는 개발자의 책임이 커집니다.

SEO가 그랬던 것처럼, 다음 경쟁은 툴 설명문에서 납니다

이 발견 레이어가 등장하면 툴 설명문이 메타 디스크립션처럼 작동합니다. 에이전트는 “항공편 예약 도와줘”라는 요청에 여러 여행 사이트의 툴 목록을 훑고 가장 명확하고 신뢰할 수 있어 보이는 툴을 선택합니다. 툴 이름에 명확한 동사를 쓰고(search_flights가 doFlight보다 낫다), 설명이 정확하고 파라미터가 잘 구조화된 툴이 에이전트의 선택을 받습니다. 구글 공식 문서도 이를 “AEO(Agentic Engine Optimization)”의 시작점으로 암시합니다. (출처: Search Engine Land, 2026-03-04)

단, 현실적으로 체크해야 할 점이 있습니다. 지금은 에이전트가 탭을 열어야만 툴을 발견할 수 있습니다. 발견 메커니즘이 없는 상태에서 AEO를 지금 당장 급하게 준비할 필요는 없습니다. 프로토타입을 만들고 구조를 파악해두는 것으로 충분합니다.

막상 써보면 이 단계에서 멈춥니다 — 크롬 이외 브라우저 지원이 없습니다. Firefox, Safari, Edge는 현재 W3C 워킹 그룹에 참여 중이지만 구현 타임라인을 공개하지 않았습니다. WebMCP는 크롬 전용 실험입니다. (출처: ivanturkovic.com, 2026-02-15; Chrome for Developers, 2026-03-11)

Q&A — 자주 나오는 질문들

마치며

WebMCP가 흥미로운 이유는 기술 자체가 아니라 방향 때문입니다. 웹을 사람과 기계가 동시에 사용하는 이중 인터페이스로 바꾸겠다는 시도이고, Google과 Microsoft가 공동으로 W3C 표준 제안으로 올렸다는 건 이 방향이 단순한 실험이 아님을 의미합니다. 1990년대 robots.txt가 그랬던 것처럼, 에이전트를 위한 기계 가독성 레이어를 먼저 붙인 사이트가 다음 세대 트래픽을 선점할 가능성이 있습니다.

다만 지금 당장 프로덕션에 넣는 건 이릅니다. API가 변경될 수 있고, 보안 모델은 아직 미완성이며, 크롬 이외 브라우저 지원도 불확실합니다. 지금은 크롬 플래그를 켜고 데모를 돌려보면서 본인 사이트의 어떤 기능을 툴로 노출할 수 있을지 구조를 생각해두는 단계가 맞습니다.

이게 핵심입니다 — WebMCP는 “대체”가 아닌 “추가”입니다. 기존 MCP, 기존 UI, 기존 API 위에 에이전트를 위한 레이어 하나를 더 얹는 개념입니다. 복잡하게 생각할 필요 없이, 잘 만들어둔 HTML 폼이 있다면 속성 두 개가 출발점이 됩니다. 그 조건이 충족될 때만 “HTML 2개로 된다”는 말이 맞습니다.

📚 본 포스팅 참고 자료

1. Chrome for Developers 공식 블로그 — WebMCP 얼리 프리뷰 발표 (2026-02-10): https://developer.chrome.com/blog/webmcp-epp
2. Chrome for Developers 공식 블로그 — WebMCP vs MCP 사용 시기 (2026-03-11): https://developer.chrome.com/blog/webmcp-mcp-usage
3. Search Engine Land — Chrome 146 WebMCP 가이드 (2026-03-04): https://searchengineland.com/webmcp-explained-inside-chrome-146s-agent-ready-web-preview-470630
4. Security Boulevard — MCP 보안: 프롬프트 인젝션 및 툴 포이즈닝 방지 (2026-01-30): https://securityboulevard.com/2026/01/…
5. ivanturkovic.com — WebMCP is Coming: How AI Agents Will Reshape the Web (2026-02-15): https://www.ivanturkovic.com/…