필사 모드: 디자인 시스템·토큰 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 계열이 더 인기

종합 비교표

| 라이브러리 | 스타일 | 접근성 | 커스터마이징 | 생태계 | 학습 |

|---|---|---|---|---|---|

| Radix Primitives | Headless | ★★★★★ | ★★★★★ | ★★★★ | 중 |

| shadcn/ui | Tailwind | ★★★★★ | ★★★★★ | ★★★★★ | 낮 |

| Chakra | Styled | ★★★★ | ★★★★ | ★★★★ | 낮 |

| Tamagui | Styled(cross) | ★★★★ | ★★★★ | ★★★ | 중~높 |

| Ark UI | Headless | ★★★★★ | ★★★★ | ★★★ | 중 |

| DaisyUI | Styled(CSS) | ★★★ | ★★★ | ★★★★ | 낮 |

| Mantine | Styled | ★★★★ | ★★★★ | ★★★★ | 낮 |

| MUI | Styled | ★★★ | ★★★ | ★★★★★ | 중 |

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';

export default function Root({ children }) {

return (

{children}

);

}

: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.