---
title: "shadcn/ui, 기본 컴포넌트 라이브러리를 Radix에서 Base UI로 변경"
published: 2026-07-05T04:46:08.000Z
canonical: https://jeff.news/article/4675
---
# shadcn/ui, 기본 컴포넌트 라이브러리를 Radix에서 Base UI로 변경

shadcn/ui가 새 프로젝트의 기본 컴포넌트 라이브러리를 Radix가 아니라 Base UI로 바꿨어. Radix 지원은 계속되지만, Base UI가 안정화됐고 주간 다운로드 600만 이상, shadcn/create 신규 프로젝트 선택 비율 2대1이라는 이유로 기본값을 바꾼 거야. 동시에 채팅 UI용 MessageScroller와 관련 컴포넌트, headless 패키지인 @shadcn/react도 공개됐어.

## shadcn/ui의 기본값이 바뀜

- shadcn/ui가 오늘부터 새 프로젝트의 기본 컴포넌트 라이브러리를 Base UI로 바꿨음
  - 2023년 1월 shadcn/ui가 처음 나왔을 때는 Radix가 기반이었음
  - 당시 Radix는 비스타일 headless 컴포넌트, 접근성, API, 실전 검증 측면에서 사실상 독보적인 선택지였음

- 이번 변경은 “Radix 버림”이 아니라 “새 프로젝트 기본값 변경”에 가까움
  - Radix는 폐기되지 않고 계속 지원됨
  - 업데이트와 새 컴포넌트도 양쪽 라이브러리로 제공할 예정임
  - 단, 어떤 컴포넌트가 Base UI에만 있으면 예외가 생길 수 있음

- shadcn/ui가 Base UI를 기본값으로 바꾼 이유는 꽤 명확함
  - Base UI가 안정화됐고 현재 버전은 1.6.0임
  - 주간 다운로드가 600만 이상임
  - shadcn/create로 만든 프로젝트에서 Base UI 선택이 Radix보다 2대1로 많았음
  - shadcn 팀도 새 프로젝트에는 Base UI를 쓰고 있다고 밝힘

> [!IMPORTANT]
> 기존 Radix 기반 앱은 마이그레이션할 필요 없음. shadcn/ui 쪽도 “프로덕션 앱에서 컴포넌트 라이브러리를 갈아엎는 건 최악에 가깝다”는 입장을 유지하고 있음.

## 새 프로젝트와 자동화에 생기는 변화

- 이제 `npx shadcn init`을 실행하면 Base UI가 기본 선택지임
  - shadcn/create에서도 Base UI가 먼저 표시됨
  - 문서의 컴포넌트 페이지도 Base UI 탭을 기본으로 열고, Radix 문서는 한 번 클릭하면 볼 수 있음

- CI나 스크립트에서 조용히 깨질 수 있는 지점이 있음
  - 비대화형으로 `shadcn init`을 돌리면서 Radix가 기본이라고 가정한 스크립트는 `-b radix` 플래그를 붙여야 기존 경로를 유지함
  - 레지스트리를 만드는 경우 특정 라이브러리를 고정하려면 `registry:base` 설정을 제공해야 함
  - 설정이 없는 항목은 이제 Base UI로 초기화됨

- 마이그레이션은 codemod 대신 ‘스킬’ 방식으로 제공됨
  - 이유는 프로젝트마다 컴포넌트를 복사한 뒤 변형, 클래스 변경, 새 프롭 추가를 해두기 때문임
  - 단순 codemod는 손대지 않은 컴포넌트에는 먹히지만, 커스터마이징된 코드에서 깨지기 쉽다는 판단임

- 마이그레이션 방식은 점진적 전환을 전제로 함
  - 컴포넌트 하나와 그 사용처를 한 번에 옮기고, 프로젝트는 계속 빌드 가능한 상태로 유지하는 식임
  - 두 라이브러리가 동시에 공존할 수 있고, 중간에 멈췄다가 나중에 이어서 진행할 수 있음
  - 기계적으로 바꿀 수 있는 건 전체 반영하되, 동작 차이는 자동 수정하지 않고 확인 대상으로 표시함

```mermaid
sequenceDiagram
    participant 개발자
    participant shadcn초기화
    participant BaseUI
    participant Radix
    participant 프로젝트
    개발자->>shadcn초기화: npx shadcn init 실행
    shadcn초기화->>BaseUI: 기본 라이브러리로 선택
    개발자->>shadcn초기화: -b radix 지정 시
    shadcn초기화->>Radix: 기존 경로 유지
    shadcn초기화->>프로젝트: 선택한 기반으로 컴포넌트 생성
```

## 채팅 컴포넌트도 같이 공개됨

- shadcn/ui는 채팅 인터페이스용 컴포넌트 묶음도 새로 냈음
  - MessageScroller, Message, Bubble, Attachment, Marker가 포함됨
  - 첫 단계는 대화 레이어, 즉 스크롤, 메시지 행, 말풍선, 첨부파일, 마커에 집중함

- MessageScroller는 스트리밍 채팅에서 은근히 망가지기 쉬운 스크롤 문제를 맡음
  - 고정된 턴, 스트리밍 응답, 저장된 스레드 복원, 이전 기록 추가, 특정 메시지로 이동, 스크롤 컨트롤, 가시성 추적을 처리함
  - 대신 메시지 데이터, AI 상태, 전송 계층, 저장소, 모델 상태는 소유하지 않음
  - 콘텐츠 렌더러는 사용자가 가져오는 구조임

- 나머지 컴포넌트는 채팅 UI의 반복 부품을 담당함
  - Message는 아바타, 정렬, 헤더, 본문, 푸터, 그룹 메시지 레이아웃을 다룸
  - Bubble은 말풍선 표면, 변형, 정렬, 반응, 링크, 버튼, 접힘 콘텐츠를 처리함
  - Attachment는 파일과 이미지, 메타데이터, 업로드 상태, 액션을 렌더링함
  - Marker는 스트리밍 상태, 도구 실행, 날짜 구분선 같은 시스템성 표시를 맡음

- 새 CSS 유틸리티도 추가됨
  - `scroll-fade`는 스크롤 컨테이너 가장자리에 더 볼 콘텐츠가 있다는 힌트를 주는 페이드를 넣음
  - `shimmer`는 “생각 중”, “응답 생성 중”, 도구 실행 상태 같은 라이브 텍스트에 반짝이는 효과를 줌
  - 둘 다 `shadcn/tailwind.css`에 포함돼, 최신 init 프로젝트에서는 바로 쓸 수 있음

## @shadcn/react의 의미

- `@shadcn/react`라는 새 headless React 패키지도 나왔음
  - 첫 primitive는 `@shadcn/react/message-scroller`임
  - shadcn/ui 레지스트리 컴포넌트는 스타일을 입힌 래퍼이고, 어려운 스크롤 동작은 패키지 안에 들어감

- 이 구조는 꽤 실용적인 분리임
  - 프로젝트는 여전히 복사해서 고치는 shadcn/ui 스타일을 유지함
  - 하지만 스크롤 고정, 자동 따라가기, 이전 기록 추가 시 위치 보존 같은 까다로운 상호작용 로직은 테스트된 한 곳에서 가져올 수 있음
  - AI Elements를 대체하는 건 아니고, 필요한 부분만 독립적으로 채택하라는 방향임

---

## 기술 맥락

- shadcn/ui가 Base UI를 기본값으로 바꾼 건 “새 라이브러리가 더 힙해서”가 아니라, 기본 선택의 비용을 다시 계산한 결과에 가까워요. 안정 버전, 다운로드 수, 실제 신규 프로젝트 선택 비율, 내부 사용 경험이 쌓였기 때문에 기본값을 움직인 거예요.

- 기존 앱에 마이그레이션을 강요하지 않는 것도 중요한 결정이에요. 컴포넌트 라이브러리는 버튼 몇 개 바꾸는 문제가 아니라 접근성 동작, 포커스 처리, 포털, 애니메이션, 테스트 스냅샷까지 흔들 수 있거든요.

- codemod 대신 스킬을 택한 이유도 shadcn/ui의 사용 방식과 맞닿아 있어요. shadcn/ui는 패키지를 설치해 쓰는 모델이 아니라 코드를 프로젝트로 복사해 고치는 모델이라, 각 팀의 커스터마이징을 이해하지 못하면 자동 변환이 쉽게 깨져요.

- MessageScroller를 headless 패키지로 뺀 건 채팅 UI에서 특히 합리적이에요. 스트리밍 응답 중 자동 스크롤, 이전 메시지 prepend 후 위치 보존, 특정 메시지 점프 같은 건 UI 스타일보다 동작 정확성이 더 중요하기 때문이에요.

## 핵심 포인트

- 새 shadcn/ui 프로젝트는 Base UI가 기본값이며 Radix는 계속 지원됨
- CI나 스크립트에서 Radix를 기대했다면 -b radix 플래그를 명시해야 함
- 채팅 인터페이스용 MessageScroller, Message, Bubble, Attachment, Marker 컴포넌트가 추가됨

## 인사이트

프론트엔드 팀에선 ‘당장 마이그레이션해야 하나?’보다 ‘기본값 변경이 새 프로젝트와 내부 디자인 시스템에 어떤 영향을 주나?’를 보는 게 맞아. 특히 shadcn init을 자동화해둔 팀은 기본값 변경이 조용히 들어올 수 있으니 확인 필요함.
