OpenUI가 JSON을 밀어내고 있다, 생성형 UI 표준 전쟁의 서막

AI 에이전트에게 "이번 분기 매출 추이를 보여줘"라고 요청하면 무엇이 돌아올까요? 대부분의 AI 챗봇은 마크다운 테이블이나 텍스트 나열로 응답합니다. 하지만 사용자가 실제로 원하는 것은 인터랙티브한 차트, 필터가 달린 대시보드, 클릭 가능한 데이터 포인트입니다. LLM의 추론 능력은 이미 충분한데, 그 결과를 UI로 변환하는 기술이 병목 이 되어 왔습니다.

2026년 3월, Thesys라는 스타트업이 이 병목을 정면으로 겨냥한 오픈소스 프레임워크 OpenUI 를 공개했습니다. JSON을 대체하는 전용 언어로 토큰을 67%까지 줄이고 렌더링을 3배 빠르게 만들겠다는 제안입니다. Product Hunt 4위, Hacker News 프론트페이지를 연달아 찍으며 개발자 커뮤니티의 관심을 끌고 있는 이 프로젝트가, "생성형 UI"라는 새로운 전선에서 Vercel과 CopilotKit을 상대로 표준 전쟁의 포문을 열고 있습니다.

텍스트만 뱉는 AI 에이전트의 한계

현재 AI 에이전트 생태계의 가장 큰 아이러니 중 하나는, 수십억 파라미터의 모델이 복잡한 추론을 해내면서도 그 결과를 여전히 텍스트 덩어리 로 전달한다는 점입니다. 데이터 분석을 요청하면 차트 대신 문단이 나오고, 비교를 요청하면 테이블 대신 글머리 기호가 나옵니다.

Thesys가 2년간 10,000명 이상의 개발자와 생성형 UI를 배포하며 발견한 문제는 명확했습니다. JSON 기반 UI 생성에는 세 가지 구조적 한계가 있었습니다.

첫째, 성능 입니다. JSON은 완전한 구조가 닫혀야 파싱이 가능합니다. LLM이 토큰을 하나씩 생성하는 스트리밍 환경에서, 사용자는 전체 JSON이 완성될 때까지 빈 화면을 봐야 합니다.

둘째, 토큰 비용 입니다. JSON의 중괄호, 쌍따옴표, 키-값 쌍 구조는 본질적으로 장황합니다. 같은 UI를 표현하는데 불필요하게 많은 토큰을 소비하며, 이는 곧 API 비용과 응답 지연으로 직결됩니다.

셋째, 신뢰성 입니다. LLM이 생성하는 JSON의 오류율은 약 3%에 달합니다. 중괄호 하나가 빠지거나 쉼표가 잘못 들어가면 전체 UI 렌더링이 실패합니다. 정교한 밸리데이션으로 0.3% 이하로 낮출 수 있지만, 그 자체가 추가 복잡성과 비용입니다.

OpenUI Lang: JSON을 대체하는 새로운 언어

Thesys의 해법은 JSON을 개선하는 것이 아니라 완전히 대체하는 것 이었습니다. OpenUI Lang은 LLM이 UI를 생성하기 위해 특별히 설계된 라인 지향적 DSL(Domain-Specific Language)입니다.

핵심 설계 원리는 간단합니다. LLM은 훈련 데이터에서 코드를 압도적으로 많이 봤습니다. JSON보다 코드와 유사한 문법이 더 안정적으로 생성됩니다. OpenUI Lang은 이 특성을 활용하여 코드 유사 구문으로 UI를 표현합니다.

벤치마크 결과는 인상적입니다. GPT-5.2에서 tiktoken으로 측정한 결과, OpenUI Lang은 Vercel의 JSON-Render 대비 평균 52.8% 적은 토큰 을 사용했습니다. 가장 극적인 차이는 Contact Form 시나리오에서 나타났는데, JSON-Render가 893 토큰을 소비하는 동안 OpenUI Lang은 294 토큰으로 동일한 UI를 표현했습니다. 67.1%의 토큰 절약 입니다.

60 tokens/sec의 일반적인 생성 속도를 기준으로 환산하면, Contact Form이 화면에 나타나기까지 걸리는 시간이 3배 빨라집니다. 대시보드나 프라이싱 페이지 같은 복잡한 UI에서도 2~3배의 속도 개선이 관찰되었습니다.

이 효율 차이가 나는 이유는 구조적입니다. JSON-Render는 각 UI 요소를 별도의 패치 연산으로 인코딩하기 때문에 구조적 반복이 누적됩니다. 반면 OpenUI Lang은 라인 단위로 스트리밍되며, 각 라인이 도착하는 즉시 렌더링할 수 있습니다.

Rust를 버리고 TypeScript로 갈아탄 역설

OpenUI의 기술적 여정에서 가장 흥미로운 에피소드는 파서의 Rust-to-TypeScript 리라이트입니다. 이 이야기는 Hacker News 프론트페이지(135 포인트)에 오르며 개발자 커뮤니티에서 뜨거운 논쟁을 일으켰습니다.

Thesys는 초기에 파서를 Rust로 작성하고 WebAssembly(WASM)로 컴파일하여 브라우저에서 실행했습니다. "Rust가 빠르니까 WASM도 빠를 것"이라는 통념을 따른 선택이었습니다. 하지만 실측 결과는 정반대였습니다.

병목은 Rust 코드의 실행 속도가 아니라 JavaScript-WASM 경계 에 있었습니다. 토큰이 도착할 때마다 JavaScript에서 WASM으로 데이터를 넘기고, WASM이 처리한 결과를 다시 JavaScript로 가져오는 과정에서 메모리 복사와 직렬화/역직렬화 오버헤드가 발생했습니다. 스트리밍 환경에서 이 경계 횡단이 초당 수십~수백 번 일어나면서, 파싱 자체보다 데이터 운반에 더 많은 시간이 소비되고 있었습니다.

TypeScript로 재작성하면서 이 경계 비용이 완전히 사라졌고, 동시에 기존 코드에 숨어있던 O(N²) 알고리즘 문제도 발견했습니다. 파서가 새 토큰이 도착할 때마다 지금까지 누적된 전체 문자열을 처음부터 다시 분석 하고 있었던 것입니다. 라인 단위 증분 캐싱으로 O(N)으로 개선한 결과, 최종적으로 2.2~4.6배의 성능 향상 을 달성했습니다.

이 사례는 "시스템 언어가 항상 빠르다"는 가정에 의문을 제기합니다. 특히 JavaScript 생태계 안에서 동작하는 컴포넌트의 경우, 생태계와의 경계 비용이 순수 연산 성능보다 지배적일 수 있다는 교훈입니다.

생성형 UI 표준 전쟁의 3파전

OpenUI는 진공 상태에서 등장한 것이 아닙니다. 2026년 3월 기준, 생성형 UI 시장은 세 가지 접근법이 격돌하는 구도입니다.

Vercel의 json-render 는 AI 모델이 JSON 구조로 UI를 기술하면 프론트엔드가 렌더링하는 방식입니다. Next.js와의 긴밀한 통합, 월간 2,000만 다운로드를 자랑하는 Vercel AI SDK 생태계가 최대 강점입니다. 개발자가 컴포넌트 카탈로그를 정의하면 모델이 그 범위 안에서 UI를 구성하므로, 안전하고 예측 가능합니다. 다만 토큰 효율 측면에서는 OpenUI에 밀립니다.

CopilotKit 은 "Agentic Application Framework"를 표방하며 다른 각도에서 접근합니다. 렌더링 효율보다는 AI와 UI 사이의 상태 동기화 에 집중합니다. Fortune 500 기업의 10% 이상이 사용한다고 밝혔으며, 최근 OpenGenerativeUI라는 오픈소스 프로젝트도 공개했습니다. A2UI(Application-to-UI) 프로토콜, MCP Apps 통합 등 에이전트 런타임 레이어에서의 포지셔닝이 차별점입니다.

OpenUI 는 이 둘과 다른 레이어를 공략합니다. 모델과 렌더러 사이의 통신 포맷 자체 를 최적화하는 것입니다. 따라서 이론적으로는 CopilotKit의 런타임 위에 OpenUI Lang을 올리거나, Vercel AI SDK와 통합하여 json-render 대신 사용하는 것도 가능합니다. 실제로 OpenUI는 Vercel AI SDK, LangChain, CrewAI 등 주요 프레임워크와의 통합을 이미 지원합니다.

세 프레임워크는 서로 다른 레이어를 공략하며, 조합 사용이 가능합니다

CopilotKit의 개발자 가이드도 이 점을 인정합니다. "최적의 접근법은 종종 이들을 조합하는 것이다. CopilotKit으로 런타임을, A2UI로 크로스 플랫폼 컴포넌트를, MCP로 도구 통합을 처리하라."

실무에 미치는 영향

생성형 UI의 부상이 개발자에게 의미하는 것은 무엇일까요?

비용 구조의 변화 가 가장 직접적입니다. 프로덕션 AI 앱에서 LLM API 호출 비용은 핵심 운영비입니다. 하루 수만 건의 UI 생성 요청이 발생하는 서비스에서, 토큰 50% 절약은 곧 API 비용 50% 절감과 같습니다. OpenUI의 벤치마크가 실제 프로덕션 워크로드에서도 유지된다면, 이것만으로도 충분한 전환 동기가 됩니다.

사용자 경험의 질적 전환 도 중요합니다. 텍스트 응답에서 인터랙티브 UI 응답으로의 전환은, 웹이 정적 HTML에서 Single Page Application으로 전환했을 때와 유사한 패러다임 시프트입니다. AI 에이전트가 단순히 "답변"하는 것이 아니라 "인터페이스를 구성"하는 시대가 열리고 있습니다.

프론트엔드 개발의 역할 변화 도 감지됩니다. 컴포넌트를 직접 조합하여 페이지를 만드는 것에서, 컴포넌트 라이브러리를 설계하고 AI가 조합하도록 제약 조건을 설정하는 것으로 역할이 이동합니다. OpenUI의 "Your components define what the model can generate"라는 원칙은 이 방향을 명확히 보여줍니다.

다만 주의할 지점 도 있습니다. OpenUI는 현재 React 전용입니다. Vue, Svelte, Angular 생태계 개발자는 아직 대상이 아닙니다. 또한 GitHub 스타 3,000개와 MIT 라이선스는 건강한 시작이지만, Vercel AI SDK의 월 2,000만 다운로드에 비하면 생태계 성숙도에서 큰 격차가 있습니다.

커뮤니티의 온도

Product Hunt에서 352 업보트로 4위에 오른 것은 초기 관심을 보여주지만, 더 의미 있는 신호는 Hacker News 프론트페이지 진입이었습니다. Rust-to-TypeScript 리라이트에 대한 기술 포스트가 135 포인트를 기록하며, 생성형 UI 자체보다 엔지니어링 결정의 품질 에 대해 개발자들이 반응했습니다.

개발자 피드백을 종합하면 두 가지 캠프로 나뉩니다. 한쪽은 "토큰 비용과 스트리밍 성능이 최우선이라면 OpenUI 수치는 진지하게 검토할 가치가 있다"는 실용파입니다. 다른 한쪽은 "생태계 성숙도와 커뮤니티 규모가 중요하다면 Vercel AI SDK가 여전히 안전한 선택"이라는 안정파입니다.

실제로 Thesys의 기존 C1 플랫폼을 사용해본 개발자들은 "UI가 훨씬 인터랙티브하고 동적이며, 모든 응답이 실시간으로 생성된다"는 긍정적 피드백을 남기고 있습니다. 하지만 "React 전용"이라는 제약은 반복적으로 언급되는 우려 사항입니다.

전망: 생성형 UI가 기본이 되는 세계

생성형 UI의 표준화 경쟁은 이제 막 시작되었습니다. OpenUI, Vercel json-render, CopilotKit, Google A2UI가 각기 다른 레이어에서 접근하고 있으며, 이들이 경쟁보다는 상호보완적으로 수렴 할 가능성도 높습니다.

확실한 것은 방향성입니다. LLM이 텍스트만 반환하는 시대는 빠르게 저물고 있습니다. 2026년 안에 주요 AI 에이전트 플랫폼들은 어떤 형태로든 구조화된 UI 생성 능력을 기본으로 탑재하게 될 것입니다.

OpenUI는 그 흐름에서 가장 뾰족한 제안을 던지고 있습니다. "JSON은 사람이 읽기 좋은 포맷이지, LLM이 생성하기 좋은 포맷은 아니다." 이 단순한 통찰이 3,000개의 GitHub 스타와 Hacker News 프론트페이지라는 결과로 이어졌습니다. 그리고 10,000명의 개발자 경험이 쌓인 Thesys C1 위에서 태어난 만큼, 단순한 학술적 제안이 아니라 프로덕션에서 검증된 접근이라는 점이 이 프로젝트의 가장 큰 강점입니다.

AI 에이전트가 코드를 작성하고, 데이터를 분석하고, 비즈니스 로직을 실행하는 세계에서, 그 에이전트가 적절한 인터페이스까지 함께 생성 할 수 있다면? 생성형 UI 표준 전쟁의 승자가 다음 세대 AI 앱의 기본 경험을 결정하게 될 것입니다.