디자인 시스템·토큰 2025 완전 정복: Radix·shadcn/ui·Chakra·Tamagui·Park UI·Ark UI·DaisyUI 비교, W3C Design Tokens 표준, Figma Variables·Tokens Studio 연동, 컴포넌트 API 설계, 접근성, 한국 대기업 사례 — Season 6 Ep 2

프롤로그 · 디자인 시스템은 CSS가 아니다

2020년경부터 모든 조직이 "디자인 시스템 구축 프로젝트"를 시작했다. 2025년 현재, 성공한 시스템과 실패한 시스템이 분명히 갈린다.

• 실패한 시스템: CSS/컴포넌트 라이브러리만 있고, 아무도 안 씀
• 성공한 시스템: 조직의 공용 언어가 되어, 디자이너·엔지니어·PM이 같은 단어를 씀

흔한 오해 3가지:

1. "디자인 시스템 = 컴포넌트 라이브러리" (X)
2. "디자인 시스템 = 디자인 팀의 일" (X)
3. "디자인 시스템 = Figma 파일" (X)

진실:

디자인 시스템 = 토큰 + 컴포넌트 + 패턴 + 문서 + 거버넌스. 그리고 이걸 Figma·Code·Storybook에서 동일하게 표현하는 시스템.

2024-2025년은 Figma Variables와 W3C Design Tokens Community Group 표준이 자리잡으며 "Design-to-Code 연결이 드디어 실용화" 된 해였다. 이번 글은 그 지형도다.

1장 · 디자인 시스템의 5층 구조

성숙한 디자인 시스템은 5층 구조.

Layer 1: Primitive Tokens (원자 토큰)

• 컬러, 폰트, 간격, 반경, 그림자의 원시 값
• 예: color-slate-500 = #64748b, space-2 = 8px

Layer 2: Semantic Tokens (의미 토큰)

• Primitive에 의도를 부여
• 예: color-surface-primary, color-text-muted, color-border-critical
• 테마 전환(light/dark)에 핵심

Layer 3: Component Tokens

• 특정 컴포넌트에 종속된 토큰
• 예: button-primary-bg, card-shadow-hover

Layer 4: Components (컴포넌트)

• Button, Input, Card, Dialog 등 실제 UI 조각
• 접근성·키보드 내비게이션 내장

Layer 5: Patterns (패턴)

• 컴포넌트 조합·페이지 레이아웃 규칙
• 예: "에러 상태 패턴", "빈 상태(empty state) 패턴"

왜 3단계 토큰?

Primitive만 쓰면

• 다크모드 추가할 때 모든 컴포넌트 수정 필요
• 리브랜딩 시 대규모 변경

Semantic을 거치면

• color-surface-primary만 다크모드용 값으로 교체 → 자동 적용
• 조직이 커질수록 필수

2장 · 2025년 주요 컴포넌트 라이브러리 지형

(1) Radix UI (Primitives)

• Headless (스타일 없음) + 접근성 완벽
• Dialog·Popover·Select·Tooltip 등 복잡 패턴 내장
• Shadcn/UI의 기반
• WAI-ARIA 완벽 구현

(2) shadcn/ui

• "설치하지 말고 복사하세요" 철학
• Radix 기반 + Tailwind로 스타일
• 각 컴포넌트를 소유함 (본인 레포에 복사)
• 2024-2025 가장 인기
• 확장·커스터마이징 자유
• CLI(npx shadcn add button)로 편의성 ↑
• 한국 스타트업 표준처럼 자리

(3) Chakra UI

• 프로페셔널 완성형, Styled + 접근성
• sx prop으로 inline 스타일
• 엔터프라이즈에서 빠른 개발 선호

(4) Tamagui

• React Native + Web 동시 지원
• 컴파일 타임 최적화로 성능 우수
• 크로스플랫폼 앱에 이상적

(5) Park UI (Cva기반)

• Ark UI + Panda CSS + Class Variance Authority
• 디자인 시스템 빌더 관점

(6) Ark UI

• Zag.js 기반 headless (상태머신)
• React·Solid·Vue 모두 지원
• Radix의 멀티 프레임워크 대안

(7) DaisyUI

• Tailwind 기반 Styled 라이브러리
• 테마 시스템이 강력
• CSS-first, JS 의존 최소

(8) Mantine

• Chakra 비슷한 완성형
• Form·DataTable·Notifications 등 부가 기능 풍부

(9) HeroUI (구 NextUI)

• 현대적 디자인, React·Tailwind 기반
• 애니메이션 기본 탑재

(10) 엔터프라이즈: Ant Design, Material UI (MUI), Fluent UI

• 큰 조직·레거시 이어 쓰는 경우
• 2024-2025 새 프로젝트에선 shadcn 계열이 더 인기

종합 비교표

3장 · Headless vs Styled — 무엇을 선택할까

Headless (Radix·Ark·React Aria)

• 동작·접근성만 제공, 스타일 0
• 장점: 완전한 디자인 자유, 브랜드 정체성 표현
• 단점: 스타일링 책임 100% 본인
• 적합: 자체 디자인 시스템을 만드는 팀

Styled (Chakra·MUI·Ant·Mantine)

• 미리 디자인된 컴포넌트
• 장점: 빠른 개발, 기본 품질 보장
• 단점: 브랜드 고유성 제한, 오버라이드 피곤
• 적합: B2B SaaS·내부 도구

Hybrid (shadcn/ui·DaisyUI)

• Headless 엔진 + 시작용 스타일
• 소유권을 본인에게 이전 (shadcn)
• 장점: 빠른 시작 + 완전한 커스터마이징
• 2024-2025 주류

선택 기준

Headless가 맞는 경우

• 브랜드가 시각 정체성의 핵심 (럭셔리·크리에이티브 브랜드)
• 접근성·애니메이션에 극도 신경
• 엔지니어·디자이너가 디자인 시스템을 직접 만들 역량

Styled가 맞는 경우

• B2B 관리자 대시보드
• 시장 출시 속도 최우선
• 브랜드보다 기능성 중요

Hybrid(shadcn)가 맞는 경우

• 대부분의 스타트업·프로덕트 팀
• 시작은 빠르게, 성장 시 커스터마이징

4장 · W3C Design Tokens 표준

2024-2025년 W3C Design Tokens Community Group(DTCG) 의 표준 포맷이 자리잡았다.

표준 포맷 (DTCG 2024)

{
  "color": {
    "brand": {
      "primary": {
        "$value": "#0066ff",
        "$type": "color",
        "$description": "Main brand color"
      }
    }
  }
}

핵심 특징

• $value, $type, $description 필드
• Alias 지원: "$value": "{color.brand.primary}"
• 중첩 그룹
• Figma·Code 양방향 호환

주요 Type

• color, dimension, fontFamily, fontWeight, duration, cubicBezier, typography, shadow, gradient, transition, border

Figma Variables (2023-2024)

• 2023 말 GA. DTCG 호환
• 모드(Mode) 지원: Light/Dark, Mobile/Desktop
• 토큰을 Figma에서 직접 정의·사용

연동 도구

(1) Tokens Studio for Figma

• Figma에서 토큰 정의 → GitHub로 push
• Style Dictionary 형식·DTCG 지원
• 가장 성숙한 Figma ↔ Code 연결

(2) Specify

• 디자인 소스(Figma·Sketch)를 code repo로 자동 동기화
• CI 통합

(3) Style Dictionary (Amazon)

• 오픈소스 표준, 2024 v4.0 DTCG 지원
• 토큰 JSON → CSS/iOS/Android/Web 변환

(4) Supernova

• 엔드투엔드 디자인 시스템 플랫폼
• 토큰·문서·코드 생성 통합

실전 워크플로우

Figma Variables / Tokens Studio
         ↓ push
    GitHub (tokens/*.json)
         ↓ CI
    Style Dictionary
         ↓ build
[web.css, ios.swift, android.xml]
         ↓ publish
    NPM · CocoaPods · Maven

5장 · 컴포넌트 API 설계 원칙

라이브러리의 가치를 결정하는 것은 API 설계. 쓰기 좋으면 정착, 어려우면 외면.

5가지 원칙

(1) Composition over Props

• prop 수백 개 vs 컴포지션
• Bad: <Button leftIcon={...} rightIcon={...} loading iconOnly ... />
• Good: <Button><Button.Icon><Plus/></Button.Icon>추가</Button> 처럼 자식 조합으로

(2) Controlled + Uncontrolled 둘 다

• 기본은 Uncontrolled (상태 내부)
• 필요 시 Controlled 진입 (value / onChange)
• React 라이브러리의 표준

(3) asChild 패턴 (Radix)

• 부모 컴포넌트의 기능을 자식에게 위임
• 예: <Button asChild><Link href="/home">홈</Link></Button> — Button의 스타일·접근성을 Link가 가져간다

(4) Polymorphic as prop (단, 타입 복잡)

• <Box as="section"> 같은 태그 교체
• asChild 가 현대적 대안

(5) Variant 패턴

• Class Variance Authority(CVA), Tailwind Variants

const button = cva('base-classes', {
  variants: {
    size: { sm: '...', md: '...', lg: '...' },
    variant: { primary: '...', ghost: '...' },
  },
});

나쁜 신호

• API 변경이 잦다 — Breaking change가 매 분기
• 문서에 "보통은 이렇게 쓰지만 예외는..." 많음
• Prop 조합 시 버그 발생 잦음
• 커스텀 훅이 너무 많다 (라이브러리에 종속)

6장 · Theming과 Dark Mode

2025년 표준 접근

1. Semantic Tokens로 색 추상화 (surface, text, border)
2. CSS Variables 기반 테마 런타임 전환
3. prefers-color-scheme 미디어 쿼리 + 사용자 선택 저장
4. SSR 깜빡임 방지: localStorage 값을 서버에서 읽거나 initial HTML에 클래스 삽입

구현 예 (shadcn/ui 기본)

'use client';
import { ThemeProvider } from 'next-themes';

export default function Root({ children }) {
  return (
    <ThemeProvider attribute="class" defaultTheme="system">
      {children}
    </ThemeProvider>
  );
}

:root { --background: 0 0% 100%; --foreground: 222.2 84% 4.9%; }
.dark { --background: 222.2 84% 4.9%; --foreground: 210 40% 98%; }

색의 세분화 (2024-2025)

• 3상태 모드: system / light / dark
• 4~5 테마: 브랜드별 or 역할별 (예: admin·customer)
• HDR 지원 논의: 새 CSS color() 함수, P3 색 공간

7장 · 접근성(Accessibility) — 기본값 철학

"접근성은 추가 기능이 아니라 기본값이다."

WCAG 2.2 (2023) 핵심 변화

• Drag 조작에 Drag-less 대안 의무
• Target Size 24×24px 최소
• Consistent Help (도움말 위치 일관)
• Focus Indicator 명확

디자인 시스템 기본값

• 모든 interactive element에 키보드 지원
• Focus 가시적 링 (:focus-visible)
• Screen Reader 레이블 (aria-label/aria-labelledby)
• 색 대비 4.5:1 이상 (텍스트)
• 모션 감소 prefers-reduced-motion 존중

주요 도구

• axe-core, axe DevTools: 브라우저 자동 검사
• Lighthouse Accessibility
• Storybook a11y addon: 컴포넌트별
• NVDA·VoiceOver: 실제 Screen Reader 테스트

법적 요구

• EU 접근성 법(EAA) 2025년 6월 발효
• 한국 웹접근성 인증마크, 장애인차별금지법
• 미국 ADA·Section 508
• 글로벌 SaaS는 의무 수준

8장 · 모바일·크로스플랫폼 디자인 시스템

웹·모바일 공존 전략

(1) 분리 운영

• Web은 React, Mobile은 Swift/Kotlin 네이티브
• 토큰만 공유, 컴포넌트는 각자

(2) React Native 공유

• Web + Native 모두 React로
• Tamagui, Solito, Expo Router
• 토큰·컴포넌트 상당 부분 공유

(3) Flutter

• 전혀 다른 기술 스택, 자체 DS 구축 필요

2024-2025 트렌드

• Expo + React Native Web: 많은 스타트업 선택
• Apple HIG + Material You 차이 존중
• Responsive & Adaptive 조합: Breakpoint + Platform

9장 · 한국 대기업 디자인 시스템 사례

토스 (TDS / Toss Design System)

• Headless + shadcn 계열 영향
• 모션 디테일 극도로 신경
• 공개 블로그·컨퍼런스(SLASH)로 유명
• 자체 아이콘 시스템·토스체(Toss Font)

네이버 (NAVER Design System, NaverNow)

• Whale 브라우저·네이버 공통
• 접근성 선도 (국내 최초 WCAG 대응)
• 노출 범위가 매우 큼 (수억 사용자)

카카오 (Kakao Design Language)

• 카카오톡·페이·모빌리티·게임
• 통합 vs 서비스별 분리 균형
• Ryan·Apeach 캐릭터 강한 브랜드

쿠팡 (Coupang Design System)

• 대규모 이커머스 특화
• A/B 실험과 연계된 컴포넌트
• 다국가(미국·대만·일본) 지원

라인 (LINE Design System, LDS)

• 글로벌 팀 협업
• 접근성·국제화(i18n) 깊음
• 일본·태국 UX 고려

배달의민족 (Woowa Design System)

• 커스텀 Toss·Shadcn 혼용
• 개발·디자인 컨퍼런스 활발

공통 패턴

• Figma 라이브러리 ↔ Storybook 연동
• 토큰 Primitive/Semantic 분리
• 브랜드 단위 변형 (서비스별 색상)
• 내부 디자인 시스템 팀 10-30명 규모

10장 · 팀 규모별 도입 전략

1-3인 (솔로·초기 스타트업)

• shadcn/ui + Radix + Tailwind
• 토큰은 Tailwind config에 직접
• Figma Variables 가볍게 사용

10-30인 (Series A-B)

• shadcn 기반 자체 컴포넌트 라이브러리 분리 (monorepo 패키지)
• DTCG 토큰 JSON 별도 관리
• Storybook 도입, 사용 가이드 문서
• 디자인 시스템 담당자 0.5-1명

50-200인 (Series C+)

• 토큰 자동 동기화 파이프라인 (Tokens Studio → GitHub)
• 디자인 시스템 전담 팀 2-5명 (디자이너 + 엔지니어)
• 크로스팀 거버넌스·버전 관리
• 접근성 전담 리뷰

200-1500인 (대기업)

• 플랫폼 팀 5-20명
• 멀티 플랫폼 (Web + iOS + Android)
• 다국가 지원·법적 요구 (WCAG·ADA·EAA)
• 사내 디자인 시스템 컨퍼런스·교육

공통 실패 패턴

• 컴포넌트만 만들고 토큰 없음 → 다크모드 전환 불가
• 디자이너 ↔ 엔지니어 단절 → 구현과 디자인 불일치
• 문서 부재 → 사용 안 됨
• 거버넌스 없음 → 팀마다 fork, 다양성 폭발
• 마이그레이션 계획 없음 → 기존 UI 방치

11장 · 실전 · "shadcn으로 사내 디자인 시스템 시작하기" 90일

Day 1-14: 토큰 정의

• Figma Variables로 Primitive + Semantic 토큰
• DTCG JSON export
• CSS Variables로 web 반영

Day 15-30: 기초 컴포넌트

• Button, Input, Select, Dialog, Toast, Card
• shadcn CLI로 설치 후 브랜드에 맞춰 수정
• Storybook 셋업

Day 31-45: 패턴

• Form, Table, EmptyState, ErrorState
• 실제 제품 페이지 1-2개 재구성

Day 46-60: 거버넌스

• 기여 가이드, PR 리뷰 기준
• 변경 로그·SemVer

Day 61-75: 접근성

• axe·Storybook a11y 통합
• 키보드·스크린리더 테스트

Day 76-90: 확산·교육

• 사내 발표, 챔피언 지정
• 각 팀에 도입 지원

12장 · 다음 글 예고 — Season 6 Ep 3: "AI-Native UI와 Generative UX"

디자인 시스템이 있으면 다음은 AI가 UI를 만드는 시대. Ep 3은 AI-native UI 패턴.

• Generative UI: LLM이 직접 UI 선택·생성
• Streaming UI: 토큰 단위 점진적 렌더링
• Tool Use와 UI (Tool Call → Dynamic Card)
• AI SDK(Vercel), LangChain UI, LlamaIndex.TS UI
• 대화형 인터페이스 설계
• Feedback·Correction UX
• 불확실성·환각의 시각화
• 에이전트의 Human-in-the-loop UI
• Progressive Disclosure와 AI
• 2025년 AI 제품 UX 벤치마크

"AI가 응답을 생성하는 동안, 사용자는 무엇을 보는가?"

다음 글에서 만나자.

에필로그 · 체크리스트 12

1. 디자인 시스템이 토큰·컴포넌트·패턴·문서·거버넌스 5층을 갖췄는가?
2. Primitive + Semantic 토큰이 분리되어 있는가?
3. Figma ↔ Code 동기화 파이프라인이 있는가?
4. 컴포넌트가 Composition·Controlled·Variant 패턴을 일관되게 쓰는가?
5. Dark Mode가 테마 토큰만 교체로 자동 전환되는가?
6. 접근성(WCAG 2.2) 기본값이 내장되어 있는가?
7. Storybook·문서 사이트가 최신 상태인가?
8. DTCG 포맷으로 토큰이 저장되는가?
9. 기여 가이드·리뷰 기준이 문서화되어 있는가?
10. 기존 UI → 새 DS로 마이그레이션 계획이 있는가?
11. 디자인 시스템이 실제 제품에 80%+ 사용되는가?
12. 유지보수 담당이 명확한가?

"좋은 디자인 시스템은 보이지 않는다. 제품이 '당연히 이래야 한다'고 느껴지면, 시스템이 잘 작동하는 것이다."

— Season 6 Ep 2, Fin.