사례 연구
shadcn, Radix, Stitch, Material 3 등 실제 AI-First 디자인 시스템 적용 사례
실제 사례를 통해 AI-First 디자인 시스템의 설계 원칙과 구현 패턴을 분석합니다.
사례 1: shadcn/ui 분석
2026년 shadcn/ui 주요 변화
- CLI v4 (2026.3):
registry:base로 디자인 시스템 전체 배포,shadcn/skills로 AI 에이전트 컨텍스트 주입 - Base UI 듀얼 지원 (2026.1): Radix UI 외에 MUI의 Base UI도 프리미티브로 선택 가능
- 통합
radix-ui패키지 (2026.2): 개별@radix-ui/react-*대신 단일 패키지 - 프레임워크 확장: Next.js, Vite, TanStack Start, React Router, Astro, Laravel 지원
AI 친화적 특징
1. 명시적 variant 시스템
// shadcn/ui의 Button variant 정의
const buttonVariants = cva(
'inline-flex items-center justify-center rounded-md text-sm font-medium...',
{
variants: {
variant: {
default: 'bg-primary text-primary-foreground hover:bg-primary/90',
destructive: 'bg-destructive text-destructive-foreground hover:bg-destructive/90',
outline: 'border border-input bg-background hover:bg-accent...',
secondary: 'bg-secondary text-secondary-foreground hover:bg-secondary/80',
ghost: 'hover:bg-accent hover:text-accent-foreground',
link: 'text-primary underline-offset-4 hover:underline',
},
size: {
default: 'h-10 px-4 py-2',
sm: 'h-9 rounded-md px-3',
lg: 'h-11 rounded-md px-8',
icon: 'h-10 w-10',
},
},
defaultVariants: {
variant: 'default',
size: 'default',
},
}
)AI 관점:
- 모든 variant가 명시적으로 열거됨
- 각 variant의 스타일 차이가 명확
- TypeScript로 자동완성 가능
2. Semantic Token 기반
/* shadcn/ui의 CSS 변수 */
:root {
--background: 0 0% 100%;
--foreground: 222.2 84% 4.9%;
--primary: 222.2 47.4% 11.2%;
--primary-foreground: 210 40% 98%;
--destructive: 0 84.2% 60.2%;
--destructive-foreground: 210 40% 98%;
/* ... */
}AI 관점:
- 색상이 용도(semantic)로 명명됨
- 하드코딩 없이 토큰 참조
- 테마 전환이 변수 교체만으로 가능
3. Compound Component 패턴
// Card 컴포넌트 구조
<Card>
<CardHeader>
<CardTitle>제목</CardTitle>
<CardDescription>설명</CardDescription>
</CardHeader>
<CardContent>본문</CardContent>
<CardFooter>
<Button>액션</Button>
</CardFooter>
</Card>AI 관점:
- 컴포넌트 구조가 명확
- 슬롯 기반 합성
- 역할별 서브 컴포넌트
shadcn/ui의 한계와 개선점
| 한계 | AI-First 개선 |
|---|---|
| 문서가 산문 중심 | 구조화된 메타데이터 추가 |
| 검증 도구 없음 | ESLint 플러그인 추가 |
| MCP 미지원 | MCP 서버 래퍼 구축 |
사례 2: Radix Primitives 분석
접근성 자동화
// Radix Dialog - 접근성 자동 처리
<Dialog.Root>
<Dialog.Trigger asChild>
<Button>열기</Button>
</Dialog.Trigger>
<Dialog.Portal>
<Dialog.Overlay />
<Dialog.Content>
{/*
자동 처리:
- role="dialog"
- aria-modal="true"
- 포커스 트랩
- Escape로 닫기
- 외부 클릭 닫기
*/}
<Dialog.Title>제목</Dialog.Title>
<Dialog.Description>설명</Dialog.Description>
<Dialog.Close asChild>
<Button>닫기</Button>
</Dialog.Close>
</Dialog.Content>
</Dialog.Portal>
</Dialog.Root>상태 관리
// Radix의 내부 상태 머신 (예시)
const dialogMachine = {
initial: 'closed',
states: {
closed: {
on: {
OPEN: 'open',
},
},
open: {
entry: ['focusTrap', 'lockScroll'],
exit: ['releaseFocusTrap', 'unlockScroll'],
on: {
CLOSE: 'closed',
ESCAPE: 'closed',
OUTSIDE_CLICK: { target: 'closed', cond: 'modal' },
},
},
},
}AI 관점:
- 상태 전이가 명확하게 정의됨
- 예측 가능한 동작
- 문서화하기 쉬움
사례 3: 실제 프로젝트 적용
프로젝트 배경
## 프로젝트: 기업용 대시보드
- 팀: 프론트엔드 5명, 디자이너 2명
- 기간: 3개월
- 목표: 신규 디자인 시스템 도입 + AI 코드 생성
## 기존 상태
- 하드코딩된 스타일 다수
- 일관성 없는 컴포넌트
- 접근성 미준수마이그레이션 과정
Week 1-2: 토큰 정의
// 감사 결과
const auditResult = {
hardcodedColors: 127, // #hexcode 직접 사용
hardcodedSpacing: 89, // px 직접 사용
inconsistentVariants: 23, // 같은 역할 다른 스타일
}
// 정의한 토큰 구조
const tokens = {
colors: {
// 12가지 시맨틱 색상
},
spacing: {
// 4px 기반 12단계
},
typography: {
// 6가지 텍스트 스타일
},
}Week 3-4: 코어 컴포넌트
// 마이그레이션한 컴포넌트 (우선순위순)
const coreComponents = [
'Button', // 가장 많이 사용
'Input', // 폼의 기본
'Card', // 레이아웃 기본
'Dialog', // 모달 통합
'Table', // 데이터 표시
'Dropdown', // 네비게이션
]
// 각 컴포넌트에 추가한 것
interface EnhancedComponent {
types: 'strict TypeScript props'
docs: 'structured MDX'
tests: 'unit + a11y + visual'
examples: 'minimal + variations'
}Week 5-6: AI 통합
## CLAUDE.md 핵심 내용
### 컴포넌트 선택
{15개 컴포넌트 가이드 테이블}
### 토큰 사용
{Good/Bad 예시}
### 패턴
{로그인 폼, 대시보드 카드, 데이터 테이블}// MCP 서버
const tools = [
'get_component', // 컴포넌트 문서
'find_pattern', // 패턴 검색
'validate_code', // 코드 검증
'suggest_fix', // 수정 제안
]Week 7-8: 팀 온보딩
## 교육 세션
### Session 1: 기본 (2시간)
- 토큰 시스템 이해
- 컴포넌트 사용법
- AI와 함께 코딩
### Session 2: 실습 (4시간)
- 실제 기능 구현
- 코드 리뷰
- 피드백 반영
## 피드백 수집
- "토큰 찾기 어려움" → 검색 도구 개선
- "예시 부족" → 예시 추가
- "AI가 잘못된 컴포넌트 선택" → CLAUDE.md 보강결과
| 지표 | Before | After | 변화 |
|---|---|---|---|
| 하드코딩된 값 | 216 | 3 | -99% |
| 접근성 위반 | 47 | 2 | -96% |
| AI 생성 코드 성공률 | - | 91% | - |
| 개발 속도 (기능당) | 3일 | 1.5일 | -50% |
| 디자인 리뷰 수정 | 8회 | 2회 | -75% |
교훈 및 권장사항
성공 요인
피해야 할 것
| 안티패턴 | 문제 | 대안 |
|---|---|---|
| 빅뱅 마이그레이션 | 리스크 높음, 롤백 어려움 | 점진적 strangler fig |
| 문서 없이 시작 | AI 성능 저하, 불일관 | 문서 먼저 |
| 검증 미비 | 품질 하락 | CI 필수 |
| 피드백 무시 | 채택률 하락 | 정기 수렴 |
권장 시작점
## Day 1
1. 현황 감사 (토큰, 컴포넌트)
2. 핵심 토큰 10개 정의
3. 버튼 컴포넌트 마이그레이션
## Week 1
1. 코어 컴포넌트 5개 완성
2. 기본 CLAUDE.md 작성
3. 첫 번째 AI 코드 생성 테스트
## Month 1
1. 모든 코어 컴포넌트 완성
2. MCP 서버 구축
3. CI 파이프라인
4. 팀 온보딩 시작사례 4: Google Stitch와 DESIGN.md
Stitch가 흥미로운 이유는 "AI로 화면을 그려준다"는 기능보다,
DESIGN.md를 디자인 에이전트가 읽는 문서 계층으로 제시했다는 점입니다.
Stitch 사례의 핵심
DESIGN.md를AGENTS.md의 디자인 대응물로 제시- plain-text markdown을 사람이 읽는 collaboration layer로 사용
- 그 아래에 structured token representation을 유지해 enforcement와 연결
- prompt, branding asset, 수동 작성 세 경로로
DESIGN.md를 생성/보정
왜 중요한가
| Stitch가 한 일 | 디자인 시스템 관점 의미 |
|---|---|
DESIGN.md라는 이름의 문서 계층 도입 | 시각 규칙을 agent-readable contract로 승격 |
| markdown + structured token 이중 표현 | 협업 문서와 enforcement 계층을 분리 |
| vibe prompt나 URL에서 문서 유도 | 레퍼런스 수집을 구조화된 문서로 환원 |
이 사례가 주는 교훈은 단순합니다. AI 시대의 디자인 시스템은 토큰만 잘 만들면 끝나는 것이 아니라, 에이전트가 읽는 상위 시각 규칙 문서가 있어야 한다는 점입니다.
AI 관점 시사점
- 토큰은 값의 정확성을 보장하지만,
DESIGN.md는 장면의 성격을 보정합니다. - 디자이너는 markdown을 수정하고, 시스템은 tokens를 enforcement하는 이중 구조가 실무적으로 강합니다.
- 브랜드 리프레시가 발생하면 컴포넌트보다 먼저
DESIGN.md가 변하는 경우가 많습니다.
사례 5: awesome-design-md와 레퍼런스 운영화
awesome-design-md는 공개 사이트를 바탕으로 작성한 DESIGN.md 컬렉션입니다.
여기서 중요한 건 특정 브랜드를 베끼는 행위가 아니라,
시각 규칙 샘플을 문서 형태로 수집·비교·추출하는 운영 방식입니다.
무엇이 유용한가
| 포인트 | 실무 활용 |
|---|---|
| 공통 섹션 구조 | Overview, Colors, Typography, Components, Layout, Do/Don't, Responsive를 팀 표준으로 삼기 좋음 |
| 사이트별 스타일 차이 문서화 | layout density, 타이포 tension, shadow/border 철학 비교 가능 |
preview.html 같은 보조 자료 | 문서와 시각 샘플을 함께 검토할 수 있음 |
주의할 점
| 위험 | 이유 | 권장 대응 |
|---|---|---|
| 브랜드 복제 | 레퍼런스를 house style로 오해 | 공통 패턴만 추출하고 자사 vocabulary로 재작성 |
| 토큰 없는 감각 복사 | enforcement 계층이 없어 일관성이 깨짐 | DESIGN.md와 token spec를 함께 운영 |
| “이 사이트처럼 만들어줘” 의존 | 장기적으로 브랜드 정체성이 약화 | 여러 레퍼런스를 distill해 팀 기준 문서 작성 |
AI 관점 시사점
DESIGN.md는 영감 보드가 아니라 비교 가능한 규칙 문서가 될 수 있습니다.- 디자인 시스템 팀은 Figma 파일만 모으는 대신
DESIGN.md샘플 라이브러리를 운영할 수 있습니다. - 좋은 레퍼런스 컬렉션은 최종 답이 아니라, 내 제품의
DESIGN.md를 더 빨리 쓰게 해주는 부트스트랩입니다.
Google: Material 3 Expressive
2025년 5월 Google I/O에서 발표된 Material Design의 새로운 방향으로, 평면 디자인의 한계를 극복하는 표현력 있는 인터페이스를 지향합니다.
M3 Expressive 핵심 변화
- Material 3 Expressive(M3E): 새로운 모션 물리, 색상 체계, 컴포넌트 업데이트, 임팩트 있는 폰트
- Android 16와 함께 출시, Pixel 10 시리즈에서 첫 적용
- Gemini AI를 Android 자동차, TV, 웨어러블, XR까지 확장
- 토큰 시스템이 AI 친화적으로 구조화되어 AI 코드 생성에 직접 활용 가능
M3E 토큰 구조
// Material 3 Expressive 토큰 예시
const m3eTokens = {
color: {
primary: 'md.sys.color.primary',
onPrimary: 'md.sys.color.on-primary',
surface: 'md.sys.color.surface',
// Dynamic Color: 사용자 배경에서 추출
dynamicPrimary: 'md.sys.color.dynamic.primary',
},
motion: {
// M3E 신규: Expressive 모션 커브
expressiveStandard: 'md.sys.motion.easing.expressive',
expressiveFling: 'md.sys.motion.easing.expressive-fling',
duration: {
short: 'md.sys.motion.duration.short3', // 250ms
medium: 'md.sys.motion.duration.medium2', // 400ms
},
},
typography: {
// M3E 신규: 임팩트 있는 디스플레이 폰트
displayLarge: 'md.sys.typescale.display-large',
expressiveHeadline: 'md.sys.typescale.expressive-headline',
},
}AI 관점 시사점
| 항목 | 내용 |
|---|---|
| 토큰 접근성 | md.sys.* 네임스페이스로 체계화 — AI가 토큰 용도를 즉시 파악 가능 |
| 멀티 플랫폼 | 동일 토큰이 Android, Web, iOS에서 공유 — 한 번의 정의로 다중 플랫폼 코드 생성 |
| Dynamic Color | 사용자 맥락 기반 색상 — AI 생성 시 하드코딩 대신 토큰 참조 강제 |
| Gemini 연동 | Google AI 생태계와 직접 통합 — 디자인 의도를 코드로 자동 변환 |
Apple: Liquid Glass + Apple Intelligence
2025년 WWDC에서 발표된 Apple의 가장 큰 디자인 변화로, 2013년 이후 최대 비주얼 개편과 AI 플랫폼 통합을 동시에 진행합니다.
Liquid Glass + Apple Intelligence 핵심
- Liquid Glass: 반투명성, 깊이감, 유동적 반응성을 구현하는 새로운 비주얼 언어
- iOS 26 / iPadOS 26 / macOS 26 / watchOS 26 / tvOS 26 / visionOS 26 전체 적용
- Apple Intelligence: 호기심 기능에서 정식 플랫폼 레이어로 승격
- HIG에 Generative AI 전용 섹션 추가: AI 생성 콘텐츠의 책임 있는 통합 가이드
- 접근성을 구조적(structural) 요소로 격상: VoiceOver, Switch Control, Voice Control이 기본 기대치
HIG Generative AI 가이드라인
## Apple HIG — AI 통합 원칙 (요약)
### 1. 투명성 (Transparency)
- AI가 생성한 콘텐츠임을 사용자에게 명확히 표시
- 생성 과정에서 사용자에게 피드백 제공
### 2. 사용자 통제 (User Control)
- AI 결과물의 편집/거부 항상 가능
- 자동 적용 대신 사용자 확인 단계 필수
### 3. 기대 관리 (Setting Expectations)
- AI 기능의 한계를 솔직하게 전달
- 생성 결과의 품질 수준을 미리 안내
### 4. 접근성 (Accessibility)
- AI 기능이 보조 기술과 완전히 호환
- VoiceOver, Switch Control 등에서 동등한 경험AI 관점 시사점
| 항목 | 내용 |
|---|---|
| 디자인 표준 | Liquid Glass가 새로운 시각 언어의 기준 — 디자인 시스템 토큰에 반투명/깊이 속성 필요 |
| AI 통합 패턴 | HIG의 "책임 있는 AI" 가이드라인이 업계 표준 패턴의 근거 |
| 접근성 기본값 | 접근성이 선택이 아닌 구조적 요소 — AI 코드 생성 시 접근성 자동 포함 강제 |
| 크로스 플랫폼 | 6개 OS 동시 적용 — 디자인 시스템의 멀티 플랫폼 일관성 중요성 재확인 |
Microsoft: Fluent 2 + Copilot 디자인 패턴
Microsoft 365 Copilot 앱에 적용된 차세대 Fluent 디자인으로, 대화(conversation)를 핵심 인터페이스로 전환하는 패러다임 변화를 보여줍니다.
Fluent 2 + Copilot UX 핵심
- 대화 중심 인터페이스: Copilot Chat이 자연스러운 대화 기반 작업 환경으로 전환
- 아코디언 스타일 아키텍처: 접이식 내비게이션 + 깔끔한 미니멀 팔레트
- 동적 윈도잉 모델: 적응형 인터페이스의 기반
- Visual Studio 2026: Modern Fluent Design 전면 UI 개편 (11개 새 테마)
- Copilot 연동 경험은 Fluent 2 컴포넌트, 스페이싱, 타이포그래피, 토큰 사용 필수
Copilot UX 디자인 패턴
// Fluent 2 + Copilot 컴포넌트 구조 예시
const copilotPatterns = {
// 대화 인터페이스 구성
conversationUI: {
inputArea: 'FluentTextarea + ActionBar',
messageList: 'ChatMessage + ContextCards',
suggestions: 'SuggestedActions (최대 3개)',
},
// 에이전트 상태 표시
agentStatus: {
thinking: 'ProgressBar + StatusLabel',
acting: 'ActionCard + StepIndicator',
complete: 'ResultCard + FeedbackButtons',
},
// 컨텍스트 카드: AI 응답에 참조 소스 표시
contextCard: {
source: 'DocumentReference',
preview: 'ContentSnippet',
action: 'OpenInApp | CopyToClipboard',
},
}AI 관점 시사점
| 항목 | 내용 |
|---|---|
| 대화 UI 표준 | Copilot UX 가이던스가 에이전트 시대의 UI 패턴 표준을 제시 |
| 토큰 필수화 | Copilot 연동 시 Fluent 2 토큰 준수 필수 — 생태계 일관성 강제 |
| 적응형 레이아웃 | 동적 윈도잉 모델이 반응형 넘어 적응형 인터페이스의 기반 |
| 개발 도구 통합 | VS 2026의 Fluent 개편은 개발자 경험과 디자인 시스템의 통합을 가속화 |
참고: Microsoft Design
대기업 디자인 시스템 트렌드 종합
| 기업 | 디자인 시스템 | AI 통합 방식 | 핵심 교훈 |
|---|---|---|---|
| Google Stitch | DESIGN.md + structured tokens | markdown visual spec → design generation | 시각 규칙 문서 자체를 인터페이스로 다뤄야 함 |
| awesome-design-md | 레퍼런스 기반 DESIGN.md 컬렉션 | 공개 사이트 스타일 → reusable visual spec | 레퍼런스는 복제가 아니라 distillation 재료여야 함 |
| Material 3 Expressive | 토큰 JSON → Gemini 코드 생성 | 체계화된 토큰이 AI 활용의 전제조건 | |
| Apple | Liquid Glass + HIG AI | HIG 가이드라인 → 책임 있는 AI 패턴 | AI 생성 콘텐츠의 투명성/통제가 필수 |
| Microsoft | Fluent 2 + Copilot UX | 대화 UI 패턴 → 에이전트 인터페이스 | 대화형 AI가 핵심 인터랙션 모델로 전환 |