WebMCP: 웹사이트가 AI 에이전트와 직접 대화하게 하는 새로운 표준
WebMCP: Teaching Your Website to Talk to AI Agents
AI 에이전트가 웹사이트를 사용하는 방식이 바뀌고 있습니다. 현재는 DOM을 스크래핑하고 요소를 추측하는 방식이라 레이아웃이 바뀌면 쉽게 깨지지만, WebMCP는 웹사이트가 자신의 기능을 구조화된 도구로 선언하여 에이전트가 직접 호출할 수 있게 합니다. Google Chrome과 Microsoft Edge가 공동 제안한 이 표준은 Chrome 149에서 오리진 트라이얼로 제공되며, 첫 도구 등록은 10분이면 충분합니다. 이 글은 WebMCP의 핵심 개념, 실제 호출 흐름, 그리고 13개의 도구를 등록한 실제 데모(커리어 코파일럿)를 통해 에이전트가 도구를 연쇄 호출하고 사람의 승인을 받는 안전 모델을 보여줍니다.
에이전트가 당신의 사이트를 조작하는 것과 사진을 조작하는 것의 차이입니다.
HN 토론
57- sandeepkd
이건 여러모로 뒤집힌 접근이고 비현실적으로 느껴진다.
한편에서는 AI가 소프트웨어 엔지니어를 대체할 만큼 똑똑하다는 주장이 나오는가 하면, 다른 한편에서는 웹사이트 소유자들이 에이전트가 제대로 일할 수 있도록 특정 형식으로 정보를 제공해야 한다고 요구받고 있다. 그 정보는 모든 일반 사용자가 이미 사용할 수 있는 바로 그 정보라는 점을 기억하라.
둘째, 일반 인간용 정보와 에이전트용 정보 두 버전을 유지한다면, 두 버전이 서로 어긋나기 시작하는 것은 시간문제다. 아무 회사의 네이티브 앱과 브라우저 애플리케이션을 가져다 비교해 보라. 99% 확률로 정확히 같지 않을 것이다.
- mg
> 여기 book_table 도구가 있다. 날짜, 시간, 인원수를 받아서 호출하면 된다.
인간과 AI가 똑같이 사용할 수 있는 간단한 폼을 제공하는 게 어떨까?
<form action=book_table>
<input type=date name=date>
<input type=time name=time>
<input type=number name=party_size>
<input type=submit value="Book table">
</form>
- dzonga
우리에게는 이미 WebMCP보다 나은 것이 있다. 즉 일반 API가 그것이다.
더 영향력 있는 작업은 기존의 레거시 데스크톱 앱 분야에서 이루어져야 한다. 대기업이든 소기업이든 대부분의 주요 업무가 거기서 이루어진다.
에이전트가 웹사이트를 자동화하는 것은 비교적 쉽다. 레거시 데스크톱 앱을 자동화하는 것은 다른 문제인데, RPA가 있긴 하다.
- arjie
터무니없게 들리겠지만, 나는 모든 HTMX 컴포넌트에 가능한 동작과 함께 AI 요약을 노출시키고, 페이지에 'AI에게 복사'라는 작은 버튼을 두어 클릭하면 단기 액세스 토큰과 모든 컴포넌트를 텍스트로 포함한 프롬프트를 생성하도록 한다.
이것을 비교적 작은 모델의 에이전트에게도 주면, 그들은 이 초기 시드를 사용해 사이트를 탐색하고 아주 잘 작업을 수행한다.
초기 프롬프트면 충분하다. 그 후에는 대부분의 에이전트가 HTML을 사용해 아주 잘 탐색한다. 원한다면 그 설명을 aria 레이블에 넣을 수도 있겠지만, 어차피 같은 것이다.
- stillpointlab
WebMCP가 왜 존재하는지 이해하는 데 시간이 좀 걸렸다. 일반 MCP + SSE/Websockets로 거의 모든 사용 사례를 커버할 수 있다고 생각했기 때문이다.
WebMCP의 흥미로운 사용 사례 중 하나는 브라우저 에이전트가 수행할 수 있는 사이트 간 활동이다. 문제의 데이터 흐름이 이질적인 웹사이트 집합을 포함하는 경우가 그렇다.
이것은 무엇보다 기존 웹 SaaS에게 생명줄처럼 느껴진다. 미래의 앱은 WebMCP가 필요 없는 방식으로 설계될 수 있지만, Salesforce나 Workday 같은 거대 앱은 프로젝트를 구성하는 웹 UI 흐름에 내장된 수십 년간의 우연한 비즈니스 로직을 포기할 수 없다. 그 흐름들이 데이터 기반이 될 수는 있지만, 그 위에 WebMCP 파사드를 얹는 것이 더 실용적이다. 기존 업체들이 AI 네이티브 MCP를 만들어 그곳에서 일급 시민이 되도록 강요하는 대신, 인간 중심의 프론트엔드 곳곳에 브라우저 어포던스를 뿌리고 에이전트에게 작업을 떠넘기는 것이 더 쉽다.
하지만 내 경우, 레거시 필요 없이 처음부터 개발하고 있기 때문에 WebMCP에 의존하는 것은 오히려 안티 패턴이라고 생각한다. 사이트 간 사용 사례에는 유용할 수 있고, 순수 UI 활동(예: 데이터가 이미 클라이언트에 모두 있는 '이 목록 필터링')의 지연 시간을 줄이는 데는 유용할 수 있지만, 일반적으로 에이전트를 위한 견고한 MCP 인터페이스를 갖는 것이 더 낫다는 생각이다.