Shadcn/UI가 Radix 대신 Base UI를 기본값으로 전환

 (ui.shadcn.com)
3P by GN⁺ | ★ favorite | 댓글 1개
  • shadcn/ui는 2026년 7월부터 새 프로젝트와 문서의 기본 흐름을 Base UI 중심으로 바꾸며, 2023년 출시 이후 이어진 Radix 기본값에서 방향을 전환함
  • Base UI는 1.6.0 안정 버전과 주간 600만 회 이상 다운로드에 도달했고, shadcn/create 프로젝트에서도 Radix보다 2:1로 더 많이 선택됨
  • Radix는 지원 중단되지 않으며, 기존 앱은 그대로 유지해도 되고 Base UI에만 있는 컴포넌트를 제외하면 업데이트와 새 컴포넌트도 계속 제공됨
  • 마이그레이션은 codemod가 아니라 에이전트 skill로 제공되어, 수정된 컴포넌트와 사용처를 컴포넌트 단위로 점진 이전하고 .migration/ 리포트와 git 커밋을 남김
  • 채팅 UI 컴포넌트, GitHub 저장소 기반 registry, shadcn eject, 새 스타일 Rhea까지 더해지며 shadcn/ui의 범위가 컴포넌트 배포와 제품 UI 구성 전반으로 넓어짐

Base UI가 기본 컴포넌트 라이브러리가 됨

  • 2026년 7월부터 Base UI가 shadcn/ui의 기본 컴포넌트 라이브러리로 지정됨
  • shadcn/ui는 2023년 1월 출시 당시 Radix 기반으로 만들어졌고, 당시 Radix는 스타일 없는 헤드리스 컴포넌트, API, 접근성, 실제 앱 사용 경험을 갖춘 선택지였음
  • Base UI는 Radix를 만든 사람들이 새로 만들고 있는 라이브러리이며, shadcn/ui는 기존 추상화를 유지한 채 모든 컴포넌트를 Base UI용으로 다시 만듦
  • 2025년 12월에는 npx shadcn create에서 두 라이브러리를 모두 선택할 수 있게 했고, 2026년 1월에는 Base UI 문서를 완성함

기본값을 바꾼 이유

  • Base UI의 안정성과 사용 흐름

    • Base UI 버전은 1.6.0임
    • 주간 다운로드는 600만 회 이상임
    • Base UI 팀은 새롭고 유용한 컴포넌트를 정기적으로 배포함
    • shadcn/ui의 새 프로젝트들은 Base UI를 사용 중임
    • shadcn/create로 생성되는 프로젝트는 Base UI를 Radix보다 2:1 비율로 더 많이 선택함
    • shadcn/ui는 이 선택 흐름을 공식 기본값으로 반영함

새 프로젝트와 문서에서 달라지는 점

  • 새 프로젝트에서 npx shadcn init을 실행하면 Base UI가 기본 선택지가 됨
  • shadcn/create는 Base UI를 먼저 보여줌
  • 문서의 컴포넌트 페이지는 Base UI 탭을 기본으로 열고, Radix 문서는 한 번의 클릭으로 접근할 수 있음

Radix 사용자가 알아야 할 점

  • Radix는 계속 지원됨

    • shadcn/ui는 Radix 지원을 유지함
    • Base UI에만 존재하는 컴포넌트를 제외하면 모든 업데이트와 새 컴포넌트는 두 라이브러리 모두에 제공됨
    • 기존 앱은 마이그레이션할 필요가 없음
    • Radix는 성숙하고 테스트된 라이브러리임
    • shadcn/ui도 Radix를 프로덕션에서 계속 사용 중이며, 자체 프로젝트도 마이그레이션하지 않음
    • 새 프로젝트에서 Radix를 선호하면 플래그를 사용할 수 있음
    • shadcn init을 비대화형으로 실행하는 스크립트나 CI가 Radix를 기대한다면 -b radix를 추가해야 기존 경로를 유지함
    • registry를 만들 때 특정 라이브러리에 고정하려면 registry:base 설정을 제공할 수 있음
    • 해당 설정이 없는 항목은 이제 Base UI로 초기화됨
    • 새 프로젝트에는 Base UI가 권장됨

Base UI로 이전하는 방식

  • 마이그레이션은 필수가 아니지만, 원할 경우 skill을 사용할 수 있음
  • 코딩 에이전트에는 다음처럼 요청할 수 있음
    • migrate accordion to base-ui
  • 기본 방식은 점진적 마이그레이션임
    • 컴포넌트와 사용처를 하나씩 이전함
    • 프로젝트는 계속 green 상태와 배포 가능한 상태를 유지함
    • 작업 중에는 두 라이브러리가 공존함
    • 중간에 멈췄다가 나중에 이어서 진행할 수 있음
    • 원하면 전체 프로젝트를 한 번에 요청할 수도 있음

codemod 대신 skill을 택한 이유

  • shadcn/ui 컴포넌트는 사용자가 소유하고 수정하는 코드라서, codemod는 손대지 않은 컴포넌트에는 맞더라도 수정된 컴포넌트에서는 깨질 수 있음
  • skill에는 이름 변경, prop 변경, 동작 차이가 양쪽 라이브러리 기준으로 손검수되어 들어 있음
  • 에이전트는 사용자가 바꾼 부분을 파악하고 그 변경을 이전 대상에도 반영함
  • 기계적으로 처리 가능한 변경은 전체에서 수정됨
    • 예: asChild는 render로 바뀜
  • 동작 변화는 조용히 패치되지 않고 표시되며, 최종 판단은 사용자가 함

마이그레이션이 남기는 결과물

  • 매 실행은 세 가지 결과를 남김
    • 동작하는 코드: 성공 보고 전에 타입체크와 빌드를 수행함
    • 컴포넌트별 리포트: 프로젝트 루트의 .migration/에 변경 사항, 그대로 둔 부분, 수동 확인 체크리스트를 남김
    • 깨끗한 git 이력: 브랜치 위에 컴포넌트당 하나의 커밋을 남기며, 롤백은 브랜치를 삭제하면 됨
  • 리포트 예시는 .migration/accordion.md이며, 다음 섹션을 포함함
    • Changed
    • Left alone
    • Behavior changes
    • Verify by hand
  • 숨겨진 상태 없이 진행 상황이 파일과 git 이력에 남기 때문에, 어떤 에이전트나 세션에서도 이어서 작업할 수 있음
  • Claude Code, Cursor, skill을 지원하는 에이전트에서 동작함
  • 실제 프로젝트 테스트에서는 60개 이상 컴포넌트 중 36개가 Radix였고, 전체 마이그레이션은 약 25분, 컴포넌트당 약 1만 토큰으로 진행됨
  • 빌드는 깨끗하게 통과했고 커스터마이징은 유지됨

채팅 인터페이스용 컴포넌트 추가

  • 2026년 6월에는 채팅 인터페이스를 만들기 위한 새 컴포넌트가 추가됨
  • 첫 단계는 대화 레이어를 구성하는 핵심 조각임
    • 스크롤
    • 메시지 행
    • 말풍선
    • 첨부
    • 마커
  • MessageScroller는 대화용 스크롤 컨테이너임
    • anchored turns
    • streamed replies
    • saved thread restore
    • prepended history
    • jump-to-message
    • scroll controls
    • visibility tracking을 처리함
  • MessageScroller는 메시지, AI 상태, 전송, 저장, 모델 상태를 소유하지 않으며, 콘텐츠 렌더러는 사용자가 제공함
  • MessageScroller는 @shadcn/react의 스타일 없는 헤드리스 컴포넌트로도 제공됨

Message, Bubble, Attachment, Marker의 역할

  • Message는 대화의 한 행을 배치함
    • 아바타
    • 정렬
    • 헤더
    • 콘텐츠
    • 푸터
    • 그룹 메시지를 다룸
  • Bubble은 메시지 표면을 렌더링함
    • variants
    • 정렬
    • reactions
    • links
    • buttons
    • collapsible content를 지원함
  • Attachment는 파일과 이미지를 렌더링함
    • media
    • metadata
    • upload state
    • actions
    • 별도로 클릭 가능한 action을 유지하는 full-card trigger를 제공함
  • Marker는 상태 업데이트, 시스템 노트, 테두리 행, 라벨 구분선을 렌더링함
    • streaming state
    • tool activity
    • date breaks 같은 용도에 사용됨
  • 이 컴포넌트들은 작게 설계되어 AI 채팅, support inbox, team thread, group chat, 제품별 대화 UI에 조합할 수 있음

채팅 UI용 CSS 유틸리티와 @shadcn/react

  • 새 CSS 유틸리티 두 개가 추가됨
    • scroll-fade: 스크롤 컨테이너 가장자리에 스크롤 인지 fade를 추가함
    • shimmer: "Thinking…", "Generating response…", 도구 실행, 스트리밍 마커 같은 라이브 상태 텍스트에 shimmer를 추가함
  • 두 유틸리티는 shadcn/tailwind.css에 포함됨
    • npx shadcn@latest init으로 초기화한 프로젝트에는 이미 포함됨
  • @shadcn/react는 스타일 없는 헤드리스 React 컴포넌트를 위한 새 패키지임
    • 첫 primitive는 @shadcn/react/message-scroller
    • registry 컴포넌트는 shadcn/ui 스타일로 감싸지만, anchoring, auto-follow, prepend preservation, scroll commands, visibility 같은 스크롤 동작은 패키지에 있음
  • 이 방식은 시각 스타일에 묶이지 않고 동작을 제공하며, 어려운 상호작용 로직을 한곳에서 테스트할 수 있게 함
  • Radix와 Base UI 모두에서 사용 가능함

AI Elements와의 관계

  • 새 채팅 컴포넌트는 AI Elements를 대체하지 않음
  • AI Elements의 AI 인터페이스 컴포넌트와 패턴은 계속 사용할 수 있음
  • 이번 릴리스는 채팅의 핵심 조각을 shadcn/ui에 하나씩 가져오는 데 초점이 있음
  • 이미 AI Elements 컴포넌트를 쓰고 있다면 앱을 다시 작성할 필요가 없음
  • 더 새로운 추상화, 업데이트된 스타일, Radix와 Base UI 양쪽 지원이 필요할 때 shadcn/ui 버전을 시도할 수 있음

GitHub 저장소를 registry로 사용

  • 2026년 6월부터 공개 GitHub 저장소를 registry로 사용할 수 있음
  • 저장소 루트에 registry.json을 추가하고 배포할 항목을 정의하면 사용자가 shadcn CLI로 GitHub에서 직접 설치할 수 있음
  • GitHub registry는 source registry임
    • shadcn build를 실행할 필요가 없음
    • 생성된 item JSON 파일을 publish할 필요가 없음
    • registry 서버를 설정할 필요가 없음
  • CLI는 루트의 registry.json을 읽고 include 항목을 해석하며, 요청된 항목을 찾아 해당 파일을 설치함
  • registry 항목은 컴포넌트에 제한되지 않음
    • components
    • hooks
    • utilities
    • design tokens
    • feature kits
    • project conventions
    • agent instructions
    • testing setup
    • CI workflows
    • release workflows
    • templates
    • codemods
    • migration kits
    • 기타 프로젝트 파일을 배포할 수 있음
  • GitHub registry 주소는 기존 registry 주소와 같은 명령에서 동작함
    • list
    • search
    • view
    • install

shadcn eject와 shadcn/tailwind.css

  • Radix와 Base UI를 모두 지원하면서 두 라이브러리가 의존하는 공유 Tailwind 유틸리티를 둘 장소가 필요해짐
    • 예: data-open:, data-closed: 같은 custom variant
    • 예: no-scrollbar 같은 utility
  • RTL 지원 작업 중 일부 버그도 모든 컴포넌트에 중복 적용하는 대신 한곳에서 고치기 쉬웠음
  • 이를 위해 shadcn/tailwind.css 가 만들어짐
    • init 실행 시 전역 CSS 파일에 @import "shadcn/tailwind.css"가 추가됨
    • tw-animate-css 같은 CSS import처럼 동작함
    • 프로덕션에서는 tree-shaken되고 빌드 시 해석되는 작은 의존성임
  • shadcn 패키지의 CSS 의존을 원하지 않으면 shadcn eject 를 사용할 수 있음
    • shadcn/tailwind.css를 전역 CSS 파일에 inline함
    • 프로젝트에서 shadcn 의존성을 제거함
  • monorepo에서는 components.json과 전역 CSS 파일이 있는 workspace에서 명령을 실행해야 함

새 스타일 Rhea

  • 2026년 5월에는 새 shadcn/ui 스타일 Rhea가 추가됨
  • Rhea는 더 compact한 Luma로, 작은 spacing과 더 조밀한 surface를 갖고 focused product interface를 위해 만들어짐
  • Rhea는 Luma의 부드러움과 형태를 유지하면서 버튼, 입력, 메뉴, 카드, 리스트를 더 타이트하게 배치함
  • Luma의 --spacing을 조정하는 방식은 선택하지 않음
    • --spacing은 multiplier이므로 바꾸면 앱 전반에서 p-2, w-4, m-16 같은 익숙한 Tailwind utility의 의미가 달라짐
  • Rhea는 별도 스타일로 제공되어 component size, gap, density를 직접 조정하면서 underlying utility scale은 예측 가능하게 유지함
  • Rhea는 shadcn/create에서 Radix와 Base UI 모두에 사용할 수 있음

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견들

  • 이 글에서 Claude 특유의 문체가 꽤 선명하게 느껴져서 이제는 좀 피곤하고 거리감이 듦
    중요한 제품 출시 글조차 사람이 온전히 신경 쓸 가치가 없다면, 어디서 선을 그어야 할지 모르겠음

    • 글은 필요한 내용을 효과적으로 전달했고, 사람이 읽기 좋게 작성·구조화된 것처럼 보였음
      AI로 작성해서 이 훌륭한 오픈소스 소프트웨어 개발에 더 많은 시간을 쓸 수 있었다면, 오히려 좋은 일이라고 봄
    • 무슨 말인지 정확히 알겠음. Claude와 plannotator를 자주 쓰는데, 특정 스타일 가이드를 요청한 뒤 훨씬 나아졌음
      “CD 시대 MSDN 레퍼런스와 Raymond Chen 블로그 스타일”을 출발점 프롬프트로 삼았더니 AI가 만든 계획을 소화하는 능력이 크게 올라갔고, 겸손하고 통찰력 있으며 독자를 존중하는 스타일이라 강력 추천함
    • 글을 읽어봤는데 AI가 쓴 것처럼 들리진 않았음
      팀 누군가가 사람이 썼다고 나서면 좀 웃길 것 같음
    • 진지하게 묻자면, 왜 그게 중요한가 싶음. 초안을 쓴 뒤 Claude의 문장을 검토하고 게시했을 수도 있음
      AI가 업무를 도와줄 때마다 왜 굳이 “잡아내려” 하는지 모르겠고, 이건 F500 회사가 아니라 오픈소스 프로젝트임. 자원도 제한적이고 영어가 모국어가 아닐 수도 있음
    • 오히려 피곤하게 들을 일이 아니라고 봄. 지금처럼 쓰이고 제시되는 방식은 기만과 거짓에 가깝기 때문임
      협력의 문화에는 신뢰와 진실이 필요하다고 믿고, AI가 “내가 했다/말했다”고 거짓으로 말하는 글은 원치 않음
      예를 들어 이 글이 정말 Claude가 쓴 것이라면, “I said”, “I meant it”처럼 팀의 사람이 직접 말한 것처럼 가장하는 이유가 무엇인지 의문임. 그건 사칭이고 기만적임. 협력과 정직을 지키는 문화라면 “내 인간이 말했다”라고 하거나, 최소한 인간을 대신해 행동하는 AI라고 제대로 표시해야 함

  • 지루한 애플리케이션에서는 사람들이 Mantine 같은 전통적인 UI 라이브러리보다 shadcn의 복사·붙여넣기 방식을 선호하는지 궁금함
    복사·붙여넣기 방식은 수정이 쉽지만 새 문제도 생김. 그냥 버전 번호만 올리면 될 일에 이제 업그레이드 AI 에이전트가 필요해지는 식임

    • “그냥 버전 번호만 올리면 된다”는 말은 지난 몇 년간 Material UI가 만든 골칫거리를 심하게 과소평가함
      지루한 앱이 아니라 아주 큰 앱에서, 주요 버전 업데이트마다 API를 크게 뒤엎어서 지루한 마이그레이션이 필요했음. shadcn으로 옮긴 뒤에는 단일 컴포넌트만 업그레이드하고 새 컴포넌트는 자유롭게 추가할 수 있어 쉬워졌음. Material UI에서는 어디서든 새 기능을 쓰려면 전체를 새 API에 맞춰 바꿔야 했지만, shadcn은 선택적으로 가능함
    • 복사·붙여넣기 방식은 전혀 이해하지 못했음. Shadcn은 그냥 유행 냄새가 나고, 직접 복사해 써봐도 뭐가 대단한지 모르겠음
      그래도 즐겨 쓰면 되고, AI의 장점 중 하나는 HN이 예전만큼 JavaScript 프레임워크 얘기로 막히지 않는다는 점임
    • 새 프로젝트에서는 점점 벤더링(vendoring) 쪽으로 기울고 있음
      기성 UI 라이브러리를 가져오면 단기적으로는 쉽지만, 대개 과하게 복잡하고, 안 쓸 기능까지 구현돼 있으며, 같은 라이브러리를 쓰는 수많은 앱과 차별화하려 할 때 수정이 어렵고, 업그레이드할 때 그 수정들이 미묘하게 깨짐. 가장 좋은 접근은 자기 UI 라이브러리를 만드는 것이라고 봄. 직접 소유하고, 여러 프로젝트에서 재사용하며, 원하면 같은 시각 스타일을 유지하고, 필요한 기능만 추가할 수 있음
    • Mantine은 훌륭함. 빠르게 거의 뭐든 만들 수 있고, 이후 확장하거나 테마와 개별 컴포넌트를 완전히 커스터마이즈할 수 있음
      학습 곡선은 있지만 거대한 수준은 아니라고 봄
    • 많은 시스템에서 실제로는 “그냥 버전 번호만 올리기”가 거의 아님. 컴포넌트 라이브러리가 정확히 원하는 일을 해줄 때만 그렇게 가능함
      실제로는 필요한 동작을 컴포넌트가 완전히 제공하지 않는 경우가 많고, 사람들은 컴포넌트에 추가 CSS를 자주 덧붙임. 대안이 몇 시간짜리 작업이라면 CSS 두 줄은 매우 유혹적이지만, 그 두 줄도 컴포넌트 라이브러리의 새 기능마다 검증해야 함. 이런 CSS 땜질이 많아지면 업그레이드는 하나의 프로젝트가 됨

  • 이런 인기 UI 툴킷들이 div를 과도하게 렌더링하는 게 거슬림
    Base UI를 보니 거의 모든 컴포넌트가 “요소를 렌더링한다”는 식인데, 아코디언에는 details/summary처럼 같은 일을 할 수 있는 네이티브 요소가 있음. 네이티브 웹 전도사는 아니고 웹 API, 특히 HTML에도 잘못된 점이 많다고 보지만, div 남용도 잘못임

  • Shadcn을 써봤고 대체로 좋아하지만, Radix 기반 라디오 버튼은 좀 과했음. 비슷하게 지나치게 부풀린 해법이 쓰인 선택지도 있음
    https://news.ycombinator.com/item?id=46688971

  • 마이그레이션 작업이 codemod에서 LLM으로 옮겨가는 흐름이 흥미로움
    codemod가 더 결정적이긴 해도, 그 시대가 끝나가고 있는지 궁금함

    • LLM을 활용해 결정적 codemod를 만들면 어떨까 싶음
      그런 다음 codemod를 실행하고 다른 결정적 안전장치를 붙여 반복하면서, 결과를 다시 LLM에 넣어 codemod를 개선할 수 있음
    • 원문 글의 프레이밍은 위험한 사고방식임. codemod 자체는 있어도 되고 없어도 됨
      원하는 것은 LLM용 skill 파일이 아니라 사람을 위한 문서여야 함. 사람을 위한 마이그레이션 가이드를 쓰면 됨. 결국 skill 파일과 문서는 같은 것이어야 한다는 사실을 깨닫는 데 시간이 좀 걸릴 것임
    • 여기서 codemod가 무엇을 뜻하는지 궁금함
    • 둘은 완벽하게 보완한다고 생각하고 앞으로도 그럴 것임
      부드러운 규칙에는 AGENTS.md 파일을 계속 쓰고, 강한 규칙에는 커스텀 린터 규칙을 쓰는데, 이게 두 세계의 장점을 모두 가져가는 방식이라고 봄

  • shad-CN을 쓰고 싶지만 매번 결국 Mantine으로 돌아가게 됨
    어떤 컨텍스트를 연결해야 하는지 기억하는 것보다 훨씬 빠름

  • 이 변화가 사용자에게 번들 크기 감소 같은 더 나은 결과를 주는지 궁금함
    아니면 Shadcn 유지보수자들의 삶의 질을 높이는 변화에 가까운가 싶음

  • Angular에서 shadcn/ui에 해당하는 것은 무엇인지 궁금함
    PrimeNG가 최근 라이선스를 바꿔서 새 프로젝트에 맞는 대안을 찾는 중임

    • PrimeNG 라이선스 변경을 HN에 띄우려는 두 번의 시도[1]가 실패했지만, PrimeTek 컴포넌트 라이브러리를 쓰고 있다면 이 변경을 알아야 함
      PrimeNG, PrimeReact, PrimeVue는 모두 완전한 폐쇄 소스로 전환되고, 2027년부터 지속 사용 라이선스는 개발자 좌석당 800달러가 됨[2]. 기존 저장소는 아카이브됨[3]. PrimeFaces는 계속 오픈소스지만, 이제 PrimeTek 직원이 아닌 독립 자원봉사 개발자들이 개발·유지보수함
      [1]: https://hn.algolia.com/?q=The+Next+Chapter+of+PrimeTek
      [2]: https://primeui.dev/nextchapter
      [3]: https://github.com/primefaces/primeng
    • 같은 상황임. 직장에서 여러 앱에 PrimeNG를 써왔고, 적절한 대체재를 찾기 전까지는 Angular 21에 묶이게 될 듯함
      다만 한 그룹이 PrimeNG를 포크했고 유지보수할 계획이라고 함. 새 이름은 아직 미정임
      https://github.com/openng-org/open-prime
    • https://spartan.ng/
    • Shadcn과 비슷한 시스템이 Svelte, Angular, Nunchucks 같은 여러 스택에서 직접 쓸 수 있게 아직 제공되지 않는 데 대한 대응으로 Lily Design System을 만들고 있음
      전부 무료 오픈소스이고, 피드백이나 제안을 보내주면 Lily에 쉽게 추가할 수 있음
      https://lilydesignsystem.github.io
    • https://www.zardui.com

  • 예전식 스큐어모픽 스타일 가이드가 그리움
    마지막이 Blueprint였던 것 같음

  • URL은 https://ui.shadcn.com/docs/changelog/2026-07-base-ui-default여야 함

답변달기