에이전트 UI의 세 단계
AI가 프론트엔드 코드를 사람보다 잘 짜는 시대에 왜 UI는 아직 정적인 채로 머물러 있을까. AI Engineer 컨퍼런스에서 Postman의 Ruben Casas가 던진 질문입니다. 그는 에이전트 UI의 진화를 세 단계로 정리합니다. 개발자가 미리 만든 컴포넌트에 에이전트가 데이터만 채우는 정적 방식, 에이전트가 JSON 기술서를 쓰면 렌더링 엔진이 디자인 시스템에 매핑하는 선언적 방식, 그리고 모델이 런타임에 HTML과 CSS를 즉석에서 써내는 생성형 컴포넌트입니다.
왜 현재의 균형점은 선언적 방식인가
선언적 방식은 디자인 시스템의 일관성을 지키면서 개인화가 가능하고 비용도 쌉니다. 생성형으로 가지 못하는 것은 능력 문제가 아니라 신뢰 문제입니다. LLM이 즉석에서 쓴 코드를 검증 없이 사용자 화면에 띄울 수는 없으므로, 샌드박스라는 안전한 유통 구조가 먼저 서야 합니다.
MCP 앱이 주목받는 이유
MCP 앱은 인증, 툴 호출, 이중 iframe 샌드박스가 기본으로 갖춰진 구조라서 생성형 UI의 배포 채널 역할을 할 수 있습니다. Anthropic이 자사 시각화 기능을 자체 렌더링 대신 MCP 앱으로 구현한 것이 전략적 신호라는 해석도 있습니다.
TV 비유 — 챗봇 붙이기의 한계
TV가 처음 나왔을 때 사람들은 라디오 쇼에 카메라만 붙였습니다. 홈페이지마다 챗봇 창을 붙이고 있는 지금의 SaaS들이 딱 그 단계입니다. 다음 단계는 사람과 에이전트가 같은 캔버스를 두고 함께 고치는 협업형 UI입니다.
기업 AX를 설계할 때도 같은 질문이 유효합니다. 챗봇을 붙일 것이 아니라, 에이전트와 사람이 함께 일할 인터페이스를 어디에 둘 것인가. SH Consulting이 AX 설계에서 인터페이스 계층을 별도로 다루는 이유입니다.