크롬과 엣지가 사이트에게 할 수 있는 일을 미리 적어두라고 했습니다

에이전트에게 웹사이트 일을 시켜본 사람은 그 장면을 압니다. 화면을 통째로 찍어 모델에게 보여주고, 어느 자리를 눌러야 하냐고 묻습니다. 모델이 찍어준 좌표를 클릭하고, 다시 화면을 찍고, 또 묻습니다.

사이트가 버튼 하나만 옮겨도 이 절차는 무너져요. 좌표가 어긋나고, 에이전트는 엉뚱한 자리를 누르고, 작업은 중간에서 멈춥니다. 리디자인 한 번이면 그동안 맞춰둔 추측이 통째로 폐기되거든요.

크롬과 엣지가 만든 WebMCP는 이 절차를 지웁니다. 사이트가 자기가 할 수 있는 일을 이름과 설명, 입력 타입까지 붙여 미리 적어 둬요. 에이전트는 화면을 뜯어보는 대신 그 목록을 읽고 그중 하나를 부릅니다.

아크샤이 파차르가 8월 28일에 올린 해설 「WebMCP Clearly Explained」가 이 구조를 정리했습니다. 소개 트윗은 조회 10만 6,754를 받았습니다.

에이전트가 페이지를 못 읽는 게 문제일까요?

파차르는 문제를 다른 자리에 놓습니다.

"그러니까 문제는 에이전트가 페이지를 잘 못 읽는다는 게 아닙니다. 페이지가 사람 말고 다른 무엇을 위해 쓰인 적이 없다는 겁니다."

이 문장이 글 전체를 지탱합니다.

읽기 능력을 탓하면 처방은 더 큰 모델, 더 정밀한 화면 인식 쪽으로 갑니다. 쓰인 적이 없다고 보면 처방이 반대쪽으로 가요. 페이지가 자기 할 일을 스스로 적어 두면 됩니다.

파차르는 같은 진단을 한 줄 더 밀어붙입니다.

"웹은 30년간 레이아웃으로 사람에게 자신을 설명해 왔고, 프로그램에는 그에 해당하는 게 없습니다."

레이아웃은 사람에게만 통하는 설명이에요. 굵은 글씨는 중요하다는 뜻이고, 오른쪽 아래 파란 사각형은 눌러도 된다는 뜻이죠. 사람은 이 규칙을 배운 적 없이도 압니다. 프로그램은 모릅니다.

30년을 쌓아온 이 설명 체계 전체가, 기계 앞에서는 한 장짜리 그림으로 납작해져요.

웹에 에이전트를 붙이는 길은 몇 개나 될까요?

파차르는 여섯 갈래를 세워 놓고 비교합니다.

첫째, 날 API를 직접 부르는 방식입니다. 둘째, 백엔드에 MCP 서버를 세워 붙이는 방식이에요. 셋째, 컴퓨터 유즈입니다. 화면을 보고 마우스와 키보드를 흉내 냅니다.

넷째, 브라우저 자동화예요. 스크립트로 페이지를 조작합니다. 다섯째, WebMCP입니다. 여섯째, 사이트가 자기 페이지 안에 챗봇을 박아두는 방식이고요.

여섯 갈래가 겨냥하는 목표는 같습니다. 사람이 손으로 하던 클릭을 프로그램이 대신하게 만드는 일이죠. 목표가 같은데 결과가 갈리는 이유를 파차르는 축 세 개로 잡아냅니다.

세 가지를 물으면 왜 하나만 남을까요?

축은 이렇습니다. 하나, 누구의 에이전트를 쓰는가. 둘, 따로 설정할 게 있는가. 셋, 받는 것이 무엇인가.

첫째 축은 주도권을 묻습니다. 내가 고른 모델, 내가 쓰던 에이전트가 그대로 들어가는지, 아니면 사이트가 골라둔 봇을 써야 하는지 갈려요.

둘째 축은 진입 비용을 묻습니다. 서버를 세우고 키를 발급하고 연결을 잡아야 하는지, 아니면 페이지를 열자마자 붙는지 갈리죠.

셋째 축은 받아 드는 물건을 묻습니다. 이름 붙은 액션을 받는지, 아니면 화면 한 장을 받아 알아서 해석해야 하는지 갈립니다.

파차르가 여섯 갈래를 이 축에 대보고 내린 결론은 한 줄입니다.

"WebMCP는 셋을 전부 지키는 유일한 방식입니다. 내 에이전트, 설정할 것 없음, 추측 대신 진짜 이름 붙은 액션."

축을 그대로 대보면 나머지가 어디서 걸리는지도 보입니다.

사이트에 박힌 챗봇은 사이트가 고른 모델이라 첫째 축에서 걸려요. 백엔드 MCP 서버는 서버를 세워야 하니 둘째 축에서 걸립니다. 컴퓨터 유즈와 브라우저 자동화는 화면과 좌표를 받으니 셋째 축에서 걸리고요.

선언이 추측을 이긴다는 말은 무슨 뜻일까요?

파차르가 꼽은 이점은 다섯 가지입니다.

첫째, 추측이 멈춥니다. 에이전트가 좌표를 맞힐 일이 없어요. 부를 이름이 이미 적혀 있습니다.

둘째, 로그인이 공짜로 넘어옵니다. 액션은 사람이 이미 로그인해 둔 탭 안에서 돌거든요. 따로 토큰을 발급하거나 인증을 새로 태울 자리가 없습니다.

이 대목이 백엔드 MCP 서버와 갈라지는 지점이에요.

셋째, 액션 목록이 페이지마다 달라집니다. 장바구니 화면에서는 장바구니 일이, 검색 화면에서는 검색 일이 노출돼요. 사람이 보는 화면과 에이전트가 받는 목록이 같은 맥락 위에서 움직입니다.

넷째, 화면을 뜯어고칠 일이 없습니다. 사람용 UI는 그대로 두고 선언만 얹어요. 에이전트 대응이 디자인 개편을 부르지 않습니다.

다섯째, 선언 형식이 JSON Schema예요. 모델마다 다른 규격을 맞출 일이 없습니다. 한 번 적어두면 여러 모델이 같이 읽어요.

다섯을 묶으면 방향이 하나로 모입니다. 지금까지 에이전트 쪽이 부담하던 해석 비용을 사이트 쪽 선언 한 줄로 옮기는 겁니다. 해석하는 쪽은 매번 틀릴 수 있지만, 선언하는 쪽은 한 번만 정확하면 되거든요.

개발자가 실제로 쓰는 코드는 얼마나 될까요?

파차르가 보여준 실물은 자바스크립트 툴 객체 하나입니다. 조각은 넷입니다. 이름, 설명, 입력 타입, 그리고 실행할 함수.

앞의 셋은 이미 페이지에 있는 걸 적어두는 일에 가까워요. 버튼에 뭐라고 써 있는지, 그 버튼이 무슨 일을 하는지, 어떤 값을 받는지는 개발자가 이미 압니다. 진짜 새로 짜는 조각은 실행 함수 하나예요.

폼은 더 짧습니다. HTML 속성 두 개를 붙이면 에이전트가 그 폼을 액션으로 읽어요. 새 프레임워크도, 별도 빌드 단계도 없습니다.

이 대목이 앞서 나온 여섯 갈래 비교와 이어집니다. 브라우저 자동화 스크립트는 사이트가 바뀔 때마다 다시 짜야 하고, 백엔드 MCP 서버는 별도 배포 대상이죠. WebMCP는 이미 있는 화면 옆에 설명을 붙이는 작업량입니다.

그래서 지금 붙일 만한 물건일까요?

파차르 자신이 아직 이르다고 적었습니다. WebMCP를 실제로 실은 브라우저는 크롬과 엣지, 한 계열이에요. 표준으로 확정된 상태도 아닙니다.

그러면서도 그는 붙여두라고 권합니다. 근거는 비용이에요. 툴 객체 하나, 폼이면 속성 두 개. 표준이 어디로 가든 잃을 게 거의 없는 크기입니다.

남는 생각

저는 이걸 프로토콜 싸움이 아니라 문서 포맷 문제로 읽습니다.

웹은 30년간 사람에게만 자신을 설명했습니다. 그 설명을 프로그램용으로 한 벌 더 쓰는 일이 지금 시작됐고, WebMCP는 그 한 벌을 어디에 적을지 정한 규격이에요. 브라우저가 몇 개 지원하느냐는 그다음 문제입니다.

선언을 적어둔 사이트와 안 적어둔 사이트가 갈리는 순간이 먼저 옵니다.

만드는 쪽에서 보면 판단이 간단해져요. 에이전트가 우리 사이트에서 뭘 할 수 있어야 하는지, 그 목록을 지금 종이에 적을 수 있는지부터 물으면 됩니다. 적을 수 있으면 코드는 오후 한나절 분량이에요.

못 적으면 그건 WebMCP 문제가 아니라, 사이트가 뭘 하는 곳인지 아직 정리가 안 됐다는 신호예요.

---

원문·소스

• 아크샤이 파차르 소개 트윗 (@akshay_pachaar, 조회 10만 6,754): https://x.com/akshay_pachaar/status/2093452397402317239
• 원문 아티클 「WebMCP Clearly Explained」 (2026-08-28): https://x.com/i/article/2093424400301514752