WebMCP란? AI가 버튼을 찾는 대신 웹 기능을 호출하는 방식

손잡이와 열쇠 구멍이 또렷하게 보이는 나무 문. 이해를 돕기 위한 AI 생성 개념 이미지입니다.

웹 에이전트가 화면의 파란 버튼을 보고 “검색일 것”이라고 추측하는 대신, 사이트가 검색 기능의 이름과 입력을 구조적으로 제공할 수 있다면 UI 변경에 덜 의존할 수 있습니다. WebMCP는 웹페이지가 브라우저 안에서 동작하는 에이전트에 이런 구조화된 도구를 노출하는 방식을 다루는 제안입니다.

다만 2026년 9월 기준 모든 브라우저에 배포된 확정 표준으로 보면 안 됩니다. 일반 사용자 화면을 유지하고, 읽기 전용 기능부터 점진적으로 추가하는 실험 후보로 보는 편이 정확합니다. WebMCP 도구를 제공한다고 해서 아무 MCP 호스트나 자동으로 연결되거나, 에이전트가 사이트를 방문하기 전에 도구를 발견하는 것도 아닙니다.

화면 자동화와 구조화된 호출의 차이

가상의 전시 검색 사이트를 비교해 보겠습니다.

화면 기반 에이전트	구조화된 웹 기능
DOM·텍스트·위치를 보고 버튼을 찾음	사이트가 searchExhibitions 기능을 알림
날짜 선택 UI를 조작	date, region 입력을 전달
화면 변경에 locator가 깨질 수 있음	도구 계약 변경을 별도로 관리
사람과 같은 결과 화면을 읽음	구조화된 결과를 받을 수 있음

구조화된 접점은 의미 추측을 줄일 수 있지만 결과 정확성을 자동 보장하지 않습니다. 화면 검색은 서울만 반환하고 도구는 전국을 반환한다면 두 경로가 다른 제품이 됩니다. 동일한 검증 규칙과 권한 경계를 재사용해야 합니다.

현재 문서가 말하는 지원 범위

Chrome WebMCP 문서는 JavaScript와 HTML 폼을 통해 페이지 기능을 도구로 제공하는 proposed web standard를 설명합니다. 문서는 2026년 8월 7일 갱신됐고 Chrome 149부터의 origin trial을 안내합니다. 로컬 개발은 chrome://flags/#enable-webmcp-testing 플래그 경로로 안내하지만, 이것은 안정 채널 전체 배포나 호환성 보장이 아닙니다. 공식 문서가 명시한 현재 한계에는 사람을 둔 로컬 브라우저 흐름 중심, 복잡한 인터페이스에서의 추가 작업, 사이트를 직접 방문해야 가능한 도구 발견이 포함됩니다.

따라서 다음 표현은 피해야 합니다.

• 모든 Chrome 사용자가 지금 사용 가능
• 모든 MCP 호스트가 그대로 연결 가능
• API 문법이 확정돼 변하지 않음
• WebMCP를 넣으면 검색 노출이나 접근성이 자동 개선
• WebMCP 도구를 등록하면 headless 환경과 모든 에이전트에서 동일하게 실행

지원 브라우저, origin trial 등록, 에이전트 구현과 문서 버전을 각각 확인해야 합니다.

선언적 방식과 명령형 방식

초기 공개 설명은 두 접근을 소개합니다.

• 선언적 API: 기존 HTML 폼의 필드와 제출 의미를 활용
• 명령형 API: JavaScript로 더 복잡한 도구 동작을 등록

단순 검색·필터처럼 기존 폼이 명확한 기능은 선언적 접근이 화면과 도구의 차이를 줄이기 쉽습니다. 선언적 폼은 도구 이름·설명과 입력 필드를 바탕으로 구조를 만들며, toolautosubmit을 쓰지 않으면 사용자가 최종 제출을 누르게 할 수도 있습니다. 여러 단계 상태, 비동기 진행, 복잡한 결과가 필요한 작업은 명령형 접근을 검토할 수 있습니다. 구체 문법과 API 표면은 제안 상태에서 바뀔 수 있으므로 현재 문서를 정본으로 삼아야 합니다.

첫 기능은 읽기 전용 검색이 좋습니다

초기 실험 후보:

기능: 공개 전시 검색
입력: 시작일, 종료일, 지역
출력: 제목, 장소, 공식 URL
권한: 로그인·결제·저장 없음

합격 기준은 다음처럼 만들 수 있습니다.

1. 같은 입력에서 일반 폼과 도구의 결과 ID가 일치
2. 잘못된 날짜와 미지원 지역을 같은 규칙으로 거부
3. WebMCP 미지원 브라우저에서도 폼이 정상 동작
4. 결과에 사용자별 비공개 데이터가 섞이지 않음
5. 도구 호출을 중단해도 페이지 상태가 손상되지 않음

이 글에서는 위 사이트를 구현하거나 origin trial에서 실행하지 않았습니다. 설계 예시입니다.

쓰기 기능에는 더 강한 계약이 필요합니다

예약, 결제, 메시지 발송, 삭제를 도구로 노출하면 화면 클릭보다 구조화됐다는 사실만으로 안전해지지 않습니다.

단계	필요한 확인
도구 발견	읽기·쓰기와 영향 범위 표시
입력	서버에서 허용값·대상 재검증
실행 전	가격·수신자·삭제 대상을 사용자에게 표시
실행	인증·인가·CSRF·중복 호출 방지
결과	성공 ID와 실제 상태 readback
실패	rollback 또는 재시도 안전성

Chrome의 보안 지침은 읽기 전용 도구에 readOnlyHint, 예약·송금·삭제 같은 되돌리기 어려운 작업에 consequentialHint, 사용자 생성·외부 데이터가 섞인 결과에 untrustedContentHint를 고려하도록 안내합니다. 이 힌트가 서버의 권한 검사나 사용자 확인을 대신하지는 않습니다. 다른 origin에 도구를 노출할 때는 허용 origin을 명시적으로 제한해야 하며, cross-origin iframe은 tools Permissions Policy 위임이 필요합니다.

모델의 도구 선택은 권한 부여가 아닙니다. 서버는 일반 UI 요청과 동일하거나 더 강한 인증·인가를 적용해야 합니다. 재시도될 수 있는 행동에는 idempotency와 감사 로그가 필요합니다.

점진적 향상으로 적용합니다

기존 폼과 서버 endpoint를 정본으로 유지하고 WebMCP를 추가 접점으로 붙이면 미지원 환경에서도 핵심 기능이 남습니다.

• 사람용 레이블과 오류 메시지를 유지
• 키보드·스크린리더 접근성을 그대로 검증
• 폼과 도구가 같은 validation을 사용
• 현재 페이지 상태에서 유효한 도구만 등록·해제
• 기능 플래그로 비활성화 가능
• 브라우저·에이전트별 관찰 로그 분리
• 제안 변경 시 contract test 재실행

Chrome의 best practices는 도구 하나에 한 기능만 두고, 겹치는 도구를 줄이며, 코드에서 입력을 엄격히 검증하고 의미 있는 오류를 반환하라고 권합니다. WebMCP가 있다고 접근성 검사를 생략해서는 안 됩니다. 사람용 UI와 에이전트용 접점은 서로 대체가 아니라 함께 유지할 수 있는 층입니다.

정리

WebMCP는 웹사이트가 기능의 의미와 입력을 브라우저 안의 에이전트에 구조적으로 제공하려는 제안입니다. 화면 추측을 줄일 수 있지만 지원 범위, 도구 발견, 권한, 입력 검증, 사용자 확인, UI와의 결과 일치를 별도로 시험해야 합니다. 현재는 일반 폼을 유지한 읽기 전용 기능부터 검토하는 편이 안전합니다.

자료 확인일은 2026년 9월 7일입니다. Chrome 공식 문서와 초기 공개 설명을 기준으로 작성했으며 origin trial 참여, 브라우저 호환성, 성능 또는 보안성을 직접 시험하지 않았습니다.