본문으로 바로가기
리옵트 핸드북
리옵트 핸드북
AI 시대의 디자인 시스템

기반 설계

토큰 아키텍처컴포넌트 명세접근성 내장

AI 워크플로우

프롬프트 인터페이스DESIGN.md 인터페이스에이전틱 디자인 품질 제어워크플로우 전략AI 기반 DS 진화컨텍스트 주입

사용자 경험

일관성 패턴인터랙션 설계폼 & 데이터 입력

차세대 인터페이스

에이전트 UI 프로토콜생성형 UI공간·멀티모달 인터페이스

실전

실행 플레이북마이그레이션 전략거버넌스 & 협업사례 연구

운영

검증 체크리스트업데이트 로그
핸드북›AI 시대의 디자인 시스템›거버넌스 & 협업
한국어English

거버넌스 & 협업

RACI·RFC 변경 관리, 6종 품질 게이트, Golden Prompt Suite 회귀 테스트, Figma-GitHub 연동까지 디자인 시스템 거버넌스와 디자이너-개발자 협업 설계.

핵심 요약

  • 역할(DS Lead·Engineer·Designer·Contributor·Consumer)과 RACI 매트릭스로 토큰·컴포넌트·브레이킹 체인지의 권한을 명확히 합니다.
  • Major 변경은 RFC 템플릿으로, PR은 type/lint/test/a11y/visual/bundle 검증을 거쳐 머지합니다.
  • 품질 게이트는 타입·린트·커버리지(80%)·접근성(WCAG AA, 위반 0)·시각 회귀·번들 크기·문서의 6종 기준으로 운영합니다.
  • AI 생성물은 Golden Prompt Suite로 회귀 테스트하되, CI 비용과 변동성 탓에 LLM 출력을 record→replay+검증하는 전략을 기본으로 둡니다.
  • Figma Dev Mode→GitHub 토큰 자동 동기화와 디자인 QA 체크리스트로 디자이너-개발자 워크플로우를 연결합니다.

디자인 시스템이 오래 살아남는지는 거버넌스에 달려 있습니다. 소유권과 변경 프로세스, 품질 기준이 명확하지 않으면 시스템은 시간이 갈수록 일관성을 잃습니다.

거버넌스 구조

팀 구조

역할 정의

역할책임권한
DS Lead전략, 로드맵, 의사결정모든 변경 승인
DS Engineer코어 개발, 리뷰컴포넌트 머지
DS Designer비주얼, 토큰, UX디자인 변경 승인
Contributor기능 기여, 버그 수정PR 생성
Consumer시스템 사용이슈 생성

RACI 매트릭스

| 활동            | DS Lead | DS Engineer | DS Designer | Contributor |
| --------------- | ------- | ----------- | ----------- | ----------- |
| 토큰 변경       | A       | C           | R           | I           |
| 컴포넌트 추가   | A       | R           | C           | C           |
| 문서 업데이트   | I       | R           | C           | R           |
| 브레이킹 체인지 | R/A     | C           | C           | I           |
| 버그 수정       | I       | A           | I           | R           |

R: Responsible (수행)
A: Accountable (책임)
C: Consulted (자문)
I: Informed (통보)

변경 관리

변경 유형

변경 요청 프로세스

RFC 템플릿 (Major 변경용)

# RFC: [변경 제목]

## 요약

한 문단으로 변경 내용 설명

## 동기

왜 이 변경이 필요한가?

## 상세 설계

### 현재 상태

현재 어떻게 작동하는가?

### 제안 변경

어떻게 변경할 것인가?

### 마이그레이션 경로

기존 사용자는 어떻게 마이그레이션하는가?

## 대안

고려한 다른 방법들

## 영향

### Breaking Changes

- [ ] Props 변경
- [ ] API 변경
- [ ] 스타일 변경

### 영향받는 컴포넌트

- Component A
- Component B

## 체크리스트

- [ ] 타입 정의 업데이트
- [ ] 문서 업데이트
- [ ] 마이그레이션 가이드
- [ ] Changelog 업데이트

품질 게이트

자동화된 체크

품질 기준

// quality-gates.config.ts

export const qualityGates = {
  // 타입 검사
  typeCheck: {
    required: true,
    strict: true,
  },

  // 린트
  lint: {
    required: true,
    rules: {
      'design-system/no-hardcoded-values': 'error',
      'design-system/component-docs': 'error',
      'design-system/prop-types': 'error',
    },
  },

  // 테스트 커버리지
  coverage: {
    required: true,
    thresholds: {
      statements: 80,
      branches: 75,
      functions: 80,
      lines: 80,
    },
  },

  // 접근성
  accessibility: {
    required: true,
    level: 'AA', // WCAG 2.1 AA
    allowedViolations: 0,
  },

  // 시각적 회귀
  visualRegression: {
    required: true,
    threshold: 0.1, // 0.1% 미만 차이 허용
    requireApproval: true, // 차이 있으면 수동 승인
  },

  // 번들 크기
  bundleSize: {
    required: true,
    maxIncrease: '5kb', // 단일 PR당 최대 증가
    absoluteMax: '50kb', // 컴포넌트당 절대 최대
  },

  // 문서
  documentation: {
    required: true,
    requiredSections: ['summary', 'props', 'examples', 'accessibility'],
  },
}

AI 생성물 평가 (Golden Prompt Suite)

디자인 시스템을 “AI가 잘 쓰는지”를 감으로만 챙기면 금방 무너집니다. LLM을 컴파일러처럼 보고 **대표 프롬프트 세트(golden prompts)**로 꾸준히 회귀 테스트하는 게 현실적인 해법입니다.

방법은 두 가지로 나뉩니다.

  • 케이스를 데이터로 관리: “어떤 UI를 만들게 할지”를 시나리오로 고정
  • 검증을 코드로 관리: “무엇이 통과 조건인지”를 룰로 고정 (토큰/컴포넌트/접근성/일관성)

케이스 포맷 (예시)

# ai-evals/cases/user-invite-form.yml
id: user-invite-form
intent: '관리자 페이지에서 사용자 초대 폼을 만든다'
prompt: |
  사용자 초대 폼을 만들어줘.
  - 이메일 필수
  - 역할 선택(단일)
  - 초대 버튼은 제출 로딩 상태 지원
constraints:
  mustUseComponents:
    - FormField
    - Input
    - Select
    - Button
  forbidden:
    - 'style={{'
    - 'text-red-500' # 토큰 우회
assertions:
  - type: no-hardcoded-colors
  - type: no-arbitrary-spacing
  - type: a11y-no-violations
  - type: only-allowed-components

Record/Replay 전략

CI에서 매번 LLM을 호출하면 비용과 변동성 탓에 신뢰도가 떨어집니다. 대신 “기록(record) → 재생(replay) + 검증”을 기본으로 둡니다.

  • record: (수동 또는 nightly) LLM 출력(코드/스크린샷)을 fixtures/로 저장
  • replay: PR마다 fixtures를 검증 (린트, 타입, a11y, 시각적 회귀, 일관성 룰)
ai-evals/
├── cases/          # 입력 시나리오 (YAML)
├── fixtures/       # 기록된 출력 (code, screenshots)
├── assertions/     # 검증 로직 (TS)
└── runner.ts       # 실행기 (record/replay)

품질 스코어(선택)

Pass/Fail만으로는 미묘한 퇴행을 놓치기 쉽습니다. “위반 개수와 중요도”를 점수로 함께 기록해 두면 추세까지 볼 수 있습니다.

  • 예: 100 - (a11y_violation*20 + hardcoded*10 + layout*5 + warnings*1)

PR 체크 워크플로우

# .github/workflows/pr-check.yml

name: PR Quality Check

on:
  pull_request:
    paths:
      - 'packages/ui/**'

jobs:
  quality-gate:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Setup
        uses: ./.github/actions/setup

      - name: Type Check
        run: yarn tsc --noEmit

      - name: Lint
        run: yarn lint

      - name: Test
        run: yarn test --coverage

      - name: Check Coverage
        uses: codecov/codecov-action@v4
        with:
          fail_ci_if_error: true

      - name: A11y Audit
        run: yarn test:a11y

      - name: Visual Regression
        run: yarn test:visual
        env:
          CHROMATIC_PROJECT_TOKEN: ${{ secrets.CHROMATIC_TOKEN }}

      - name: Bundle Size
        uses: preactjs/compressed-size-action@v2
        with:
          repo-token: ${{ secrets.GITHUB_TOKEN }}

      - name: Documentation Check
        run: yarn docs:check

버저닝 전략

Semantic Versioning

MAJOR.MINOR.PATCH

MAJOR: Breaking changes
MINOR: 새 기능 (하위 호환)
PATCH: 버그 수정

Changelog 자동화

// scripts/generate-changelog.ts

import { getCommitsSinceLastTag, parseConventionalCommit } from './git'

const commitTypes = {
  feat: '✨ Features',
  fix: '🐛 Bug Fixes',
  docs: '📚 Documentation',
  style: '💅 Styles',
  refactor: '♻️ Refactoring',
  perf: '⚡ Performance',
  test: '✅ Tests',
  chore: '🔧 Chores',
  breaking: '💥 Breaking Changes',
}

async function generateChangelog(): Promise<string> {
  const commits = await getCommitsSinceLastTag()
  const parsed = commits.map(parseConventionalCommit)

  const grouped = groupBy(parsed, 'type')

  let changelog = `# Changelog\n\n`

  for (const [type, commits] of Object.entries(grouped)) {
    const title = commitTypes[type as keyof typeof commitTypes]
    changelog += `## ${title}\n\n`

    for (const commit of commits) {
      changelog += `- ${commit.description}`
      if (commit.scope) {
        changelog += ` (${commit.scope})`
      }
      changelog += ` ([${commit.hash.slice(0, 7)}](...))\n`
    }

    changelog += '\n'
  }

  return changelog
}

디자이너-개발자 워크플로우

Figma-GitHub 연동

# .github/workflows/figma-sync.yml

name: Figma Sync

on:
  repository_dispatch:
    types: [figma-update]

jobs:
  sync:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Fetch Figma Tokens
        run: |
          npx figma-tokens-sync \
            --token ${{ secrets.FIGMA_TOKEN }} \
            --file ${{ github.event.client_payload.file_key }} \
            --output ./tokens/

      - name: Create PR
        uses: peter-evans/create-pull-request@v6
        with:
          title: 'sync: Update design tokens from Figma'
          body: |
            자동 동기화된 토큰 변경사항입니다.

            Figma File: ${{ github.event.client_payload.file_url }}

디자인 QA 체크리스트

## 디자인 QA 체크리스트

### 시각적 일치

- [ ] 색상이 Figma와 일치
- [ ] 간격이 8px 그리드 준수
- [ ] 타이포그래피 일치
- [ ] 아이콘 크기/정렬

### 인터랙션

- [ ] Hover 상태
- [ ] Focus 상태
- [ ] Active 상태
- [ ] Disabled 상태
- [ ] Loading 상태

### 반응형

- [ ] 모바일 (< 640px)
- [ ] 태블릿 (640px ~ 1024px)
- [ ] 데스크톱 (> 1024px)

### 접근성

- [ ] 색상 대비
- [ ] 포커스 표시자
- [ ] 키보드 내비게이션

커뮤니케이션

채널 정의

채널용도응답 기대
GitHub Issues버그, 기능 요청1-2 영업일
Slack #design-system빠른 질문, 논의당일
RFC PR주요 변경 제안1주일
Office Hours심층 논의, 페어링주 1회

정기 미팅

## Design System Sync (주간)

- 일시: 매주 목요일 14:00
- 참석: DS Team, 관심 있는 Contributor
- 어젠다:
  - 지난주 변경사항 리뷰
  - 이번주 계획
  - Open PR/Issue 논의
  - Q&A

## Design-Dev Sync (격주)

- 일시: 격주 화요일 15:00
- 참석: DS Team, Product Designer, Tech Lead
- 어젠다:
  - 디자인 시스템 로드맵 동기화
  - 새 컴포넌트 니즈 논의
  - 피드백 공유

체크리스트

참고 자료

  • Design System Governance
  • Conventional Commits
  • Chromatic for Visual Testing
  • Figma Dev Mode

관련 문서

워크플로우 전략

Design→Code, Code→Design, 양방향 동기화 - 세 가지 AI 워크플로우 비교

실행 플레이북

토큰(1주) → 컴포넌트 명세·접근성(2주) → AI 문서(3주) → 품질 게이트·변경 관리(4주)로 AI-First 디자인 시스템을 4주 만에 운영 가능 상태로 만드는 최소 경로.

디자인 워크플로우

Codex 명령어 마스터 · /plugins·/skills·/mcp·/ide를 Figma, ImageGen, Playwright와 연결해 UI를 설계·구현·검증하는 공식 Codex 디자인 흐름

MCP 명령/연동 가이드

Codex 명령어 마스터 · /mcp·/apps·/plugins·/permissions로 Codex의 MCP 서버·도구를 안전하게 운영하는 방법. 읽기 전용 도입과 승인 정책 동시 설계를 원칙으로 합니다.

마이그레이션 전략

토큰 정규화·타입 강화(Phase 1), CLAUDE.md·MCP·검증 파이프라인(Phase 2), 팀 온보딩(Phase 3)과 Strangler Fig 패턴으로 기존 DS를 AI-Ready로 점진 전환하는 로드맵.

사례 연구

shadcn, Radix, Stitch, Material 3 등 실제 AI-First 디자인 시스템 적용 사례

On this page

거버넌스 구조팀 구조역할 정의RACI 매트릭스변경 관리변경 유형변경 요청 프로세스RFC 템플릿 (Major 변경용)품질 게이트자동화된 체크품질 기준AI 생성물 평가 (Golden Prompt Suite)케이스 포맷 (예시)Record/Replay 전략품질 스코어(선택)PR 체크 워크플로우버저닝 전략Semantic VersioningChangelog 자동화디자이너-개발자 워크플로우Figma-GitHub 연동디자인 QA 체크리스트커뮤니케이션채널 정의정기 미팅체크리스트팀 구조변경 관리품질 게이트버저닝협업참고 자료