패턴 라이브러리: 재사용이 일관성을 만든다Design Pattern Libraries: Build Once, Use Everywhere
컴포넌트 기반 패턴 라이브러리 구축의 이점과 시작 방법, 디자인 시스템과의 관계를 설명합니다.What a design pattern library is, why it's different from a component library, and how to build one that actually gets used.
- 왜 일관성이 사용성인가
- 작게 시작하는 법
- 운영이 구축보다 어렵다
- 도구: 피그마에서 스토리북까지
- 토큰: 라이브러리의 헌법
- Pattern vs. component
- What to include
- Making patterns get used
버튼을 매번 새로 그리는 팀과 만들어 둔 버튼을 가져다 쓰는 팀의 격차는 시간이 지날수록 벌어집니다. 패턴 라이브러리는 자주 쓰는 UI 요소(버튼, 입력란, 카드, 모달, 테이블)를 표준화해 모아 둔 재사용 가능한 부품 창고입니다. 일관성과 속도를 동시에 얻는, 비용 대비 효과가 가장 확실한 투자입니다.
왜 일관성이 사용성인가
같은 기능이 화면마다 다르게 생기면 사용자는 매번 다시 학습해야 합니다. 어떤 화면에서는 파란 버튼이 저장이고 다른 화면에서는 초록 버튼이 저장이라면, 제품 전체가 낯선 곳이 됩니다. 패턴이 통일되면 한 번의 학습이 제품 전체에 적용되고, 사용자는 인터페이스가 아니라 자신의 일에 집중할 수 있습니다. 개발 측면에서도 같은 컴포넌트의 재사용은 버그 감소와 유지보수 비용 절감으로 직결됩니다.
작게 시작하는 법
거창한 디자인 시스템부터 시작할 필요는 없습니다. 1단계는 인벤토리입니다. 현재 제품의 모든 버튼을 캡처해 한 페이지에 모아 보세요. 미묘하게 다른 버튼이 수십 종 발견될 것입니다. 2단계는 통합입니다. 그중 살아남을 표준형을 정하고(주요/보조/위험, 3가지 크기 정도) 나머지를 폐기합니다. 3단계는 토큰화입니다. 색상, 간격, 모서리, 그림자를 변수로 정의해 컴포넌트들이 같은 기초 위에 서게 합니다. 버튼, 입력란, 카드 세 가지만 표준화해도 화면의 80%가 정돈됩니다.
운영이 구축보다 어렵다
라이브러리는 만든 날부터 낡기 시작합니다. 새 패턴이 필요할 때 기존 패턴으로 해결할 수 없는지 먼저 검토하는 절차, 예외를 허용하는 기준, 변경 사항을 전파하는 채널이 없으면 라이브러리는 곧 장식이 됩니다. 도구보다 합의가 중요합니다. 디자이너와 개발자가 같은 이름으로 같은 부품을 부르는 것, 그것이 살아 있는 패턴 라이브러리의 징표입니다.
오늘 할 수 있는 일은 하나입니다. 제품의 버튼 인벤토리를 만들어 보세요. 그 한 장의 충격적인 스크린샷이 시스템화의 가장 강력한 설득 자료가 됩니다.
도구: 피그마에서 스토리북까지
패턴 라이브러리의 양대 거점은 디자인과 코드입니다. 디자인 쪽에서는 피그마의 컴포넌트와 배리언트로 상태(기본/호버/비활성)와 크기 변형을 한 부품에 담고, 팀 라이브러리로 게시해 모두가 같은 부품을 쓰게 합니다. 코드 쪽의 표준은 스토리북(Storybook)입니다. 컴포넌트를 독립된 환경에서 모든 상태로 열람·테스트할 수 있어, 디자이너와 개발자가 '살아 있는 카탈로그'를 공유하게 됩니다. 두 거점의 컴포넌트 이름을 일치시키는 것이 협업 효율의 핵심입니다.
토큰: 라이브러리의 헌법
컴포넌트가 패턴 라이브러리의 시민이라면 디자인 토큰은 헌법입니다. 색(--color-accent), 간격(--space-4), 모서리(--radius-md), 그림자(--shadow-2), 폰트 크기(--text-lg)를 변수로 정의하고 모든 컴포넌트가 이를 참조하게 만들면, 브랜드 색 변경이나 다크 모드 같은 전면적 변화가 변수 몇 줄의 수정으로 끝납니다. 이 사이트의 디자인 위자드가 내보내는 CSS 변수·JSON 토큰이 바로 이 구조의 출발점입니다. 작게 시작하더라도 토큰부터 시작하세요.
A design pattern library is a documented collection of reusable solutions to recurring UI problems. Not just components (a button), but patterns (a form validation flow, an empty state, a pagination control). It answers the question: "what's the right way to do X in our product?" — so every designer and developer doesn't have to answer it from scratch.
Pattern vs. component
Components are the atoms: button, input, badge, avatar. Patterns are the molecules: how a button and input combine in a search bar; how a badge and avatar combine in a notification item; how multiple components combine to solve a specific user need. Component libraries answer "what building blocks do we have?" Pattern libraries answer "how do we build this kind of experience?"
What to include
Start with the highest-frequency, highest-variance patterns in your product — the ones where designers currently make different choices. Common candidates: empty states (no data, no results, no connection), error and success feedback, loading states, form layouts, modal/sheet usage rules, data table patterns. Document: the pattern name, when to use it, when not to use it, the component recipe, an example, and accessibility notes.
Making patterns get used
A pattern library that isn't consulted is shelfware. Embed patterns in the workflow: link to the relevant pattern directly in design review, reference patterns in code review, update patterns when you discover a better solution. The goal is that "check the pattern library first" becomes team reflex, not extra work.
Pattern libraries reduce decision fatigue, onboarding time, and consistency failures simultaneously. The ROI compounds — every pattern you document pays dividends every time someone would otherwise have reinvented it.