MCP Apps 등장: 대화형 AI를 ‘조작 가능한 UI’로 바꾸는 공식 확장

MCP Apps는 Model Context Protocol(MCP)의 첫 번째 공식 확장으로, AI가 텍스트로만 답하던 방식을 넘어 “대화창 안에서 바로 만지고 조작하는 인터페이스”를 띄울 수 있게 해줍니다. 쉽게 말해, 이제 채팅이 단순 Q&A가 아니라 대시보드·폼·시각화·단계형 워크플로우가 들어오는 작업 공간이 됩니다. 이번 글에서는 MCP Apps가 왜 나왔는지, 어떻게 동작하는지, 무엇이 달라지는지(그리고 무엇을 조심해야 하는지)까지 한 번에 정리해볼게요.

MCP Apps란? ‘말로 설명’ 대신 ‘화면으로 보여주는’ AI

지금까지 MCP 도구는 데이터를 가져오거나 작업을 실행한 뒤, 결과를 텍스트(또는 구조화된 데이터)로 돌려주는 방식이 일반적이었습니다. 문제는 결과가 복잡해질수록 “요약”만으로는 부족해진다는 점이죠.

MCP Apps는 여기서 한 발 더 나아가, 도구가 결과와 함께 UI를 반환할 수 있게 합니다. 대화 중간에 차트가 뜨고, 필터를 바꾸면 즉시 내용이 바뀌고, 체크박스로 승인/반려를 누르면 모델이 그 행동을 ‘보고’ 다음 단계를 이어가는 식입니다. MCP Core 유지보수팀은 이를 MCP의 첫 공식 확장으로 발표하며, 프로덕션 준비가 되었다고 못 박았습니다¹.

왜 필요한가: “데이터 300줄 요약”이 해결 못 하는 순간들

예를 들어 “지난달 매출 데이터에서 이상치만 골라줘”를 생각해봅시다. 모델이 요약은 잘합니다. 하지만 사람은 대개 그 다음을 원해요. “지역별로 다시 보고”, “특정 계정만 눌러 상세로 들어가고”, “기간 슬라이더로 범위를 바꾸고”… 이런 탐색은 텍스트로 하면 매번 프롬프트를 추가해야 해서, 대화가 금방 ‘질문-대답-질문-대답’ 미로가 됩니다.

MCP Apps는 이 지점의 병목을 겨냥합니다. 탐색은 UI가 맡고, 모델은 사용자의 선택과 흐름을 이해한 상태로 안내/자동화에 집중합니다. 특히 실시간 업데이트, 네이티브 미디어 뷰어(PDF 등), 상태 유지 같은 “텍스트로는 불편한 기능”이 대화창 안에서 자연스럽게 돌아가도록 설계돼 있습니다¹.

어떻게 동작하나: UI 리소스 + 샌드박스 iframe + JSON-RPC

구조는 생각보다 명확합니다. 도구(tool)가 “나 UI도 있어요”라고 메타데이터로 알려주면, 클라이언트(호스트)가 해당 UI 리소스를 불러와 대화창에 렌더링합니다. 이 UI는 샌드박스된 iframe 안에서 실행되고, 호스트와 UI는 JSON-RPC 메시지로 통신합니다¹.

중요한 포인트는 “UI가 단순히 웹페이지를 보여주는 수준이 아니라”는 점입니다. UI는 필요하면 서버 도구 호출을 트리거할 수 있고, 사용자의 클릭/선택 같은 이벤트를 모델 컨텍스트에 업데이트해서 다음 응답의 재료로 쓸 수 있습니다. 즉, 모델이 사용자 행동을 ‘감지’하는 인터랙티브 루프가 만들어집니다¹.

어떤 UI가 가능해지나: 대시보드·마법사·문서리뷰·모니터링

활용 시나리오는 이미 꽤 구체적으로 제시됐습니다. 대화 안에서 필터 가능한 분석 대시보드가 뜨는 데이터 탐색, 선택값에 따라 항목이 늘어나는 구성 마법사, PDF를 인라인으로 보여주고 중요한 조항을 하이라이트하는 문서 검토, 그리고 서버 메트릭이 자동 갱신되는 실시간 모니터링 같은 패턴이 대표적입니다¹.

흥미로운 건 이 변화가 “AI가 다른 앱을 대신 실행해준다”에서 끝나지 않는다는 점이에요. The Register는 이 기능을 두고, 채팅 환경이 여러 앱을 가로지르는 인터페이스 레이어처럼 변할 수 있다고 짚었습니다. 사용자는 앱을 옮겨 다니지 않고도, 대화창에서 필요한 화면을 띄워 작업을 이어갈 수 있다는 거죠².

개발자에게 좋은 점: ‘클라이언트별 UI 코드’에서 해방

개발자 관점에서 MCP Apps의 매력은 “한 번 만들면 여러 클라이언트에서 동작”에 있습니다. 기존엔 어떤 플랫폼에 임베딩하느냐에 따라 UI/연동 방식을 따로 맞추는 일이 흔했는데, MCP Apps는 이를 공통 표준으로 묶어주는 쪽으로 갑니다.

공식 발표 기준으로 Claude, Goose, Visual Studio Code Insiders가 이미 지원하고, ChatGPT도 지원이 시작된다고 안내됐습니다¹. 즉 도구 제작자는 특정 클라이언트에 종속된 화면을 따로 만들지 않고도, 다양한 호스트에서 일관된 인터랙티브 경험을 배포할 수 있는 길이 열린 셈입니다.

보안 모델: “남이 만든 UI 코드를 내 대화창에 띄운다”는 현실

여기서부터는 설렘과 함께 긴장해야 합니다. MCP Apps는 “서버가 제공한 UI 코드”를 클라이언트에서 실행하는 모델이기 때문에, 신뢰 경계가 확 달라집니다. 공식 문서에서도 연결 전 MCP 서버를 신중히 검증하라고 강하게 권고합니다¹.

대신 방어 장치도 여러 겹입니다. UI는 제한된 권한의 샌드박스 iframe에서 실행되고, UI↔호스트 통신은 로그 가능한 JSON-RPC로 오가며, UI가 시작한 도구 호출은 호스트가 사용자 동의를 요구하도록 설계할 수 있습니다¹. The Register 역시 “코드를 직접 작성하지 않았다는 점”을 위험 요소로 지적하면서, 샌드박싱/감사 가능 메시징/승인 흐름을 핵심 방어로 소개했습니다².

시사점 내용 (핵심 포인트 정리 + 개인적인 생각 또는 실용적 조언)...

MCP Apps는 한 문장으로 정리하면 “대화형 AI의 출력물을 ‘조작 가능한 작업 화면’으로 바꾸는 표준”입니다. 요약 중심의 도구 사용에서, 탐색·검토·결정·모니터링 같은 인간의 상호작용을 대화 한복판으로 끌고 들어왔다는 점이 큽니다.

다만 운영 관점에서는 ‘연결할 서버를 검증하는 습관’이 필수가 됩니다. 앞으로는 좋은 MCP 서버를 고르는 능력이, 좋은 앱을 고르는 능력만큼 중요해질 가능성이 큽니다. 처음 도입한다면 사내 검증된 서버로 작게 시작하고, UI가 트리거하는 도구 호출에는 동의(approval) 정책을 강하게 거는 쪽을 추천합니다.

참고

¹MCP Apps - Bringing UI Capabilities To MCP Clients | Model Context Protocol Blog

²Claude supports MCP Apps, presents UI within chat window • The Register