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

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

사이트가 버튼 하나만 옮겨도 에이전트는 길을 잃어요. 좌표가 어긋나고, 에이전트는 엉뚱한 곳을 누르고 중간에 멈춥니다. 리디자인 한 번이면 그동안 맞춰둔 추측을 통째로 버려야 하거든요.

크롬과 엣지가 만든 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는 그 한 벌을 어디에 적을지 정한 규격이에요. 브라우저가 몇 개 지원하느냐는 그다음 문제입니다.

그보다 먼저, 선언을 적어둔 사이트부터 에이전트 손님을 받을 거예요.

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

못 적는다면 사이트가 뭘 하는 곳인지부터 정리해야 해요.

---