WebMCP: 프론트의 시대는 다시 오는가?

지금 AI 에이전트는 웹을 제대로 “사용”하지 못합니다. 마치 지도 없이 외국 도시를 돌아다니는 여행자처럼, 화면을 캡처하고 HTML을 억지로 파싱하며 버튼의 의미를 추측합니다. 그리고 작은 UI 변경 하나에도 전체 동작이 깨집니다. 느리고, 비싸고, 무엇보다 구조적으로 불안정합니다. 이 문제를 단순히 “AI가 아직 부족해서”라고 생각하기 쉽지만, 사실 더 근본적인 이유가 있습니다. 바로 **웹의 구조 자체가 AI를 위해 설계되지 않았다는 점**입니다. ## DOM은 원래 사람을 위한 인터페이스였다 지금까지 웹은 DOM(Document Object Model) 중심으로 발전해왔습니다. DOM은 클릭, 스크롤, 입력과 같은 인간의 인터랙션을 전제로 만들어진 구조입니다. 즉, “보여주기 위한 인터페이스”입니다. 하지만 AI에게 DOM은 전혀 다른 의미를 가집니다. 버튼이 무엇을 하는지 알 수 없고, input 필드가 어떤 데이터를 요구하는지 이해하지 못하며, form이 어떤 기능을 수행하는지도 명확하지 않습니다. 결국 AI는 모든 것을 추측해야 합니다. HTML 구조를 분석하고, 요소의 역할을 가정하고, 클릭과 입력을 시뮬레이션하며, 실패하면 다시 시도하는 방식입니다. 이 과정은 단순히 비효율적인 수준이 아닙니다. **구조적으로 잘못된 접근 방식**입니다. DOM은 “의미”가 아니라 “표현”이기 때문입니다. ## DOM 기반 웹의 한계: 비용, 불안정성, 그리고 의미의 부재 이 구조가 만들어내는 문제는 세 가지로 정리됩니다. 첫째, 비용입니다. DOM을 파싱하고, 화면을 캡처하고, 반복적으로 시도하는 과정은 토큰과 연산 비용을 급격히 증가시킵니다. API 호출 한 번으로 해결될 일을 수십 단계로 나눠 처리하는 셈입니다. 둘째, 불안정성입니다. 클래스명이 바뀌거나 DOM 구조가 조금만 변경되어도 전체 로직이 무너집니다. UI 리디자인은 곧 AI 사용성의 붕괴를 의미합니다. 셋째, 의미의 부재입니다. DOM은 `

검색

`과 같은 형태로 “보여주기”는 하지만, 그것이 “search(query)”라는 기능이라는 사실은 담고 있지 않습니다. AI가 필요로 하는 것은 구조화된 함수 호출입니다. 하지만 DOM은 그 정보를 제공하지 않습니다. ## WebMCP: DOM을 더 잘 파싱하는 것이 아니라, 아예 우회한다 이 지점에서 등장하는 개념이 WebMCP(Web Model Context Protocol)입니다. WebMCP의 핵심은 단순합니다. DOM을 더 잘 이해하려는 것이 아니라, **DOM 자체를 거치지 않게 만드는 것**입니다. 기존에는 AI가 DOM을 읽고, 해석하고, 추론해야 했다면, WebMCP 환경에서는 웹사이트가 직접 이렇게 말합니다. “이건 searchFlights라는 함수고, origin, destination, date를 입력하면 결과를 줄게.” AI는 더 이상 버튼을 찾거나 클릭을 시도하지 않습니다. 그냥 함수를 호출하고 결과를 받습니다. 수십 번의 인터랙션이 하나의 호출로 대체됩니다. ![WebMCP 도입전후 AI 에이전트 작동방식의 차이를 비교하는 이미지](https://cdn.trychainshift.ai/cms/workspaces/37/images/01a1771e-2b3e-7666-b1f7-1f2716ff04d8-7uA0Ci7vhvjIl854fO6ertw72Q.webp) *WebMCP 도입전후 AI 에이전트 작동방식의 차이를 비교하는 이미지* ## 웹의 역할이 바뀐다: 페이지에서 기능으로 이 변화는 단순한 기술 업데이트가 아니라, 웹의 정의 자체를 바꾸는 변화입니다. 과거에 웹은 페이지였습니다. 그 다음에는 콘텐츠 중심으로 진화했습니다. 그리고 이제 웹은 **기능(Function)**으로 재정의되고 있습니다. 중요한 것은 더 이상 “얼마나 잘 보여주느냐”가 아닙니다. **얼마나 잘 실행되느냐**입니다. ## SSR vs 프론트 논쟁, 완전히 다른 질문이 필요하다 이 지점에서 자연스럽게 나오는 질문이 있습니다. “이제 다시 프론트엔드의 시대가 오는 것 아닌가?” 하지만 이 질문 자체가 잘못된 프레임입니다. CSR로 돌아가는 것도 아니고, SSR이 끝나는 것도 아닙니다. 실제 변화는 그보다 한 단계 위에서 일어납니다. 이제 웹은 세 개의 레이어로 나뉩니다. - 사람을 위한 HTML (SSR/SSG) - 검색엔진을 위한 구조화된 콘텐츠 (SEO/AEO) - AI를 위한 실행 인터페이스 (WebMCP) DOM은 여전히 필요합니다. 하지만 더 이상 인터페이스의 중심의 웹이 아니라, AI를 감안한 **렌더링 결과물이 함께 중요해지는 시점입니다.** ## 마케터와 제품팀이 반드시 이해해야 할 변화 이 변화는 마케팅 전략에도 직접적인 영향을 줍니다. 많은 팀들이 여전히 “콘텐츠를 많이 만들면 AI 노출이 된다”고 생각합니다. 하지만 AI는 콘텐츠를 단순히 읽지 않습니다. **사용할 수 있는지를 기준으로 선택합니다.** 이제 GEO 전략은 인용되는 것을 넘어서 **AI의 workflow 안에 들어가는 것**으로 진화합니다. 예를 들어 여행 서비스를 생각해보면, 과거에는 “추천 여행지 콘텐츠”가 중요했다면, 앞으로는 AI가 바로 예약을 실행할 수 있는 구조를 가진 사이트가 선택됩니다. ## 그래서 지금 무엇을 해야 하는가 이 변화에 대응하기 위해 필요한 것은 명확합니다. 첫째, DOM을 정리해야 합니다. 불필요한 구조를 제거하고, semantic HTML과 명확한 form 구조를 갖추는 것이 WebMCP의 전제 조건이 됩니다. 둘째, 핵심 action을 정의해야 합니다. 검색, 예약, 구매, 상담과 같은 기능을 “페이지”가 아니라 “함수” 단위로 나눠야 합니다. 셋째, UI를 기능으로 재해석해야 합니다. 버튼은 함수 호출이고, 폼은 input schema이며, 결과 페이지는 response입니다. 넷째, KPI를 바꿔야 합니다. 노출과 클릭이 아니라, **AI 실행률과 task 완료율**이 핵심 지표가 됩니다. ## 결론: DOM은 끝난 것이 아니라, 역할이 바뀌었다 DOM은 지난 30년 동안 웹의 중심이었습니다. 하지만 AI 시대에서 DOM은 더 이상 인터페이스가 아닙니다. 그저 사람이 보기 위한 렌더링 레이어일 뿐입니다. WebMCP는 웹을 다시 인터페이스로 되돌리는 시도입니다. 단, 이번에는 사람을 위한 인터페이스가 아니라 **AI가 직접 사용할 수 있는 인터페이스**입니다. 그리고 이제 가장 중요한 질문은 이것입니다. > 당신의 웹사이트는 > AI가 “읽을 수 있는가”가 아니라 > AI가 “사용할 수 있는가" Reference [https://developer.chrome.com/blog/webmcp-epp?hl=ko https://news.hada.io/topic?id=26597](https://developer.chrome.com/blog/webmcp-epp?hl=ko)

추천 게시글