Background

29CM은 고객의 라이프스타일을 반영한 최적의 상품을 발견하고 추천하는 온/오프라인 셀렉트숍입니다. 12년의 운영 기간 중, 최근 6년간은 가설과 데이터를 중심으로 한 의사결정 문화로 전환하며 눈에 띄는 성장을 이루었습니다. 그러나 오랜 시간 동안 축적된 레거시와 디자인 및 코드의 파편화는 팀원들의 피로도를 높였고, 디자인 시스템 Task Force(이하 RulerTF)에 할당된 리소스는 제한적이었습니다. 이에 따라 선택과 집중, 그리고 실행 속도가 특히 중요했습니다.

---

파편화로 인한 협업의 문제

29CM 내에서 디자인과 코드의 파편화 정도는 실제 서비스 화면과 프로덕트 디자이너들의 Figma 작업을 통해 쉽게 확인할 수 있습니다. 아래 이미지는 29CM에서 사용되는 다양한 Alert Dialog로 UI 파편화 사례를 보여줍니다.

사례 : 29CM에서 사용되고 있는 Alert Dialog UI 케이스들

이전에 저는 SEED 디자인 시스템에서의 경험을 통해, 일관성 결여가 사용자에게 불필요한 UI 재학습을 요구하고 서비스 질을 저하시키는 주요 원인임을 알고 있었습니다.

이 문제는 외부 사용자뿐만 아니라 내부적으로도 지속적인 커뮤니케이션과 높은 개발 비용으로 이어지는 문제를 야기합니다. 29CM 역시 같은 문제를 겪고 있음을 알 수 있었습니다.

일관성 관리 부재로 인한 디자이너와 개발자의 피로도

실제로 디자이너, 개발자 대상으로 인터뷰를 진행한 결과, 화면 구성 & 핸드오프 - 구현 과정에서 높은 피로도를 경험하고 있음을 확인할 수 있었습니다.

이에 따라, 디자이너와 개발자가 직면한 비효율적인 문제들을 해결하기 위해 필요한 도구와 역할을 정의하였고, 이를 기반으로 29CM의 디자인 시스템을 개발하는 데 필요한 작업(Task)들을 확정했습니다.

디자이너와 개발자의 니즈	제공할 도구 및 역할
정의된 UI를 통한 불필요한 UI 논의 및 회의 시간 감소	명확한 인터페이스 정의
명확한 가이드를 통한 개발 비용 절감	지원되는 동작과 스타일에 대한 스펙 정의
컨텍스트 스위칭 감소	채널 일원화
디자인 및 개발 경험 향상	표준으로 삼을 수 있는 컴포넌트 퀄리티
서비스 디자인 및 코드 퀄리티 향상	프로덕트 조직과 플랫폼 공통의 역할
고객에게 보다 좋은 사용성 제공	프로덕트 조직과 플랫폼 공통의 역할

---

문제를 더 빠르게 해결할 수 있는 환경만들기

일관성을 통해 구성원의 피로도를 감소하기 위해서는 우선 디자인 시스템이 제공되어야 하기 때문에 빠르게 Component를 제작하는 것은 무엇보다 중요했습니다.

하지만 디자인 시스템을 개발하는 과정은 많은 논의와 동기화를 필요로 합니다. iOS, Android, FE 개발자들의 리소스가 한정된 상황이였기 때문에 빠르고 효과적으로 디자인 시스템을 제공하기 위해서는 사전에 명확한 제작 원칙과 실행 방향성이 필요하다 생각했습니다.

기능과 로직, 스타일을 독립적으로 관리하기

분리된 관심사의 원칙 : 디자인 시스템 제작에 있어서 컴포넌트의 유연성 그리고 일관성은 필수적인 고려사항입니다. 팀에서 기능과 로직(Headless¹), 시각적인 부분(Design Token)을 각각 독립적으로 정의하고 관리하는 방식에 대해서 공유하여 빠르게 방향성을 맞출 수 있었습니다.

FE의 경우,복잡한 상태 관리 부분은 Ark-ui²에 위임하여 각각 조직에 필요한 디자인 토큰 정의와 컴포넌트 구현에 더 집중할 수 있었습니다.

논의의 집결지 : 디자인, iOS, Android, FE 등 다양한 플랫폼에 컴포넌트를 제공해야 하는 상황에서, 각 플랫폼과 사용 상황을 고려한 수많은 논의와 디자인 및 구현 결정이 필요합니다.

각 플랫폼 담당자와 사용처 간 1:N 관계에서 결정된 사항들을 채널 분산 없이 효과적으로 공유하기 위해, 모든 논의가 집결되는 SSOT(Single Source Of Truth) 문서의 필요성을 느꼈습니다. 이런 문서 작업은 종종 속도 측면에서 경시되지만, 실제로는 다음과 같은 중요한 기능을 수행합니다:

• 세부적인 결정 사항이 유지된다.
• History가 보존된다.
• 명확한 사용 지침과 Spec 정의를 제공한다.
• 정보 불일치로 인한 커뮤니케이션 문제, 비효율성, 오류를 감소시킨다.
• 내부 구성원과 최종 사용자에게 제작 과정을 이해하는 데 도움이 되는 로드맵을 제공한다.
• 확인이 필요한 모든 정보의 단일 창구 역할을 한다.
• 플랫폼 개발자와 디자이너 간의 커뮤니케이션 비용을 절감한다.

Ruler SSOT는 서버 주도 UI(Server-Driven UI, SDUI) 방식을 채택하여 관리되므로, 디자이너가 직접 SSOT 문서를 작성, 수정, 배포할 수 있고, 웹이나 모바일 앱과 같은 다양한 클라이언트에 일관된 내용을 제공할 수 있습니다. 이를 통해 컴포넌트 정의와 제작 과정에서 속도와 효율성을 크게 향상시킬 수 있었습니다.

또한 필요한 모든 컴포넌트를 목록화하고, 각 플랫폼 작업자별로 작업을 할당하여 컴포넌트 제작의 진행 상황을 추적할 수 있도록 체계적으로 관리했습니다. 이런 방식으로 정형화된 제작 프로세스를 마련함으로써 토론해야 할 주제의 범위를 좁힐 수 있었고, 과정 중에 발생할 수 있는 혼란을 방지하여 제작 팀이 보다 안정적으로 작업을 진행할 수 있는 환경을 조성할 수 있었습니다.

Ruler SSOT가 궁금하시다면 Ruler SSOT 보러가기 →

---

측정 가능한 환경 만들기

디자인 시스템은 장기적으로 서비스의 성장과 함께 발전해야 하는 지속 가능한 제품입니다. 이에 그 가치를 지속적으로 측정하고 개선할 수 있는 체계를 마련하는 것이 필수적입니다.

현재 컴포넌트들은 신속하게 제작되어 안정적으로 배포되고 있지만, 실제로 얼마나 제작되었는지, 또한 구성원들의 생산성과 효율성을 실질적으로 어떻게 향상시키는지는 명확히 알 수 없습니다. 제작자와 사용자 모두에게 이러한 효과가 명확하게 드러나지 않는다면, 해결해야 할 문제의 본질을 파악하기 어렵습니다.

컴포넌트는 사용되는 순간부터 디자이너와 개발자의 효율성을 증가시킵니다. 이미 구현된 요소를 재사용함으로써 발생하는 디자인과 개발의 초기 비용을 크게 줄일 수 있기 때문입니다.

이러한 점을 고려할 때, 한 화면당 프레임 총 수에서 사용된 컴포너트의 갯수(중복 제외)의 비율을 통해서 Ruler가 제공하는 순수한 생산성을 나타낼 수 있습니다. 이는 Ruler를 통해 기존의 작업했어야 할 초기 디자인 및 개발 비용을 얼만큼 줄일 수 있었는지를 수치화합니다.

반면, 한 화면당 프레임 총 수에서 사용된 전체 컴포너트의 갯수(중복 포함)의 비율을 통해서 Ruler가 얼만큼 일관성을 제공하고 있는지 나타냅니다. 이 수치는 컴포넌트가 화면을 얼마나 잘 채우고 있는지, 디자인의 일관성을 얼마나 유지하고 있는지를 측정하는 지표로 활용됩니다.

이를 통해 Ruler가 단 4개의 컴포넌트만으로 화면의 61%를 커버하고 있으며, 이로 인해 15%의 개발 및 디자인 비용이 절감되었다는 사실을 확인할 수 있습니다. 또한 이는 29CM의 디자인 일관성을 사전에 확보하고 파편화를 줄이는 부가적인 효과를 기대하게 합니다.

이렇게 분기별로 Ruler의 조직 내 지원 범위와 구성원들에 대한 서포트 수준을 시각화함으로써, 팀의 노력을 확인하고 이를 바탕으로 사용을 더 적극적으로 권장할 수 있게 되었습니다.

---

그래서 무엇이 개선됐나요?

1. 단 6개월만에 Component 50.3%가 제작 & 제공되고 있습니다. 위와 같은 환경을 셋팅한 후 디자인 시스템 TF는 한정된 리소스임에도 불구하고 3분기 내 컴포넌트 제작 50.3%(정의한 컴포넌트 35개 중 23개)를 빠르게 달성하고 구성원에게 제공까지 할 수 있었습니다. 제공된 컴포넌트의 수 만큼, 구성원이 피로도를 느끼는 소통비용도 감소됐을것 입니다.

2. 디자인 시스템의 생산성 & 일관성의 가치를 지속적으로 측정하고 개선할 수 있게 되었습니다.

Ruler SSOT를 바탕으로 소통하는 모습들!

3. 구성원 Ruler SSOT라는 동일한 기반에서 소통하게 되었습니다. 정의되지 않거나 지원되지 않는 스펙에 대한 질문이나 요구사항이 있을 때, 구성원들은 SSOT를 통해 해답을 얻거나 필요한 논의를 진행할 수 있습니다. 이렇게 공통된 참조점을 사용함으로써 생기는 문제점에 대해 명확하고 효과적으로 대응할 수 있게 됐습니다.

NPS설문조사에 답변주신 실제 내용들

생산성과 효율성의 증진 만큼 Ruler 디자인 시스템을 실제로 사용하는 팀원들의 만족감 역시 중요하다고 생각합니다. 단지 컴포넌트를 신속하게 제공하는 데에만 집중하면 컴포넌트 사용성에 대한 깊은 고민이 부족할 수 있고, 이는 결국 구성원들에게 Ruler 사용에 대한 진정한 동기를 부여하지 못할 수 있습니다. 따라서, 팀원들의 피드백을 지속적으로 수렴하고 디자인 시스템에 반영하는 것이 필요합니다.

24년 1Q에 실행한 NPS 설문조사 결과로 76.2%라는 높은 만족도를 기록하며 Ruler가 구성원에게 긍정적인 반응을 얻고 있음을 알 수 있었습니다. 이는 디자인 시스템이 잘 작동하고 있음을 의미하지만, 동시에 구성원들이 마주한 문제점들을 개선함으로써 만족도를 80% 이상으로 끌어올릴 수 있는 기회로도 바라볼 수 있습니다.

설문을 통해 얻은 피드백은 Ruler의 사용성을 한층 더 강화하고, 모든 구성원이 보다 높은 만족감을 느낄 수 있는 방향으로 더 개선되어야 할 것입니다.

---

남아있는 숙제들

사용자 문제를 해결하기 위해 프로덕트 디자이너는 디자인 시스템의 컴포넌트를 활용해 새로운 UI를 구성합니다. 이때, 팀이 담당하는 도메인의 특성에 따라 UI의 정보 구성이 달라지며, 경우에 따라 기존의 예측을 벗어나는 실험적인 디자인을 시도하기도 합니다.

이 단계에서 대부분의 고민은 어떤 요소를 엄격하게 관리할 것인지, 어디에 유연성을 부여할 것인지와 같은 추상화에 대한 고민들입니다.

대부분의 UI는 Card나 List Item과 같은 기본 컴포넌트로 구성될 수 있지만 모든 상황을 하나의 컴포넌트로 통일하려는 시도나 지나치게 유연한 접근은 일관성과 관리 측면에서 새로운 문제를 발생시킬 수 있습니다. 때문에 디자인 시스템에서는 컴포넌트의 적절한 추상화 수준을 정의하고, 각 컴포넌트의 사용 범위와 규칙을 명확히 설정하는 것이 중요합니다.

팀을 더 잘 서포팅하기 위한 Pattern과 Governance³

29CM은 레포지토리나 Figma 내에서 컴포넌트와 패턴을 명시적으로 분리하지 않지만, 개념적으로 두 범주의 레벨을 구분하여 디자인 시스템을 구축하고 있습니다.

Component	Pattern
재사용 가능한 디자인 요소 또는 UI 빌딩 블록	하나 이상의 컴포넌트가 결합되어 특정 상호작용이나 레이아웃을 형성하는 구조
서비스를 구성하는 가장 기본적인 공통 형태	29CM 서비스에 특징적으로 반복되는 디자인 형태
독립적으로 기능적인 역할을 수행함	29CM 서비스에서 범용적으로 사용자에게 특정 역할을 수행함
RulerTF에서 기본적으로 제공되는 단위	29CM 서비스 차원에서 바라보되, 도메인별 특성은 Ruler에서 직접 제공하지 않음

컴포넌트는 재사용성을 강조하는 기본 빌딩 블록으로, 반면 패턴은 이러한 빌딩 블록들이 어떻게 상호작용하여 전체적인 사용자 경험을 형성하는지에 대한 구조적 접근을 제공합니다.

지나친 추상화는 프로덕트 디자이너를 혼란스럽게 합니다

디자인 자유도를 증가시키기 위해 다양한 내용을 담을 수 있는 카드 패턴을 제안하기도 했었지만, 지나치게 추상화된 디자인은 프로덕트 디자이너에게 필요한 구체적인 가이드라인을 제공하지 못하고 오히려 혼란을 초래했습니다. 이러한 경험을 바탕으로, 패턴에 낮은 수준의 추상화를 부여하여 29CM 서비스 내 특정 사용 사례를 바탕으로 UI가 사용자에게 수행하고 있는 역할에 맞게 조정하고 관리하는 것이 더 효과적임을 알 수 있었습니다.

정의된 'Product Card'는 29CM의 사용자에게 수행하고 있는 역할을 기반으로 하며,그 역할을 효과적으로 수행하기 위해 필요한 필수 정보와 선택적인 속성을 명확하게 제시합니다.

이 기준을 바탕으로, 'Product Card'의 확장, 커스터마이징, 새로운 패턴 생성에 대한 명확한 지침을 제공할 수 있습니다.

우리는 도메인마다 다른 정보와 옵션들을 모두 예측할 수 없습니다. 단일 사례에 기반하여 추상화를 확장하는 것보다는 다양한 사례를 수집하고 그 의미를 파악하는 것을 우선시합니다. 충분한 사례 수집 없이는 RulerTF에서 이를 제공하지 않습니다.

프로덕트 디자이너가 필요에 의해 동일한 역할을 수행하는 다른 형태를 제안할 경우, 이는 다른 문제에 대한 고민을 발견하거나 심미적 가치를 강화하는 기회로 바라볼 수 있습니다. 이런 경우, 디자이너의 의도와 사용자의 필요를 이해하고 적합한 해결책을 도출하기 위해 팀 내 논의로 이어갑니다.

이와 같은 Governance 접근 방식은 즉각적으로 프로덕트 디자이너에게 다양한 Pattern을 제공하는 것이 아니라, 장기적인 관점에서 "사용자에게 수행하는 역할"을 패턴의 정체성으로 설정함으로써, 프로덕트 디자이너와 플랫폼 디자이너가 사용성을 고려한 디자인 시스템을 함께 구축해 나갈 수 있도록 합니다.

---

이 접근법은 아직 초기 단계에 있으며, Ruler와 프로덕트 디자이너가 서로에게 긍정적인 영향을 주며 29CM의 제품에 기여할 수 있는지 확실히 알 수 없습니다. 그러나 과거의 경험을 바탕으로, 디자인 시스템은 단순히 단기 프로젝트가 아니라, 조직의 서비스와 함께 성장하며 발전해야 하는 제품으로 바라보고, 최종적으로 사용자를 위해 구성되는 것이 목표일 것 입니다. 사용자 중심의 접근은 플랫폼 디자이너와 프로덕트 디자이너가 함께 공유하는 핵심 가치이며, 함께할 때 더 큰 가치를 만들어갈 수 있다고 믿습니다.

현재 정의된 기준은 최선을 다해 설정한 것이지만, 조직의 방향성과 구성원의 요구에 따라 언제든지 유연하게 조정될 수 있습니다. 더 나은 아이디어와 방법이 생각나신다면 꼭 알려주세요.

---

Footnotes

1. Headless 컴포넌트는 UI의 시각적 부분을 제외하고 기능성과 데이터 처리를 중점으로 둔 컴포넌트로, 개발자가 다양한 환경에서 자유롭게 스타일과 레이아웃을 정의할 수 있게 해줍니다. ↩

2. Ark-ui 는 Zag.js가 내장된 headless ui 라이브러리 입니다. 다양한 사용자 인터랙션과 UI 상태 관리를 처리합니다. 예를 들어, 드롭다운 메뉴의 열기/닫기, 탭 전환, 모달 대화상자의 표시 같은 사용자 인터페이스의 상호작용을 쉽게 구현하고 관리할 수 있도록 돕습니다. ↩

3. 디자인 시스템에서의 거버넌스(Governance)는 디자인 시스템의 생성, 관리, 그리고 발전을 위한 정책, 절차, 가이드라인을 설정하고 실행하는 과정을 의미합니다. ↩