shadcn/ui가 Radix를 버렸다: 프런트엔드 컴포넌트 프리미티브 전쟁의 서막

React로 UI를 만드는 개발자라면 shadcn/ui를 모르기 어렵습니다. GitHub 별 8만 개를 넘긴, 요즘 가장 뜨거운 컴포넌트 라이브러리인데요. 그런데 이 프로젝트가 최근 조용히, 그러나 결정적인 결정을 내렸습니다. 그동안 심장 역할을 하던 Radix UI를 걷어내고, Base UI를 새 기본값으로 삼은 겁니다. 버튼 색깔 바꾸는 수준의 이야기가 아닙니다. 프런트엔드 밑바닥에서 지각변동이 일어나고 있다는 신호입니다.

잠깐, shadcn/ui가 뭐길래 이게 중요한가요

shadcn/ui는 좀 독특한 물건입니다. 보통 컴포넌트 라이브러리는 npm으로 설치해서 가져다 쓰는데요. shadcn/ui는 다릅니다. 컴포넌트 코드를 내 프로젝트 안으로 복사해 넣는 방식입니다. 라이브러리를 ‘설치’하는 게 아니라 소스코드를 ‘가져오는’ 거죠.

이 방식이 폭발적인 인기를 끌었습니다. 코드가 내 것이 되니 자유롭게 뜯어고칠 수 있고, 버전 업데이트에 발목 잡히지도 않습니다. Vercel이 만든 Next.js 생태계와 궁합이 좋다는 점도 컸습니다.

그런데 여기서 함정이 하나 있습니다. shadcn/ui는 디자인을 담당할 뿐, 실제 동작의 뼈대는 다른 라이브러리에 맡겨왔다는 점입니다. 드롭다운이 열리고 닫히는 로직, 키보드로 메뉴를 넘나드는 접근성 처리, 포커스가 갇히는 모달 동작 같은 건 눈에 안 보이지만 만들기 정말 까다로운 부분인데요. 이 궂은일을 그동안 Radix UI가 도맡았습니다.

그런데 왜 Radix를 버렸을까요

핵심은 유지보수 활력입니다. Radix UI는 WorkOS가 인수한 뒤로 업데이트 속도가 눈에 띄게 느려졌다는 지적이 꾸준했습니다. 밀린 이슈가 쌓이고, React 최신 버전 대응도 더디다는 불만이 커뮤니티에서 반복적으로 나왔는데요. 인프라 역할을 하는 라이브러리가 정체되면, 그 위에 얹힌 shadcn/ui도 함께 발이 묶입니다.

여기서 Base UI가 등장합니다. Base UI는 그냥 새로 나온 무명 프로젝트가 아닙니다. Radix를 만든 핵심 개발자들과 Material UI(MUI) 팀이 손잡고 만든 물건입니다. 쉽게 말해, Radix의 정신적 후계자에 가깝습니다. 원조 제작진이 축적한 노하우를 새 그릇에 다시 담은 셈이죠.

shadcn 입장에서는 계산이 명확합니다. 정체된 옛 파트너 대신, 같은 유전자를 가졌으면서 더 활발하게 움직이는 새 파트너로 갈아타는 겁니다. 게다가 shadcn/ui는 코드를 복사하는 구조라, 엔진을 바꿔도 사용자 눈에 보이는 겉모습은 거의 그대로 유지할 수 있습니다. 갈아타기의 충격을 최소화할 수 있는 구조적 이점이 있는 거죠.

‘헤드리스’ 전쟁: 보이지 않는 곳의 진짜 싸움

이번 사건의 본질을 이해하려면 헤드리스(headless) 컴포넌트라는 개념을 짚어야 합니다. 헤드리스는 ‘머리가 없다’, 즉 디자인은 없고 동작 로직만 제공하는 부품을 뜻합니다.

왜 이걸 따로 떼어냈을까요. 접근성과 상호작용 로직이 생각보다 훨씬 어렵기 때문입니다. 예를 들어 콤보박스 하나를 제대로 만들려면, 스크린리더 대응, 키보드 조작, 화면 밖으로 삐져나가지 않게 위치 잡기 같은 수십 가지 엣지 케이스를 처리해야 합니다. 이걸 매번 새로 짜는 건 낭비죠. 그래서 Radix, Base UI, React Aria, Headless UI 같은 ‘엔진 전문’ 라이브러리들이 이 영역을 놓고 경쟁해왔습니다.

shadcn/ui가 어떤 엔진을 기본값으로 채택하느냐는 그래서 파급력이 큽니다. 수많은 개발자가 shadcn을 통해 그 엔진을 자연스럽게 쓰게 되니까요. shadcn/ui는 프런트엔드 세계의 사실상 표준 배포 채널에 가깝습니다. 여기 실리느냐 마느냐가 엔진 라이브러리의 운명을 좌우합니다. 이번 결정으로 Base UI는 단숨에 대세로 올라설 발판을 얻었고, Radix는 가장 큰 유통망을 잃은 셈입니다.

기존 사용자는 어떻게 되나요

가장 현실적인 걱정거리인데요. 이미 Radix 기반 shadcn/ui로 프로젝트를 굴리고 있는 사람은 어떻게 될까요.

당장 발밑이 꺼지지는 않습니다. shadcn/ui의 철학 자체가 ‘코드는 이미 네 것’이기 때문입니다. 이미 복사해둔 컴포넌트는 계속 작동합니다. 다만 새로 추가하는 컴포넌트부터 Base UI 기반으로 바뀌기 때문에, 한 프로젝트 안에 두 엔진이 섞이는 어색한 상황이 생길 수 있습니다.

기존 프로젝트를 통째로 Base UI로 이전하려면 손이 꽤 갑니다. API 이름이 다르고, 세부 동작에 미묘한 차이가 있어서 단순 찾아 바꾸기로 끝나지 않는 경우가 많습니다. 새 프로젝트라면 고민 없이 최신 방식을 따라가면 되지만, 운영 중인 서비스라면 마이그레이션 비용을 냉정하게 따져봐야 합니다. 급하게 갈아탈 이유는 없습니다.

마무리: 인프라의 주인이 바뀔 때

shadcn/ui의 이번 결정은 단순한 기술 선택이 아닙니다. 프런트엔드의 보이지 않는 토대를 누가 쥐느냐를 둘러싼 힘겨루기입니다. 원조 제작진이 만든 후계자 Base UI가 가장 강력한 유통망을 손에 넣었고, 정체됐던 Radix는 중대한 갈림길에 섰습니다.

기술 스택을 고를 때 우리는 겉으로 보이는 화려함에 끌리지만, 정작 프로젝트의 수명을 좌우하는 건 그 밑에 깔린 인프라의 건강입니다. 여러분이 지금 의존하고 있는 라이브러리, 그 아래에는 무엇이 돌아가고 있나요. 한 번쯤 발밑을 들여다볼 때입니다.