AI로 홈페이지를 관리 — WebMCP가 바꾸는 것
“AI로 홈페이지를 관리할 수 없냐”는 문의를 자주 받습니다. 대개 AI가 글을 대신 써주거나 챗봇이 문의를 받아주는 그림을 떠올리십니다. 그런데 브라우저 쪽에서 준비 중인 변화는 방향이 반대입니다. AI가 우리 사이트를 관리해 주는 것이 아니라, 우리 사이트가 AI에게 자기 기능을 내주는 쪽입니다. WebMCP라는 웹 표준 제안이 그 이야기입니다.
「AI 홈페이지」라는 말이 왜 콘텐츠 이야기로만 흘렀나요?
AI를 실무에 도입한 많은 부분이 글쓰기였기 때문입니다. 원고를 뽑고, 제목을 바꿔 보고, 요약을 만드는 일에서 효과를 봤습니다. 자연스럽게 “AI 대응”이라는 말도 콘텐츠를 뜻하게 됐습니다.
사이트 쪽에서 할 수 있는 일도 읽히는 것입니다. 제목 위계를 정리하고 구조화 데이터를 붙여서, AI가 답을 만들 때 우리 내용을 근거로 쓰게 만드는 일이지요. 이 흐름은 2026 웹디자인 트렌드 — 진짜 바뀐 것은 화면이 아닙니다에서 숫자와 함께 정리해 두었습니다.
여기까지 우리 쪽 동사는 전부 수동태였습니다. 읽히고, 인용되고, 언급되는 것. 사이트가 AI에게 무언가를 시킬 수 있다는 발상은 아직 없었습니다.
지금 AI 에이전트는 우리 사이트를 어떻게 쓰고 있나요?
사람을 흉내 냅니다. 화면을 캡처하고 페이지 구조를 훑어서 “장바구니 담기 버튼이 어디 있나”를 추측한 다음, 마우스 클릭을 흉내 내 누릅니다. 다음 화면이 뜨면 그 과정을 처음부터 다시 합니다.
WebMCP 표준안은 이 방식을 “부서지기 쉬운(brittle) UI 조작”이라고 부릅니다. 버튼 이름을 「문의하기」에서 「상담 신청」으로 바꾸면 어제까지 되던 일이 오늘 안 됩니다. 화면 하나를 옮기는 개편은 말할 것도 없습니다.
에이전트가 우리 사이트에서 막혀도 실패로 집계되는 곳이 없습니다. 사람이라면 문의가 줄거나 이탈률이 오르는 식으로 신호가 잡히지만, 에이전트가 중간에 포기한 일은 어느 지표에도 안 남습니다. 그래서 화면을 바꿀 때마다 끊기는 경로가 생깁니다.
WebMCP는 무엇을 바꾸나요?
페이지가 자기 기능을 도구 목록으로 정리해 브라우저에 등록합니다. 「자료 검색」, 「문의 보내기」, 「견적 계산」처럼 이름과 설명을 붙이고, 어떤 값을 받는지도 함께 적습니다. 에이전트는 화면을 추측하는 대신 그 목록을 받아 읽고, 필요한 도구를 골라 실행합니다.
마이크로소프트와 구글 엔지니어들이 2025년 8월 W3C 웹 머신러닝 커뮤니티 그룹에 처음 냈고, 지금도 다듬는 중입니다. 동작 방식은 이렇습니다.
- 등록. 페이지가 자기 기능을 도구로 올립니다. HTTPS 페이지에서만 됩니다.
- 발견. 에이전트가 지금 이 페이지에 어떤 도구가 있는지 목록을 받습니다.
- 실행. 브라우저가 중간에서 확인한 뒤 그 페이지의 코드로 도구를 돌립니다.
- 응답. 결과가 정해진 형식으로 돌아가고, 화면도 함께 바뀝니다.
눈여겨볼 대목은 4번입니다. 에이전트가 우리 사이트를 우회하지 않고 통과합니다. 사용자는 자기 화면에서 무슨 일이 벌어지는지 그대로 보고, 우리는 방문 기록을 그대로 가져갑니다.
표준안은 <form> 요소를 브라우저가 알아서 도구로 바꾸는 방식도 함께 담고 있습니다. 브라우저가 「이건 입력 양식이다」라고 알아볼 수 있게 만들어 둔 폼은 손댈 것이 거의 없고, 겉모습만 폼처럼 보이게 만든 화면은 나중에 도구를 내주기로 할 때 다시 만들어야 합니다. 지금 어떻게 만드느냐가 그때 비용을 가릅니다.
그동안 해온 AI 대응과는 무엇이 다른가요?
대체가 아니라 한 층 위에 쌓이는 이야기입니다. 읽히는 일과 쓰이는 일은 서로 다른 준비를 요구합니다.
| 구분 | 지금까지 (읽히는 층) | 더해질 층 (쓰이는 층) |
|---|---|---|
| AI가 하는 일 | 우리 글을 읽고 답에 인용 | 우리 기능을 직접 실행 |
| 준비하는 것 | 제목 구조 · 구조화 데이터 | 기능을 도구로 등록 |
| 성과가 보이는 곳 | AI 답변에 회사가 언급됨 | 문의 · 조회가 우리 사이트에서 끝남 |
| 지금 상태 | 이미 해야 하는 일 | 브라우저가 실험 중 |
읽히는 쪽이 먼저입니다. AI가 우리 회사를 알아보지 못하면 사용자가 물었을 때 우리가 후보로 떠오르지 않고, 도구를 내놔도 쓸 일이 생기지 않습니다. 그 앞단은 지원사업으로 홈페이지를 만들었는데 성과가 없는 이유에서 다뤘습니다.
우리 사이트에서는 무엇이 도구가 될 수 있나요?
거창한 기능이 아닙니다. 지금 화면에 이미 있는 것들입니다.
- 문의 폼. 사용자가 말로 설명한 내용을 항목에 맞게 채우고, 보내기 전에 화면으로 보여줍니다.
- 견적·비용 계산. 조건을 넣어 결과를 받아 옵니다.
- 자료·카탈로그 검색. 조건에 맞는 제품이나 문서를 찾아 목록으로 돌려줍니다.
- 지점·일정 조회. 지역과 날짜로 걸러 답합니다.
- 사이트 안 검색. 우리 글을 찾아 답의 근거로 씁니다.
도구는 페이지마다 다르게 내놓을 수 있고, 상황에 따라 넣고 뺄 수도 있습니다. 로그인 전에는 조회만 열고, 로그인 뒤에 신청을 여는 식입니다. 사이트 전체를 한 번에 여느냐 마느냐의 문제가 아닙니다.
AI가 우리 사이트를 마음대로 쓰게 되는 것 아닌가요?
당연히 나올 걱정이고, 표준안도 이 문제를 앞에 두고 설계했습니다. 우선 기본값이 「전부 열림」이 아닙니다. 우리가 도구로 올린 것만 보이고, 올리지 않은 기능은 없는 것과 같습니다. 사이트 전체에서 이 기능을 아예 끄는 설정도 따로 있습니다.
표준안이 하지 않겠다고 못 박은 것도 있습니다. 사람이 쓰는 화면을 대체하지 않고, 사람 없이 혼자 도는 자동화를 겨냥하지 않으며, 서버끼리 붙는 기존 연동을 대신하지도 않습니다. 사람이 브라우저 앞에 앉아 있는 상황을 전제로 만들어졌습니다.
물론 걱정이 아예 없는건 아닙니다. 문의 폼을 도구로 열면 사람이 아닌 요청이 늘어날 수 있고, 그 판단은 사이트를 관리하는 우리 몫으로 남습니다. 다만 지금도 에이전트는 이미 우리 사이트를 사용합니다. 화면을 훑어 클릭을 흉내 내는 방식으로 말이지요. WebMCP를 연결한다는 것은 새로 연결하는 것이 아니라, 이미 사용되던 통로를 우리가 정한 모양으로 바꾸는 일에 가깝습니다.
그럼 지금 무엇을 해야 하나요?
지금은 아무것도 안 하셔도 됩니다. 표준이 아직 초안이고, 브라우저마다 상태가 다릅니다. 2026년 9월 기준입니다.
| 대상 | 상태 |
|---|---|
| 크롬 | 149 버전부터 신청한 사이트만 시험 가능 |
| 엣지 | 150 버전부터 신청한 사이트만 시험 가능 |
| 브레이브 | 내장 AI 채팅에 실험 지원 |
| ChatGPT 데스크톱 | 지원 |
| 파이어폭스 · 사파리 | 지지 여부를 논의하는 단계 |
표준이 자리 잡지 못할 가능성도 있습니다. 지금 개발비를 쓰시라고 권하지 않는 이유입니다. 다만 그때 가서 바로 되는 사이트와 다시 만들어야 하는 사이트는 이미 나눠져 있습니다.
- HTTPS. 이 기능은 보안 연결에서만 동작합니다. 대부분 이미 갖춰져 있습니다.
- 화면 없이도 기능이 작동하는가. 사람이 버튼을 눌러야만 도는 기능은 AI에게 내줄 수 없습니다. 버튼과 따로 부를 수 있어야 합니다.
- 폼이 진짜 폼인가. 겉모습만 폼인 화면은 브라우저가 도구로 바꿔 주지 못합니다.
- 페이지 설정을 우리가 다룰 수 있는가. 무엇을 열고 닫을지 정하려면 페이지 상단과 서버 응답에 손이 닿아야 합니다.
4번은 낯선 조건이 아닙니다. 검색엔진에 사이트를 등록할 때 막히는 자리와 같습니다. → 네이버 서치어드바이저 등록하는 데 5분 — 막히는 곳은 다른 데 있습니다
넷 중 어느 것도 디자인을 새로 하는 일이 아닙니다. 사이트를 갈아엎을 이유로 삼지 마시고, 다음에 개편하거나 새로 만들 때 요구사항에 넣어 두시면 충분합니다. 구조부터 다시 보는 순서는 지금 필요한 것은 리뉴얼이 아니라 리스트럭처입니다에 정리해 두었습니다.
이 변화를 어떻게 보면 되나요?
홈페이지의 역할이 하나 늘어나는 겁니다. 지금까지 사이트는 보여주는 것이었습니다. 사람에게는 화면으로, 검색과 AI에게는 의미 구조로 보여줬습니다. 여기에 WebMCP로 도구를 연결해 쓰이는 것이 더해집니다.
이 방향이 반가운 이유가 하나 더 있습니다. AI가 답을 대신 만들어 주면서 사이트 방문은 줄어드는 중인데, 도구는 사용자를 우리 사이트 안으로 다시 데려옵니다. AI가 우리를 요약해 지나가는 대신, 우리 사이트에서 일을 끝내게 됩니다.
결국 준비란 새 기술을 미리 붙이는 일이 아닙니다. 기능이 코드로 정리돼 있고, 폼이 폼이고, 설정에 손이 닿는 사이트를 만들어 두는 일입니다. 이것들은 WebMCP가 없어도 이미 좋은 사이트의 조건입니다.
지금 보고 계신 이 사이트가 그 예시입니다. 문의 페이지는 화면 효과가 아니라 실제 폼 요소로 만들었고, 전 구간이 HTTPS이며, 페이지 상단 설정과 서버 응답을 저희가 직접 다룹니다. 도구를 내주기로 결정하면 새로 만들 것이 없다는 뜻입니다. 준비는 그런 모양으로 하는 것입니다.
