Python으로 만드는 생성형 UI? — Jeremiah Lowin (Prefect)

URL: https://www.youtube.com/watch?v=Krzs8GeiWTc 날짜: 2026-09-11 채널: aiDotEngineer

---

📌 핵심 질문 / 이 영상이 다루는 핵심 논점

==Python 엔지니어가 프론트엔드 생태계 전체를 Python으로 억지로 재현하지 않고도, MCP 앱을 위한 상호작용형·생성형 UI를 만들 수 있는가?==

• MCP 앱(MCP Apps)은 에이전트가 MCP 도구를 호출한 뒤 결과를 다시 문맥창에 넣어 텍스트로만 답하는 흐름을 확장해, 사용자에게 HTML·CSS·JavaScript로 된 완전한 UI를 직접 제공한다.
• FastMCP의 주요 사용자는 기업에서 정보를 공유하고 수집하는 Python 엔지니어이므로, 소비자용 브랜드 UI보다 표·폼·차트 같은 제한된 목적의 조합형 UI가 적합하다.
• Prefab은 Python DSL(Domain-Specific Language)로 잘 설계된 컴포넌트를 조합하고 JSON 중간 표현으로 직렬화하여, 인터랙티브 도구·백엔드가 붙은 앱·에이전트가 실시간 생성하는 UI를 모두 지원한다.

MCP 앱의 핵심은 Python 자체가 아니라 UI를 직렬화할 수 있는 중간 표현이다. Python은 사람이 읽고 쓰기 좋은 표면 문법으로 작동하고, 실제 렌더링은 React 애플리케이션이 담당한다. 이 구조는 에이전트가 UI를 생성하거나 수정하게 하면서도 Python 사용자에게 익숙한 생태계를 유지하고, 데이터 전송량·토큰 비용·지연 시간을 줄이는 방향으로 확장된다.

1. MCP 앱이 바꾸는 에이전트와 사용자 사이의 경계

에이전트와 MCP 서버의 전통적인 관계는 도구 호출 결과가 에이전트의 문맥창을 거쳐 다시 사용자에게 전달되는 구조다. MCP 앱은 이 구조에서 UI를 사용자에게 직접 내보내는 경로를 추가한다.

1.1. 전통적인 MCP 도구의 요청·응답 사이클

1. 사용자가 에이전트에 요청한다

   1. 사용자의 자연어 요청이 먼저 에이전트로 들어간다.
   2. 에이전트가 어떤 MCP 도구를 사용할지 결정한다.

2. 에이전트가 MCP 서버의 도구를 호출한다

   1. MCP 도구는 MCP 서버에 호스팅된 함수와 비즈니스 로직이다.
   2. 서버가 반환한 도구 결과는 다시 에이전트의 문맥(context)에 들어간다.
   3. 에이전트는 결과를 바탕으로 응답을 구성해 사용자에게 보낸다.

3. 문맥창이 사실상의 중간 통로가 된다

   1. MCP 서버는 에이전트에 기능과 비즈니스 로직을 훌륭하게 추가하지만, 일반적인 흐름에서 사용자와 MCP 서버가 직접 연결되지는 않는다.
   2. 모든 결과가 에이전트의 판단과 문맥창을 통과하므로, 사용자가 결과를 직접 조작하는 인터페이스는 기본적으로 제공되지 않는다.

1.2. MCP 앱의 우회 경로

1. 도구 결과를 UI로 사용자에게 보낸다

   1. 사용자가 에이전트에 요청하고 에이전트가 도구를 선택하는 첫 단계는 동일하다.
   2. MCP 앱에서는 도구 결과가 다시 에이전트에게 텍스트로 돌아가지 않고, HTML·CSS·JavaScript로 구성된 UI 형태로 사용자에게 전달된다.
   3. 따라서 MCP 앱은 단순한 텍스트 결과가 아니라 원하는 대로 브랜딩하고 상호작용을 설계할 수 있는 완전한 애플리케이션을 제공한다.

2. 사용자가 앱을 직접 조작한다

   1. 사용자는 렌더링된 앱 안에서 정보를 입력하고, 도구를 실행하고, 애플리케이션의 백엔드 호스트로 데이터를 보낼 수 있다.
   2. 에이전트는 앱을 띄우고 작업을 중개하지만, 최종 상호작용은 사람의 직접 조작으로 진행될 수 있다.
   3. 에이전트가 사용자의 행동을 대신 해석해 텍스트로 재구성할 필요가 줄어든다.

3. 실제 사용 사례가 넓어진다

   1. 레스토랑 테이블 예약처럼 여러 선택지를 확인하고 확정해야 하는 업무를 UI로 처리할 수 있다.
   2. 비행기 좌석 변경처럼 좌석 배치와 선택 상태를 시각적으로 확인해야 하는 업무를 직접 수행할 수 있다.
   3. AI Engineer 행사 일정처럼 일정표를 탐색하고 필요한 항목을 고르는 작업도 앱으로 제공할 수 있다.

1.3. 에이전트가 앱을 조작하는 다음 단계

1. MCP 릴리스의 확장 방향

   1. 발표 시점에는 에이전트가 앱을 띄우고 사용자가 조작하는 흐름이 중심이었다.
   2. 다가오는 7월 MCP 릴리스에서는 에이전트도 앱과 상호작용할 수 있는 확장이 예정되어 있다고 소개됐다.

2. 사람과 에이전트가 같은 시각적 상태를 공유한다

   1. 사용자가 앱에서 행동을 수행하면 에이전트가 그 앱의 상태를 읽고 다시 조작할 수 있다.
   2. 체스판을 예로 들면, 사용자가 시각적 앱에서 말을 움직인 뒤 에이전트도 같은 앱에서 자신의 수를 둘 수 있다.
   3. 이 변화는 채팅창에서 명령과 결과만 주고받는 모델을 넘어, 사람과 에이전트가 공동으로 조작하는 인터랙티브 환경을 열 수 있다.

2. Python 엔지니어를 위한 UI 문제 정의

Jeremiah Lowin이 이끄는 Prefect 팀은 FastMCP의 새 기능을 Python 중심 사용자에게 전달해야 했다. 문제는 프론트엔드를 Python에 억지로 욱여넣지 않으면서도 실용적인 UI를 제공하는 것이었다.

2.1. FastMCP 사용자와 프론트엔드의 긴장

1. FastMCP 생태계의 출발점

   1. 발표자는 FastMCP의 저자이며, Prefect가 이 프로젝트를 유지한다고 설명했다.
   2. FastMCP는 MCP 서버를 만드는 가장 인기 있는 방식 중 하나로 소개됐다.
   3. MCP에 새로운 기능이 등장할 때마다 Prefect 팀은 이를 FastMCP 사용자에게 어떻게 전달할지 먼저 고민한다.

2. 주요 사용자는 Python 엔지니어다

   1. FastMCP 사용자는 대부분 Python 엔지니어이며, 특히 기업 환경에 속한 경우가 많다.
   2. 새 MCP 앱 기능은 자연스럽게 프론트엔드와 UI를 요구하지만, 이 사용자층이 갑자기 전통적인 프론트엔드 전문성을 갖추기를 기대하기는 어렵다.

3. 피해야 할 해결책

   1. React와 Python을 한 시스템 안에 무리하게 결합해 프론트엔드 생태계 전체를 Python으로 옮기는 방식은 타협적이고 복잡한 결과가 될 수 있다.
   2. 발표자는 이를 이미 시도된 어리석은 방식, 즉 여러 생태계를 한데 밀어 넣은 Frankenstein 같은 시스템으로 만들고 싶지 않다고 표현했다.
   3. Python 개발자에게 React와 Python을 함께 배포하겠다고 약속하는 방식은 실용적인 해답이 아니라고 선을 그었다.

2.2. 사용자의 실제 업무를 제약으로 삼기

1. 소비자용 UI가 핵심 요구가 아니다

   1. 기업의 Python 개발자들이 필요한 것은 완전히 브랜딩된 소비자용 맞춤 UI가 아니다.
   2. 모든 픽셀을 임의로 설계하는 프론트엔드보다 조직 안에서 정보를 다루는 도구가 더 중요하다.

2. 기업 업무의 세 가지 목적

   1. 조직 전체에 정보를 공유하는 것이 주요 목적 중 하나다.
   2. 조직 안에서 정보를 수집하는 것도 중요한 목적이다.
   3. 수집·공유한 정보를 표로 보여주고, 폼으로 입력받고, 차트로 전달하는 형태가 자연스럽다.

3. 제약이 설계 원칙이 된다

   1. 사용자가 만들 UI의 범위를 표·폼·차트 중심으로 좁히면 임의의 프론트엔드를 처음부터 구현할 필요가 없다.
   2. 잘 설계된 컴포넌트를 조합하는 방식은 Python 엔지니어에게 필요한 기능을 유지하면서 품질의 가드레일도 제공한다.
   3. 이 제한은 기능 부족이 아니라 대상 사용자와 업무에 맞는 설계 공간을 정해 주는 유용한 제약이다.

3. Prefab: Python으로 UI를 조합하는 프레임워크

Prefab은 발표 몇 달 전에 오픈소스로 공개됐고, FastMCP 사용자 사이에서 예상보다 큰 인기를 얻었다. 목적은 에이전트를 통해 UI를 제공하는 범위 안에서, 재사용 가능한 컴포넌트를 Python으로 조합하는 것이다.

3.1. Hello World가 보여주는 낯섦과 실용성

1. 익숙한 Hello World 카드

   1. 이름을 입력하면 화면이 실시간으로 바뀌는 카드는 어느 프론트엔드 프레임워크에서나 볼 수 있는 전형적인 예제다.
   2. Prefab의 예제도 같은 사용자 경험을 제공한다.

2. 완전히 Python으로 생성되는 UI

   1. 화면을 생성한 코드는 전부 Python으로 작성되어 있다.
   2. 화면만 보면 일반적인 프론트엔드 컴포넌트처럼 보이지만, 코드를 보면 UI가 Python 클래스와 문맥 관리자로 표현되어 있어 낯설다.
   3. 발표자는 이 조합을 보며 “멋지다”라는 느낌과 “조금 무섭고 이상하다”라는 느낌을 동시에 받는다고 했다.

3. 낯선 문법이 이해되는 조건

   1. 이 방식은 프론트엔드를 처음부터 만드는 것이 아니라, 세계 수준의 잘 설계된 컴포넌트 묶음에서 필요한 것을 조합하는 방식일 때 설득력을 얻는다.
   2. 사용자는 임의의 UI를 발명하려는 것이 아니라 구조화된 프론트엔드를 업무 대상 앞에 배치하려는 사람이다.
   3. 컴포넌트라는 가드레일이 있으면 Python으로 작성된 선언적 UI도 읽기 쉽고 목적에 맞게 느껴진다.

3.2. Prefab DSL의 세 가지 구성 요소

1. 문맥 관리자(Context Manager)로 구조를 표현한다

   1. FastMCP의 핵심 혁신을 Python 데코레이터 하나로 전체 MCP 서버를 만들 수 있게 한 것으로 요약할 수 있다.
   2. 같은 방식으로 Prefab은 문맥 관리자 하나를 이용해 전체 UI를 구성한다고 볼 수 있다.
   3. 문맥 관리자를 중첩하면 UI의 부모·자식 구조가 코드에 그대로 나타난다.
   4. 코드를 읽는 순간 어떤 요소 안에 어떤 요소가 들어가는지 확인할 수 있다.

2. 컴포넌트 클래스와 매개변수를 조합한다

   1. 각 UI 요소는 인스턴스화하는 클래스다.
   2. 렌더링되면 Shadcn 컴포넌트처럼 보이는 아름다운 시각적 요소가 된다.
   3. 클래스에 매개변수를 전달해 동작과 외형을 조정할 수 있다.
   4. CSS 클래스를 전달하면 필요한 범위에서 스타일을 바꿀 수 있다.

3. 반응형 변수(Reactive Variable)로 클라이언트 상호작용을 만든다

   1. 여러 컴포넌트 사이에 데이터를 바인딩하고 클라이언트 측 상호작용을 만드는 체계를 제공한다.
   2. 이 기능은 사용자가 JavaScript 생태계로 완전히 넘어가지 않고도 풍부한 경험을 만드는 방법이다.
   3. Python 엔지니어가 익숙한 생태계를 유지하면서도 화면 안에서 값과 텍스트를 함께 갱신할 수 있다.

3.3. Python DSL에서 React 렌더러까지의 파이프라인

1. 선언적 UI를 직렬화한다

   1. 개발자는 Prefab Python DSL로 UI의 선언적 표현을 작성한다.
   2. 이 표현은 JSON 프로토콜로 직렬화된다.
   3. JSON은 MCP 앱으로 호스팅되는 실제 React 앱이 렌더링할 수 있는 중간 형식이다.

2. JSON이 진짜 핵심이다

   1. Python은 처음부터 핵심 목표로 정해진 것이 아니라, 발표자가 원했던 사용 방식에서 우연히 발견된 표면 문법이다.
   2. 진짜 목표는 UI를 직렬화 가능한 표현으로 만드는 것이었다.
   3. 직렬화된 표현은 에이전트가 생성할 수도 있고, 에이전트에 전달할 수도 있으며, 사람이 만든 표현을 에이전트에게 수정해 달라고 할 수도 있다.
   4. 이 중간 표현 덕분에 사람과 에이전트가 UI를 공동으로 만들고 변형하는 여러 가능성이 열린다.

3. Python이 표면 언어로 살아남은 이유

   1. Python DSL이 구조를 자연스럽게 드러내면서도 사용하기 좋게 떨어져 나왔다.
   2. JSON이라는 핵심 구조와 Python이라는 편리한 표면 문법이 결합되면서 Prefab이 단순한 Python용 위젯 모음보다 넓은 가능성을 갖게 됐다.

4. 문서와 개발 경험 자체를 Prefab으로 만든다

Prefab은 프레임워크를 설명하는 문서조차 같은 프레임워크로 렌더링하는 방식으로 일관성을 보여준다.

4.1. 컴포넌트 규모와 문서의 실시간성

1. 약 130~140개 컴포넌트

   1. Prefab은 임의의 UI를 만들 수 있도록 약 130개 또는 140개 정도의 조합 가능한 컴포넌트를 제공한다.
   2. 발표자는 정확한 숫자를 130인지 140인지 잠시 망설였지만, 상당한 규모의 컴포넌트 라이브러리라는 점을 강조했다.

2. 문서가 Prefab으로 렌더링된다

   1. Prefab 문서는 100% Prefab으로 렌더링된다.
   2. 데이터 테이블 컴포넌트 문서의 기본 사용 예제도 정적인 그림이 아니라 실제로 Prefab으로 렌더링되는 화면이다.
   3. 화면 하단에 보이는 Python 코드는 렌더러가 실시간으로 실행·표현해 현재 UI를 만든다.

3. 라이브 플레이그라운드

   1. 문서의 어떤 예제든 링크를 눌러 플레이그라운드로 가져갈 수 있다.
   2. 플레이그라운드에서 Python 코드를 실시간 편집하면 UI가 즉시 갱신된다.
   3. Python 코드가 화면을 만들고, 화면의 문서가 다시 Python 코드를 보여주는 순환이 처음에는 이상하지만, 문제를 컴포넌트 조합으로 제한하면 납득하기 쉬워진다.

4.2. MCP 밖에서의 사용 가능성

1. 작은 인터랙티브 데이터 앱

   1. Prefect 팀은 Prefab으로 소규모 인터랙티브 데이터 앱을 만들고 탐색용 도구를 만든다.
   2. FastMCP 서버에 연결되지 않은 일반적인 프론트엔드 문제에도 사용할 수 있다.

2. 프레젠테이션

   1. 팀은 Prefab으로 발표 자료도 만들기 시작했다.
   2. 어두운 모드 테마가 기본 제공되며, 발표 화면처럼 보이는 자료를 구성할 수 있다.
   3. 발표자가 보여준 화면도 이 어두운 테마와 비슷한 스타일이라고 설명했다.

3. 가장 중요한 적용처

   1. Prefab은 여러 종류의 UI를 만들 수 있지만, 처음 만든 목적은 MCP 서버에서 사용하는 것이었다.
   2. 이후 세 가지 수준의 MCP 적용 방식을 점점 더 복잡해지는 순서로 소개한다.

5. 첫 번째 적용 방식: 인터랙티브 도구

전통적인 MCP 도구가 에이전트에게 결과를 돌려주는 일회성 호출이라면, 인터랙티브 도구는 그 결과를 사용자가 직접 조작할 수 있는 컴포넌트로 제공한다.

5.1. Python 반환값 하나를 컴포넌트로 바꾼다

1. 기존 FastMCP 도구

   1. 도구 데코레이터가 붙은 일반 Python 함수가 정보를 반환한다.
   2. 함수가 반환하는 Python 딕셔너리는 에이전트로 전달된다.
   3. 사용자는 그 딕셔너리 자체를 직접 조작하지 못하고, 에이전트가 결과를 해석해 답변을 만든다.

2. Prefab 컴포넌트 반환

   1. 딕셔너리를 반환하는 대신 Prefab 컴포넌트를 반환하면 된다.
   2. 예시에서는 데이터 테이블 컴포넌트를 반환한다.
   3. FastMCP는 반환값이 Prefab 컴포넌트라는 사실을 자동으로 감지한다.
   4. FastMCP가 MCP 앱에 필요한 HTML·JavaScript·CSS·렌더러 등 모든 실행 장치를 자동으로 준비한다.

3. 사용자가 받는 결과

   1. 에이전트에게 “팀 디렉터리를 보여줘”라고 요청하면 클라이언트에 데이터 테이블이 나타난다.
   2. 데모는 Goose 클라이언트를 사용했다.
   3. 테이블은 검색·필터링·정렬·페이지네이션을 지원한다.
   4. 이 기능은 각각의 프론트엔드 기능을 새로 구현한 결과가 아니라, 데이터 테이블 클래스 하나를 반환한 결과다.

5.2. 한 줄씩 기능을 확장한다

1. 표 옆에 파이 차트를 추가한다

   1. 데이터 테이블만 반환하던 코드에 Grid와 Pie Chart를 추가로 가져온다.
   2. 문맥 관리자로 파이 차트와 데이터 테이블을 Grid 안에 자연스럽게 중첩한다.
   3. 같은 팀 디렉터리 데이터를 표와 파이 차트로 나란히 보여줄 수 있다.

2. 점진적 복잡성 원칙

   1. Prefect 팀은 “코드 한 줄이 크고 눈에 띄는 변화 하나를 만든다”는 원칙을 중요하게 여긴다.
   2. 기능을 추가할 때 복잡성이 갑자기 폭발하지 않고 단계적으로 증가하도록 설계한다.
   3. 문맥 관리자 기반 조합은 이 원칙과 프레임워크·DSL의 중요한 사용성을 함께 만족시킨다.

5.3. JavaScript 없이 클라이언트 측 반응성을 만든다

1. 여러 컨트롤을 서로 연결한다

   1. 발표자는 여러 컨트롤이 연결되어 값과 텍스트가 함께 바뀌는 클라이언트 상호작용 데모를 보여줬다.
   2. 조작에 따라 화면의 값과 문장이 즉시 갱신된다.
   3. 이 데모에는 별도의 JavaScript 코드가 작성되지 않았다.

2. 공통 속성과 RX 클래스

   1. 여러 컴포넌트에 같은 속성을 할당하는 몇 개의 클래스만 조합하면 서로 연결된다.
   2. Prefab에는 반응형을 뜻하는 RX 클래스가 있다.
   3. 반응형 변수를 코드 어디에서든 참조할 수 있고, 값의 형식을 지정하거나 컴포넌트 이름으로 사용할 수 있다.
   4. 이 표현은 올바른 JavaScript 구현으로 자동 컴파일된다.

6. 두 번째 적용 방식: 백엔드를 가진 FastMCP 앱

인터랙티브 도구가 한 번 띄운 결과를 클라이언트에서 조작하는 일회성 UI라면, FastMCP 앱은 MCP 서버 자체를 백엔드로 갖는 완전한 애플리케이션이다.

6.1. 앱의 기본 구조

1. 앱 클래스와 UI 진입점

   1. FastMCP 앱을 나타내는 클래스를 작성한다.
   2. 최소 두 개의 함수에 app.ui 데코레이터를 붙여 앱의 기본 UI를 반환하는 진입점을 만든다.
   3. app.ui가 반환하는 Prefab 컴포넌트들이 애플리케이션의 기본 화면을 구성한다.

2. 백엔드 도구

   1. app.tools 데코레이터가 붙은 메서드는 UI에서 참조할 수 있는 백엔드 메서드다.
   2. 발표자는 app.tools가 선택 사항이며, 0개 이상 둘 수 있다고 덧붙였다.
   3. 사용자가 폼에 입력한 값을 버튼으로 전송하고, 데코레이터가 붙은 도구가 그 데이터를 데이터베이스에 저장하는 흐름을 만들 수 있다.

3. UI와 서버의 역할 분리

   1. UI는 사용자의 입력과 상호작용을 담당한다.
   2. MCP 서버는 앱의 백엔드가 되어 저장·조회·처리 같은 업무를 담당한다.
   3. 에이전트는 앱을 호출하는 진입점이지만, 모든 세부 데이터를 에이전트의 문맥창으로 복사하는 통로가 될 필요가 없다.

6.2. 파일 업로드가 보여주는 직접 연결의 가치

1. MCP 서버에 파일을 보내는 기본 문제

   1. MCP 서버에 직접 파일을 업로드할 수 있는 주체는 기본적으로 에이전트뿐이다.
   2. 사용자가 파일을 보내더라도 에이전트를 거쳐 MCP 서버의 업로드 도구를 호출해야 한다.
   3. 많은 구현이 MCP 서버에 업로드 도구를 만들면서, 에이전트가 실제로 그 도구를 호출해야 한다는 점을 간과한다.

2. 세계에서 가장 비싼 복사·붙여넣기

   1. 사용자가 에이전트에게 1MB의 텍스트를 전달한다.
   2. 에이전트는 그 텍스트를 글자 단위로 다시 입력해 MCP 서버에 넘긴다.
   3. 결과적으로 업로드는 되지만, 토큰과 시간과 비용을 낭비하는 극도로 비효율적인 복사·붙여넣기가 된다.

3. MCP 앱의 업로드 컴포넌트

   1. 에이전트에게 앱을 띄우라고 요청하고, 사용자가 파일을 앱에 끌어다 놓으면 된다.
   2. 파일은 에이전트를 우회해 서버로 바로 전달된다.
   3. 이 방식을 안전하고 저렴하게 사용할 수 있도록 FastMCP에 업로드 컴포넌트를 기본 제공한다.
   4. 업로드 기능은 한 줄로 추가할 수 있고, 비슷한 실용적 도구도 여러 개 제공된다.

4. 데모에서 확인된 흐름

   1. 발표자는 파일을 드래그 앤 드롭한 뒤 에이전트가 해당 파일과 상호작용하는 장면을 보여줬다.
   2. 발표 자료는 나중에 공개할 예정이며, 관심 있는 사람은 한 줄짜리 구현을 자신의 서버에서 바로 시험할 수 있다고 안내했다.
   3. 발표자는 자신의 슬라이드를 제대로 준비하지 못한 점을 스스로 농담하며, “자기 슬라이드를 아는 것이 좋은 교훈”이라고 말했다.

7. 세 번째 적용 방식: 에이전트가 생성하는 완전한 UI

Prefab과 직렬화된 UI 표현을 결합하면 개발자가 화면을 미리 정의하지 않아도 에이전트가 실시간으로 UI를 만들고 스트리밍할 수 있다.

7.1. Claude가 UI를 실시간으로 스트리밍한다

1. 데모의 요청

   1. 발표자는 Claude에게 “이 주제로 발표 중이니, 떠올릴 수 있는 가장 흥미로운 UI를 지금부터 스트리밍해 달라”고 요청했다.
   2. Claude는 별도의 사전 설계 없이 화면을 만들어 스트리밍하기 시작했다.

2. 스트리밍 렌더링의 작동 원리

   1. 서버는 Prefab이 사용하는 UI 직렬화 프로토콜의 JSON을 받는 도구를 노출한다.
   2. 에이전트가 네트워크를 통해 UI 정보를 보내는 동안 렌더러는 도착한 내용을 실시간으로 처리한다.
   3. 렌더러는 불완전하거나 계속 변하는 JSON을 복구하고(healing) 현재까지 확보한 구조를 화면으로 렌더링한다.
   4. 결과적으로 UI가 완성될 때까지 기다리지 않고, 에이전트가 만드는 화면을 바로 볼 수 있다.

3. UI를 미리 정의하지 않는 경험

   1. 개발자는 모든 화면을 직접 설계하고 구현할 필요가 없다.
   2. Prefab이 제공하는 스킬을 에이전트에게 알려 주면, 에이전트가 어떤 컴포넌트를 사용해 UI를 만들 수 있는지 학습한다.
   3. 에이전트가 사용자의 요청에 맞춰 원하는 형태의 제한된 UI를 만들 수 있다.

7.2. 빌트인 UI와 사용자 정의 UI의 선택

1. 클라이언트의 기본 기능을 존중한다

   1. 일부 MCP 클라이언트는 이미 생성형 UI를 내장하고 있다.
   2. 클라이언트에 잘 맞는 기본 기능이 있다면 그것을 사용해도 된다.

2. Prefab의 사용자 정의 가치

   1. 자체 클라이언트나 서비스에 맞는 접근 방식을 직접 만들고 싶을 때 Prefab을 사용할 수 있다.
   2. 모든 컴포넌트를 허용하는 대신, 특정 업무에 유용한 제한된 컴포넌트 집합만 노출할 수도 있다.
   3. 조직의 브랜드·보안·업무 규칙에 맞는 생성형 UI 경계를 정할 수 있다.

7.3. JSON보다 작아진 Python 표현

1. 초기 설계

   1. 원래 계획은 에이전트가 JSON을 네트워크로 보내고, 이를 전체 React 애플리케이션으로 렌더링하는 것이었다.
   2. 발표자가 녹화한 데모도 처음에는 JSON을 스트리밍하는 방식이었다.

2. 실험에서 발견한 크기 차이

   1. Python으로 표현한 UI가 JSON 표현보다 약 70% 작았다.
   2. Python 표현은 JSON보다 토큰 수와 전송량 측면에서 훨씬 압축적이었다.
   3. 동시에 Python DSL은 사람이 읽고 쓰기에도 더 자연스러웠다.

3. 현재 파이프라인

   1. 이제는 JSON 대신 Python 표현을 네트워크로 스트리밍한다.
   2. 서버의 샌드박스에서 Python을 실행해 JSON으로 변환한다.
   3. 변환된 JSON을 기존 React 렌더러가 화면으로 만든다.
   4. 이 변경으로 토큰 효율·비용·지연 시간에서 매우 큰 이점이 생겼다.
   5. 녹화된 데모와 사용자 경험은 본질적으로 같지만, 뒤에서 오가는 표현 형식이 더 효율적으로 바뀐 것이다.

8. 전체 흐름과 설계 원칙

8.1. 하나의 직렬화 표현이 연결하는 세 주체

1. Python 개발자

   1. 문맥 관리자와 컴포넌트 클래스를 이용해 익숙한 방식으로 UI를 조합한다.
   2. 반응형 변수를 활용해 JavaScript를 직접 작성하지 않고도 상호작용을 정의한다.

2. 에이전트

   1. 직렬화된 UI 표현을 생성하거나 전달받거나 수정할 수 있다.
   2. 미리 정의된 컴포넌트 스킬을 사용해 특정 업무에 맞는 화면을 실시간으로 만들 수 있다.
   3. MCP 앱의 향후 확장에서는 생성한 UI를 직접 조작하는 주체가 될 수도 있다.

3. React 렌더러와 MCP 클라이언트

   1. Python 표현은 서버의 샌드박스에서 JSON으로 변환된다.
   2. React 기반 MCP 앱이 JSON을 받아 HTML·CSS·JavaScript로 렌더링한다.
   3. 사용자는 검색, 필터, 정렬, 입력, 파일 업로드 같은 시각적 상호작용을 수행한다.

8.2. 점진적 복잡성과 범위 제한

1. 컴포넌트 조합으로 가드레일을 만든다

   1. 처음부터 자유로운 프론트엔드를 허용하면 품질과 유지보수가 어려워질 수 있다.
   2. 잘 설계된 표·폼·차트 등의 컴포넌트를 조합하게 하면 업무에 필요한 표현력은 남기고 무질서한 설계는 줄인다.

2. 변화 단위를 작게 유지한다

   1. 데이터 테이블에서 Grid와 Pie Chart를 추가하는 것처럼, 한 줄의 코드가 눈에 띄는 기능 하나를 더하게 한다.
   2. 사용자는 큰 프론트엔드 프로젝트를 새로 만드는 대신, 필요한 기능을 작은 조합으로 확장한다.

3. 에이전트의 자율성도 경계 안에서 설계한다

   1. 생성형 UI가 아무 UI나 만드는 것이 아니라, 조직이 승인한 컴포넌트 집합 안에서 작동하도록 제한할 수 있다.
   2. 이 경계는 예측 가능성·보안·브랜드 일관성을 확보하는 데 도움이 된다.

주요 발언 모음

“MCP 앱은 에이전트에 인터넷을 넣는 방법이라고 말할 수 있다.”

“우리는 프론트엔드를 처음부터 만들려는 것이 아니라, 세계 수준의 잘 설계된 컴포넌트 묶음에서 프론트엔드를 조합하려는 것이다.”

“Python으로 프론트엔드를 조합하면, 문제의 범위를 제대로 제한했을 때 실제로 기분이 좋아지기 시작한다.”

“핵심은 JSON이라는 중간 표현이다. Python은 나중에 발견한 우연한 표면 문법이다.”

“코드 한 줄이 크고 눈에 띄는 변화 하나를 만들어야 한다.”

“에이전트가 1MB의 텍스트를 글자 하나씩 MCP에 다시 입력하는 것은 세상에서 가장 비싼 복사·붙여넣기다.”

“Python 표현은 JSON 표현보다 약 70% 작았고, 토큰 효율과 비용과 지연 시간에 극적인 이점을 만들었다.”

“원한다면 Prefab을 확인해 보라. 이것은 내가 만든 것 중 가장 이상한 소프트웨어다.”

핵심 데이터 & 수치

• MCP 앱 소개 시점: 발표자는 MCP 앱이 당해 1월에 소개된 MCP 프로토콜 확장이라고 설명했다.
• 에이전트 상호작용 확장 시점: 당해 7월 MCP 릴리스에서 에이전트가 앱과 직접 상호작용하는 기능이 나올 예정이라고 소개했다.
• Prefab 공개 시점: 발표 몇 달 전에 오픈소스로 공개됐으며, FastMCP 사용자 사이에서 예상보다 큰 인기를 얻었다.
• 컴포넌트 수: Prefab은 약 130~140개의 조합 가능한 컴포넌트를 제공한다.
• 파일 업로드 예시 크기: 에이전트가 약 1MB 텍스트를 글자 단위로 재입력하는 비효율을 설명했다.
• Python 표현의 크기: UI의 Python 표현은 같은 UI의 JSON 표현보다 약 70% 작았다.
• MCP 적용 방식: 인터랙티브 도구, 백엔드를 가진 FastMCP 앱, 완전한 생성형 UI의 세 단계로 설명했다.
• 핵심 기술 층: Python DSL → JSON 직렬화 표현 → React 기반 MCP 앱 렌더러의 세 층으로 구성된다.

결론 및 시사점

1. MCP 앱은 MCP 서버의 기능을 에이전트 문맥창 안에 가두지 않고 사용자에게 직접 조작 가능한 인터페이스로 전달한다.
2. Python 엔지니어에게 필요한 해법은 프론트엔드 전체를 Python으로 복제하는 것이 아니라, 목적이 분명한 컴포넌트를 Python으로 조합하게 하는 것이다.
3. Prefab의 중요한 기술적 자산은 Python 문법보다 직렬화 가능한 UI 중간 표현이며, 이 표현이 사람·에이전트·렌더러 사이의 공통 언어가 된다.
4. 인터랙티브 도구는 기존 MCP 함수의 반환값을 Prefab 컴포넌트로 바꾸는 작은 변경만으로 검색·필터·정렬·페이지네이션 UI를 제공한다.
5. FastMCP 앱은 UI와 MCP 서버 백엔드를 결합해 폼 입력, 데이터베이스 저장, 파일 업로드처럼 문맥창을 거치면 비효율적인 업무를 직접 연결한다.
6. 생성형 UI는 에이전트가 승인된 컴포넌트 집합 안에서 화면을 즉시 만들도록 하며, 클라이언트의 기본 기능과 자체 구현 사이에서 선택권을 제공한다.
7. Python 표현을 샌드박스에서 JSON으로 변환하는 현재 구조는 약 70%의 표현 크기 감소를 활용하면서도 React 렌더링 생태계를 유지한다.
8. AI 에이전트 시대의 UI 프레임워크는 화면을 미리 고정하는 도구에서 벗어나, 안전한 구성 요소와 직렬화 프로토콜을 통해 상황에 맞는 화면을 생성하는 방향으로 발전할 수 있다.

핵심 요약 (20줄)

1. MCP 앱은 에이전트의 문맥창을 우회해 사용자에게 직접 조작 가능한 HTML·CSS·JavaScript UI를 제공한다.
2. 전통적인 MCP 도구는 사용자의 요청을 에이전트가 해석하고 서버 결과를 다시 문맥창을 거쳐 텍스트로 전달한다.
3. MCP 앱에서는 도구 호출 결과가 완전한 UI로 전달되어 사용자가 예약·좌석 변경·일정 탐색을 직접 수행할 수 있다.
4. 다가오는 MCP 확장은 에이전트도 같은 앱을 조작하게 해 사람과 에이전트가 하나의 시각적 환경에서 협업하도록 만든다.
5. FastMCP의 주 사용자는 기업의 Python 엔지니어이므로 소비자용 맞춤 프론트엔드보다 정보 공유와 수집이 중요하다.
6. 표·폼·차트 중심의 업무 제약은 프론트엔드를 Python으로 억지로 복제하지 않고도 품질을 유지하게 한다.
7. Prefab은 잘 설계된 UI 컴포넌트를 Python DSL로 조합해 MCP 앱에서 렌더링하는 오픈소스 프레임워크다.
8. Prefab의 문맥 관리자 중첩 구조는 Python 코드 안에 UI의 부모·자식 관계를 자연스럽게 드러낸다.
9. 컴포넌트 클래스는 CSS 클래스와 매개변수를 받아 필요한 범위에서 외형과 동작을 조정한다.
10. 반응형 변수와 RX 클래스는 JavaScript를 직접 작성하지 않고도 클라이언트 측 데이터 바인딩을 제공한다.
11. Python DSL은 UI를 선언적으로 표현한 뒤 JSON 프로토콜로 직렬화하고 React 앱이 이를 렌더링한다.
12. 직렬화된 JSON 중간 표현은 에이전트가 UI를 생성하거나 사람이 만든 UI를 수정하게 하는 핵심 기반이다.
13. Prefab 문서는 약 130~140개 컴포넌트를 실제 Prefab으로 렌더링하며 예제 코드를 실시간 플레이그라운드에서 편집하게 한다.
14. 첫 번째 MCP 적용 방식은 딕셔너리 대신 데이터 테이블 컴포넌트를 반환해 검색·필터·정렬·페이지네이션을 제공하는 인터랙티브 도구다.
15. Grid와 파이 차트를 한 줄씩 추가하면 같은 팀 디렉터리를 표와 시각화로 함께 보여줄 수 있다.
16. 두 번째 방식인 FastMCP 앱은 UI 진입점과 선택적 백엔드 도구를 결합해 폼 데이터와 데이터베이스를 직접 연결한다.
17. 파일 업로드 컴포넌트는 에이전트가 1MB 텍스트를 글자별로 재입력하는 비싼 복사·붙여넣기를 없앤다.
18. 세 번째 방식은 에이전트가 Prefab 스킬을 사용해 승인된 컴포넌트로 완전한 UI를 실시간 생성하고 스트리밍하는 것이다.
19. Python UI 표현은 JSON보다 약 70% 작아 현재는 Python을 샌드박스에서 JSON으로 바꾼 뒤 React로 렌더링한다.
20. Prefab은 사람·에이전트·MCP 서버를 직렬화 가능한 UI와 제한된 컴포넌트 생태계로 연결하는 실험이다.