WebMCP, MCP 대체한다고요?
이 조건이면 다릅니다

구글이 Chrome 146에 조용히 심어놓은 WebMCP가 화제입니다. “드디어 MCP를 대체할 기술이 나왔다”는 말이 돌고 있는데, 공식 문서를 직접 읽어보면 얘기가 완전히 달라집니다. AI 에이전트가 웹사이트와 상호작용하는 방식을 근본적으로 바꿔놓는 건 맞지만, WebMCP가 작동하는 조건과 작동하지 않는 조건이 명확히 나뉩니다.

AI 에이전트가 웹사이트에서 뭘 하고 있었는지

비행기 예매를 시키면 AI 에이전트는 어떻게 작동할까요? 사람처럼 화면을 스캔하고, 버튼이 어디 있는지 추측하고, 클릭을 시도합니다. 실제로 작업 하나당 스크린샷 30~50장을 찍고 각각 멀티모달 모델로 분석하는 과정을 반복하는데, 이 단순한 흐름이 토큰 약 1만 개, 비용으로는 건당 약 $0.15를 소비합니다. (출처: Medium/@itsvksharma_, 2026.02.18)

문제는 비용만이 아닙니다. 웹사이트가 디자인을 조금만 바꿔도 — 버튼 위치 5픽셀, 필드 이름 변경 — 에이전트는 그 즉시 멈춥니다. 시각적 추론에 의존하다 보니, 어제 됐던 게 오늘은 안 되는 일이 반복됩니다. 성공률은 60~70% 수준. 나머지 30~40%는 그냥 실패입니다.

WebMCP는 이 구조 자체를 바꿉니다. 에이전트가 화면을 “보는” 게 아니라, 함수를 “호출”하도록 합니다.

WebMCP가 뭔지, 공식 문서에서 직접 확인했습니다

WebMCP는 구글과 마이크로소프트 엔지니어들이 공동으로 설계하고, W3C 웹 머신러닝 커뮤니티 그룹에서 표준화를 진행 중인 브라우저 표준 제안입니다. (출처: Chrome for Developers 공식 블로그, 2026.02.10) Chrome 146 Canary 빌드에 chrome://flags/#enable-webmcp-testing 플래그를 활성화하면 지금 바로 써볼 수 있습니다.

핵심 개념은 간단합니다. 웹사이트 개발자가 자신의 사이트 기능을 “에이전트가 부를 수 있는 함수”로 등록해 두면, AI 에이전트는 화면을 읽는 대신 그 함수를 직접 호출합니다. 비행기 예매라면 에이전트가 “bookFlight(origin: ‘ICN’, destination: ‘LAX’, date: ‘2026-06-10’, passengers: 2)” 형태로 호출하고, 사이트는 확인번호와 가격을 구조화된 형태로 돌려줍니다.

API 구조는 두 가지입니다. HTML 폼에 속성 몇 줄을 추가하는 선언적 API(Declarative API)와, JavaScript로 복잡한 로직을 등록하는 명령형 API(Imperative API)입니다. 기존 사이트에 코드 몇 줄만 더하면 에이전트 친화적 사이트로 바뀐다는 게 구글의 설명입니다. (출처: Chrome for Developers 공식 블로그, 2026.02.10)

MCP와 WebMCP, 어떻게 다른가

구글 크롬 공식 블로그(2026.03.11)가 명확히 선을 그었습니다. “WebMCP는 MCP를 대체하지 않는다”고 직접 밝혔습니다. 두 기술은 역할이 분리되어 있습니다.

비유하자면 이렇습니다. MCP는 기업의 고객센터 콜센터와 같습니다. 언제 어디서든 전화해서 데이터를 요청하거나 작업을 시킬 수 있습니다. WebMCP는 매장 안의 전문 직원입니다. 매장 안에서만, 그것도 손님(사용자)이 매장에 들어와 있는 동안에만 일을 합니다.

공식 문서는 둘을 함께 쓰는 방식을 권장합니다. MCP로 핵심 비즈니스 로직과 데이터를 처리하고, WebMCP로 브라우저 안의 UI 조작을 담당하는 구조입니다. (출처: Chrome for Developers 공식 블로그, 2026.03.11) MCP가 없어질 이유가 없습니다.

탭을 닫으면 끝나는 이유 — 이게 버그가 아닙니다

WebMCP 도구는 탭 기반(Ephemeral) 수명을 가집니다. 사용자가 탭을 닫거나 다른 페이지로 이동하면, 에이전트는 더 이상 해당 사이트에 접근하거나 작업을 수행할 수 없습니다. (출처: Chrome for Developers 공식 블로그, 2026.03.11)

이 구조 덕분에 WebMCP의 도구는 사용자의 현재 세션, 쿠키, 인증 정보를 그대로 활용합니다. 에이전트가 로그인된 사용자로서 행동하는 게 가능해지면서, 동시에 그 행동 범위는 사용자가 브라우저를 보고 있는 시간으로 제한됩니다. 사용자 모르게 백그라운드에서 뭔가를 처리하는 건 구조적으로 불가능합니다.

보안 관점에서도 양쪽에 허가 요청이 발생합니다. 사이트가 도구를 등록할 때, 그리고 에이전트가 도구를 호출할 때 브라우저가 사용자에게 각각 허가를 묻습니다. (출처: 4sysops.com, 2026.02.16) 브라우저가 중개자 역할을 하면서 무분별한 접근을 차단하는 구조입니다.

지금 직접 써볼 수 있는 방법

Chrome 146.0.7672.0 이상의 Canary 빌드가 필요합니다. 아래 순서대로 따라 하면 됩니다.

1. Chrome Canary를 설치하고 chrome://flags/#enable-webmcp-testing 접속
2. “WebMCP for testing” 플래그를 Enabled로 변경 후 Chrome 재시작
3. Chrome 웹 스토어에서 Model Context Tool Inspector 확장 프로그램 설치
4. 구글 공식 트래블 데모 페이지에서 도구 목록 확인 및 자연어 호출 테스트

확장 프로그램을 설치하면 현재 페이지에 등록된 WebMCP 도구 목록을 시각적으로 확인하고, 직접 파라미터를 입력해 실행해볼 수 있습니다. Gemini API를 연결하면 자연어로 도구를 호출하는 흐름도 테스트할 수 있습니다. (출처: searchengineland.com, 2026.03.04)

아직 믿고 쓰면 안 되는 조건들

솔직히 말하면, 아직 프로덕션에 쓰기에는 이릅니다. 지금 시점의 한계를 공식 문서 기준으로 정리하면 이렇습니다.

이 제약들이 있음에도 불구하고 지금 주목해야 하는 이유는 하나입니다. 모바일 최적화가 2010년대 초반 선점 게임이었듯, 에이전트 친화적 웹 구현도 선점 타이밍이 있습니다. 표준이 확정되기 전에 프로토타이핑하고 설계 방향을 익혀두는 것은, 뒤늦게 따라가는 것과 체감상 완전히 다릅니다.

Q&A

마치며

WebMCP를 한 줄로 요약하면, “AI 에이전트가 화면을 추측하는 대신 함수를 호출하게 만드는 브라우저 표준“입니다. 당장 쓸 수 있는 기술은 아니지만, 방향은 명확합니다.

MCP와 WebMCP는 경쟁하는 기술이 아닙니다. MCP가 서버 사이드의 일을 담당하고, WebMCP가 브라우저 UI의 일을 담당합니다. 두 기술을 함께 쓸 때 비로소 에이전트가 사용자를 온전히 대신할 수 있는 흐름이 만들어집니다.

아직 Chrome Canary에서 플래그를 켜야 한다는 사실이 “아직 멀었구나”처럼 보일 수 있습니다. 그런데 2010년대 초, 반응형 웹이 처음 나왔을 때도 비슷했습니다. 먼저 손댄 사람들이 표준이 자리 잡히는 시점에 훨씬 유리한 자리에 있었습니다. WebMCP도 그런 타이밍의 기술일 수 있습니다.

📚 본 포스팅 참고 자료

1. WebMCP is available for early preview — Chrome for Developers (2026.02.10)
2. WebMCP and MCP usage — Chrome for Developers (2026.03.11)
3. What is Microsoft’s and Google’s new WebMCP standard? — 4sysops (2026.02.16)
4. WebMCP explained: Inside Chrome 146’s agent-ready web preview — Search Engine Land (2026.03.04)
5. WebMCP Early Preview Program 신청 — Chrome for Developers