웹에서 AI 에이전트가 일을 대신 처리한다고 하면 흔히 “사람처럼 화면을 클릭한다”는 장면을 떠올립니다. 그러나 실제 서비스에서는 그 방식이 불안정합니다. 버튼 위치가 바뀌고, 팝업이 끼어들고, 같은 폼이라도 사용자 상태에 따라 DOM 구조가 달라지기 때문입니다. Google Chrome 팀이 2026년 I/O에서 공개한 WebMCP는 이 문제를 웹 표준 쪽에서 풀어보려는 제안입니다.
핵심은 웹사이트가 브라우저 기반 에이전트에게 “여기서 호출해도 되는 구조화된 도구”를 명시한다는 점입니다. 사용자는 권한을 승인하고, 에이전트는 HTML 화면을 억지로 해석하는 대신 사이트가 노출한 함수나 폼을 더 기계 친화적인 방식으로 다룹니다. 기존 원격 MCP가 서버·도구 연결을 다뤘다면, WebMCP는 브라우저와 웹페이지 사이의 접점을 겨냥합니다.
배경
Chrome 발표에서 WebMCP는 “웹사이트를 에이전트용 툴킷으로 바꾸는” 제안으로 소개됐습니다. 실험적 origin trial은 Chrome 149에서 시작될 예정이고, Gemini in Chrome도 WebMCP API를 지원할 계획이라고 설명됐습니다. Google I/O 2026 개발자 키노트 정리에도 Modern Web Guidance, Chrome DevTools for agents, Chrome 내장 AI API가 같은 흐름으로 묶였습니다. 방향은 분명합니다. 에이전트가 코드를 만들고, 브라우저에서 검증하고, 사용자의 허가 아래 웹 서비스를 조작하는 흐름을 하나의 플랫폼 경험으로 묶겠다는 것입니다.
이 변화가 중요한 이유는 에이전틱 AI가 앱 바깥으로 나올 때 생기는 실패 지점이 대부분 인터페이스에 있기 때문입니다. LLM이 문장을 잘 써도 결제, 예약, 신청 같은 업무에서는 권한, 상태, 검증, 취소 경로가 더 중요합니다. WebMCP는 “무엇을 눌렀는지”보다 “어떤 의도를 어떤 제한 안에서 실행했는지”를 웹이 표현하게 만드는 쪽에 가깝습니다.
| 구분 | 화면 클릭식 에이전트 | WebMCP식 접근 |
|---|---|---|
| 대상 | 버튼, 입력창, DOM 구조 | 사이트가 선언한 함수·폼·도구 |
| 실패 원인 | 레이아웃 변화, 팝업, 숨은 상태 | 권한 설계, 도구 스키마, 서버 검증 |
| 사용자 통제 | 화면 감시와 사후 취소 | 호출 전 승인과 범위 제한 |
| 개발 포인트 | UI 자동화 안정화 | 도구 정의, 감사 로그, 예외 처리 |
원리
간단한 여행 예약 사이트를 생각해 보겠습니다. 예전 방식의 에이전트는 출발지와 도착지를 입력하고, 날짜 선택기를 열고, 필터를 누른 뒤 결과를 읽어야 합니다. WebMCP식 구조에서는 사이트가 searchFlights, holdReservation, compareHotelOptions 같은 호출 가능한 기능을 브라우저에 알려줄 수 있습니다. 에이전트는 사용자가 허용한 범위 안에서 이 도구를 호출하고, 결과를 사람에게 보여준 뒤 결제처럼 민감한 단계에서는 다시 승인을 요구합니다.
Chrome 내장 AI도 같은 맥락에 있습니다. 번역, 언어 감지, 향후 요약·작성 보조 같은 기능이 브라우저 안에서 실행되면 서버 호출 비용과 개인정보 이동을 줄일 수 있습니다. 물론 모든 모델이 로컬에서 충분히 빠르게 도는 것은 아닙니다. 그래서 브라우저가 모델을 관리하고 사이트 간에 최적화된 실행 환경을 공유한다는 설명이 붙습니다. 개발자 입장에서는 기능을 무조건 서버 API로 보내기 전에 “브라우저가 처리할 수 있는 작업인가”를 따져볼 필요가 생깁니다.
구조
WebMCP를 제품에 넣는다고 해서 사이트가 곧바로 자율적으로 움직이는 것은 아닙니다. 실제 구조는 네 층으로 나뉩니다. 첫째, 웹앱은 호출 가능한 도구와 입력 스키마를 정의합니다. 둘째, 브라우저는 그 도구를 에이전트에게 안전하게 노출합니다. 셋째, 사용자는 계정·금액·개인정보 같은 범위를 승인합니다. 넷째, 서버는 최종 권한과 비즈니스 규칙을 다시 검증합니다.
이 구조는 개발자 도구에도 영향을 줍니다. Chrome DevTools for agents는 콘솔 로그, 네트워크 트래픽, 접근성 트리 같은 정보를 에이전트가 확인하도록 열어줍니다. 사람이 “테스트해 봐”라고 말하는 대신, 에이전트가 실제 브라우저에서 성능과 접근성 문제를 재현하고 수정안을 낼 수 있습니다. 다만 이때도 최종 책임은 배포 파이프라인에 남습니다. 자동 수정이 늘수록 테스트, 롤백, 감사 로그가 더 중요해집니다.
체크포인트
- WebMCP는 아직 제안과 실험 단계의 성격이 강합니다. Chrome 149 origin trial 같은 조건을 확인하고, 표준화 진행 상황에 맞춰 실험 범위를 제한해야 합니다.
- 사이트가 노출하는 도구는 새로운 공격면이 됩니다. 입력 검증, 권한 분리, 호출 빈도 제한, 민감 작업 재확인이 설계의 중심이어야 합니다.
- 브라우저 내장 AI는 비용과 지연 시간을 줄일 수 있지만, 모델 가용성·기기 성능·브라우저별 지원 차이가 제품 경험을 흔들 수 있습니다.
- 에이전트가 처리한 작업은 사용자가 이해할 수 있어야 합니다. “완료했습니다”보다 어떤 자료를 조회했고 어떤 선택지는 보류했는지 보여주는 UI가 필요합니다.
WebMCP의 의미는 웹사이트가 AI에게 모든 권한을 넘긴다는 뜻이 아닙니다. 오히려 반대에 가깝습니다. 사람이 승인한 범위, 사이트가 정의한 도구, 서버가 검증하는 규칙을 분리해 에이전트의 행동을 더 좁고 명확하게 만드는 시도입니다. 웹 서비스를 운영한다면 지금 볼 지점은 화려한 데모보다 “우리 서비스의 어떤 행동을 안전한 도구로 표현할 수 있는가”입니다.
댓글 없음:
댓글 쓰기