2026년 1월, 조용하지만 묵직한 스펙 하나가 공개됐다. MCP Apps—Model Context Protocol의 확장 사양으로, AI 대화창 안에 인터랙티브 HTML UI를 직접 렌더링할 수 있게 해주는 개념이다. 차트, 폼, 대시보드, 지도가 채팅 버블 옆에 살아있는 컴포넌트로 떠오른다. 그리고 거의 같은 시기, vite-plugin-pilot이라는 오픈소스 플러그인이 등장해 AI 에이전트가 브라우저 내부에서 프론트엔드를 직접 디버깅하는 실전 사례를 보여줬다. 이 두 움직임은 각자 독립적으로 보이지만, 사실 같은 방향을 가리키고 있다. AI가 UI의 소비자에서 생산자이자 운영자로 이동하는 전환점.
MCP Apps: 대화창이 곧 UI가 되는 구조
MCP Apps 스펙(dev.to의 finfin 작성 글 참고)이 흥미로운 이유는 단순히 "채팅 안에 예쁜 것을 보여주는" 기능이 아니라는 점이다. 아키텍처를 뜯어보면 세 레이어가 분리되어 있다. MCP Server(도구와 HTML 리소스를 등록하는 백엔드), Host(Claude Desktop, VS Code Copilot 같은 AI 인터페이스), View(샌드박스 iframe 안에서 실행되는 프론트엔드 앱). 이 구조에서 View는 단순한 출력 컨테이너가 아니다. postMessage 기반 JSON-RPC 채널로 Host와 양방향 통신하고, 사용자 인터랙션을 LLM 컨텍스트로 다시 흘려보낸다.
핵심은 두 API다. sendMessage는 사용자가 폼을 제출하거나 액션을 완료했을 때 마치 사용자가 직접 타이핑한 것처럼 LLM에 메시지를 보낸다. updateModelContext는 반대로 조용하다—사용자가 지도에서 특정 지역을 선택하는 동안 좌표를 LLM 컨텍스트에 silently 동기화해두고, 사용자가 "근처 맛집 추천해줘"라고 물을 때 LLM이 이미 맥락을 알고 있게 만든다. 이 두 API의 조합이 MCP App을 단순한 디스플레이에서 진짜 인터랙티브 컴포넌트로 격상시킨다. 입력이 들어오고, 사용자가 행동하고, 출력이 다시 LLM으로 흐른다.
저자가 직접 만든 mermaid-mcp-app은 이 흐름을 잘 보여주는 실전 예제다. Claude Desktop에 MCP 서버를 등록하고 "사용자 인증 플로우차트 그려줘"라고 입력하면, 드래그·줌이 되는 Mermaid 다이어그램이 대화창 안에 인라인으로 렌더링된다. 사용자가 split-view 에디터에서 코드를 수정하면 updateModelContext로 변경사항이 자동 동기화되고, ⌘Enter를 누르는 순간 sendMessage로 LLM이 즉각 반응한다. 이건 "AI가 결과물을 보여주는" 경험이 아니라, AI와 사용자가 같은 캔버스 위에서 실시간으로 협업하는 경험이다.
vite-plugin-pilot: AI 에이전트가 브라우저 안으로
한편, Chrome DevTools MCP의 한계를 우회하는 또 다른 접근이 나타났다. 공식 Chrome DevTools MCP는 Chrome의 디버깅 프로토콜을 통해 연결되기 때문에, 브라우저 익스텐션, 임베디드 WebView, 커스텀 런타임 환경에서는 작동하지 않는다. vite-plugin-pilot(dev.to의 llej 작성 글 참고)은 다른 방식을 택했다. 외부에서 연결하는 대신, 에이전트를 페이지 안에 직접 심는 '인사이더 접근법'이다.
구조는 단순하면서 강력하다. AI 에이전트가 브라우저에서 직접 JS를 eval하고, 페이지와 상호작용하고, 결과를 검증할 수 있다. 멀티탭 지원, Vue/React 컴포넌트 스케줄러 인식, Tampermonkey 유저스크립트를 통한 임의 사이트 연결까지 가능하다. 특히 눈에 띄는 기능은 Alt+Click으로 DOM 요소를 선택하면 Claude Code로 직접 전송할 수 있는 프롬프트가 생성되는 것—브라우저와 터미널 사이를 오가는 복사-붙여넣기 지옥에서 탈출할 수 있는 작지만 실질적인 DX 개선이다. 그리고 이 플러그인 자체가 glm5-turbo + Claude Code로 이터레이션됐다는 사실—빌드하는 도구로 그 도구 자신을 개발한 셀프레퍼런셜한 구조—은 AI 에이전트 기반 개발이 어디까지 왔는지를 단적으로 보여준다.
프론트엔드 설계 패러다임이 흔들리는 지점
두 프로젝트를 함께 놓고 보면 하나의 구조적 전환이 보인다. 지금까지 프론트엔드 개발자는 UI를 설계하고, AI는 그 UI를 통해 사용자와 대화했다. 하지만 MCP Apps는 AI 대화 자체가 UI의 렌더링 컨텍스트가 되는 역전을 만들고, vite-plugin-pilot은 AI 에이전트가 브라우저 런타임 내부에서 UI를 직접 조작하고 검증하는 흐름을 만든다. UI와 AI의 경계가 흐려지는 것이 아니라, 그 경계가 새로운 레이어로 재정의되고 있다.
프론트엔드 개발자에게 이건 꽤 도발적인 질문을 던진다. 컴포넌트를 설계할 때 "사람이 어떻게 볼까"만이 아니라 "AI 호스트가 어떻게 렌더링하고, 에이전트가 어떻게 상호작용할까"를 함께 고려해야 하는 시대가 열리고 있는 것이다. _meta.ui.resourceUri처럼 AI 호스트에게 렌더링 힌트를 주는 메타데이터 설계, ontoolinput vs ontoolresult 타이밍을 활용한 프로그레시브 렌더링 전략, 샌드박스 iframe의 제약 안에서 다운로드·외부 링크를 Host에 위임하는 아키텍처—이것들은 기존 프론트엔드 지식과 완전히 다른 새로운 설계 어휘다.
지금 이 순간, 무엇을 준비해야 하는가
MCP Apps 스펙은 아직 Claude Desktop과 VS Code Copilot 같은 일부 호스트에서만 지원되고, vite-plugin-pilot도 실험적 단계에 가깝다. 하지만 방향성은 분명하다. AI 호스트가 브라우저를 대체하는 게 아니라, 브라우저와 AI 호스트가 공존하는 레이어가 새로 생기고 있다. 그 레이어에서 UI를 설계하는 원리는 지금과 다를 것이다.
당장 프로덕션에 적용할 기술은 아니다. 하지만 프로토타입을 만들어보기엔 지금이 딱 좋은 타이밍이다. mermaid-mcp-app처럼 간단한 MCP App 하나를 직접 빌드해보면, 단순히 스펙을 읽는 것보다 훨씬 빠르게 이 패러다임의 촉감을 잡을 수 있다. 대화창이 UI가 되고, AI가 브라우저 안으로 들어오는 이 전환—프론트엔드 개발자가 가장 먼저 감각을 키워야 할 영역이 바로 여기다.