WebMCP는 Google I/O 2026에서 가장 중요한 발표일지도 모릅니다

몇 년마다 한 번씩, 제품처럼 보이지만 실제로는 프로토콜 (Protocol)인 기술이 등장합니다. 그런 일이 발생하면 제품은 잊히고 프로토콜은 인프라 (Infrastructure)가 됩니다. Google I/O 2026에는 그런 순간 중 하나가 있었습니다. 다만 그 순간이 그에 걸맞게 다뤄지지 않았을 뿐입니다.

모델들은 인상적이었습니다. Gemini 3.5 Flash는 이전 모델보다 4배 더 빠릅니다. Antigravity 2.0은 에이전트 오케스트레이션 (Agent Orchestration)을 실제로 배포 가능한 수준처럼 느껴지게 만듭니다. AI Studio는 이제 클릭 한 번으로 Cloud Run에 배포할 수 있습니다. 이 중 건축학적으로 놀라운 것은 없었습니다. 하지만 개발자 세션 속에 묻혀 있던 다른 무언가가 있었습니다. 바로 브라우저 기반 AI 에이전트 (AI Agents)에게 구조화된 도구 (Structured Tools)를 노출하기 위해 제안된 개방형 표준인 WebMCP입니다.

이것은 진지하게 살펴볼 가치가 있습니다.

모두가 이미 알고 있는 실패 모드

만약 당신이 Selenium 자동화를 6개월 이상 유지보수해 본 적이 있다면, WebMCP가 해결하려는 문제를 이미 이해하고 있을 것입니다.

자동화는 제품 팀이 결제 페이지를 재설계하기 전까지는 잘 작동합니다. 그러다 셀렉터 (Selector)가 깨집니다. 당신은 이를 수정합니다. 3주 후 로그인 흐름이 변경됩니다. 당신은 다시 수정합니다. 당신은 무언가를 엔지니어링하고 있는 것이 아닙니다. 당신은 결코 정지 상태로 설계되지 않은 UI를 상대로 영구적인 후방 방어전을 수행하고 있는 것입니다. 자동화가 취약한 이유는 추론 (Inference)에 기반하기 때문입니다. 당신의 코드는 프레젠테이션 (Presentation)을 읽음으로써 의도를 추측하고 있습니다.

1세대 브라우저 AI 에이전트들은 정확히 이 문제를 더 큰 규모와 더 높은 위험도를 가지고 겪고 있습니다. 그들은 버튼, 양식, 내비게이션 메뉴를 볼 수 있고 클릭할 수도 있지만, 언제나 단 한 번의 재설계만으로 실패할 위기에 처해 있습니다. 그들이 인간의 행동을 모방하는 이유는 웹이 그들에게 대안을 제공한 적이 없기 때문입니다.

오늘날 에이전트(Agent)를 통해 항공권을 예약하는 상황을 상상해 보십시오. 에이전트는 출발지 입력란, 날짜 선택기, 좌석 선택기, 결제 버튼을 시각적으로 탐색합니다. 모든 재설계(Redesign)는 워크플로우(Workflow)를 깨뜨릴 위험을 수반합니다. WebMCP 환경에서는 항공사가 예약 프로세스 자체를 구조화된 기능(Structured capability)으로 노출할 수 있습니다: 목적지, 날짜, 승객 수, 좌석 선호도, 결제 승인 등 말입니다. 에이전트는 인터페이스를 탐색하는 것을 멈추고, 그 밑에 있는 시스템과 상호작용하기 시작합니다.

WebMCP가 바로 그 대안입니다.

이 표준은 웹 개발자가 구조화된 도구들 — JavaScript 함수, 타입이 지정된 매개변수(Typed parameters), 폼 상호작용(Form interactions) — 을 기계가 읽을 수 있는 기능(Machine-readable capabilities)으로 노출할 수 있게 해줍니다. 에이전트가 DOM을 파싱하여 "이것은 아마도 검색창일 것이다"라고 추론하는 대신, 사이트는 단순히 다음과 같이 선언합니다: 여기 검색 함수가 있고, 여기 입력값이 있으며, 여기 반환값이 있다고 말입니다. 표준적인 상호작용에는 선언적(Declarative)이며, 런타임 JavaScript가 필요한 모든 것에는 명령적(Imperative)입니다. Chrome의 실험적 오리진 트라이얼(Origin trial)은 Chrome 149에서 시작됩니다.

즉각적인 이점은 신뢰성(Reliability)입니다. 하지만 그것이 흥미로운 부분은 아닙니다.

표면 아래에서 일어나는 변화

웹사이트는 항상 가시성(Visibility)을 중심으로 설계되어 왔습니다. 인간이 무언가를 보고 조작할 수 있다면 웹은 성공한 것이었습니다. 그 가정은 너무나 깊게 뿌리박혀 있어 보이지 않을 정도였습니다. 인터페이스는 프레젠테이션 레이어(Presentation layer)였고, 그것을 제대로 보이게 만드는 것이 업무의 전부였습니다.

WebMCP는 다른 가정을 도입합니다: 시스템이 운영상 유용하기 위해 반드시 시각적으로 탐색 가능할 필요는 없을 수도 있다는 것입니다. 인터페이스는 더 이상 주로 프레젠테이션 레이어에 머물지 않고, 기능 표면(Capability surface)이 되기 시작합니다.

이것은 중대한 돌연변이입니다.

구조화된 예약 기능을 노출하는 항공사 사이트는 더 이상 단순히 당신이 방문하는 장소가 아닙니다. 그것은 에이전트가 직접 호출할 수 있는 서비스가 됩니다. 웹사이트와 API 사이의 구분이 개발자뿐만 아니라 웹 자체의 프로토콜 수준에서 모호해지기 시작합니다.

이러한 변화에는 역사적 전례가 있습니다.

RSS는 웹 콘텐츠를 기계가 읽을 수 있는 형태(machine-readable)로 만들었습니다. 피드 리더(feed reader)는 블로그를 스크래핑(scraping)하여 기사 제목이 어디서 끝나고 사이드바가 어디서 시작되는지 추측할 필요가 없었습니다. 사이트가 단순히 구조를 직접 노출했기 때문입니다. RSS는 결국 소비자 기술로서 몰락했지만, 구조화된 신디케이션(syndication)이 스크래핑보다 낫다는 그 아이디어는 현대 콘텐츠 API의 기초가 되었습니다.

WebMCP는 RSS가 콘텐츠에 했던 일을 액션(actions)에 대해 수행합니다.

이 차이는 엄청나게 중요합니다.

콘텐츠 신디케이션은 수동적입니다. 기계는 인간이 작성한 것을 읽습니다. 액션 노출(action exposure)은 능동적입니다. 기계는 실제 세계에 영향을 미치는 결과를 수반하며 사용자를 대신하여 작업을 수행합니다. "읽을 수 있는(readable)" 상태에서 "실행 가능한(actionable)" 상태로의 도약은 웹 자체의 존재론(ontology)을 변화시킵니다.

이것이 바로 Google이 조용히 구축해 나가고 있는 방향입니다.

Antigravity 2.0은 에이전트(agents)를 오케스트레이션(orchestrate)합니다. Gemini Spark는 Gmail, Calendar, 그리고 궁극적으로 MCP를 통해 제3자 도구(third-party tools) 전반에서 작동합니다. 하지만 에이전트 워크플로(agent workflows)는 그것이 작동하는 인터페이스(surfaces)만큼만 신뢰할 수 있습니다. 에이전트 스택(agentic stack) 전체는 웹사이트가 결국 기계 소비를 위한 구조화된 인터페이스를 노출할 것이라는 전제를 깔고 있습니다.

WebMCP는 개방형 웹(open web)에서 그것이 어떤 모습일지에 대한 사양(specification)입니다.

당신이 반드시 해야 할 비판

대부분의 컨퍼런스 보도가 안일하게 넘어가는 지점이 바로 여기입니다.

WebMCP는 채택(adoption)이 뒤따를 때만 의미가 있습니다. 단 하나의 브라우저만이 뒤를 받치고 생태계의 참여가 없는 개방형 표준은 그저 Chrome의 실험일 뿐입니다. 제안된 웹 표준의 역사는 대부분 임계 질량(critical mass)을 기다리다 죽어버린 유망한 아이디어들의 묘지이거나, 구현이 너무 일관되지 않아 결국 개발자들이 우회 방법(workarounds)을 작성하게 만든 아이디어들의 역사입니다. 즉, 결국 다시 Selenium 문제로 돌아가게 된 것입니다.

Google은 6개월 안에 Chrome 149를 전 세계 대부분의 브라우저로 밀어붙일 수 있을 만큼 충분한 플랫폼 영향력 (leverage)을 가지고 있습니다. 하지만 에이전트 (agents)가 사용해야 하는 모든 사이트에 대해 그와 동일한 영향력을 가지지는 못합니다. "여기에 표준이 있습니다"와 "Stripe, Shopify, 그리고 의료 포털들이 이 표준을 올바르게 구현했습니다" 사이의 간극은 수년간의 개발자 노력과 비즈니스 협상이 필요한 영역입니다. 표준을 발표한다고 해서 그 타임라인이 단축되지는 않습니다.

또한, I/O 보도 내용에서 대체로 회피하고 있는 안전성 문제도 있습니다.

구조화된 도구 노출 (Structured tool exposure)은 양날의 검과 같습니다. 현재 브라우저 에이전트들이 제한적인 이유는 부분적으로 그들이 안전하기 때문이기도 합니다. 즉, 그들이 할 수 있는 일이 많지 않기 때문입니다. 모든 사이트가 깨끗하고 기계가 실행 가능한 기능 (machine-actionable capabilities)을 노출하는 웹은, 해킹되거나 오작동하는 에이전트의 피해 범위 (blast radius)가 현저히 커지는 웹이 될 것입니다.

권한 모델 (permissions model), 동의 모델 (consent model), 감사 추적 (audit trail) — 이 중 그 어떤 것도 "이 사이트가 지원하는 작업은 다음과 같습니다"라고 선언한다고 해서 해결되지 않습니다. 오히려 이는 책임 소재 (accountability) 문제를 더욱 날카롭게 만듭니다.

인프라 (infrastructure)는 신뢰 보장 (trust guarantees)보다 더 빠르게 도착하고 있습니다.

이것이 현재 에이전트 기반 개발 (agentic development)이 실제로 처한 상황에 대한 솔직한 요약입니다. WebMCP뿐만 아니라 모든 분야에 해당되는 이야기입니다.

이것이 여전히 핵심인 이유

이러한 우려 사항들이 WebMCP의 중요성을 낮추지는 않습니다. 오히려 주의 깊게 추적해야 할 이유를 더해줍니다.

I/O 이후 DEV 커뮤니티의 반응은 시사하는 바가 큽니다. 공감을 얻은 제출물들은 모델 벤치마크 (model benchmarks)에 관한 것이 아니었습니다. 그것들은 인프라, 개인정보 보호, 그리고 인간만큼이나 기계를 위해 설계된 프레임워크에 관한 것이었습니다. 이러한 패턴은 우연이 아닙니다.

생계를 위해 결과물을 만들어내는 개발자들은 실제 작업이 어디로 향할지 알아채는 확실한 직관을 가지고 있으며, 현재 그 직관은 지능 (intelligence)이 아닌 통합 (integration)을 가리키고 있습니다.

기능 (capability) 문제는 대부분의 사람들이 인정하고 싶어 하는 것보다 해결에 더 가까워졌습니다. 모델은 추론을 잘합니다. 모델은 행동합니다. 해결되지 않은 과제로 남아 있는 것은 그러한 행동들을 대규모 환경에서 신뢰할 수 있고, 감사 가능하며, 안전하게 만드는 것입니다.

그것은 인프라 (Infrastructure) 문제입니다.

그리고 인프라 문제는 제품 (Products)이 아니라 프로토콜 (Protocols)을 통해 해결됩니다.

WebMCP는 신뢰할 수 있는 에이전트-웹 상호작용 (Agent-web interaction)이 어떤 모습이어야 하는가라는 질문에 대한 초기 답변입니다. 아마도 이것이 최종적인 정답은 아닐 것입니다. RSS 역시 그랬습니다. 하지만 RSS는 그 아이디어가 실행 가능하다는 것을 증명했고, 그 이후의 모든 것들은 그 증명을 바탕으로 구축되었습니다.

초기 웹은 문서들을 연결했습니다.

다음 버전은 단순히 페이지를 탐색하는 인간뿐만 아니라, 의도 (Intent)를 실행하는 에이전트 (Agents)를 위해 역량 (Capabilities)을 연결할지도 모릅니다.

웹은 인간이 탐색할 수 있도록 구축되었습니다.

다음 버전은 에이전트가 작동할 수 있도록 구축될지도 모릅니다.

DEV의 Google I/O 2026 Writing Challenge에 제출되었습니다.