개방형 생성형 UI
개방형 생성형 UI (Open-ended Generative UI)
생성형 UI 스펙트럼에서 "에이전트가 전부 만들어내는" 쪽 끝이 바로 개방형(open-ended) 생성형 UI예요. 이 방식에서는 인터페이스가 여러분의 애플리케이션 밖에서 만들어집니다. 예를 들어 MCP 서버가 만들고, 여러분의 프론트엔드는 그걸 샌드박스 안에서 렌더링하는 거죠. 컴포넌트는 여러분도, 에이전트도 쓰지 않아요 — 제3자가 제공하고, 여러분의 앱이 호스팅합니다.
개요
이 접근 방식은 가장 넓은 표현 범위를 제공합니다. 에이전트가 캔버스를 소유하니까요. 어떤 기능(capability)이 이미 만들어진 인터페이스를 갖고 도착할 수 있어서, 여러분이 한 번도 구현해 본 적 없는 인터랙티브 도구를 프론트엔드 코드 한 줄 없이 표면화할 수 있어요. 일회성 시각화나 결과가 예측 가능한 것보다 "놀랍고 충분히 좋은" 것을 선호하는 맞춤형 답변에 잘 맞습니다.
다만 이 방식은 가장 실험적이고, 가장 비결정적이며, 실행이 더 느리고 비용도 더 듭니다. 또 신뢰할 수 없는 UI(untrusted UI)를 일관되게 만들고, 접근성을 보장하고, 안전하게 유지하는 것이 가장 어렵기 때문에, 반드시 애플리케이션의 나머지 부분과 격리해야 해요.
언제 이 방식을 쓸까요?
애플리케이션 밖에 존재하고, 애플리케이션과 별개로 진화하는 기능과 인터페이스를 표면화하고 싶을 때 개방형 생성형 UI를 쓰면 됩니다. 예를 들어 MCP 서버 생태계가 제공하는 도구들이죠. 반대로 브랜딩, 접근성, 레이아웃을 보장해야 한다면, 스펙트럼을 되돌아가 선언형(declarative) 또는 제어형(controlled) 생성형 UI를 선택하는 것이 좋아요. 그쪽에서는 여러분의 애플리케이션이 컴포넌트를 소유하니까요.
MCP 앱 (MCP Apps)
Model Context Protocol은 에이전트가 도구와 리소스를 제공하는 외부 서버에 연결할 수 있게 해 줍니다. MCP Apps는 그 아이디어를 인터페이스까지 확장한 개념이에요. MCP 서버가 인터랙티브 UI를 제공하고, 프론트엔드가 그것을 보통 iframe 안에서 대화에 직접 렌더링하죠. 서버가 컴포넌트와 데이터, 상호작용을 소유하고, 여러분의 애플리케이션은 프레임과 에이전트와의 연결을 제공합니다.
CopilotKit은 이 패턴을 MCP Apps라고 문서화하고 있어요.
샌드박싱과 안전성
인터페이스가 제3자에게서 오기 때문에, 그것을 신뢰할 수 없는 것으로 취급해야 합니다. 샌드박스된 iframe 같은 격리된 컨텍스트에서 렌더링하고, 잘못 동작하거나 악의적인 앱이 페이지의 나머지 부분이나 사용자 데이터에 닿지 못하도록 접근 범위를 제한하세요. 샌드박싱은 스펙트럼의 개방형 끝을 프로덕션에서 쓸 수 있게 만드는 핵심이에요 — 표현의 범위를 제한하는 게 아니라 안전하게 담아내는 방식이죠.