정책과 흐름을 연결하는 도구로서의 디자인 시스템
디자인시스템의 또다른 역할
처음 디자인 시스템이라는 개념을 접했을 땐, 컬러, 폰트, 컴포넌트, 토큰을 정리해 디자인의 일관성을 지키고 효율성을 높이는 도구 정도로 이해했다.
하지만 실제로 도입해 적용해보며 깨달은 건, 사용자 권한이 다양하고 기능이 기하급수적으로 늘어나는 제품에서는 디자인 시스템 없이는 설계 자체가 어려워진다는 점이었다.
디자인 시스템은 단순히 재사용을 위한 라이브러리가 아니라, 복잡한 제품 속에서 디자이너가 사고하고 소통하는 방식이었다.
복잡한 제품에서 디자인 시스템이 꼭 필요한 이유
1. 인터페이스의 역할-책임(responsibility)이 명확해진다.
디자인시스템은 컴포넌트가 어떤 상황에서, 어떤 역할로 쓰여야 하는지를 정의한다.
예를 들어, 아래 교통관제 시스템의 노선 관리 헤더를 보자.
'노선관리' 헤더의 권한별 UI 변화권한(운영자, 관리자, 특수 관리자)과 정책에 따라 UI의 형태가 달라지는데, 여기서 '이 컴포넌트가 화면에서 맡는 역할은 무엇인가?'의 관점으로 정의하는 것이 중요하다.
헤더 컴포넌트 (Header Component) 정의
- 화면의 현재 컨텍스트 표기: 화면이나 기능의 이름, 선택된 대상을 좌측에 고정 배치한다.(예: 노선 관리, 노선 생성, 노선명 등)
- 맥락에서 현재 수행 가능한 주요 기능 노출: 권한과 정책에 따라 버튼 유무, 액션을 분기해 제공한다.
- 우선 순위 있는 기능 배치: 주요 액션 버튼은 우측에 고정 배치한다, 복수 액션 기능은 더보기 메뉴(⋮)로 묶어 표현한다.
이런 정의를 통해 하나의 UI 구조 안에서 역할과 책임을 일관되게 표현할 수 있다.
비슷한 맥락에서 복사 버튼도 단순히 복사 아이콘을 보여주는 것에 그치지 않는다. 클릭 직후 알림을 통해 “복사되었습니다” 같은 피드백을 제공하는 것까지 포함된다. 즉, 버튼의 책임은 행동의 결과 피드백을 함께 전달하는 데 있다.
Figma에서 annotation을 활용한 가이드 화면이런 시스템 차원의 정의가 없다면, 화면마다 규칙은 흩어지고, 디자인은 혼란에 빠진다. 디자인시스템은 이를 방지해 전체 구조가 무너지지 않도록 지켜준다.
그 결과, 컴포넌트의 재사용을 넘어 정책과 흐름까지 일관되게 표현할 수 있게 된다.
2. 구조를 통제할 수 있다.
디자인시스템은 속성(Properties)과 상태(State)라는 구조로 정의해 흐름을 통제할 수 있다.
예를 들어, 아래 우리가 정의한 DatePicker 컴포넌트를 보자. 단순한 날짜 입력 필드처럼 보이지만, 실제로는 다양한 정책이 속성(Properties)으로 구조화되어 있다.
Figma에서 속성으로 구조화한 DatePicker 컴포넌트granularity: day, hour, minute, second
→ 일,시,분,초의 노출을 업무 정책이나 규제에 따라 다르게 반영한다.
locale: ko, en
→ 언어/지역 정책을 반영한다. (예: ko → 2025.08.15, en(US) → 08/15/2025)
hourCycle: 24, 12
→ 24시간제, 12시간제 선택은 문화적/제도적 정책에 따른다.
정의된 속성으로 구현한 다양한 UI (좌: locale=ko, 우: locale=en)이처럼 정책이 속성으로 정의되어 있으면, 요구사항이 바뀌더라도 컴포넌트를 새로 만들 필요가 없다.
매번 UI를 뜯어고치는 것이 아니라, 속성 값 변경만으로 정책을 반영할 수 있게 만드는 것이 바로 디자인시스템이 구조를 통제하는 방식이다.
아래의 예시는 지역 선택 패널이다. 하나의 컴포넌트 구조의 너비를 조절하여, PC 환경에서는 넓은 화면에서 한눈에 모든 지역을 보여주고, 화면이 좁은 환경에서는 1단 스크롤 구조로 풀어낸다. 화면 형태가 달라져도 규칙은 변하지 않고 구조 안에서 일관되게 통제된다.
하나의 컴포넌트를 레이아웃에 따라 통제 가능하다.디자인 시스템은 UI 레벨의 단순 통일에 그치지 않고, 상태와 정책을 구조적으로 정의해 흐름 전체를 통제하는 체계로 만든다.
3. 유지보수 가능한 디자인을 가능하게 한다.
유지보수 가능한 디자인이란, 변화가 생길 때마다 디자인을 다시 하는게 아니라 이미 정의된 구조 안에서 변화를 흡수할 수 있는 설계를 말한다.
새로운 기능이 추가되거나 정책이 바뀌었을 때, 기존 컴포넌트를 확장, 수용할 수 있는 구조를 만들어두는 것이 핵심이다. 이는 제품 구조의 신뢰성과 안정성을 지켜주는 일이기도 하다.
해당 컴포넌트를 다른 맥락에서 다시 쓸 수 있는가?
새로운 상태나 속성이 추가되었을 때, 해결이 가능한가? 아니면 기존 구조 전체를 바꿔야 하는가?
이 질문에 “가능하다”라는 답을 줄 수 있어야 한다.
예를 들어 버튼을 처음 만들 땐, 버튼의 활성상태(가능/불가능)만 생각 할 수 있다. 하지만 사용하다보면,
‘로딩 중…’, ‘다시 시도하세요’ 같은 형태도 필요해진다. 정책상 어떤 상황에서는 버튼을 못 누르게 해야 할 수도 있다.
그래서 처음부터 버튼을 만들 때 새로운 상태나 정책이 생겨도 버튼 하나를 계속 발전시켜서 쓸 수 있는 구조로 만드는것이 중요하다.
DatePicker 역시 확장성의 좋은 사례다.
만일 서비스 확장으로 새로운 지역이 추가되어 "15/08/2025"같은 표기방법 필요해도 속성을 추가하기만 하면 된다. 전체 시스템에 새로운 표기 방법을 반영하는 일이 디자인시스템으로 손쉽게 구현이 가능하다.
새로운 표기방법도 locale의 속성 추가만으로 손쉽게 전체 적용이 가능하다.정책은 계속 바뀌기 때문에 디자인시스템이 정책 문서가 될 수는 없다. 하지만 정책을 UI에서 어떻게 표현할지는 변하지 않는 구조다. 디자인시스템은 정책 그 자체를 담기보다, 정책이 바뀌어도 적용할 수 있는 표현의 언어와 틀을 제공하는 것에 의미가 있다.
이 점은 글로벌 사례에서도 확인할 수 있다.
Airbnb – Design Language System(DLS)
단순한 UI 킷이 아니라 제품 철학을 표현하는 언어 체계로 설계됨.
Shopify – Polaris
각 컴포넌트마다 “어떤 조건에서 사용되는가”를 문서화. ‘모양’이 아니라 ‘맥락’을 정의함.
Google – Material 3
디자인 시스템에 ‘상태 기반 설계(stateful design)’ 개념을 강화. 조건, 정책, 흐름 중심의 시스템 설계를 촉진함.
복잡한 운영 시스템, 툴 기반 제품, 화면보다 기능이 많은 제품일수록 디자인 시스템은 제품을 설계할 수 있게 해주는 구조 그 자체가 된다는 생각이 들었다.
돌아보면, 디자인시스템을 만든다는 건 디자인을 규격화하는 일이 아니라 제품 구조를 디자인 언어로 만드는 일이었다. 디자인이 주인공이 아니라, 그 디자인을 가능하게 하는 시스템이 주인공이었다.
디자인시스템을 설계하는 건 룰에 갇히는 게 아니라, 변화를 구조 안에서 수용 가능한 방향으로 정제하는 디자인 작업이라고 생각한다.
보이는 UI는 결과일 뿐, 본질은 그 UI를 가능하게 만드는 구조와 규칙을 정의하는 일에 있다. 그래서 복잡한 시스템일수록, 디자이너는 조건에 따라 작동하는 구조를 정의할 수 있어야 한다.
그것이야말로 디자인의 역할이라고 생각한다.
