WebMCP란? 웹사이트가 AI 에이전트용 API가 되는 브라우저 표준

이번 포스팅에서는 WebMCP에 대해서 정리하고자 한다. 요즘 AI 에이전트가 사람을 대신해 웹사이트에서 항공권을 검색하거나 장바구니에 물건을 담는 시연을 자주 본다. 그런데 이런 에이전트는 대부분 사람이 보라고 만든 화면을 억지로 읽어 내며(스크래핑) 동작해, 화면이 조금만 바뀌어도 헤맨다. WebMCP는 이 방식을 뒤집는다. 웹사이트가 AI 에이전트에게 “여기 네가 쓸 수 있는 도구가 있어”라고 직접 알려 주게 만드는 새로운 브라우저 표준이다. 구글과 마이크로소프트 엔지니어들이 함께 제안했고, 크롬에 실험적으로 실려 화제가 되고 있다. 이 글에서는 WebMCP가 정확히 무엇인지, 이미 알려진 MCP와 무엇이 다른지, 그리고 왜 지금 주목받는지를 코드 없이 개념 중심으로 풀어 본다.

한눈에 보는 핵심 정리

WebMCP는 웹페이지가 자바스크립트 함수를 “AI가 호출할 수 있는 도구”로 등록해, 브라우저 안의 AI 에이전트가 화면을 긁지 않고 그 도구를 바로 불러 쓰게 하는 제안 단계의 브라우저 표준이다.

• 누가: 구글과 마이크로소프트 엔지니어들이 W3C 산하 Web Machine Learning 커뮤니티 그룹에서 인큐베이팅 중이다.
• 무엇을: 웹사이트가 브라우저의 document.modelContext API로 도구를 등록하면, 에이전트가 그 도구 목록을 발견해 직접 호출한다.
• 왜 중요한가: 사람용 화면을 추측으로 조작하던 방식에서, 웹사이트가 기계용 창구를 정식으로 여는 방식으로 바뀐다.
• 지금 상태: 정식 표준이 아니라 W3C 커뮤니티 그룹 초안(2026년 4월 최신 보고서) 단계이며, Chrome 149에서 실험적 시험 운영(origin trial) 중이다.

어떻게 된 일인가

WebMCP는 2026년 2월 처음 공개된 뒤, 크롬에 실험 기능으로 실리면서 본격적으로 주목받기 시작했다. 웹페이지가 브라우저의 modelContext 인터페이스를 통해 자신의 기능을 “도구”로 등록하면, 브라우저에서 동작하는 AI 에이전트가 그 도구를 찾아 호출한다는 것이 핵심이다. 예를 들어 쇼핑몰이라면 “상품 검색”, “장바구니에 담기” 같은 기능을 도구로 노출할 수 있다.

여기서 클라우드플레어가 자사 블로그를 통해 WebMCP 지원을 발표하면서 관심이 커졌다. 클라우드플레어는 웹사이트에 스크립트 한 줄을 넣으면 기존 기능을 WebMCP 도구로 자동 노출해 준다고 소개했다. 발표문의 표현을 빌리면, 이제 “에이전트가 사람을 위해 만들어진 페이지를 더듬어 추측할 필요가 없다”는 것이다.

주의할 점은 API가 아직 빠르게 바뀌고 있다는 것이다. 처음에는 navigator.modelContext로 공개됐지만, 도구는 특정 페이지에 속한다는 이유로 스펙이 이를 document.modelContext로 옮겼고, Chrome 150에서는 구형 navigator.modelContext가 지원 중단(deprecated) 예정으로 표시됐다. 즉 지금 정확한 진입점은 document.modelContext다. 이렇게 세부가 흔들리는 건 초안 단계라는 방증이기도 하다.

기술 표준으로서 WebMCP는 아직 확정된 것이 아니다. W3C의 정식 표준이 아니라 Web Machine Learning 커뮤니티 그룹의 초안 보고서(최신 2026년 4월 23일자) 단계이고, 표준 트랙에 오른 것도 아니다. 브라우저 지원도 아직 크롬 계열에 한정된다. 실제 구현은 Chrome이 선도해 origin trial까지 왔고, 같은 크로미움 엔진을 쓰는 Edge가 뒤이어 지원할 가능성이 높다. 반면 Firefox와 Safari는 스펙 논의에는 참여하지만 지원 시기를 밝히지 않았다. 다만 구글과 마이크로소프트가 함께 밀고 있다는 점에서, 논의가 빠르게 진행될 가능성은 높다.

이게 왜 중요한가

WebMCP가 중요한 이유는 AI 에이전트가 웹을 다루는 방식을 근본적으로 바꾸기 때문이다. 지금까지 에이전트는 사람이 보라고 만든 화면(HTML)을 읽어 버튼 위치를 추측하고 클릭을 흉내 냈다. 이 방식은 화면 구조가 조금만 바뀌어도 깨지고, 웹사이트 입장에서는 원치 않는 자동 접근이라 대응이 어려웠다. WebMCP는 웹사이트가 스스로 기계용 창구를 열어 주므로, 이 추측과 마찰을 없앤다.

비유하자면 이렇다. 기존 방식이 로봇에게 식당에 들어가 메뉴판 사진을 찍어 글자를 해독하고 종업원 흉내를 내며 주문하게 하는 것이라면, WebMCP는 식당이 로봇 전용 주문 창구를 하나 열어 두는 것이다. 로봇은 그 창구에서 “메뉴 조회”, “주문하기” 같은 정해진 기능을 정확히 부르기만 하면 된다. 화면이 바뀌어도, 창구의 규격만 유지되면 로봇은 헤매지 않는다.

이 변화는 웹사이트 운영자에게도 의미가 크다. 클라우드플레어의 설명에 따르면 도구는 방문자의 브라우저 안에서, 그 방문자의 로그인 세션을 그대로 이용해 실행된다. 즉 사람이 통제권을 쥔 채로 에이전트가 동작하고, 사이트는 자기 트래픽을 잃지 않는다. 무단 스크래핑으로 콘텐츠만 빨려 나가던 구도와 달리, 이제 웹사이트가 어떤 기능을 어떻게 열지 스스로 정한다.

MCP와 WebMCP, 이름은 비슷한데 뭐가 다른가

가장 헷갈리는 지점이 이름이다. 이미 널리 쓰이는 MCP(Model Context Protocol)와 WebMCP는 개념은 닮았지만 동작하는 자리가 완전히 다르다. MCP는 AI 모델을 서버 쪽 도구에 연결하는 프로토콜로, 보통 백엔드에서 돌아간다. 반면 WebMCP는 브라우저 안에서 웹페이지가 직접 도구를 노출하는 방식이다.

앤트로픽이 만든 MCP는 서버 간 통신 규약이다. AI 모델이 파일 시스템, 데이터베이스, 사내 API 같은 외부 도구에 접근할 때 쓰는 표준으로, 개발자가 MCP 서버를 따로 띄워 연결한다. 이 블로그에서도 MCP 실전 가이드나 IntelliJ MCP 서버 연동에서 다룬 그 MCP다. 개발 도구나 백엔드 세계의 이야기다.

WebMCP는 그 개념을 브라우저로 가져온 것이다. 별도 서버를 띄우는 대신, 웹페이지의 자바스크립트가 브라우저 API로 도구를 등록하고, 사용자의 브라우저에서 함께 도는 에이전트가 그걸 호출한다. 두 기술은 “AI에게 도구를 제공한다”는 발상을 공유하지만, MCP는 서버에서 JSON-RPC로 통신하고 WebMCP는 브라우저 자체 API로 동작한다는 점에서 서로 다른 층에 있다. 이름이 비슷해 혼동하기 쉽지만, 하나는 백엔드용, 다른 하나는 브라우저용이라고 기억하면 된다.

표로 보면 둘의 관계가 분명해진다. 발상은 “AI에게 도구를 준다”로 같지만, MCP가 백엔드에서 이미 자리 잡은 규약이라면 WebMCP는 그 아이디어를 브라우저 앞단으로 끌어와 이제 막 실험을 시작한 표준이다.

그래서 지금은 어떻게 생겼나 — 도구 등록과 실험 방법

개념만으로는 감이 잘 안 오니, 도구 하나가 실제로 어떻게 등록되는지 형태만 짚어 보자. 웹페이지는 document.modelContext.registerTool로 도구의 이름·설명·입력 형식·실행 함수를 함께 넘긴다. 에이전트는 이 설명을 읽고 언제 어떤 도구를 부를지 판단한다.

// 웹페이지가 "장바구니 담기" 기능을 에이전트용 도구로 등록
document.modelContext.registerTool({
  name: "add_to_cart",
  description: "상품 ID를 받아 장바구니에 담는다",
  inputSchema: { /* 파라미터 정의 (예: productId) */ },
  async execute({ productId }) {
    // 실제 사이트의 기존 로직 재사용
    return await cart.add(productId);
  }
});

// 웹페이지가 "장바구니 담기" 기능을 에이전트용 도구로 등록
document.modelContext.registerTool({
  name: "add_to_cart",
  description: "상품 ID를 받아 장바구니에 담는다",
  inputSchema: { /* 파라미터 정의 (예: productId) */ },
  async execute({ productId }) {
    // 실제 사이트의 기존 로직 재사용
    return await cart.add(productId);
  }
});

핵심은 description이다. 에이전트가 이 문장을 근거로 도구를 고르므로, 사람이 읽는 버튼 라벨보다 훨씬 구체적으로 “무엇을 하는 도구인지”를 적어 주는 게 중요하다. 폼(form)이 이미 있는 페이지라면 코드 없이 <form> 요소에 toolname·tooldescription 속성만 붙이는 선언형(declarative) 방식도 지원한다. 등록된 도구는 그 페이지에 묶이므로, 화면이 사라지면 도구도 함께 내려 사용자가 못 보는 기능을 에이전트가 부르는 일을 막는다.

당장 손으로 확인해 보고 싶다면 방법이 있다. Chrome 149의 origin trial에 참여하거나, 구글이 내놓은 Model Context Tool Inspector 확장을 설치하면 특정 페이지에 등록된 도구 목록을 눈으로 보고 직접 실행해 볼 수 있다. 앞서 언급한 클라우드플레어의 스크립트처럼, 기존 사이트에 코드를 거의 건드리지 않고 도구를 붙여 주는 서비스도 등장하고 있어 진입 장벽은 계속 낮아지는 중이다.

우리 생활·업무에 미치는 영향

WebMCP가 자리 잡으면 AI 에이전트에게 일을 시키는 경험이 훨씬 안정적으로 바뀐다. “이 쇼핑몰에서 어제 본 신발 다시 장바구니에 담아 줘” 같은 부탁이, 화면 구조에 흔들리지 않고 정확히 실행될 수 있다. 웹사이트가 공식 창구를 열어 두는 만큼, 에이전트가 엉뚱한 버튼을 누르거나 절차를 건너뛰는 사고도 줄어든다.

보안 측면에서도 안심할 구석이 있다. WebMCP는 브라우저의 보안 모델을 그대로 따르도록 설계됐다. 각 사이트의 도구는 그 사이트 출처(origin)에 격리돼 다른 사이트가 넘볼 수 없고, 암호화된 HTTPS 연결에서만 동작하며, 중요한 동작에는 사용자의 확인을 거치도록 사람이 개입하는 구조를 둔다. 에이전트가 사용자 몰래 결제를 진행하는 식의 시나리오를 표준 차원에서 막으려는 것이다.

물론 아직 갈 길이 멀다. 제안 단계인 데다 크롬 실험 기능이라, 실제로 널리 쓰이려면 표준 확정과 다른 브라우저의 채택이 필요하다. 그럼에도 방향은 분명하다. 웹이 사람만이 아니라 에이전트도 1급 사용자로 받아들이기 시작했고, WebMCP는 그 입구를 표준으로 만들려는 첫 시도다. AI 에이전트를 업무에 붙여 쓰는 사람이라면, 지금부터 이름 정도는 알아 둘 가치가 있다.

FAQ

더 알아보기

WebMCP는 아직 초안 단계라 앞으로 세부가 바뀔 수 있지만, 웹과 AI 에이전트가 만나는 지점을 표준으로 정리하려는 흐름 자체는 되돌리기 어려워 보인다. 개인적으로는 MCP가 개발 도구 세계에서 빠르게 퍼진 걸 지켜본 터라, 그 개념이 브라우저로 넘어오는 이번 시도도 눈여겨보게 된다. MCP가 무엇인지부터 짚고 싶다면 이 블로그의 MCP 실전 가이드를, 자세한 원문은 클라우드플레어 WebMCP 발표를 참고하면 좋다. 웹이 에이전트를 손님으로 맞을 준비를 시작했다는 신호로 읽으면 충분하다.