[기술문서] 디자인 시스템, 패턴 라이브러리, 스타일 가이드와 컴포넌트 라이브러리의 차이점

저는 현재 사내에서 프론트엔드 개발자를 위한 리액트 기반의 디자인 시스템을 구축중입니다.

 

사내 라이브러리를 v0.8.0 까지 제작하였는데, 개인적으로 지금까지의 버전은 컴포넌트 라이브러리에 지나지 못했다고 느끼고 있었습니다.

 

좀 더 체계화하여 시스템을 구축하는 방향으로 발전시켜야 디자인 시스템이라고 부를 수 있지 않을까 생각하던 참에,

디자인 시스템, UI 컴포넌트 라이브러리 및 비슷한 다른 개념들의 차이를 이해하고, 더 발전하기 위한 방향성을 찾기 위해 참고한 아티클이 있어 공유합니다.

 

https://www.uxpin.com/studio/blog/design-systems-vs-pattern-libraries-vs-style-guides-whats-difference/

The Difference Between Design Systems, Pattern Libraries, Style Guides & Component Libraries

 

이 글의 내용 중 핵심을 요약하자면, 아래와 같습니다.

• 디자인 시스템: 디자인 표준, 문서화, UI 도구 키트를 포함하는 완전한 세트로 브랜드 지침, 접근성 지침, UI 디자인 지침 등을 포함합니다. 디자인 시스템은 스타일 가이드, 컴포넌트, 모든 것을 묶어 연결해 줍니다.
• 스타일 가이드: 색상 코드, 타이포그래피 등 디자인 시스템의 패턴과 컴포넌트 사용 지침을 제공합니다. 사용방법을 설명한 정적 문서이기 때문에 유지관리가 필요하고 빠르게 구식이 될 수 있습니다.
• 패턴 라이브러리: 반복 가능한 UI 패턴의 모음으로, 로고, 링크, 검색 폼, CTA 버튼이 포함된 네비게이션 바 등의 구성 요소를 포함합니다. 아토믹 패턴에서 분자와 유기체에 해당합니다.
  • 아톰을 결합하여 만든 더 큰 UI 컴포넌트나 패턴(예: 페이지네이션, 브레드크럼)
  • 아톰과 분자로 구성된 복잡한 UI 패턴(예: 카드, 네비게이션 바)
• 컴포넌트 라이브러리: 재사용 가능한 코드 블록의 모음입니다. 버튼, 아이콘과 같은 아토믹 패턴에서의 Atom(아톰)에 해당합니다.

 

아래는 글 전문입니다.

---

디자인 시스템(design system), 컴포넌트 라이브러리(component library)는 종종 혼용되지만 각각 다른 부분을 지칭합니다. 

디자인 시스템은 컴포넌트 라이브러리를 포함하지만, MUI나 React-Bootstrap 같은 컴포넌트 라이브러리 자체도 독립된 생태계입니다. 

이 글은 이러한 용어들을 정의하고, 디자인 시스템과 컴포넌트 라이브러리의 장점과 디자이너와 개발자가 이를 어떻게 사용하는지 설명합니다. 디자이너는 MUI를 사용하여 코드 작성 없이 프로토타입을 만들 수 있습니다.

목차

1. 디자인 시스템이란?
2. 패턴 라이브러리 vs. 컴포넌트 라이브러리 – 차이점은 무엇인가?
3. 스타일 가이드란?
4. 디자인 시스템 vs. 컴포넌트 라이브러리
   1. 실용적인 디자인 시스템
   2. 디자인 시스템 만들기
   3. 디자인 시스템에 대해 더 알아보기
   4. 컴포넌트 라이브러리 사용하기
5. 디자이너와 엔지니어가 디자인 시스템을 사용하는 방법
6. UXPin Merge를 사용한 컴포넌트 라이브러리 및 디자인 시스템 사용

 

디자인 시스템이란?

디자인 시스템은 UI 도구 키트와 함께 제공되는 디자인 표준(스타일 가이드) 및 문서의 완전한 세트로, UI 패턴, UX 디자인 원칙 및 구성 요소를 포함합니다. 디지털 제품을 구축하고 확장하는 데 필요한 모든 것을 포함합니다.

디자인 시스템에 포함될 수 있는 항목:

• 브랜드 가이드라인
• 접근성 가이드라인
• UI 디자인 가이드라인
• 거버넌스 (Governance)
• 모범 사례
• 디자인 시스템 로드맵 및 릴리스
• 코드 스니펫
• CSS 변수 및 디자인 토큰
• UI 키트
• 다운로드 가능한 자산

 

패턴 라이브러리 vs. 컴포넌트 라이브러리 - 차이점은 무엇인가요?

패턴 라이브러리와 컴포넌트 라이브러리(component library)는 종종 혼용되지만, 정확히는 다릅니다. Brad Frost의 아토믹 디자인(Brad Frost’s Atomic Design) 방법론으로 차이를 설명할 수 있습니다:

• 아톰(Atoms): 더 이상 분해할 수 없는 기본 디자인 요소(예: 버튼, 아이콘).
• 분자(Molecules): 아톰을 결합하여 만든 더 큰 UI 컴포넌트나 패턴(예: 페이지네이션, 브레드크럼).
• 유기체(Organisms): 아톰과 분자로 구성된 복잡한 UI 패턴(예: 카드, 네비게이션 바).
• 템플릿(Templates): 아톰, 분자, 유기체를 포함한 완전한 레이아웃 및 와이어프레임.
• 페이지(Page): 모든 요소를 하나의 화면에 통합한 것.

컴포넌트 라이브러리 (아톰): 컴포넌트는 독립적으로 사용할 수 있는 재사용 가능한 코드 블록입니다. 예를 들어, 버튼 같은 것입니다. 디자인 시스템 내에서 UI 컴포넌트 모음입니다.

패턴 라이브러리 (분자 & 유기체): 패턴은 사용성 문제를 해결하기 위해 디자이너가 사용하는 컴포넌트 그룹입니다. 예를 들어, 로고, 링크, 검색 폼, CTA 버튼이 포함된 네비게이션 바 등이 있습니다. 디자인 시스템 내에서 UI 패턴 모음입니다.

이 방법으로 패턴과 컴포넌트를 정의할 수 있습니다.

 

스타일 가이드란?

스타일 가이드는 디자인 시스템의 패턴과 컴포넌트에 대한 맥락과 지침을 제공하는 문서입니다.

예를 들어, 색상 HEX 코드, 타이포그래피 규모, 사용 방법, 사용해서는 안 될 사항 등을 포함합니다.

스타일 가이드는 일관된 디자인을 유지하고, 디자이너와 개발자 간의 소통을 원활하게 합니다.

 

디자인 시스템 vs. 컴포넌트 라이브러리

컴포넌트 라이브러리(예: MUI, React-Bootstrap)는 광범위한 문서와 지침을 제공하지만 디자인 시스템과는 다릅니다. 컴포넌트 라이브러리는 오픈 소스로, 사용자들이 자유롭게 수정하고 새로운 패턴을 만들 수 있습니다.

반면, 디자인 시스템은 일관된 UI를 구축하기 위한 가이드라인과 스타일 가이드, 원칙 등을 엄격히 따라야 합니다. 팀원들이 컴포넌트를 변경하거나 새로운 패턴을 도입하려면 디자인 시스템의 거버넌스 절차를 따라야 하며, 최종 결정은 디자인 시스템 팀에 의해 이루어질 수 있습니다.

 

실용적인 디자인 시스템

디자인 시스템은 제한적으로 보일 수 있지만, 그 절차와 규정에는 타당한 이유가 있습니다. Atlassian을 예로 들어보겠습니다. Atlassian 전 세계적인 사용자 기반을 갖춘 비즈니스 도구 모음을 보유하고 있습니다.

Atlassian은 고객 지원부터 판매, 디자인, 개발에 이르기까지 전 세계 사용자들이 일관되고 일체감 있는 경험을 제공하기 위해 제품을 동기화하여 사용할 수 있도록 합니다. 이는 디자이너, 제품 팀, 엔지니어로 구성된 글로벌 팀이 일관된 경험을 제공하기 위해 디자인 시스템을 활용하는 것입니다.

다른 예로 Shopify는 전 세계 프리랜서와 에이전시가 개발하는 제3자 애플리케이션, 테마 및 기타 통합 기능을 지원합니다. 이것은 Atlassian보다 응집력과 일관성을 유지하는 것이 훨씬 더 어렵습니다.

Shopify는 Polaris 디자인 시스템을 개발하여 내부 및 외부 개발자가 Shopify 제품을 구축할 때 일관된 사용자 경험을 제공하도록 합니다. Polaris 디자인 시스템은 디자이너를 위한 UI 키트와 엔지니어를 위한 React 컴포넌트 라이브러리를 포함합니다.

이 경우, Polaris는 원칙, 문서화된 콘텐츠, 시각적 속성 및 UI 컴포넌트를 포함한 완전한 디자인 시스템입니다. 스타일 가이드는 Polaris 웹사이트에서 디자인 시스템을 사용하는 방법을 설명하는 정적 문서입니다. 패턴 라이브러리는 Polaris 디자인 시스템의 "Components" 부분입니다.

이 차이점은 제품 개발을 개선하는 데 매우 중요합니다. 스타일 가이드는 유지 관리가 필요하기 때문에 빠르게 구식이 될 수 있습니다. 패턴 라이브러리는 일관된 구현을 위한 지침과 원칙이 부족합니다.

디자인 시스템은 모든 것을 연결해 줍니다.

 

디자인 시스템 만들기

이제 이러한 용어들이 무엇을 의미하는지, 그리고 어떻게 함께 작동하는지 알았으니, 디자인 시스템을 구축하는 방법을 간단히 검토해보겠습니다. 다음은 "Creating a Design System: The 100-Point Process Checklist"라는 50페이지짜리 전자책에서 발췌한 주요 단계들입니다. (Creating a Design System: The 100-Point Process Checklist.)

1. UI 인벤토리 생성: 현재 인터페이스에서 사용 중인 모든 디자인 패턴을 목록화하고 불일치를 기록합니다.
2. 조직의 지원 확보: 조사 결과를 발표하고 공통 디자인 언어의 유용성을 설명합니다. (As explained in our Evangelizing Design Systems templates,) 중복 작업에 낭비되는 디자인 및 엔지니어링 시간을 추정하고, 제품 일관성이 NPS 점수에 미치는 영향을 설명합니다. 
3. 디자인 원칙 확립: (Codify your practices.) 스타일 가이드의 기초가 되는 디자인 원칙을 규정합니다.
4. 색상 팔레트 구축: UI 인벤토리에서 발견된 색상들을 통합하여 팔레트를 만듭니다.
5. 타이포그래피 스케일 구축: 폰트 크기, 굵기, 줄 높이 등의 속성을 설정합니다.
6. 아이콘 라이브러리 및 기타 스타일 구현: UI 인벤토리에서 디자인 시스템에 포함될 아이콘을 결정하고 표준화합니다. ( standardize the implementation.)
7. 첫 패턴 구축 시작: 제품의 현재 상태 또는 가까운 미래의 목표 상태를 반영하는 패턴을 만듭니다.

 

디자인 시스템에 대해 더 알아보기

우리는 디자인 시스템, 스타일 가이드, 패턴 라이브러리의 용어를 정의하고 이를 계층 구조로 조직했습니다. 또한 자체 디자인 시스템을 구축하는 방법도 간략히 설명했습니다.

디자인 시스템 구축의 단계별 설명은 50페이지 분량의 전자책 Creating a Design System: The 100-Point Process Checklist. 에서 확인할 수 있습니다. 이 조언은 UXPin의 CEO Marcin Treder가 내부 디자인 시스템을 구축한 경험을 바탕으로 합니다.

시스템을 구축한 후에는 성공을 보장하기 위한 추가 작업이 필요합니다. 조직에서 디자인 시스템을 출시한 후 해야 할 작업의 체크리스트도(checklist of things that you should do after releasing a design system) 준비했습니다.

 

컴포넌트 라이브러리 사용하기

컴포넌트 라이브러리는 디지털 제품 디자인을 위한 포괄적인 UI 요소 및 컴포넌트를 디자인 및 엔지니어링 팀에게 제공합니다. 가장 큰 이점은 팀이 처음부터 시작할 필요 없이, 철저히 테스트된 컴포넌트 라이브러리를 사용해 즉시 프로토타입 제작과 테스트를 시작할 수 있다는 점입니다.

MUI는 Google의 Material Design UI 기반으로, 세계에서 가장 포괄적이고 널리 사용되는 컴포넌트 라이브러리 중 하나입니다. 테마를 통해 사용자 정의를 제공하여 동일한 컴포넌트 라이브러리를 사용하더라도 경쟁사와 차별화된 UI를 만들 수 있습니다.

컴포넌트 라이브러리는 사용자 정의가 가능하지만, 디자인과 개발 간의 단일 진실의 원천을 제공합니다. 디자이너와 엔지니어가 동일한 컴포넌트를 사용하면 제품의 수명 주기 초기에 특히 도전적인 이점을 제공합니다. 디자인이 전달될 때 엔지니어는 컴포넌트 라이브러리의 컴포넌트를 복사하여 디자이너의 모형과 프로토타입에 따라 변경할 수 있습니다.

또한, 컴포넌트 라이브러리는 독립적인 엔지니어와 스타트업에게 제품과 프로토타입을 구축하기 위한 전문적으로 스타일링된 UI 요소를 제공하여 시장에 진입하고 경쟁하는 것을 용이하게 합니다.

 

디자이너와 엔지니어가 디자인 시스템을 사용하는 방법

디자이너와 엔지니어는 동일한 디자인 원칙을 따르지만, 지침과 문서는 다릅니다.

예를 들어, Polaris를 사용할 때 디자이너와 엔지니어는 Shopify 제품을 설계하는 접근 방식, 브랜드 요구 사항, 원칙을 이해하기 위해 Foundations와 Experiences를 따라야 합니다. 이러한 지식은 디자인과 코딩을 시작하기 전에 필수적입니다.

Polaris에는 UI 키트, Polaris 도구(아이콘 세트), Polaris GitHub 페이지, Shopify 블로그 링크, 추가 개발자 문서, 포럼 및 커뮤니티가 포함된 리소스 섹션이 있습니다.

디자이너: Shopify 제품 디자인을 위한 스타일 가이드, 디자인 언어, 색상, 타이포그래피, 일러스트레이션, 아이콘 등을 다루는 콘텐츠와 디자인 섹션을 참고합니다.

개발자: 디자인 문서를 숙지하고 컴포넌트 섹션에서 상호작용 예제 컴포넌트, 코드 스니펫, CodeSandbox 링크를 사용하여 Shopify 제품을 개발합니다.

 

UXPin Merge를 사용한 컴포넌트 라이브러리 및 디자인 시스템 사용

UXPin Merge를 통해 저장소에 호스팅된 디자인 시스템 또는 컴포넌트 라이브러리를 UXPin의 편집기와 동기화할 수 있습니다. 디자이너는 UI 키트 대신 완전한 코드 컴포넌트를 사용해 목업과 프로토타입을 만듭니다.

디자인 시스템 팀은 Git 통합(React의 경우) 또는 Merge의 Storybook 통합(Vue, Ember, Angular 등)과 함께 컴포넌트의 속성을 통해 제약을 설정하고 유연성을 제공합니다. 저장소의 모든 업데이트는 디자인 편집기와 자동 동기화되며, UXPin은 팀에 변경 사항을 알립니다. 이를 통해 조직 전체에 단일 진실의 원천을 만듭니다.

디자이너는 UXPin의 속성 패널을 통해 컴포넌트를 조정하거나 JSX로 전환하여 코드를 직접 수정할 수 있습니다. 디자인 전달 시, 엔지니어는 각 컴포넌트의 JSX 속성을 복사해 최종 제품을 개발합니다.

UXPin은 코드에서 생성된 상호작용 컴포넌트로 자동 디자인 시스템을 생성합니다. 스타일 가이드와 다른 문서도 포함할 수 있어, 디자인 언어를 한 곳에서 관리할 수 있습니다. 디자인 팀은 디자인 라이브러리 패널에서 필요한 자산을 가져와 레이아웃을 구축합니다.