부제: Semantic·Elastic·MUI를 돌다 Tailwind·shadcn까지
1·2편은 경계와 상태·계약이었다. 오늘은 화면.
용어
- Semantic UI / Elastic UI / MUI: 완성도 높은 컴포넌트·테마를 한 번에 쓰는 UI 키트 계열.
- Tailwind CSS: 유틸리티 클래스로 스타일을 조합하는 프레임워크. 팀끼리 같은 말로 간격·색을 말하기 좋다는 면에서 협업에 도움이 될 수 있다.
- Radix UI: 접근성·키보드 동작 위주의 헤드리스 프리미티브.
- shadcn/ui: Radix 등을 바탕으로 컴포넌트 소스를 프로젝트에 복사해 가져가 쓰는 흔한 패턴.
- CVA(class-variance-authority): 버튼 variant/size처럼 조합 규칙을 정리하는 유틸.
1) 여러 키트를 돌아다닌 이유
외부용 제품이 아니면 디자인·기획 지원을 사실상 못 받는 경우가 많았다. 그래서 완성도 높은 키트를 여러 가지 도입했다. 개발자 입장에선 필요한 기능을 빨리 주려는 목적이 컸다.
결과적으로 일관성·완성도가 떨어져 보인다는 피드백도 있었다. 키트 탓이라기보다 조건에 가깝게 기억한다.
잠깐 개념: UI 키트가 해 주는 것
버튼·다이얼로그 같은 반복 UI와 접근성 기본값을 빨리 준다. 반면 제품 전체가 한 브랜드처럼 보이게 만드는 건 팀 합의·커스터마이징이 필요하다.
2) “안 맞았다”보다 철학 혼재·MUI 통일 후회
안 맞다기보다, 키트마다 디자인 철학이 비슷하기도 다르기도 해서 한 결이 안 보일 수 있었다. 돌이켜 보면 MUI만 일관되게 썼으면 나았겠다는 생각도 든다. 예전에 Semantic UI, Elastic UI, MUI를 순회했던 시절이 있었다.
커스텀 컴포넌트를 제법 만들어야 했고, 그때마다 키트만으로는 아쉬움이 있었다.
3) shadcn — 내부 조사는 해 뒀고, 프로젝트가 없어 미뤘다
아쉬움을 줄일 수 있겠다는 쪽으로 기술 조사를 해 둔 적이 있다. 도입 시기는 불명확했고 밀 만한 프로젝트가 없어 미뤘다. 지금 학습용 베이스에서 처음 제대로 붙인다.
잠깐 개념: shadcn이 다른 점
npm에 완성 테마 하나만 있는 형태보다, 소스를 내 레포로 가져와 고치기 쉽다는 설명이 흔하다.
4) Tailwind — 스타일시트 이슈 + 협업
스타일 시트 이슈로 써 봤다. 기획 지원은 없었어도 협업 차원에서 필요하다고 느꼈다.
5) 지금 레포에 깔린 것
tailwindcss ^4.2.2, @tailwindcss/postcss, Radix 계열, CVA, clsx, tailwind-merge, lucide-react, **components.json**.
6) 트레이드오프
지원이 부족한 현실에서 속도와 일관성 사이를 어떻게 잡을지가 늘 문제였다. 지금은 다른 무게중심을 시험 중이다.
4편은 JPA·Snowflake·MyBatis·Flyway와 Postgres·Drizzle이다.
