왜 지금 디자인 시스템인가
많은 조직이 서비스 규모가 커지면서 비슷한 문제를 겪습니다. 화면마다 버튼 색이 조금씩 다르고, 같은 기능인데 모달 디자인이 페이지별로 제각각입니다. 개발팀은 비슷한 컴포넌트를 여러 번 만들고, 디자이너는 매번 같은 스펙을 다시 설명합니다. 이 비효율의 근원은 단 하나입니다. 공유된 단일 기준이 없다는 것.
디자인 시스템은 이 문제를 구조적으로 해결하는 수단입니다. 단순히 Figma 라이브러리나 UI 컴포넌트 모음이 아니라, 디자인 의사결정의 원칙·도구·프로세스를 하나의 체계로 묶은 것입니다. 잘 구축된 디자인 시스템은 신규 화면 개발 속도를 높이고, 브랜드 일관성을 유지하며, 팀 간 커뮤니케이션 비용을 줄입니다.
이 글은 디자인 시스템을 처음 구축하거나 기존 시스템을 정비하려는 담당자를 위해, 기술적 설계 결정 사항과 운영·거버넌스 실무를 함께 정리합니다.
1부: 기술 아키텍처 — 어떻게 설계할 것인가
1-1. 디자인 토큰: 시스템의 뼈대
디자인 시스템 구축의 첫 번째 기술적 결정은 디자인 토큰(Design Token) 체계를 어떻게 정의하느냐입니다.
디자인 토큰은 색상, 타이포그래피, 간격(spacing), 그림자(shadow), 모서리 반경(border-radius) 등 시각적 속성을 이름이 붙은 변수로 추상화한 것입니다. 예를 들어 #0057FF라는 색상값을 직접 쓰는 대신 color.primary.500이라는 토큰 이름으로 참조합니다.
토큰의 계층 구조는 일반적으로 세 단계로 설계합니다.
계층 | 설명 | 예시 |
|---|---|---|
Global Token | 원시값(Raw value) 정의 |
|
Alias Token | 의미 기반 참조 |
|
Component Token | 컴포넌트별 매핑 |
|
이 3단계 구조를 갖추면 브랜드 색상을 바꿀 때 Global Token 하나만 수정해도 전체 시스템에 반영됩니다. 다크 모드 지원도 Alias Token 레벨에서 테마를 교체하는 방식으로 깔끔하게 처리할 수 있습니다.
실무 팁: 토큰 파일은 JSON 또는 YAML로 관리하고, [Style Dictionary](https://amzn.github.io/style-dictionary/)와 같은 도구를 사용해 CSS 변수, iOS Swift 상수, Android XML 등 플랫폼별 코드로 자동 변환하는 파이프라인을 구성하면 디자인-코드 불일치를 구조적으로 방지할 수 있습니다.
1-2. 컴포넌트 분류 체계
컴포넌트를 어떻게 분류하고 명명할 것인지는 시스템의 확장성과 직결됩니다. 가장 널리 알려진 프레임워크는 Brad Frost의 Atomic Design입니다.
Atoms: 더 이상 쪼갤 수 없는 최소 단위. 버튼, 입력 필드, 아이콘, 레이블.
Molecules: Atom의 조합. 검색 입력 필드 + 버튼 = 검색 바.
Organisms: 독립적인 UI 섹션. 헤더, 카드 리스트, 폼 블록.
Templates: 페이지 레이아웃 뼈대.
Pages: 실제 콘텐츠가 채워진 최종 화면.
다만 5단계 전체를 엄격하게 적용하면 팀 규모가 작을 때 오히려 오버헤드가 생깁니다. Atom·Molecule·Organism 3단계만 유지하거나, 서비스 도메인에 맞는 독자적 분류(예: Primitive / Pattern / Layout)를 사용하는 것도 충분히 유효한 선택입니다.
중요한 것은 분류 체계보다 일관된 명명 규칙입니다. 컴포넌트 이름은 기능을 기술하되 특정 페이지에 종속되지 않도록 합니다. MainPageCard가 아닌 ProductCard, LoginButton이 아닌 PrimaryButton처럼 재사용 가능한 이름을 사용하세요.
1-3. Figma 라이브러리 구조화
Figma는 현재 디자인 시스템의 사실상 표준 도구입니다. 라이브러리를 효과적으로 구조화하기 위한 핵심 원칙은 다음과 같습니다.
파일 분리 전략
단일 Figma 파일에 모든 것을 넣으면 파일이 무거워지고 충돌이 잦아집니다. 아래와 같이 목적별로 파일을 분리하는 것을 권장합니다.
_Tokens: 색상, 타이포그래피, 간격 스타일 정의_Icons: 아이콘 컴포넌트 전용_Components: Atom·Molecule·Organism 컴포넌트_Patterns: 반복되는 UI 패턴 및 템플릿
컴포넌트 Variants 활용
Figma의 Component Variants 기능을 사용해 하나의 컴포넌트에서 상태(Default, Hover, Disabled, Error)와 크기(Small, Medium, Large)를 모두 관리하세요. 이렇게 하면 디자이너가 상태별 컴포넌트를 개별 파일에 흩어 놓지 않아도 됩니다.
Auto Layout 필수 적용
모든 컴포넌트에 Auto Layout을 적용해 콘텐츠 길이 변화에 유연하게 대응하도록 설계하세요. 고정 크기 컴포넌트는 실제 개발 환경과 괴리가 생겨 불필요한 재작업을 유발합니다.
1-4. 코드 컴포넌트 구현
코드 레벨에서 컴포넌트를 구현할 때 고려해야 할 기술적 결정 사항을 정리합니다.
기술 스택 선택
항목 | 권장 접근 |
|---|---|
프레임워크 | 서비스 메인 스택과 일치 (React, Vue 등) |
스타일링 | CSS Variables + CSS Modules 또는 Tailwind (토큰 연동 필수) |
문서화 | Storybook (컴포넌트 카탈로그 + 인터랙션 테스트) |
패키지 배포 | npm private registry 또는 monorepo (Turborepo, Nx) |
Props 설계 원칙
컴포넌트 Props는 디자인 토큰과 1:1로 대응하도록 설계합니다. color="#0057FF"처럼 원시값을 직접 받는 Props는 지양하고, variant="primary" | "secondary"처럼 의미 기반의 열거형(Enum)을 사용하세요. 이렇게 하면 사용자가 시스템 외부의 값을 임의로 주입하는 것을 방지할 수 있습니다.
접근성(Accessibility) 기본 내장
컴포넌트를 만들 때부터 WCAG 2.1 AA 기준을 충족하도록 설계하세요. 버튼에는 aria-label, 입력 필드에는 aria-describedby, 모달에는 포커스 트랩(Focus Trap)을 기본으로 포함합니다. 접근성은 나중에 추가하는 것이 아니라 처음부터 구조에 녹여야 합니다.
2부: 운영 실무 — 어떻게 유지할 것인가
2-1. 버전 관리와 Changelog
디자인 시스템이 '유령 문서'가 되는 가장 흔한 이유는 변경 이력이 관리되지 않기 때문입니다. 코드 저장소는 Git으로 관리하더라도, Figma 라이브러리 변경 내역은 별도로 문서화하지 않으면 추적이 불가능해집니다.
Semantic Versioning 적용
코드 패키지와 Figma 라이브러리 모두 [Semantic Versioning](https://semver.org/) 규칙을 따르세요.
MAJOR: 하위 호환성이 깨지는 변경 (컴포넌트 Props 삭제·변경)MINOR: 하위 호환성을 유지하는 기능 추가 (신규 컴포넌트)PATCH: 버그 수정, 미세 조정
Changelog 작성 규칙
Changelog는 기술 담당자만 읽는 문서가 아닙니다. 디자인 담당자와 기획자도 이해할 수 있도록 변경 이유와 영향 범위를 함께 기록하세요.
## v2.3.0 (2025-06-01)
### Added
- `DatePicker` 컴포넌트 추가 (모바일 대응 포함)
### Changed
- `Button` 컴포넌트: `size` Prop에 `xs` 옵션 추가
### Fixed
- `Modal` 컴포넌트: iOS Safari에서 스크롤 잠금 버그 수정2-2. 거버넌스 프로세스 설계
기술보다 어려운 것이 거버넌스입니다. 시스템이 특정 개인에게 의존하거나, 변경 요청이 쌓여 병목이 생기거나, 팀마다 독자적인 컴포넌트를 만들기 시작하면 시스템은 빠르게 분열됩니다.
시스템 위원회(Design System Council) 구성
최소 구성원:
디자이너 1명 (시스템 오너)
프론트엔드 개발자 1명
기획자(PO) 또는 서비스 담당자 1명
위원회는 격주 또는 월 1회 정기 리뷰를 운영하며, 다음 사항을 결정합니다.
신규 컴포넌트 추가 여부
기존 컴포넌트 변경·폐기 결정
토큰 값 업데이트
긴급 버그 수정 우선순위
RFC(Request for Comment) 프로세스
컴포넌트 추가·변경 요청은 자유롭게 제출하되, 반드시 RFC 문서 형식을 거치도록 합니다. RFC에는 다음 내용이 포함되어야 합니다.
변경 배경 및 문제 정의
제안하는 해결 방법 (시각 자료 포함)
영향받는 컴포넌트 및 페이지 목록
대안 검토 내용
RFC 프로세스가 있으면 즉흥적인 변경을 방지하고, 결정 근거를 나중에 추적할 수 있습니다.
2-3. 사용 현황 모니터링
컴포넌트가 실제로 어디서 얼마나 사용되고 있는지 파악하지 못하면, 폐기해야 할 컴포넌트를 계속 유지하거나 중요한 컴포넌트를 섣불리 변경하는 실수를 범할 수 있습니다.
코드 레벨 추적
정적 분석 도구(예: ESLint 커스텀 룰,
react-scanner)를 활용해 각 컴포넌트의 사용 횟수와 위치를 주기적으로 집계하세요.사용 빈도가 0인 컴포넌트는 '폐기 후보(Deprecated)' 상태로 표시하고, 일정 기간 후 제거합니다.
Figma Analytics 활용
Figma Organization 플랜에서는 라이브러리 컴포넌트의 사용 통계를 확인할 수 있습니다. 어떤 컴포넌트가 자주 분리(Detach)되는지 모니터링하면, 시스템이 실무 요구를 충족하지 못하는 지점을 발견할 수 있습니다.
2-4. 문서화: 살아있는 문서 만들기
좋은 컴포넌트보다 중요한 것이 좋은 문서입니다. 문서가 없거나 오래된 시스템은 신규 팀원이 사용하기 어렵고, 결국 시스템 외부에서 독자적인 컴포넌트가 생겨납니다.
Storybook을 문서의 중심으로
Storybook은 컴포넌트 카탈로그이자 인터랙티브 문서입니다. 각 컴포넌트 Story에는 다음을 포함하세요.
사용 목적과 사용하지 말아야 할 상황 (Do / Don't)
Props 설명 및 기본값
상태별 예시 (Default, Hover, Disabled, Error, Loading)
접근성 고려사항
관련 컴포넌트 링크
문서 업데이트를 PR 프로세스에 포함
컴포넌트를 변경하면서 문서를 업데이트하지 않는 것이 가장 흔한 문제입니다. PR 체크리스트에 'Storybook 문서 업데이트 여부'를 필수 항목으로 추가하고, 리뷰어가 확인하도록 프로세스를 만드세요.
3부: 단계별 구축 로드맵
디자인 시스템은 한 번에 완성할 수 없습니다. 단계적으로 구축하고 점진적으로 확장하는 접근이 현실적입니다.
Phase 1: 기반 구축 (1~2개월)
현재 서비스 UI 감사(Audit): 중복·불일치 요소 목록화
디자인 토큰 정의: 색상, 타이포그래피, 간격 우선
핵심 Atom 컴포넌트 10~15개 구현: 버튼, 입력 필드, 체크박스, 라디오, 셀렉트, 뱃지, 태그, 아이콘, 아바타 등
Figma 라이브러리 초기 구성 및 팀 공유
Storybook 환경 세팅 및 기본 문서화
Phase 2: 확장 (2~4개월)
Molecule·Organism 컴포넌트 추가: 폼, 모달, 테이블, 카드, 네비게이션 등
토큰 기반 테마 시스템 구축 (다크 모드, 브랜드 테마)
거버넌스 프로세스 정식 도입 (RFC, 위원회 운영)
npm 패키지 배포 및 버전 관리 시작
접근성 감사 및 보완
Phase 3: 정착 및 고도화 (4개월 이후)
사용 현황 모니터링 체계 구축
컴포넌트 성능 최적화 (번들 크기, 렌더링)
멀티 플랫폼 확장 (모바일 앱, 이메일 템플릿 등)
정기 시스템 리뷰 및 로드맵 업데이트
마치며: 시스템은 제품이다
디자인 시스템을 성공적으로 운영하는 조직의 공통점이 있습니다. 시스템을 내부 제품(Internal Product)으로 대우한다는 것입니다. 사용자는 외부 고객이 아닌 내부 디자이너와 개발자이지만, 그들의 피드백을 수집하고 우선순위를 정해 개선하는 방식은 일반 제품 개발과 다르지 않습니다.
기술적으로 완벽한 시스템보다, 팀이 실제로 사용하는 시스템이 더 좋은 시스템입니다. 처음부터 모든 것을 갖추려 하지 말고, 작게 시작해 빠르게 피드백을 받으며 반복하세요. 그 과정에서 시스템은 조직의 언어와 문화를 담은 살아있는 자산이 됩니다.