{3줄 요약}

Design System은 팀이 같은 언어로 제품을 만들게 해주는 공유 구조로, 같은 요소를 매번 처음부터 정하지 않아도 되게 해줘요.
처음부터 완벽한 시스템을 노리기보다 지금 반복되는 패턴부터 시작하는 게 현실적이에요.
가치는 완성 시점이 아니라 컴포넌트 하나를 공유하기 시작하는 순간부터 드러나요.

이 방법을 쓰는 맥락

Design System은 이런 신호가 보일 때 필요해요:

  • 같은 버튼이 화면마다 다르게 생겼어요
  • 새 화면을 만들 때 이전 화면에서 컴포넌트를 복사해서 써요
  • 개발자가 "이 버튼 색이 디자인이랑 왜 다른가요?"를 자주 물어봐요
  • 서비스가 여러 팀에서 동시에 개발되고 있어요

작은 팀이라도 화면이 10개 이상이면 Design System의 이점이 나타나기 시작해요.

단계별 실행 방법

1단계 — 지금 있는 것을 먼저 파악하기 (UI Audit)

새로 만들기 전에 지금 있는 것을 먼저 봐요. 현재 서비스의 모든 화면에서 사용되는 요소들을 수집해요.

  • 버튼: 몇 가지 종류가 있는가? 크기, 색, 형태가 일관한가?
  • 색상: 실제로 쓰이는 색이 몇 개인가? 역할이 정의됐는가?
  • 타이포그래피: 텍스트 스타일이 몇 가지인가?
  • 간격: 패딩과 마진이 일관한 규칙을 따르는가?

이 작업에서 "우리가 얼마나 불일치했는지"가 보여요.
그리고 가장 많이 쓰이는 것이 무엇인지도요.
많이 쓰이는 것부터 먼저 시스템화해요.

토스의 Toss UI, 카카오의 Cocoa Design System도 처음부터 완성된 시스템이 아니었어요.
반복되는 패턴부터 정리하면서 점점 확장했어요.

2단계 — 기초(Foundation) 먼저 정의하기

컴포넌트를 만들기 전에 기초를 정해요. 기초가 없으면 컴포넌트마다 다른 색과 간격이 생겨요.

색상 시스템: 역할(Role) 기반으로 정의해요. Primary, Secondary, Error, Warning, Surface, On-Surface 등. 구체적인 hex 값보다 역할 이름으로 관리해요. → Color System 설계 참고.

타이포그래피 스케일: Display, Title, Body, Label, Caption 같은 계층을 크기와 굵기로 정의해요. 각 계층이 언제 쓰이는지 명확한 가이드와 함께요.

간격 규칙: 4px 또는 8px 기반 시스템을 써요. 4, 8, 12, 16, 24, 32, 48, 64... 이 배수만 사용하면 화면 전체의 간격이 자연스럽게 일치해요.

모서리 반경(Border Radius): Small(4px), Medium(8px), Large(16px), Full(pill)처럼 토큰으로 정의해요.

3단계 — 원자 컴포넌트부터 만들기

Brad Frost의 Atomic Design 원칙이에요. 작은 단위(원자)부터 만들고, 조합해서 더 큰 단위(분자, 유기체)를 만들어요.

원자(Atoms): Button, Input, Checkbox, Radio, Badge, Icon. 더 이상 쪼갤 수 없는 가장 작은 단위예요.

분자(Molecules): Form Field (Label + Input + Error Message), Card (이미지 + 텍스트 + 버튼). 원자들의 조합이에요.

유기체(Organisms): Navigation Bar, Header, Form. 분자들의 조합이에요.

컴포넌트를 만들 때 각각의 상태(State)를 모두 정의해야 해요.

  • Default: 기본 상태
  • Hover: 마우스를 올렸을 때
  • Active/Pressed: 클릭 중
  • Focus: 키보드로 포커스됐을 때
  • Disabled: 비활성 상태
  • Error: 오류 상태
  • Loading: 처리 중 상태

이 상태들을 Figma에서 Component Property나 Variant로 정의해요.

4단계 — 토큰(Design Token) 시스템 만들기

Design Token은 색상, 간격, 타이포그래피 값에 의미 있는 이름을 붙이는 거예요.

// 하드코딩 대신
background-color: #1A73E8;

// 토큰 사용
background-color: var(--color-primary);

토큰의 장점: 브랜드 색이 바뀌면 --color-primary 값 하나만 바꾸면 전체가 바뀌어요.
다크 모드도 토큰 값만 교체하면 돼요.

Figma의 Variables 기능, Style Dictionary 같은 도구로 토큰을 코드와 디자인 도구에서 함께 관리할 수 있어요.

5단계 — 문서화하기

컴포넌트를 만들었어도 어떻게 쓰는지 문서가 없으면, 팀원들이 올바르게 쓰지 않아요.

각 컴포넌트 문서에는:

  • 이 컴포넌트가 무엇인지 (목적)
  • 언제 써야 하는지 (적합한 상황)
  • 언제 쓰면 안 되는지 (부적합한 상황)
  • 각 Variant가 무엇을 의미하는지
  • 접근성 주의사항

Storybook, Zeroheight 같은 도구가 컴포넌트 문서화에 자주 쓰여요.

하지 말아야 할 것

처음부터 완벽한 시스템을 목표로 하지 마세요: "완성되면 공유하겠다"고 하면 영원히 공유를 못 해요.
버튼 하나를 만들었으면 바로 공유해요.

컴포넌트를 미리 너무 많이 만들지 마세요: 실제로 쓰이지 않는 컴포넌트는 유지 비용만 발생해요.
쓰이는 것이 생기면 그때 만들어요.

개발자 없이 만들지 마세요: 디자이너만 만든 Design System은 구현 가능성과 괴리가 생길 수 있어요.
개발자가 함께 참여해야 코드로 실제로 구현되는 시스템이 나와요.

실행 후 확인하기

  • Foundation(색상, 타이포, 간격)이 토큰으로 정의됐나요?
  • 각 컴포넌트의 모든 상태(State)가 정의됐나요?
  • 컴포넌트 사용 가이드 문서가 있나요?
  • 개발자가 같은 컴포넌트를 코드로 구현할 수 있는 명세가 있나요?
  • 팀 전체가 이 시스템을 실제로 쓰고 있나요?

관련 아티클

참고 문헌

  • Alla Kholmatova, 《Design Systems》(2017) - Design System의 구성 요소와 구축 방법론을 실무 관점으로 설명해요.
  • Brad Frost, 《Atomic Design》(2016) - 원자 → 분자 → 유기체 → 템플릿 → 페이지의 계층적 컴포넌트 구조를 다뤄요.