WebKit이 WebMCP에 반대하는 이유와 오늘 실제로 구축해야 할 것

만약 에이전트 웹(agentic-web) 표준 논쟁을 따라왔다면, 헤드라인들을 보셨을 겁니다: Chrome은 [Chrome 149에서 WebMCP origin trial]을 출시했고, WebKit의 표준 위치 추적기(standards-positions tracker)는 한 단어 평결인 **oppose**를 내렸습니다.

이것을 'Apple이 안 된다고 하니 기다려야 한다'고 읽기 쉽지만, 그것은 잘못된 해석입니다. 이 반대는 대부분 _좋은 엔지니어링 피드백_이며, 이것을 내재화하면 오늘 에이전트를 위해 정확히 어떻게 구축해야 하는지를 알려줍니다—스펙이 지연되더라도 안전한 방식으로 말이죠.

WebKit이 실제로 문제 삼았던 것들

WebKit의 입장은 일반적인 목록을 인용합니다—API 설계, 기존 플랫폼 기능 중복, i18n(국제화), 이식성(portability), 개인 정보 보호(privacy), 보안(security), 불분명한 사용 사례. 상투적으로 들릴 수 있지만, 그중 하나가 핵심 비판점이며, 이는 WebMCP 레포지토리 자체에서 가장 뚜렷하게 나타납니다: 접근성 트리와의 중복성.

주장은 명확합니다:

접근성 트리는 이미 기계가 읽을 수 있는 액션 공간—레이블, 역할(roles), 상태(states), 예상 입력값, 유효성 검사 오류, 관계—을 노출하고 있습니다. 이는 DOM에서 파생되었기 때문에 동기화되지 않을 수 없습니다. 별도로 유지되는 JavaScript 도구 레지스트리는 시간이 지남에 따라 페이지와 다르게 분기될 수 있습니다.

이것은 정확합니다. 만약 에이전트를 위해 UI의 병렬 설명을 직접 작성한다면, 당신은 두 번째 진실의 원천(second source of truth)을 만든 것이고, 두 번째 진실의 원천은 부패하기 마련입니다. 그것은 실제적인 문제점이며, '인간에게 도움이 되지 않는 에이전트 전용 API'는 의심할 만한 정당한 이유가 됩니다.

접근성 트리만으로는 여전히 충분하지 않은 이유

여기서 반대 의견이 과소평가하는 부분이 있습니다. a11y(접근성) 트리는 상태—페이지에 무엇이 있는지, 각 컨트롤이 무엇인지, 무엇이 필요한지—를 설명하는 데는 탁월합니다. 하지만 특히 복합적인 액션(compound ones)을 설명하는 데는 훨씬 취약합니다.

"50유로 미만, 재고 있음 제품을 필터링한 다음, 가장 상단의 결과를 장바구니에 담아줘"라는 명령을 생각해 보십시오. 스크린 리더(screen reader)를 사용하는 사람에게 이것은 개별적인 제어 상호작용(control interactions)의 연속입니다. 하지만 에이전트(agent)에게 역할(roles)과 레이블(labels)로부터 이 전체 흐름을 추론하게 하는 것은 취약합니다. 에이전트는 기본 요소(primitives)로부터 앱의 의도를 역공학(reverse-engineer)해야 하기 때문입니다. 타입이 지정된 입력 스키마({ maxPrice, inStock })와 단일 핸들러(handler)를 가진 도구는 그러한 추측을 하나의 검증된 호출로 압축합니다.

따라서 다음 두 가지 사실은 동시에 성립합니다:

병렬로 수동 관리되는 에이전트 API는 부담(liability)이 됩니다.
접근성 트리(a11y tree)는 다단계 _액션(actions)_에 대해 정보 손실(lossy)이 발생합니다.

해결책은 "한쪽 편을 드는 것"이 아닙니다. 그것은 도구(tools)를 어떻게 구현하느냐에 달려 있습니다.

비판을 견뎌내는 설계

중복성에 대한 반대는 도구 정의가 _두 번째 구현(second implementation)_일 때만 유효합니다. 그러니 도구가 두 번째 구현이 되지 않게 하십시오.

올바른 태도는 다음과 같습니다 (순서대로):

사람을 위해 먼저 구축하십시오. 시맨틱 HTML (Semantic HTML), 실제 폼 요소 (form elements), 깔끔한 접근성 트리 (accessibility tree). 이것은 타협할 수 없는 사항이며, 사용자, 보조 기술 (assistive tech), 검색, 그리고 에이전트 모두가 혜택을 받는 부분입니다.
새로운 앱이 아니라 액션(actions)을 노출하십시오. 에이전트 도구를 등록하는 곳에서, 해당 핸들러가 UI가 이미 호출하고 있는 것과 정확히 동일한 함수를 호출하도록 하십시오. 귀하의 "장바구니에 담기" 버튼과 add_to_cart 도구는 결국 하나의 코드 경로(code path)로 수렴해야 합니다.
도구를 가볍게 유지하십시오. 도구는 기존 동작에 대한 타입이 지정된 진입점(entry point)이지, 새로운 비즈니스 로직을 위한 장소가 아닙니다. 만약 도구가 UI가 할 수 없는 일을 수행한다면, 그것이 바로 WebKit이 경고한 괴리(divergence)입니다. 대신 UI를 수정하십시오.

이렇게 하면 "두 개의 진실의 원천(two sources of truth)" 문제는 사라집니다. 여전히 단 하나만 존재하기 때문입니다. 도구 레지스트리(tool registry)는 페이지에 대한 병렬적인 설명이 아니라, 페이지가 이미 실행 중인 핸들러로 향하는 타입이 지정된 정문(front door)입니다. 이들은 동일한 코드이므로 동기화가 어긋날(desync) 수 없습니다.

구체적으로

명령형 API(imperative API)는 단지 귀하가 이미 가지고 있는 함수에 대한 타입이 지정된 래퍼(wrapper)일 뿐입니다:

navigator.modelContext.registerTool({
  name: "add_to_cart",
  description: "id와 수량을 사용하여 장바구니에 상품을 추가합니다",
...

그리고 대부분의 브라우저에는 아직 이 기능이 없을 것이므로, 기능 감지 (feature-detect)를 수행하세요:

if ("modelContext" in navigator) {
  // 도구 등록
}

저 if 문이 리스크 프로필의 전부입니다. 만약 WebMCP가 어디에서나 출시된다면, 당신은 준비가 된 것입니다. 만약 WebKit이 방어선을 유지하여 진행이 정체되더라도, 당신은 아무것도 잃지 않습니다. 이미 인간 사용자를 위해 존재하던 핸들러 (handlers) 위에 기능 감지된 강화 기능을 추가했을 뿐이기 때문입니다. 이것은 그저 점진적 향상 (progressive enhancement)일 뿐입니다.

이것이 당신에게 남기는 것

에이전트형 웹 (agentic-web) 툴링은 이미 "이것이 실재하는가"의 단계를 넘어섰습니다. Google의 Lighthouse는 이제 에이전트형 브라우징 (Agentic Browsing) 감사 카테고리를 제공하며, 스캐너들은 귀하의 사이트가 도구를 노출하는지 여부를 점점 더 높은 비중으로 평가할 것입니다. 표준에 관한 정치적 싸움은 정착되기까지 1년 정도 걸릴 것입니다. 그동안 당신이 취해야 할 행동은 하나의 명세 (spec)에 회사의 운명을 거는 것이 아닙니다. 하나의 진실된 원천 (source of truth)을 유지하면서, 이미 배포 중인 핸들러들에 타입이 지정되고 기능 감지되는 프런트 도어 (front door)를 설치하는 것입니다.

공개 사항: 저는 사이트의 기존 검색/장바구니/폼을 WebMCP 도구로 노출하는 오픈 소스 (MIT) 한 줄 스크립트인 Latch에서 일하고 있습니다. 이 프로젝트는 정확히 "기존 핸들러를 재사용하고, 기능 감지를 수행하며, 명세가 정체되더라도 아무것도 잃지 않는다"는 태도를 바탕으로 구축되었습니다. 만약 도구를 채택하기보다 표준을 먼저 이해하고 싶다면, WebMCP 가이드는 특정 벤더에 치우치지 않은 정보를 제공합니다. 댓글을 통해 설계상의 트레이드오프 (trade-offs)에 대해 이야기 나누는 것을 환영합니다.