FE 0.5인 리소스로 디자인 시스템 구축한 방법

2025년 설 연휴, 여러분은 어떻게 보내고 있나요? 새로운 시작을 위해 준비하는 분도, 다시 달리기 위해 푹 쉬는 분도 있을 텐데요. 요즘IT에서 설 연휴를 맞아 국내 주요 기업의 특색 있고 유익한 블로그 콘텐츠를 소개하는 시리즈를 준비했습니다. 이들은 어떻게 사고하고, 어떤 방식으로 일하는 걸까요?

이번 글에서는 패션 플랫폼 29CM의 프론트엔드 플랫폼팀에서 ‘효율적인 디자인 시스템’을 구축하고 활용한 경험에 대해 소개합니다.

안녕하세요! 29CM에서 일관된 UI/UX 제공을 위해 디자인 시스템을 개발 및 유지보수하고 있는 프론트엔드 플랫폼 팀의 신다혜입니다. 저는 현재 기존에 운영되던 Ruler 디자인 시스템을 인수인계받아 관리하고 있어요. 다만 본래 진행하던 업무가 있었기 때문에 디자인 시스템은 0.5인의 리소스로 운영해야 했습니다.

이러한 제한된 리소스 안에서 어떻게 디자인 시스템을 생산적이고 효율적으로 관리할 수 있을지 끊임없이 고민했고, 그 과정에서 얻은 실무적인 경험과 인사이트를 이 글에서 공유하고자 합니다.

빠르게 성장하는 회사에서는 많은 태스크가 동시다발적으로 생기기도 합니다. 그러다 보면 특정 업무에만 집중하기는 어려워요. 29CM에서도 디자인 시스템이 필요하지만, 여기에 모든 리소스를 투입할 수 없는 상황이었는데요. 이런 상황에서는 어떤 대안이 있을까요?

처음부터 끝까지 디자인 시스템을 만들 수 있는 여력이 없다면, 이미 잘 만들어진 디자인 시스템을 도입해 보면 어떨까요? 디자인된 토큰에 대한 유틸리티를 만들어야 한다면요? 그 과정은 지금부터 소개해 드릴게요!

디자인 시스템도 하나의 제품이다

“사람들이 사지 않는다면 최고의 제품을 생산하는 것이 무슨 의미가 있겠는가?”

— 도널드 노먼

디자인 시스템에는 어떤 식으로 접근하면 좋을까요? 디자인 시스템도 하나의 지속 가능한 제품이라는 관점에서 도널드 노먼의 말이 마음에 깊이 와닿았어요. 아무리 뛰어난 컴포넌트를 만들어도, 개발자와 유저가 사용하지 않는다면 가치가 사라지고 결국 폐기되죠. 29CM의 디자인 시스템도 마찬가지입니다.

디자인 시스템은 대고객(사용자)에게 일관된 UI/UX를 제공하고, 개발자에게는 효율적인 개발 환경을 지원해야 합니다. 디자인 시스템의 구독자는 대고객과 개발자라고 생각해요. 대고객과 개발자에게 VOC를 빠르게 듣고, 피드백을 반영하면 더 잘 쓰이게 되죠.

그래서 저는 디자인 시스템도 MVP로 빠르게 구축하고, 짧은 iteration을 통해 가치를 검증하고 발전시켜야 한다고 생각해요.

서비스 특성에 맞춘 전략적 도입

어드민 서비스: 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 기반의 Customize Theme를 만드는 기능을 제공하고 있어요.

29CM에서도 Antd를 도입할 때 기존 어드민 페이지와 톤앤매너가 이질적으로 느껴지지 않도록 기존 어드민 페이지의 Theme와 유사한 토큰(색상 및 간격)들을 추출해서 Customize Theme를 적용했어요.

대고객 서비스: Ruler + TailwindCSS + tailwind-variants

대고객 서비스의 상황은 어드민과는 다른데요. 바로 29CM에 알맞은 감도를 제공할 수 있는 UI/UX가 서빙되어야 하기 때문입니다.

이를 충족 시키기 위해서는 일부 커스텀만 허용하는 UI 라이브러리는 한계를 가지고 있어요. 이런 한계 때문에 별도로 스타일을 입힌 컴포넌트를 제작할 수밖에 없어요.

기존 Ruler는 emotion(css-in-js)으로 제작되었어요. 초기 디자인 시스템으로도 atomic한 단위의 컴포넌트(Badge, Button 등)가 제작될 때는 큰 문제가 되지 않았습니다. 다만 패턴 컴포넌트가 제작되면서부터 성능 이슈가 발생했어요. 현재 Ruler 디자인 시스템에서 서빙되고 있는 컴포넌트 중 가장 활용도가 높은 컴포넌트는 바로 ProductCard인데요. 다음과 같이 내부에 다양한 컴포넌트의 조합이 사용되고 있습니다.

PC 화면의 경우 ProductCard가 50개씩 노출되어야 하는데요. css-in-js를 사용하는 경우, 런타임 성능 이슈가 사용자 경험(UX)을 저하시키는 수준으로 발생했습니다. css-in-js의 성능 이슈 관련하여 유명한 글이 있으니 해당 글을 읽어보는 것을 추천해 드려요!

참고 글: CSS-in-JS와 결별하는 이유 Blog

이를 위해 스타일링 라이브러리 교체 작업이 이루어졌고, 주로 고민했던 포인트는 다음과 같습니다.

1. JavaScript Bundle, Runtime Overhead를 줄일 수 있을 것
2. 일반적인 스타일링을 할 때, DX 경험을 감소시키지 않을 것

팀에서는 TailwindCSS + tailwind-variants / vanilla-extract + sprinkle와 같은 대응안이 논의되었어요. 최종적으로는 TailwindCSS + tailwind-variants를 채택했는데요. 앞서 언급한 1+2가 모두 충족되었기 때문이에요.

1. TailwindCSS는 PostCSS를 이용해 컴파일 타임에 스타일을 전처리
   - JavaScript Bundle 사이즈에 영향을 주지 않음
   - 스타일 생성을 위한 Runtime Overhead가 없음
2. tailwind-variants 조합을 통해 개발자 경험 유지
   - class conflict 방지
   - Variant API 기반의 스타일링 경험 제공
   - 자동 완성과 타입 세이프티 지원

추가적으로 아래와 같은 이유로 디자인 시스템을 서빙하는 데 효율적이라는 이유도 있었습니다.

• Theme Configuration 기반의 간편한 class utility 제작 (color palette, type scale, fonts, breakpoints, border radius values 등)
• 풍부한 커뮤니티 및 플러그인 (tailwind-prettier, IDE intellisense 등등)

TailwindCSS의 생태계가 궁금하다면 awesome-tailwind를 확인해 보세요!

시행착오와 개선 과정

그렇게 현재 디자인된 37개 컴포넌트 중 약 30개를 제작했고, 서비스에 반영했는데요. 이 과정이 마냥 순탄하지는 않았습니다. 디자인 시스템을 관리하며 겪었던 문제 상황들과 이를 통해 얻은 인사이트도 함께 공유해 보려고 해요.

시행착오 1. 완벽한 컴포넌트를 구현하기는 어렵다

디자인 시스템 컴포넌트를 개발하면서 알게 된 사실은 ‘완벽하게 한 번에 잘 쓰이는 컴포넌트를 구현하기가 굉장히 어렵다’는 점이에요. 다음은 제가 컴포넌트를 만들면서 만든 버그들이에요.

• Dialog: 긴 제목이 있을 때 닫기(X) 버튼과 겹침
• Tabs: underline 스펙 누락
• ProductCard: 클릭커블한 요소 중, 포인터 커서가 반영되지 않은 부분이 있음

29CM에서 함께 일하는 동료 FE 개발자분들이 컴포넌트를 사용하면서 리포트 해준 부분인데요. 서빙되는 컴포넌트의 안정성을 높이기 위한 조치가 필요하다고 생각했어요.

배운 점

컴포넌트를 완벽하게 만들려고 시간을 많이 투자한다고 해서 모든 실수를 방지할 수는 없습니다.

(1) 빠르게 만들어 피드백을 받고 개선하는 것이 더 효과적이었습니다. (2) 대응 가능한 리소스가 없는 상황에서 버그가 있다면, 디자인 시스템이 자생할 수 있는 가이드라인과 프로세스 구축이 필요하다고 생각했어요.

Action1: 피드백 프로세스 — Chromatic + Storybook

• Chromatic을 사용하면, 디자이너에게 컴포넌트 단위로 좀 더 정확한 피드백을 받을 수 있어요.
• 간단한 chromatic.yaml 세팅만으로 Storybook CI/CD를 구축해서 QA 가능한 프로세스를 만들 수 있어요.

Action2: Ruler 오픈 소스 — 기여 제도 도입

• Wiki 내 Ruler에 작업할 수 있는 가이드 문서를 작성해 두었어요
• 누구나 디자인 시스템을 관리하는 데 기여할 수 있게 함으로써 트럭 팩터 1인 상황을 방지할 수 있게 했어요.

시행착오 2. 컴포넌트 스펙은 변화한다.

디자인 시스템은 살아있는 제품이라서 유기적으로 변화한다는 사실을 깨달았어요. 컴포넌트는 제작되었다고 끝나는 것이 아니고, 지속적인 업그레이드가 필요하더라고요. ProductCard는 제작된 이후에도 스펙이 약 3번 정도 추가되었습니다.

1. 이미지 Preview에 Badge를 노출할 수 있는 extraBadge 추가
2. 하단 Badge 그룹에 icon을 표기하는 스펙 추가
3. 브랜드명을 별도 클릭할 수 있는 스펙 추가

주로 스펙이 추가되는 케이스는 다음과 같은 이유가 있었어요.

1. ProductCard를 활용하여 A/B 테스트가 진행된 이후, 실험에 성공하여 롤아웃
2. 전사 서비스 방향성 반영

특정 스펙이 변화할 때마다 Design/AOS/IOS/FE 모두 디자인 시스템 컴포넌트를 업데이트를 해야 했는데요. 각자 작업이 가능한 시기가 달라 Cross Platform 환경에서 디자인 시스템 스펙을 일관성 있게 유지하는 것이 아주 어려웠어요.

배운 점

디자인 시스템은 끊임없는 유지 보수가 필요한 제품이라는 사실을 알게 되었어요. 유지 보수에 필요한 히스토리를 명확히 하지 않으면, 스펙에 대한 파편화가 일어나기 아주 쉽다는 사실도 알게 되었죠.

Action: 깃허브 프로젝트로 컴포넌트 트래킹

깃허브 프로젝트를 통해서 컴포넌트 단위로 히스토리를 관리할 수 있도록 세팅을 추가했습니다. 초기 스펙에서 어떠한 이유로 변화했는지 히스토리를 트래킹하기 위해서였어요. 디자인 시스템은 AOS/IOS/FE 세 플랫폼에서 모두 관리되어야 하기 때문에 각각 플랫폼마다의 진행 상황과 스펙을 확인하기에 용이했어요. 플랫폼 디자이너분과 Adobe의 깃허브 프로젝트를 참고하여 만들었어요.

실행 가능한 가이드

1. 디자인 시스템이 처음이라면? (작은 것부터 시작하기 — MVP 접근)

파편화된 UI 중 어떤 것이 UX/DX에 가장 큰 문제가 되고 있나요? 만약 처음 디자인 시스템을 개발하는 단계라면 다음과 같은 액션을 해보는 것을 추천해 드려요.

• 버튼, 입력창, 내비게이션 바와 같은 핵심 컴포넌트부터 구축
• 빠르게 적용하고 짧은 피드백 주기로 개선

2. 리소스가 부족하다면? (효율적인 협업 구조 만들기)

디자인 시스템의 개발/유지보수에 어려움을 겪고 있다면, 다른 사람의 도움을 받아 팀 오픈 소스 방식으로 운영하는 것을 고려해 보면 어떨까요? 자동화로 개선할 수 있는 부분이 있다면 자동화 도구를 충분히 활용해도 좋을 거예요.

• 기여 가이드라인 작성 → 개발자 누구나 디자인 시스템에 쉽게 참여하도록 유도
• 자동화 도구(Chromatic) 활용 → 품질 유지와 리뷰 시간 절감

마치며: 빠르게 만들고 꾸준히 개선하기

디자인 시스템을 제품 관점에서 볼 때 가장 중요한 것은 무엇일까요? 고객의 불편함을 해결해주는 것이라고 생각해요. 하지만, 빠르게 서비스가 서빙되지 못하면 무엇이 문제인지조차 알기 어려운 경우들이 많은 것 같아요. 제가 컴포넌트를 제작하고 서빙한 후에 알게 된 문제들이 있듯 말이에요.

앞으로도 디자인 시스템 구독자인 고객(사용자, 개발자)이 계속 필요로 할 수 있도록 가치를 제공할 디자인 시스템을 만들고 싶어요. 여러분이 필요한 디자인 시스템은 어떤 디자인 시스템인가요? 정답이 없는 문제이지만, 제 경험이 도움이 되었기를 바랍니다. 그럼 저는 Ruler를 통해 Guide To Better Choice에 기여하러 가보겠습니다. 여기까지 읽어주셔서 감사합니다.

<원문>

당신2 9하던 디자인 시스템? 0.5인 리소스로 효율적으로 구축하기

©️요즘IT의 모든 콘텐츠는 저작권법의 보호를 받는 바, 무단 전재와 복사, 배포 등을 금합니다.