AI가 UI를 찍어내는 속도가 빨라질수록, 역설적으로 '무엇을 설계해야 하는가'라는 질문은 더 선명해진다. 한 줄 프롬프트로 랜딩 페이지가 뚝딱 완성되고, AI 앱 빌더가 대시보드와 로그인 화면과 그라디언트 버튼을 동시에 토해내는 지금, 디자인 시스템을 고민하는 사람들에게 진짜 물어야 할 질문은 이것이다. "AI가 뽑아낸 결과물, 우리는 그다음에 무엇을 할 수 있는가?"
이미지가 아닌 '문서'를 돌려받아야 한다
Picorn을 3년간 만들어온 개발자가 MCP(Model Context Protocol) 워크플로우를 공개하며 던진 핵심 문제의식은 의외로 단순하다. 대부분의 AI 비주얼 도구는 에이전트에게 딱 하나의 행동만 허락한다—이미지를 생성하는 것. 결과물이 플랫 PNG라면 헤드라인 단어 하나를 바꾸거나, 제품 이미지를 20픽셀 이동하거나, CTA를 피사체 앞으로 꺼내려 할 때 에이전트가 할 수 있는 일은 전체를 다시 생성하는 것뿐이다.
그의 해법은 '레이어를 가진 문서'를 돌려받는 것이었다. 소셜 포스트 하나를 만들더라도 배경, 제품 이미지, 헤드라인 텍스트 레이어, CTA 레이어가 명확한 ID와 스태킹 순서를 갖춘 오브젝트 모델로 존재해야 한다. 그래야 에이전트가 "제품을 헤드라인 뒤로 보내줘" 혹은 "CTA만 바꿔줘"라고 동일한 오브젝트를 다시 지칭할 수 있다. 렌더 이미지는 소스가 아니라 문서의 '미리보기'로 격하된다.
그가 설계한 워크플로우는 이렇다. Claude나 Cursor가 캠페인 브리프를 받으면 MCP를 통해 Picorn에서 실제 레이어를 가진 프로젝트를 만들고, 컴포지션을 확인할 프리뷰를 렌더링한다. 같은 프로젝트가 브라우저 에디터에서 열리고, 사람이 처음부터 다시 시작하지 않고 크롭, 텍스트, 색상, 순서, 간격을 수정할 수 있다. 그리고 발행과 스케줄링은 반드시 명시적 승인 단계 뒤에 놓인다. "에이전트가 캠페인을 준비할 수는 있지만, 생성된 결과물이 연결된 소셜 계정에 조용히 올라가면 안 된다"는 것이 그의 원칙이다.
이 구조가 디자인 시스템 관점에서 흥미로운 이유는 따로 있다. 그는 Picorn의 MCP에 30개의 작은 도구를 노출시켰다. make_campaign 같은 단일 통합 도구 하나로 만들면 데모하기는 쉽지만, 첫 번째 결과가 틀렸을 때 에이전트가 수정할 구조를 숨겨버린다. 작은 도구들이 모델로 하여금 문서의 한 부분을 검사하고 수리하게 만든다. 이것은 컴포넌트 설계의 오랜 원칙—작고, 조합 가능하고, 각각이 명확한 책임을 갖는—을 AI 툴체인에 그대로 적용한 셈이다.
헤드리스 + 유틸리티: 브랜드가 라이브러리와 싸우지 않는 구조
AI가 UI를 생성하든, 사람이 컴포넌트를 직접 조립하든, 결국 질문은 같다. 이 결과물을 우리 브랜드처럼 보이게 만들 수 있는가? 리테일 POS 플랫폼을 만든 한 팀의 선택이 여기서 참고가 된다. 그들은 MUI나 Ant Design 같은 풀 컴포넌트 라이브러리 대신 Radix UI 프리미티브와 Tailwind CSS를 조합했다.
이유는 명확했다. 그들의 제품은 수십 개 화면에서 매일 상인과 사용자를 만나는 브랜드 접점이었다. "우리 로고를 붙인 기본 테마 컴포넌트 라이브러리"처럼 보여서는 안 됐다. Radix는 다이얼로그, 드롭다운, 셀렉트, 팝오버, 탭, 토스트, 툴팁 등 접근성이 검증된 비스타일 프리미티브를 제공한다. 포커스 트래핑, 키보드 내비게이션, ARIA 속성, 포털 렌더링 같은 "틀리기 쉬운 어려운 부분"을 처리하되, 어떻게 보여야 하는지에 대해선 어떤 의견도 내놓지 않는다.
이 팀이 구축한 구조는 세 레이어다. 스타일 없는 행동(Radix) → 스타일 입힌 프리미티브(자체 ui/ 폴더) → 제품 컴포넌트(피처 코드). 22개의 Radix 기반 컴포넌트가 중간 레이어에 살고, 제품 코드는 그 위에서만 조합한다. 시각적 정체성은 tailwind.config.ts의 CSS 변수로 관리되어, 다크 모드는 테마 객체를 복제하는 대신 변수 교체 한 번으로 처리된다. Radix가 data-state="open" 같은 데이터 속성으로 상태를 노출하기 때문에, 애니메이션은 Tailwind의 data-[state=...] 변형자로 직접 연결된다. JS 애니메이션 라이브러리가 필요 없고, 컴포넌트 라이브러리의 트랜지션 시스템과 씨름할 필요도 없다.
그런데 이 팀이 솔직하게 고백하는 것이 있다. 헤드리스+유틸리티 방식은 일관성을 기본으로 주지 않는다. MUI나 Ant Design은 <Table>이 하나고 <Modal>이 하나고 토스트 시스템이 하나다. 이 팀에는 자체 Radix 기반 토스트 시스템과 react-toastify가 동시에 살아있다. 디자인 결정이 아니라 점진적 도입의 잔재다. 컴포넌트 라이브러리였다면 애초에 하나의 토스트 API만 있었을 것이다. "브랜드 차별화"를 위해 지불하는 비용이 바로 이것—일관성은 팀이 능동적으로 유지해야 한다.
AI 앱 빌더 시대의 핵심: 가치 루프를 먼저 설계하라
AI 앱 빌더 Lovable이 2026년 133억 달러 밸류에이션으로 4억 달러 시리즈 C를 완료했다. 숫자보다 중요한 것은 그들이 다음에 무엇을 만들겠다고 선언했느냐다. 결제, 검색 가능성, 보안, 권한, 거버넌스, 그리고 소프트웨어가 의미 있는 성과를 냈는지 이해하는 시스템. 즉, '빌드 버튼' 너머의 세계다.
이 관점에서 AI 앱 빌더 생태계가 던지는 초보자 함정은 디자인 시스템 설계자에게도 동일하게 적용된다. AI 코딩 도구는 "진척되는 감각"을 만드는 데 탁월하다. 랜딩 페이지, 대시보드, 로그인 화면, 데이터베이스, 애니메이션 버튼이 순식간에 만들어진다. 그러나 화면의 집합은 제품 루프가 아니다.
가치 루프는 여섯 가지 질문에 답하는 것이다. 사용자가 앱을 여는 트리거는 무엇인가? 사용자가 제공하는 입력은 무엇인가? 앱이 수행하는 변환은 무엇인가? 사용자가 이전에 할 수 없었던 유용한 결과는 무엇인가? 앱을 닫고 다시 열어도 유지되어야 할 상태는 무엇인가? 사용자를 다시 불러오는 이유는 무엇인가? 이 여섯 가지 답이 없으면, AI에게 건네는 것은 아키텍처가 아니라 가구 카탈로그다.
세 가지 관점이 가리키는 하나의 방향
세 이야기는 서로 다른 레이어에서 같은 진실을 말하고 있다. Picorn의 MCP 워크플로우는 '편집 가능한 구조'를 생성 단계부터 설계해야 한다고 말한다. Radix UI + Tailwind 사례는 '일관성'이 도구가 보장해주는 것이 아니라 팀이 능동적으로 유지해야 할 설계 결정임을 증명한다. Lovable의 행보는 '만드는 것'과 '작동하게 하는 것' 사이의 거리가 실제 제품 설계의 영역임을 보여준다.
AI가 UI를 뽑아내는 속도가 올라갈수록, 디자인 시스템 설계자의 역할은 '컴포넌트를 만드는 사람'에서 '편집 가능성의 구조를 설계하는 사람'으로 이동한다. 어떤 레이어가 AI에게 열려 있고, 어떤 레이어는 사람이 판단해야 하는지. 어떤 상태가 유지되어야 하고, 어떤 변경이 승인을 거쳐야 하는지. 이 경계를 그리는 일이 지금 디자인 시스템 설계자에게 남겨진 가장 실질적인 과제다.