우리 팀만의 디자인 라이브러리 제작기 #1
디자인 일관성을 찾아가는 여정
저희 팀은 UX/UI 에이전시 내에서 UX 컨설팅을 전문으로 하는 팀이에요. 일반적인 업무 프로세스상 GUI까지 완성하기보다는 와이어프레임 단계에서 마무리하는 경우가 많은데요. 대신 Low-fidelity 수준의 단순한 선 그림이 아니라, 디자인이 어느 정도 입혀진 Hi-fidelity 수준의 와이어프레임을 제작해요. 클라이언트 입장에서는 최종 결과물에 대한 이해도가 높아지고, 프로젝트 진행 과정에서 소통도 훨씬 원활해지죠.
하지만 여기서 문제가 발생했어요. 에이전시 특성상 매번 새로운 클라이언트, 새로운 프로젝트를 진행하다 보니 구체적으로 정립된 디자인 시스템이 존재하지 않았어요. 각 컨설턴트가 개인의 센스와 스타일로 화면을 그리다 보니, 같은 서비스 내에서도 화면마다 스타일이 제각각이었어요. 버튼 하나를 예로 들어도, A는 둥근 모서리의 버튼을, B는 각진 버튼을, C는 또 다른 스타일의 버튼을 사용하는 식이었죠.
결국 프로젝트 막바지에 스타일 통일 작업이 필수가 되었습니다. 각자 다르게 그린 화면들을 하나의 일관된 룩앤필로 맞추는 작업 말이에요. 이 과정에서 꽤 많은 시간이 소요되었고, 때로는 이미 완성된 화면을 거의 새로 그려야 하는 경우도 있었어요.
"이런 식으로 계속 작업하면 안 되겠다"는 공감대가 팀 내에서 형성되기 시작했어요.
라이브러리 제작을 결정한 이유
작업 효율성 개선
가장 직접적인 목표였어요. 매번 새로운 버튼, 입력 필드, 카드 컴포넌트를 만드는 대신, 기존에 만들어둔 컴포넌트를 재사용할 수 있다면 작업 속도가 훨씬 빨라질 것이라고 예상했어요.
팀 협업의 질 향상
"이 버튼은 어떤 스타일로 할까요?" "이 입력 필드 크기는 어떻게 할까요?" 같은 반복적인 소통을 줄이고, 더 본질적인 UX 논의에 집중할 수 있을 것이라고 기대했어요.
클라이언트 만족도 증대
결과적으로는 더 완성도 높은 결과물을 더 빠른 시간 내에 제공할 수 있게 되어, 클라이언트 만족도도 자연스럽게 향상되리라 예상했어요.
일단 작은 단위의 컴포넌트 라이브러리부터 만들어보자!
거창한 디자인 시스템을 처음부터 구축하기보다는, 실제로 자주 사용하는 기본 컴포넌트들부터 체계화해 보기로 했습니다. 버튼, 입력 필드, 카드 같은 기본적인 요소들 말이에요.
완벽하지 않더라도 시작해 보고, 실제 사용하면서 점진적으로 개선해 나가자는 마음가짐이었어요.
제작 방식과 접근법 (1)
가장 먼저 한 일은 인터넷 검색이었어요. "다른 에이전시들은 어떻게 디자인 라이브러리를 만들고 있을까?" 하고 찾아봤는데, 관련 자료가 많이 나오지 않더라고요. 결국 맨땅에 헤딩을 할 수밖에 없었습니다. 대신 기존의 유명한 회사들의 디자인 시스템을 참고하며 피그마 내에서 라이브러리 구조를 설계해 보기로 했어요.
재사용 가능한 컬러 시스템
우리가 컬러 시스템을 정리할 때 가장 먼저 고민한 건 프로젝트마다 달라지는 브랜드 컬러를 어떻게 유연하게 관리할 수 있을까였어요. 에이전시 특성상 하나의 브랜드에 고정되는 게 아니라, 매번 새로운 프로젝트에 맞춰 primary 컬러가 바뀌니까요. 고정된 컬러셋을 유지하기보다는, 컬러 시스템 자체를 유동적으로 변경할 수 있는 구조가 필요했어요.
그래서 Figma의 Variables 기능을 기반으로 디자인 토큰을 세 단계로 분리했어요.
1. Color Palette
가장 기본이 되는 색상값들을 담은 단계예요.
모든 프로젝트에서 공통으로 사용되는 그레이 컬러 세트, 그리고 프로젝트의 브랜드 메인 컬러(당시에는 블루)를 이 단계에서 정의했어요.
명도 기준으로 blue-50, blue-100, blue-200처럼 네이밍했고, 나중에 다른 프로젝트에 들어가게 되면 해당 컬러만 교체하면 되는 구조예요.
2. Primitive Token
UI 요소에 직접 매핑되지는 않지만, 컬러의 역할을 대략적으로 추상화해서 정리하는 단계예요. (e.g. primary color, alert color 등)
이 단계는 컬러의 성격이나 용도(중요한 버튼, 경고 메시지 등)에 따라 토큰을 정의하고, 이 토큰들이 palette의 색상값을 참조하도록 구성했어요.
중요한 건 이 단계에서 브랜드 컬러가 어떤 역할을 하는지 결정된다는 거예요. 예를 들어 현재 프로젝트의 메인 컬러가 파랑이라면 primary-color = blue-500, 다음 프로젝트에선 primary-color = green-500으로만 바꿔주면 전체 시스템이 따라오게 돼요.
3. Semantic Token
가장 구체적인 단계로, 실제 UI 요소에 쓰이는 컬러들이 이 단계에서 정의돼요. (e.g. background-primary, border-focus, icon-disabled 등)
이 단계는 UI 구조와 직접 연결되기 때문에, 팀원 모두가 공통된 언어로 소통할 수 있게 도와줘요.
Semantic Token은 Primitive Token을 참조하기 때문에, 프로젝트가 바뀌더라도 구조를 바꿀 필요 없이 자동으로 컬러가 반영돼요.
프로젝트마다 컬러는 바뀌지만, 구조는 그대로 가져갈 수 있다는 점이 이 시스템의 가장 큰 장점이에요. 아직 여러 프로젝트에 충분히 적용해보진 않았지만, 앞으로 더 다양하게 확장해보며 실제 효과도 확인해볼 예정이에요.
사용 맥락으로 나눈 텍스트 스타일
프로젝트마다 디자인 톤이 조금씩 달라지다 보니, 텍스트 스타일도 유연하게 가져갈 수 있어야 했어요. 하지만 반대로 너무 많은 스타일을 만들면 관리가 힘들고, 협업 시 혼란이 생길 수 있다는 점도 고민이었어요.
우선 역할에 따라 분류 체계를 만드는 것부터 시작했어요. 정보 구조 및 사용 맥락에 따라 다섯 가지 섹션으로 나누었는데요.
Display: 히어로 영역이나 브랜드 강조에 쓰이는 가장 큰 스타일
Heading: 본문 내 주요 제목이나 섹션 타이틀용
Body: 일반적인 본문, 설명, 리스트 등의 기본 텍스트
Caption: 보조 정보나 부연 설명처럼 작은 텍스트
Compact: 버튼, 테이블 등 좁은 행간에 최적화된 스타일
각 섹션 안에서는 굵기(weight)와 사이즈를 조합해 여러 단계로 나눴고, 스타일 이름도 섹션, 단계, 굵기, 사이즈가 한눈에 보이도록 네이밍 했어요.
이렇게 만들다 보니 스타일 수가 꽤 많아졌는데요. 특히 Body 계열은 굵기와 크기를 조합해서 무려 11종이나 되어버렸어요. 처음엔 팀원 요청에 따라 전부 추가했는데, 정리하고 나니 ‘너무 많지 않나?’하는 고민이 남았어요.
그래서 최근에는 실제 사용 빈도와 역할을 기준으로 통합하거나, 예외 스타일은 별도 관리하는 방식을 고민 중인데요. 이렇게 하나씩 다듬어가면서 더 실용적이고 가벼운 구조로 정리하는 걸 목표로 하고 있습니다.
아직 완성형은 아니지만, 적어도 '매번 새로 만드는' 비효율성은 많이 줄어들었어요.
물론 아직 개선할 부분들이 많지만, 하나씩 다듬어가면서 더 실용적인 시스템으로 만들어갈 예정이에요. 컬러와 텍스트 기반을 다진 후에는 본격적으로 컴포넌트 라이브러리 구축에 들어갔는데요. 어떤 기준으로 컴포넌트를 설계했는지, 그리고 실제 프로젝트에 적용하면서 어떤 문제들이 생겼는지에 대한 이야기는 다음 편에서 계속하겠습니다.
읽어주셔서 감사합니다.
