UI 생성 자동화 워크플로우 + vercel/json-render 도입기

AI 도입이 가속화되며 많은 업무가 자동화되고 있는 가운데, 저희 팀도 프로젝트마다 병목이 되던 디자인 생성 과정을 자동화하고자 했습니다. 이러한 배경 속에서 ‘디자인 프로세스 자동화’에 착수했으며, 저는 AI Agent를 활용해 일관된 UI를 자동으로 생성하는 워크플로우를 설계하고 구축했습니다.

워크플로우 구축을 시작하면서, 생각보다 빨리 부딪힌 문제가 하나 있었습니다. 화면을 "만드는 것" 자체는 점점 쉬워지는데, 정작 개발자가 보고 바로 구현할 수 있을 정도로 정리된 디자인을 안정적으로 얻는 일은 또 다른 문제였다는 점입니다. 특히 디자이너 없이 개발자 중심으로 빠르게 움직여야 하는 상황에서는 이 차이가 더 크게 느껴졌습니다.

처음에는 자연스럽게 생성 품질 자체를 높이는 방향으로 접근했습니다. Gemini와 Mastra agent를 묶어서 워크플로우를 만들고, 출력 포맷을 다듬고, 프로젝트에 맞는 흐름으로 정리하는 일은 예상보다 크게 어렵지 않았습니다. 문제는 그 다음부터였습니다. 디자인 시스템, 프로젝트 정보, 화면 맥락 같은 컨텍스트가 계속 붙기 시작하자 한 화면을 만드는 데 드는 비용이 빠르게 커졌습니다.

이번 글에서는 왜 vercel/json-render를 도입하게 되었는지, 기존 방식의 어떤 한계 때문에 방향을 바꾸게 되었는지, 그리고 현재 어떻게 진행중인지 정리해보려고 합니다.

도입하게 된 계기

가장 먼저 필요했던 것은 디자이너 없이 개발자가 보고 개발할 수 있는 디자인이었습니다. 여기서 말하는 디자인은 단순히 예쁘게 보이는 시안이 아니라, 구현 단위와 규칙이 어느 정도 정리되어 있어서 화면을 읽는 순간 바로 코드로 옮길 수 있는 형태에 가까웠습니다.

기존처럼 Figma를 중심에 두는 방식은 분명 익숙합니다. 하지만 저희가 원하는 흐름은 조금 달랐습니다. 가능하면 텍스트와 구조화된 데이터만으로도 화면을 설계하고, 그 결과를 반복 가능하게 만들고 싶었습니다. 즉, 화면 설계가 특정 툴에 묶이기보다 프로젝트 안의 데이터와 규칙 위에서 돌아가기를 원했습니다.

그래서 자연스럽게 Figma 의존성을 줄이고 싶다는 생각도 함께 커졌습니다. 디자인 파일을 따로 관리하고, 구현 시점에는 다시 해석하고, 변경이 생기면 또 따로 반영하는 흐름은 AI 기반 실험 속도와 잘 맞지 않았습니다. 가능하면 생성과 검토와 구현이 같은 맥락 안에서 이어져야 했습니다.

처음 시도했던 방식은 무엇이었을까요?

초기에는 Gemini와 Mastra를 이용해서 UI 생성 워크플로우를 직접 만들었습니다. 어떤 정보를 입력으로 넣을지 정하고, 어떤 구조로 응답을 받아야 할지 설계하고, 결과를 프로젝트에 맞게 조금씩 다듬어 가는 과정 자체는 생각보다 매끄러웠습니다. AI를 이용해 초안을 만들고, 그것을 프로젝트 컨텍스트에 맞게 보정하는 흐름은 충분히 작동했습니다.

적어도 가능한가 아닌가의 관점에서는 답이 빨리 나왔습니다. 프로토타입 수준에서는 꽤 빠르게 화면이 나왔고, 워크플로우를 다듬는 것 자체도 크게 막히지 않았습니다. 이 시점까지는 생성 품질을 더 밀어 올리면 원하는 방향으로 갈 수 있겠다고 생각했습니다.

그런데 실제 프로젝트 맥락을 계속 얹기 시작하자 병목이 분명해졌습니다. 단순한 화면 설명만 넣는 것이 아니라 디자인 시스템, 프로젝트 구조, 기존 제품 톤, 화면별 역할 같은 정보가 함께 들어가야 했기 때문입니다. 이 컨텍스트가 많아질수록 프롬프트는 길어졌고, 한 번의 생성 비용도 같이 커졌습니다.

실제로 부딪힌 문제는 품질보다 비용과 속도였습니다

가장 먼저 체감된 것은 시간입니다. 한 화면을 디자인하는 데 대략 10분 정도가 소요되기 시작했고, 이 시간이 반복되면서 흐름이 끊기기 시작했습니다. 처음 한두 번은 감수할 수 있어도, 여러 화면을 연속으로 다뤄야 하는 프로젝트에서는 꽤 부담스러운 비용이었습니다.

토큰 소모도 무시하기 어려웠습니다. 좋은 결과를 얻으려면 결국 더 많은 컨텍스트를 넣어야 했고, 그 컨텍스트가 길어질수록 생성 한 번의 부담도 커졌습니다. 결과적으로 원하는 디자인을 얻기 위해 점점 더 많은 설명이 필요해지는 구조가 되었습니다.

여기서 느낀 문제는 단순히 API 비용이 아니었습니다. 생성할 때마다 같은 종류의 맥락을 계속 주입해야 한다는 점, 그리고 그 과정을 거쳐도 결과가 완전히 재현 가능하다고 보기는 어렵다는 점이 더 큰 문제였습니다. 프로젝트에 쌓인 디자인 시스템과 제품 문맥이 많아질수록, 이 방식을 계속 확장하는 데 한계가 있다는 생각이 들었습니다.

그래서 vercel/json-render를 보게 됐습니다

다른 방법을 찾던 중 구글의 a2-ui라는 레퍼런스를 알게 됐고, 비슷한 결의의 프로젝트로 vercel/json-render도 보게 됐습니다. 두 프로젝트 모두 AI Agent 기반으로 UI를 생성하는 데에 초점을 두고 있었으며, 단순히 "멋진 화면을 한 번 생성하는 것"보다, 구조화된 데이터로 UI를 다루려는 방향이 보였습니다.

다만 vercel/json-render를 바로 프로젝트에 깊게 들이기 전, 중간 단계로 a2-ui의 프로토콜만 먼저 가져와 본 적도 있었습니다. 그 프로토콜을 참고해서 저희 쪽에서 custom json primitive component를 구성해 보고, 생성 결과를 조금 더 구조적으로 다룰 수 있는지 확인해 보려는 시도였습니다. 이 단계는 방향성을 검증하는 데에는 분명 도움이 됐지만, 결국 primitive 계층 자체를 계속 내부에서 관리해야 한다는 부담까지 사라지지는 않았습니다.

그중에서 최종적으로는 Vercel 쪽 솔루션을 더 진지하게 보기 시작했습니다. 가장 큰 이유는 생태계의 지속성에 대한 판단이었습니다. 구글 쪽은 흥미로운 레퍼런스나 프로젝트가 나와도 도중에 중단되는 경우가 잦다고 느꼈고, 장기적으로 프로젝트에 녹여내야 하는 입장에서는 이 부분이 꽤 크게 걸렸습니다. 프로젝트에 실제로 붙여 보면서 확장하기에는 vercel/json-render 쪽이 조금 더 손에 잡히는 느낌이 있었습니다. 단순 참고용 데모가 아니라, 실제 제품 안에서 규격과 렌더링을 맞춰 갈 수 있는 기반으로 보였습니다.

저희가 계속 직접 관리하고 있던 컴포넌트 카탈로그와 스키마, 그리고 그것을 프롬프트에 요약해서 넣는 방식은 유지비가 꽤 높았습니다. 반면 json-render를 기준으로 보면, 적어도 프리미티브 레벨의 source of truth를 외부 표준에 더 가깝게 둘 수 있겠다는 기대가 생겼습니다.

즉, 플래니가 계속 직접 소유해야 하는 것은 모든 UI 규격이 아니라 제품 고유의 계층이라고 봤습니다. 예를 들면 템플릿, 디자인 시스템 정책, 프로젝트 문맥, 화면 간 흐름 같은 것들입니다. 기본적인 렌더링 vocabulary까지 전부 내부에서 안고 가는 것보다는, 외부 생태계에 기대고 제품 고유 맥락에 더 집중하는 편이 맞다고 판단했습니다.

지금 현재는 ?

현재도 json-render에 대해 계속 탐구하고 있고, 워크플로우에 어떻게 잘 녹여낼지 연구를 이어 가고 있습니다. 다만 이 영역 자체가 아직 초기 단계이기 때문에, 도입한다고 해서 바로 모든 문제가 풀리는 것은 아니었습니다. json-render 자체도 꽤 초기이고, 실제 프로젝트에 맞게 붙이려면 예상보다 손이 많이 가는 부분들이 있습니다.

특히 디자인 시스템을 어디까지 외부 vocabulary에 맞추고, 어디부터는 프로젝트 고유 정책으로 남길지 정하는 일이 쉽지 않았습니다. 표준을 그대로 따르기만 해서는 부족하고, 그렇다고 로컬 규칙을 너무 많이 얹으면 다시 유지비가 커지기 때문입니다. 결국 이 균형을 어떻게 잡을지가 현재 가장 큰 숙제 중 하나입니다.

그럼에도 불구하고 방향 자체는 꽤 명확해졌습니다. AI가 만드는 결과를 매번 긴 설명으로 겨우 붙잡는 방식보다는, 구조화된 규칙과 렌더링 체계 안에서 반복 가능하게 만드는 쪽이 더 맞다는 확신이 생겼습니다. 지금은 다소 애를 먹고 있지만, 이 영역이 빠르게 발전하고 있다는 점도 분명히 체감하고 있습니다.

앞으로 기대하는 것

제가 기대하는 것은 단순히 "더 예쁜 화면이 더 빨리 나온다"는 수준이 아닙니다. 프로덕션 퀄리티의 디자인이 더 빠르게 나오되, 그것이 프로젝트 컨텍스트와 디자인 시스템 안에서 안정적으로 반복될 수 있는 상태에 더 가깝습니다.

아직은 분명 초기입니다. 도구도 초기이고, 저희가 그것을 프로젝트에 녹여내는 방식도 계속 실험 중입니다. 하지만 AI 시대가 막 열리기 시작한 지금 시점에서는, 이런 식의 구조화된 UI 표현 방식이 앞으로 점점 더 중요해질 것이라고 보고 있습니다.