Engineering
당신2 9하던 디자인 시스템? 0.5인 리소스로 효율적으로 구축하기
2025년 1월 15일
원문에서 보기 ↗
안녕하세요! 29CM 에서 일관된 UI/UX 제공을 위해 디자인 시스템을 개발 및 유지보수하고 있는 프론트엔드 플랫폼 팀의 신다혜입니다.
저는 현재 기존에 운영되던 Ruler 디자인 시스템을 인수인계받아 관리하고 있어요. 본래 진행하던 업무가 있었기 때문에 디자인 시스템은 0.5인의 리소스로 운영해야 했습니다.
이러한 제한된 리소스 안에서 어떻게 디자인 시스템을 생산적이고 효율적으로 관리 할 수 있을지 끊임없이 고민했고, 그 과정에서 얻은 실무적인 경험과 인사이트를 이 글에서 공유하고자 합니다.
빠르게 성장하는 회사에서는 많은 태스크가 동시 다발적으로 생기기도 합니다. 그러다보면 특정 업무에만 집중하기는 어려워요. 29CM 에서도 디자인 시스템이 필요하지만, 여기에 모든 리소스를 투입할 수 없는 상황이었는데요. 이런 상황에서는 어떤 대안이 있을까요?
처음부터 끝까지 디자인 시스템을 만들 수 있는 여력이 없다면 이미 잘 만들어진 디자인 시스템을 도입해보면 어떨까요? 디자인 된 토큰에 대한 유틸리티를 만들어야 한다면요?
그 과정은 지금부터 소개드릴게요!
1️⃣ 디자인 시스템도 하나의 제품이다
도널드 노먼의 사용사 중심 디자인
“사람들이 사지 않는다면 최고의 제품을 생산하는 것이 무슨 의미가 있겠는가?”
— 도널드 노먼
테크 업계에서 디자인 시스템을 어떤 식으로 접근하면 좋을까요? 디자인 시스템도 하나의 지속 가능한 제품이라는 관점에서 도널드 노먼의 말이 마음에 깊이 와 닿았어요. 아무리 뛰어난 컴포넌트를 만들어도, 개발자와 유저에게 사용하지 않는다면 가치가 사라지고 결국 폐기되죠. 29CM 의 디자인 시스템도 마찬가지입니다.
디자인 시스템은 대고객(사용자) 에게 일관된 UI/UX 를 제공하고, 개발자에게는 효율적인 개발 환경을 지원해야 합니다. 디자인 시스템의 구독자는 대고객과 개발자라고 생각해요. 대고객과 개발자에게 VOC를 빠르게 듣고, 피드백을 반영하면 더 잘 쓰이게 되죠.
그래서 저는 디자인 시스템도 MVP 로 빠르게 구축하고, 짧은 iteration 을 통해 가치를 검증하고 발전시켜야 한다고 생각해요.
2️⃣ 서비스 특성에 맞춘 전략적 도입
💡 어드민 서비스: ANTD + Custom Theme
어드민 디자인 시스템을 구축할 때는 Ant Design(ANTD) 를 도입했어요. 이유는 간단한데요. 바로 기회비용 측면에서 ANTD 를 사용하는 것이 더 이득이었기 때문입니다.
어드민 서비스는 다음과 같은 특징을 가지고 있어요.
- 내부 관리자 및 파트너사가 대부분
- 어드민 서비스는 유려한 UI/UX 보다 기능적으로 치중해야하는 요소가 많음
- 예측 가능하고, 올바른 기능이 구현되는 것이 중요
ANTD, MUI 등과 같은 라이브러리들은 어드민에 사용하기 풍부한 기능을 가진 컴포넌트들을 제공해요. Table 과 같은 컴포넌트의 경우, 구현에 있어서 복잡도가 상당해요. 페이지네이션, 필터링, 소팅의 기능을 갖춘 Table 컴포넌트를 디자이너가 설계하고, 이를 개발자가 구현하여 서빙하기 까지는 많은 시간과 리소스가 드는 일입니다. 자체적으로 완성도 높은 Table 컴포넌트를 만들기 위해서 제작에만 몇 달을 소요할 수도 있어요.
ANTD 와 같이 풍부한 기능을 내재하고 있는 라이브러리 사용은 FE 개발자들에게 학습 비용도 굉장히 짧으며, 어드민 페이지의 디자인과 개발 생산성을 크게 향상 시킬 수 있어요.
ANTD 디자인 시스템을 적용한 후, 실제로 어떤 효과를 볼 수 있었을까요?
한 화면 기준 디자인 작업 시간은 최대 75% , 개발 작업 시간은 약 87% 단축되었습니다.
작업이 진행 된 어드민 디자인
상단 이미지 디자인 시안 작업에 걸리는 시간을 기준으로 측정되었어요. 디자이너 리소스를 1/4, FE 리소스를 1/8 절감할 수 있게 되었죠. 퍼블리싱 등에 집중하는 시간을 비즈니스 로직이나 더 중요한 문제를 푸는데 투자할 수 있게 되었어요.
어드민의 톤앤매너가 걱정되시나요? 걱정하실 필요 없어요! 대부분의 라이브러리들에서 이미 Token 기반의 CustomizeTheme 을 만드는 기능을 제공하고 있어요.
29CM에서도 Antd 를 도입 할 때 기존 어드민 페이지와 톤앤매너가 이질적으로 느껴지지 않도록 기존 어드민 페이지의 Theme 와 유사한 토큰(색상 및 간격)들을 추출해서 CustomizeTheme을 적용했어요.
💡 대고객 서비스: Ruler + TailwindCSS + tailwind-variants
대고객 서비스의 상황은 어드민과는 다른데요. 바로 29CM의 알맞는 감도를 제공할 수 있는 UI/UX가 서빙되어야 하기 때문입니다.
- 29CM 감도에 어울리도록 디자인 된 UI/UX 경험 제공이 필요
이를 충족 시키기 위해서는 일부 커스텀만 허용하는 UI 라이브러리는 한계를 가지고 있어요. 이런 한계 때문에 별도로 스타일을 입힌 컴포넌트를 제작할 수 밖에 없어요.
기존 Ruler는 emotion (css-in-js)를 통해 제작되었어요. 초기 디자인 시스템에서 atomic한 단위의 컴포넌트 (Badge, Button 등)가 제작될 때는 큰 문제가 되지 않았습니다. 패턴 컴포넌트가 제작되면서부터 성능 이슈가 발생했어요. 현재 Ruler 디자인 시스템에서 서빙되고 있는 컴포넌트 중 가장 활용도가 높은 컴포넌트는 바로 ProductCard 인데요. 다음과 같이 내부에 다양한 컴포넌트의 조합이 사용되고 있습니다.
Ruler ProductCard 컴포넌트
PC 화면의 경우 ProductCard가 50개씩 노출되어야 하는데요. css-in-js를 사용하는 경우, 런타임 성능 이슈가 사용자 경험(UX)을 저하시키는 수준으로 발생했습니다. css-in-js의 성능 이슈 관련하여 유명한 글이 있으니 해당 글을 읽어보는 것을 추천드려요!
이를 위해 스타일링 라이브러리 교체 작업이 이루어졌고, 주로 고민했던 포인트는 다음과 같습니다.
- JavaScript Bundle, Runtime Overhead를 줄일 수 있는 것
- 일반적인 스타일링을 할 때, DX 경험을 감소시키지 않을 것
TailwindCSS + tailwind-variants / vanilla-extract + sprinkle 와 같은 대응안이 논의되었어요. 최종적으로는 TailwindCSS + tailwind-variants를 채택했는데요. 앞서 언급한 1+2가 모두 충족되었기 때문이에요.
- TailwindCSS는 PostCSS를 이용해 컴파일 타임에 스타일을 전처리
- JavaScript Bundle 사이즈에 영향을 주지 않음
- 스타일 생성을 위한 Runtime Overhead 가 없음
- tailwind-variants 조합을 통해 개발자 경험 유지
- class conflict 방지
- Variant API 기반의 스타일링 경험 제공
- 자동 완성과 타입 세이프티 지원
추가적으로 아래와 같은 이유로 디자인 시스템을 서빙 하는데 효율적이었기 때문입니다.
- Theme Configuration 기반의 간편한 class utility 제작 (color palette, type scale, fonts, breakpoints, border radius values 등)
- 풍부한 커뮤니티 및 플러그인 (tailwind-prettier, IDE intellisense 등등)
TailwindCSS의 생태계가 궁금하시다면 확인해보세요!
3️⃣ 시행착오와 개선 과정
현재 디자인 된 37개 컴포넌트 중 약 30개가 제작 되었고, 서비스에 반영 되어있는데요. 이 과정이 마냥 순탄하지는 않았습니다. 디자인 시스템을 관리하며 겪었던 문제 상황들과 이를 통해 얻은 인사이트도 함께 공유드려보려고 해요.
1. 시행 착오: 완벽한 컴포넌트를 구현하기는 어렵다.
디자인 시스템 컴포넌트를 개발하면서 알게 된 사실은 완벽하게 한번에 잘 쓰이는 컴포넌트를 구현하기가 굉장히 어렵다는 사실을 깨달았어요. 다음은 제가 컴포넌트를 만들면서 만든 버그들이에요.
- Dialog : 긴 제목이 있을 때 닫기(X) 버튼과 겹침
- Tabs : underline 스펙 누락
- ProductCard : 클릭커블한 요소 중, 포인터 커서가 반영되지 않은 부분이 있음
29CM에서 함께 일하는 동료 FE 개발자분들이 컴포넌트를 사용해주시면서 레포트 해주신 부분이에요. 서빙되는 컴포넌트의 안정성을 높이기 위한 조치가 필요하다고 생각했어요.
배운 점
컴포넌트를 완벽하게 만들려고 시간을 많이 투자한다고 해서 모든 실수를 방지할 수는 없습니다. (1) 빠르게 만들어 피드백을 받고 개선 하는 것이 더 효과적이었습니다. (2) 대응 가능한 리소스가 없는 상황에서 버그가 있다면, 디자인 시스템이 자생 할 수 있는 가이드라인과 프로세스 구축이 필요하다고 생각했어요.
Action1: 피드백 프로세스 — Chromatic + Storybook
- Chromatic을 사용하면, 디자이너에게 컴포넌트 단위로 좀 더 정확한 피드백을 받을 수 있어요.
- 간단한 chromatic.yaml 세팅만으로 Storybook CI/CD를 구축해서 QA 가능한 프로세스를 만들 수 있어요.
Chromatic Review
Action2: Ruler 오픈 소스 — 기여 제도 도입
- Wiki에 Ruler에 작업을 할 수 있는 가이드 문서를 작성해두었어요
- 누구나 디자인 시스템을 관리하는데 기여할 수 있게 함으로서 트럭 팩터 1인 상황을 방지할 수 있게 했어요.
Ruler Wiki와 기여 받은 PR
2. 시행 착오: 컴포넌트 스펙은 변화한다.
디자인 시스템은 살아있는 제품이라서 유기적으로 변화한다는 사실을 깨달았어요. 컴포넌트는 제작되었다고 끝나는 것이 아니고, 지속적인 업그레이드가 필요하더라구요. ProductCard는 제작 된 이후에도 스펙이 약 3번 정도 추가되었는데요.
- 이미지 Preview에 Badge 를 노출 할 수 있는 extraBadge 추가
- 하단 Badge 그룹에 icon 을 표기하는 스펙 추가
- 브랜드 명을 별도 클릭 할 수 있도록 하는 스펙 추가
주로 스펙이 추가되는 케이스는 다음과 같은 이유들이 있었어요.
- ProductCard를 활용하여 A/B 테스트가 진행 된 이후, 실험에 성공하여 롤아웃
- 전사적인 서비스 방향성 반영
특정 스펙이 변화할 때 마다 Design/AOS/IOS/FE 모두 디자인 시스템 컴포넌트를 업데이트를 해야 했는데요. 각자 작업이 가능한 시기가 달라 Cross Platform 환경에서 디자인 시스템 스펙을 일관성 있게 유지하는 것이 아주 어려웠어요.
배운 점
디자인 시스템은 끊임 없는 유지보수 가 필요한 제품이라는 사실을 알게 되었어요. 유지 보수에 필요한 히스토리를 명확히 하지 않으면, 스펙에 대한 파편화가 일어나기 아주 쉽다는 사실도 알게 되었죠.
Action: 깃허브 프로젝트로 컴포넌트 트래킹
깃허브 프로젝트를 통해서 컴포넌트 단위로 히스토리를 관리할 수 있도록 세팅을 추가했습니다. 초기 스펙에서 어떠한 이유로 변화해는지 히스토리를 트래킹하기 위해서였어요. 디자인 시스템은 AOS/IOS/FE 세 플랫폼에서 모두 관리되어야하기 때문에 각각 플랫폼마다의 진행 상황과 스펙을 확인하기에 용이했어요.
Ruler Task Tracking Board
플랫폼 디자이너분과 Adobe의 깃헙 프로젝트(LINK)를 참고하여 만들었어요. :)
4️⃣ 실행 가능한 가이드
1. 디자인 시스템이 처음이라면? (작은 것부터 시작하기 — MVP 접근)
파편화 된 UI 중에 어떤 것이 가장 UX/DX 에 문제가 되고 있나요? 만약 처음 디자인 시스템을 개발하는 단계라면 다음과 같은 액션을 해보시는 것을 추천드려요.
- 버튼 , 입력창 , 내비게이션 바 와 같은 핵심 컴포넌트부터 구축
- 빠르게 적용하고 짧은 피드백 주기로 개선
2. 리소스가 부족하다면? (효율적인 협업 구조 만들기)
디자인 시스템의 개발/유지보수에 어려움을 겪고 있다면, 다른 사람의 도움을 받아 팀 오픈 소스 방식으로 운영하는 것을 고려해보면 어떨까요? 자동화로 개선할 수 있는 부분이 있다면 자동화 도구를 충분히 활용해도 좋을거에요.
- 기여 가이드라인 작성 → 개발자 누구나 디자인 시스템에 쉽게 참여하도록 유도
- 자동화 도구(Chromatic) 활용 → 품질 유지와 리뷰 시간 절감
5️⃣ 결론: 빠르게 만들고 꾸준히 개선하기
디자인 시스템을 제품 관점에서 볼 때 가장 중요한 것은 무엇일까요? 고객의 불편함을 해결해주는 것이라고 생각해요. 하지만, 빠르게 서비스가 서빙되지 못하면 무엇이 문제인지조차 알기 어려운 경우들이 많은 것 같아요. 제가 컴포넌트를 제작하고 서빙 한 후에 알게 된 문제들이 있듯이 말이에요.
앞으로도 디자인 시스템 구독자인 고객(사용자, 개발자)이 계속 필요로 할 수 있도록 가치를 제공할 수 있는 디자인 시스템을 만들고 싶어요. 여러분이 필요한 디자인 시스템은 어떤 디자인 시스템인가요? 정답이 없는 문제이지만, 저의 경험이 도움이 되었기를 바랍니다. 🙂
그럼 저는 Ruler 를 통해 Guide To Better Choice에 기여하러 가보겠습니다. 🙌
여기까지 읽어주셔서 감사합니다.
💡 디자인 시스템? 지금 시작해보세요!
- “팀에서 가장 많이 필요로 하는 컴포넌트는 무엇인가요?”
- “디자인 시스템 도입 과정에서 궁금한 점이 있다면 댓글로 남겨주세요!”
MUSINSA CAREER
함께할 동료를 찾습니다.
29CM팀은 ‘고객의 더 나은 선택을 돕는다’라는 미션으로 출발했습니다. 우리는 우리만의 방식으로 콘텐츠를 제공하며, 브랜드와 고객 모두에게 대체 불가능한 커머스 플랫폼을 만들어가고 있습니다. 이 미션을 이루기 위해 우리는 흥미로우면서도 복잡한 문제들을 해결하고 있습니다. 만약 우리와 함께 이 문제들을 해결해 보고 싶다면, 주저하지 말고 29CM에 합류하세요!
🚀 팀 무신사 채용 페이지 (무신사/29CM 전체 포지션 확인이 가능해요)
채용이 완료되면 공고가 닫힐 수 있으니 빠르게 지원해 주세요!