스크린샷을 찍고 클릭을 '추측'하는 에이전트
AI 에이전트가 웹사이트를 사용하는 방식을 상상해보면, 지금까지의 현실은 꽤 원시적이다. 스크린샷을 찍고, 뭐가 있는지 추측하고, 클릭해보고, 다시 스크린샷을 찍는다. 서리 낀 유리창 너머로 상대방 입을 읽으려는 것과 같다. Google I/O 2026에서 공개된 WebMCP(Web Model Context Protocol)는 바로 이 구조적 한계를 겨냥한다. 에이전트가 UI를 '보고 추측'하는 대신, 개발자가 무엇을 할 수 있는지 명시적으로 선언하도록 하는 것이다.
WebMCP가 바꾸는 것: 추측 대신 선언
dev.to의 분석에 따르면 WebMCP는 크게 두 가지 방식으로 동작한다. 하나는 선언형 API—기존 HTML 폼에 data-mcp-tool 속성을 붙여 에이전트에게 이 폼이 무엇을 하는지 알려주는 방식이다. 새 JavaScript 한 줄도 필요 없다. 다른 하나는 명령형 API—navigator.mcp.registerTool()로 JavaScript 함수를 직접 에이전트가 호출할 수 있는 도구로 등록하는 방식이다. 에이전트는 add_to_cart({ productId: 'ABC123', quantity: 2 })를 직접 호출하고, 신뢰할 수 있는 응답을 받는다. DOM을 파싱하지 않고, 재시도도 없다.
이 발표가 단순한 Google 실험에 그치지 않을 것으로 보이는 이유는 Microsoft와 공동 개발이라는 점이다. W3C Web Machine Learning Community Group에서 두 거대 브라우저 벤더가 같은 방향을 바라보고 있다는 것은, 이 표준이 단순한 origin trial을 넘어 웹 플랫폼의 일부가 될 가능성을 상당히 높인다. Firefox와 Safari의 미참여, 헤드리스 미지원이라는 현실적 제약은 분명히 존재하지만—이 표준이 걸어가는 경로 자체는 Service Workers나 aria-label이 밟았던 것과 닮아 있다.
'직접 만들지 말라'는 원칙이 여기서 다시 나온다
WebMCP 맥락에서 특히 흥미로운 것은, 거의 같은 시기에 주목받은 다른 원칙이다. geeknews가 소개한 '직접 만들지 말라(Don't Roll Your Own)' 원칙—원래 암호화에서 나온 이 규칙이 웹 UI에도 그대로 적용된다는 주장이다.
브라우저가 이미 잘 처리하는 것을 굳이 다시 만들면 어떤 일이 생기는가. 커스텀 스크롤은 마우스·터치패드·키보드 각각에 대한 기대를 깨뜨린다. JavaScript로 가로챈 링크 탐색은 새 탭을 여는 것보다 느려지기도 한다. 가짜 비밀번호 필드는 비밀번호 관리자, 자동완성, 모바일 키보드, 접근성 도구와의 협력을 끊어버린다. 사용자는 의식하지 않고 쓰던 동작이 낯선 동작으로 바뀌는 순간, 컨텐츠가 아니라 인터페이스 조작 자체를 신경 써야 하는 상황에 놓인다.
두 원칙이 수렴하는 지점: 브라우저 네이티브 = 에이전트 가독성
여기서 두 기사가 하나의 설계 원칙으로 수렴한다.
브라우저 네이티브를 지키는 것은 단순히 '사람 사용자'를 위한 결정이 아니다. <input type="password">가 비밀번호 관리자와 협력하듯, WebMCP의 data-mcp-tool 어노테이션은 AI 에이전트와 협력한다. <a href>가 브라우저의 탭 관리, bfcache, 접근성 트리와 연결되듯, navigator.mcp.registerTool()은 에이전트에게 신뢰할 수 있는 액션 인터페이스를 제공한다.
커스텀 컴포넌트로 브라우저 시맨틱을 덮어쓰는 순간, 두 가지가 동시에 손상된다—스크린리더가 읽을 수 없어지고, 에이전트가 이해할 수 없어진다. ARIA가 보조 기술을 위한 의미 계층이었다면, WebMCP는 AI 에이전트를 위한 의미 계층이다. 그리고 두 계층 모두 네이티브 마크업을 기반으로 할 때 가장 견고해진다.
시사점: '세 번째 사용자 타입'을 위한 설계 체크리스트
이 수렴이 실무에 던지는 질문은 구체적이다.
- 지금 만들고 있는 폼이
<form>과<input>시맨틱을 유지하고 있는가, 아니면 div와 onClick으로 흉내 내고 있는가? - 링크가 실제
<a href>인가, JavaScript 이벤트 핸들러가 탐색을 가로채고 있는가? - 날짜 선택기, 비밀번호 필드, 다중 선택 UI를 커스텀으로 교체할 때 접근성 도구와 에이전트 양쪽에 미치는 영향을 검토했는가?
물론 날짜 범위 선택, 항공권 가격 표시가 내장된 캘린더처럼 네이티브 컨트롤이 실질적으로 부족한 케이스가 존재한다. 이 경우에도 방향은 있다—네이티브 <input type="date">를 대체하는 것이 아니라, 동일 필드를 조작하는 보조 위젯으로 추가하는 것. 시맨틱 기반을 유지하면서 기능을 확장하는 방향이다.
전망: 2015년의 aria-label이 다시 찾아왔다
WebMCP를 오늘 바로 프로덕션에 전면 적용해야 한다는 말이 아니다. Firefox와 Safari 미참여, 헤드리스 미지원, W3C 정식 표준화 이전이라는 한계는 실재한다. 그러나 이 표준이 신호하는 방향은 이미 충분히 선명하다.
웹앱의 사용자는 이제 세 타입이다—데스크톱 인간, 모바일 인간, 그리고 AI 에이전트. 2015년에 aria-label을 붙이는 것이 '선택 사항처럼 느껴졌지만 결국 기본값이 됐듯', WebMCP 어노테이션과 네이티브 시맨틱은 '에이전트 가독성'이라는 새로운 품질 기준의 기초가 될 것이다.
가장 실용적인 첫 걸음은 거창하지 않다. 지금 운영 중인 핵심 플로우 하나—검색 폼, 체크아웃 단계, 필터 UI—를 골라 data-mcp-tool 어노테이션을 붙여보는 것. 새 JavaScript가 필요 없다. 한 시간이면 된다. 그리고 그 한 시간은 '브라우저가 이미 잘 하는 것을 다시 만들지 않는다'는 오래된 원칙을 AI 시대의 언어로 다시 번역하는 시간이기도 하다.