디자인 시스템: 구성, 도입, 구축과 배포

디자인 시스템이란

디자인 시스템(design system)은 팀이 제품의 목적에 맞는 디자인을 일관되게 적용하도록 정한 규칙의 묶음이다. 버튼 모음(UI 키트)에 그치지 않고, 원칙·스타일·컴포넌트·문서와 그것을 바꾸는 절차까지 포함한다.

"바퀴를 다시 발명하지 말라"는 말처럼, 잘 만든 바퀴 하나를 언제든 가져다 쓰게 해 두고 진짜 문제(사용자 경험)에 시간을 쓰게 하는 것이 목적이다.

없으면 생기는 일

시스템이 주는 효과는 작업 시간 단축, 제품 전반의 일관성, 커뮤니케이션 비용 감소다. 컴포넌트 이름만으로 소통이 끝나고, 1px 단위 디자인 QA가 줄고, 기능까지 담은 공통 컴포넌트라 버그와 기능 QA도 줄어든다. 새 구성원의 온보딩도 빨라진다. 피그마를 다룰 줄 아는 기획자·개발자가 기존 컴포넌트를 조합해 간단한 화면을 직접 만들 수도 있다.

구성 요소

공개된 디자인 시스템(Google Material Design 3, Microsoft Fluent 2, IBM Carbon, Atlassian, Adobe Spectrum 등)은 구조와 문서화 방식을 참고하기 좋다.

언제 도입하나

디자인 시스템은 초기 비용이 큰 투자다. 다음을 함께 본다.

• 조직 규모와 의지: 사람이 늘수록 비일관성이 생산성을 갉아먹는다. 구성원이 규칙을 지킬 의지가 없으면 만들어도 쓰이지 않는다.
• 로드맵과 역량: 대규모 개편, 새 시장·채널 확장이 예정돼 있는지, 만들고 유지할 기술 역량이 있는지.
• 도입 시점: 전면 리디자인이나 프론트엔드 프레임워크 전환처럼 모든 화면을 다시 만드는 때가 최적기다. 레거시를 덜 남기고 처음부터 시스템 위에 쌓을 수 있다.
• 작은 팀도 필요하다: 디자이너가 한 명이어도 ① 반년 뒤의 나는 오늘 세운 규칙을 기억하지 못하고, ② 디자이너 혼자서는 개발된 컴포넌트의 구조까지 맞출 수 없고, ③ 개발자는 여러 명일 수 있다. 혼자 세운 규칙보다 합의되고 기록된 규칙이 오래간다.
• 처음부터 다 만들기보다 검증된 오픈 소스 라이브러리를 바탕으로 키우는 편이 현실적이다.

모양이 같아도 같은 컴포넌트가 아니다

디자이너와 개발자가 각자 "재사용 가능한 모달"을 만들어 겉모양이 똑같아도, 개발 쪽에서 왼쪽 회색 버튼을 '닫기 전용'으로 고정했다면 "왼쪽 버튼으로 알림 끄기" 같은 다음 요청에 쓸 수 없다. 컴포넌트를 고치면 기존 화면이 모두 영향을 받고, 피하려면 비슷한 모달을 또 만들게 된다. 그래서 컴포넌트는 모양과 함께 어떤 슬롯과 동작을 바꿀 수 있는지(props)를 디자이너와 개발자가 함께 정해야 한다.

구축·개편 절차

flowchart TB
  S1["1. 감사(inventory)<br/>지금 쓰는 스타일·컴포넌트를 전부 모으고, 쓰는 것과 안 쓰는 것을 가른다"]
  S2["2. 목표 범위<br/>예: 파운데이션과 공통 UI의 디자인 파일 ↔ Storybook 일치율 100%"]
  S3["3. 기준 합의<br/>디자인 방향성 · 확장성 · 접근성 · 지속 관리 방식을 디자이너끼리 먼저 정한다"]
  S4["4. 정리·재정의<br/>파운데이션 → 컴포넌트 순으로 줄이고 이름을 붙인다 (조금씩 나눠 합의)"]
  S5["5. 개발 합의<br/>구조와 props, 무엇을 시스템에 넣고 무엇을 화면별로 둘지 정한다"]
  S6["6. 구현·QA<br/>실제 서비스에 적용해 화면을 돌며 깨진 곳을 찾는다"]
  S7["7. 릴리스·개선<br/>사용자가 이질감을 느끼지 않게 기존 인상은 유지하고, 버전을 올리며 계속 다듬는다"]
  S1 --> S2 --> S3 --> S4 --> S5 --> S6 --> S7

인터페이스 인벤토리: 1단계를 설득 도구로

1단계 감사는 인터페이스 인벤토리(interface inventory) 로 한다. 콘텐츠 인벤토리처럼, 지금 화면에 있는 고유한 UI 패턴을 전부 스크린숏으로 모아 범주별로 묶는 작업이다. 같은 패턴은 한 번만 찍는다. 한 페이지에 모양이 다른 버튼이 십여 개 모인 슬라이드는 말보다 강하게 시스템의 필요를 보여 준다.

시각 방향을 싸게 정하는 법

3단계 기준 합의 중 디자인 방향성은 완성 시안(comp)부터 그리지 않고 정한다. 완성 시안부터 그리면 시간이 많이 들고, 한 번 그린 레이아웃에 의견이 묶인다. 그 전에 가벼운 산출물로 미감을 합의한다.

이 단계 뒤에야 브라우저 안에서 컴포넌트를 반복해 다듬는다. 디자인이 끝나고 개발이 시작되는 폭포수가 아니라, 개발도 디자인 과정의 일부로 함께 돈다.

흔한 문제와 처방

규칙 예시

• 타이포그래피: 가장 많이 보이는 화면에서 실제로 많이 쓰는 크기를 추리고, 단계 사이를 2px 이상 벌려 구분되게 한다. 굵기는 역할에 묶는다. Display·Heading은 Bold, Body·Caption은 Regular처럼 두세 가지로 줄인다.
• 버튼: 모서리·높이 같은 형태를 먼저 통일한다. 이름은 색(default, yellow)이 아니라 형태와 강조 수준으로 짓는다. Contained(주요 실행), Outlined(보조 액션, 두 버튼 중 낮은 우선순위), Text(옵션처럼 가장 낮은 우선순위).
• 아이콘: 선 굵기·모서리·격자를 맞춰 전부 다시 다듬고, 키워드-모양-색 같은 규칙으로 이름을 지어 디자인 파일과 코드에서 같은 이름으로 찾게 한다.
• 드물게 쓰는 컴포넌트(예: 플로팅 버튼)는 시스템에 넣지 않고 화면별로 대응할 수 있다. 시스템에는 자주, 여러 곳에서 쓰는 것부터 넣는다.

컴포넌트 이름과 속성 축

흩어진 컴포넌트를 통합할 때는 무엇이 다르면 다른 컴포넌트이고, 무엇이 다르면 옵션인가부터 정한다.

버튼이라면 대개 세 축의 조합으로 정리된다.

축마다 값을 적게 제한해야 「같은 목소리」를 낸다. 축이 정해지면 각 prop을 클래스나 스타일 변형으로 바꾸는 구현은 단순하다. 기존 버튼 사용법과 크게 다르지 않게 만들어야 이전(migration)이 쉽다. 크기는 높이를 고정하고 너비는 기기 폭에 맞춰 늘어나게 둔다.

이름 규칙:

• 용도보다 형태를 기준으로 짓고, 컴포넌트 종류(Button)를 이름 끝에 둔다.
• BTN 같은 약어를 쓰지 않는다. 짧되 필요한 정보는 다 담는다.
• 팀마다 다르게 부르던 이름을 먼저 모두 모아 하나로 정한다. 같은 대상을 다르게 부르는 것이 소통 비용의 가장 큰 원인이다.
• 눌림(pressed) 같은 상태도 컴포넌트 정의에 넣어, 화면마다 따로 확인하지 않게 한다.

다크 모드에서 기본 색이 1:1로 대응하지 않으면 컴포넌트 전용 색 토큰을 두기도 한다. 당장은 편하지만 컴포넌트 수만큼 토큰이 불어나므로, 결국 의미 토큰 체계로 모아야 한다. 컴포넌트의 주 사용자는 디자이너이므로 디자이너가 설계를 주도하고 개발자가 리뷰하는 방식이 체계를 오래 유지하기 쉽다. 디자이너가 개발 환경을 갖추고 컴포넌트 골격 코드를 직접 쓰는 팀도 있다.

코드로 배포하기

여러 프로젝트가 같은 버튼·색·간격을 쓰게 하려면 각 저장소에 스타일을 복사하지 말고 한 곳에서 만들어 패키지로 배포한다.

디자인 토큰

색상, 간격, 모서리, 폰트 크기, 브레이크포인트처럼 디자인 결정을 값으로 정의한 것이 디자인 토큰이다. 값을 Sass·CSS 파일에 두지 않고 플랫폼 중립 형식(JSON)에 한 번만 적어, 웹·iOS·안드로이드가 같은 원천에서 각자의 변수를 생성한다. Salesforce Lightning 디자인 시스템이 처음 이름 붙여 퍼뜨렸다.

{
  "color": {
    "primary": { "$type": "color", "$value": "#5B5CFF" },
    "action": { "$value": "{color.primary}" }
  },
  "spacing": {
    "md": { "$type": "dimension", "$value": { "value": 16, "unit": "px" } }
  }
}

토큰 파일 형식은 W3C 디자인 토큰 커뮤니티 그룹(DTCG)의 Design Tokens Format Module이 표준이고, 2025년 10월 첫 안정판이 나왔다. $value가 있는 객체가 토큰이고, {color.primary}처럼 다른 토큰을 참조(alias)한다. 토큰 JSON에서 CSS 변수, TypeScript 상수, 테마 객체를 자동 생성하고(예: Style Dictionary), Figma 변수와도 주고받는다. 토큰을 「결정의 인코딩」으로 보는 관점과 섣부른 시맨틱 토큰의 함정은 제품 언어로서의 디자인 시스템에 있다.

컴포넌트

<Button variant="contained" size="md" loading={isSubmitting} disabled={isSubmitting}>
  저장
</Button>

바닥부터 만들기보다 shadcn/ui 같은 접근성이 검증된 컴포넌트를 가져와 토큰과 디자인을 입히는 편이 빠르다. 모바일 대응도 컴포넌트 안에 넣어 두면 화면마다 모바일 시안을 따로 그릴 일이 줄어든다.

중앙 저장소(모노레포)와 문서

design-system/
├─ packages/
│  ├─ tokens/      # 색상, spacing, typography, radius
│  ├─ icons/       # 공통 아이콘
│  ├─ ui/          # Button, Input, Modal, Table 등
│  └─ theme/       # 테마, CSS 변수, 다크 모드
├─ apps/
│  └─ storybook/   # 컴포넌트 문서
└─ package.json

// 각 프로젝트: npm install @my-org/ui @my-org/tokens
import "@my-org/tokens/css"
import { Button, TextField, Modal } from "@my-org/ui"

Storybook으로 컴포넌트마다 사용 예와 props를 보여 주면 디자이너·기획자도 실제 컴포넌트를 확인할 수 있다. 디자인 파일과 Storybook이 어긋나는 순간 시스템은 신뢰를 잃는다. 개편의 출발점이 대개 이 불일치다.

AI 코딩 도구가 읽는 팀 규칙 파일(SKILL.md)도 같은 구조로 중앙에서 배포할 수 있다(Claude 스킬 만들기 가이드).

정리

• 디자인 시스템은 UI 키트가 아니라 원칙·파운데이션·컴포넌트·문서와 변경 절차를 아우르는 팀의 약속이다.
• 작은 팀에도 필요하다. 합의되고 기록된 규칙이 사람과 시간의 차이를 메운다.
• 전면 개편·프레임워크 전환 때 도입하고, 감사 → 기준 합의 → 정리 → 개발 합의 → QA 순으로 만든다.
• 이름은 색이 아니라 역할·형태로 짓고, 컴포넌트는 모양과 바꿀 수 있는 동작을 함께 정의한다.
• 토큰 → 컴포넌트 → Storybook을 중앙에서 관리해 패키지로 배포하고, 한 번 만들고 끝이 아니라 버전을 올리며 계속 다듬는다.

관련 노트: Storybook, 디자인 도구와 개발자 핸드오프, Atomic Design과 컴포넌트 폴더 구조, CSS 커스텀 속성으로 색상 체계 짜기, Animated Icon: 영상을 투명 배경 아이콘으로 쓰기, Claude 스킬 만들기 가이드, UX 라이팅: 원칙, 가이드라인, 체크리스트, 디자인 단계의 접근성, 제품 언어로서의 디자인 시스템: 토큰, 기능과 형태, 컴포넌트 API, 개발자를 위한 시각 디자인 요령