0.5인 리소스로 효율적으로 구축하는 디자인 시스템

디자인 시스템도 하나의 제품으로 보고, 사용자와 개발자에게 실제로 쓰이게 만드는 데 초점을 맞췄다. 완성도를 한 번에 끌어올리기보다 MVP로 빠르게 만들고 짧은 iteration으로 개선하는 방식이 핵심이었다.

서비스 특성에 따라 도입 전략도 달랐다. 어드민은 복잡한 Table과 기능 중심 요구가 많아 Ant Design(ANTD) 을 선택했고, 기존 어드민의 톤앤매너와 어긋나지 않도록 토큰을 추출해 Custom Theme 을 적용했다. 그 결과 한 화면 기준 디자인 작업은 최대 75%, 개발 작업은 약 87% 단축됐다.

반면 대고객 서비스는 29CM 감도에 맞는 UI/UX가 중요해 커스텀 스타일링이 가능한 구조가 필요했다. 기존 Ruler 는 emotion(css-in-js) 기반이었지만, 특히 ProductCard 처럼 복합 컴포넌트가 대량 노출되는 화면에서 런타임 성능 문제가 드러났고, 이를 해결하기 위해 스타일링 방식을 바꿨다.

최종 선택은 TailwindCSS + tailwind-variants 였다.

• TailwindCSS: PostCSS 기반 컴파일 타임 스타일 처리로 JavaScript bundle 과 런타임 오버헤드를 줄임
• tailwind-variants: class conflict 방지, Variant API, 자동완성과 타입 세이프티 제공
• 토큰 기반 설정으로 색상, 간격, 폰트, breakpoint, radius 등을 쉽게 운영
• 풍부한 생태계와 IDE 지원으로 개발 효율을 유지

운영 과정에서는 시행착오도 있었다. Dialog 의 닫기 버튼 겹침, Tabs 의 underline 누락, ProductCard 의 pointer cursor 미반영처럼 버그가 생겼고, 이를 통해 완벽한 컴포넌트보다 빠른 배포와 피드백 이 더 중요하다는 점을 배웠다. 이를 보완하기 위해 Chromatic + Storybook 으로 컴포넌트 단위 리뷰와 QA 프로세스를 만들고, Wiki와 기여 제도를 열어 오픈 소스처럼 운영했다.

스펙 변경 관리도 중요한 과제였다. ProductCard 는 이미지 Preview의 extraBadge, 하단 Badge 그룹의 icon, 브랜드명 분리 클릭 등으로 여러 차례 바뀌었고, AOS/IOS/FE가 함께 맞춰야 해서 히스토리 관리가 필요했다. 그래서 GitHub Projects 로 컴포넌트별 진행 상황과 변경 이유를 추적하며 플랫폼 간 스펙 파편화를 줄였다.

결론은 분명하다. 처음부터 거대한 시스템을 만들기보다, 가장 필요한 컴포넌트부터 시작해 빠르게 적용하고, 자동화와 협업 구조로 유지보수 가능한 체계를 만드는 것이 0.5인 리소스에서 가장 현실적인 해법이다.