WebMCP는 무엇인가…에이전트가 화면 대신 함수를 부른다

브라우저에 붙은 AI에게 항공권을 찾아 달라고 시켜 본 사람은 답답함을 안다. 화면을 읽고 입력란을 짐작해 채우다가 엉뚱한 날짜를 넣는다. WebMCP는 이 방식을 뒤집는다. 사이트가 자기 기능을 함수로 내놓고, 에이전트는 그 함수를 부른다.

크롬(Google Chrome) 공식 개발자 문서는 이 규격을 “AI 에이전트를 위한 구조화된 툴을 만들고 노출하도록 돕는 웹 표준 제안”(a proposed web standard to help you build and expose structured tools for AI agents)이라고 소개한다. 버튼의 의도를 에이전트가 짐작하는 대신 사이트가 먼저 선언한다는 점이 핵심이다.

식당에서 종업원이 손님의 손짓을 해석하는 일과, 주문서를 내주는 일의 차이에 가깝다.

함수 선언의 본질… 이름·설명·입력 스키마의 3대 구조

사이트가 명시하는 핵심 정보는 툴 이름과 자연어로 작성된 설명, 그리고 입력 형식이다. 이 입력 형식을 ‘입력 스키마(input schema)’라고 부르는데, 어떤 값을 몇 개 받고 각각이 무슨 뜻인지 미리 규정해 둔 데이터 양식이다.

기사 검색 기능을 툴로 내놓는다면 직관적인 형태를 띤다. 이름은 search_articles, 설명은 ‘키워드로 기사를 검색한다’, 입력은 검색어 문자열 하나다. 에이전트는 이 세 줄의 선언만 읽고도 해당 함수가 어떤 목적을 수행하는지 즉각 판단한다. 여기서 설명 항목은 사람이 읽기 전에 AI 모델이 가장 먼저 읽고 해석하는 자리다.

W3C 웹 머신러닝 커뮤니티 그룹의 규격 초안에 실린 대표적 예시는 할 일 목록에 항목을 추가하는 툴이다. 실제 등록 코드는 다음과 같은 간결한 형태다.

await document.modelContext.registerTool({
  name: "add-todo",
  description: "Add a new item to the user's active todo list",
  inputSchema: {
    type: "object",
    properties: {
      text: { type: "string" }
    }
  },
  async execute({ text }) {
    await addTodoItemToCollection(text);
  }
});

마지막 줄의 addTodoItemToCollection은 사이트가 기존부터 운용해 오던 내부 자바스크립트 함수다. 개발자가 새로 작성하는 코드는 해당 함수에 붙이는 이름표와 인터페이스 선언뿐이다. 규격 초안은 툴을 등록하는 registerTool과 목록을 조회하는 getTools, 호출을 실행하는 executeTool 3개를 표준 인터페이스로 규정했다. 자바스크립트 코드를 직접 작성하지 않는 대안도 열려 있다. 크롬 문서는 기존 HTML 폼(Form) 요소에 전용 속성을 덧붙여 툴로 등록하는 방식을 함께 제시한다. 사이트에 이미 구현된 검색창 하나에 식별자 속성만 부여하면, 에이전트가 호출할 수 있는 구조화된 툴로 곧바로 변환된다.

브라우저 런타임 실행… ‘눈에 보이는 동작’과 사용자 신뢰

이 지점이 WebMCP의 성격을 가르는 가장 본질적인 대목이다. 툴은 원격 서버가 아니라 사용자가 눈으로 보고 있는 바로 그 웹페이지(브라우저 탭) 내부에서 구동된다. 크롬 문서는 이러한 아키텍처 설계의 이유로 “툴이 웹페이지에서 눈에 보이게 실행되므로 사용자가 작업이 기대한 대로 끝났다는 신뢰를 얻는다”(Tools execute on your webpage visibly, so users gain trust that tasks are completed as expected)는 점을 강조했다. 에이전트가 어떤 버튼과 기능을 트리거했는지 사용자가 실시간 화면을 통해 직관적으로 확인할 수 있으며, 에이전트가 사용자 시야 밖의 백엔드 깊숙한 곳에서 작업을 처리하고 결과만 일방 통보하는 구조와는 완전히 차별화된다.

백엔드 MCP vs 프런트엔드 WebMCP… 인증과 UI 보존의 분기점

명칭이 유사해 혼동하기 쉽지만 두 기술은 명확한 층위의 차이를 지닌다. AI에 외부 기능을 연결하는 표준 규격인 MCP(Model Context Protocol)는 에이전트가 서비스의 백엔드 서버와 직접 통신하는 방식이다. 반면 WebMCP는 브라우저 런타임 환경 안에서 웹페이지와 직접 결합한다.

깃허브에 공개된 규격 설명서(Explainer)는 기존 백엔드 연동 방식의 한계를 “백엔드 연동은 에이전트와 서비스 사이에서 직접 일어나므로 서비스의 웹 UI와 브라우저 경험을 우회한다”(bypassing the service’s web UI / browser experience)는 점으로 짚었다. 화면을 우회하게 되면 세 가지 문제가 수반된다. 서비스 제공자가 심혈을 기울여 구축한 프런트엔드 UI가 완전히 무력화되고, 인증과 상태 관리를 별도로 구축해야 하며, 개발자가 전용 백엔드 서버를 신설해야 한다.

이커머스의 장바구니 기능에 대입해 보면 차이가 더욱 극명해진다. 백엔드 연동 방식에서 쇼핑몰은 에이전트 전용 통신 창구를 개설하고 API 키를 발급·관리해야 한다. 반면 WebMCP 방식에서는 사용자가 이미 로그인해 있는 브라우저 탭 안에서 장바구니 함수가 곧바로 호출된다. 로그인 상태를 증명하는 보안 쿠키와 세션이 해당 브라우저 컨텍스트에 이미 존재하므로, 사용자 자격증명을 별도 서버에 복제할 위험과 부담이 사라진다.

규격 설명서가 명확한 경계선으로 그어 둔 대목도 주목할 만하다. 사람의 감독 없이 독자 판단으로 행동하는 완전 자율 에이전트를 겨냥한 규격이 아니라고 선을 그었다. 백엔드 중심 MCP와의 관계 역시 상호 배타적인 대체가 아니라 긴밀한 상호보완 관계로 규정했다.

정적 llms.txt의 한계와 능동형 호출 인터페이스의 태동

기계가 읽는 웹의 1세대는 정적 파일 기반이었다. 사이트가 콘텐츠 요약을 정리한 정적 텍스트 문서를 호스팅해 두고, AI 에이전트나 크롤러가 찾아와 읽어가기를 기다리는 수동적 방식이다. 대표적인 사례가 작년부터 확산된 ‘llms.txt’ 파일이다.

문서 구조는 매우 단순하다. 최상단에 사이트 이름 한 줄, 그 아래 다루는 영역에 대한 요약 한 문단, 그다음 기사 제목과 URL 주소를 순차적으로 나열하는 형태다. 일반 사용자도 브라우저에서 손쉽게 열람할 수 있는 일반 텍스트 파일이다.

그러나 실증적 데이터가 보여준 성적표는 냉혹했다. 글로벌 SEO 분석 기업 에이치레프스(Ahrefs)가 13만7210개 도메인의 웹 서버 로그를 정밀 분석한 결과, 2026년 5월 기준 트래픽이 발생한 도메인 중 llms.txt를 구축한 사이트는 28%에 달했으나 그중 97%는 한 달간 단 1건의 요청도 받지 못했다. 존재하지 않는 llms.txt를 AI 봇이 탐색하려 시도한 사례는 0건이었다. 연구진은 AI 검색 봇이 애초에 해당 파일을 탐색조차 하지 않는다고 결론지었다.

구글 검색 센터(Google Search Central) 공식 문서 역시 7월 개정 가이드라인을 통해 동일한 맥락을 짚었다. “구글 검색과 그 생성형 AI 기능에 노출되려고 기계 판독 파일이나 AI용 텍스트 파일, 마크업, 마크다운을 새로 만들 필요는 없다”(You don’t need to create new machine readable files, AI text files, markup, or Markdown to appear in Google Search (including its generative AI capabilities))고 명시했다.

WebMCP는 이 패러다임을 정반대로 전환했다. 정적 텍스트를 나열해 두고 읽어가기를 기다리는 대신, 브라우저가 직접 실행할 수 있는 실행형 인터페이스를 능동적으로 제공하는 방식이다.

“기계가 읽는 웹의 1세대가 내용을 정리해 두고 AI가 찾아오길 기다리는 우편함이었다면, WebMCP는 브라우저 안에서 에이전트가 직접 누를 수 있는 초인종을 달아 주는 패러다임의 전환이다.”

정확도·개발비용·통제권… 3대 도입 효용과 ‘앱 탈중개’ 방어

첫 번째 도입 효용은 실행의 ‘정확도’다. 지금까지 AI 에이전트가 웹을 제어하는 주된 방식은 화면 픽셀이나 DOM 트리를 시각적으로 인식해 마우스 클릭과 키보드 입력을 흉내 내는 화면 조작(액추에이션, actuation)이었다. 크롬 문서는 구조화된 툴 호출이 “화면 조작 방식보다 현저히 신뢰할 수 있다”(more reliable than actuation)고 설명하며, 액추에이션 방식은 실행 단계가 파편화되어 늘어날 뿐 아니라 각 단계가 모델의 자의적 해석에 취약하게 노출된다고 지적했다.

해석에 열려 있다는 것은 현실에서 빈번한 오류를 낳는다. 웹사이트 업데이트로 버튼 문구가 ‘담기’에서 ‘추가’로 바뀌거나, 예상치 못한 쿠키 수락 팝업이 화면을 가려 클릭이 빗나가거나, 날짜 입력란의 자릿수 형식이 달라져 검색이 수포로 돌아가는 상황이다. 항공권 조회를 툴로 규격화해 두면 이러한 불안정성이 원천 제거된다. 에이전트는 입력란 좌표를 찾아 헤매는 대신, 출발지와 도착지, 탑승일을 스키마에 정의된 형식 그대로 채워 단일 함수에 전달한다. 10번의 불안정한 마우스 클릭이 단 1번의 확정적인 함수 호출로 압축된다.

두 번째는 ‘개발 부담의 최소화’다. AI 에이전트 지원을 위해 별도 백엔드 인프라를 신축하거나 복잡한 프록시 서버를 증설할 필요 없이, 웹사이트에 기구현된 자바스크립트 함수에 표준 이름과 스키마 설명만 결합하면 된다. API 인증 키를 별도 발급하고 접근 권한을 관리하는 운영 오버헤드 역시 대폭 축소된다.

세 번째는 웹 서비스 제공자의 ‘통제권 보존’이다. 규격 설명서는 사용자가 작업을 AI에 위임하면서도 웹페이지에 대한 가시성과 실행 이력, 세부 통제권을 온전히 유지하는 균형점을 핵심 목표로 제시했다. AI 에이전트가 서비스의 프런트엔드를 완전히 집어삼키는 것이 아니라, 기존 프런트엔드가 에이전트 인터페이스를 수용하여 조화롭게 공존하는 구도다. 설명서는 이를 플랫폼의 가치가 증발하는 ‘앱 탈중개(Disintermediation)’를 방어하는 중요한 설계라고 규정했다. 크롬 문서 역시 구조화된 폼 입력이나 사람 중심 인터페이스에서 에이전트가 일부 절차만 지원하는 하이브리드 워크플로우, 그리고 개발자가 화면을 일일이 조작하지 않고 기능을 직접 호출해 검증하는 디버깅 용도를 대표 사례로 꼽았다.

실제 워크플로우 실증… 단순 조회에서 고위험 결제·설치까지

추상적인 설명만으로는 구체적인 쓰임새를 체감하기 어렵다. 대만 국립양밍자오퉁대(National Yang Ming Chiao Tung University) 연구진이 발표한 선행 연구 논문에서 실험에 활용한 4대 핵심 과제는 이 기술의 실제 구동 양상을 명확히 보여준다.

단일 툴이 작업 전체를 마법처럼 일괄 처리하는 구조가 아니다. 검색, 데이터 조회, 저장, 결제처럼 잘게 분할된 개별 함수들을 에이전트가 논리적 맥락에 맞춰 순차적으로 호출한다. 호출 순서가 꼬이면 전체 작업 흐름이 파탄 나므로, 연구진은 정해진 시퀀스를 오차 없이 준수했는가를 과제 완수의 핵심 판정 기준으로 삼았다.

첫 번째 과제는 AI 안전 관련 문서를 검색해 가장 부합하는 결과를 지식베이스에 적재하는 작업이다. 두 번째 과제에서 에이전트는 주간 매출 데이터를 질의해 요약 보고서를 작성한 뒤 경영진에 이메일로 발송한다. 이어 장바구니를 점검해 할인 쿠폰을 적용하고 등록된 결제 수단으로 주문을 완결하는 세 번째 과제, 그리고 시스템에 탑재된 GPU 드라이버 버전을 조회해 최신 패키지를 내려받아 설치를 실행하는 네 번째 과제로 이어진다.

네 가지 과제를 차례로 대조해 보면 작업에 내재된 위험도의 계단이 명확히 드러난다. 단순 기사 검색·저장과 실제 결제 승인, 그리고 로컬 실행 파일 구동은 사후 되돌림(Rollback)의 난이도와 잠재적 피해 규모에서 완전히 다른 차원의 무게를 갖는다.

표준 생태계 현주소… 오리진 트라이얼과 브라우저별 로드맵

현재의 표준화 단계를 명확히 짚고 넘어갈 필요가 있다. WebMCP는 W3C 웹 머신러닝 커뮤니티 그룹(WebML CG)이 주도하는 제안 초안(Community Draft)이며, 규격 원문에도 “W3C 공식 표준이 아니며 정식 표준 트랙에 등재된 상태도 아니다”(It is not a W3C Standard nor is it on the W3C Standards Track)는 조항이 명시되어 있다. 2026년 9월 14일자 초안의 공식 편집자는 마이크로소프트(Microsoft)의 브랜던 월더먼과 구글의 쿠샬 사가르, 도미닉 파롤리노 연구원이다.

주요 웹 브라우저 진영의 행보는 뚜렷하게 갈린다. 구글 크롬은 버전 149부터 선별적 테스트 기간인 ‘오리진 트라이얼(Origin Trial)’을 공식 개시했다. 정식 배포 전 단계로, 참여를 신청한 도메인에 한해 기능을 선별 활성화해 주는 시험 운영 방식이다.

크롬 플랫폼 상태(Chrome Platform Status) 공식 페이지는 데스크톱과 안드로이드, 웹뷰 전 영역에서 149버전에 시작해 156버전에서 종료되는 로드맵을 공표했다. 기능 구동을 위한 엄격한 보안 전제 조건도 붙는다. 오리진 격리(Origin-Isolation)가 적용된 보안 문서에서만 구동되며, document.domain을 조작하는 페이지에서는 API가 강제 차단된다. 툴의 노출 범위 역시 웹 권한 정책(Permissions Policy)으로 엄밀히 통제되어, 동일 오리진이 기본값이며 타 오리진 기반 iframe 임베드는 원천 차단된다.

발견성의 한계… “해당 탭이 열려 있어야 에이전트가 본다”

실무 관점에서 WebMCP 도입을 검토한다면 이 제약 사항을 가장 면밀히 들여다보아야 한다. 크롬 개발 문서는 아키텍처의 한계 항목에 ‘툴 발견성(Discovery)’ 문제를 적시하며, “클라이언트와 브라우저는 호출 가능한 툴이 존재하는지 파악하기 위해 반드시 해당 사이트를 직접 방문해야 한다”(Clients and browsers must visit a site directly to know if it has callable tools)고 강조했다. 에이전트 프롬프트에 사이트 도메인만 입력하고 검색해 달라고 요청하는 방식으로는 툴에 도달할 수 없다. 사용자가 해당 웹사이트를 브라우저 탭에 능동적으로 열어 둔 상태에서만 에이전트가 툴 목록을 인식할 수 있다.

현재 시점에서 웹 개발자가 등록된 툴을 직접 호출해 볼 수 있는 유일한 통로는 크롬이 배포한 시험용 확장 프로그램이다. 크롬 문서는 이 확장의 프롬프트가 특정 경량 모델로 라우팅되며 향후 크롬에 탑재될 상용 제미나이(Gemini) 기능과는 무관하다고 설명했다. 브라우저 엔진에 깊숙이 통합된 네이티브 에이전트가 웹페이지 툴을 자율 호출하는 시나리오는 아직 정식 상용화 전 단계에 머물러 있다. 따라서 지금 사이트에 WebMCP 코드를 삽입하더라도 오늘 당장 일반 방문자가 체감할 수 있는 사용자 경험은 없다. 새로운 가전제품이 출시되기 전에 벽면에 전용 규격의 전기 콘센트를 선제 매립하는 사전 배선 공사에 가깝다.

선제 도입의 실제 작동 구조와 체감 시점

실제 웹 서비스에 WebMCP를 선제 적용하면 어떤 구조로 동작하는지 구현 사례를 살펴보자. 시험 기간에 맞춰 사이트에 3개의 툴을 등록할 수 있다. 콘텐츠를 검색하는 search_articles, 단일 기사를 조회하는 get_article, 최신 발행 목록을 반환하는 get_latest_articles다. 정적 메타데이터 체계도 병행 구축할 수 있다. 기사 요약을 담은 /llms.txt와 본문 발췌를 포함한 /llms-full.txt를 배포 파이프라인에 연결해 두는 방식이다.

작동 메커니즘은 명확하다. 사용자가 해당 사이트를 브라우저 탭에 열어 둔 상태에서 브라우저 에이전트에 특정 주제의 기술 분석을 찾아 달라고 요청하면, 에이전트는 불안정하게 화면을 훑는 대신 search_articles 툴에 키워드를 직접 주입해 함수를 호출한다. 검색 결과 목록이 반환되면 get_article을 순차 실행해 정확한 원문 데이터를 수신한다. 화면 UI 버튼을 몇 번 클릭할지 추론하는 복잡한 액추에이션 단계가 완전히 생략된다.

다만 현시점에서 일반 방문자가 이러한 변화를 즉각 체감하기는 어렵다. 프런트엔드 페이지에는 규격화된 툴이 온전히 배치되어 있으나, 이를 자율적으로 인지하고 방아쇠를 당겨 줄 브라우저 내장 네이티브 에이전트가 정식 기능으로 배포되지 않았기 때문이다.

미결된 핵심 쟁점… 툴 소유권과 악의적 스크립트 방어

표준 규격 자체가 여전히 활발한 개정 과정에 놓여 있다는 점도 고려해야 한다. 툴 등록 인터페이스가 위치하는 최상위 경로 자체가 최근 전면 변경됐다. 실제로 공식 풀 리퀘스트(PR #184)를 통해 5월 27일 modelContext 접근자가 Document 객체로 전격 이전됐다. 그 직전까지 통용되던 navigator 경로 기반의 해설 문서들이 여전히 웹상에 다수 남아 있는 만큼, 현재 연동 코드를 구현하려면 규격 초안과 최신 크롬 문서를 반드시 직접 대조해야 한다.

공식 깃허브 저장소에 제기된 미결 이슈들도 가볍지 않은 구조적 난제를 안고 있다. 호출을 요청한 에이전트가 신뢰할 수 있는 주체인지 툴이 확인할 수 있는 메커니즘의 부재, 에이전트 신원 상호 검증 절차, 개인정보나 결제 등 민감한 출력을 표시하는 주석 체계, 그리고 스크린 리더 등 웹 접근성 연동 규격이 모두 표준화 합의를 기다리고 있다.

보안 학계의 실증 연구 역시 이러한 취약점을 정조준하고 있다. 앞서 4대 과제를 설계했던 대만 연구진은 타사 광고 스크립트나 서드파티 분석 트래커가 웹페이지에 주입되었을 때, 에이전트가 열람하는 툴 목록을 가로채 바꿔치기하는 공격 기법을 구현했다. 정규 툴이 등록되기 전에 악의적 스크립트가 동일한 함수명을 선점하는 선착순 공격(Front-running)은 실험 대상 3개 프런티어 모델 모두에서 100% 성공률을 보였다. 이에 연구진은 8월 후속 보안 연구 논문을 통해 브라우저가 툴의 도메인 소유권을 엄격히 입증하는 암호학적 방어 모델을 제시했으며, 그 결과 악의적 스크립트의 툴 덮어쓰기 및 무단 삭제 공격 성공률은 20건 중 20건(100%)에서 0건으로 완벽히 통제됐다.

물론 두 연구는 크롬 엔진의 정식 네이티브 구현체가 아닌 브라우저 에뮬레이션 환경에서 수행되었으며, 공격자가 이미 대상 웹페이지의 자바스크립트 실행 권한을 탈취했다는 극한 상황을 전제한다. 당장 일반 웹사이트가 해킹 위험에 노출된다는 뜻은 아니다. 하지만 등록된 툴의 실소유주와 호출 권한을 확인하는 신원 보증 규약이 아직 W3C 규격 초안에 부재하다는 점은 분명한 사실이다. 연구진 역시 규격이 고정 표준으로 굳어지기 전에 툴 소유권 검증 기제를 표준안에 반드시 반영해야 한다고 권고했다.

크롬의 오리진 트라이얼은 156버전까지 시험 일정이 잡혀 있다. 규격이 정식 웹 표준 트랙에 안착하고 보안·권한 검증 프레임워크가 무르익기까지, 웹 브라우징과 자율 AI 에이전트의 새로운 접점은 이제 막 첫 번째 공개 시험대에 올라섰다.