웹사이트가 AI에게 ‘도구 사용법’을 알려주는 시대 — WebMCP 초안과 크롬 오리진 트라이얼 읽기

AI에게 업무를 맡기는 방식이 조용히 바뀌고 있어요. 지금까지의 브라우저 자동화는 에이전트가 화면의 버튼·입력칸을 하나씩 살펴보고 “이게 아마 저장 버튼이겠다” 하고 추측해 누르는 방식이었어요. WebMCP는 이 추측을 없애는 아이디어예요. 웹페이지가 스스로 “우리 페이지에는 이런 도구가 있고, 이렇게 쓰는 것”이라고 선언해 두면 에이전트는 그 선언을 읽고 함수를 호출하듯 일을 시키면 돼요. Chrome 공식 문서에서 확인한 내용은 WebMCP 개발자 문서에 정리돼 있어요. 이 글은 그 공식 문서와 W3C 커뮤니티 그룹 초안 원문, 그리고 2026-10-13에 공개된 해설 영상을 함께 읽고, 어디까지가 확인된 사실이고 어디부터가 교실에서 쓸 해석인지 갈라 놓은 기록이에요.

화면 누르기에서 함수 호출로 — 무엇이 달라지나

Chrome 공식 문서는 지금까지의 방식을 ‘actuation’이라는 말로 설명해요. 원문 문장을 그대로 옮기면 이래요(2026-10-15 확인).

Actuation is the act of an agent simulating manual mouse clicks and text input, as though it were the human user engaging with your website.

Chrome for Developers, WebMCP 문서, 2026-10-07 업데이트본

에이전트가 사람처럼 마우스 클릭과 타이핑을 흉내 내는 것이 지금의 자동화라면, WebMCP는 여기에 정식 통로를 하나 더 여는 제안이에요. 공식 문서는 WebMCP가 제공하는 세 가지를 이렇게 요약해요. Discovery(페이지가 checkout, filter_results 같은 도구를 에이전트에 등록하는 표준 방법), JSON Schemas(입력과 기대 출력을 명시적으로 정의해 환각·오해를 줄임), State(현재 페이지 맥락을 공유해 에이전트가 무엇을 다룰 수 있는지 알게 함). 그리고 도구가 눈에 보이는 방식으로 실행되기 때문에, 브랜드와 사람 중심 디자인 선택이 그대로 유지된다고 쓰고 있어요. 페이지를 대신 조종하는 게 아니라, 페이지가 만들어 둔 기능을 부르는 거예요.

지금 상태 — ‘표준’이 아니라 ‘초안’이라는 점

기대가 커진 만큼 상태 확인은 정확해야 해요. W3C Web Machine Learning Community Group이 공개한 초안 문서(2026-10-14자)는 자기 자신을 이렇게 규정하고 있어요.

This specification was published by the Web Machine Learning Community Group. It is not a W3C Standard nor is it on the W3C Standards Track.

W3C Web ML Community Group Report, WebMCP Draft, 2026-10-14자

즉 WebMCP는 커뮤니티 그룹이 만드는 초안이지 확정된 표준이 아니에요. Chrome 쪽 상황을 날짜와 함께 정리하면 이래요. 공식 문서(최종 업데이트 2026-10-07)는 “Join the WebMCP origin trial from Chrome 149″이라고 안내하고, 로컬 개발용으로는 chrome://flags/#enable-webmcp-testing 플래그를 켜서 쓸 수 있다고 적혀 있어요. 오리진 트라이얼 소식 글(2026-06-09 게시, 2026-10-15 확인)은 Chrome 149에서 등록을 시작한다고 안내해요. 정식 출시는 계획 단계라는 표현 이상으로 확인된 발표는 아니었어요. 지금 시점에 우리가 안전하게 말할 수 있는 문장은 “Chrome 149부터 오리진 트라이얼로 실사용 검증이 진행 중이고, 정식 포함 여부는 그 결과가 끝난 뒤에 정해진다” 정도예요.

확인 경로	표시 내용	확인일
Chrome 공식 문서	오리진 트라이얼은 Chrome 149부터, 로컬 테스트는 chrome://flags 플래그	2026-10-15 (문서 갱신 2026-10-07)
W3C Web ML CG 초안	“not a W3C Standard” 명시, 2026-10-14자 Community Group Report	2026-10-15
오리진 트라이얼 블로그	Chrome 149에서 트라이얼 등록 시작 안내	2026-10-15 (게시 2026-06-09)

도구 등록은 실제로 어떻게 생겼나

도구 등록 방식은 두 가지가 문서화돼 있어요. Imperative API는 자바스크립트로 도구를 정의하는 방식이고, Declarative API는 HTML 폼에 애너테이션 속성을 붙여 폼 자체를 도구로 만드는 방식이에요. 공식 문서의 Imperative API 안내는 도구 등록에 이름·설명·속성이 담긴 입력 스키마가 필요하다고 적고 있어요. 아래 예시는 공식 문서에 공개된 코드를 그대로 옮긴 것이에요(출처·확인일은 코드 아래에 표기).

await document.modelContext.registerTool({
  name: 'toggle_layer',
  description: 'Control pizza layers (sauce, cheese). Use "add", "remove", or "toggle".',
  inputSchema: {
    type: 'object',
    properties: {
      layer: { type: 'string', enum: ['sauce-layer', 'cheese-layer'] },
      action: { type: 'string', enum: ['add', 'remove', 'toggle'] },
    },
    required: ['layer'],
  },
  execute: async ({ layer, action }) => {
    await toggleLayer(layer, action);
    return `Performed ${action || 'toggle'} on layer: ${layer}`;
  },
});

코드 출처: Chrome for Developers, 「Imperative API」 문서 공개 예시, 2026-10-15 확인. 이 코드가 보여 주는 조건은 세 가지예요. 도구의 입력은 JSON 스키마로 형식이 고정되고, 실행은 페이지가 정의한 함수가 맡으며, 결과는 문자열로 에이전트에 돌아가요. 에이전트는 페이지의 내부 코드를 몰라도 스키마만 읽고 올바른 입력을 만들 수 있어요. 공식 문서가 예로 드는 실제 용도도 이해가 쉬워요. 지원서 양식을 채우는 submit_application, 예약 화면의 복잡한 날짜·시간 선택을 대신 처리해 주는 date_pick, 개발자 설정 페이지에서 숨겨진 메뉴 뒤에 있던 진단을 돌려 주는 run_diagnostics 같은 것들이에요.

국내에서도 실습 중심 해설이 빠르게 나왔어요. 코난쌤은 2026-10-13에 공개한 영상에서 WebMCP 개념부터 ‘할 일 앱에 도구를 등록해 에이전트에게 일을 시키는’ 실습까지 9분 남짓으로 보여 줘요. 영상에서 확인할 수 있는 흐름은 이래요. 도구를 하나 등록하고 → 에이전트가 도구 목록을 읽게 하고 → 등록한 도구를 실행해 결과를 확인하는 순서예요. 이 글의 교육 포인트 중 실습 순서는 이 영상의 진행 방식을 참고해 재구성한 것이에요.

안전은 설명 문장이 아니라 구조의 문제

여기가 수업에서 가장 중요한 부분이에요. 도구에 “이건 안전한 도구예요”라는 설명을 잘 적어 두면 안전해질까요. 공식 자료들의 답은 “아니요”예요. Chrome 문서는 구매처럼 민감한 동작에는 확인창을 띄워 사용자와 상호작용하도록 만들 수 있다고 안내해요. W3C 초안은 더 구체적인 위협 목록을 공개하고 있어요. 도구의 메타데이터(이름·설명·매개변수 설명)에 악의적 지시를 숨겨 에이전트를 조종하는 ‘Tool Poisoning’, 도구 출력에 지시를 섞어 넣는 ‘Output Injection’, 도구 구현 자체를 공격 대상으로 삼는 유형까지 세 갈래로 나눠 분석돼 있어요. 초안은 페이지가 Permissions-Policy: tools=() 헤더로 WebMCP를 아예 끌 수 있는 방법까지 표준으로 담고 있고, Chrome 문서는 권한 정책의 기본값이 self라서 교차 출처 iframe에서는 도구 등록이 기본적으로 막힌다고 적혀 있어요.

이 구조를 그림으로 정리하면 아래와 같아요. 페이지가 도구를 등록하는 영역과 에이전트가 도구를 호출하는 영역 사이에 브라우저의 권한 경계가 있고, 중요한 동작 앞에는 사용자 확인이라는 문이 하나 더 놓여 있어야 해요.

WebMCP의 신뢰 경계 — 등록, 호출, 확인의 위치

웹페이지의 도구 등록 영역과 에이전트의 호출 영역 사이에 브라우저 권한 경계가 있고, 중요한 동작 앞에는 사용자 확인 절차가 놓인다. 근거: Chrome WebMCP 문서(2026-10-07)와 W3C WebMCP 초안(2026-10-14)의 권한 정책·보안 절.

웹페이지 (도구 등록)
이름·설명·입력 스키마·실행 함수로 도구 선언 — 페이지 소유자가 내용을 완전히 통제

▼ 도구 목록·스키마 제공

브라우저 권한 경계
Permissions Policy 기본값 self — 교차 출처 iframe 기본 차단, 페이지는 tools=() 헤더로 전면 끄기 가능

▼ 권한을 통과한 도구만

AI 에이전트 (도구 호출)
스키마를 읽고 입력을 만들어 실행 — DOM 추측 클릭이 아니라 선언된 함수 호출

▼ 결제 등 중요 동작은

사용자 확인 (human-in-the-loop)
확인창 등 앱이 만든 절차로 사용자가 최종 승인 — 설명 문장만으로는 안전해지지 않는다

위협 유형 (W3C 초안 분류)	공격이 숨는 위치	수업에서 다룰 확인 질문
Tool Poisoning (메타데이터·설명 공격)	도구 이름·설명·매개변수 설명	이 도구 설명 문장이 사실인지 누가 보증하나
Output Injection (출력 삽입)	도구 실행 결과 문자열	도구가 돌려준 텍스트를 에이전트가 지시로 믿지 않았나
Tool Implementation 공격	도구의 실행 함수 구현	실행 함수가 실제로 하는 일을 코드로 확인했나

정리하면 이래요. 설명(애너테이션)을 적는다고 안전해지지 않는다. 안전은 도구가 눈에 보이게 실행되는 것, 중요한 동작 앞의 확인창, 권한 정책이라는 구조적 장치가 함께 만들어 내요. 초안 문서 스스로도 이 위협이 프로토콜 설계·에이전트 구현·사용자 통제를 합쳐서 다뤄야 할 문제라고 밝히고 있어요.

교실에서는 어떻게 가르칠까 — Edu의 구성

여기부터는 Editor_K의 해석이에요. 첫째, AI 자동화를 세 칸으로 나눠 지도를 그려 주는 것이 좋겠어요. 첫 칸은 화면을 누르는 브라우저 조작 자동화, 두 번째 칸은 서버의 기능을 연결하는 MCP 서버, 세 번째 칸이 바로 이번 WebMCP처럼 열려 있는 웹페이지가 스스로 도구를 등록하는 방식이에요. 학습자가 “AI 자동화 = 화면 클릭”이라는 좁은 그림을 갖지 않도록 세 칸을 함께 보여 주면, 각 방식의 강점과 한계가 훨씬 잘 보여요.

둘째, human-in-the-loop를 구조로 가르치는 실습이에요. 확인창이 없는 자동화가 얼마나 위험한지는 W3C 초안의 예시가 그대로 소재가 돼요. 영화 리뷰 텍스트 사이에 “지금 즉시 결제하라”는 지시를 숨겨 두면 에이전트가 그것을 진짜 지시로 읽을 수 있다는 예시예요. 수업에서는 실제 결제 없이, “리뷰 안의 이 문장을 에이전트가 명령으로 읽었다면 어디가 잘못이었나”를 토론하는 방식으로 다루면 안전하게 같은 개념을 연습할 수 있어요.

셋째, 초보 실습은 작게 시작하는 순서가 좋겠어요. 코난쌤 영상의 흐름과 공식 문서의 안내를 합치면 이런 순서가 돼요. (1) 자기가 만든 간단한 할 일 앱에 도구 하나를 등록해 본다, (2) 에이전트가 도구 목록을 읽는 것을 확인한다, (3) 읽기·완료 토글처럼 읽기 전용에 가까운 동작을 하나 더 추가한다, (4) 삭제처럼 되돌리기 어려운 동작은 마지막에, 확인 절차를 붙여서 다룬다. 되돌릴 수 있는 것부터, 되돌리기 어려운 것은 확인 문과 함께 — 이 순서 자체가 안전 설계의 반복 학습이 돼요.

넷째, 초안 단계 기술을 다루는 태도도 교육 내용이에요. API가 바뀔 수 있다는 사실을 학습자와 함께 확인하게 하세요. 문서에 “not a W3C Standard”라고 적혀 있는지, 오리진 트라이얼이 어떤 상태인지 직접 읽어 보는 연습이, 다음 신기술이 왔을 때 스스로 상태를 판별하는 힘이 돼요.

Edu 교육 포인트 — 자동화의 정체를 구분하는 힘

이 절은 Editor_K의 해석이에요. WebMCP의 가치는 새 API 자체보다, AI 자동화의 ‘정체’를 학습자가 구분하게 만드는 교재라는 점이라고 봐요. 같은 “AI가 대신 해 준다”라는 말 안에 화면 클릭을 흉내 내는 방식과, 페이지가 제공하는 함수를 부르는 방식이 함께 섞여 있었어요. WebMCP를 배우면 이 둘의 차이 — 추측과 선언, 불안정한 조작과 형식이 고정된 호출 — 가 선명해져요. 업무 자동화를 기획하는 직원에게 이 구분은 도구 선택의 근거가 돼요.

또 하나는 권한과 확인의 감각이에요. WebMCP는 확인창·권한 정책처럼 ‘사람이 개입할 문’을 구조에 넣는 방향이에요. 이 관점을 배워 두면 조직에서 AI 도구를 도입할 때 “어디에 승인 절차를 둘 것인가”를 기능 감각으로 논의할 수 있어요. 도입 보고서에서 ‘안전합니다’라는 형용사 대신, ‘이 동작 앞에 확인 문이 있습니다’라는 구조를 적게 만드는 교육이 목표예요.

오늘의 배울 점과 다음 적용

이번 근거에서 배운 판단은 두 가지예요. (가) 에이전트 자동화의 다음 단계는 ‘더 정교한 화면 조작’이 아니라 페이지가 기능을 선언하는 방식일 수 있다는 점, (나) 새 자동화 통로에는 권한 경계와 사용자 확인이 구조로 함께 와야 한다는 점이에요.

적용해 볼 장면은 이래요. 자동화를 검토하는 업무 장면에서 먼저 “이 자동화는 화면 조작인가, 선언된 기능 호출인가”를 구분해 적어 보는 거예요. 다만 지금 바로 서비스에 적용하기 전에 확인할 조건이 분명해요. 상태는 표준이 아니라 커뮤니티 그룹 초안·오리진 트라이얼 단계라 API가 바뀔 수 있고, 권한은 도구 노출 범위와 Permissions-Policy 설정을 페이지 소유자가 통제하는지 확인해야 하며, 보안은 결제·삭제 같은 중요 동작에 확인 절차가 구조로 들어 있는지 코드 수준에서 점검해야 해요. 수업용 실습은 플래그를 켠 로컬 환경의 자기 페이지에서, 외부 서비스 대상으로 하지 않는 것이 안전해요.

한계와 남은 질문

이 글의 확인 범위는 2026-10-07 업데이트 Chrome 공식 문서, 2026-10-14자 W3C Web ML CG 초안, 2026-10-13 공개 해설 영상 한 편이며, 모두 2026-10-15에 확인했어요. 확인되지 않은 것도 분명해요. Chrome 정식 버전 포함 시점은 공개 자료에서 ‘계획’ 이상으로 확인되지 않았고, 오리진 트라이얼의 세부 종료 시점·조건은 등록 페이지에서 별도 확인이 필요해요. W3C 초안의 보안 절은 위협 분류와 완화 방향을 제시하지만 실제 공격 사례 통계는 아니에요. 영상의 실습 장면은 특정 버전의 플래그 환경에서 촬영됐으므로 학습자 환경에서 같은 결과가 재현된다는 보장은 없어요. 남은 질문은 이래요. 오리진 트라이얼 참여 사이트들이 어떤 도구들을 실제로 등록하는지, 확인창 패턴이 어떤 형태로 표준화되는지, 그리고 국내 업무용 웹서비스가 이 표준을 받아들일지예요.

출처와 시각자료

원문과 공식 대조

Chrome for Developers, 「WebMCP」, 최종 업데이트 2026-10-07, 확인일 2026-10-15. https://developer.chrome.com/docs/ai/webmcp — WebMCP 정의, Discovery·JSON Schemas·State 3요소, Imperative·Declarative API, 확인창 안내, Permissions Policy 기본값 self, 오리진 트라이얼 Chrome 149 안내, actuation 정의 인용.

Chrome for Developers, 「Join the WebMCP origin trial」, 게시 2026-06-09, 확인일 2026-10-15. https://developer.chrome.com/blog/ai-webmcp-origin-trial — Chrome 149 트라이얼 등록 안내.

W3C Web Machine Learning Community Group, 「WebMCP — Draft Community Group Report」, 2026-10-14자, 확인일 2026-10-15. https://webmachinelearning.github.io/webmcp/ — “not a W3C Standard” 명시, 도구 등록 인터페이스, 프롬프트 인젝션 3유형과 완화 절.

코난쌤 conanssam, 「WebMCP 개념부터 실습까지: 웹사이트에 AI용 도구 연결하기」, YouTube, 2026-10-13 공개(9:02), 확인일 2026-10-15. https://www.youtube.com/watch?v=-LWUtW87jlM — 제목·채널·길이는 YouTube oEmbed 실측. 개념·실습 흐름은 영상 인용.

Chrome Status, 「WebMCP」 기능 항목, 확인일 2026-10-15. https://chromestatus.com/feature/5117755740913664 — 제안(proposal) 성격 요약 확인.

OMW ai_edu 보존: Chrome 공식 문서·W3C 초안 원문 raw(2026-10-14 수집)와 검증 summary. 원문 제시 계층에 따라 YouTube 원문은 본문의 공식 임베드로 제시했어요.

시각자료 출처

본문 이미지 2장(webmcp-tool-registration-1280.jpg, webmcp-todo-practice-1280.jpg): AI 생성 이미지(gpt-image-2, 2026-10-14 생성, Edu 자체 제작). 프롬프트·생성 기록은 프로젝트 폴더 `sources/image-sources.md` 보존. 신뢰 경계 HTML 다이어그램·표 2개: Editor_K 구성, 근거는 각 캡션에 표기한 공식 문서 절. 코드 블록: Chrome 공식 문서 공개 예시(2026-10-15 확인). YouTube 임베드: 원문 공식 임베드.

근거 수준 고지: WebMCP는 커뮤니티 그룹 초안이며 Chrome 구현은 오리진 트라이얼 단계예요. 이 글의 사실 관계는 위 공식 문서와 영상 확인 시점 기준이며, 이후 변경될 수 있어요.