테마
마이크로프론트엔드와 디자인 시스템
여러 팀이 독립적으로 개발하는 마이크로프론트엔드 환경에서 일관된 사용자 경험을 보장하는 핵심 장치, 디자인 시스템의 정의와 구성 요소, 그리고 MFE에서의 역할을 학습한다.
학습 목표
- 디자인 시스템의 정의를 설명하고, UI 라이브러리와의 차이를 명확히 구분할 수 있다
- 디자인 시스템의 세 가지 핵심 구성 요소(스타일 가이드, 컴포넌트 라이브러리, 패턴 라이브러리)를 설명할 수 있다
- 디자인 시스템이 조직에 가져다주는 구체적인 장점을 나열할 수 있다
- 마이크로프론트엔드 환경에서 디자인 시스템이 특히 중요한 이유를 이해하고 설명할 수 있다
Part A: 디자인 시스템이란
1. 정의
디자인 시스템은 단순한 UI 컴포넌트 모음이 아니다. 여러 권위 있는 정의를 살펴보자.
위키피디아:
"명확한 표준에 따라 관리되는 재사용 가능한 컴포넌트의 모임으로, 조합하여 여러 애플리케이션을 구축할 수 있는 것"
닐슨 노만 그룹(Nielsen Norman Group):
"여러 페이지와 채널에서 시각적 일관성을 유지하면서 중복을 줄이고, 대규모 디자인을 관리하기 위한 표준의 집합"
두 정의에서 공통적으로 강조하는 키워드는 표준, 재사용, 일관성, 대규모 관리이다.
2. 디자인 시스템 ≠ UI 라이브러리
많은 사람이 디자인 시스템과 UI 라이브러리를 혼동한다. 그러나 UI 라이브러리는 디자인 시스템을 구성하는 여러 요소 중 하나일 뿐이다.
| 구분 | UI 라이브러리 | 디자인 시스템 |
|---|---|---|
| 범위 | 코딩된 컴포넌트(버튼, 인풋 등) | 원칙 + 가이드라인 + 컴포넌트 + 패턴 + 도구 + 프로세스 |
| 대상 | 개발자 | 디자이너 + 개발자 + PM + QA |
| 산출물 | npm 패키지 | 문서 사이트 + npm 패키지 + Figma 파일 + 기여 가이드 |
| 목적 | 코드 재사용 | 조직 전체의 일관된 경험 보장 |
| 예시 | Material UI, Ant Design | Material Design, Carbon Design System |
즉, 디자인 시스템은 "왜 이 컴포넌트가 이렇게 생겼는지"에 대한 원칙과 문맥까지 포함하는 상위 개념이다.
Part B: 디자인 시스템의 구성 요소
디자인 시스템은 크게 세 가지 핵심 요소와 이를 운영하는 전담 팀으로 구성된다.
1. 스타일 가이드 (Style Guide)
시각적 규칙의 집합이다. 모든 디자인 결정의 기초가 된다.
색상 체계
css
/* 디자인 토큰(Design Token)으로 정의 */
:root {
/* Primary */
--color-primary-50: #e3f2fd;
--color-primary-100: #bbdefb;
--color-primary-500: #2196f3; /* 기본 */
--color-primary-700: #1976d2; /* 호버 */
--color-primary-900: #0d47a1; /* 액티브 */
/* Semantic */
--color-success: #4caf50;
--color-warning: #ff9800;
--color-error: #f44336;
--color-info: #2196f3;
/* Neutral */
--color-text-primary: #212121;
--color-text-secondary: #757575;
--color-background: #fafafa;
--color-border: #e0e0e0;
}타이포그래피
css
:root {
--font-family-base: 'Pretendard', -apple-system, sans-serif;
--font-size-xs: 0.75rem; /* 12px */
--font-size-sm: 0.875rem; /* 14px */
--font-size-md: 1rem; /* 16px - 기본 */
--font-size-lg: 1.25rem; /* 20px */
--font-size-xl: 1.5rem; /* 24px */
--font-size-2xl: 2rem; /* 32px */
--font-weight-regular: 400;
--font-weight-medium: 500;
--font-weight-bold: 700;
--line-height-tight: 1.25;
--line-height-normal: 1.5;
--line-height-relaxed: 1.75;
}간격 체계
css
:root {
--spacing-1: 0.25rem; /* 4px */
--spacing-2: 0.5rem; /* 8px */
--spacing-3: 0.75rem; /* 12px */
--spacing-4: 1rem; /* 16px */
--spacing-6: 1.5rem; /* 24px */
--spacing-8: 2rem; /* 32px */
--spacing-12: 3rem; /* 48px */
--spacing-16: 4rem; /* 64px */
}디자인 토큰(Design Token): 색상, 폰트, 간격 같은 디자인 결정 값을 플랫폼 독립적인 형태로 저장하는 것. JSON, YAML 등으로 정의하고 CSS, iOS, Android 등 각 플랫폼 코드로 변환한다.
2. 컴포넌트 라이브러리 (Component Library)
스타일 가이드에 정의된 규칙을 코드로 구현한 재사용 가능한 UI 컴포넌트 모음이다. 디자인 시스템의 가장 실질적인 산출물이다.
typescript
// Button 컴포넌트 예시 - 디자인 토큰을 기반으로 구현
interface ButtonProps {
variant: 'primary' | 'secondary' | 'ghost';
size: 'sm' | 'md' | 'lg';
disabled?: boolean;
loading?: boolean;
children: React.ReactNode;
onClick?: () => void;
}
function Button({ variant, size, disabled, loading, children, onClick }: ButtonProps) {
return (
<button
className={`btn btn--${variant} btn--${size}`}
disabled={disabled || loading}
onClick={onClick}
>
{loading && <Spinner size="sm" />}
{children}
</button>
);
}컴포넌트 라이브러리는 다음과 같은 수준으로 분류된다.
| 수준 | 예시 | 설명 |
|---|---|---|
| Atom (원자) | Button, Input, Icon, Badge | 더 이상 분해할 수 없는 최소 단위 |
| Molecule (분자) | SearchBar, FormField, MenuItem | 원자 컴포넌트를 조합한 것 |
| Organism (유기체) | Header, DataTable, Modal | 분자와 원자를 조합한 복잡한 UI 블록 |
3. 패턴 라이브러리 (Pattern Library)
반복적으로 등장하는 UI/UX 패턴을 정리한 것이다. 컴포넌트가 "무엇"이라면, 패턴은 "어떻게 조합하고 배치하는가"이다.
| 패턴 | 설명 | 예시 |
|---|---|---|
| 폼 패턴 | 사용자 입력을 수집하는 방식 | 라벨 위치, 유효성 검사 메시지 위치, 필수 필드 표시법 |
| 네비게이션 패턴 | 화면 간 이동 방식 | 탭, 브레드크럼, 사이드 네비게이션, 페이지네이션 |
| 에러 처리 패턴 | 오류를 사용자에게 알리는 방식 | 인라인 에러, 토스트, 에러 페이지, 빈 상태 |
| 데이터 표시 패턴 | 데이터를 보여주는 방식 | 카드 리스트, 테이블, 차트, 타임라인 |
| 로딩 패턴 | 대기 상태를 표현하는 방식 | 스피너, 스켈레톤, 프로그레스 바 |
4. 디자인 시스템 전담 팀
디자인 시스템은 만들고 나면 끝이 아니다. 지속적으로 관리하고 발전시키는 전담 팀이 필요하다.
전담 팀의 역할:
- 디자인 토큰과 컴포넌트의 추가/수정/폐기 관리
- 각 마이크로앱 팀의 요청 수렴 및 반영
- 문서화와 스토리북(Storybook) 관리
- 버전 관리 및 마이그레이션 가이드 제공
- 사용 가이드라인 교육
Part C: 디자인 시스템의 장점
1. 디자인에서 프로덕션까지의 워크플로우 간소화
디자인 시스템이 없으면 디자이너가 만든 시안을 개발자가 매번 처음부터 해석하고 구현해야 한다. 디자인 시스템이 있으면 디자이너는 정의된 컴포넌트로 시안을 구성하고, 개발자는 이미 구현된 컴포넌트를 조합하면 된다.
2. 팀 간 통합된 언어(Shared Language)
디자이너가 "Primary Button"이라고 말하면 개발자도 정확히 같은 것을 떠올린다. "좀 더 큰 버튼"이 아니라 size="lg"라는 명확한 속성으로 소통한다. 이러한 공유 언어는 의사소통 비용을 크게 줄인다.
3. 재사용 가능한 컴포넌트
한 번 잘 만든 컴포넌트를 여러 팀, 여러 프로젝트에서 재사용할 수 있다. 버튼 하나를 만드는 데 드는 시간이 3시간이라면, 10개 팀이 각자 만들면 30시간이지만 디자인 시스템에서 1번 만들면 3시간 + 유지보수 비용만 든다.
4. 응집력 있는 사용자 경험(UX)
상품 페이지, 주문 페이지, 마이페이지를 서로 다른 팀이 만들더라도, 같은 디자인 시스템을 사용하면 사용자는 하나의 통합된 서비스를 경험한다.
5. 기술 부채 감소와 유지보수 개선
- 컴포넌트의 접근성(a11y) 처리를 한 곳에서 관리
- 브라우저 호환성 대응을 한 곳에서 처리
- 디자인 변경 시 디자인 시스템만 업데이트하면 전체 반영
- 새로운 팀원의 온보딩 시간 단축
장점 요약
| 장점 | 영향 받는 대상 | 효과 |
|---|---|---|
| 워크플로우 간소화 | 디자이너, 개발자 | 구현 속도 향상 |
| 공유 언어 생성 | 전체 조직 | 의사소통 비용 감소 |
| 컴포넌트 재사용 | 개발자 | 개발 시간 절약 |
| 일관된 UX | 사용자 | 서비스 신뢰도 향상 |
| 기술 부채 감소 | 개발자, 관리자 | 유지보수 비용 절감 |
| 확장성 개선 | 조직 전체 | 새 서비스 출시 가속 |
Part D: MFE와 디자인 시스템의 관계
1. 왜 MFE에서 디자인 시스템이 특히 중요한가
모놀리식 프론트엔드에서는 하나의 팀이 전체를 개발하므로, 명시적 디자인 시스템 없이도 자연스럽게 일관성이 유지될 수 있다. 같은 코드베이스를 공유하기 때문이다.
그러나 마이크로프론트엔드에서는 상황이 완전히 다르다.
- 각 팀이 독립적으로 개발한다
- 각 팀이 자체 코드베이스를 관리한다
- 각 팀이 자율적으로 기술 결정을 내린다
이런 환경에서 디자인 시스템이 없으면 UX 파편화가 발생한다.
[디자인 시스템 없는 MFE]
팀 A: 파란색 Primary Button, 8px 패딩, 둥근 모서리
팀 B: 초록색 Primary Button, 12px 패딩, 각진 모서리
팀 C: 파란색 Primary Button, 8px 패딩, 각진 모서리
→ 사용자: "이게 같은 서비스가 맞나?"2. 디자인 시스템은 MFE의 안전장치
마이크로프론트엔드의 핵심 가치는 팀의 자율성이다. 그러나 자율성이 곧 무질서를 의미해서는 안 된다. 디자인 시스템은 이 둘 사이의 균형을 잡는 안전장치 역할을 한다.
| 자율성 | 디자인 시스템이 보장하는 일관성 |
|---|---|
| 팀이 자유롭게 기술 스택 선택 | 어떤 기술로 구현하든 같은 디자인 토큰 사용 |
| 팀이 독립적으로 배포 | 배포 시점과 무관하게 시각적 일관성 유지 |
| 팀이 자체적으로 기능 결정 | 사용자 인터랙션 패턴은 통일 |
| 팀이 자체 코드베이스 관리 | 공유 컴포넌트로 기본 품질 보장 |
3. 디자인 시스템 팀의 워크플로우
디자인 시스템은 한 번 만들고 끝나는 프로젝트가 아니라 지속적인 제품이다.
이 순환 과정의 각 단계를 자세히 보면:
디자인: Figma 등의 도구에서 컴포넌트를 디자인한다. 디자인 토큰을 정의하고 컴포넌트의 상태(기본, 호버, 비활성, 에러 등)를 모두 정의한다.
빌드: 디자인된 컴포넌트를 코드로 구현한다. 접근성(a11y), 키보드 네비게이션, 반응형 대응을 포함한다.
문서화: Storybook 등으로 각 컴포넌트의 사용 예시, Props 설명, Do/Don't 가이드를 작성한다.
배포: npm 패키지로 배포하여 마이크로앱 팀들이 설치할 수 있게 한다. 시맨틱 버저닝을 적용한다.
소비: 각 마이크로앱 팀이 디자인 시스템 패키지를 설치하고 컴포넌트를 사용한다.
피드백: 사용 과정에서 발견된 문제점이나 개선 요청을 수렴하여 다음 버전에 반영한다.
4. MFE 환경에서 디자인 시스템 운영 시 주의사항
| 주의사항 | 설명 |
|---|---|
| 버전 불일치 | 팀마다 다른 버전의 디자인 시스템을 사용할 수 있음. 주요 변경 시 마이그레이션 가이드 필수 |
| 커스터마이즈 제한 | 디자인 시스템 컴포넌트를 과도하게 커스터마이즈하면 일관성이 깨짐. 확장 포인트를 명확히 정의 |
| 성능 고려 | 각 마이크로앱이 디자인 시스템 전체를 번들에 포함하면 용량이 커짐. Tree-shaking 지원 필수 |
| 프레임워크 중립성 | React, Vue, Svelte 등 다양한 프레임워크를 사용하는 팀이 있다면, 프레임워크 독립적인 토큰 레이어가 필요 |
| 팀 간 거버넌스 | 디자인 시스템 변경 프로세스(RFC, 리뷰, 승인)를 명확히 해야 변경이 혼란을 일으키지 않음 |
핵심 정리
디자인 시스템은 UI 라이브러리보다 상위 개념이다. 시각적 규칙(스타일 가이드), 코드 구현(컴포넌트 라이브러리), 사용 패턴(패턴 라이브러리), 그리고 이를 운영하는 프로세스와 전담 팀까지 포함한다.
디자인 시스템의 세 가지 핵심 구성 요소는 스타일 가이드, 컴포넌트 라이브러리, 패턴 라이브러리이다. 스타일 가이드는 "규칙", 컴포넌트 라이브러리는 "도구", 패턴 라이브러리는 "사용법"을 정의한다.
디자인 시스템은 워크플로우 간소화, 공유 언어 생성, 일관된 UX, 기술 부채 감소 등 다방면의 장점을 제공한다. 초기 투자 비용이 크지만 조직 규모가 커질수록 효과가 극대화된다.
MFE 환경에서 디자인 시스템은 "선택"이 아니라 "필수"이다. 각 팀이 자율적으로 개발하는 MFE의 특성상, 디자인 시스템 없이는 UX 파편화를 막을 수 없다. 디자인 시스템은 자율성과 일관성 사이의 균형을 잡는 안전장치이다.
디자인 시스템은 지속적인 제품이다. 디자인 -> 빌드 -> 문서화 -> 배포 -> 소비 -> 피드백의 순환 사이클을 통해 끊임없이 발전해야 한다. 이를 위해 오너쉽을 갖는 전담 팀이 반드시 필요하다.
다음 단계
디자인 시스템으로 여러 마이크로앱의 시각적 일관성을 보장하는 방법을 학습했다. 다음으로는 이 마이크로앱들의 코드를 어떤 저장소 구조로 관리할 것인가 하는 문제를 다룬다. 싱글 레포, 멀티 레포, 모노레포 각 전략의 장단점을 비교한다.