같은 날, 두 개의 신호
며칠 사이에 흥미로운 신호 두 개가 거의 동시에 떴다. shadcn/ui가 2023년 출시 이후 계속 유지해온 Radix 기본값을 버리고 Base UI로 전환한다는 공식 발표, 그리고 Figma의 전략적 방향에 의문을 제기하는 날카로운 분석 글. 표면적으로 이 둘은 별개의 이야기처럼 보이지만, 나는 같은 질문을 가리키고 있다고 읽는다. AI가 실행 비용을 낮추는 시대에 디자인 시스템과 컴포넌트 전략의 무게중심은 어디로 이동하는가.
shadcn/ui의 선택: 커뮤니티 실측값이 기본값이 되다
shadcn/ui의 Base UI 전환(출처: GeekNews)은 기술적 결정이기 이전에 데이터 기반 결정이다. shadcn/create로 새 프로젝트를 만들 때 사용자들이 이미 Base UI를 Radix보다 2:1로 더 많이 선택하고 있었고, Base UI는 주간 600만 다운로드와 1.6.0 안정 버전이라는 수치로 성숙도를 증명했다. shadcn/ui는 그 흐름을 공식 기본값으로 추인한 것이다.
주목할 점은 Radix를 버리지 않았다는 것이다. 기존 앱은 마이그레이션 의무가 없고, 업데이트와 새 컴포넌트는 Base UI 전용 컴포넌트를 제외하면 양쪽 모두에 계속 제공된다. 이 결정은 파괴가 아니라 방향 재설정에 가깝다.
마이그레이션을 codemod가 아닌 에이전트 skill로 푼 이유
shadcn/ui 컴포넌트는 사용자가 직접 소유하고 수정하는 코드다. codemod는 원본 코드에는 맞지만, 팀이 손댄 커스터마이징 위에서는 깨진다. 그래서 shadcn/ui가 선택한 마이그레이션 방식은 AI 에이전트 skill이다.
에이전트는 컴포넌트 단위로 점진적으로 이전하면서 .migration/ 리포트와 깨끗한 git 커밋을 남긴다. 실제 테스트에서는 60개 이상 컴포넌트 중 36개 Radix 컴포넌트를 약 25분, 컴포넌트당 1만 토큰으로 마이그레이션했고 빌드는 통과했다. 기계적으로 처리할 수 있는 변경은 자동화하고, 동작 변화는 사람에게 판단을 넘긴다. 이건 AI를 단순 코드 생성기가 아니라 점진적 리팩터링의 협업자로 쓰는 방식이다.
채팅 UI와 GitHub registry: 컴포넌트 시스템의 범위 확장
이번 업데이트에서 또 하나 눈에 띄는 건 shadcn/ui의 범위 자체가 넓어지고 있다는 점이다. MessageScroller, Message, Bubble, Attachment, Marker 같은 채팅 인터페이스 전용 컴포넌트가 추가됐고, GitHub 저장소를 registry로 직접 사용할 수 있게 됐다. 서버 없이 registry.json 하나로 컴포넌트·훅·디자인 토큰·에이전트 인스트럭션까지 배포할 수 있다.
새 스타일 Rhea도 의미있다. --spacing 멀티플라이어를 건드리지 않고 컴포넌트 수준에서 밀도를 조정한다는 설계 결정은 디자인 시스템의 예측 가능성을 지키면서 변형을 허용하는 섬세한 접근이다. shadcn/ui는 단순한 컴포넌트 모음집에서 제품 UI 구성 인프라로 진화하고 있다.
Figma의 딜레마: 캔버스는 진실의 원천인가
Figma에 관한 분석 글(출처: GeekNews)은 더 근본적인 질문을 던진다. 캔버스 기반 디자인 도구가 만들어진 전제는 시각적 의도와 동작하는 소프트웨어 사이에 번역 비용이 크다는 것이었다. Figma는 그 번역 과정을 멀티플레이어 협업 공간으로 만들어서 Sketch를 구식으로 만들었다.
그런데 AI가 그 번역 거리를 좁히면 캔버스의 존재 이유가 흔들린다. 디자인 시스템, API, 패턴에 접근하는 프롬프트가 직접 코드화된 인터페이스를 만들어낸다면, 캔버스는 더 이상 실행 직전 단계의 진실이 아니다. 캔버스는 표현(representation)이었고 실제 제품은 코드에 있었는데, 그 갭이 줄어드는 속도가 캔버스의 역할을 재정의하고 있다.
AI 시대의 병목은 실행이 아니라 조정(coordination)이다
이 분석에서 가장 날카로운 통찰은 여기다. AI가 실행 비용을 낮추면 병목은 이동한다. "인터페이스를 만들 수 있는가"가 아니라 "올바른 기준과 조직적 신뢰 하에서 올바른 인터페이스를 만들 수 있는가"가 핵심 질문이 된다.
어떤 컴포넌트가 승인됐는가, 어떤 패턴이 폐기됐는가, 문서와 코드와 Figma 파일이 서로 다를 때 무엇이 권위 있는 구현인가. 이건 캔버스 문제가 아니라 인프라 문제다. 이 세계에서 디자인 시스템은 사람이 참조하는 문서가 아니라 AI 시스템에게 조직의 만드는 방식을 알려주는 실행 가능한 지능(executable intelligence)이 된다.
두 신호가 가리키는 같은 방향
shadcn/ui와 Figma의 이야기는 결국 같은 압력에 대한 서로 다른 응답이다. shadcn/ui는 컴포넌트를 사용자 소유 코드로 만들고, 에이전트가 그 코드를 점진적으로 다룰 수 있는 구조를 만들었다. 헤드리스 컴포넌트와 Tailwind의 조합, GitHub registry, 에이전트 skill 기반 마이그레이션은 모두 "코드가 진실"이라는 전제 위에서 작동한다.
Figma는 반대 방향의 유혹 앞에 서 있다. 모든 것을 캔버스로 되돌리려는 전략은 단기적으로 유용한 기능을 만들 수 있지만, 코드와 런타임이 진실의 중심이 되는 세계에서는 캔버스를 예쁜 그림으로 만들 위험이 있다. 분석 글이 말하는 "피벗 경로"—캔버스를 중심이 아닌 살아있는 시스템을 시각적으로 추론하는 하나의 뷰로 삼는 것—는 맞는 방향이지만, 현재 사업을 성립시키는 가정을 포기해야 하는 결정이다.
프로덕트 관점에서 지금 해야 할 질문
디자인 시스템을 운영하는 팀이라면 지금 이 전환기에 물어봐야 할 질문이 있다. 우리 디자인 시스템은 사람이 읽는 문서인가, 아니면 AI가 실행할 수 있는 구조화된 지식인가. 컴포넌트의 진실은 Figma 파일에 있는가, GitHub에 있는가, 아니면 둘이 계속 어긋나고 있는가.
shadcn/ui의 Base UI 전환이 흥미로운 건 기술적 선택 때문이 아니다. 커뮤니티의 실측값을 기본값으로 만들고, 마이그레이션을 에이전트가 다룰 수 있는 skill로 설계하고, 컴포넌트 시스템의 범위를 제품 UI 인프라 수준으로 넓혔다는 것—이 세 가지가 함께 보여주는 그림이 흥미롭다. 디자인과 코드의 경계는 사라지는 게 아니라, 더 코드 쪽으로 다시 그어지고 있다.