웹사이트는 누구를 위해 만들까요? 지금까지는 주로 사람을 위해 만들었습니다. UI/UX 전략도 방문자가 원하는 정보를 쉽게 찾고 필요한 작업을 편리하게 처리하도록 설계해 왔습니다. 하지만 AI가 사용자를 대신해 웹사이트를 탐색하고 작업을 처리하기 시작하면서 사용자의 정의가 인간을 넘어 에이전트까지 확장되고 있습니다.
AI가 웹사이트 방문객의 하나가 되어 가는 변화는 이미 주요 브라우저와 AI 서비스에서 나타나고 있습니다. Gemini in Chrome의 auto browse는 사용자가 로그인한 웹사이트에서 상품 비교와 예약, 양식 입력 같은 작업을 처리합니다. Microsoft Edge의 Copilot Mode도 사용자의 브라우저에서 웹사이트를 이동하고 버튼을 누르며 정보를 입력합니다. OpenAI 역시 ChatGPT의 에이전트 기능으로 사용자의 브라우징 환경에서 웹사이트를 이동하며 다단계 작업을 수행합니다.
이러한 흐름과 함께 주목받는 기술이 WebMCP입니다. WebMCP는 웹사이트의 검색과 입력, 실행 기능을 에이전트가 호출할 수 있는 구조화된 도구로 제공하는 웹 API 제안입니다. W3C Web Machine Learning Community Group이 초안을 공개한 상태입니다. 발 빠른 조직에서는 크롬 149의 오리진 트라이얼과 별도의 얼리 프리뷰 프로그램을 활용해 에이전트 친화적인 웹사이트 설계를 위한 사전 테스트에 나서고 있습니다. 이번 포스팅에서는 WebMCP의 동작 원리와 사전 평가 대상을 골라 어떻게 테스트하면 좋을지 정리해 보겠습니다.
사람을 위한 화면만으로는 부족한 이유
우리가 방문하는 대부분의 웹사이트는 화면을 바라보는 사람의 눈과 마우스를 쥔 손을 중심으로 설계돼 있습니다. 사람은 화면을 보고 버튼과 입력창의 의미를 이해합니다. AI는 다릅니다. 에이전트가 같은 웹사이트를 이용하려면 HTML 구조를 분석하거나 화면을 캡처해 시각 요소를 해석해야 합니다.
이 방식에는 명확한 한계가 있습니다. 화면 구성이나 버튼 위치가 바뀌면 에이전트가 작업 흐름을 놓칠 수 있습니다. 기능의 목적과 입력 조건이 분명하지 않으면 잘못된 버튼을 누르거나 값을 틀리게 입력하기도 합니다. 화면을 반복해서 읽고 해석하는 과정에서는 시간과 토큰도 더 많이 씁니다.
이런 한계는 웹사이트가 기능의 의미와 사용 방법을 에이전트에게 직접 알려 주는 방식으로 줄일 수 있습니다. 사람에게는 기존 화면을 제공하고 에이전트에게는 구조화된 도구를 함께 제공하는 것입니다. WebMCP를 적용하면 웹사이트 운영자는 페이지 상태와 로그인 여부에 따라 에이전트에게 제공할 도구를 정할 수 있습니다.
WebMCP는 어떻게 동작하나?
WebMCP를 적용하면 웹사이트가 에이전트에게 사용할 수 있는 도구를 제공합니다. 각 도구에는 이름과 기능 설명, 입력 조건, 반환 결과를 담습니다. 에이전트는 화면을 보고 기능을 추측하는 대신에 현재 페이지가 제공하는 도구를 확인하고 필요한 기능을 호출합니다.
전자상거래를 예로 들어 보겠습니다. 홈 화면에서는 상품 검색과 카테고리 조회, 필터 도구를 제공할 수 있습니다. 상품 상세 화면에서는 장바구니 담기와 유사 상품 조회 도구를 제공할 수 있습니다. 로그인 상태나 페이지의 상황에 따라 노출할 도구를 바꾸는 것도 가능합니다.
도구를 만드는 방식은 두 가지입니다. 명령형 API는 자바스크립트로 도구의 동작을 정의합니다. 화면 이동이나 상태 변경처럼 세밀한 제어가 필요한 기능에 적합합니다. 선언형 API는 HTML 폼 요소에 정보를 추가해 도구로 제공합니다. 기존 입력 양식을 그대로 활용할 수 있다는 장점이 있습니다.
WebMCP 적용 효과는 에이전트가 화면을 추측하는 과정을 줄이는 데 있습니다. 입력과 출력이 정해진 도구를 쓰면 작업의 정확성과 일관성이 높아집니다. 화면을 반복해서 분석하는 방식보다 처리 과정도 간결합니다. 사용자는 같은 화면에서 진행 상황과 결과를 확인할 수 있습니다.
여기서 혼동하지 말아야 할 점이 있습니다. WebMCP는 기존 MCP를 대신하는 개념이 아닙니다. 우리가 잘 알고 있는 MCP는 원격 시스템이나 데이터 소스를 에이전트와 연결하는 데 적합합니다. WebMCP는 사용자가 보고 있는 웹사이트의 상태와 기능을 브라우저 에이전트에게 제공하는 데 초점을 맞추고 있다고 이해하면 됩니다.
무엇부터 테스트를 해보아야 할까?
새로운 기술이나 규격을 적용할 때는 효과가 가장 큰 대상을 먼저 시험하는 편이 좋습니다. WebMCP는 여러 단계의 조회와 입력, 실행이 반복되는 업무에서 효과가 큽니다. 단순히 정보를 읽는 페이지보다, 에이전트가 사용자를 대신해 처리할 작업이 있는 페이지가 우선 적용 대상입니다.
전자상거래에서는 상품 검색과 비교, 장바구니, 주문 절차를 도구로 제공할 수 있습니다. 여행과 예약 서비스에서는 일정과 인원, 가격 조건을 받아 검색과 비교, 예약으로 이어지는 흐름을 구성할 수 있습니다. 고객 지원에서는 문의 분류와 계정 조회, 진단, 담당자 이관 절차를 제공할 수 있습니다.
사내 포털과 개발자 포털도 적용해 볼 만합니다. 에이전트가 데이터 파이프라인을 실행하거나 품질 점검 결과를 조회하고, 관련 화면으로 사용자를 안내할 수 있습니다. 사용자는 웹 UI에서 로그와 실행 결과를 확인합니다. 반복되는 조회와 입력, 승인 업무도 에이전트에게 맡기고 결과만 검토하는 방식으로 바꿀 수 있습니다.
우리 조직에서 우선 적용할 대상을 고르고 싶다면 다음 세 질문에 답해 보세요.
- 사용자가 여러 화면을 오가며 반복하는 업무인가?
- 입력과 결과를 명확하게 정의할 수 있는가?
- 에이전트가 처리했을 때 시간과 비용을 줄일 수 있는가?
이 기준에 맞지 않는 단순 정보 페이지에 도구를 추가하면 개발과 운영 부담만 늘 수 있습니다.
신뢰할 수 있는 도구를 설계하는 원칙
적용할 웹사이트를 골랐다면 에이전트가 사용할 도구를 설계해야 합니다. 도구를 제공하는 것만으로 에이전트가 올바르게 일을 하지는 않습니다. 도구의 목적과 입력 조건, 실행 결과를 명확하게 정의해야 합니다.
도구 하나에는 한 가지 기능을 담는 것이 좋습니다. 상품 검색과 결제를 하나의 도구로 묶으면 사용자가 중간 결과를 확인하기 어렵습니다. search-products, add-to-cart, start-checkout처럼 작업 단위를 나누면 에이전트도 다음에 해야 할 행동을 판단하기 쉽습니다.
배포 전에는 기능 테스트와 에이전트 평가를 진행해야 합니다. 기능 테스트를 통해 같은 입력에 정해진 결과가 나오는지 확인합니다. 에이전트 평가에서는 사용자의 표현이 달라져도 올바른 도구와 입력값을 고르는지 확인합니다. 잘못된 도구 선택과 잘못된 실행 순서, 틀린 입력값, 불완전한 출력, 쿠폰 적용 실패, 속도 제한 같은 상황도 평가에 포함해야 합니다.
도구 설계를 마쳤다면 다음은 보안을 살펴보아야 합니다. 브라우저 에이전트는 사용자의 로그인 상태에서 작업할 수 있습니다. 도구를 편리하게 제공하는 것만큼 권한과 데이터 보호가 중요한 이유입니다.
정상적인 웹사이트의 댓글이나 상품 설명에도 악의적인 지시가 섞일 수 있습니다. 도구 설명이나 반환 결과를 이용해 에이전트의 행동을 바꾸려는 간접 프롬프트 인젝션도 고려해야 합니다. LLM은 동작이 확률적이라 모델의 안전 기능만으로 이런 위험을 모두 막을 수는 없습니다. 권한 범위와 실행 조건을 시스템에서 함께 통제하는 다층 방어가 필요합니다.
사이트와 상호작용하는 Gemini 기반 에이전트가 필요하다면…
지금 모든 페이지를 WebMCP에 맞춰 바꿀 필요는 없습니다. 먼저 사용자가 여러 단계를 반복하는 핵심 업무를 찾고, 입력과 결과를 명확하게 정의할 수 있는지 사전 테스트를 통해 확인하면 됩니다. 작은 조회 업무부터 도구로 제공하고 정확도와 보안을 평가한 뒤 적용 범위를 넓히는 편이 좋습니다.
사이트와 상호작용하는 Gemini 기반 에이전트를 고려 중이라면 메가존소프트 문의 포털을 통해 상담을 신청해 주세요.
