Vercel Labs의 json-render가 보여주는 ‘Generative UI’의 다음 단계

AI가 코드를 쓰는 대신 UI를 조립하기 시작했다

“매출 현황을 보여주는 대시보드를 만들어줘.”

지금까지 AI에게 이렇게 요청하면 보통 이런 일이 벌어졌다.

AI가 React 코드를 작성한다.
컴포넌트를 만든다.
CSS를 붙인다.
차트 라이브러리를 고른다.
상태 관리 코드를 만들고 버튼 이벤트도 연결한다.

그리고 우리는 그 코드가 실제로 실행되기를 기도한다.

컴파일 오류가 나기도 하고, 이미 회사에서 사용 중인 디자인 시스템을 무시한 새로운 버튼이 생기기도 한다. 버튼 하나를 수정해 달라고 했는데 AI가 파일 전체를 다시 작성하기도 한다.

Vercel Labs의 json-render는 이 문제를 조금 다른 방향에서 바라본다.

AI에게 프론트엔드 코드를 작성하게 하지 말고,
우리가 허용한 UI 부품으로 화면의 ‘설계도’만 만들게 하면 어떨까?

이것이 json-render의 핵심 아이디어다.

현재 GitHub의 vercel-labs/json-render 저장소는 약 1만 7천 개 이상의 스타를 받고 있으며, 핵심 패키지인 @json-render/core도 npm에 공개돼 있다. 2026년 9월 21일 기준 npm에는 0.21.0 버전이 게시돼 있다.

다만 최근 다시 크게 주목받고 있다고 해서 프로젝트가 “방금 처음 오픈소스화됐다”고 보는 것은 정확하지 않다. 공개 GitHub 이슈는 적어도 2026년 1월부터 존재한다. 최근 업데이트와 기능 확장이 빠르게 이어지면서 다시 주목받는 프로젝트라고 보는 편이 정확하다.

코드를 생성하지 말고, UI 설명서를 생성한다

json-render를 이해하려면 먼저 기존 AI 프론트엔드 생성 방식과 비교해보면 쉽다.

기존 방식은 대략 이렇다.

사용자 요청 → AI → React/HTML/CSS/JavaScript 코드 → 실행

json-render는 중간에 하나의 계층을 집어넣는다.

사용자 요청 → AI + Catalog → JSON Spec → Renderer → 실제 UI

공식 문서에서는 이 구조를 Generative UI라고 설명한다.

개발자는 먼저 AI가 사용할 수 있는 컴포넌트와 액션을 정의한다.

예를 들어 우리 회사 서비스에 다음 컴포넌트만 있다고 해보자.

Card
Metric
Chart
Button
Table

그리고 AI에게 이렇게 말한다.

“이번 달 매출 현황을 보여주는 대시보드를 만들어줘.”

그러면 AI는 새로운 React 컴포넌트를 마음대로 만드는 대신, 대략 이런 구조를 만든다.

{
  "root": "dashboard",
  "elements": {
    "dashboard": {
      "type": "Card",
      "props": {
        "title": "이번 달 매출"
      },
      "children": [
        "revenue",
        "growth"
      ]
    },
    "revenue": {
      "type": "Metric",
      "props": {
        "label": "총매출",
        "value": "125,000,000원"
      }
    },
    "growth": {
      "type": "Metric",
      "props": {
        "label": "전월 대비",
        "value": "+12%"
      }
    }
  }
}

AI가 만들어낸 것은 애플리케이션 코드가 아니다.

UI를 어떻게 조합할지를 설명하는 JSON 설계도다.

실제 Card와 Metric이 어떻게 생겼는지는 개발자가 이미 정의한 컴포넌트가 결정한다. 공식 문서 역시 AI가 생성하는 Spec을 “Catalog에 의해 제한된 typed element tree”로 설명한다.

여기서 가장 중요한 개념은 Catalog다

json-render에서 가장 중요한 것은 AI보다 오히려 Catalog다.

Catalog는 AI에게 주는 일종의 LEGO 상자다.

“너는 이 안에 있는 블록만 사용할 수 있어.”

라는 계약이다.

예를 들어 Button 컴포넌트를 정의하면서 사용할 수 있는 속성을 지정할 수 있다.

Button: {
  props: z.object({
    label: z.string(),
    variant: z.enum(["primary", "secondary"])
  })
}

이렇게 정의하면 AI는 갑자기 존재하지 않는

superFancyGradientButton

같은 컴포넌트를 만들어 사용할 수 없다.

AI의 자유도를 완전히 없애는 것이 아니라,

구조를 만드는 자유는 AI에게 주되, 사용할 수 있는 부품과 행동의 범위는 개발자가 통제한다.

이것이 json-render가 말하는 Guardrail이다.

사실 이 구조는 AI UI에서 꽤 중요한 변화다

지금까지 AI 코딩에서는 AI의 역할이 상당히 컸다.

AI가 구조도 결정하고,

컴포넌트도 만들고,

스타일도 만들고,

상태 관리도 만들고,

이벤트 코드도 작성했다.

그러다 보니 생성 결과가 매번 조금씩 달라졌다.

json-render에서는 역할이 분리된다.

영역기존 AI 코드 생성json-render

화면 구조	AI	AI
컴포넌트 구현	AI가 생성 가능	개발자가 미리 정의
디자인 시스템	AI가 벗어날 수 있음	Catalog로 제한
출력	소스 코드	JSON Spec
사용자 액션	생성 코드	허용된 Action
수정	코드 재생성	Spec 변경 가능
실행 안전성	생성 코드에 따라 달라짐	임의 코드 실행을 줄이는 구조

즉,

AI가 프로그램을 작성하는 것이 아니라 프로그램이 사용할 인터페이스를 구성한다.

이 차이가 꽤 크다.

버튼도 단순한 그림이 아니다

Generative UI가 단순히 예쁜 화면만 만들어준다면 활용 범위는 제한적이다.

하지만 json-render는 상태와 액션을 함께 다룬다.

예를 들어 AI가 생성한 버튼이

“PDF 내보내기”

라는 액션을 호출할 수 있다.

하지만 실제로 PDF를 만드는 코드를 AI가 작성하는 것은 아니다.

개발자가 미리 다음과 같은 행동을 등록한다.

export_report
submit_form
load_customer
change_tab

AI는 그중 어떤 액션을 어느 버튼에 연결할지만 결정한다.

실제 네트워크 요청이나 파일 생성 같은 로직은 애플리케이션이 가지고 있다.

공식 Registry 문서에서도 개발자가 액션 handler를 등록하고 AI-generated spec이 이를 호출하는 형태로 설명한다.

보안 측면에서도 중요한 차이다.

AI에게

“알아서 JavaScript를 작성해서 실행해.”

라고 하는 것과,

“이 10개의 허용된 액션 중 적절한 것을 선택해.”

라고 하는 것은 완전히 다른 문제다.

UI도 스트리밍된다

json-render에는 또 하나 재미있는 특징이 있다.

AI 답변처럼 UI도 스트리밍할 수 있다.

예를 들어 사용자가

“고객 데이터를 분석해서 대시보드를 만들어줘.”

라고 하면 완성된 JSON이 나올 때까지 기다렸다가 화면 전체를 보여주는 것이 아니다.

Spec이 생성되는 동안 JSONL patch가 전달되고 UI가 점진적으로 업데이트될 수 있다.

Card가 먼저 생기고,

Metric이 나타나고,

Chart가 이어서 나타나는 방식이다.

공식 문서에서는 Standalone Mode와 Inline Mode 모두 동일한 JSONL patch 기반 스트리밍 구조를 사용한다고 설명한다.

따라서 챗봇에서

텍스트 → 텍스트 → 텍스트

만 나오는 대신,

텍스트 → 표 → 버튼 → 차트 → 입력 폼

처럼 대화 상황에 따라 인터페이스 자체가 달라지는 구조를 만들 수 있다.

더 흥미로운 것은 ‘React 전용 도구’가 아니라는 점이다

처음 보면 React용 UI 생성 라이브러리처럼 보인다.

현재 범위는 훨씬 넓다.

같은 기본 철학을 사용하면서 React, Vue 3, Svelte 5, SolidJS를 비롯해 React Native 모바일 UI와 TanStack Start 애플리케이션을 렌더링할 수 있다.

그뿐 아니라 React PDF를 이용한 PDF 문서, Satori 기반 SVG·PNG 이미지, Remotion 기반 영상, Ink 기반 터미널 UI도 지원한다.

심지어 Three.js 계열도 있다.

@json-render/react-three-fiber에는 Box, Sphere, Light, Camera, GLTF 모델, 환경, 텍스트 등의 3D 컴포넌트가 준비돼 있으며 Gaussian Splat도 지원한다. 공식 문서 기준으로 기본 3D 컴포넌트가 20개 제공된다.

즉 json-render가 말하는 Renderer는 단순히

JSON → 웹페이지

가 아니다.

JSON Spec
   ↓
React UI
Vue UI
Svelte UI
Mobile UI
PDF
Image
Video
Terminal
3D Scene

같은 개념까지 확장되고 있다.

여기서 Generative UI라는 용어의 의미가 훨씬 커진다.

AI가 “웹페이지”를 생성하는 것이 아니라,

상황에 맞는 표현 형식을 선택하고 조립하는 시스템

으로 발전할 가능성이 있기 때문이다.

디자인 시스템이 있는 회사일수록 오히려 재미있다

json-render의 가치가 가장 크게 드러나는 곳은 이미 제품이 어느 정도 만들어진 조직일 수 있다.

예를 들어 회사에 이미

Button
Card
Dialog
Table
Chart
DatePicker
UserCard
ProductCard
PaymentPanel

같은 디자인 시스템이 있다고 하자.

그 컴포넌트들을 Catalog로 등록한다.

그러면 AI에게

“이번 달 결제가 실패한 VIP 고객을 보여줘.”

라고 요청했을 때

AI가 새로운 UI 라이브러리를 설치하거나 임의의 CSS를 만드는 것이 아니라 기존 사내 컴포넌트만 조합해서 화면을 만들 수 있다.

브랜드 컬러도 그대로다.

버튼 모양도 그대로다.

접근성 규칙도 그대로다.

모바일 규칙도 그대로다.

AI가 디자인 시스템을 따라야 한다고 프롬프트로 “부탁”하는 것이 아니다.

애초에 디자인 시스템 밖으로 나갈 수 있는 선택지를 주지 않는 방식이다.

이 차이가 중요하다.

디버깅 도구도 따로 있다

Generative UI의 가장 골치 아픈 문제 중 하나는 이런 것이다.

“AI가 왜 이런 화면을 만들었지?”

json-render는 이를 확인하기 위한 Devtools도 제공한다.

현재 Devtools에서는 Spec Tree, State Editor, Action Log, Stream Log, Catalog Browser, DOM Picker 등을 확인할 수 있다.

React뿐 아니라 Vue, Svelte, Solid용 adapter도 제공한다.

개발 환경에서는 패널을 띄워 AI가 어떤 Spec을 만들었는지 확인할 수 있고, 공식 설명상 production에서는 tree-shaking을 통해 null로 제거된다.

그리고 MCP와 연결된다

여기서 AI Agent 시대와 연결되는 지점이 나온다.

json-render에는 @json-render/mcp 패키지도 있다.

MCP 서버가 단순한 텍스트나 JSON 데이터만 반환하는 것이 아니라 실제로 클릭할 수 있는 UI를 AI 대화 안에 반환할 수 있도록 만든 구조다.

공식 문서에서는 Claude, ChatGPT, VS Code, Cursor를 비롯한 MCP Apps 지원 클라이언트를 안내하고 있다.

예를 들어 CRM MCP가 있다고 생각해보자.

사용자가 AI에게 말한다.

“오늘 연락해야 할 고객을 보여줘.”

기존 방식이라면 AI가 이렇게 답할 것이다.

1. 김OO
2. 박OO
3. 이OO

하지만 Generative UI 방식에서는

고객 카드
전화 버튼
이메일 버튼
상태 선택 메뉴
미팅 예약 버튼

을 포함한 작은 CRM 인터페이스 자체를 대화 안에 보여줄 수 있다.

AI Agent의 결과가

Answer

에서

Application

으로 바뀌는 것이다.

재미있는 실험: Jev와도 만나기 시작했다

최신 @json-render/core에는 더욱 흥미로운 실험도 들어가 있다.

experimental_composeSpec과 experimental_createEvaluator라는 API다.

공식 npm 설명에서는 미리 정의된 atomic UI 후보 중 어떤 요소를 선택할지 평가하는 decision-model 구성 방식을 실험하고 있으며, 현재 예시로 typesafe-ai/jev를 언급하고 있다.

이 접근은 일반적인 LLM 생성과 조금 다르다.

AI에게

“JSON을 처음부터 끝까지 만들어.”

라고 하는 대신,

Card?
Chart?
Metric?
Table?
Button?

와 같은 후보 가운데 어떤 컴포넌트가 적절한지를 판단하게 하는 방식으로 발전할 수 있다.

아직 experimental_ 접두사가 붙은 기능이므로 API가 바뀔 수 있고 안정 기능으로 간주해서는 안 된다.

하지만 방향 자체는 재미있다.

Generative UI가 앞으로 반드시

긴 텍스트를 생성하는 LLM

에만 의존할 필요는 없다는 뜻이기 때문이다.

그렇다고 프론트엔드 개발자가 사라지는 것은 아니다

여기서 흔히 나오는 오해가 있다.

“그러면 앞으로 AI가 UI를 전부 만드는 것 아닌가?”

오히려 json-render의 구조를 보면 반대에 가깝다.

좋은 Generative UI를 만들려면 먼저 좋은 컴포넌트 시스템이 필요하다.

어떤 Button을 허용할 것인지,

어떤 Chart를 허용할 것인지,

어떤 데이터에 접근할 것인지,

어떤 Action을 실행할 수 있을 것인지,

각 컴포넌트가 모바일에서 어떻게 동작할 것인지,

잘못된 입력은 어떻게 검증할 것인지

사람이 정의해야 한다.

결국 프론트엔드 개발자의 일이

“모든 화면을 직접 그리는 것”

에서

“AI가 안전하게 사용할 수 있는 UI 언어를 설계하는 것”

으로 일부 이동할 가능성이 있다.

그리고 아직 만능은 아니다

json-render를 보고

“이제 한 문장만 입력하면 모든 앱이 완성된다.”

라고 이해하면 과장이다.

Catalog에 없는 것은 기본적으로 만들 수 없다.

따라서 충분한 컴포넌트와 액션을 먼저 만들어놓아야 한다.

Schema에 맞는 UI라고 해서 반드시 좋은 UX라는 보장도 없다. AI는 허용된 컴포넌트 안에서도 이상한 배치나 불필요하게 복잡한 화면을 만들 수 있다.

또한 결제, 삭제, 권한 변경 같은 중요한 액션은 단순히 Catalog에 등록했다고 안전해지는 것이 아니다. 실제 서버에서 인증·인가·검증을 별도로 수행해야 한다.

무엇보다 프로젝트는 아직 0.x 버전이다. npm 기준 @json-render/core는 현재 0.21.0으로 빠르게 업데이트되고 있다. API 변화 가능성을 감안해야 한다.

그러므로 지금 단계에서는 기존 프론트엔드 프레임워크를 대체하는 기술이라기보다,

AI가 기존 애플리케이션의 UI를 동적으로 조립할 수 있게 해주는 새로운 레이어

라고 이해하는 편이 정확하다.

그런데 코드가 정말 필요하면?

재미있는 점은 json-render가 이제 반대 방향도 지원한다는 것이다.

기본 철학은

Prompt → JSON Spec → Runtime Renderer

이지만, 공식 사이트에서는 생성된 UI Spec을 독립적인 React 코드로 내보내는 Code Export 기능도 소개하고 있다.

생성된 결과를 Next.js 프로젝트와 컴포넌트 코드로 추출해 json-render runtime 없이 실행하는 형태다.

즉 두 가지 사용법이 가능해지고 있다.

동적인 AI 인터페이스가 필요하면 Spec을 runtime에서 렌더링하고,

AI가 만든 결과를 출발점으로 일반 애플리케이션을 만들고 싶다면 코드로 내보낼 수 있다.

이 부분은 상당히 현실적인 선택이다.

내가 json-render에서 가장 흥미롭게 보는 부분

개인적으로 이 프로젝트의 핵심은 “AI가 UI를 잘 만든다”가 아니다.

더 중요한 변화는 AI에게 주는 자유의 범위를 설계할 수 있다는 것이다.

지금까지 우리는 AI에게 말했다.

“이 앱을 만들어줘.”

앞으로는 이렇게 말하게 될지도 모른다.

“우리가 만든 이 40개의 컴포넌트와 15개의 액션을 사용해서, 지금 이 사용자에게 가장 적절한 인터페이스를 만들어줘.”

이 둘은 완전히 다른 개발 방식이다.

첫 번째는 AI에게 개발을 맡긴다.

두 번째는 사람이 시스템을 설계하고 AI에게 조립을 맡긴다.

LLM은 무엇이든 만들어낼 수 있기 때문에 강력하다.

하지만 실제 제품에서는 무엇이든 만들어내는 능력이 오히려 문제가 되기도 한다.

그래서 json-render의 철학은 역설적이다.

AI를 더 자유롭게 만들기 위해, 먼저 AI가 움직일 수 있는 울타리를 만든다.

앞으로 UI는 ‘고정된 화면’이 아닐 수도 있다

지금 사용하는 대부분의 앱은 모든 사용자에게 거의 동일한 인터페이스를 보여준다.

로그인하면 대시보드가 있고,

왼쪽에 메뉴가 있고,

설정 페이지가 있고,

검색 페이지가 있다.

하지만 AI가 사용자의 의도를 이해하고 그 순간 필요한 인터페이스를 생성할 수 있다면 이야기가 달라진다.

“지난달보다 매출이 떨어진 이유를 찾아줘.”

라고 입력했을 때는 분석 대시보드가 만들어지고,

“그중 문제가 있는 고객에게 연락하고 싶어.”

라고 하면 CRM 인터페이스가 만들어지고,

“이 내용을 대표에게 보고할 자료로 만들어줘.”

라고 하면 PDF가 만들어질 수 있다.

같은 데이터와 같은 AI가

상황에 따라

Chart가 되고,

Form이 되고,

Table이 되고,

PDF가 되고,

모바일 화면이 될 수 있다.

json-render가 지금 당장 이 미래를 모두 완성했다는 뜻은 아니다.

하지만 방향은 꽤 선명하다.

웹의 인터페이스는 오랫동안 사람이 미리 모든 화면을 설계하는 방식으로 만들어졌다.

Generative UI가 자리 잡는다면 앞으로 개발자는 모든 화면을 미리 만드는 대신,

AI가 사용할 수 있는 UI의 문법을 만든다.

그리고 AI는 그 문법 안에서

그 순간 필요한 화면을 조립한다.

어쩌면 AI 시대의 프론트엔드에서 중요한 질문은

“AI가 얼마나 코드를 잘 작성하는가?”

가 아니라

“AI에게 어떤 부품과 어떤 행동을 허용할 것인가?”

가 될지도 모른다.

---

참고 자료

GitHub — Vercel Labs json-render
vercel-labs/json-render GitHub 저장소

공식 사이트 및 문서
json-render 공식 사이트
json-render 공식 문서

npm
@json-render/core npm 패키지

MCP
@json-render/mcp 문서

Renderers
json-render Renderer 문서

3D / React Three Fiber
React Three Fiber Renderer 문서