디자인 시스템(Design System)

디자인 시스템의 정의

디자인 시스템을 생각하면 무엇부터 떠오르는가?

UI 컴포넌트의 집합? 디자인 토큰? 컬러 시스템 혹은 타이포그래피? 브랜드의 철학을 담고 있는 무언가?

위에 나열된 모든 것들은 디자인 시스템이 맞다. 더 정확히는 디자인 시스템의 정의가 아닌 디자인 시스템을 구성하는 개체들이다.

 

그렇다면 디자인 시스템의 정의는 무엇일까? 여러 디자인 시스템의 정의를 살펴보자.

 

Nielsen Norman Group에서는 디자인 시스템을 다음과 같이 정의하고 있다.

 

A design system is a complete set of standards intended to manage design at scale using reusable components and patterns.

디자인 시스템은 재사용 가능한 컴포넌트와 패턴을 활용하여 규모 있는 디자인을 관리하기 위한 완전한 표준 체계

 

여기서 중요한 것은 "at scale"이다.  "규모가 있는" 디자인을 관리하기 위한 체계(System)이다.

 

 

Figma는 디자인 시스템을 더 넓은 범위로 정의하고 있다.

 

a set of building blocks and standards that help keep the look and feel of products and experiences consistent.

제품과 경험의 Look & Feel을 일관되게 유지하도록 돕는 Building Block과 Standards의 집합

 

NN/g가 디자인 시스템의 정의에 "using reusable components and patterns"라는 표현을 사용했다면, Figma는 디자인 시스템 정의에 "a set of building blocks and standards" 라는 표현을 사용했다.

 

더 자세하게 살펴보면 Figma는 Design System의 레이어를 다음과 같이 설명했다.

Design Stsyem
ㄴ Foundations
ㄴ Component / Pattern Libraries
ㄴ Documentation / Standars / Processes

 

위에 나열된 각 레이어는 각자 독립된 레이어가 아닌 Design System을 구성하는 레이어이다.

 

조금만 더 자세하게 살펴보자.

 

Foundations 

Foundations 레이어는 다음과 같이 정의할 수 있다.

제품을 만드는 데 필요한 가장 기본적인 디자인 언어와 규칙

Fimgasms Foundations를 제품 경험(Product Experience)를 만드는데 사용하는 Building Block이라고 설명한다.

예를 들면, Visual Styles, Colors, Typography, Components, Patterns 등이 포함된다.

쉽게 말하자면 "제품 전반에서 반복해서 사용하는 기본적인 디자인 속성과 그 기준을 정의" 이다.

 

Component / Pattern

Component

프론트엔드 개발자에게 가장 익숙한 개념이다.

Button, Input, Checkbox, Radio, Dropdown 등 웹 애플리케이션 개발에서 매일 마주치게 되는 UI 컴포넌트다.

 

Pattern

Pattern이란 무엇인가?

reusable solutions to common problems or user goals

 

Component 레이어가 Button, Input, Select와 같은 독립할 수 있는 요소를 제공한다면,

Pattern 레이어는 Login Form, Search, Filtering과 같이 사용자가 "특정한 문제를 해결하기 위해 컴포넌트를 어떻게 조립하는가?"를 제공한다.

 

곧 Component와 Pattern 레이어는 별개의 레이어가 아닌 상호 의존관계에 놓인 레이어라고 볼 수 있다.

 

Documentation / Standards / Processes

Documentation

Documentation 레이어는 단순히 API 문서를 지칭하지 않는다.

Figmasms Documentation를 Design System의 "how"라고 표현한다.

즉, "이걸 무엇을 위해 만들었고, 어떻게 사용해야 하는가?" 를 설명하는 것이다.

 

예를 들면 Button Component가 있다고 생각해보자.

Button 컴포넌트를 설명하기 위해서 우리는 다음의 내용을 문서로 작성할 수 있다.

# Purpose(목적)
언제 사용하는가?

# Usage(사용 예시)
어떻게 사용하는가?

# Do
어떤 상황에서 사용하는가?

# Don't
어떤 상황에서 사용하면 안 되는가?

# Accessibility
어떤 접근성 규칙을 지켜야 하는가?

# API
컴포넌트의 API(prop)은 무엇이 있는가?

 

Design System을 구축하기 위해서는 빈틈없는 문서가 필수이다.

특히 Agentic Engineering에서 일관성 있는 제품 경험을 만들기 위해서는 Design System의 문서화가 잘 되어있어야 한다.

 

Standards

"무엇을 기준으로 판단할 것인가?"를 의미한다.

예를 들면, 다음과 같은 기준이나 규칙이 될 수 있다.

- Button의 높이는 40px이다.

- 카드의 테두리 둥글기 기본 값은 8px이다.

- Primary Action은 화면에 하나만 존재한다.

 

Processes

Figma는 디자인 시스템을 유지보수하는 과정도 Design System의 일부라고 한다.

예를 들면, 새로운 요구사항 발생 > Component 추가 > Design 검토 > 개발 검토 > Develop > Review > Release > Documentation의 과정도 디자인 시스템의 일부라는 것이다.

 

디자인 시스템은 고여있지 않다.

완성된 디자인 시스템은 존재하지 않으며, 제품이 성장함에 따라 디자인 시스템도 함께 성장한다.

이렇게 유기적으로 살아 숨쉬는 디자인 시스템은 필연적으로 성장을 위한 Process를 가지며, Process에 녹아있는 History 역시 디자인 시스템의 일부인 것이다.

 

위 정의들을 살펴보면 우리는 디자인 시스템을 다음과 같이 정의할 수 있을것 같다.

"규모 있는 제품"에서 "일관된 제품 경험을 제공"하기 위해 구축하는 체계

 

디자인 시스템의 구성

Figma의 정의를 통해 디자인 시스템을 구성하는 각 레이어들을 살펴봤다.

그럼 실제적으로 디자인 시스템을 구성하기 위해서 필요한 것들은 무엇이 있을지 살펴보자.

 

Foundation

Foundation은 제품의 UI를 구성할 때 반복해서 사용되는 기본적인 디자인 속성과 그 기준을 정의한다.

제품에서 어떤 색상, 글꼴, 간격, 크기, 모서리 곡률(border-radius)를 사용할 것인지 기준을 정하고, 이를 일관되게 적용할 수 있도록한다.

 

예시

Design Token

색상, 간격, 타이포그래피, Radius, Shadow 등 디자인에서 반복적으로 사용되는 값을 이름과 의미를 가진 단위로 정의한다.

Color Palette

제품에서 사용할 색상의 종류와 역할을 정의한다. 단순히 색상 값을 나열하는 것이 아닌 primary, background, text, border 등 UI에서의 용도와 관계를 정의한다. (semantic)

 

Component

Component는 Foundation에서 정의한 기본 요소를 조합하여 만든 재사용 가능한 UI 단위다.

버튼, 입력창, 체크박스와 같이 제품에서 반복적으로 사용되는 UI를 하나의 컴포넌트로 정의하고, 동일한 컴포넌트를 여러 제품과 화면에서 재사용할 수 있도록 한다.

 

Document

Document는 디자인 시스템의 구성 요소를 어떻게(how), 언제(when), 왜(why) 사용해야 하는지 설명한다.

컴포넌트의 API나 사용 방법뿐만 아닌 접근성, 사용하면 안 되는 경우와 같은 의사결정 기준까지 문서화하여, 디자이너와 개발자가 동일한 기준으로 디자인 시스템을 바라볼 수 있도록 한다.

 

Usage

컴포넌트의 사용 방법과 적절한 사용 상황을 정의한다.

Guidelines

컴포넌트의 사용 원칙과 Do/Don't 등의 의사결정의 기준을 제공한다.

Accessibility

키보드 탐색, 스크린 리더, 상태 표현 등 접근성을 고려한 사용 방법과 요구사항을 정의한다.

 

Integration

Agentic Engineering에서 Design System과 AI를 연결할 수 있는 영역이다.

디자인 시스템은 컴포넌트와 토큰을 만들어서 제공하는 것에서 끝나는  것이 아닌, 실제 제품을 만드는 과정에서 디자인과 코드가 동일한 시스템을 바라볼 수 있도록 연결한다.

 

MCP

AI가 디자인 시스템의 컴포넌트, 토큰, 문서 등의 정보를 활용할 수 있도록 연결하는 인터페이스다. MCP를 통해 AI가 일반적인 UI를 생성하는 것을 넘어, 프로젝트에서 사용하는 디자인 시스템의 규칙과 컴포넌트를 기반으로 작업할 수 있도록 한다.

 

Figma with Code Connect

Figma의 디자인 컴포넌트와 실제 코드의 컴포넌트를 연결한다. 디자이너가 Figma에서 사용하는 컴포넌트와 개발자가 코드에서 사용하는 컴포넌트가 서로 다른 형태로 관리되는 문제를 줄이고, 디자인과 코드 사이의 연결성을 높인다.

 

Component Library !== Design System

디자인 시스템을 이야기할 때 가장 흔하게 발생하는 오해 중 하나는 디자인 시스템을 컴포넌트 라이브러리와 동일하게 생각하는 것이다.

 

컴포넌트 라이브러리는 Button, Input, Dialog와 같은 재사용 가능한 UI 컴포넌트를 제공한다. 하지만 디자인 시스템은 컴포넌트만을 제공하는 것이 아닌, 제품의 UI를 일관되게 만들기 위한 기본 원칙과 디자인 기준, 컴포넌트, 사용 가이드, 문서와 이를 관리하는 체계까지 포함한다.

 

즉, 컴포넌트 라이브러리가 디자인 시스템을 구성하는 중요한 요소 중 하나라면, 디자인 시스템은 그보다 더 넓은 범위를 가진다.

 

마치며

이번 글에서는 여러 디자인 시스템의 정의를 살펴보며 디자인 시스템이 무엇인지 알아보고, 실제 디자인 시스템을 구성하는 요소들을 간단하게 살펴봤다.

디자인 시스템은 단순히 UI 컴포넌트를 모아놓은 라이브러리가 아니다.

제품을 만드는 과정에서 반복되는 디자인과 개발의 의사결정을 일관된 기준으로 만들고, 이를 재사용 가능한 형태로 제공하는 시스템에 가깝다.

 

그렇다면 여기서 한 가지 질문이 생긴다.

"디자인 시스템은 실제 제품 개발에서 어떤 문제를 해결하고 있을까?"

 

다음 글에서는 컴포넌트의 재사용을 넘어, 디자인 시스템이 어떤 의사결정을 표준화하고 개발 과정의 어떤 비용을 줄이는지 살펴보려고 한다.

그리고 이러한 관점은 앞으로 AI Agent가 제품을 개발하는 환경에서 디자인 시스템이 어떤 역할을 할 수 있는지를 이해하는 중요한 출발점이 될 것이다.

 

참고자료

https://www.nngroup.com/articles/design-systems-101/?lm=design-system-enforcer&pt=article

https://help.figma.com/hc/en-us/articles/14552901442839-Overview-Introduction-to-design-systems

https://help.figma.com/hc/en-us/articles/14552740206743-Lesson-2-Define-your-design-system

https://help.figma.com/hc/en-us/articles/14552740206743-Lesson-2-Define-your-design-system