우리 팀만의 디자인 라이브러리 제작기 #2
디자인 일관성을 찾아가는 여정
지난 글에서는 컬러 시스템과 텍스트 스타일을 어떻게 체계화했는지 다뤘는데요. 이제 기본적인 스타일 토큰들이 정리되었으니, 본격적으로 실제 화면에서 사용할 컴포넌트들을 만들어야 할 차례였어요.
제작 방식과 접근법 (2)
컴포넌트 구축하기
사실 처음에는 컴포넌트를 어떤 기준으로 나누어야 하는지조차 몰라서, 우선 가장 자주 사용하는 버튼부터 만들어보기 시작했어요.
지금까지 진행했던 프로젝트들을 돌아보면서 많이 사용했던 컴포넌트가 무엇인지 파악해나갔는데, 탭 컴포넌트에서 문제가 생겼어요. 탭은 내부에 다수의 탭 요소가 모여서 하나의 완성된 컴포넌트가 되는 구조인데, 내부 아이템을 정의하지 않고 탭 전체를 덩어리로만 만들다 보니 디자인을 수정할 때 매번 다시 만들어야 했는데요.
이 과정에서 관련 자료를 찾아보다가 아토믹 디자인(Atomic Design) 방법론을 알게 되었는데, 우리 상황에 도움이 될 것 같다는 생각이 들었어요.
출처: https://atomicdesign.bradfrost.com/chapter-2/아토믹 디자인은 Brad Frost가 제안한 UI 설계 방법론인데요. 고등학교 화학 시간에 배운 원자 구조에서 영감을 받아 UI를 작은 단위로 쪼개어 점진적으로 쌓아 올리는 구조적 접근법이에요. UI를 역할과 복잡도에 따라 5단계 계층 구조로 나누는데, 해당 구조는 다음과 같아요.
- Atoms(원자): 버튼, 입력필드, 레이블 등 더 이상 쪼갤 수 없는 기본 요소
- Molecules(분자): 여러 원자가 결합해 특정 기능을 수행하는 작은 구성 요소
- Organisms(유기체): 분자 및 원자가 결합해 UI의 한 영역을 구성하는 구조
- Templates(템플릿): 유기체를 배열해 레이아웃을 구성한 뼈대
- Pages(페이지): 템플릿에 실제 데이터를 적용한 최종 화면
출처: https://atomicdesign.bradfrost.com/chapter-2/이 방법론은 작은 구성 요소와 전체 구조 모두를 동시에 고려할 수 있게 도와주는데요. 우리가 만든 컴포넌트를 보니 Molecule 단위가 많았고, 그 안의 Atom 요소를 따로 정의해두면 재활용성이 높아질 것 같았어요.
하지만 Organism 단위까지 만들어두기엔 문제도 있었습니다. 우리는 한 프로젝트에만 쓸 라이브러리가 아니라 여러 프로젝트에서 활용해야 했는데, 너무 구체적인 레이아웃이나 사용 흐름이 고정되어 버릴 위험이 있을 것 같았어요.
위 예시는 Organism 단위의 대표적인 컴포넌트인 ‘카드’예요(보기 쉽게 캐러셀 형태로 구성했어요). 같은 유형의 컴포넌트지만 서비스 성격에 따라 완전히 다른 정보 구조와 사용자 경험을 제공해야 하는데요. 쇼핑몰에서는 하나의 대표 상품 이미지로 상품을 직관적으로 보여주고, 가격 할인 정보 및 별점, 후기 수가 구매 결정에 핵심적인 역할을 해요. 반면 부동산 매물 카드는 방 구조나 인테리어를 자세히 확인할 수 있도록 슬라이드 형태로 여러 이미지를 제공해야 하고, 보증금과 월세 같은 금액 정보, 정확한 주소와 집 상세 설명이 가장 중요한 콘텐츠가 되죠.
이처럼 같은 컴포넌트라도 이미지 표시 방식부터 핵심 정보, 사용자 행동 패턴까지 사용자 플로우를 깊이 고려해 설계해야 하는 복합적인 구조들은 특정 프로젝트에는 완벽하게 맞아떨어질 수 있지만, 다른 프로젝트에 그대로 적용하기엔 오히려 제약이 되는 경우가 많았어요.
반면 Atom이나 Molecule 단위는 더 추상적이고 범용적인 요소들이라, 어느 프로젝트든 조립해서 쓸 수 있는 여지가 크다고 느꼈어요. 그래서 일단은 고정된 컴포넌트를 만들기보다는 유연하게 조합할 수 있는 재료를 중심으로 구성하는 쪽을 선택했습니다.
컴포넌트 프로퍼티 구조화하기
처음에는 컬러를 나누는 것부터 시작했어요. 첫 컴포넌트였던 버튼은 스타일이 다양하니까, 제일 먼저 눈에 띄는 컬러부터 Variant로 분리한 거죠. 그런데 컴포넌트가 늘어나면서, 속성을 필요한 대로 추가하다 보니 기준이 애매해지고 마구 섞여있는 느낌이 들었어요.
그래서 속성을 크게 세 가지 그룹으로 묶어서 구조를 잡아봤는데요.
이렇게 그룹을 나눈 이유는 새 컴포넌트를 만들 때 속성의 성격을 빠르게 분류할 수 있고, 팀원들이 구조를 직관적으로 이해할 수 있기 때문이에요. 또 세 그룹 자체는 그대로 유지하면서 그룹 안에 들어가는 세부 속성은 컴포넌트 종류에 따라 확장하거나 변경할 수 있어서 유연성도 확보되고요.
덕분에 예전처럼 뒤죽박죽 섞인 속성들 속에서 헤매지 않아도 되고, 새 컴포넌트를 만들 때도 “이건 어떤 그룹에 들어갈까?”부터 생각하게 되었어요. 기준이 잡히니까 작업 과정이 훨씬 수월해지고, 전체 라이브러리의 일관성도 자연스럽게 유지할 수 있었어요.
설계할 땐 몰랐던 사용의 현실
문제는 ‘잘 만드는 것’만으로는 충분하지 않다는 점이었어요.
막상 프로젝트에 적용해보니 당황스러운 상황들이 벌어졌어요. 분명 버튼 컴포넌트에 color variant를 만들어뒀는데, 어떤 팀원은 버튼을 가져다 쓰면서 색상을 직접 바꾸고 있더라고요. Variant로 간단히 전환할 수 있는 상황임에도 fill color를 일일이 수정하는 식으로 말이에요. 라이브러리는 '잘 만드는 것'만큼이나 '잘 사용되게 만드는 것'이 중요하다는 걸 깨달았습니다. 컴포넌트를 아무리 체계적으로 설계해도 사용법이 직관적이지 않거나 구조를 제대로 공유하지 않으면, 결국 팀원들은 본인이 편한 방식대로 작업하게 되거든요.
우리 팀에는 ‘러닝쉐어’라는 지식 공유 프로그램이 있는데요. 꼭 업무 관련 주제가 아니더라도, 개인이 습득한 인사이트나 경험을 팀원들과 자유롭게 나누는 시간이에요. 저도 이 기회를 활용해서 디자인 라이브러리 관련 러닝쉐어 세션을 열었어요. 세션에서 다룬 내용은 다음과 같았어요.
세션을 위해 제작했던 자료1) 라이브러리 구조 이해하기
- 파일이 어떻게 구성되어 있는지
2) 올바른 사용법
- 프로퍼티가 어떻게 나뉘어져 있는지
- 컴포넌트를 어떻게 가져오고 Variant 기능을 어떻게 활용해야 하는지
3) 확장 및 수정 가이드
- 새로운 컴포넌트가 필요할 때 어떤 절차를 거쳐야 하는지
- 기존 컴포넌트를 수정해야 할 때의 원칙
러닝쉐어 세션 이후로 아직 새로운 프로젝트가 시작되지 않아서, 이런 공유가 실제로 얼마나 효과적이었는지는 확인하지 못했는데요. 하지만 라이브러리가 단순히 '만들어진 것'이 아니라 '함께 사용하는 것'이라는 인식을 공유할 수 있었던 것 같아요.
라이브러리의 지속적인 발전을 위해
앞으로는 프로젝트가 끝날 때마다 라이브러리 사용 현황을 점검하는 루틴을 만들어 발전시켜 나가려고 해요.
사실 예전에 한 번, 프로젝트 종료 후 회고 자리에서 비슷한 시도를 해본 적이 있었어요. 그때 팀원들이 “이 컴포넌트에 이런 기능이 추가되면 좋겠다” 같은 피드백을 주더라고요.
회고 내용 정리 중 일부텍스트 버튼 variant를 늘려달라거나, 아이콘 종류를 더 다양하게 추가해달라는 요청이 있었는데요. 그래서 실제로 해당 요청들을 반영해 업데이트를 진행했고, 결과적으로 라이브러리가 조금 더 쓰기 편해졌어요.
앞으로는 이런 과정을 정기적으로 운영해서, 프로젝트가 끝날 때마다 팀원들의 피드백을 수집하고 개선에 반영하려고 해요. 결국 라이브러리를 매일 사용하는 사람들의 경험이 가장 정확한 개선 방향을 알려주니까요.
지금까지 UX 컨설팅 팀이 디자인 라이브러리를 만들게 된 과정과, 그 안에서 겪은 시행착오 및 배운 점을 정리해봤어요.
저희 방식이 절대적인 정답은 아니지만, 비슷한 상황에 있는 분들에게 하나의 참고 사례가 되었으면 합니다.
읽어주셔서 감사합니다!
