이것은 Google I/O Writing Challenge

에 대한 제출물입니다. Google I/O 2026에서 큰 발표는 쉽게 발견할 수 있었습니다: Gemini 3.5, Antigravity 2.0, 안드로이드 에이전트, AI 스튜디오 업그레이드, 그리고 AI로 소프트웨어를 만드는 새로운 방법이 많았습니다.

나 지속해서 돌아오는 발표는 훨씬 조용했습니다:

WebMCP.

Chrome 문서에서는 이를 Chrome 플래그를 통해 로컬에서 테스트할 수 있는 제안된 개방형 웹 표준으로 설명하고 있습니다.

하지만 그 아래에 있는 아이디어는 중요합니다.

웹사이트가 에이전트가 버튼과 양식의 의미를 추측하도록 강제하지 않고 구조화되고 타입화된 작업을 직접 노출한다면 어떨까요.

그것은 오늘 존재하는 도구와 비교했을 때 작아 보이지만요.Chrome DevTools MCP는 구글의 공식 MCP 서버로, 코딩 에이전트가 DevTools를 통해 크롬을 제어하고 검사할 수 있게 해줍니다.

두 가지를 모두 살펴보니, 제 생각은 간단합니다.

Chrome DevTools MCP는 에이전트가 이미 구축된 웹을 이해하는 데 도움을 줍니다. WebMCP는 에이전트가 추측 없이 사용할 수 있는 웹을 만들도록 요구합니다.

그 차이는 모든 웹 개발자에게 중요합니다.

현재 웹은 여전히 눈과 손을 위해 구축되었습니다

대부분의 웹 앱은 사용자가 픽셀을 보고 UI를 한 번 클릭씩 탐색하는 인간이라고 가정합니다

그 모델은 사람들에게는 작동하지만 에이전트에게는 훨씬 신뢰할 수 없습니다

대리인은 DOM을 검사하려고 시도할 수 있습니다. 접근성 트리를 사용할 수 있습니다. 스크린샷을 찍을 수 있습니다. 버튼을 클릭할 수 있습니다. 필드를 채울 수 있습니다. 하지만 앱이 더 명확한 의도를 노출하지 않는 한 대리인은 여전히 많은 것을 추론해야 합니다:

• 이 버튼은 파괴적인지 되돌릴 수 있는지요?
• 이 날짜 필드는 MM/DD/YYYY, YYYY-MM-DD, 또는 사용자 지정 피커 흐름을 기대하는가요?
• 표시된 가격이 최종인가요, 아니면 세금이 나중에 나타나나요?
• 이 양식이 즉시 제출되나요, 아니면 초안을 저장하나요?
• 이 비활성화된 버튼은 검증, 인증, 재고, 또는 자바스크립트 상태를 기다리고 있나요?

인간은 맥락으로 모호함을 처리하지만, 에이전트는 재시도, 취약한 규칙, 그리고 가끔 맹목적인 무의미함으로 모호함을 처리합니다.

WebMCP는 흥미로운 이유는 그것이 혼란을 원천에서 줄이려고 하는 데 있습니다.

WebMCP가 추가하는 것

Chrome WebMCP 문서화는 WebMCP를 웹 페이지가 구조화된 도구를 AI 에이전트에 공개하는 방법으로 설명합니다. 페이지는 JavaScript 함수를 등록하거나 HTML 양식을 주석 처리하여 에이전트가 사용 가능한 작업을 발견하고 입력 스키마를 이해하며 현재 브라우저 컨텍스트 내에서 해당 작업을 호출할 수 있게 합니다.

즉, 웹사이트는 다음과 같이 말할 수 있습니다.

// Conceptual example, not exact production code
registerTool("searchFlights", {
  description: "Search available flights",
  input: {
    origin: "string",
    destination: "string",
    date: "string",
    passengers: "number"
  }
});

그것은 "원본을 의미할 가능성이 있는 텍스트 상자를 찾고, 그 안에 입력하고, Tab을 누르고, 커스텀 날짜 선택기가 작동하는 것을 희망하고, 파란색 버튼을 클릭하는" 것과 다른 계약입니다.

공식 문서에서는 발견, JSON 스키마, 페이지 상태에 대한 지원을 언급합니다. 또한 지원 흐름, 여행 예약, 구조화된 양식, 날짜 선택기, 숨겨진 진단 작동 등의 예를 제공합니다.

중요한 단어는구조화된.

웹은 이미 API가 있습니다. 하지만 WebMCP는 백엔드 API가 아닙니다. 그것은 브라우저 컨텍스트에 살아 있습니다. 도구 호출은 사용자가 보는 동일한 UI를 업데이트할 수 있습니다. 이는 사용자를 루프에 유지하고 시각적 제품 경험을 보존하면서 에이전트에게 원시 작동보다 더 신뢰할 수 있는 경로를 제공합니다.

왜 Chrome 개발자 도구 MCP와 비교했는가

Google I/O 개발자 키노트에서 WebMCP와 에이전트용 Chrome 개발 도구를 동일한 더 넓은 섹션에 배치했습니다: "에이전트 시대에 웹 개발을 재정의합니다." 그 짝은 유용합니다.

에이전트용 Chrome 개발 도구는 코딩 에이전트가 크롬과 상호작용할 수 있도록, 페이지를 검사하고, 런타임 동작을 디버깅하며, 실제 사용자 경험을 에뮬레이션하고, 검토를 실행하며, 콘솔 메시지를 검사하고, 네트워크 요청을 분석하고, 접근성 트리 스냅샷을 촬영하고, 성능 워크플로우를 실행할 수 있는 능력을 부여합니다.

GitHub README입니다.chrome-devtools-mcp는 이를 MCP 서버로 설명하며, Antigravity, Claude, Cursor, Copilot, Codex와 같은 에이전트가 실시간 크롬 브라우저를 제어하고 검사할 수 있도록 허용한다. 도구 참조에는 탐색, 입력 자동화, 에뮬레이션, 네트워크 검사, 콘솔 검사, 스크린샷, 접근성 스냅샷, Lighthouse 검토, 성능 추적, 메모리 도구, 확장 도구, 실험적인 WebMCP 도구가 포함된다.

그래서 많은 권한이다.

하지만 그것은 다른 레이어입니다.

Chrome 개발 도구 MCP는 주로 개발자 측 디버깅 및 자동화 도구입니다.

WebMCP는 사이트 측 기능 계약입니다.

하나는 에이전트가 무엇이 있는지 검사할 수 있게 합니다. 다른 하나는 사이트가 무엇을 할 수 있는지 선언할 수 있게 합니다.

제 작은 테스트

직접 확인하고 싶었는데, "AI는 모든 것을 변화시킬 것"이라는 글을 또 쓰지 않고 싶었습니다.

WebMCP 문서는 명령형과 선언형 구현을 모두 포함하는 데모를 가리킵니다:

• WebMCP zaMakerWebMCP 명령형 API를 사용합니다.
• 여행 데모도 WebMCP 명령형 API를 사용합니다.
• Le Petit Bistro은 WebMCP Declarative API를 사용합니다.

나는 WebMCP zaMaker로 시작했습니다. 명령형 버전은 핵심 아이디어를 매우 명확하게 보여줍니다. 에이전트에게 피자 제어를 픽셀로부터 추론하도록 요청하는 대신, 페이지는 검사기가 발견할 수 있는 명시적인 도구를 등록합니다.

나는 크롬에서 WebMCP 테스트를 활성화하고, zaMaker 데모를 열고, WebMCP - Model Context Tool Inspector를 사용했습니다. 확장 프로그램.

이 확장 프로그램은 여러 페이지 정의 도구를 노출시켰습니다. 예를 들어:

• add_topping
• manage_pizza
• remove_topping
• set_pizza_size
• set_pizza_style

그것이 내게 와닿은 부분입니다. 이것들은 "좌표 X에서 클릭"이나 "입력 Y에 입력"과 같은 일반적인 브라우저 작동과는 다릅니다. 이것들은 페이지에 노출된 제품 수준의 기능입니다.

예를 들어, 디버거는 add_topping를 보여주었는데, 스키마에는 topping 열거형과size 열거형입니다. 또한 set_pizza_size를 구조화된 size 입력과 함께 보여주었으며, 올바른 크기를 추론하는 데 도움이 될 수 있는 number_of_persons 필드도 포함했습니다.

그런 다음 저는 인спект어에 자연어 프롬프트를 사용했습니다.

add pizza with large toppings

인спект어는 이를 도구 호출로 번역했습니다.

{
  "size": "Large",
  "topping": "🍕"
}

그런 다음 저는 다음을 시도했습니다:

make the pizza extra large

확장 프로그램 이름은:

{
  "size": "Extra Large"
}

페이지는 피자 상태를 변경하여 응답했습니다.

그 작은 데모는 문서만으로는 더 명확한 차이를 보여줬습니다. 브라우저 자동화 에이전트는 피자 빌더를 클릭할 수 있습니다. WebMCP에 알리지 못하는 페이지 대신, "이 제품이 지원하는 작업은 이것입니다, 허용되는 매개변수는 이것이며, 한 작업을 호출했을 때 일어난 일은 이것입니다"라고 말할 수 있습니다.

대조적으로, Chrome 개발 도구 MCP는 개발자 측면의 렌즈처럼 느껴졌습니다. 이는 페이지를 검사하고 접근성 트리를 읽고 콘솔 출력을 보고 상호작용을 자동화하며 에이전트가 이미 브라우저에 렌더링된 내용을 디버깅하는 데 도움을 줄 수 있습니다.

그것은 강력하지만 여전히 페이지를 외부에서 보고 있습니다. zaMaker 데모는 이 아이디어의 다른 측면을 보여주었습니다: 페이지 자체는 에이전트가 사용할 수 있도록 일부 의도적인 작동을 발행할 수 있습니다.

그래서 제 실제 결과는 다음과 같았습니다:

Chrome 개발자 도구 MCP는 오늘날 페이지를 검사하고 테스트하는 데 실용적입니다. WebMCP 검사기는 페이지 자체가 제품 수준 도구를 노출할 때 어떤 변화가 있는지 보여줍니다.

WebMCP 대 Chrome 개발자 도구 MCP

이제 제가 생각하는 가장 깨끗한 차이점에 대한 방법은 다음과 같습니다:

어귀가 체크아웃 페이지가 왜 깨졌는지를 디버깅하고 있다면, Chrome DevTools MCP가 올바른 도구입니다

대리인이 여행을 예약하거나 지원 요청을 제출하거나 대시보드를 구성하거나 앱 내에서 다단계 워크플로우를 완료하려고 할 때, WebMCP는 더 흥미로운 장기적인 해답입니다.

왜 "AI가 버튼을 클릭할 수 있다"가 더 큰 문제입니다

WebMCP가 등장하기 전에 기본 브라우저-대리인 경로는 이렇게 보였습니다:

1. 페이지를 확인하세요.
2. 사용자의 다음 작업을 추측하세요.
3. 클릭하거나 타이핑하세요.
4. 결과를 관찰하세요.
5. 틀리면 다시 시도하세요.

그것은 작동할 수 있지만, 취약합니다. 또한 느리고 비쌉니다. 그 이유는 각 단계가 모델 추론, 시각 분석, DOM 해석, 또는 둘 다를 추가하기 때문입니다.

WebMCP는 다른 경로를 제안합니다.

1. 사이트의 사용 가능한 도구를 발견하세요.
2. 사용자의 목표와 일치하는 도구를 선택하세요.
3. 타입된 매개변수 전송.
4. 사이트가 시각적 브라우저 컨텍스트에서 작동을 실행하도록 허용.
5. 구조화된 출력 또는 명확한 오류 반환.

이는 API에 더 가깝지만, 사용자가 여전히 제품을 보고 있음.

이것이 왜 WebMCP가 중요하다고 생각하는 이유입니다. 이것은 에이전트를 더 강력하게 만드는 것뿐만 아니라, 책임을 애플리케이션 개발자에게 다시 돌리는 것에 관한 것입니다. 에이전트가 안전하고 신뢰성 있게 행동하려면, 우리는 픽셀로부터 모든 워크플로우를 역공학하는 것을 할 수 없습니다.

우리는 의도를 드러내야 합니다.

WebMCP가 전 세계에 퍼지기 전에 개발자들이 할 수 있는 일

우리 대부분은 내일 생산 WebMCP 흐름을 배송할 수 없습니다. 브라우저 지원이 늦었고, 제안안은 여전히 변경 중입니다.

하지만 인간과 에이전트 모두 이해하기 쉬운 사이트를 시작할 수 있습니다.

이것에서 가져온 실용적인 체크리스트는 다음과 같습니다.

• 커스텀 위젯 전에 의미론적 HTML을 사용하세요.
• 중요한 버튼과 양식을 접근성 트리에서 명확하게 만드세요.
• 입력에 안정적인 이름과 레이블을 부여하세요.
• 중요한 상태를 시각적 스타일링에만 숨기지 마세요.
• 파괴적인 작업은 명시적인 확인 후에만 수행하세요.
• "미리보기", "임시저장", "제출", "구매" 프로세스를 명확히 분리하세요.
• 유효성 검사 오류를 기계용으로 읽을 수 있도록하고 사람용으로 읽을 수 있도록 만드세요.
• 브라우저 자동화, 접근성 스냅샷, 그리고 Lighthouse를 사용하여 중요한 흐름을 테스트합니다.
• 나중에 구조화된 도구가 필요할 앱 작업을 고려합니다.

WebMCP용 제품을 준비한다면, 모든 버튼을 도구로 노출하지 않을 것입니다. 가장 혼란스러움을 유발하는 몇 가지 워크플로우부터 시작할 것입니다.

• 검색
• 구매 확인
• 예약
• 지원 티켓 생성
• 반품/환불 시작
• 대시보드 필터링
• 진단
• 계정 설정 변경

이것들은 에이전트가 UI를 통해 추측하면서 실제 사용자의 고통을 만들 수 있는 장소입니다.

보안 질문

여기에는 명백한 위험성이 있습니다: 웹사이트가 에이전트에게 작업을 노출하면, 나쁜 도구 설계는 나쁜 작업을 더 쉽게 만들 수 있습니다.

그래서 웹MCP 모델이 모든 사이트를 맹목적인 백엔드 API로 바꾸지 않고 브라우저 컨텍스트에 작업을 유지한다는 점이 마음에 듭니다. 민감한 작업은 여전히 시각적 UI, 사용자 확인, 페이지 수준 상태가 필요할 수 있습니다.

하지만 개발자들은 자기 규율이 필요합니다.

좋은 WebMCP 도구는 다음과 같은 특징을 가져야 합니다:

• узкая цель
• 명확한 이름
• 엄격한 스키마
• 유용한 오류 메시지
• 투명한 실행
• 불가역적인 작업에 대한 확인
• 미묘한 부작용 없음

목표는 "대리인이 무엇이든 할 수 있도록 하라"가 되어서는 안 됩니다.

목표는 "대리인이 추측을 줄여 올바른 일을 해낼 수 있도록 하라"여야 합니다.

제 의견

Chrome 개발 도구 MCP는 웹 개발자들이 지금 사용할 수 있는 도구처럼 느껴집니다.

WebMCP는 웹 개발자들이 다음에 설계해야 할 수업처럼 느껴집니다.

그래서 저는 그것이 Google I/O 2026에서 더 중요한 웹 발표 중 하나라고 생각합니다. 그것은 변화를 가리키고 있습니다:

대리인이 더 나은 스크래핑 도구로서 작용합니다

수신:

агенты를 구조화된 웹 기능의 최상위 사용자로

그 변화는 어제 오늘에 일어나지 않을 것입니다. 브라우저 지원, 표준 작업, 개발자 도구, 보안 패턴, 그리고 많은 현실 세계 테스트가 필요합니다.

하지만 방향은 명확합니다. 대리인이 우리 대신 웹을 사용하려면, 웹 애플리케이션은 시각적으로 사용 가능한 것 이상이어야 합니다.

그들은 이해 가능해야 합니다.

그들은 검사 가능해야 합니다.

그리고 결국, 그들은 대리인 준비가 되어 있어야 합니다.

자원

• WebMCP 문서
• WebMCP 강제 API
• 에이전트용 Chrome 개발 도구
• GitHub의 ChromeDevTools/chrome-devtools-mcp
• Google I/O 2026 개발자 키노트 요약
• GoogleChromeLabs WebMCP 도구 및 데모