Cloudflare가 WebMCP 개발자 프리뷰를 공개했다. 핵심은 Cloudflare를 사용하는 사이트 운영자가 대시보드에서 기능을 켜면, 브라우저 안의 AI 에이전트가 해당 사이트가 제공하는 도구를 발견하고 호출할 수 있게 한다는 것이다. 별도의 공개 API를 새로 만들거나 원본 서버의 애플리케이션 코드를 수정하지 않아도 된다는 점이 이번 발표의 가장 큰 특징이다.
다만 “어떤 웹사이트든”이라는 표현은 적용 범위를 정확히 나눠서 이해해야 한다. 이번 기능은 Cloudflare가 사이트 앞단에서 HTML 응답을 처리할 수 있다는 전제에 놓여 있다. 또한 WebMCP 자체가 실험 단계의 브라우저 표준이고 Chrome 146에서 실험적으로 제공되는 기능이므로, 일반 방문자와 모든 브라우저에서 곧바로 동일하게 작동한다고 보기는 어렵다. 실제 도입 여부는 Cloudflare 계정에서 기능이 노출되는지, 대상 도메인이 지원되는지, 방문자가 사용하는 브라우저와 에이전트가 WebMCP를 이해하는지를 함께 확인해야 한다.
기존 웹 자동화와 무엇이 다른가
지금까지 브라우저 에이전트는 사람에게 보이는 문장, 링크, 버튼, 입력창을 해석한 뒤 화면을 따라 움직이는 방식에 크게 의존했다. 페이지 구조가 바뀌거나 버튼 이름이 달라지면 자동화가 깨지기 쉽고, 에이전트가 탐색과 조작에 많은 토큰을 쓰는 문제도 있다. 크롤러가 콘텐츠를 외부 서버로 복사해 처리하는 방식은 사이트 방문과 출처 귀속이 약해질 수 있다는 문제도 있다.
WebMCP는 사이트가 에이전트에게 허용할 작업을 구조화된 도구 목록으로 제시하는 접근이다. 에이전트는 화면을 추측하며 클릭하는 대신 도구의 이름, 설명, 입력 형식을 읽고 필요한 작업을 호출할 수 있다. 사이트 운영자는 어떤 기능을 도구로 내놓을지 선택하고, 방문자는 자신의 브라우저와 세션 안에서 이를 사용한다. 웹페이지를 없애거나 사람용 화면을 대체하는 기술이라기보다, 같은 사이트에 에이전트용 인터페이스를 하나 더 제공하는 구조에 가깝다.
| 방식 | 에이전트가 사용하는 대상 | 도입 판단에서 볼 점 |
|---|---|---|
| 화면 기반 브라우저 자동화 | 문장, 링크, 버튼, 폼 | 화면 변경에 따른 실패율과 유지보수 비용 |
| 크롤링 또는 외부 처리 | 복사한 페이지와 콘텐츠 | 트래픽, 출처 표시, 데이터 이동 조건 |
| WebMCP | 사이트가 등록한 구조화된 도구 | 브라우저 지원, 도구 권한, 서버 측 검증과 운영 안정성 |
Cloudflare는 페이지에 무엇을 추가하나
사이트에서 WebMCP를 활성화하면 Cloudflare는 HTML 응답을 처리하는 엣지 구간에서 브리지 스크립트를 가리키는 한 줄을 삽입한다. 태그와 스크립트는 같은 출처에서 제공되며, 원본 서버의 코드에는 손대지 않는다. Cloudflare 설명에 따르면 정적 사이트와 단일 페이지 애플리케이션에서도 같은 방식으로 동작한다.
브리지는 브라우저에서 document.modelContext 인터페이스를 찾는다. 지원 인터페이스가 없으면 별도의 작업을 하지 않고 종료되므로 기존 페이지는 이전처럼 동작한다. 지원되는 브라우저에서는 운영자가 선택한 도구 팩을 하나의 목록으로 구성하고 각각을 WebMCP 도구로 등록한다.
현재 공개된 구조에서 도구 실행은 방문자의 브라우저 안에서 이뤄진다. 콘텐츠 자격 증명 도구는 이미지의 메타데이터 일부를 로컬에서 읽고, 사이트 MCP 서버 도구는 페이지에서 해당 사이트의 MCP 엔드포인트로 직접 요청한다. Cloudflare 서버를 거쳐 도구 결과를 다시 받아오는 구조는 아니지만, 브리지 코드 자체는 Cloudflare 엣지에서 제공된다. Cloudflare는 앞으로 브라우저만으로 처리하기 어려운 작업을 엣지 워커와 연결할 가능성도 설명했으므로, 이후 제공되는 팩은 현재와 데이터 흐름이 달라질 수 있다.
개발자 프리뷰에 포함된 두 가지 도구 팩
Content Credentials
Content Credentials 팩은 페이지의 이미지를 살펴보고 C2PA 관련 메타데이터를 읽는 도구를 제공한다. 여러 이미지를 훑어 자격 증명이 포함됐는지 요약하거나, 특정 이미지의 매니페스트에서 편집 이력, 표시된 작성자, 서명 인증서 등의 정보를 꺼낼 수 있다. 이미지 전체를 분석하는 대신 앞부분에 포함된 메타데이터 일부를 읽는 방식으로 설명돼 있다.
여기서 가장 중요한 제한은 읽기와 검증을 구분해야 한다는 점이다. 이번 구현은 자격 증명 내용을 해석해 보여주지만 암호학적으로 서명을 검증하지 않는다. 결과에도 서명 검증이 완료되지 않았다는 상태가 표시된다. 따라서 에이전트가 작성자나 생성 도구의 이름을 반환하더라도, 그것만으로 콘텐츠의 진위나 서명의 유효성이 입증됐다고 판단해서는 안 된다. 연구 자료나 보도 자료의 출처 확인에 사용한다면 별도의 검증 절차가 필요하다.
Site MCP Server
Site MCP Server 팩은 운영자가 이미 보유한 MCP 서버의 도구를 브라우저 에이전트에 연결한다. 기본 경로는 같은 출처의 /mcp이며, 설정을 통해 자체 MCP 서버 주소를 가리킬 수 있다. 브리지는 MCP 서버가 공개한 도구 목록을 확인한 뒤 각 도구를 WebMCP 인터페이스에 등록한다. 에이전트가 도구를 호출하면 페이지는 같은 출처로 요청을 보내고 방문자의 기존 세션을 사용한다.
이 방식은 검색, 계정별 조회, 예약이나 제출 같은 사이트 기능을 에이전트에 제공할 때 유용할 수 있다. 반면 기존 로그인 세션이 요청에 포함될 수 있다는 점은 보안 검토의 중심이 된다. 브라우저에 도구가 보인다는 사실을 권한 부여로 간주해서는 안 된다. MCP 엔드포인트는 각 호출마다 사용자의 인증 상태와 작업 권한을 다시 검사하고, 입력값 검증과 호출 제한, 감사 기록, 오류 처리 기준을 갖춰야 한다.
누가 먼저 검토할 만한가
- 문서나 검색 중심 사이트 운영자: 에이전트가 페이지 구조를 해석하지 않고 사이트가 정의한 검색 도구를 사용하게 만들 수 있는지 확인할 가치가 있다.
- 기존 MCP 서버를 운영하는 개발팀: 서버 도구를 브라우저 방문자의 세션과 연결했을 때 별도 API를 추가하는 것보다 유지보수가 줄어드는지 비교할 수 있다.
- 이미지 출처 정보를 다루는 연구자와 제작자: C2PA 메타데이터의 일괄 확인에는 활용 가능성이 있지만, 표시된 정보와 검증된 정보를 구분해야 한다.
- 브라우저 에이전트를 만드는 개발자: 화면 좌표나 DOM 선택자에 의존하는 자동화와 구조화된 도구 호출의 성공률, 토큰 사용량, 복구 가능성을 비교해 볼 수 있다.
반대로 현재 사용자가 WebMCP 지원 브라우저를 거의 사용하지 않거나, 사이트가 제공할 작업을 아직 명확히 정의하지 못했다면 우선순위는 낮다. 기존 MCP 서버가 없는 사이트에서 Site MCP Server 팩을 켠다고 업무 기능이 자동으로 만들어지는 것도 아니다. Cloudflare가 연결 계층을 제공하더라도 실제 도구의 의미, 권한, 결과 품질은 사이트 운영자가 설계해야 한다.
적용 범위와 비용은 따로 확인해야 한다
발표문은 기능을 개발자 프리뷰로 소개하고 대시보드의 Agent Readiness > Labs에서 도메인별로 활성화할 수 있다고 설명한다. 그러나 제공된 정보만으로는 계정 유형별 제공 범위, 지역 제한, 정식 출시 일정, 사용량 한도와 과금 조건을 확정할 수 없다. 실제 계정에서 설정 메뉴가 보이는지 확인하고, Cloudflare의 최신 제품 문서와 가격 정책을 적용 시점에 다시 살펴봐야 한다.
| 항목 | 확인할 질문 | 판단 기준 |
|---|---|---|
| 브라우저 호환성 | 주요 사용자의 브라우저와 에이전트가 WebMCP를 지원하는가? | 미지원 환경에서도 기존 페이지 기능이 정상적으로 유지돼야 한다. |
| 계정과 도메인 | 현재 Cloudflare 계정과 대상 도메인에 Labs 설정이 노출되는가? | 실제 운영 환경에서 활성화 가능해야 평가 의미가 있다. |
| 비용 | 프리뷰와 정식 제공 단계의 요금 및 사용량 조건은 무엇인가? | 화면 자동화 유지비나 자체 연동 비용보다 절감 효과가 커야 한다. |
| 데이터 흐름 | 각 도구가 브라우저, 자체 MCP 서버, Cloudflare 엣지 중 어디에서 처리되는가? | 민감한 자료가 예상하지 못한 처리 구간으로 이동하지 않아야 한다. |
| 권한 | 읽기, 쓰기, 결제, 제출처럼 영향이 다른 작업을 구분하는가? | 도구별 최소 권한과 서버 측 재검증이 가능해야 한다. |
| 운영 안정성 | 실험 표준이나 브리지 변경 시 도구 호출이 실패하면 어떻게 되는가? | 기존 사용자 흐름과 롤백 경로가 유지돼야 한다. |
보안 검토에서 놓치기 쉬운 부분
WebMCP는 에이전트가 사이트를 더 정확하게 사용할 수 있게 하지만, 도구를 공개하는 행위 자체가 새로운 호출 표면을 만든다. 특히 방문자의 세션을 이용하는 도구는 일반 페이지 요청과 같은 수준 이상의 검증이 필요하다. 읽기 전용 검색과 데이터를 변경하는 작업을 같은 권한으로 묶지 말고, 계정 변경이나 외부 전송처럼 되돌리기 어려운 작업은 사용자 확인 절차가 있는지 점검해야 한다.
- 에이전트에 등록되는 도구의 이름, 설명, 입력 스키마가 실제 권한 범위와 일치하는지 확인한다.
- MCP 서버가 도구 이름과 인수를 신뢰하지 않고 서버에서 다시 검증하는지 확인한다.
- 로그인한 사용자가 접근할 수 없는 데이터가 도구 응답에 섞이지 않는지 계정별로 시험한다.
- 반복 호출, 대량 조회, 잘못된 입력에 대한 제한과 오류 응답을 점검한다.
- 콘텐츠 보안 정책이나 기존 엣지 변환 규칙이 브리지 삽입과 충돌하지 않는지 확인한다.
- 기능을 끄면 삽입된 브리지와 등록 도구가 제거되고 기존 동작으로 돌아가는지 시험한다.
“사람이 통제권을 유지한다”는 방향은 사이트가 공개할 팩을 선택하고 방문자의 브라우저와 세션에서 도구가 실행된다는 구조에서 찾을 수 있다. 다만 모든 민감한 호출에 사용자 확인 화면이 자동 제공되는지는 별개의 문제다. 쓰기 작업을 연결하기 전에는 사용하는 브라우저 에이전트의 승인 방식과 MCP 서버의 권한 검사를 직접 확인해야 한다.
작게 시험하는 방법
- 실제 계정 변경이 없는 읽기 전용 도메인이나 테스트 환경을 선택한다.
- 한 가지 도구 팩만 활성화하고 페이지가 기존 브라우저에서 동일하게 작동하는지 확인한다.
- 지원 브라우저에서 노출되는 도구 목록과 입력 스키마를 기록한다.
- 정상 요청뿐 아니라 빈 값, 과도한 입력, 권한이 없는 계정, 만료된 세션으로 호출해 본다.
- 화면 기반 자동화와 비교해 성공률, 처리 시간, 수정 횟수, 토큰 사용 변화를 측정한다.
- 기능을 비활성화한 뒤 브리지와 도구 노출이 사라지는지 확인한다.
도입 판단은 기능을 켤 수 있는지보다 반복 작업을 실제로 줄이는지에 맞추는 편이 좋다. 문서 검색 한 건처럼 범위가 작은 작업에서 시작해 실패 원인과 복구 방법을 기록하면, 실험 표준이 바뀌더라도 영향을 파악하기 쉽다. 기존 API나 화면 자동화가 이미 안정적으로 작동한다면 즉시 전환할 필요는 없다. WebMCP가 페이지 변경에 따른 유지보수를 줄이고, 사용자의 권한을 보존하며, 결과를 더 예측 가능하게 만들 때 전환 가치가 생긴다.
출처와 검증
기능 구조, 개발자 프리뷰 범위, Chrome 146의 실험적 지원, 두 가지 도구 팩과 C2PA 검증 제한은 Cloudflare의 발표 내용을 기준으로 정리했다. 계정별 제공 여부, 가격, 사용량 제한과 이후 정식 기능의 데이터 처리 방식은 변경될 수 있으므로 실제 적용 시점의 대시보드와 공식 문서를 다시 확인해야 한다.