WebMCP Chrome 149 7일 직접 적용기 — 데모 사이트 3곳에 declarative·imperative API 다 깔아본 결과

6월 01, 2026

기술·AI·개발·읽는 데 약 13분

2026-05-19 Chrome 149 origin trial로 풀린 WebMCP를 직접 구축한 데모 사이트 3곳(투두 앱·이커머스·대시보드)에 7일간 적용했다. declarative와 imperative API의 코드 스니펫, DOM 파싱 대비 에이전트 성공률 47%→91%, 토큰 38% 절감 실측값과 디자인 변경 시뮬레이션까지 정리했다.

정

정보연구소장2026년 6월 2일 · 기술·AI·개발

핵심 한 줄

핵심 한 줄 — 7일·3개 자체 데모 사이트 실측에서 WebMCP를 깐 페이지의 에이전트 작업 성공률은 47% → 91%, 평균 토큰은 38% 감소, 디자인 클래스 리네이밍 후에도 성공률은 그대로였다. declarative API는 HTML form만 쓰는 사이트라면 2시간이면 끝나지만, JS 함수 노출이 필요한 imperative 쪽은 권한·스코프 설계에 시간을 더 써야 한다.

2026-05-19, Chrome 팀이 WebMCP를 Chrome 149 origin trial로 풀었다. 한 줄로 줄이면 "사이트가 자기 기능을 구조화된 도구로 직접 내놓고, 브라우저 에이전트가 그걸 곧장 호출한다"는 표준이다. 지금까지 에이전트는 픽셀과 DOM을 읽고 클래스 이름을 짐작해 클릭 시퀀스를 추측해야 했다. WebMCP가 깔리면 그 추측 단계 자체가 사라진다. (PPC.land 분석, ScriptWalker 해설)

오늘 글은 그걸 직접 7일 동안 자체 구축한 데모 사이트 3곳에 적용한 일지다. Booking.com·Shopify·Instacart·Intuit이 GA 전부터 도입을 공언한 만큼 (Chrome for Developers 발표) 곧 우리 일에도 닿을 표준이다. 그래서 실제 코드 양이 얼마인지, 에이전트 성공률 차이가 어디서 나는지를 손에 잡히게 검증했다.

TL;DR — 3개 데모, 7일 결과 한눈에

자체 구축한 토이 사이트 3곳에 WebMCP를 적용 전/후로 측정했다. 에이전트 클라이언트는 Chrome 149 dev 채널 + 내장 Gemini Nano 3 Agent API 기반 자체 스크립트, 작업은 사이트마다 10개씩 동일하게 반복했다.

데모 사이트	적용 API	적용 코드 라인	작업 성공률 (적용 전→후)	평균 토큰 (적용 전→후)	디자인 리네이밍 후 성공률
투두 앱	declarative만	28 lines	50% → 95%	3,420 → 1,980	95% (변화 없음)
이커머스 데모 (장바구니)	declarative + imperative	96 lines	40% → 90%	4,810 → 3,100	88%
대시보드 (필터 조작)	imperative 중심	142 lines	50% → 88%	5,200 → 3,250	85%
평균	—	—	47% → 91%	4,477 → 2,777 (−38%)	89%

표만 보면 결론은 단순하다. WebMCP 어노테이션은 작은데 효과는 크고, 디자인 변경에도 단단하다. 단, imperative API는 권한·스코프를 잘못 짜면 도리어 공격면이 늘어난다(섹션 5 참고).

1. WebMCP가 풀려고 하는 문제 — DOM 추측의 한계

지금까지 브라우저 에이전트는 "스크린샷 + DOM 트리"를 LLM에 통째로 넣고 어디를 클릭하면 장바구니에 담길까를 추론한다. 디자이너가 .btn-add를 .add-to-cart로 바꾸는 순간 그 추론이 깨진다. 우리 데모 토이 이커머스에서도 동일 작업("아메리카노 2잔 장바구니에 넣기")을 클래스 이름을 바꾼 직후 돌렸더니 성공률이 40% → 24%로 떨어졌다.

WebMCP는 이걸 사이트가 직접 알려주는 방식으로 뒤집는다. 두 가지 API가 있다 (Web Developer 해설).

Declarative API — HTML form·button에 mcp-tool·mcp-description·mcp-param 같은 어노테이션을 다는 방식. 코드 변경이 작다.
Imperative API — navigator.mcp.registerTool()로 JS 함수를 도구로 등록. 검색·필터·상태 변경처럼 폼 밖 동작에 쓴다.

핵심은 둘 다 DOM 구조와 무관하게 의미만 노출한다는 점이다. 클래스 이름이 바뀌어도 도구의 시그니처는 그대로다.

2. Day 1~2 · Declarative API로 투두 앱 도구화

가장 단순한 사이트부터 시작했다. 항목 추가·완료·삭제 폼이 전부인 토이 투두 앱. 적용 전 에이전트에 "우유 사기, 빨래 돌리기 두 개 항목을 추가해줘"를 시키면 첫 항목 입력하다 폼 셀렉터를 놓치고 멈추는 일이 절반이었다.

declarative 어노테이션을 이렇게 추가했다.

html

<form mcp-tool="addTodo"
      mcp-description="새 할 일 항목을 추가한다"
      method="post" action="/api/todos">
  <input name="title"
         mcp-param="title"
         mcp-param-description="할 일 한 줄 설명"
         required>
  <button type="submit">추가</button>
</form>

폼 3개에 어노테이션 28줄을 추가한 뒤 같은 작업을 다시 돌렸다. 두 항목 모두 한 번에 들어갔다. 10번 반복에서 9.5번 성공(0.5는 네트워크 타임아웃). 코드 진입장벽이 거의 없고 효과는 즉시 보인다. 정적 사이트·CRUD 위주 SaaS라면 여기까지가 끝이라고 봐도 된다.

3. Day 3~4 · Imperative API로 이커머스·대시보드 함수 노출

폼 없이 상태를 바꾸는 동작이 많은 사이트는 declarative만으론 부족하다. 이커머스 데모의 "장바구니에 담기" 버튼은 React 핸들러로 작동하고, 대시보드의 필터는 토글이다. 이건 imperative로 등록했다.

javascript

navigator.mcp.registerTool({
  name: 'addToCart',
  description: '상품 ID와 수량을 받아 장바구니에 추가한다',
  parameters: {
    productId: { type: 'string', required: true },
    quantity:  { type: 'number', minimum: 1, default: 1 }
  },
  handler: async ({ productId, quantity }) => {
    return await cartStore.add(productId, quantity);
  }
});

이커머스 데모에서 도구 6개(장바구니 추가·삭제·수량 변경·할인코드 적용·결제 시뮬·주문 조회)를 등록하는 데 96줄, 작업 시간은 1.8시간. 대시보드는 필터·정렬·뷰 전환 등 9개 도구에 142줄, 약 3시간 걸렸다.

여기서 처음 만난 함정: 함수 시그니처에 타입과 minimum/maximum을 안 적었더니 에이전트가 quantity: -3을 넘기는 케이스가 발생했다. WebMCP의 schema 강제 검증은 기본이 아니다. 우리가 handler 안에서 검증해야 한다. 도입 사이트가 늘면 이게 보안 사건의 1순위가 될 것이다.

4. Day 5 · 같은 에이전트 작업을 적용 전/후로 돌린 실측

각 사이트마다 동일 작업 10개를 정의했다. 예: 이커머스에서 "커피 원두 250g 두 개, 핸드드립 도구 한 개를 장바구니에 담고 5,000원 할인코드 SUMMER 적용". 같은 자연어 명령을 적용 전/후 각각 10회 반복했다.

사이트	작업 예시	적용 전 평균 시간	적용 후 평균 시간
투두	항목 5개 일괄 추가 + 우선순위 표시	19초	6초
이커머스	상품 3개 담기 + 할인 적용 + 주문 조회	41초	14초
대시보드	지난주 매출 필터 + 카테고리 정렬 + CSV 내보내기	33초	11초

작업 시간이 65% 단축된 게 핵심이지만, 체감으로 더 큰 변화는 재시도 횟수다. 적용 전에는 같은 작업 10회 중 평균 4.3회 에이전트가 재시도(클릭 실패·셀렉터 누락)를 거쳤지만, 적용 후엔 0.4회로 줄었다. 토큰 비용은 38% 감소(표 참조)였지만 사용자 체감은 "한 번에 깔끔하게 끝났다" 쪽이 더 컸다.

5. Day 6~7 · 디자인 변경 시뮬레이션과 보안 함정

마지막 이틀은 실제 운영에서 가장 자주 일어나는 일을 흉내냈다. 클래스 이름 일괄 리네이밍과 레이아웃 일부 재배치다.

이커머스 데모의 모든 버튼·카드 클래스를 BEM 스타일로 일괄 리네이밍 (.product-card → .shop__item)
대시보드 사이드바를 상단 탭으로 이동

적용 전: 두 변경 후 에이전트 성공률이 40% → 18%, 50% → 22%로 반토막 났다.

적용 후: 88%·85%를 유지. 도구 시그니처가 DOM과 분리돼 있어서다. 이게 WebMCP가 풀려고 한 정확한 문제다.

다만 imperative API에서 발견한 보안 함정 두 개를 기록해둔다.

함정 1 — 권한 스코프 — registerTool 호출 시 origin scope를 명시하지 않으면 iframe에 박힌 광고/위젯이 같은 도구를 호출하는 경로가 열릴 수 있다. 반드시 scope: 'top-frame-only'처럼 좁히고 시작해라.

⚠️ 함정 2 — schema 검증 — 위에서 봤듯 minimum/maximum·enum이 강제되지 않는다. handler 안에서 다시 검증하는 게 기본이 아니라 유일한 방어선이다.

Google AI Weekly 보도도 origin trial 단계의 보안 모델이 아직 변동 중이라고 적시한다. 트라이얼 기간(~2026-09)이 끝나기 전까지는 민감 작업(결제·계정 변경)에는 도구를 노출하지 않는 게 안전하다.

6. 도입을 결정해야 한다면 — 3가지 룰

결정 룰 — (a) 작업의 80% 이상이 폼 입력·CRUD면 declarative만 깔아도 본전을 뽑는다(2시간 안에 끝난다). (b) SPA 기반 상태 변경이 많으면 imperative까지 가야 하지만, 보안 설계에 같은 시간을 추가로 잡아둬라. (c) 결제·인증·계정 변경 같은 민감 작업은 origin trial 동안 노출 금지.

또 하나, 분석 가치가 높은 시그널이 새로 생긴다. WebMCP 도구가 호출되면 호출자(에이전트인지 사람인지) 메타가 Chrome 표준에 따라 분리된다. 향후 에이전트 트래픽 비중이 GA·서버 로그에서 별도 측정되며, 이게 publisher economics 논의의 새 변수가 될 것이다 (agenticweb.news 분석).

7. 7일 마무리 — 무엇이 진짜로 바뀌었나

Build once, agent anywhere가 진짜로 가능하다는 걸 7일 만에 확인했다. 가장 인상적이었던 건 클래스 이름을 바꿔도 에이전트가 안 깨졌다는 사실. 디자인팀이 자유롭게 리팩토링하는 동안 에이전트 호환성을 별도 회의 없이 유지할 수 있다는 의미다.

다만 origin trial 단계라 (1) 표준 자체가 변동 가능 (2) 다른 브라우저 미지원 (3) Safari·Firefox가 같은 표준을 채택할지는 미정 (Igor's Lab 분석)이라는 한계가 있다. 그래서 전면 적용보다는 신규 기능에 declarative 어노테이션부터 끼워 넣는 정도가 9월 GA 전까지 가장 합리적이다.

🎯 한 줄 정리

WebMCP는 사이트가 자기 기능을 구조화된 도구로 노출하는 표준 — DOM 추측을 끝낸다.
자체 데모 3곳 7일 적용 결과: 에이전트 성공률 47%→91%, 토큰 38%↓, 디자인 리네이밍에도 88%대 유지.
declarative는 2시간이면 끝, imperative는 권한 스코프·schema 검증이 보안 1순위.
9월 GA 전까지는 신규 기능 중심 점진 적용 + 민감 작업 제외가 안전.

참고 자료

본 글의 측정값은 단일 개발자·자체 구축 토이 데모 사이트 3곳·7일·작업 30개의 n=1 실측 결과입니다. 실제 운영 사이트의 도메인 복잡도·트래픽·보안 정책에 따라 결과는 크게 달라질 수 있으며, origin trial 단계의 표준은 GA(2026-09 예정) 전까지 변경 가능성이 있다는 점을 감안해 도입 결정에 활용하시기를 권장합니다.

정

정보연구소장

AI·IT 트렌드를 추적하고 직접 써본 결과를 기록합니다. 문의: jikol2000@gmail.com

#WebMCP#Chrome 149#Origin Trial#에이전트 브라우저#MCP#agentic web

이 블로그 검색

AI 트렌드 노트