WebMCP, 클릭 대신 도구를 받는 브라우저 에이전트

AI 요약

• 무슨 일: Chrome이 WebMCP 문서를 공개하고, 웹페이지가 에이전트용 구조화 도구를 노출하는 방식을 제안했습니다.
  • 로컬 개발은 Chrome flag로 가능하고, Chrome 149 origin trial이 예고됐습니다.
• 의미: 브라우저 에이전트가 버튼을 추론해 클릭하는 대신, 사이트가 선언한 tool과 schema를 호출할 수 있습니다.
• 주의점: 아직 표준 제안 단계이며, 열린 탭과 사용자 가시 UI를 전제로 하므로 headless MCP 서버의 대체재는 아닙니다.

Chrome 팀이 공개한 WebMCP 문서는 브라우저 에이전트 경쟁에서 조용하지만 중요한 방향 전환을 보여줍니다. 핵심은 단순합니다. 웹사이트가 더 이상 AI 에이전트에게 "여기 버튼이 있으니 알아서 보고 눌러 보라"고만 말하지 않고, "이 페이지에는 checkout, filter_results, submit_application 같은 도구가 있고, 입력과 출력은 이 schema를 따른다"고 선언하는 방식입니다.

이 변화가 흥미로운 이유는 WebMCP가 MCP의 유행어를 웹으로 가져왔기 때문만은 아닙니다. 지금 AI 에이전트가 웹을 쓰는 방식의 병목을 정확히 찌르기 때문입니다. 브라우저 에이전트는 화면을 보고, DOM을 읽고, 버튼과 입력창의 의미를 추론하고, 사람처럼 클릭하고 타이핑합니다. 이 과정을 Chrome 문서는 actuation이라고 부릅니다. 사람이 쓰도록 만든 UI를 그대로 쓰기 때문에 범용성이 있지만, 단계가 많고 각 단계마다 모델의 해석이 개입됩니다. 결제, 예약, 고객 지원, 관리자 설정처럼 상태가 많고 실수가 비싼 화면에서는 이 방식의 불안정성이 곧 제품 리스크가 됩니다.

WebMCP는 이 병목을 "더 똑똑한 화면 인식"이 아니라 "웹앱이 직접 도구 표면을 제공하는 방식"으로 풀어보려는 제안입니다. 웹페이지가 JavaScript 함수와 HTML 폼 주석을 통해 에이전트가 호출 가능한 기능을 등록하고, 브라우저 또는 브라우저 안의 에이전트가 이를 발견해 호출합니다. Google I/O 2026 개발자 키노트 정리도 WebMCP를 브라우저 기반 AI 에이전트가 더 빠르고, 신뢰성 있고, 정밀하게 작업하도록 돕는 structured tools 제안으로 설명했습니다.

WebMCP가 바꾸려는 문제

기존 브라우저 에이전트의 기본 동작은 "사람의 UI를 흉내 내기"에 가깝습니다. 예를 들어 여행 예약 사이트에서 사용자가 "다음 달 금요일 저녁에 도착하고, 토요일 오후에 돌아오는 비행편을 찾아줘"라고 말하면 에이전트는 날짜 선택기를 열고, 필드를 채우고, 필터를 누르고, 결과를 읽어야 합니다. 날짜 선택기가 복잡하거나, 접근성 이름이 부족하거나, 중간에 팝업이 뜨면 실패율은 올라갑니다.

WebMCP의 발상은 이렇습니다. 사이트가 이미 내부적으로 searchFlights, pickDateRange, applyFilters 같은 기능을 갖고 있다면, 에이전트가 UI를 돌아다니며 그 기능을 추론할 필요가 없습니다. 웹페이지가 그 기능을 도구로 등록하고, JSON Schema로 입력과 출력의 모양을 설명하면 됩니다. 사용자는 여전히 같은 웹페이지를 보고 있고, 도구 호출 결과도 앱이 관리하는 UI 안에서 드러납니다.

여기서 중요한 표현은 "사용자가 보는 화면 안에서"입니다. WebMCP explainer는 이 제안의 목표를 완전 자율 에이전트가 사이트를 몰래 조작하게 하는 것으로 두지 않습니다. 오히려 human-in-the-loop 워크플로가 중심입니다. 사용자가 페이지를 보고 있고, 에이전트가 일부 반복 작업을 맡으며, 앱은 기존 UI와 상태를 유지합니다. 사용자가 확인해야 하는 결제나 예약 같은 민감한 행동에는 확인 dialog를 포함할 수 있습니다.

웹페이지가 MCP 서버처럼 보이는 순간

WebMCP explainer는 웹페이지를 "백엔드가 아니라 client-side script로 도구를 구현하는 MCP 서버"에 비유합니다. 이 문장이 이번 뉴스의 핵심입니다. MCP가 도구 서버를 통해 모델 바깥의 기능을 연결했다면, WebMCP는 웹페이지 자체가 에이전트에게 도구를 제공하게 만듭니다.

이 구조는 백엔드 MCP와 닮았지만 같은 물건은 아닙니다. 백엔드 MCP는 에이전트 플랫폼이 서버와 직접 통신합니다. UI가 필요하면 별도로 붙여야 하고, 인증과 세션 상태도 서버 통합에 맞게 설계해야 합니다. WebMCP에서는 열린 브라우저 탭이 중심입니다. 사용자의 로그인 상태, 현재 선택된 상품, 장바구니, 입력 중인 폼, 앱의 클라이언트 상태가 그대로 남아 있습니다.

이 차이는 개발자 경험에도 영향을 줍니다. 웹 앱 팀은 이미 프론트엔드에 많은 비즈니스 로직과 UI 상태 관리를 갖고 있습니다. 그 기능을 별도 Python 또는 Node MCP 서버로 다시 표현하는 일은 단순한 포팅이 아닙니다. 인증, 권한, 에러, rate limit, 사용자 확인, UI 상태 동기화까지 다시 생각해야 합니다. WebMCP가 노리는 틈은 바로 여기입니다. 웹 앱이 기존 JavaScript와 HTML 구조를 재사용해 에이전트 경로를 점진적으로 추가할 수 있다면, "AI 에이전트 지원"이 별도 플랫폼 통합 프로젝트가 아니라 웹 기능 개선 작업에 가까워질 수 있습니다.

Chrome 문서가 공개한 구체적 모양

Chrome 문서 기준으로 WebMCP는 세 가지 축을 지원합니다. 첫째는 Discovery입니다. 페이지가 checkout이나 filter_results 같은 도구를 등록하면 에이전트가 현재 페이지에서 쓸 수 있는 기능을 발견할 수 있습니다. 둘째는 JSON Schema입니다. 입력과 출력의 모양을 명시해 모델이 필드 의미를 잘못 추론하거나 임의 값을 꾸며내는 위험을 줄입니다. 셋째는 State입니다. 현재 페이지의 실시간 상태를 공유해, 에이전트가 지금 어떤 리소스와 액션을 사용할 수 있는지 알 수 있게 합니다.

API 형태는 두 갈래입니다. Imperative API는 JavaScript로 도구를 정의합니다. 복잡한 앱 상태, 비동기 처리, 커스텀 검증이 필요한 기능에 어울립니다. Declarative API는 표준 HTML 폼에 주석을 더해 도구를 만드는 방향입니다. 폼 중심의 업무, 신청서, 예약, 고객 지원 흐름처럼 이미 구조화된 입력이 있는 화면에서는 이 방식이 더 낮은 진입 장벽을 줄 수 있습니다.

권한 모델도 이미 문서에 들어가 있습니다. WebMCP 도구는 tools Permissions Policy로 제어됩니다. 기본값은 self라서 top-level과 same-origin context에서 도구 등록을 허용하고, cross-origin iframe에서는 비활성화됩니다. iframe에서 허용하려면 allow="tools"를 명시해야 합니다. 아직 초안 단계의 기능이지만, 최소한 Chrome 팀이 권한 경계를 도구 설계의 중심 문제로 보고 있다는 신호입니다.

현재 사용할 수 있는 상태도 명확합니다. Chrome 문서는 WebMCP가 로컬 개발용 Chrome flag로 제공되며, Chrome 149에서 origin trial로 제공될 예정이라고 설명합니다. 즉 오늘 당장 모든 사용자에게 배포되는 표준 기능은 아닙니다. 실험하고 피드백을 줄 수 있는 단계입니다. 문서에는 inspector extension도 소개되어 있습니다. 이 확장은 페이지에 등록된 navigator.modelContext API 도구를 확인하고, JSON Schema를 검증하고, 자연어 prompt가 적절한 도구 호출로 이어지는지 실험하게 해줍니다.

왜 Google은 지금 이 층을 밀까

이번 발표는 Google I/O 2026의 더 큰 흐름 안에 있습니다. Google은 Antigravity 2.0, Managed Agents in the Gemini API, Google AI Studio 통합, Chrome DevTools for agents, Modern Web Guidance, Android CLI와 skills를 한꺼번에 이야기했습니다. 모두 같은 방향을 가리킵니다. 모델이 더 똑똑해지는 것만으로는 에이전트 제품이 안정적으로 굴러가지 않습니다. 에이전트가 실행할 수 있는 환경, 도구, 권한, 평가, UI 검증, 개발자 가이드가 함께 필요합니다.

WebMCP는 그중에서도 웹 플랫폼 쪽의 응답입니다. 브라우저가 에이전트 실행 표면이 될수록, 웹사이트는 두 가지 선택지 앞에 놓입니다. 하나는 에이전트가 화면을 해석하도록 방치하는 것입니다. 다른 하나는 사이트가 직접 에이전트에게 의미 있는 동작 단위를 제공합니다. Chrome 팀은 후자를 표준화 가능한 웹 API로 만들려는 쪽에 베팅하고 있습니다.

이 접근은 Google에게도 전략적입니다. Gemini in Chrome 같은 브라우저 내 에이전트가 웹을 더 잘 다루려면, 개별 사이트별 스크래핑과 클릭 자동화만으로는 충분하지 않습니다. 웹 개발자가 도구를 등록하고, 브라우저가 이를 중립적인 방식으로 노출하며, 에이전트가 schema에 맞춰 호출하는 생태계가 필요합니다. Chrome이 WebMCP를 "어떤 agentic capabilities를 가진 브라우저든 구현하고 혜택을 볼 수 있는 API"라고 표현한 것도 이 때문입니다.

개발자에게 생기는 새 질문

WebMCP가 현실화되면 웹 앱 개발자는 새로운 API 표면을 설계해야 합니다. 지금까지 API 설계는 주로 백엔드 REST, GraphQL, 내부 RPC, 공개 SDK의 문제였습니다. WebMCP는 사용자 UI 안에 존재하는 에이전트용 API입니다. 따라서 함수 이름을 예쁘게 짓는 문제보다 더 복잡합니다.

첫째, 어떤 작업을 도구로 만들지 결정해야 합니다. 모든 버튼을 도구로 바꾸는 것은 좋은 설계가 아닙니다. 에이전트가 자주 실패하는 복잡한 폼, 반복 입력, 필터링, 진단, 예약, 지원 흐름처럼 구조화 이득이 큰 작업부터 노출하는 편이 자연스럽습니다.

둘째, schema가 제품 언어가 됩니다. 필드 이름, 설명, enum, 기본값, 오류 메시지가 모델의 행동을 직접 좌우합니다. 사람에게 보이지 않던 내부 함수명이 에이전트에게는 제품 카피가 되는 셈입니다. 좋은 WebMCP 도구는 타입만 맞는 함수가 아니라, 에이전트가 안전하게 판단할 수 있는 설명과 제한을 갖춘 기능이어야 합니다.

셋째, 사용자 확인과 되돌리기 경험이 중요해집니다. WebMCP explainer는 사용자가 에이전트와 함께 작업하는 협업 시나리오를 강조합니다. 에이전트가 디자인을 수정하거나, 여행 조건을 바꾸거나, 지원 양식을 채우는 작업은 사용자가 검토하고 취소할 수 있어야 합니다. 도구 호출은 성공했지만 사용자가 의도하지 않은 상태가 되는 경우를 제품이 흡수해야 합니다.

넷째, 보안과 권한 경계가 더 세밀해집니다. allow="tools" 같은 Permissions Policy는 시작점일 뿐입니다. 실제 제품에서는 어떤 사용자가 어떤 도구를 호출할 수 있는지, agent가 호출한 액션을 감사 로그에 어떻게 남길지, 민감한 도구는 어떤 confirmation을 요구할지, cross-origin embed에서 도구를 허용할지 결정해야 합니다. 특히 결제, 개인정보 수정, 계정 삭제, 권한 변경 같은 작업은 WebMCP가 있다고 해서 자동으로 안전해지지 않습니다.

MCP를 대체하는가, 보완하는가

이름 때문에 WebMCP를 "MCP의 웹 버전"으로만 읽기 쉽지만, 현재 문서를 보면 대체재라기보다 보완층에 가깝습니다. WebMCP explainer의 non-goals는 headless browsing, 완전 자율 에이전트 워크플로, 기존 backend integration 대체를 명시적으로 제외합니다. 즉 서버 대 서버 도구 호출이 필요한 에이전트, 장시간 백그라운드 작업, 사람이 보지 않는 자동화, 여러 서비스의 데이터 파이프라인에는 여전히 백엔드 MCP나 다른 프로토콜이 더 적합합니다.

반대로 WebMCP가 강한 영역은 "웹 UI와 상태가 핵심인 작업"입니다. 사용자가 쇼핑몰 페이지를 보고 있고, 에이전트가 필터를 정리해주며, 사용자가 최종 결정을 내리는 장면을 떠올리면 됩니다. 고객 지원 콘솔에서 에이전트가 적절한 양식을 열고 일부 필드를 채우되, 상담원이 제출 전에 확인하는 장면도 비슷합니다. 웹 앱이 이미 갖고 있는 사용자 경험을 버리지 않고, 그 안에 에이전트가 더 안정적으로 들어올 수 있게 하는 것입니다.

이 관점에서 WebMCP는 웹의 "에이전트 접근성" 문제로도 볼 수 있습니다. 스크린 리더를 위해 의미 있는 구조와 접근성 정보를 제공하듯, 에이전트를 위해 고수준 행동 단위와 schema를 제공하는 방향입니다. 물론 에이전트와 보조기술을 같은 것으로 볼 수는 없습니다. 그러나 복잡한 시각 UI를 고수준 의미로 번역해야 한다는 점에서는 문제가 겹칩니다.

아직 열린 표준화 숙제

가장 큰 변수는 채택입니다. Chrome 문서와 GitHub explainer는 분명한 1차 소스지만, WebMCP는 아직 완성된 웹 표준이 아닙니다. Chrome flag와 origin trial은 실험의 시작이지, 모든 브라우저와 모든 에이전트가 따라오겠다는 약속이 아닙니다. Safari, Firefox, 독립 브라우저, 확장 기반 에이전트, OpenAI나 Anthropic 같은 외부 AI 플랫폼이 어떤 방식으로 받아들일지는 지켜봐야 합니다.

두 번째 변수는 도구 품질입니다. WebMCP가 성공하려면 웹 개발자가 "에이전트가 실제로 쓸 수 있는 도구"를 만들어야 합니다. schema가 부실하거나, 오류 메시지가 불명확하거나, UI 상태와 tool state가 어긋나면 클릭 자동화보다 나을 것이 없습니다. 표준이 생겨도 제품별 구현 품질이 낮으면 에이전트는 다시 화면을 보고 추론하는 방식으로 돌아갈 수 있습니다.

세 번째 변수는 사용자 신뢰입니다. 도구 호출이 UI 안에서 보인다는 점은 장점이지만, 사용자는 여전히 에이전트가 무엇을 했는지 이해해야 합니다. "에이전트가 필터를 적용했습니다"와 "에이전트가 계정 설정을 변경했습니다"는 전혀 다른 무게를 갖습니다. WebMCP 도구 설계는 audit log, undo, confirmation, permission prompt와 함께 논의돼야 합니다.

이번 뉴스의 실제 의미

WebMCP는 당장 모든 웹 앱이 넣어야 하는 production 기능은 아닙니다. 그러나 AI 에이전트 시대의 웹 개발이 어디로 갈지 보여주는 신호로는 충분히 큽니다. 지금까지 웹사이트는 사람과 검색 크롤러를 주된 소비자로 생각했습니다. 앞으로는 브라우저 에이전트도 중요한 소비자가 될 수 있습니다. 다만 그 소비자는 페이지의 시각적 모양만 보는 것이 아니라, 사이트가 제공하는 구조화된 행동 단위를 기대합니다.

그래서 이번 발표의 핵심은 "Chrome이 새 API를 하나 냈다"보다 "웹페이지가 에이전트에게 무엇을 약속해야 하는가"에 있습니다. 클릭 가능한 버튼이 아니라 호출 가능한 도구, 자유로운 DOM 해석이 아니라 schema가 있는 입력, 몰래 실행되는 백엔드 자동화가 아니라 사용자가 보는 탭 안의 협업 흐름입니다.

MCP가 모델과 서버 도구 사이의 접속층을 만들었다면, WebMCP는 브라우저 탭과 웹 앱이 에이전트에게 스스로를 설명하는 접속층을 만들려 합니다. 아직은 제안이고, Chrome 중심의 실험이며, 보안과 UX 숙제도 많습니다. 하지만 에이전트가 웹을 "보는" 단계에서 웹이 에이전트에게 "말하는" 단계로 넘어가는 방향은 분명해 보입니다. 그 전환이 실제 표준이 될지는 Chrome 149 origin trial과 개발자 피드백이 첫 시험대가 될 것입니다.