브라우저가 에이전트를 위한 API 레이어가 된다 — WebMCP 1편: 표준의 탄생

AI 에이전트가 웹을 사용하는 방식은 지금까지 이랬습니다. 화면을 캡처하고, DOM을 파싱하고, 버튼이 어디 있을지 추측하고, 클릭하고, 다시 기다립니다. 느리고, 깨지기 쉽고, 디자이너가 클래스 하나만 바꿔도 망가집니다. 2026년 5월 19일 Google I/O에서 공개된 **WebMCP(Web Model Context Protocol)**는 이 구조를 근본부터 바꾸려는 시도입니다. 웹사이트가 에이전트에게 "이렇게 써달라"고 직접 말할 수 있는 표준입니다. Chrome 149 Origin Trial이 6월 2일 열리고, Microsoft가 공동 저자로 참여했으며, 이미 Expedia를 포함한 글로벌 브랜드가 실험 중입니다. 무엇이 왜 등장했는지, 어떤 구조이고, 어디까지 왔는지 정리했습니다.

---

이 포스트 한 줄 요약 → WebMCP = 웹사이트가 JS 함수·HTML 폼을 에이전트용 도구로 직접 노출하는 브라우저 표준 → Google I/O 2026 (5/19) 발표, Chrome 149 Origin Trial 6월 2일 개시 → 현재 Chrome 146 Canary에서 WebMCP for testing 플래그로 테스트 가능 → Google·Microsoft 공동 저작, W3C Web ML Community Group 인큐베이션 → Edge 147 이미 지원, Firefox·Safari 미공표 → Gemini in Chrome이 현재 WebMCP 도구를 소비하는 유일한 에이전트 → Declarative API (HTML 어노테이션) + Imperative API (JS 함수 등록) 두 방식 → DOM 스크래핑 → 구조적 도구 호출로의 전환 — "AEO(에이전트 엔진 최적화)" 개념 등장

---

문제: 에이전트는 지금 어떻게 웹을 쓰나

브라우저 에이전트가 항공권을 예약하려면 지금 이런 과정을 거칩니다.

1. 페이지 스크린샷 캡처
2. 시각 모델로 UI 파싱 ("출발지 입력 필드가 좌측 상단에 있음")
3. 클릭 좌표 계산 → 클릭 실행
4. 다시 스크린샷 → 폼이 맞게 채워졌는지 확인
5. "여행자 수" 드롭다운 발견 → 다시 파싱
6. ... 수십 번 반복

이 방식의 문제는 세 가지입니다. 속도 — 스크린샷·파싱을 반복하니 단순한 예약 하나에 수십 초가 걸립니다. 신뢰성 — 버튼 위치가 바뀌거나 A/B 테스트가 돌아가면 에이전트가 멈춥니다. 비용 — 시각 파싱에 쓰이는 토큰과 왕복 요청이 누적됩니다.

WebMCP는 이 구조를 뒤집습니다. 에이전트가 추측하는 대신, 웹사이트가 직접 "이 기능은 이렇게 호출하면 됩니다"를 선언합니다.

---

WebMCP란 정확히 무엇인가

Web Model Context Protocol의 약자입니다. 브라우저 안에서 웹사이트가 AI 에이전트에게 구조화된 도구(tool)를 노출하는 제안 표준입니다. 두 가지 방식으로 도구를 정의합니다.

Declarative API — HTML 폼에 어노테이션을 추가하는 방식입니다. 기존 HTML을 거의 그대로 유지하면서 에이전트용 메타데이터를 덧붙입니다.

<!-- 기존 검색 폼 -->
<form
  data-mcp-tool="flight-search"
  data-mcp-description="항공편을 검색합니다. 출발지, 도착지, 날짜를 받아 가용 항공편 목록을 반환합니다."
>
  <input name="origin" data-mcp-param-description="출발 공항 코드 (예: ICN)" />
  <input name="destination" data-mcp-param-description="도착 공항 코드 (예: NRT)" />
  <input type="date" name="departure" />
  <button type="submit">검색</button>
</form>

Imperative API — JavaScript로 도구를 명시적으로 등록하는 방식입니다. 폼 없이도 에이전트가 호출할 수 있는 함수를 직접 정의합니다.

// 에이전트가 호출할 수 있는 도구 등록
navigator.mcpTools.register({
  name: "add-to-cart",
  description: "상품을 장바구니에 추가합니다.",
  parameters: {
    productId: { type: "string", description: "상품 ID" },
    quantity:  { type: "number", description: "수량", default: 1 },
  },
  handler: async ({ productId, quantity }) => {
    const result = await cartAPI.add(productId, quantity);
    return { success: true, cartTotal: result.total };
  },
});

에이전트는 이 도구 목록을 읽고, 스크린샷 없이 직접 함수를 호출합니다. 서버 사이드 MCP와 같은 도구 정의 구조를 브라우저 레이어로 가져온 것입니다.

---

서버 MCP와 무엇이 다른가

Anthropic이 주도한 MCP(Model Context Protocol)는 이미 서버 측에서 에이전트 도구를 노출하는 방식으로 자리잡고 있습니다. WebMCP는 그 개념을 브라우저로 가져온 것이지만, 중요한 차이가 있습니다.

항목 서버 MCP WebMCP

실행 위치	서버·클라우드	브라우저 (클라이언트)
백엔드 필요	✅ 필수	❌ 불필요
인증 주체	서버 인증	브라우저 Permissions Policy
에이전트 위치	외부 에이전트	브라우저 내장 에이전트
표준화 주체	Anthropic 주도	W3C (Google·Microsoft 공동)
현재 성숙도	프로덕션 사용	Origin Trial 단계

핵심 차이는 브라우저가 신뢰 경계가 된다는 점입니다. 서버 MCP는 에이전트가 외부에서 API를 호출하는 구조지만, WebMCP는 사용자가 열어둔 탭 안에서 에이전트가 그 페이지의 기능을 직접 사용하는 구조입니다. 사용자의 로그인 세션, 쿠키, 로컬 상태가 그대로 활용됩니다.

---

표준화 현황 — 어디까지 왔나

W3C 위상: 현재 W3C Web Machine Learning Community Group에서 인큐베이션 중입니다. W3C 공식 Standards Track에는 아직 오르지 않았습니다. Community Group 단계는 제안이 실험을 거쳐 Working Group으로 넘어가기 전 단계입니다.

브라우저별 지원 현황:

브라우저 상태

Chrome	✅ 146 Canary 플래그 테스트 → 149 Origin Trial (6/2)
Edge	✅ 147 지원 (2026년 3월, Microsoft 공동 저작)
Firefox	❌ 미공표
Safari	❌ 미공표

Chrome(~65%) + Edge(~5%) = 약 70% 브라우저 커버리지입니다. Firefox와 Safari가 없는 상황이지만, Google과 Microsoft가 공동 저작한 표준이 70% 점유율 브라우저에서 동시에 지원된다는 건 가볍지 않은 신호입니다.

타임라인:

2026년 3월     — Microsoft, Edge 147에 WebMCP 지원 첫 출시
2026년 5월 18일 — Chrome Developers 공식 문서 게시
2026년 5월 19일 — Google I/O 2026 개발자 키노트 발표
2026년 6월 2일  — Chrome 149 Origin Trial 정식 개시
미정            — Gemini in Chrome WebMCP API 정식 지원
미정            — W3C Working Group 승격 여부 결정

---

지금 누가 쓰고 있나

Google I/O에서 Expedia가 WebMCP 도구를 라이브 데모로 시연했습니다. 에이전트가 DOM을 파싱하지 않고 flight-search 도구를 직접 호출해 결과를 반환하는 흐름을 보여줬습니다. 구체적인 기업명 외에도 글로벌 소비자 브랜드 6곳이 I/O 발표 시점에 공개적으로 구현 의사를 밝혔습니다.

Chrome 146 Canary에서 chrome://flags에서 WebMCP for testing을 활성화하면 지금 바로 테스트할 수 있습니다. Origin Trial 등록은 Chrome Developer Console에서 도메인을 등록하면 되고, 6월 2일(Chrome 149) 이후 실제 사용자 트래픽에서 테스트할 수 있게 됩니다.

---

왜 지금 시점에 등장했나

세 가지 조건이 동시에 갖춰졌기 때문입니다.

첫째, 브라우저 내장 에이전트의 등장입니다. Gemini in Chrome, Microsoft Copilot in Edge처럼 브라우저 안에 에이전트가 내장되면서 "브라우저가 에이전트를 위한 실행 환경"이 되는 구조가 현실화됐습니다. 에이전트가 탭 안에 있으면, 웹사이트와 에이전트 사이의 프로토콜이 필요합니다.

둘째, 스크래핑의 한계가 임계점을 넘었습니다. Computer Use 에이전트들이 실제 서비스에서 운영되면서 스크린샷 기반 방식의 비용과 신뢰성 문제가 수면 위로 올라왔습니다. 빠르고 예측 가능한 대안이 필요해졌습니다.

셋째, MCP 생태계가 선례를 만들었습니다. Anthropic의 MCP가 서버 사이드에서 "에이전트 도구 정의"의 표준으로 자리잡으면서, 같은 개념의 브라우저 버전에 대한 수요가 생겼습니다. WebMCP는 그 연장선에 있습니다.

---

개발자에게 무엇이 달라지는가

WebMCP가 안착하면 웹 개발의 고려 대상이 하나 늘어납니다. 지금까지 웹사이트는 사람이 보는 UI를 만들었습니다. 앞으로는 사람이 보는 UI + 에이전트가 호출하는 도구를 함께 설계해야 합니다.

"Buy" 버튼은 사람이 클릭하는 UI 요소이면서, 동시에 에이전트가 호출하는 add-to-cart 도구의 트리거가 됩니다. 검색 폼은 사용자 인터페이스이면서, product-search 도구의 스키마 정의가 됩니다. SEO가 검색 엔진을 위한 최적화였다면, **AEO(Agent Engine Optimization)**는 에이전트를 위한 최적화가 됩니다. 에이전트가 어떤 사이트의 도구를 잘 호출할 수 있느냐가 트래픽에 영향을 미치는 시대가 오고 있습니다.

---

남은 불확실성

WebMCP는 아직 제안 단계입니다. 현실적인 리스크가 있습니다.

Firefox와 Safari가 구현하지 않으면 "Chromium 전용 패턴"으로 끝날 수 있습니다. 역사적으로 Apple은 Privacy 이유로 독자적인 접근을 택해왔고, WebMCP가 브라우저 에이전트의 행동을 사이트가 추적할 수 있게 한다는 점에서 Safari 지원 여부는 불투명합니다. Anthropic의 2026 MCP 로드맵에도 WebMCP에 대한 언급이 없습니다.

Origin Trial이 데이터를 쌓고, W3C Working Group 승격 여부가 결정되는 시점이 사실상의 분기점입니다.

---

✅ 결론

항목 평가

문제 해결 방향	✅ DOM 스크래핑의 근본 한계를 정면으로 공략
표준화 주체	✅ Google·Microsoft 공동, W3C 인큐베이션
브라우저 커버리지	⚠️ 70% (Chrome+Edge), Firefox·Safari 미정
현재 성숙도	⚠️ Origin Trial 단계, 스펙 변동 가능
개발자 도입 난이도	✅ HTML 어노테이션 수준으로 진입 가능
생태계 파급력	✅ AEO 개념 촉발, 웹 개발 패러다임 확장

WebMCP는 오늘 당장 프로덕션에 도입할 표준은 아닙니다. 하지만 "에이전트가 웹을 어떻게 사용할 것인가"의 방향을 결정할 수 있는 표준입니다. Origin Trial 기간 동안 핵심 사용자 플로우 하나에 도구를 정의해보는 것이 지금 시점에서 가장 현실적인 대응입니다.