모델 컨텍스트 프로토콜(Model Context Protocol, MCP) API의 등장은 에이전트 중심 아키텍처 시대의 도래를 예고한다. 이 구조에서는 채팅 인터페이스가 곧 프론트엔드가 되며, 필요할 때마다 UI 컨트롤을 즉석에서 생성한다. 이것이 바로 ‘생성형 UI(generative UI)’다.

새로운 포틀릿의 등장

한때 포털이라는 개념은 모든 사용자에게 개인화된 화면을 제공하겠다는 약속을 내세웠다. 사용자가 곧 제어자가 되는 웹 환경이 마침내 구현될 것처럼 보였다. 그러나 결과는 기대와 달랐다. 이제 생성형 UI는 에이전트형 MCP API와 맞춤형 UI 구성 요소를 결합함으로써, UI 개인화를 전혀 다른 수준으로 끌어올리겠다는 구상을 제시한다.

기존 방식에서는 특정 작업을 수행하는 API를 제공하는 백엔드를 개발하고, 사람이 그 API를 쉽게 활용할 수 있도록 사용자 인터페이스를 따로 구현했다. 새로운 접근 방식에서는 에이전트가 백엔드에서 직접 작업을 수행할 수 있도록 MCP 정의를 제공하고, 프론트엔드는 이러한 기능을 노출하는 정의 집합, 예를 들어 조드(Zod) 스키마와 같은 형태로 바뀐다.

오랜 시간 동안 업계를 지켜보며 얻은 가장 큰 자산은 건전한 회의감이다. 수많은 기술이 등장해 엄청난 가능성을 약속하는 모습을 지켜봤다. 어떤 기술은 실패로 끝나고, 어떤 기술은 중요한 위치를 차지한다. 그리고 실제로 유용한 기술은 결국 개발자의 툴킷으로 자연스럽게 흡수된다.

이러한 회의감은 이제 의식적인 판단이 아니다. 누군가 AI가 필요할 때마다 사용자 인터페이스를 즉석에서 만들어낼 것이라고 말하면, 성능이나 정확성과 같은 문제부터 본능적으로 떠올리게 된다.

그럼에도 불구하고 AI가 개발 전반에 미친 영향은 이미 상당하다. 그렇다면 생성형 UI는 무엇을 의미할까?

생성형 UI 직접 살펴보기

필자는 생성형 UI를 관리형 에이전트 환경의 진화 형태로 본다. 파이어베이스 스튜디오(Firebase Studio)와 같은 환경이 대표적이다. 에이전틱 IDE에서는 원하는 내용을 문장으로 입력하는 것만으로도 UI를 빠르게 프로토타이핑할 수 있다. 생성형 UI는 여기서 한 단계 더 나아간 개념으로, 사용자가 챗GPT와 같은 호스팅된 챗봇에 프롬프트를 입력하면 즉석에서 상호작용 가능한 UI 구성 요소를 만들어내는 구조다.

향후 코드 라이브 프리뷰(Code Live Preview)를 활성화한 제미나이나 챗GPT와 같은 AI 도구가 충분히 강력해질 경우, 사용자는 개발자 관점이 아니라 사용자 관점에서 도구를 활용하게 될 가능성이 크다. 향후에는 코드를 직접 작성하는 시간보다 설계에 더 많은 시간을 쓰고, 문제가 발생하거나 더 높은 수준의 구현이 필요할 때만 개발자 모드로 전환하는 흐름이 점진적으로 자리 잡을 것으로 보인다.

이 개념을 실제로 살펴보기 위해 버셀(Vercel)의 젠UI(GenUI) 데모를 살펴볼 수 있다. 데이터스택스(Datastax)가 미러 형태로 제공하는 버전도 있다. 이 데모는 streamUI 함수를 구현한 사례다.

버셀은 streamUI 함수에 대해 “언어 모델이 생성하는 결과와 함께 리액트 서버 컴포넌트를 스트리밍해 애플리케이션에 동적인 사용자 인터페이스를 통합할 수 있도록 해준다. 버셀 AI SDK에서 제공하는 streamUI 훅에 대한 자세한 내용은 별도 문서를 참고할 수 있다”라고 설명했다.

버셀의 젠UI 데모는 채팅 상호작용과 함께 즉석에서 생성되는 UI 구성 요소가 무엇을 의미하는지 감을 잡게 해준다.

버셀의 젠UI 데모

Foundry

어디까지나 데모이지만, 개념 자체를 전달하는 역할은 충분히 수행한다. 동시에 AI 특유의 허점과 한계도 여실히 드러난다. 예를 들어 주식 거래 채팅 화면에서 “솔라나를 조금 사달라”라고 요청하면 “유효하지 않은 금액”이라는 응답이 돌아온다. 이후 “솔라나 10개를 사달라”라고 다시 요청하자, 구매 버튼이 포함된 단순한 UI 컨트롤이 화면에 표시됐다.

물론 이는 어디까지나 개념을 보여주기 위한 데모일 뿐이며, 실제 구매를 뒷받침하는 인프라는 전혀 연결돼 있지 않다. 지갑이나 은행 계좌를 연동하고, 이에 따른 각종 인증 절차를 구현해야 한다는 점을 고려하면, 이러한 인프라를 구축하는 작업은 결코 간단하지 않다.

이는 결함을 지적하기 위한 데모가 아니다. 일부 문제는 개발자의 집중적인 작업을 통해 충분히 개선할 수 있다. 반면 다른 문제는 현재 LLM이 지닌 구조적 한계에서 비롯된다. 이 데모에서 말하고자 하는 것은, AI나 에이전틱 도구를 사용할 때 처음에는 엄청난 가능성이 펼쳐지는 듯한 인상을 받지만, 곧이어 상당한 좌절감이 뒤따르는 경우가 많다는 점이다. AI가 먼저 만들어낸 수많은 결과물을 정리하고 다듬기 위해 결국 인간이 오랜 시간 집중해 개입해야 하는 상황에 직면하게 된다.

마치 커피를 너무 많이 마셨다가 카페인이 빠진 뒤의 상태와 비슷하다. 이제 소매를 걷어붙이고, 거창한 아이디어들을 실제로 작동하는 소프트웨어로 만들기 위해 씨름해야 할 차례다.

버셀의 데모만 있는 것이 아니다. 다음은 테시스(Thesys)가 공개한 생성형 UI 데모다.

마이크로소프트의 AG-UI 또한 이와 유사한 기능을 제공한다.

생성형 UI는 과연 좋은 아이디어일까?

생성형 UI API와 LLM이 현재 수준을 넘어 충분히 발전하고, 개발자가 모든 부담을 떠안지 않아도 되는 상황을 가정해 보자. 그렇다면 핵심 질문은 이것이다. 생성형 UI는 과연 우리가 실제로 사용하고 싶어 할 인터페이스일까?

공정하게 말하자면, 버셀의 젠UI는 독립적인 완성형 UI라기보다 다른 애플리케이션에서 활용하기 위한 API다. 다시 말해 AI 응답 흐름 속에 UI 구성 요소를 스트리밍 방식으로 끼워 넣을 수 있도록 해준다. 그런 점에서 streamUI API를 통해 필요할 때 리액트 컴포넌트를 통합하는 방식은, 잘 설계된 기존 UI 안에서는 충분히 의미 있는 선택지가 될 수도 있다.

다만 여전히 가장 많이 사용되는 것은 완성도 높은 UI와 우수한 사용자 경험을 갖춘 서비스다. 예를 들어 AI에게 카트만두행 항공편의 좋은 조건을 찾아달라고 요청한 뒤, 곧바로 항공권 구매 인터페이스를 띄우는 방식이 유용할 수는 있다. 하지만 대부분은 익숙한 여행 예약 사이트를 직접 이용하게 될 가능성이 크다.

설령 의도를 완벽하게 UI로 표현할 수 있다고 해도, 막상 충분히 쓸 만한 UI가 만들어지면 그 이후에는 이를 계속 깊게 수정하고 싶기보다는 저장해 두고 재사용하고 싶어질 가능성이 높다. 생성형 UI가 가진 가능성과 별개로, 실제 사용 방식은 결국 반복과 축적의 방향으로 흘러갈 수밖에 없다는 의미다.

사용자의 의도를 어떤 언어든 자연어로 입력하는 방식은 조사나 브레인스토밍, 아이디어를 정리하는 과정에서는 분명 강력한 도구다. 그러나 시각적인 UI 역시 그 자체로 큰 장점을 지닌다. 윈도우가 여러 용도에서 DOS를 대체할 수 있었던 이유도 여기에 있다.

생성형 UI라는 아이디어를 처음부터 부정하려는 것은 아니다. 잘 설계된 UI에 챗봇 프롬프트를 결합해, 필요에 따라 UI를 즉석에서 수정하는 하이브리드 형태가 현실적인 대안이 될 가능성도 있다.

여기서 중요한 점은 웹이 에이전틱 엔드포인트의 집합으로 진화할 수 있다는 점이다. AI가 MCP나 유사한 기능을 통해 실제 행동을 수행하게 되면, 중립적인 언어 인터페이스를 통해 선택 가능한 행동이 일종의 ‘행동의 시장’처럼 구성되고, 필요할 때 생성되는 맞춤형 UI는 그 환경에서 자연스럽게 핵심 요소로 자리 잡게 된다.

이 경우 웹은 더 이상 방대한 문서와 데이터의 집합이 아니다. 사용자의 의도와 의미에 따라 실행할 수 있는 ‘행동’의 집합으로 재편된다.

과거 시맨틱 웹은 의미 중심의 웹을 만들겠다는 목표를 내세웠다. AI가 결합된 시맨틱 웹은 훨씬 실용적인 형태로 구현될 가능성이 있다. 생성형 UI는 이러한 웹과 상호작용하기 위한 도구 정의를 제공하는 새로운 방식이 될 수 있다.

컨텍스트 아키텍트

생성형 UI라는 개념에는 분명 의미가 있지만, 단기간에 UX·UI 엔지니어를 대체할 것으로 보이지는 않는다. 다만 이들을 보완하거나 새로운 도구를 제공하는 역할은 충분히 가능해 보인다.

바이브 코딩과 마찬가지로, 앞으로는 인터페이스를 직접 구축하기보다는 AI를 활용해 ‘컨텍스트를 설계’하는 데 더 많은 시간을 쓰게 될 것이라는 관점은 미래 프론트엔드 개발의 한 단면을 보여준다. 다만 그것이 전부는 아닐 것이다.

이 모델에서 UI 개발자의 역할은 챗봇과 MCP 서버 사이를 연결하는 인터페이스 정의를 제공하는 데 있다. 이런 정의는 아래에 제시된 코드 예시와 유사한 형태를 띨 수 있다. 버셀의 API는 조드를 사용하지만, 이는 실제 구현이 아닌 개념을 설명하기 위한 의사 코드다.

// This Zod schema acts as the "Interior Interface" for the AI Agentconst cryptoPurchaseTool = {  description: 'Show this UI ONLY when the user explicitly asks to buy',  parameters: z.object({    coin: z.enum(['SOL', 'BTC', 'ETH']),    amount: z.number().min(0.1).describe('Amount to buy'),  }),  generate: async ({ coin, amount }) => {    // The AI plays within this sandbox    return   }}

어떤 의미에서 보면, 이 스키마는 AI가 활용할 수 있는 ‘내부 UI’로 기능하게 되고, AI 자체는 인간과 기계를 연결하는 일종의 범용 중개자로 자리 잡게 된다. 과연 우리가 향하고 있는 방향이 이런 모습일지는 아직 단정하기 어렵다. 시간이 지나야 답이 나올 것이다.
dl-itworldkorea@foundryco.com