기존의 UI 라이브러리를 사용하면서 추상화된 컴포넌트 뒤에 숨겨진 복잡한 로직과 스타일 제약으로 코드를 수정하기 어려웠기 때문에 약간의 걸림돌으로 느껴지곤 했습니다. 하지만 shadcn/ui를 공부하며 '컴포넌트의 소유권을 온전히 이전받는다'는 철학으로 더 이상 외부 라이브러리의 스타일에 갇히지 않고 직접 코드를 통제하며 번들 사이즈를 최적화할 수 있다는 것을 알게 되어 꼭 이 프로젝트에 사용해봐야겠다는 다짐을 하게 되었습니다.
이는 단순히 화면을 구현하는 것을 넘어, 서비스의 확장성과 유지보수성을 고려한 설계의 관점에서 UI를 고민해보았는데, 이제는 기술의 편리함에 의존하기보다 그 기술이 왜 그렇게 만들어졌는지 본질을 탐구하며 신중한 선택을 하는 개발자로 성장하고 싶습니다.
8. shadcn/ui
shadcn/ui는 Vercel이 만든 UI 컴포넌트 모음으로, Tailwind CSS + Radix UI를 결합해 쉽게 디자인 시스템을 구축할 수 있습니다.
8-1. 선정 이유
shadcn/ui는 '외부 라이브러리를 설치하는 것'이 아니라, '컴포넌트를 코드 내 프로젝트에 내재화하는 것'에 있다고 합니다. 따라서 기존 UI 라이브러리들과는 근본적으로 다음과 같은 차이가 있습니다.
1) 소유권
- 기존 UI 프레임워크(MUI, Chakra UI)와 달리, 컴포넌트를 직접 복사해서 내 프로젝트에 포함시키는 구조를 사용하고 있어 쉬운 커스터마이징과 완전한 제어가 가능하다.
- npm install이 아닌 npx shadcn-ui@latest add [component] CLI 명령어를 사용해, 필요한 컴포넌트의 소스 코드를 프로젝트의 특정 디렉토리(components/ui)에 직접 복사합니다.
- 이로 인해 개발자는 더 이상 외부 라이브러리의 블랙박스에 의존하지 않습니다. 컴포넌트의 모든 라인, 즉 로직, 스타일, 구조를 프로젝트의 요구사항에 맞춰 자유롭게 수정하고 확장할 수 있습니다. 따라서 외부 의존성을 최소화하여 장기적인 유지보수성을 높이는 방법입니다.
2) 자유로운 스타일링
- 모든 스타일은 Tailwind CSS 유틸리티 클래스로 작성되어 있습니다. 따라서 Emotion, styled-components와 같은 별도의 CSS-in-JS 라이브러리 학습 없이, 기존 Tailwind 지식만으로 신속하게 디자인을 수정하고 새로운 변형(variant)을 추가할 수 있습니다.
- CSS 변수 기반의 테마 시스템을 제공하여 다크 모드, 브랜드 컬러 등 전역적인 스타일 변경을 손쉽게 구현할 수 있습니다.
3) 번들 경량화
- 프로젝트에 실제로 사용하는 컴포넌트만 코드에 포함되기 때문에, 불필요한 코드가 번들에 포함되지 않아 Tree-shaking에 의존할 필요가 없이 처음부터 최적화된 번들 사이즈를 유지할 수 있습니다.
- Tailwind CSS 4.0과 공식적으로 호환되며 접근성(Accessibility)을 고려한 구성과, 유연한 스타일 확장성, SSR 환경에서도 안정적인 렌더링 지원 등의 장점 덕분에 최근 Next.js 기반 프로젝트에서 널리 사용되고 있습니다.
8-2. 기존 UI 프레임워크와 비교하기
| 항목 | shadcn/ui | MUI / Chakra UI | Tailwind CSS 단독 사용 |
| 아키텍처 | 컴포넌트 코드 직접 소유 | 라이브러리 의존성(npm 패키지) | 순수 유틸리티 클래스 |
| 커스터마이징 | 코드 레벨의 완전한 제어 (구조, 로직, 스타일 모두 수정 가능) | 제한적 제어 (Theme, sx prop, Style Overrides를 통한 간접 제어) | 완전한 자유도 (모든 컴포넌트를 직접 설계하고 구현해야 함) |
| 접근성 (a11y) | Radix UI 기반으로 완벽 지원 (WAI-ARIA 표준 내장) | 대부분 지원하지만, 일부 복잡한 컴포넌트는 추가 작업 필요 | 수동 설정 필수 (ARIA 속성, 키보드 인터랙션 등을 직접 구현) |
| SSR 호환성 | 매우 안정적 (정적 CSS 생성으로 Hydration 이슈 없음) | 잠재적 이슈 존재 (CSS-in-JS의 런타임 스타일 주입으로 Hydration Mismatch 발생 가능) | 설정 의존적 (PostCSS 등 빌드 파이프라인 설정 필요) |
| 스타일링 방식 | Tailwind CSS 유틸리티 (빌드 타임에 CSS 생성, 런타임 오버헤드 없음) | CSS-in-JS (Emotion) (런타임에 스타일 계산 및 주입, 성능 저하 가능성) | Tailwind CSS 유틸리티 |
| 의존성/번들 크기 | 최소화 (필요한 컴포넌트만 선택적으로 추가, 런타임 라이브러리 없음) | 높음 (프레임워크 전체가 의존성으로 추가됨) | 매우 작음 (필요한 유틸리티 클래스만 빌드에 포함됨) |
8-3. 왜 우리 서비스에 적합한가?
1) 개발 생산성 향상 가능
- 미리 구현된 컴포넌트를 기반으로 빠르게 UI를 구성하면서도(생산성), 필요할 땐 언제든지 내부 코드를 직접 수정(자유도)하여 서비스만의 디자인과 기능을 구현할 수 있습니다. 빠른 프로토타이핑과 브랜드 경험 구축이라는 두 마리 토끼를 모두 잡을 수 있는 방법입니다.
- React 서버 컴포넌트(RSC)를 비롯한 최신 Next.js 환경과의 호환성이 완벽하게 검증되었습니다. 나중에 기술 스택을 고도화할 때 발생할 수 있는 잠재적인 호환성 문제를 미연에 방지하고, 안정적인 서비스 운영이 가능합니다.
2) 우리만의 디자인 시스템 구축을 위한 초석
- shadcn/ui를 시작점으로 삼아, 서비스의 성장에 따라 컴포넌트를 점진적으로 발전시켜 자체적인 디자인 시스템(Design System)을 구축할 수 있습니다. 이는 장기적으로 협업 효율을 극대화하고, 전체적인 디자인 일관성을 유지하는 핵심적인 자산이 됩니다.
3) 모바일 중심 환경에서의 성능 극대화
- 채팅, 실시간 피드 등 인터랙션이 많은 우리 서비스 특성상, 번들 사이즈와 렌더링 속도는 사용자 경험에 직결되는 요소입니다.
- CSS-in-JS의 런타임 오버헤드가 없는 shadcn/ui는 모바일 환경에서도 쾌적한 성능을 보장하며, TBT(Total Blocking Time)와 같은 코어 웹 바이탈 지표 개선에 유리합니다.
'👩🏻💻 Develop > Document' 카테고리의 다른 글
| [설계 문서] Turbopack, Webpack 선정 이유 (0) | 2025.10.08 |
|---|---|
| [설계 문서] Axios 1.8.4 선정 이유 (0) | 2025.10.07 |
| [설계 문서] Zustand? Tanstack Query? 전역 상태 관리 라이브러리 선정하기 (0) | 2025.10.05 |
| [설계 문서] 서비스에 최적화된 TailwindCSS 4.0 선택하기 (0) | 2025.10.01 |
| [설계 문서] TypeScript를 선택한 이유 (vs JavaScript) (0) | 2025.09.29 |