Microsoft·Google WebMCP 해설: 브라우저 에이전트 시대에는 화면 자동화보다 사이트가 노출할 도구 경계를 먼저 설계해야 하는 이유

발행일: 2026-06-24 | 카테고리: ai뉴스

1. 한 줄 문제 정의

핵심 요약: 브라우저 에이전트가 보편화되면, 웹사이트는 더 이상 사람 눈에 보이는 화면만 설계해서는 부족합니다.

지금의 브라우저 자동화는 대체로 화면을 읽고, 버튼을 찾고, 클릭을 흉내 냅니다. 이 방식은 데모에는 좋아 보이지만 실제 서비스에서는 깨지기 쉽습니다. 버튼 문구가 바뀌거나, 모달이 하나 더 뜨거나, 접근성 라벨이 빠지면 에이전트는 같은 일을 엉뚱하게 수행할 수 있습니다.

WebMCP가 겨냥하는 현실 문제는 바로 이 지점입니다. 웹사이트가 에이전트에게 “여기서 검색할 수 있다”, “이 상품 가격을 조회할 수 있다”, “이 예약 변경은 사용자 확인이 필요하다”처럼 기능을 구조화해서 알려주자는 제안입니다. 적용 범위는 브라우저 안에서 AI 에이전트가 사이트 기능을 호출해야 하는 검색, 커머스, 예약, SaaS, 관리자 도구입니다. 반대로 단순 소개 페이지나 외부 실행이 전혀 없는 블로그에는 아직 과합니다.

2. 먼저 결론

핵심 요약: WebMCP는 “AI용 SEO 태그”가 아니라, 사이트 기능을 에이전트에게 맡길 때 필요한 실행 계약입니다.

제 판단은 분명합니다. 2026년에 WebMCP를 바로 전면 도입할 팀은 많지 않습니다. 아직 W3C Community Group Draft 단계이고, Chrome과 Edge의 origin trial 중심으로 검증되는 중이기 때문입니다. 하지만 제품팀과 프론트엔드팀은 지금부터 준비해야 합니다. 이유는 단순합니다. 브라우저 에이전트가 실제 사용자의 로그인 세션 안에서 행동하는 순간, 사이트는 “클릭 가능한 UI”뿐 아니라 “호출 가능한 도구”도 제품 표면으로 관리해야 합니다.

지금 맞는 팀은 폼, 검색, 필터, 장바구니, 예약, 티켓 생성처럼 반복 액션이 많고 브라우저 에이전트 유입을 실험하려는 서비스입니다. 아직 관찰만 해도 되는 팀은 회원 정보 변경, 결제, 외부 발송처럼 실패 비용이 큰 작업만 있는 서비스입니다. 그런 팀은 WebMCP 구현보다 먼저 승인·철회·감사 로그 설계를 해야 합니다.

3. 핵심 구조 분해

핵심 요약: WebMCP는 웹페이지, 브라우저, 에이전트 사이에 “도구 목록”을 놓는 구조입니다.

초보 개발자 기준으로 쉽게 말하면, 기존 웹 UI는 사람이 읽는 메뉴판입니다. WebMCP는 에이전트가 읽을 수 있는 주문서입니다. 메뉴판을 보고 사람이 직접 주문할 수도 있지만, 주문서에는 “상품 ID는 문자열”, “수량은 숫자”, “취소는 사용자 확인 필요” 같은 규칙이 더 명확하게 적힙니다.

구조는 네 층으로 보면 쉽습니다.

1. 사이트 층: 웹 앱이 HTML 폼이나 JavaScript 함수로 실제 기능을 갖고 있습니다. 검색, 필터, 견적 계산, 예약 변경 같은 기능입니다.
2. 도구 등록 층: 사이트가 navigator.modelContext 같은 API를 통해 이름, 설명, 입력 스키마, 실행 함수를 등록합니다.
3. 브라우저 중재 층: Chrome이나 Edge 같은 브라우저가 이 도구를 에이전트에게 노출하고, origin과 사용자 세션 경계를 관리합니다.
4. 에이전트 층: Gemini in Chrome 같은 브라우저 내 에이전트가 도구를 발견하고, 사용자의 요청에 맞는 도구 호출을 선택합니다.

핵심은 “웹사이트가 MCP 서버를 새로 운영한다”가 아닙니다. 브라우저가 중간 다리 역할을 하고, 사이트는 자신의 페이지 안에서 호출 가능한 기능을 선언하는 쪽에 가깝습니다.

4. 설계 의도 해설

핵심 요약: WebMCP의 설계 의도는 에이전트가 화면을 추측하지 않게 만드는 것입니다.

브라우저 에이전트가 DOM을 긁거나 클릭을 흉내 내는 방식은 인간 UI에 과하게 의존합니다. 사람에게 좋은 UI와 에이전트에게 안정적인 실행 인터페이스는 다릅니다. 예를 들어 사람은 “할인 적용” 버튼을 보고 맥락을 이해하지만, 에이전트는 그 버튼이 쿠폰 적용인지, 결제 확정인지, 프로모션 조회인지 헷갈릴 수 있습니다.

WebMCP는 이 불확실성을 줄이기 위해 도구 이름, 자연어 설명, 입력 스키마, 실행 결과를 분리합니다. 얻는 것은 안정성입니다. 포기하는 것은 숨겨진 자동화의 자유입니다. 사이트가 도구를 명시적으로 노출해야 하므로, “에이전트가 알아서 화면을 다 조작하게 하자”는 접근보다 초기 설계 비용이 생깁니다.

하지만 저는 이 비용이 필요하다고 봅니다. 에이전트가 사용자의 로그인 세션을 공유하는 순간, 실수는 단순 오답이 아니라 실제 변경으로 이어질 수 있습니다. 따라서 WebMCP의 가치는 기능 노출보다 “어떤 기능은 노출하지 않을지”를 결정하게 만든다는 데 있습니다.

5. 근거 및 비교

핵심 요약: WebMCP의 진짜 비교 대상은 MCP 서버가 아니라 DOM 스크래핑, 전용 API, 접근성 기반 자동화입니다.

2026년 6월 기준 근거는 세 가지입니다. 첫째, W3C Web Machine Learning Community Group의 WebMCP 초안은 Draft Community Group Report 상태입니다. 둘째, Chrome은 WebMCP를 Chrome 149 이후 origin trial로 실험하는 흐름이고, Edge도 별도 origin trial을 공개했습니다. 셋째, 주요 구현 설명들은 HTML 폼을 선언적으로 노출하는 방식과 JavaScript 함수를 명령형으로 등록하는 방식을 함께 다룹니다.

6. 실제 동작 흐름 / 단계별 실행 방법

핵심 요약: 처음부터 결제나 계정 변경을 노출하지 말고, 읽기 전용 도구부터 작게 시작해야 합니다.

1. 에이전트에게 맡길 액션을 분류합니다. 조회 전용, 초안 생성, 사용자 확인 후 변경, 절대 자동화 금지로 나눕니다.
2. 첫 도구는 읽기 전용으로 고릅니다. 예를 들어 searchDocs, getProductPrice, filterEvents처럼 실패해도 데이터가 바뀌지 않는 기능이 좋습니다.
3. 입력 스키마를 작게 만듭니다. 문자열 하나로 모든 것을 받지 말고, productId, dateRange, region처럼 필드를 나눕니다.
4. 민감 액션은 사용자 확인을 요구합니다. 예약 취소, 결제, 개인정보 변경, 외부 발송은 에이전트 단독 실행이 아니라 브라우저 확인 UI를 거쳐야 합니다.
5. 호출 로그를 남깁니다. 도구명, 입력값 요약, 사용자 확인 여부, 실행 결과, 실패 이유를 저장해야 장애 분석이 가능합니다.
6. 일반 UI fallback을 유지합니다. WebMCP가 없어도 사람은 기존 폼과 버튼으로 같은 일을 할 수 있어야 합니다.

if ('modelContext' in navigator) {
  navigator.modelContext.registerTool({
    name: 'searchDocs',
    description: 'Search public help documents by keyword',
    inputSchema: {
      type: 'object',
      properties: {
        query: { type: 'string', description: 'Search keyword' }
      },
      required: ['query']
    },
    handler: async ({ query }) => {
      return await window.helpCenter.search(query);
    }
  });
}

위 예시는 의도적으로 읽기 전용입니다. 이 정도부터 시작해야 도구 선택 실패가 실제 고객 피해로 이어지지 않습니다.

7. 실수/함정(Pitfalls)

핵심 요약: WebMCP에서 가장 위험한 실수는 “에이전트가 이해하겠지”라고 믿는 것입니다.

• 함정 1: 도구 설명을 마케팅 문구처럼 쓰는 것
  예방: “최고의 상품을 찾아줍니다”가 아니라 “상품 ID와 지역을 받아 현재 판매 가능 여부를 반환합니다”처럼 쓰십시오.
  복구: 잘못 호출된 로그를 기준으로 설명과 스키마를 더 좁힙니다.
• 함정 2: 변경 작업을 확인 없이 노출하는 것
  예방: 결제, 취소, 삭제, 외부 전송은 반드시 사용자 확인 단계를 둡니다.
  복구: 문제 발생 시 해당 도구를 unregister하거나 origin trial 토큰을 회수하고, 로그로 피해 범위를 확인합니다.
• 함정 3: 기존 UI 접근성을 방치하는 것
  예방: WebMCP는 접근성의 대체재가 아닙니다. 라벨, role, 오류 메시지, 키보드 흐름을 함께 정리해야 합니다.
  복구: 에이전트 실패가 많은 화면은 WebMCP보다 먼저 폼 구조와 접근성 라벨을 고칩니다.
• 함정 4: 모든 기능을 도구로 노출하는 것
  예방: 사용 빈도와 실패 비용 기준으로 상위 5개 도구만 먼저 등록합니다.
  복구: 호출률이 낮거나 실패 비용이 큰 도구는 비활성화하고 read-only 대체 도구로 낮춥니다.

8. 강점과 한계

핵심 요약: WebMCP는 브라우저 에이전트 친화성을 높이지만, 아직 범용 배포 표준으로 단정하면 이릅니다.

강점은 명확합니다. 사이트가 자신의 기능을 구조적으로 설명하므로 에이전트가 화면을 덜 추측합니다. 브라우저 origin과 사용자 세션 안에서 동작하므로, 별도 API 키를 사용자에게 맡기는 방식보다 자연스럽습니다. HTML 폼 기반 선언 방식은 기존 사이트에도 낮은 비용으로 붙일 수 있습니다.

한계도 큽니다. 2026년 6월 현재 WebMCP는 최종 표준이 아닙니다. 브라우저 지원은 origin trial 중심이고, Gemini in Chrome 같은 특정 에이전트 경험에 먼저 묶여 있습니다. 또한 도구 호출 입력은 여전히 신뢰할 수 없는 입력입니다. 사이트는 에이전트가 보낸 값도 일반 사용자 입력처럼 검증해야 합니다.

따라서 지금의 추천은 “전면 도입”이 아니라 “AI-ready action inventory를 만들고, 읽기 전용 도구 1~2개로 실험”입니다. 민감 업무가 많은 금융, 의료, 공공 서비스는 표준 안정화와 감사 로그 체계가 먼저입니다.

9. 더 깊게 공부할 포인트

핵심 요약: WebMCP를 제대로 이해하려면 MCP 자체보다 브라우저 보안 모델과 폼 설계를 같이 봐야 합니다.

• W3C 초안: API 이름, 보안 고려사항, 도구 등록 모델이 바뀔 수 있으므로 원문을 주기적으로 확인하십시오.
• Chrome·Edge origin trial: 실제 배포 가능 버전, 토큰 등록 방식, 만료일을 확인해야 합니다.
• 브라우저 origin 보안: 같은 사용자 세션 안에서 도구가 실행될 때 쿠키, CSRF, 권한 확인이 어떻게 맞물리는지 봐야 합니다.
• 접근성 폼 설계: WebMCP가 없더라도 명확한 폼 구조는 사람과 에이전트 모두에게 도움이 됩니다.
• 감사 로그 설계: 에이전트 호출은 사용자의 직접 클릭과 구분해 저장해야 원인 분석이 됩니다.

10. 실행 체크리스트 + 작성자 관점

핵심 요약: WebMCP는 기능 추가가 아니라 제품의 실행 경계를 다시 그리는 일입니다.

• 에이전트에게 노출할 액션을 조회, 초안, 확인 후 변경, 금지로 분류했는가?
• 첫 실험 도구가 읽기 전용이며 실패 비용이 낮은가?
• 도구 입력 스키마가 넓은 문자열 하나가 아니라 검증 가능한 필드로 나뉘었는가?
• 민감 액션에 사용자 확인, 취소, 재시도, 감사 로그가 있는가?
• WebMCP 미지원 브라우저에서도 기존 UI가 그대로 작동하는가?
• 도구 호출 로그에 도구명, 입력 요약, 사용자 확인 여부, 결과 코드가 남는가?
• origin trial 만료와 스펙 변경 시 비활성화할 플래그가 있는가?

Definition of Done: 읽기 전용 WebMCP 도구 1개가 origin trial 환경에서 정상 호출되고, 실패·미지원·사용자 거부 케이스가 기존 UI fallback과 감사 로그로 모두 확인되면 1차 검증 완료로 봅니다.

저라면 WebMCP를 “올해 반드시 붙여야 할 SEO 기능”으로 팔지 않겠습니다. 대신 브라우저 에이전트가 들어올 미래를 대비해 사이트의 주요 액션을 정리하는 계기로 삼겠습니다. 특히 커머스와 SaaS는 지금부터 액션 목록, 권한 경계, 사용자 확인 정책을 문서화해야 합니다. 반대로 표준이 안정화되기 전에 결제·삭제·개인정보 변경을 곧장 노출하는 것은 비추천입니다.

참고자료

• W3C Web Machine Learning Community Group: WebMCP Draft Community Group Report (2026-06-17 확인)
• GitHub: webmachinelearning/webmcp specification repository (2026-06-24 확인)
• InfoWorld: WebMCP API extends web apps to AI agents (2026-06 확인)
• Microsoft Edge Origin Trials: WebMCP (2026-06-24 확인)
• NoHacks: What is WebMCP? (2026-06-09 업데이트)