Skip to content

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

|

디자인 시스템·토큰 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 PrimitivesHeadless★★★★★★★★★★★★★★
shadcn/uiTailwind★★★★★★★★★★★★★★★
ChakraStyled★★★★★★★★★★★★
TamaguiStyled(cross)★★★★★★★★★★★중~높
Ark UIHeadless★★★★★★★★★★★★
DaisyUIStyled(CSS)★★★★★★★★★★
MantineStyled★★★★★★★★★★★★
MUIStyled★★★★★★★★★★★

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.

Design Systems and Tokens 2025 — Complete Guide: Radix, shadcn/ui, Chakra, Tamagui, Park UI, Ark UI, DaisyUI Compared, the W3C Design Tokens Standard, Figma Variables and Tokens Studio Integration, Component API Design, Accessibility, and Korean Enterprise Case Studies — Season 6 Ep 2

Prologue — A Design System Is Not CSS

Starting around 2020, every organization launched a "design system initiative." By 2025, the line between successful systems and failed systems is sharply drawn.

  • Failed systems: just a CSS or component library that nobody uses.
  • Successful systems: a shared language for the org — designers, engineers, and PMs use the same words.

Three common misconceptions:

  1. "Design system = component library" (wrong)
  2. "Design system = the design team's job" (wrong)
  3. "Design system = a Figma file" (wrong)

The truth:

Design system = tokens + components + patterns + docs + governance. And a system that expresses all of this identically across Figma, code, and Storybook.

2024–2025 was the year Figma Variables and the W3C Design Tokens Community Group standard settled in, and Design-to-Code integration finally became practical. This post is the map of that terrain.

Chapter 1 — The Five Layers of a Design System

A mature design system has five layers.

Layer 1: Primitive Tokens

  • Raw values for color, typography, spacing, radius, and shadow.
  • Examples: color-slate-500 = #64748b, space-2 = 8px.

Layer 2: Semantic Tokens

  • Assign intent to primitives.
  • Examples: color-surface-primary, color-text-muted, color-border-critical.
  • Essential for theme switching (light/dark).

Layer 3: Component Tokens

  • Tokens scoped to specific components.
  • Examples: button-primary-bg, card-shadow-hover.

Layer 4: Components

  • Actual UI pieces: Button, Input, Card, Dialog, etc.
  • Accessibility and keyboard navigation built in.

Layer 5: Patterns

  • Rules for composing components and laying out pages.
  • Examples: "error state pattern", "empty state pattern".

Why Three Token Tiers?

If you only use Primitives

  • Adding dark mode requires editing every component.
  • Rebranding means sweeping changes.

With Semantics in between

  • Swap only color-surface-primary for its dark-mode value and every consumer updates automatically.
  • Essential as the organization grows.

Chapter 2 — The 2025 Landscape of Component Libraries

(1) Radix UI (Primitives)

  • Headless (unstyled) with excellent accessibility.
  • Ships complex patterns: Dialog, Popover, Select, Tooltip.
  • The foundation of shadcn/ui.
  • Near-perfect WAI-ARIA implementation.

(2) shadcn/ui

  • "Don't install it — copy it."
  • Radix under the hood, Tailwind for styling.
  • You own each component (copy into your own repo).
  • Most popular choice in 2024–2025.
  • Unlimited freedom to extend and customize.
  • CLI (npx shadcn add button) for convenience.
  • Has become something like the default for Korean startups.

(3) Chakra UI

  • Polished and complete, Styled + accessible.
  • sx prop for inline styles.
  • Favored by enterprises for rapid development.

(4) Tamagui

  • React Native + Web simultaneously.
  • Compile-time optimization for strong performance.
  • Ideal for cross-platform apps.

(5) Park UI (CVA-based)

  • Ark UI + Panda CSS + Class Variance Authority.
  • Oriented toward design-system builders.

(6) Ark UI

  • Headless, built on Zag.js (state machines).
  • Supports React, Solid, and Vue.
  • A multi-framework alternative to Radix.

(7) DaisyUI

  • A Tailwind-based Styled library.
  • Powerful theme system.
  • CSS-first with minimal JS dependency.

(8) Mantine

  • Similar in scope to Chakra.
  • Rich add-ons: forms, data tables, notifications.

(9) HeroUI (formerly NextUI)

  • Modern design on React + Tailwind.
  • Animations built in.

(10) Enterprise: Ant Design, Material UI (MUI), Fluent UI

  • For large orgs or inherited legacy.
  • For new projects in 2024–2025, the shadcn family tends to win.

Head-to-head Comparison

LibraryStyleA11yCustomizationEcosystemLearning
Radix PrimitivesHeadlessfive starsfive starsfour starsmedium
shadcn/uiTailwindfive starsfive starsfive starslow
ChakraStyledfour starsfour starsfour starslow
TamaguiStyled (cross)four starsfour starsthree starsmed–high
Ark UIHeadlessfive starsfour starsthree starsmedium
DaisyUIStyled (CSS)three starsthree starsfour starslow
MantineStyledfour starsfour starsfour starslow
MUIStyledthree starsthree starsfive starsmedium

Chapter 3 — Headless vs Styled: Which Should You Pick?

Headless (Radix, Ark, React Aria)

  • Behavior and accessibility only; zero styles.
  • Pros: total design freedom; full brand expression.
  • Cons: 100% of the styling burden is yours.
  • Fits: teams building their own design system.

Styled (Chakra, MUI, Ant, Mantine)

  • Pre-designed components.
  • Pros: fast shipping; baseline quality guaranteed.
  • Cons: limited brand individuality; override fatigue.
  • Fits: B2B SaaS and internal tools.

Hybrid (shadcn/ui, DaisyUI)

  • Headless engine with starter styles.
  • Transfers ownership to you (shadcn).
  • Pros: fast start + full customization.
  • The mainstream choice in 2024–2025.

How to Decide

Pick Headless when

  • Brand is core to visual identity (luxury, creative brands).
  • You obsess over accessibility and animation.
  • Your engineers and designers can build a design system themselves.

Pick Styled when

  • You're building a B2B admin dashboard.
  • Time-to-market is the top priority.
  • Function matters more than brand.

Pick Hybrid (shadcn) when

  • You're a typical startup or product team.
  • You want to start fast and customize as you grow.

Chapter 4 — The W3C Design Tokens Standard

In 2024–2025 the W3C Design Tokens Community Group (DTCG) standard format has taken hold.

Standard Format (DTCG 2024)

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

Key Characteristics

  • $value, $type, $description fields.
  • Alias support: "$value": "{color.brand.primary}".
  • Nested groups.
  • Bi-directional Figma ↔ code compatibility.

Major Types

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

Figma Variables (2023–2024)

  • GA at the end of 2023, DTCG-compatible.
  • Mode support: Light/Dark, Mobile/Desktop.
  • Tokens defined and used directly in Figma.

Integration Tools

(1) Tokens Studio for Figma

  • Define tokens in Figma, push to GitHub.
  • Supports Style Dictionary format and DTCG.
  • The most mature Figma ↔ code bridge.

(2) Specify

  • Auto-syncs design sources (Figma, Sketch) to a code repo.
  • CI integration.

(3) Style Dictionary (Amazon)

  • Open-source standard; v4.0 (2024) added DTCG support.
  • Converts token JSON into CSS / iOS / Android / Web.

(4) Supernova

  • End-to-end design system platform.
  • Unified tokens, docs, and code generation.

A Real-World Workflow

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

Chapter 5 — Principles of Component API Design

The real determinant of a library's value is its API design. Pleasant to use means it sticks; painful means it gets abandoned.

Five Principles

(1) Composition over Props

  • Hundreds of props vs. composition.
  • Bad: <Button leftIcon={...} rightIcon={...} loading iconOnly ... />.
  • Good: something like <Button><Button.Icon><Plus/></Button.Icon>Add</Button> — compose via children.

(2) Both Controlled and Uncontrolled

  • Uncontrolled by default (internal state).
  • Enter controlled mode when needed (value / onChange).
  • Standard in React libraries.

(3) The asChild Pattern (Radix)

  • Delegate the parent's capabilities to a child.
  • Example: <Button asChild><Link href="/home">Home</Link></Button> — the Link inherits Button's styling and accessibility.

(4) Polymorphic as prop (but typing gets hairy)

  • Tag swap like <Box as="section">.
  • asChild is the more modern alternative.

(5) Variant Pattern

  • Class Variance Authority (CVA), Tailwind Variants.
const button = cva('base-classes', {
  variants: {
    size: { sm: '...', md: '...', lg: '...' },
    variant: { primary: '...', ghost: '...' },
  },
});

Warning Signs

  • Frequent API changes — breaking changes every quarter.
  • Docs full of "normally you do this, but the exceptions are...".
  • Bugs triggered by prop combinations.
  • Too many custom hooks (locks you into the library).

Chapter 6 — Theming and Dark Mode

The 2025 Standard Approach

  1. Semantic tokens abstract colors (surface, text, border).
  2. CSS Variables drive runtime theme switching.
  3. prefers-color-scheme plus a persisted user choice.
  4. No SSR flash: read localStorage on the server, or inject a class on the initial HTML.

Implementation (shadcn/ui default)

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

Finer Color Modeling (2024–2025)

  • Three-state mode: system / light / dark.
  • 4–5 themes: per brand or per role (e.g. admin vs. customer).
  • HDR conversation: new CSS color() function, the P3 color space.

Chapter 7 — Accessibility: A Defaults Philosophy

"Accessibility isn't an add-on — it's the default."

WCAG 2.2 (2023) Key Changes

  • Mandatory drag-less alternatives for drag interactions.
  • Target Size: minimum 24×24 px.
  • Consistent Help (help placed consistently).
  • Clear Focus Indicator.

Design System Defaults

  • Keyboard support on every interactive element.
  • Visible focus ring (:focus-visible).
  • Screen-reader labels (aria-label / aria-labelledby).
  • Color contrast of 4.5:1 or better (text).
  • Respect prefers-reduced-motion.

Key Tools

  • axe-core, axe DevTools: automated browser checks.
  • Lighthouse Accessibility.
  • Storybook a11y addon: per component.
  • NVDA, VoiceOver: real screen-reader testing.
  • EU Accessibility Act (EAA) went into effect June 2025.
  • Korea's Web Accessibility Certification Mark, Anti-Discrimination Act.
  • US ADA, Section 508.
  • Mandatory for any global SaaS.

Chapter 8 — Mobile and Cross-Platform Design Systems

Strategies for Web and Mobile Together

(1) Run Them Separately

  • React for web, native Swift/Kotlin for mobile.
  • Share tokens only; each platform owns its components.

(2) Share via React Native

  • Web and Native both in React.
  • Tamagui, Solito, Expo Router.
  • Significant token and component reuse.

(3) Flutter

  • A completely different stack — build your own DS.
  • Expo + React Native Web: common choice for startups.
  • Respect the differences between Apple HIG and Material You.
  • Responsive and adaptive combined: breakpoint plus platform.

Chapter 9 — Korean Enterprise Case Studies

Toss (TDS / Toss Design System)

  • Headless + shadcn-style influence.
  • Extreme attention to motion detail.
  • Public blog and conferences (SLASH) have given it a strong reputation.
  • Proprietary icon system and Toss Font.
  • Shared across Whale browser and Naver surfaces.
  • Accessibility leader (first in Korea to align with WCAG).
  • Massive exposure (hundreds of millions of users).

Kakao (Kakao Design Language)

  • KakaoTalk, Pay, Mobility, Games.
  • Balances unified vs. per-service divergence.
  • Strong brand anchors in Ryan and Apeach.

Coupang (Coupang Design System)

  • Tuned for large-scale e-commerce.
  • Components coupled to A/B experimentation.
  • Multi-country support (US, Taiwan, Japan).

LINE (LINE Design System, LDS)

  • Global team collaboration.
  • Deep investment in accessibility and i18n.
  • Accounts for Japanese and Thai UX.

Baemin / Woowa (Woowa Design System)

  • Mix of customized Toss-style and shadcn.
  • Active dev and design conference presence.

Shared Patterns

  • Figma library synced with Storybook.
  • Primitive / Semantic token split.
  • Brand-level variants (per-service colors).
  • Internal design-system teams of 10–30 people.

Chapter 10 — Adoption Strategy by Team Size

1–3 People (solo / early startup)

  • shadcn/ui + Radix + Tailwind.
  • Put tokens directly in Tailwind config.
  • Light use of Figma Variables.

10–30 People (Series A–B)

  • Split your own component library off shadcn (monorepo package).
  • Manage DTCG token JSON separately.
  • Adopt Storybook; write usage guides.
  • 0.5–1 person on design-system duties.

50–200 People (Series C+)

  • Automated token-sync pipeline (Tokens Studio → GitHub).
  • Dedicated design-system team of 2–5 (designer + engineer).
  • Cross-team governance and versioning.
  • Dedicated accessibility review.

200–1,500 People (enterprise)

  • Platform team of 5–20.
  • Multi-platform (Web + iOS + Android).
  • Multi-country support, legal compliance (WCAG, ADA, EAA).
  • Internal design-system conferences and training.

Common Failure Modes

  • Components without tokens — can't switch to dark mode.
  • Designer-engineer disconnect — implementation diverges from design.
  • No documentation — never gets used.
  • No governance — each team forks and the variety explodes.
  • No migration plan — legacy UI just sits there.

Chapter 11 — 90-Day Playbook: Starting an Internal DS with shadcn

Day 1–14: Define Tokens

  • Primitive and semantic tokens via Figma Variables.
  • Export DTCG JSON.
  • Project into web via CSS Variables.

Day 15–30: Foundation Components

  • Button, Input, Select, Dialog, Toast, Card.
  • Install via shadcn CLI, then adjust to your brand.
  • Stand up Storybook.

Day 31–45: Patterns

  • Form, Table, EmptyState, ErrorState.
  • Rebuild 1–2 real product pages on top of them.

Day 46–60: Governance

  • Contribution guide and PR review criteria.
  • Changelog and SemVer.

Day 61–75: Accessibility

  • Integrate axe and Storybook a11y.
  • Keyboard and screen-reader testing.

Day 76–90: Rollout and Enablement

  • Internal talks; designate champions.
  • Support each team's adoption.

Chapter 12 — Next Up: Season 6 Ep 3 — "AI-Native UI and Generative UX"

Once you have a design system, the next frontier is the era when AI builds the UI. Ep 3 is about AI-native UI patterns.

  • Generative UI: the LLM picks and generates the UI directly.
  • Streaming UI: token-by-token progressive rendering.
  • Tool Use and UI (Tool Call → Dynamic Card).
  • AI SDK (Vercel), LangChain UI, LlamaIndex.TS UI.
  • Designing conversational interfaces.
  • Feedback and correction UX.
  • Visualizing uncertainty and hallucination.
  • Human-in-the-loop UI for agents.
  • Progressive disclosure meets AI.
  • Benchmarks for AI product UX in 2025.

"While the AI generates its response, what is the user looking at?"

See you in the next post.

Epilogue — A 12-Point Checklist

  1. Does your design system cover all five layers: tokens, components, patterns, docs, governance?
  2. Are primitive and semantic tokens cleanly separated?
  3. Is there a Figma ↔ code sync pipeline?
  4. Do components consistently apply the composition, controlled, and variant patterns?
  5. Does dark mode switch automatically just by swapping theme tokens?
  6. Are WCAG 2.2 defaults baked in?
  7. Are your Storybook and docs site up to date?
  8. Are tokens stored in DTCG format?
  9. Are contribution and review guidelines documented?
  10. Is there a migration plan from legacy UI to the new DS?
  11. Is the design system actually used in 80%+ of real product surfaces?
  12. Is maintenance ownership clear?

"A good design system is invisible. When the product just feels 'as it should,' the system is working."

— Season 6 Ep 2, Fin.