← Back to list2026-08-22

클릭하던 AI가 함수를 호출합니다: 구글 WebMCP가 만드는 에이전트 웹

WebMCPGoogle ChromeAgentic AIMCPComputer Use브라우저 에이전트웹 표준

지금의 웹 에이전트는 사람처럼 화면을 읽고 움직입니다. 스크린샷이나 접근성 트리에서 버튼을 찾고, 클릭하고, 입력란에 문자를 넣고, 다음 화면이 제대로 열렸는지 다시 확인합니다. 사람을 위해 만든 인터페이스를 기계가 역으로 해석하는 방식입니다. 어느 사이트에서나 시도할 수 있다는 장점이 있지만 버튼 위치, 문구, 화면 상태가 조금만 달라져도 엉뚱한 행동을 할 수 있습니다.

구글이 공개한 WebMCP는 이 관계를 뒤집습니다. 에이전트가 화면만 보고 행동의 뜻을 추측하는 대신, 웹사이트가 상품 검색, 예약 신청, 장바구니 추가, 진단 실행 같은 기능을 이름·설명·입력 형식·실행 함수로 직접 선언합니다. 에이전트는 구조화된 인수를 보내고, 현재 탭 안의 자바스크립트가 그 일을 실행합니다.

핵심은 웹사이트에 기계가 읽을 수 있는 행동 계층을 하나 더 만드는 것입니다. HTML이 문서 구조를, API가 서버 기능을 기계가 읽게 했다면, WebMCP는 로그인된 현재 웹페이지에서 사용자가 할 수 있는 일을 에이전트가 호출할 수 있는 계약으로 바꾸려 합니다.

다만 지금은 완성된 웹 표준이 아닙니다. W3C Web Machine Learning Community Group에서 논의하는 제안이며, 2026년 8월 기준 Chrome과 Edge는 오리진 트라이얼, Brave는 실험 지원 단계입니다. Mozilla는 중립 입장이고 WebKit은 반대 입장을 표시했습니다. 따라서 WebMCP는 이미 방향성이 분명한 기술이지만, 모든 브라우저가 채택하기로 합의한 표준으로 부르면 안 됩니다.

WebMCP는 웹페이지가 에이전트에게 건네는 행동 계약입니다

WebMCP의 실행 흐름은 비교적 단순합니다.

웹사이트가 현재 페이지에서 허용할 기능을 도구로 등록합니다.
브라우저 안의 에이전트가 도구 이름, 설명과 JSON 스키마를 발견합니다.
모델이 사용자 요청에 맞는 도구와 인수를 선택합니다.
브라우저가 페이지의 자바스크립트 실행 함수를 호출합니다.
페이지가 구조화된 결과를 돌려주고, 필요한 경우 사용자에게 화면과 확인 절차를 보여줍니다.

예를 들어 쇼핑몰은 다음과 같은 도구를 현재 탭에 등록할 수 있습니다. 아래 코드는 API의 성격을 보여주기 위해 단순화한 예시입니다.

document.modelContext.registerTool({
  name: "add_to_cart",
  description: "현재 상품과 선택한 수량을 장바구니에 추가합니다.",
  inputSchema: {
    type: "object",
    properties: {
      quantity: { type: "integer", minimum: 1, maximum: 10 }
    },
    required: ["quantity"]
  },
  async execute({ quantity }) {
    return addCurrentProductToCart(quantity);
  }
});

사용자가 "이 상품 두 개를 장바구니에 넣어줘"라고 말하면 에이전트는 화면에서 장바구니 버튼의 좌표를 찾지 않아도 됩니다. add_to_cart를 고르고 { "quantity": 2 }를 전달합니다. 실제 재고 확인, 옵션 처리, 장바구니 상태 갱신은 사이트가 이미 쓰고 있는 애플리케이션 로직이 담당합니다.

WebMCP는 모델이 사이트 코드를 대신 쓰는 기술이 아닙니다. 모델은 도구와 인수를 선택하고, 사이트가 소유한 코드가 현재 브라우저 상태에서 실행됩니다.

WebMCP는 같은 목적을 두 방식으로 구현합니다.

명령형 API: document.modelContext.registerTool()로 자바스크립트 함수를 등록합니다. 복잡한 상태 관리, 탐색, 진단, 사용자 정의 위젯처럼 단순한 HTML 양식으로 표현하기 어려운 기능에 맞습니다.
선언형 API: 기존 <form>에 toolname, tooldescription 같은 속성을 붙입니다. 양식 필드가 도구의 입력 스키마가 되고, 브라우저가 값을 채운 뒤 자동 제출하거나 사용자의 제출 클릭을 기다릴 수 있습니다.

선언형 API는 특히 중요합니다. 에이전트 전용 백엔드를 새로 만들지 않아도 사람이 보던 양식과 검증 로직을 재사용할 수 있기 때문입니다. 에이전트가 채운 값은 화면에 나타나고 사용자가 최종 제출 전에 확인할 수도 있습니다. WebMCP가 인간 UI를 없애는 기술이 아니라 인간과 에이전트가 같은 페이지 상태를 공유하는 기술이라는 뜻입니다.

더 큰 흐름은 웹의 에이전트용 행동 계층입니다

WebMCP는 독립적으로 등장한 기술이 아닙니다. LLM의 도구 호출, MCP, 브라우저 Computer Use, 에이전트 하네스가 빠르게 결합하면서 생긴 다음 단계입니다.

초기 LLM은 답변을 생성했습니다. 도구 호출이 추가되면서 모델이 검색, 계산, 데이터베이스 조회와 업무 함수를 선택할 수 있게 됐습니다. MCP는 이 도구와 데이터를 여러 에이전트가 공통 방식으로 연결하는 서버 측 규약을 만들었습니다. Computer Use는 별도 API가 없는 소프트웨어도 화면을 통해 조작하게 했습니다. 이제 WebMCP는 웹사이트가 자신의 프런트엔드 행동을 표준 도구로 선언하는 계층을 제안합니다.

이 변화는 모델 능력보다 시스템 인터페이스가 실제 성공률을 크게 좌우한다는 에이전트 엔지니어링의 흐름과도 맞닿아 있습니다. 강한 모델이 화면을 매번 해석하게 하는 것보다, 중간 정도의 모델이라도 정확한 도구 이름과 입력 형식을 받는 편이 안정적일 수 있습니다. 추론으로 풀던 문제 일부를 계약과 코드로 옮기기 때문입니다.

왼쪽으로 갈수록 기존 사이트에 바로 적용하기 쉽고, 오른쪽으로 갈수록 실행 의미가 명확해집니다. WebMCP는 현재 페이지의 상태와 구조화된 함수 호출 사이를 채웁니다.

이 관점에서 WebMCP는 웹사이트용 robots.txt나 llms.txt와도 다릅니다. 그런 파일은 주로 콘텐츠 접근과 발견을 돕지만 행동을 직접 실행하지 않습니다. 정적 매니페스트만으로는 사용자의 로그인 여부, 현재 장바구니, 선택한 상품, 실시간으로 바뀌는 도구를 반영하기도 어렵습니다. WebMCP 도구는 페이지가 열려 있는 동안 현재 상태에 맞춰 등록되고, 탭을 닫으면 사라집니다.

WebMCP는 MCP의 브라우저판이 아닙니다

이름 때문에 가장 많이 생기는 오해는 WebMCP를 MCP 서버의 자바스크립트 구현으로 보는 것입니다. Chrome의 공식 비교 문서는 WebMCP가 MCP의 확장도 대체재도 아니며, MCP에서 영감을 받은 별도의 브라우저 API라고 명시합니다.

구분	WebMCP	MCP·OpenAPI
실행 위치	사용자가 열어 둔 브라우저 탭	서버·로컬 프로세스·클라우드
수명	페이지가 열려 있는 동안만 존재	서버가 운영되는 동안 지속
상태	현재 DOM, 쿠키, 로그인 세션, 클라이언트 상태 활용	별도 인증과 서버 상태 필요
발견	에이전트가 사이트를 방문한 뒤 도구 확인	에이전트 호스트에 서버·API 등록
UI	사람이 보는 기존 웹페이지와 상태 공유	헤드리스 또는 별도 에이전트 UI
강점	맥락 있는 프런트엔드 업무, 양식, 사용자 확인	백그라운드 작업, 대량 처리, 장기 실행, 데이터 접근
제약	탭 필요, 브라우저 지원 필요, 사이트 구현 필요	UI 문맥과 클라이언트 로직을 별도로 연결해야 함

예를 들어 여행 서비스의 항공편 검색과 결제 로직은 MCP나 일반 API로 제공할 수 있습니다. 반면 사용자가 현재 보고 있는 여정, 선택한 좌석, 로그인 세션을 그대로 유지한 채 양식을 채우고 화면에서 확인하게 하는 마지막 구간은 WebMCP에 맞습니다. 서버의 핵심 업무는 MCP, 현재 탭의 공동 작업은 WebMCP가 맡는 조합입니다.

MCP Apps와도 방향이 반대입니다. MCP Apps는 에이전트 제품 안에 서비스 UI가 들어갑니다. WebMCP에서는 에이전트가 기존 웹사이트 안으로 들어와 사이트의 UI와 규칙을 따릅니다. 누가 주된 공간을 소유하는지가 다릅니다.

유사·대체 기술은 범용성, 신뢰성, 상태 소유권이 다릅니다

WebMCP가 해결하는 문제에는 이미 여러 방법이 있습니다. 어느 하나가 전부를 대체하기보다 업무 성격에 따라 계층을 나누게 될 가능성이 높습니다.

시각 기반 Computer Use

OpenAI Computer Use나 Claude의 Computer Use처럼 모델이 스크린샷을 보고 좌표 기반 클릭과 타이핑을 생성합니다. 기존 사이트가 코드를 바꾸지 않아도 되고, 캔버스·원격 데스크톱·낡은 사내 시스템까지 조작할 수 있다는 것이 가장 큰 장점입니다.

반면 매 단계에서 화면을 캡처하고 해석해야 하므로 지연과 토큰 비용이 늘어납니다. 화면 배치가 바뀌거나 팝업이 뜨면 실패할 수 있고, 실제로 어떤 기능을 실행하는지 모델이 추론해야 합니다. 페이지 안의 악성 지시가 모델의 행동을 바꾸는 프롬프트 인젝션 위험도 큽니다. WebMCP는 사이트가 지원하는 핵심 행동에서 이 추측을 명시적 함수 호출로 치환합니다. 다만 WebMCP 도구가 없는 사이트까지 다루려면 Computer Use는 계속 필요합니다.

DOM·접근성 트리·Playwright·CDP

Playwright MCP는 접근성 스냅샷을 통해 대화형 요소에 참조값을 붙입니다. 스크린샷 좌표보다 텍스트가 간결하고 안정적인 경우가 많고, 자동화 테스트 생태계와도 잘 연결됩니다. Selenium, Playwright, Chrome DevTools Protocol과 브라우저 확장 프로그램의 콘텐츠 스크립트도 같은 계열입니다.

이 방식은 사이트 변경 없이 적용할 수 있지만, 이 버튼은 환불 요청을 제출한다 같은 업무 의미를 구조에서 다시 추론해야 합니다. DOM 변경, 사용자 정의 위젯, 접근성 정보가 부족한 페이지에서 흔들릴 수 있습니다. WebMCP는 셀렉터가 아니라 애플리케이션 로직에 연결되므로 디자인이 바뀌어도 도구 계약을 유지할 수 있습니다.

전용 확장 프로그램과 사이트별 통합

브라우저 확장 프로그램은 특정 사이트에 맞춘 스크립트, 권한, UI를 제공할 수 있습니다. 이미 가능한 기술이고 강한 통제력을 갖지만 사이트별 유지보수와 배포가 필요합니다. 브라우저·에이전트마다 별도 통합을 만들면 연결 비용이 다시 커집니다. WebMCP가 실제 공통 표준이 되면 사이트가 한 번 공개한 도구를 여러 브라우저 에이전트가 사용할 수 있다는 장점이 생깁니다. 바로 이 부분이 아직 표준화 여부에 달려 있습니다.

일반 API·OpenAPI·MCP

서버 API는 결정적 실행, 대량 처리, 백그라운드 작업과 시스템 간 연동에서 가장 강합니다. 에이전트가 사용자의 브라우저를 열어 둘 필요도 없습니다. 하지만 사이트에만 존재하는 클라이언트 상태와 UI 검증 로직을 다시 구현해야 할 수 있고, 로그인과 권한을 별도로 연결해야 합니다. WebMCP는 백엔드 API를 밀어내기보다 서버 API까지 갈 필요가 없는 현재 탭의 마지막 구간을 맡습니다.

A2A와 UCP

Agent2Agent 같은 규약은 에이전트끼리 업무를 위임하고 상태를 교환하는 데 초점이 있습니다. Google의 Universal Commerce Protocol은 상품 탐색부터 결제까지 상거래 도메인의 에이전트 거래를 구조화합니다. 둘 다 웹페이지의 일반 행동을 선언하는 WebMCP와 범위가 다릅니다. A2A는 상대가 다른 에이전트일 때, UCP는 상거래 프로토콜이 필요할 때, WebMCP는 현재 웹 UI에서 사이트 기능을 실행할 때 쓰입니다.

방식	기존 사이트 변경	로그인된 현재 탭	헤드리스 실행	업무 의미의 명시성	대표 역할
시각 Computer Use	불필요	가능	가능	낮음	범용 폴백, 캔버스·레거시 UI
DOM·ARIA 자동화	불필요	가능	가능	중간	테스트, 일반 웹 자동화
확장 프로그램	에이전트 측 구현	가능	제한적	통합 품질에 따라 다름	사이트별 맞춤 자동화
WebMCP	사이트 구현 필요	매우 강함	불가	높음	방문 중인 웹 업무와 공동 확인
MCP·일반 API	서버 구현 필요	별도 연결	매우 강함	높음	백그라운드·대량·장기 업무

따라서 가장 현실적인 아키텍처는 도구 우선, DOM·화면 폴백입니다. 에이전트는 WebMCP 도구가 있으면 이를 사용하고, 지원하지 않는 구간만 접근성 트리나 시각 조작으로 넘깁니다. 핵심 거래는 구조화해 성공률을 높이면서도 웹 전체에 대한 범용성을 잃지 않는 방식입니다.

구글은 Chrome을 에이전트의 실행 환경으로 만들고 있습니다

구글이 WebMCP를 추진하는 직접적인 이유는 공식 문서에 적혀 있습니다. 에이전트의 속도와 안정성을 높이고, 사이트가 자신의 기능을 어떻게 사용하게 할지 통제하며, 기존 브랜드와 인간 중심 UI를 유지하려는 것입니다. WebMCP 공개 설명서는 목표 중 하나로 웹 콘텐츠가 에이전트에 의해 중개에서 배제되는 것을 막는다고 밝힙니다.

이 문장은 전략적으로 중요합니다. 에이전트가 모든 웹사이트를 화면이나 비공식 API로 우회해 결과만 가져가면 사용자는 원래 서비스의 UI, 브랜드, 추천, 부가 기능과 확인 절차를 보지 않을 수 있습니다. 사이트 운영자는 고객 접점과 행동 통제력을 잃고, 에이전트 사업자가 새로운 관문을 차지합니다. WebMCP는 사이트가 에이전트 시대에도 자신의 화면과 업무 로직 안에서 거래가 일어나게 만드는 대응입니다.

구글의 제품 움직임과 연결하면 의도는 더 선명해집니다. 구글은 2025년부터 Gemini in Chrome의 다중 탭 이해와 에이전트 브라우징을 예고했고, 이후 Chrome auto browse로 예약, 양식 작성, 문서 수집, 비용 처리, 구독 관리 같은 다단계 업무를 공개했습니다. 로그인 필요 시 Google Password Manager를 활용하고, 구매·소셜 게시 같은 민감 행동에서는 사용자 확인을 요구하는 구조도 제시했습니다.

WebMCP는 이 제품 전략의 사이트 측 기반입니다. Gemini가 아무리 강해도 전 세계 웹페이지의 화면을 매번 정확하게 조작하는 것은 비싸고 불안정합니다. 사이트가 도구를 제공하면 Chrome의 에이전트는 더 짧은 경로로 행동하고, 사이트는 허용한 함수와 UI 안에 실행을 묶을 수 있습니다.

여기서부터는 공개 사실을 바탕으로 한 해석입니다.

Chrome은 정보 열람 도구에서 행동 실행 환경으로 이동합니다. 브라우저가 페이지를 보여주는 데 그치지 않고 사용자 의도, 로그인 세션, 도구, 권한, 확인을 중재합니다.
구글은 에이전트가 웹을 우회하는 위험과, 에이전트가 새로운 웹 관문이 되는 기회를 동시에 보고 있습니다. WebMCP는 사이트의 통제권을 일부 보존하면서 Chrome을 공통 실행 계층으로 만듭니다.
Gemini의 모델 경쟁력을 배포 우위로 바꿀 수 있습니다. 브라우저 안에서 페이지 문맥, Google 계정, Password Manager, Connected Apps와 결합하면 모델 API만으로는 만들기 어려운 사용자 경험이 됩니다.
표준의 형태가 중요합니다. 여러 브라우저가 채택하면 사이트의 통합 부담이 줄고 에이전트 웹이 빨리 커집니다. Chromium 계열에만 남으면 구글과 마이크로소프트의 플랫폼 영향력은 커질 수 있지만, 개방형 웹 표준이라는 명분과 개발자의 보편적 채택은 약해집니다.

구글의 직접적인 목표는 안정적 에이전트 실행입니다. 전략적으로는 Chrome이 사용자 의도와 웹사이트 행동 사이의 권한·세션·보안 계층을 차지한다는 의미가 큽니다.

웹사이트는 사람용 화면과 에이전트용 계약을 함께 갖게 됩니다

WebMCP가 널리 채택될 경우 가장 큰 변화는 웹사이트가 두 개의 인터페이스를 갖는 것입니다.

사람에게는 화면, 문구, 버튼, 시각적 피드백을 제공합니다.
에이전트에게는 도구 이름, 설명, 입력 스키마, 실행 함수와 구조화된 결과를 제공합니다.

이는 모바일 반응형 디자인이나 접근성 속성처럼 프런트엔드 개발의 새로운 품질 항목이 될 수 있습니다. 모든 버튼을 도구로 복제하는 것이 아니라, 사용자가 이루려는 핵심 목적을 안정적인 행동 단위로 공개해야 합니다. next_button보다 submit_refund_request, click_blue_icon보다 filter_available_rooms가 좋은 계약입니다.

화면 설계는 사라지지 않고 역할이 바뀝니다

에이전트가 메뉴 탐색과 반복 입력을 줄이면 일부 페이지 이동과 클릭은 감소할 수 있습니다. 그렇다고 UI가 없어지지는 않습니다. 사용자가 에이전트의 진행 상태를 이해하고, 입력값을 고치고, 민감한 행동을 승인하고, 결과를 비교하는 공간이 더 중요해집니다. 좋은 에이전트 UI는 조작 패널보다 공동 작업의 상태판과 확인 계층에 가까워집니다.

에이전트 준비도는 새로운 제품 품질이 됩니다

검색엔진 최적화와 비슷한 표현으로 설명하고 싶어질 수 있지만 차이가 있습니다. WebMCP 도구는 에이전트가 사이트를 방문해야 발견할 수 있고, 현재 탭에서만 존재합니다. 전 세계에서 미리 색인되는 검색 문서가 아닙니다. 더 정확한 개념은 Agent Experience, 즉 에이전트 경험 설계입니다.

에이전트가 적절한 도구를 고르는지, 필수 인수를 정확히 채우는지, 여러 도구를 올바른 순서로 호출하는지, 오류 후 복구하는지를 평가해야 합니다. Chrome의 WebMCP 평가 가이드도 일반 자바스크립트 테스트와 별도로 도구 선택·인수·순서·사용자 여정에 대한 확률적 평가를 요구합니다.

사이트의 거래 통제력이 일부 회복됩니다

에이전트가 비공식 화면 자동화로 사이트를 조작하면 운영자는 어떤 경로가 안정적이고 안전한지 알려주기 어렵습니다. WebMCP에서는 읽기 전용 조회, 되돌릴 수 있는 변경, 결제 같은 고위험 행동을 서로 다른 도구로 나누고 설명할 수 있습니다. 에이전트가 수행할 기본 경로를 사이트가 직접 설계하므로 오류와 지원 비용을 줄일 여지가 있습니다.

브라우저의 플랫폼 권력은 커집니다

브라우저는 원래 웹 문서와 하드웨어 권한을 중재했습니다. 카메라, 위치, 알림, 저장소 접근에서 사용자 동의를 받았습니다. 에이전트 시대에는 여기에 누가 어떤 사이트 도구를 발견하는가, 어떤 도구를 호출해도 되는가, 언제 사용자 확인을 강제하는가가 추가됩니다. 이 층을 소유한 브라우저는 에이전트의 배포와 신뢰 정책에서 더 중요한 플랫폼이 됩니다.

보안은 구조화됐지만 해결되지는 않았습니다

함수 호출은 좌표 클릭보다 안정적이지만 자동으로 안전해지는 것은 아닙니다. 오히려 로그인된 브라우저 세션에서 구조화된 고권한 도구를 빠르게 실행할 수 있어 실패의 영향이 커질 수 있습니다.

Chrome의 에이전트 보안 문서는 두 공격 경로를 구분합니다.

악성 도구 정의: 도구 이름이나 설명 안에 숨긴 지시가 에이전트의 판단을 오염시킬 수 있습니다.
오염된 도구 출력: 정상 도구가 외부 콘텐츠를 가져오면서 악성 프롬프트를 결과에 섞을 수 있습니다.

WebMCP에는 도구가 읽기 전용인지, 결과에 신뢰할 수 없는 콘텐츠가 포함되는지를 알리는 readOnlyHint, untrustedContentHint 같은 힌트가 있습니다. 그러나 이름 그대로 힌트입니다. 모델이나 에이전트 하네스가 이를 무시할 가능성을 전제로 해야 합니다.

기술적으로는 오리진 격리, 기본 self인 tools Permissions Policy, 교차 오리진 노출 제한이 적용됩니다. 그래도 사이트가 과도한 개인정보를 입력 스키마에 요구하거나, 에이전트가 여러 오리진 사이에서 정보를 옮기거나, 승인 없이 고위험 작업을 실행하는 문제는 남습니다. WebMCP 공개 문서에서도 사용자 상호작용 요청, 확인, 결과 스키마, 교차 문서 탐색과 스트리밍 등은 계속 논의 중입니다.

실제 서비스에는 API 자체보다 더 넓은 통제가 필요합니다.

조회, 수정, 결제·삭제를 서로 다른 위험 등급으로 나눕니다.
가능한 도구는 최소 권한과 최소 입력으로 설계합니다.
결제, 전송, 공개 게시, 계정 변경에는 독립적인 사용자 확인을 둡니다.
도구 정의와 외부 콘텐츠가 섞인 출력을 모두 신뢰하지 않는 입력으로 검사합니다.
호출한 도구, 인수, 실행 결과, 사용자 승인과 중단을 감사 기록으로 남깁니다.
에이전트가 실패했을 때 사람이 현재 상태를 보고 이어받을 수 있게 합니다.

구글 역시 Chrome 에이전트 보안 아키텍처에서 신뢰할 수 없는 페이지 콘텐츠와 분리된 비평 모델, 오리진 제한, 민감 행동 확인을 강조합니다. 이는 WebMCP 하나로 끝나는 보안이 아니라 브라우저, 모델, 하네스, 사이트가 함께 지켜야 하는 다층 문제라는 방증입니다.

아직은 강한 제안이지 합의된 웹 표준이 아닙니다

2026년 8월 공개 상태는 다음과 같습니다.

브라우저	공개 상태	해석
Chrome	149부터 오리진 트라이얼	실제 사이트 피드백을 받는 실험 단계
Edge	150에서 오리진 트라이얼	마이크로소프트가 공동 제안자로 참여
Brave	Leo AI Chat에 실험 지원	Chromium 계열의 초기 구현 확대
Firefox	Mozilla 표준 입장 `neutral`	채택 약속도 반대도 아닌 상태
Safari	WebKit 표준 입장 `oppose`	API 중복, 설계, 이식성, 개인정보, 보안, 동의 등에 우려

WebMCP 구현 현황에 Chrome·Edge·Brave의 실험이 올라와 있지만, Chrome 문서도 API가 활발히 논의 중이며 바뀔 수 있다고 밝힙니다. Angular의 지원 역시 experimental입니다. 현재 API를 프로덕션의 유일한 경로로 두기 어려운 이유입니다.

WebKit의 반대는 가볍게 넘길 사안이 아닙니다. Apple이 Safari에 채택하지 않으면 iPhone과 Mac의 중요한 브라우저 구간에서 동일한 API를 기대하기 어렵습니다. 웹 개발자가 WebMCP와 기존 접근성·DOM 경로를 함께 유지해야 한다면 표준 도입의 비용 절감 효과도 줄어듭니다.

가장 강한 반론은 세 가지입니다.

기존 웹 플랫폼과 기능이 겹칠 수 있습니다. 좋은 HTML, 양식, ARIA와 자동화 API를 개선하는 편이 더 보편적이라는 주장이 가능합니다.
사이트가 에이전트에게 별도 행동 표면을 주면 새로운 공격 면이 생깁니다. 인간에게 보이는 UI와 에이전트 도구의 권한이 달라지거나, 의미 있는 동의 없이 행동이 실행될 수 있습니다.
Chrome의 내장 에이전트가 우선 수혜를 얻을 수 있습니다. API가 공개돼도 어떤 에이전트가 도구를 볼 수 있고 브라우저 권한을 활용하는지는 구현 주체의 선택에 달려 있습니다.

반대로 이 제안이 살아남을 이유도 분명합니다. 웹 에이전트가 늘어날수록 화면 추측만으로는 비용, 신뢰성, 안전 요구를 충족하기 어렵고, 백엔드 API만으로는 로그인된 현재 UI의 맥락을 온전히 다루기 어렵습니다. 그 사이에 구조화된 프런트엔드 행동 계층이 필요하다는 문제 정의 자체는 유효합니다. 최종 이름과 API 모양이 달라지더라도 비슷한 기능은 다시 나타날 가능성이 높습니다.

복잡한 로그인 업무부터 도입 가치가 큽니다

모든 사이트가 바로 WebMCP를 붙일 필요는 없습니다. 도입 가치는 화면 해석의 불확실성과 업무 실패 비용이 큰 곳에서 먼저 생깁니다.

우선순위가 높은 영역

로그인 후 여러 단계가 이어지는 고객 지원, 계정 설정, 비용 처리와 관리 업무
날짜·좌석·옵션처럼 사용자 정의 UI가 복잡한 여행, 예약, 티켓 업무
필드가 많고 검증 규칙이 복잡한 신청서, 보험, 행정, B2B SaaS 양식
진단 실행, 필터 구성, 보고서 생성처럼 메뉴 안쪽의 기능을 반복 호출하는 업무
사용자가 화면에서 입력값과 결과를 확인해야 하는 고맥락 작업

우선순위가 낮은 영역

읽기만 하는 정적 콘텐츠와 단순한 링크 탐색
탭 없이 밤새 돌아가야 하는 배치·백그라운드 업무
이미 안정적인 서버 API와 MCP가 있고 UI 맥락이 필요하지 않은 기능
표준 HTML 양식과 접근성 정보만으로 충분히 안정적으로 자동화되는 짧은 흐름

도입할 때는 기존 업무 함수를 얇게 감싸는 방식이 좋습니다. 에이전트 전용 비즈니스 로직을 별도로 복제하면 사람용 UI와 행동이 달라지고 보안 검증도 두 벌이 됩니다. 읽기 전용 도구에서 시작해 평가 데이터를 쌓고, 되돌릴 수 있는 수정, 사용자 확인이 필요한 고위험 행동 순서로 확장하는 편이 안전합니다.

평가 기준도 페이지 로딩 성공률이 아니라 업무 결과로 잡아야 합니다.

사용자의 의도에 맞는 도구 선택률
필수·선택 인수의 정확도
여러 도구의 호출 순서와 중단 조건
사람의 수정·재입력·취소 비율
성공한 결과 한 건당 모델 호출, 지연과 비용
위험 행동의 승인 누락과 권한 초과 건수
WebMCP 실패 후 DOM·화면 폴백의 복구율

파급효과는 클릭의 소멸보다 웹의 이중 인터페이스화입니다

WebMCP를 AI가 웹사이트를 대신 쓰는 기술로만 보면 변화의 일부만 보입니다. 더 큰 변화는 웹서비스가 사람과 에이전트를 동시에 고객으로 맞는 운영체제로 바뀌는 것입니다.

단기에는 Chrome·Edge 중심의 실험과 특정 사이트 통합이 늘어날 가능성이 큽니다. 여행, 상거래, 생산성 SaaS처럼 브라우저 안에서 반복 작업이 많은 서비스가 선행할 수 있습니다. Computer Use와 DOM 자동화는 WebMCP를 지원하지 않는 사이트와 화면 요소를 담당하며 계속 공존합니다.

중기에는 웹 개발의 산출물에 도구 스키마, 권한, 에이전트 평가와 감사 기록이 추가될 수 있습니다. 접근성 트리가 인간의 다양한 입력 방식을 지원하듯, 행동 계약은 여러 에이전트가 사이트의 핵심 기능을 안정적으로 쓰게 하는 공통 표면이 됩니다. 사이트는 모델마다 별도 통합하는 대신 웹 표준에 한 번 연결하려 할 것입니다.

장기에는 브라우저가 에이전트 운영체제에 가까워질 수 있습니다. 사용자의 탭, 로그인, 쿠키, 비밀번호, 결제, 위치, 파일과 화면을 이미 중재하는 소프트웨어가 의도와 행동까지 연결하면 가장 풍부한 개인 업무 문맥을 갖게 됩니다. 이때 경쟁의 중심은 모델 점수만이 아니라 어떤 브라우저가 더 많은 사이트 도구, 안전한 권한 체계, 풍부한 사용자 문맥을 연결하는가로 이동합니다.

그러나 그 미래는 표준 합의와 신뢰에 달려 있습니다. WebKit의 반대를 해소하지 못하고 프롬프트 인젝션과 사용자 동의 문제를 충분히 풀지 못하면 WebMCP는 Chromium 계열의 편의 API에 머물 수 있습니다. 반대로 브라우저 중립적인 권한·확인 모델과 개발자 경험을 만든다면 웹사이트마다 흩어진 행동을 에이전트가 공통 방식으로 호출하는 기반이 될 수 있습니다.

맺으며

WebMCP의 본질은 AI가 버튼을 더 잘 누르게 만드는 데 있지 않습니다. 버튼의 의미를 추측해야 했던 구간을 사이트가 소유한 명시적 행동 계약으로 바꾸는 데 있습니다.

이 기술이 지향하는 웹은 화면 없는 웹이 아닙니다. 사람은 화면에서 상태와 결과를 이해하고 책임 있는 결정을 내리며, 에이전트는 구조화된 도구로 반복 탐색과 입력을 줄입니다. 사이트는 업무 로직과 고객 접점을 지키고, 브라우저는 사용자 의도·세션·권한·확인을 중재합니다.

따라서 WebMCP의 가장 큰 의미는 클릭의 종말이 아니라 사람용 UI 위에 에이전트용 행동 계층이 생기는 것입니다. 지금의 API가 그대로 표준이 될지는 아직 열려 있습니다. 그러나 웹이 사람만 읽는 문서와 화면에서, 에이전트도 안전하게 행동할 수 있는 계약을 가진 실행 환경으로 이동한다는 기술적 방향은 이미 분명해지고 있습니다.

주요 출처