WebMCP로 설계하는 선언형 에이전트 웹 도구 노출

화면 자동화의 신뢰성 문제를 프로토콜로 옮기다

Microsoft와 Google, OpenAI가 관여하는 WebMCP 웹 표준 제안이 공개됐다. 페이지가 제공 가능한 기능을 MCP 도구로 선언하면, 에이전트는 DOM을 스크래핑하거나 화면 좌표를 클릭하는 대신 해당 도구를 호출한다.

화면 기반 자동화는 페이지 마크업이 바뀔 때마다 깨지기 쉽고, 사이트는 원치 않는 조작을 차단하는 방식 외에는 통제 수단이 제한적이다. WebMCP는 사이트가 허용할 기능을 직접 선언하게 함으로써, 에이전틱 브라우징의 신뢰성 문제를 구현 요령이 아닌 프로토콜 계층에서 다룬다.

이 흐름은 MCP 코어의 무상태 전환과 맞물려 있다. 서비스가 갖춰야 할 범위는 선언 메타데이터, 인자 스키마, 권한 표기, 동의 흐름, 응답 규격, 화면 정합성, 악성 선언 탐지, 버전 정책까지 이어진다.

선언된 도구를 안전하게 호출하는 경로

도구 선언에는 이름, 설명, 부작용 여부, 필요한 권한을 구조화해 담는다. 에이전트는 이 설명을 도구 선택 근거로 사용하므로, 사람을 겨냥한 마케팅 문구와는 다르게 작성해야 한다. 모호하거나 과장된 설명은 잘못된 선택으로 이어질 수 있다.

인자는 타입, 범위, 필수 여부를 스키마로 고정하고 호출 시 서버에서 다시 검증한다. 클라이언트 검증은 안내일 뿐 신뢰 경계가 아니다. 읽기, 상태 변경, 결제·삭제처럼 되돌릴 수 없는 행위는 권한 수준을 구분해 표기하고, 그 수준에 따라 동의 흐름의 강도를 결정한다.

되돌릴 수 없는 도구는 호출 전에 사용자 확인을 받아야 한다. 이때 동의 범위와 유효 기간을 분명히 해 한 번의 승인이 무기한 위임으로 굳지 않게 해야 한다. 호출 결과도 성공, 부분 성공, 실패와 사유를 규격화된 형태로 반환해야 후속 에이전트 판단에 쓸 수 있다.

도구 호출과 기존 화면 조작은 내부 처리를 공유해야 한다. 두 경로가 분리되면 도구로 처리한 결과가 화면에 반영되지 않는 불일치가 생긴다. 또한 페이지가 실제와 다른 기능을 선언해 에이전트를 유도할 수 있으므로, 선언 내용과 실제 동작의 차이를 검증하는 클라이언트 측 수단이 필요하다. 선언을 그대로 신뢰하면 프롬프트 주입의 새 경로가 열린다.

도구 선언 버전도 명시해야 한다. 인자를 추가하거나 제거할 때의 호환 규칙을 정하고, 폐기 예정 도구에는 표시를 남겨 에이전트가 사라진 도구를 계속 호출하는 상황을 막는다.

⤢✕

서비스에 노출할 기능을 고르는 기준

자동화 수요가 확인된 기능부터 선언하는 편이 낫다. 모든 기능을 한꺼번에 열면 오남용 표면만 불필요하게 넓어진다. 되돌릴 수 없는 기능은 별도 검토 절차를 거쳐 결정하고, 로그인 상태에서만 제공할 도구와 비로그인 상태에서도 제공할 도구를 구분한다. 사업적으로 민감한 기능은 선언 대상에서 제외한다. 선언은 자동화를 허용한다는 의미이기도 하다.

동의 화면에서는 도구가 수행할 일, 되돌릴 수 있는지 여부, 동의의 유효 기간을 보여줘야 한다. 도구별로 형식을 제각각 만들기보다 일관된 흐름을 유지하는 편이 사용자의 판단 품질을 지킨다.

표준을 지원하지 않는 클라이언트를 위해 기존 화면 경로도 계속 제공해야 한다. 두 경로가 같은 결과를 내는지 정기적으로 확인하고, 도구별 호출 수·실패율·동의 거부율을 측정한다. 동의 거부율이 높은 도구는 설명이 부족하거나 권한 등급 표기가 맞지 않을 수 있다는 신호다.

제안 단계의 표준은 규격이 바뀔 수 있다. 변경을 추적할 담당과 반영 주기를 정하고, 초기 구현이 확정본과 어긋날 가능성을 전제로 추상화 계층을 둔다. 신규 도구 선언과 권한 등급 상향은 승인 대상으로 관리하며, 도구 오남용 사례와 악성 선언 탐지 결과도 정기 보고 항목으로 편성할 필요가 있다.

선언형 호출과 기존 자동화의 경계

구분	선언형 도구 호출	DOM 스크래핑 자동화
자동화 안정성	높음	낮음
사이트 통제력	높음	없음
적용 가능 범위	선언한 사이트만	모든 사이트
결과 판정 명확성	높음	낮음
구현 부담	사이트 측 발생	에이전트 측 발생
새로운 공격면	악성 선언	화면 위장

선언형 호출은 페이지 마크업이 바뀌어도 도구 규격이 유지되면 자동화가 깨지지 않는다. 정형화된 응답으로 성공 여부를 판단할 수 있고, 사이트는 허용할 조작을 직접 정할 수 있다. 반면 사이트가 도구를 선언하지 않으면 이 방식은 성립하지 않으며, 노출된 기능 밖의 조작도 할 수 없다. 선언 자체가 조작되면 새로운 유도 공격 경로가 된다.

DOM 스크래핑은 사이트 협조 없이 바로 적용할 수 있고 화면에 있는 모든 기능을 다룰 수 있다. 하지만 마크업 변경마다 유지보수가 필요하고, 성공 여부를 화면 변화로 추정해야 해 판정이 불확실하다. 사이트 입장에서는 원치 않는 자동화를 막기 위해 차단에 의존하게 된다. 표준이 확산되기 전에는 두 경로를 병행하되, 선언을 제공하는 사이트부터 전환하는 순서가 현실적이다.

표준 프로토콜을 채택하면 여러 에이전트 클라이언트가 별도 연동 없이 같은 방식으로 접근할 수 있다. 클라이언트의 도구 발견과 동의 흐름을 재사용하고 생태계 확산 효과도 얻는다. 다만 제안 단계 규격은 계속 바뀔 수 있고, 표준 바깥의 설계 자유도는 제한될 수 있다.

자체 공개 API는 인증 방식과 데이터 구조를 조직 요구에 맞춰 설계할 수 있으며 기존 운영 API도 재사용할 수 있다. 그러나 클라이언트마다 별도 연동이 필요하고 에이전트의 도구 발견 흐름에 자동으로 편입되지 않는다. 이미 API가 있는 조직이라면 그 API를 표준 선언으로 감싸는 방식이 두 경로의 장점을 함께 취할 수 있다.

전 기능 노출은 활용도를 높이고 자동화 수요를 사후 데이터로 확인할 수 있지만, 대량 호출과 의도치 않은 조작의 위험도 함께 넓어진다. 각 기능에 인자 검증과 권한 표기를 갖춰야 하는 부담도 크다. 조회와 저부작용 기능부터 제한적으로 열고, 사용 데이터를 바탕으로 확대하는 방식이 오남용 위험과 품질 관리를 함께 다룬다.

통합과 보안에서 확인할 지점

도구 선언 메타데이터와 버전 호환성 정책은 웹 표준의 확장성과 후방 호환 요건을 따른다. 표준 미지원 클라이언트에 기존 화면 경로를 남겨두는 것은 점진적 향상 원칙에 해당한다.

선언형 도구 호출은 화면 기반 통합을 인터페이스 기반 통합으로 옮기는 변화다. 도구 호출과 화면 경로가 처리 로직을 공유하도록 하는 일은 통합 지점의 단일 진실 원천을 유지하는 조건이기도 하다.

권한 요구 수준 표기와 동의 흐름은 접근 통제와 정보주체 동의 관리를 결합한다. 악성 선언 탐지는 신뢰할 수 없는 입력을 실행 지시로 받아들이는 위험을 통제하는 장치다.

표준화 흐름에서 준비할 일

WebMCP 제안은 표준화 절차를 거치며 브라우저 구현이 등장하고 초기 채택 사이트가 늘어나는 방향으로 움직이고 있다. 도구 선언을 통해 사이트가 자동화 허용 범위를 통제하는 관행이 자리 잡으면, 차단과 우회의 구도도 완화될 수 있다.

클라이언트에서는 선언 내용과 실제 동작의 정합 검증이 필수 기능으로 요구되는 흐름이 예상된다. 서비스 제공자에게는 기존 공개 API를 표준 선언으로 감싸는 어댑터 패턴이 현실적인 도입 경로가 될 수 있다.