디자인 시스템 구축기
1. 왜 디자인 시스템이 필요했을까?
Plaid는 B2B와 B2C 프로젝트를 모두 진행하는 구조를 가지고 있습니다. 내부 서비스뿐만 아니라 여러 기업 고객사의 프로젝트를 동시에 수행하다 보니, 프로젝트 수가 늘어날수록 공통 컴포넌트와 UI 패턴을 반복적으로 구현하는 상황이 잦아졌습니다. 특히 버튼, 입력 필드와 같은 기본 UI 컴포넌트는 형태와 역할이 유사함에도 불구하고 프로젝트마다 새로운 구현이 필요했습니다.
이 과정에서 “매번 새로 만드는 대신 우리 회사만의 기준과 표준을 만들 수는 없을까?”라는 고민을 하게 되었고, 이를 계기로 사내 디자인 시스템을 구축해야겠다는 필요성을 느끼게 되었습니다. 디자인 시스템을 통해 공통 컴포넌트를 표준화한다면 개발 효율을 높일 수 있을 뿐만 아니라 여러 고객사의 프로젝트를 진행하더라도 Plaid만의 일관된 스타일과 개발 경험을 유지할 수 있을 것이라 생각했습니다.
2. 단순한 컴포넌트 모음이 아닌 ‘확장 가능한 시스템’을 목표로
디자인 시스템을 구성하면서 가장 중요하게 생각했던 점은 “얼마나 빨리 만들 수 있는가”가 아니라 “얼마나 오래 유지할 수 있는가”였습니다. 디자인 시스템은 한 번 만들고 끝나는 산출물이 아닌 시간이 지날수록 컴포넌트와 규칙이 계속 추가되고 수정되는 구조이기 때문입니다.
따라서 초기 설계 단계에서부터 다음과 같은 질문들을 지속적으로 던졌습니다.
여러 프로젝트에서 동시에 사용해도 문제가 없을까?
디자인 토큰과 컴포넌트 스타일이 자연스럽게 연결될 수 있을까?
새로운 컴포넌트나 variant가 추가되었을 때 확장하기 쉬운 구조일까?
디자이너와 개발자 간의 협업 비용을 줄일 수 있을까?
이러한 고민을 바탕으로 단순히 UI 컴포넌트를 나열하는 라이브러리가 아니라 회사 전반에서 재사용 가능한 설계 시스템을 만드는 것을 목표로 삼았습니다.
3. CSS 라이브러리로 vanilla-extract를 선택한 이유
FE 팀의 기존 프로젝트에서는 Tailwind CSS를 사용해 왔습니다. Tailwind는 빠른 UI 개발에 매우 효과적인 도구이지만 디자인 시스템 관점에서 보면 몇 가지 아쉬운 점이 존재했습니다.
Tailwind는 유틸리티 클래스 기반이기 때문에 컴포넌트 내부에서 스타일 규칙이 분산되기 쉽고 컴포넌트 라이브러리 자체가 Tailwind에 강하게 의존하게 됩니다. 이런 점이 외부 프로젝트나 다른 환경에서 디자인 시스템을 재사용할 때 제약 요소로 작용할 수 있다고 판단했습니다.
이에 따라 CSS-in-TypeScript 방식이면서도 제로 런타임(Zero-runtime)을 제공하는 vanilla-extract를 선택하게 되었습니다. vanilla-extract는 빌드 시점에 정적인 CSS를 생성하므로 런타임 오버헤드가 없고, 번들 사이즈 최적화 측면에서도 유리하다는 특징이 있습니다.
또한 recipe API를 활용하면 variant 기반 스타일 정의가 가능하여, 기존에 cva(Class Variance Authority)를 사용하던 패턴을 자연스럽게 대체할 수 있었습니다. 이 방식은 variant가 많은 컴포넌트를 설계할 때 특히 유용하고 디자인 토큰 기반의 스타일 구조화에도 잘 어울린다고 판단했습니다. 무엇보다 TypeScript 기반의 타입 안전성을 제공한다는 점에서 대규모 컴포넌트 관리에 적합하다고 생각했습니다.
4. 번들러로 Vite를 선택한 이유
디자인 시스템은 개발 단계뿐만 아니라 빌드와 배포 과정에서도 빠른 피드백이 중요합니다. 이러한 요구사항을 충족하기 위해 번들러로는 Vite를 선택하게 되었습니다.
Vite는 ESM 기반의 개발 서버를 제공하여 개발 속도가 빠르고, Rollup 기반 빌드를 통해 라이브러리 배포 시에도 안정적인 tree-shaking과 code splitting을 지원합니다. 또한 CSS, TypeScript, JSX에 대한 기본적인 컴파일 환경을 별도 설정 없이 제공한다는 점에서 초기 세팅 부담을 크게 줄일 수 있었습니다.
특히 Storybook을 함께 사용하는 디자인 시스템 환경에서는 Vite builder와의 궁합이 매우 좋다고 생각했습니다.
5. 아이콘과 SVG 관리 전략
아이콘은 디자인 시스템에서 가장 많이 사용되면서도 관리가 까다로운 요소 중 하나라고 생각합니다. 단순히 SVG 파일을 제공하는 방식보다는 React 컴포넌트 형태로 아이콘을 제공하는 것이 재사용성과 확장성 면에서 더 유리하다고 생각했습니다.
이를 위해 SVGR을 사용해 SVG를 React 컴포넌트로 변환하고, SVGO를 통해 파일 용량 최적화와 불필요한 attribute 제거를 선행하는 구조를 채택했습니다. 이 방식을 통해 아이콘 품질 관리와 성능 최적화를 동시에 만족시킬 수 있습니다.
아이콘 컴포넌트는 props를 통해 제어 가능하도록 설계하여 디자인 토큰과 자연스럽게 연동될 수 있도록 확장성 있게 구성했습니다.
6. 배포 전략 설계
디자인 시스템은 단일 프로젝트가 아닌 여러 프로젝트에서 동시에 사용되는 공용 자산이기 때문에 배포 전략 역시 초기 설계 단계에서 중요하게 고려해야 했습니다. 특히 Plaid의 특성상 디자인 시스템을 각 프로젝트에 일관되게 적용하고 변경 사항을 안정적으로 공유할 수 있는 배포 방식이 필요했습니다.
이러한 환경에서 사내 디자인 시스템의 정식 배포 방식으로는 npm publish가 가장 표준적이고 유지보수성이 높다고 판단했습니다. npm 패키지 형태로 배포할 경우 각 프로젝트에서는 일반 라이브러리와 동일하게 npm install만으로 디자인 시스템을 사용할 수 있으며, 버전 관리(SemVer)를 통해 변경 범위를 명확히 인지할 수 있다는 장점이 있습니다. 이런 특징은 디자인 시스템 업데이트 시 특정 프로젝트에 영향을 미칠 수 있는 변경 사항을 사전에 제 어하는 데에도 큰 도움이 된다고 생각했습니다.
또한 npm publish 방식은 CI/CD와의 궁합이 뛰어나 GitHub Actions를 활용한 자동 빌드·배포 파이프라인 구성이 용이합니다. 이를 통해 컴포넌트 변경 → 테스트 → 빌드 → 배포까지의 과정을 자동화할 수 있습니다. 결과적으로 디자인 시스템을 지속적으로 업데이트 할 수 있는 기반이 됩니다.
B2B·B2C 디자인 시스템의 figma 파일 분리
디자인 시스템과 실제 서비스 UI를 명확히 분리하기 위해 디자인 파일은 크게 두 가지 축으로 관리합니다. B2C 외부 고객사의 작업물은 NUVION 디자인 시스템과는 별개의 디자인 시스템을 새로 구성해야 하는 경우가 많기 때문입니다.
1. B2B Design System
B2B 디자인 시스템 파일은 외부 고객사 및 내부 서비스인 Nuvion 전반에서 공통으로 사용하는 표준 UI 자산을 관리하기 위한 공간입니다. 버튼, 입력 필드, 아이콘, 타이포그래피와 같은 기본 컴포넌트뿐만 아니라 여러 프로젝트에서 반복적으로 사용되는 패턴을 중심으로 구성합니다.
이 파일에는 실제 서비스 화면이나 프로젝트별 UI 시안은 포함하지 않으며, 오로지 디자인 시스템 자체와 그 사용 가이드, 샘플 컴포넌트만을 관리합니다. 이를 통해 외부 프로젝트가 늘어나더라도 공통된 기준을 유지할 수 있으며, 디자이너와 개발자 모두가 동일한 기준점에서 작업을 시작할 수 있도록 합니다.
또한 B2B 특성상 클라이언트마다 요구사항이 다를 수 있기 때문에 디자인 시스템은 확장 가능한 구조로 설계하되 핵심적인 UI 원칙과 스타일은 고정된 표준으로 유지하는 것을 목표로 했습니다.
파일 내 페이지는 컴포넌트 구현 순서와 복잡도에 따라 foundation, basic, complex로 구분하여 구성했습니다.
foundation 페이지에는 컬러, 타이포그래피, 아이콘과 같이 디자인 시스템의 기반이 되는 요소들을 정리했습니다. 이 단계는 이후 모든 컴포넌트가 참조하는 기준이 되는 영역으로, 디자인 토큰과 시각적 규칙을 명확히 정의하는 데 초점을 맞췄습니다.
basic 페이지에는 버튼, 로딩, 체크박스처럼 다른 컴포넌트와 합성되지 않는 단일 컴포넌트를 중심으로 구성했습니다. 각각의 컴포넌트는 독립적으로 사용 가능하도록 설계하여 다양한 상황에서 유연하게 재사용할 수 있도록 했습니다.
complex 페이지는 basic 컴포넌트들이 조합되어 완성되는 구조의 컴포넌트들로 구성했습니다. 예를 들어 드롭다운, 모달, 내비게이션과 같이 여러 단일 컴포넌트가 함께 동작하는 UI를 이 영역에서 관리하며 컴포넌트 간의 역할과 책임을 명확히 구분하는 것을 목표로 했습니다.
2. B2C Design System
B2C 디자인 시스템은 B2B와는 다른 방향의 관리 전략을 취합니다. B2C 프로젝트는 서비스별 브랜드 아이덴티티와 사용자 경험이 더욱 중요하게 작용하기 때문에 B2B 디자인 시스템과 동일한 기준을 그대로 적용하기 어렵다고 판단했습니다.
이에 따라 B2C 프로젝트의 경우 B2B 디자인 시스템과는 별도의 디자인 시스템 파일을 생성하여 관리하여 서비스 특성에 맞춘 컴포넌트 변형과 확장이 가능하도록 설계했습니다.
이러한 구조는 B2C 프로젝트마다 서로 다른 디자인 요구사항을 유연하게 수용하면서도 프로젝트 내부에서는 일관된 규칙과 기준을 유지할 수 있도록 합니다.
디자인 시스템 컴포넌트 구성 순서
B2B 디자인 시스템은 다음과 같은 순서로 설계 및 구현합니다.
Foundation
color → font → icon
Basic
loading → button → stepper → link → checkbox → text_field → text_area → notice → avatar → chip → pagination → header → toast → toggle → skeleton
Complex
lnb → gnb → bottom_tab → dropdown → menu → modal → popup → table → date range picker
table, chart, date range picker의 경우 라이브러리 사용 가능성이 높아 초기 디자인 시스템 범위에서는 제외했습니다.
디자인 시스템 설계 기준: 타이포그래피
타이포 네이밍 규칙
타이포그래피는 디자인 시스템에서 가장 빈번하게 사용되는 요소 중 하나이기 때문에 네이밍 규칙을 명확하게 정의했습니다.
네이밍에는 텍스트 크기 정보를 반드시 포함합니다.
형식은 다음과 같습니다.
사이즈정보_굵기약자_픽셀값
예:head1_b_36,title2_r_32
사이즈 체계는 다음과 같이 정의합니다.
head > title > body > caption동일한 카테고리 내에서는 숫자가 작을수록 크기가 큽니다.
(예:head1>head2)
또한 행간과 자간은 퍼센트 단위가 아닌 픽셀(px) 단위로만 정의하여 개발 단계에서의 해석 차이를 최소화했습니다.
디자인 시스템 설계 기준: 아이콘 시스템
아이콘은 크기별로 나누어 관리하지 않습니다.
기본 크기는 24px로 통일하며 별도의 사이즈 variant는 만들지 않습니다. 크기 조절은 개발 단계에서 props로 처리합니다.
아이콘 네이밍 규칙
숫자를 사용하지 않습니다.
여백이나 방향 구분이 필요한 경우 언더스코어를 사용합니다.
예:
ic_arrow_left
추후 filled 스타일 아이콘이 추가될 가능성을 고려하여 outline과 filled를 분리할 수 있는 구조로 설계해 두었습니다.
디자인 시스템 설계 기준: 컬러 시스템
컬러 네이밍에는 회사명이나 위계를 포함하지 않습니다.
이는 여러 기업의 외부 프로젝트를 동시에 진행하는 환경에서 컬러 코드 중복과 의미 충돌을 방지하기 위함입니다.
컬러는 용도가 아닌 색상 이름 기준으로 명명합니다.
투명 컬러의 경우
_t_를 중간에 추가합니다.
예:indigo_100,indigo_t_90
컬러는 기본적으로 50~900까지 10단계로 정의하며 필요하지 않은 단계는 생략할 수 있습니다.
또한 non-transparent 컬러와 transparent 컬러를 원칙적으로 함께 정의하고, 그라디언트 역시 디자인 시스템에 포함합니다.
마치며
이번 글에서는 디자인 시스템을 왜 필요로 했는지, 그리고 그 필요를 해결하기 위해 어떤 구조와 기술 스택을 선택했는지를 중심으로 정리했습니다. vanilla-extract, Vite, npm 기반 배포 전략, 아이콘과 토큰 설계, Storybook 도입까지 모두 “여러 프로젝트에서 안정적으로 재사용할 수 있는 기준을 만드는 것”이라는 하나의 목표를 기준으로 선택한 결과였습니다.
무엇보다 설계 과정에서 가장 중요하게 생각했던 점은 빠르게 만들고 나중에 고치는 시스템이 아니라 처음부터 유지보수와 확장을 고려한 구조를 만드는 것이었습니다. 초기에는 다소 시간이 걸리더라도 명확한 기준과 일관된 구조가 이후의 개발 속도와 협업 효율을 크게 높여줄 것이라고 믿고 있습니다.
다음 글에서는 실제로 디자인 시스템 컴포넌트를 구현하면서 겪었던 고민과 선택들, 그리고 버튼·로딩과 같은 핵심 컴포넌트를 어떻게 설계했는지에 대해 좀 더 구체적으로 다뤄볼 예정입니다. 디자인 시스템 도입을 고민하고 계신 분들께 이 기록이 작은 참고 자료가 되기를 바랍니다.