--- 창작제목: "웹사이트가 AI에게 직접 말을 걸기 시작했다 — WebMCP" 원제목: "WebMCP, Web 문서를 읽는 AI 에이전트에게 사용 가능한 기능을 도구로 알려주는 웹 표준 제안 (feat. Microsoft, Google, ChatGPT)" 출처: https://discuss.pytorch.kr/t/webmcp-web-ai-feat-microsoft-google-chatgpt/11770 저장소: https://github.com/webmachinelearning/webmcp 정리: 다비(davi.kr) — https://davi.kr/ 작성일: 2026-09-02 태그: [WebMCP, AI Agent, 웹표준, MCP, Chrome, W3C, 브라우저] 문서목적: WebMCP 표준 제안의 개념·성능 수치·보안 쟁점을 실무 판단 가능한 수준으로 압축 정리 --- # 웹사이트가 AI에게 직접 말을 걸기 시작했다 — WebMCP > 원문: https://discuss.pytorch.kr/t/webmcp-web-ai-feat-microsoft-google-chatgpt/11770 > 저장소: https://github.com/webmachinelearning/webmcp --- ## 쉬운 설명 지금까지 AI 에이전트는 웹사이트를 사람처럼 "눈으로 보고" 다뤘습니다. 화면을 캡처해 버튼처럼 생긴 것을 찾고, 좌표를 계산해 클릭을 흉내 냈죠. 그런데 사이트 디자인이 한 번 바뀌면 그대로 무너지고, 화면을 볼 때마다 토큰 비용이 나갑니다. **WebMCP는 이 순서를 뒤집습니다. 웹사이트가 "나는 검색·장바구니·예약 기능이 있다"고 AI에게 직접 알려주는 방식입니다.** 방법은 두 가지입니다. 자바스크립트로 `document.modelContext.registerTool()`을 호출해 기능을 등록하거나(명령형), 이미 있는 `
` 태그에 `toolname`·`tooldescription` 속성 두 개만 붙이는 것(선언형)입니다. Microsoft와 Google 엔지니어 6명이 2025년 8월 13일 처음 공개했고, 2026년 8월 기준 **Chrome 149 / Edge 150에서 오리진 트라이얼 진행 중**, Brave는 실험적 지원, ChatGPT 데스크톱 앱은 '사이트 도구(Site tools)'라는 이름으로 지원합니다. GitHub 저장소는 별 3.5k, 이슈 108개로 활발히 논의 중입니다. --- ## 활용 방법 - **가장 싼 시작점**: 이미 있는 HTML 폼에 속성 두 개만 추가하세요. 코드는 이게 전부입니다. ```html ``` - **명령형 첫 도구는 읽기 전용으로 만드세요.** `annotations: { readOnlyHint: true }`를 붙이면 에이전트가 상태 변경 여부를 판단합니다. - **Chrome에서 바로 테스트하세요**: `chrome://flags/#enable-webmcp-testing` 활성화 후 재시작. - **에이전트 없이 확인하려면** Model Context Tool Inspector 확장을, 미지원 브라우저에서는 Chrome 팀의 WebMCP 폴리필을 쓰세요. - **도구 설명 상한을 지키세요**: 도구 설명 500자, 파라미터 설명 150자, 이름 각 30자, 개별 출력 1.5K자. --- ## 전문가 의견 (사실 기반) **1) 성능 이득은 '정확도'가 아니라 '비용'에서 나옵니다.** 오픈소스 벤치마크 WindTunnel(8개 사이트, 49개 작업, 2,352회 시도)에서 동일 모델(Sonnet 5) 기준: | 방식 | 중앙값 비용 | 토큰 | 시간 | |---|---|---|---| | WebMCP | $0.009 | 5,172 | 6.8초 | | DOM+비전 | $0.210 | 64,424 | 29.3초 | **비용 23배, 토큰 12.5배, 시간 5.5배 차이입니다.** 반면 해결률은 둘 다 48/49로 동일했습니다. 즉 "더 정확해진다"가 아니라 **"같은 정확도를 몇 분의 일 비용으로 얻는다"**가 방어 가능한 근거입니다. 턴 예산 소진은 WebMCP 1,029건 중 0건, 화면 구동 방식 1,323건 중 181건이었습니다. **2) 아직 표준이 아닙니다.** Firefox는 중립(neutral), **Safari(WebKit)는 공식 반대(oppose)** 입장입니다. WebKit의 논지는 날카롭습니다 — "타입 스키마는 인자의 형태만 제약할 뿐 에이전트가 추론할 의미는 제약하지 않는다. 취약성이 DOM에서 도구 설명으로 옮겨갈 뿐이다." 또한 사이트가 에이전트를 식별할 수 있게 되면 사람용 화면과 에이전트용 화면이 갈라질 위험을 지적합니다. **3) 명세 자체에 구멍이 남아 있습니다.** 선언형 API를 다루는 명세 4.3절은 통째로 TODO이고, 접근성 고려사항(7절)은 제목만 있고 내용이 비어 있습니다. 지금 Chrome에서 동작하는 폼 속성은 확정 표준이 아니라 시험 구현입니다. **4) 보안 위험이 구조적입니다.** 도구 설명 자체가 공격 표면입니다(도구 중독), 도구 반환값에 지시를 섞는 출력 인젝션, 그리고 `pregnant`·`skinTone` 같은 파라미터를 요구해 개인정보를 긁는 **과잉 파라미터화**까지 명세가 직접 열거합니다. 특히 "선언한 의도가 실제 동작과 일치한다는 보장이 없다"고 명세가 인정합니다. `finalizeCart`가 실제로는 결제를 실행할 수 있습니다. --- ## Bottom Line **오늘 당장 사이트의 폼 하나에 `toolname`·`tooldescription` 두 속성을 붙이고 Chrome 149에서 열어 보십시오.** 시도 비용이 사실상 0에 가깝고, 표준 확정 여부와 무관하게 "내 사이트의 기능을 기계가 읽을 수 있게 서술하는 훈련"은 남습니다. 단, 결제·삭제 같은 고권한 동작에는 `toolautosubmit`을 붙이지 마시고, 기존 사람용 UI는 반드시 그대로 유지하십시오. WebMCP는 대체가 아니라 점진적 향상(progressive enhancement)입니다. --- *정리: 다비(davi.kr) · https://davi.kr/*