webMCP는 새로운 접근성 계층이 아니라 새로운 공격 표면입니다: 장난스러운 데모에 대한 거버넌스 관점의 재구성

Sylwia Laskowska의 webMCP 기사는 영리하고 재미있으며 진심으로 즐겁습니다. 또한 그녀는 이것이 실험적인 것이며, 프로덕션(production) 권장 사항이 아님을 명시하고 있습니다. 이것은 반박이 아닙니다. 재구성(reframing)입니다. 동일한 데모를 리스크 표면(risk surfaces)과 거버넌스(governance)의 관점에서 바라보는 것입니다. 저의 우려는 그녀의 의도가 아니라, 클라이언트 시스템을 구축하는 초보자들이 장난스러운 데모를 복제해야 할 패턴으로 너무 쉽게 오해할 수 있다는 점에 있습니다.

I. 데모가 재미있었던 이유는 리스크가 실재하기 때문입니다

Sylwia의 기사에서 그녀는 다음과 같이 썼습니다:

webMCP는 웹사이트가 사용 가능한 작업(actions)에 대한 구조화된 정보를 노출할 수 있게 해줍니다…

그 "작업(actions)"들은 단순한 설명적 힌트가 아닙니다. 그것들은 애플리케이션 로직에 직접 연결된 호출 가능한 함수(callable functions)입니다.
그녀의 데모에서 이러한 작업에는 다음이 포함됩니다:

• hire_employee (직원 채용)
• fire_employee (직원 해고)
• rewriteInRust (Rust로 재작성)
• pivotToAgents (에이전트로 전환)

장난감 앱(toy app)에서는 아주 웃기지만, 실제 앱에서는 재앙적입니다. 유머가 통하는 이유는 바로 그 기저에 깔린 리스크가 실재하기 때문입니다.

II. 숨겨진 가정: 작업 노출은 중립적이다

webMCP는 "접근성 메타데이터(accessibility metadata)와 같다"는 식으로 프레임이 잡혀 있습니다. 하지만 접근성 메타데이터는 설명적(descriptive)입니다. webMCP 메타데이터는 실행 가능(executable)합니다.

이것이 대부분의 초보자들이 놓칠 개념적 역전(conceptual inversion)입니다.

III. 구조적 취약점 #1: 경계가 없는 작업 표면 (Unbounded Action Surface)

도구가 존재한다면, 에이전트(agent)는 그것을 호출할 수 있습니다. 여기에는 다음이 없습니다:

• 권한 모델 (permission model)
• 권한 범위 지정 (capability scoping)
• 속도 제한 (rate limiting)
• 의도 검증 (intent validation)
• 안전 영역 (safety envelope)

Sylwia는 농담조로 말합니다: "누군가는 분명히 에이전트에게 fireEmployee()에 대한 권한을 줄 것이고, 에이전트는 회사 전체를 해고해 버릴 것입니다…"

이것은 가설이 아닙니다. 이것은 정확한 실패 모드(failure mode)입니다.

IV. 구조적 취약점 #2: 에이전트의 권한 남용 (Agent Overreach)

그녀의 CEO 시뮬레이션은 문제를 완벽하게 보여줍니다:

에이전트는 적절한 도구를 선택했고 즉시 작업을 시작했습니다.

에이전트는 자신의 세계 모델(world model)이 불완전할 때조차 높은 확신을 가지고 행동합니다. webMCP는 에이전트에게 애플리케이션 상태(application state)로 직접 들어갈 수 있는 레버를 제공합니다. 이것은 MCP가 가진 것과 동일한 권한 남용 문제이며, 단지 브라우저로 옮겨졌을 뿐입니다.

V. 구조적 취약점 #3: 프로토콜의 취약성 (Protocol Brittleness)

webMCP는 사람이 작성한 설명(descriptions)에 의존합니다:

html<form mcp-name="createSupportTicket" mcp-description="Create a new customer support ticket">

만약 이 설명이 틀렸거나, 불완전하거나, 오해의 소지가 있다면, 에이전트(agent)는 잘못된 동작을 수행할 것입니다.

Sylwia의 기사에 달린 한 댓글은 이 점을 완벽하게 포착했습니다: "ARIA 역할(roles)은 쉬운 부분이었습니다. 진짜 어려운 부분은 흐름(flow)이 실제로 작동하는지 검증하는 것이었습니다."

webMCP는 현재 ARIA 단계에 머물러 있습니다. 하지만 ARIA와 달리, 그 결과는 사용성(usability)에만 국한되지 않습니다. 여기에는 상태 변이(state mutation), 데이터 손실, 그리고 권한 상승(privilege escalation)이 포함됩니다.

VI. 브라우저가 모든 상황을 악화시킨다

webMCP는 MCP의 위험성을 상속받는 동시에 브라우저 특유의 위험성을 추가합니다:

• 인증된 세션 하이재킹 증폭 (authenticated session hijack amplification)
• 교차 사이트 에이전트 오케스트레이션 (cross-site agent orchestration)
• 혼동된 대리인 문제 (confused-deputy problems)
• 드라이브 바이 에이전트 활성화 (drive-by agent activation)
• 교차 애플리케이션 권한 부여 모델의 부재 (no cross-application authorization model)

한 댓글 작성자는 직설적으로 이렇게 말했습니다: "우리는 신호등을 만들기 전에 고속도로를 건설하고 있습니다." 그들의 말이 맞습니다.

VII. 더 나은 프레임워크: 접근성이 아닌 고위험 통합 계층 (High-Risk Integration Layer)

webMCP는 접근성(accessibility)이 아닙니다. 점진적 향상(progressive enhancement)도 아닙니다. 무해한 호환성 계층(compatibility layer)도 아닙니다.

이것은 자율 에이전트(autonomous agents)를 위한 특권 인터페이스(privileged interface)이며, 다음과 같은 요소들이 필요합니다:

• 권한 부여 (authorization)
• 감사 가능성 (auditability)
• 안전 게이트 (safety gates)
• 정책 (policy)
• 기능 엔벨로프 (capability envelopes)
• 상태 전이 검증 (state-transition validation)

만약 당신의 공개 API(public API)에서 특정 동작을 노출하지 않을 것이라면, webMCP에서도 이를 노출해서는 안 됩니다.

결론

Sylwia의 기사는 재미있고 상상력이 풍부하며, webMCP가 무엇을 가능하게 할 수 있는지에 대한 탐구로서 진정으로 가치가 있습니다. 위험 요소들은 실재하며, 구조적이고, 특히 초심자들에게는 놓치기 쉽습니다.

webMCP는 미래 웹의 일부가 될 수도 있습니다. 하지만 그렇게 된다면, 우리가 다른 모든 특권 인터페이스에 적용하는 것과 동일한 엄격함(rigor)이 필요할 것입니다.

그때까지는 이를 접근성 계층이 아니라, 공격 표면(attack surface)으로 취급하십시오.