웹앱을 AI 에이전트가 조작하게 만들 때 가장 흔한 접근은 화면을 보고 클릭하게 하는 방식입니다. 데모는 빨리 나옵니다. 하지만 실무에서는 버튼 위치가 바뀌거나, 문구가 바뀌거나, 모달이 하나 끼면 실패합니다. Google I/O 2026 Developer Keynote에서 소개된 WebMCP는 이 문제를 다른 방향에서 풀려는 제안입니다. 브라우저 기반 AI 에이전트가 JavaScript 함수, HTML form 같은 구조화된 도구를 사용할 수 있도록 웹 표준 형태로 노출하자는 접근입니다.
핵심 검색 의도는 분명합니다. “AI agent가 웹사이트를 안정적으로 조작하려면 무엇을 준비해야 하나?”입니다. 답은 단순히 모델을 키우는 것이 아닙니다. 웹앱 쪽에서 에이전트가 사용할 수 있는 안전한 tool surface를 설계해야 합니다. WebMCP는 아직 제안 단계이고 Chrome 149 origin trial로 실험이 예고된 영역이지만, 지금부터 설계 원칙을 바꿔야 할 이유는 충분합니다.
화면 자동화는 사람이 보는 인터페이스를 모델이 해석해서 행동합니다. “저 파란 버튼을 눌러”, “이 입력칸에 이메일을 넣어” 같은 방식입니다. 장점은 기존 웹앱을 거의 수정하지 않아도 된다는 점입니다. 단점은 불안정성입니다. UI가 바뀌면 에이전트가 같은 의도를 다른 요소에 연결할 수 있습니다.
구조화 도구 방식은 웹앱이 에이전트에게 명시적 기능을 제공합니다. 예를 들어 searchOrders, createTicket, applyCoupon, submitReturnRequest 같은 작업 단위를 노출합니다. 에이전트는 화면 픽셀을 추측하지 않고 정의된 입력 스키마와 권한 범위 안에서 작업합니다. 이 방식은 API와 비슷하지만, 브라우저 문맥에서 사용자 세션, 페이지 상태, 폼, 권한과 연결될 수 있다는 점이 다릅니다.
첫 번째는 복잡한 폼입니다. 보험 청구, 환불 신청, B2B 견적 요청, 관리자 설정처럼 입력칸이 많고 조건부 필드가 있는 화면은 visual agent만으로 안정화하기 어렵습니다. 모델은 보이는 필드명을 잘 읽어도 숨겨진 validation rule이나 required condition을 모를 수 있습니다.
두 번째는 장바구니나 결제 직전 플로우입니다. 사용자가 “이 쿠폰 적용해줘”라고 했을 때 에이전트가 화면을 클릭해 처리할 수는 있지만, 잘못된 쿠폰을 적용하거나 결제 버튼을 눌러버리면 사고가 됩니다. 구조화 도구는 applyCoupon은 허용하되 placeOrder는 사용자 승인이 필요하게 나눌 수 있습니다.
세 번째는 SaaS 관리자 화면입니다. 계정 권한 변경, 팀원 초대, API key 재발급, 과금 플랜 변경은 에이전트 자동화 수요가 큽니다. 동시에 위험도도 큽니다. 이런 영역은 화면 클릭이 아니라 명시적 tool contract와 감사 로그가 필요합니다.
먼저 액션을 읽기, 제안, 쓰기로 나눠야 합니다. 읽기 액션은 비교적 자유롭게 허용할 수 있습니다. 예를 들어 주문 상태 조회, 문서 검색, 설정값 확인입니다. 제안 액션은 변경 전 미리보기입니다. “이 설정을 바꾸면 이렇게 된다”를 계산해 보여줍니다. 쓰기 액션은 실제 상태 변경입니다. 여기에는 승인, 롤백, 로그가 붙어야 합니다.
다음은 입력 스키마입니다. 에이전트에게 자유 텍스트만 받으면 검증이 어렵습니다. 가능한 enum, date format, amount range, user id, resource id를 명확히 해야 합니다. 예를 들어 환불 처리 tool은 orderId, refundItems, reasonCode, notifyCustomer를 분리해야 합니다. “환불해줘”라는 문장을 그대로 받으면 위험합니다.
세 번째는 권한 모델입니다. 사용자에게 권한이 있어도 에이전트에게 모든 권한을 주면 안 됩니다. 에이전트 사용 시 권한을 한 단계 더 좁히는 방식이 필요합니다. 읽기는 허용, 쓰기는 승인, 외부 발송은 금지처럼 정책을 나눕니다.
WebMCP 같은 흐름은 기술 문서와 제품 SEO에도 영향을 줍니다. 앞으로 사용자는 “이 서비스는 AI agent friendly 한가?”를 볼 가능성이 큽니다. API 문서만 있는 서비스보다 agent action 문서, tool schema, 안전한 자동화 가이드가 있는 서비스가 선택될 수 있습니다.
개발자 대상 SaaS라면 문서에 “AI agent integration”, “browser agent support”, “MCP tool surface”, “automation-safe actions” 같은 검색 의도를 반영할 수 있습니다. 단, 키워드를 억지로 반복하면 안 됩니다. 실제로 어떤 작업을 에이전트에게 맡길 수 있고, 어떤 작업은 승인 단계가 필요한지 예시 중심으로 써야 합니다.
WebMCP 자체를 기다리지 않아도 지금 적용할 수 있는 기준이 있습니다. 웹앱 내부 액션을 사람이 보는 UI와 에이전트가 쓰는 tool contract로 분리하는 것입니다. 그리고 각 tool에 위험 등급을 붙입니다.
예를 들어 readInvoice는 low risk, draftRefund는 medium risk, executeRefund는 high risk입니다. low risk는 자동 실행, medium risk는 미리보기 후 승인, high risk는 2단계 확인과 감사 로그를 요구합니다. 이렇게 해두면 WebMCP가 본격화됐을 때도 구조를 옮기기 쉽습니다.
WebMCP 도입의 본질은 “에이전트가 웹앱을 더 똑똑하게 보게 하자”가 아닙니다. 웹앱이 에이전트에게 안전하고 검증 가능한 작업 단위를 제공하자는 것입니다. 실무 개발자는 지금부터 화면 자동화 중심 사고를 줄이고 tool contract 중심 설계로 이동해야 합니다.
