MCP Apps가 바꾸는 에이전트 UX: 도구 출력은 이제 작은 제품 화면이다

테크
MCP Apps 아키텍처: 사용자 의도, MCP 도구, 샌드박스 iframe UI, 승인된 도구 호출 흐름을 연결한 다이어그램
MCP Apps는 도구 결과를 단순 텍스트가 아니라 대화 안의 샌드박스 UI로 렌더링하는 패턴이다.

AI 에이전트를 실제 업무에 붙여 보면 가장 먼저 부딪히는 한계는 모델 성능이 아니라 인터페이스다. 로그 분석 결과를 표로 보고 싶고, 배포 옵션을 폼으로 고르고 싶고, 계약서의 조항을 클릭해서 검토하고 싶은데, 많은 에이전트 도구는 여전히 긴 텍스트와 JSON 덩어리를 돌려준다. 사용자는 다시 “지난주만 필터링해줘”, “이 행을 펼쳐줘”, “승인 버튼은 어디 있어?”라고 물어야 한다.

MCP Apps는 이 병목을 정면으로 건드린다. Model Context Protocol의 공식 문서는 MCP Apps를 도구가 텍스트 대신 대화 안에서 렌더링되는 인터랙티브 HTML 인터페이스를 반환하는 확장으로 설명한다. 도구는 UI 리소스를 선언하고, 호스트는 이를 샌드박스 iframe으로 렌더링하며, UI와 호스트는 JSON-RPC 기반 통신으로 다시 도구 호출이나 사용자 동의를 연결한다. 즉, 에이전트 도구 출력이 “읽는 응답”에서 “조작하는 작은 제품 화면”으로 바뀐다.

무슨 일이 있었나

핵심 흐름은 세 가지다. 첫째, SEP-1865로 정리된 MCP Apps가 MCP의 공식 확장 트랙에서 Final 상태로 올라와 있다. 둘째, MCP 공식 문서와 블로그는 데이터 탐색, 설정 마법사, 문서 검토, 실시간 모니터링처럼 텍스트만으로는 느린 워크플로를 대표 사례로 제시한다. 셋째, Vercel의 2026년 5월 19일 변경 로그는 Nuxt MCP Toolkit이 MCP Apps를 지원한다고 발표했다. Vue SFC를 app/mcp/ 아래에 작성하고, defineMcpApp과 useMcpApp으로 도구 정의, 사전 로드된 데이터, 후속 도구 호출을 묶는 방식이다.

Microsoft 쪽에서도 같은 방향의 신호가 있다. Microsoft Learn은 declarative agents에 MCP 서버 기반 액션과 UI 위젯을 붙이는 방법을 안내하며, Copilot은 위젯을 별도 렌더러 호스트에서 표시하고 CORS, OAuth/SSO redirect URI, 허용 URL 같은 조건을 요구한다. 이 지점이 중요하다. MCP Apps는 “예쁜 HTML을 반환하면 끝”이 아니라, 호스트별 보안 모델과 배포 조건까지 포함한 제품 통합 문제다.

왜 개발자에게 중요한가

개발팀 관점에서 MCP Apps의 가치는 토큰 절약보다 크다. 기존 MCP 도구는 결과를 모델이 읽고 다시 설명하는 구조에 가까웠다. 그래서 사용자가 직접 탐색해야 하는 데이터, 여러 옵션이 얽힌 설정, 승인·반려 같은 명시적 행위는 매번 자연어 왕복이 필요했다. MCP Apps는 이 왕복을 UI 상호작용으로 바꾼다. 모델은 의도를 해석하고 적절한 도구를 고르며, 사용자는 표, 그래프, 폼, 체크리스트, 미리보기 같은 익숙한 UI에서 결정을 내린다.

이 변화는 에이전트 개발의 책임 경계도 바꾼다. 도구 작성자는 더 이상 “JSON 스키마만 잘 만들면 된다”고 생각하기 어렵다. 어떤 데이터는 모델 컨텍스트로 보내고, 어떤 데이터는 UI에만 전달할지 나눠야 한다. 어떤 버튼은 단순 필터인지, 어떤 버튼은 실제 시스템 변경을 일으키는지 구분해야 한다. UI가 도구 호출을 요청할 때 사용자 동의, 감사 로그, 실패 복구를 어떻게 남길지도 설계해야 한다.

커뮤니티 신호: 기대보다 혼란이 더 크다

커뮤니티 반응은 아직 “대세가 됐다”보다 “왜 아직 크게 퍼지지 않았나”에 가깝다. Reddit의 최근 토론은 MCP Apps가 MCP나 Skills만큼 바이럴하지 않은 이유를 묻는다. Microsoft Q&A에서도 MCP Inspector에서는 위젯이 보이는데 Microsoft 365 Copilot Chat에서는 텍스트만 반환되는 사례가 올라왔다. 이 글은 사실 출처가 아니라 실무 신호다. 개발자들은 이미 인터랙티브 에이전트 UI를 원하지만, 호스트 지원 여부, 메타데이터, CORS, 인증, 위젯 렌더러 도메인, 배포 채널에서 막히고 있다.

그래서 지금 MCP Apps를 볼 때의 올바른 태도는 “당장 모든 챗봇 UI가 앱 플랫폼으로 바뀐다”가 아니다. 더 현실적인 결론은 “에이전트 도구가 제품화될 때 필요한 UI 표준이 생겼고, 프레임워크와 엔터프라이즈 호스트가 이를 흡수하기 시작했다”이다.

실무 영향

MCP Apps를 도입하기 전에 결정할 것

  • 도구 결과 중 모델이 읽어야 하는 요약과 UI만 써야 하는 상세 데이터를 분리한다.
  • UI 리소스는 ui:// 같은 선언형 리소스로 관리하고, 번들 크기와 초기 로딩 시간을 측정한다.
  • 모든 상태 변경 버튼은 사용자 동의, 재시도, 감사 로그, 롤백 가능성을 기준으로 분류한다.
  • 호스트별 차이를 문서화한다. Claude, ChatGPT, Microsoft 365 Copilot, VS Code 계열은 렌더링·인증·권한 요구사항이 다를 수 있다.
  • MCP Inspector 통과를 최종 검증으로 보지 않는다. 실제 배포 호스트에서 CORS, OAuth redirect, iframe CSP를 확인해야 한다.

프론트엔드 팀에는 새로운 기회가 열린다. 지금까지 에이전트 도구는 백엔드 통합과 스키마 설계가 중심이었다. MCP Apps에서는 UI 컴포넌트의 접근성, 빈 상태, 로딩 상태, 오류 상태, 키보드 조작, 반응형 레이아웃이 그대로 중요해진다. 사용자는 “AI가 보여준 것”이라고 관대하게 봐주지 않는다. 버튼이 위험한 동작을 한다면 확인이 필요하고, 차트가 오해를 부르면 레이블이 필요하며, 폼이 실패하면 이유를 설명해야 한다.

백엔드와 플랫폼 팀에는 운영 문제가 생긴다. 위젯이 서버 도구를 다시 호출할 수 있다면, 도구 호출은 더 이상 한 번의 LLM 응답에 갇히지 않는다. 사용자가 UI 안에서 필터를 바꾸거나 승인 버튼을 누를 때마다 서버 호출, 권한 확인, rate limit, 감사 이벤트가 발생한다. 이는 일반 웹 앱 운영과 비슷하지만, 차이점은 대화형 호스트, 모델 컨텍스트, 외부 도구 권한이 한 흐름 안에 섞인다는 것이다.

좋은 적용 사례와 피해야 할 사례

MCP Apps가 특히 잘 맞는 곳은 반복적인 자연어 왕복을 줄일 수 있는 업무다. 예를 들어 배포 설정 마법사, 장애 타임라인, 비용 분석 대시보드, CRM 레코드 검토, 문서 승인, 데이터 필터링, 보안 이벤트 triage가 있다. 사용자가 데이터를 직접 훑고, 선택하고, 확인해야 하는 업무라면 텍스트보다 UI가 낫다.

반대로 단순 질의응답, 짧은 요약, 한 번만 읽고 끝나는 결과에는 과하다. 작은 MCP 도구에 무거운 프론트엔드 빌드 파이프라인을 붙이면 유지보수 면적만 늘어난다. 또한 모델이 실제로 봐야 할 판단 근거를 UI에만 숨겨두면 에이전트는 후속 대화에서 맥락을 잃을 수 있다. UI와 모델 컨텍스트를 분리하되, 모델이 책임 있게 설명해야 하는 요약은 반드시 별도로 제공해야 한다.

개발 체크리스트

  • 스키마: tool input/output schema를 먼저 안정화하고, UI는 그 위에 얇게 얹는다.
  • 권한: 읽기 전용 상호작용과 상태 변경 상호작용을 분리한다. 상태 변경은 항상 명시적 동의와 감사 로그를 남긴다.
  • 보안: iframe sandbox, CSP, 허용 origin, OAuth redirect URI를 배포 호스트 기준으로 테스트한다.
  • 접근성: 표, 차트, 폼에 키보드 탐색과 대체 텍스트를 제공한다. 에이전트 UI도 제품 UI다.
  • 관찰성: tool call, UI action, consent event, failure reason을 같은 trace에서 볼 수 있게 만든다.
  • 호환성: MCP Inspector, 로컬 호스트, 실제 호스트를 분리해 검증한다. Inspector에서 보인다고 최종 사용자에게 보인다는 뜻은 아니다.

리스크와 반론

첫 번째 반론은 표준과 구현이 아직 움직이고 있다는 점이다. SEP-1865는 Final 상태지만, 호스트별 구현과 SDK 지원은 계속 달라질 수 있다. 두 번째는 보안이다. UI가 도구를 호출하고 사용자의 연결된 기능을 위임받을 수 있다면, 클릭 한 번의 의미가 커진다. “대화 안에 있으니 안전하다”는 가정은 위험하다. 오히려 대화 안에 있기 때문에 사용자는 더 쉽게 신뢰할 수 있고, 그만큼 승인·권한·로그가 더 중요하다.

세 번째는 제품 복잡도다. MCP Apps는 멋진 데모를 만들기 쉽지만, 장기적으로는 또 하나의 UI 표면을 운영하는 일이다. 디자인 시스템, 테마, i18n, 오류 문구, 브라우저 호환성, 보안 업데이트가 따라온다. 그래서 모든 도구를 앱으로 만들기보다, 텍스트 왕복 비용이 높고 사용자의 직접 조작이 명확한 업무부터 시작하는 편이 낫다.

결론

MCP Apps의 의미는 “챗봇 안에 HTML을 넣자”가 아니다. 더 정확히는 에이전트 도구의 출력 계약이 넓어졌다는 것이다. 이제 좋은 도구는 모델이 이해할 수 있는 구조화된 결과와, 사람이 조작할 수 있는 안전한 UI를 함께 설계해야 한다. 개발팀이 오늘 할 일은 거창한 앱 스토어 전략이 아니라 작고 위험이 낮은 내부 워크플로 하나를 고르는 것이다. 로그 triage, 배포 승인, 비용 리포트처럼 텍스트 왕복이 반복되는 업무를 골라 MCP Apps가 실제 시간을 줄이는지, 그리고 보안·관찰성·호스트 호환성 비용이 감당 가능한지 검증해볼 만하다.

출처

다른 글