5개 브랜드가 함께 쓰는 시스템
디자인 시스템 #2. 멀티브랜드 디자인시스템 만들기
작은 간과가 만든 큰 비효율
처음 디자인 시스템을 만들었을 때, Foundation부터 차근차근 정리하고 버튼 같은 기본 컴포넌트들을 하나씩 만들어갔어요. 빠르게 성장하는 조직에서 뒤죽박죽이 된 UI 스타일을 정리하고, 디자이너의 생산성도 높일 수 있을 거라 기대했죠. 처음엔 아무 문제가 없을 것 같았지만, 막상 실제 서비스에 적용하려니 예상치 못한 문제가 터졌어요.
팀스파르타에는 스파르타클럽, 내일배움캠프, 항해99... 여러 브랜드가 공존하고 있거든요. 각각 추구하는 이미지가 다르고, 당연히 Primary 컬러도 달랐죠. 이런 멀티 브랜드 특성을 깊이 고려하지 않고 설계된 시스템은 컴포넌트를 만들면서 규칙을 정하기가 정말 어려웠어요.
힘들게 만든 버튼 컴포넌트가 사용되는 곳은 일부 프로덕트 뿐이었고, 시스템의 존재를 모르는 개발자 분도 있었어요. 다양한 컴포넌트를 품은 시스템으로 확장하려면 구조부터 다시 설계해야 했습니다. 큰 성장을 이룬 상황에서 완성도 측면의 도약을 위해 새로운 멀티브랜드 디자인 시스템의 필요성이 대두되었죠.
그렇게 두 번째 도전이 시작되었어요.
*멀티 브랜드 디자인 시스템이 왜 필요했을까?
궁금하다면 이전 글을 참고해 주세요 → "우리가 디자인시스템을 처음부터 다시 만드는 이유"
10개월 대장정의 시작
작동하는 디자인 시스템을 만든다는 건 생각보다 긴 여정이었어요. TF에선 작년 9월부터 약 10개월 동안 디자인 시스템을 구축했고, 최근에서야 리스트업했던 모든 컴포넌트 개발을 마무리했답니다. Foundation과 초기 컴포넌트가 배포된 건 11월쯤이라, 사내 구성원들이 새로운 디자인 시스템을 사용한 지도 벌써 반년이 지나가고 있네요.
첫번째 배포였던 Foundation 및 컴포넌트 배포 공지첫 번째 실패를 겪고 나니 무엇이 중요한지 더 명확해졌어요. 예쁜 UI 컴포넌트를 그리는 것과 실제로 작동하는 시스템을 만드는 것은 완전히 다른 영역이라는 걸 깨달았거든요.
앞으로 나아가기 위한 노력
초기에는 현실적인 문제가 있었어요. 디자인 시스템 전담 개발 리소스를 확보하기 어려워서, 서로 간 합의를 미리 맞추기 위해 TF 형태로 운영했거든요. 그때그때 리소스가 있는 개발자가 한 명씩 돌아가며 디자인 시스템을 맡는 구조였죠.
이 방식은 유연한 대신, 중간에 작업자가 계속 바뀌는 만큼 디자인 시스템에 대한 구조를 학습하는 시간이 필요했어요. 개발자가 바뀔 때마다 기존 코드를 파악하고, 컨벤션을 이해하는 데 시간이 걸렸답니다.
그래서 실험적으로 ‘AI 템플릿’을 만드는 시도를 했어요. 새로운 작업자가 빠르게 컨텍스트를 이해하고 작업할 수 있도록 가이드 역할을 하는 도구였죠. AI 템플릿은 디자인과 개발 요청 문서를 토대로 PRD와 템플릿 코드를 생성해주었고, 실제로 초기 개발에 드는 시간을 대폭 줄여주었어요.
이후 다행히도 개발자가 한 명으로 고정되면서 더 이상 필요하지 않게 되었지만, 당시에는 꽤 유효한 시도였다고 생각해요. 이런 경험을 통해 디자인 시스템을 만드는 데에도 맥락이 중요하다는 걸 배울 수 있었죠.
시스템의 완성은 ‘함께’
디자인 시스템은 단지 개발 작업만으로 완성되는 것은 아니죠. 디자이너도 리소스가 부족했기 때문에 한 명이 모든 걸 디자인하는 방식이 아니라, 각자가 맡은 컴포넌트를 책임지고 디자인을 완성했어요. 이후 총괄을 맡은 디자이너가 개발자를 위한 가이드를 정리하고 QA까지 진행했죠.
여러 명이 작업하다 보니 각자의 디자인 스타일이 드러날 수도 있어요. 그래서 초기에 디자인 시스템 제작 원칙을 명확히 정의하고 이를 토대로 디자인 피드백을 받았어요. 모든 컴포넌트가 하나의 목소리로 말할 수 있도록요. 덕분에 일관성도 챙기고, 모든 디자이너가 제작에 참여하면서 자연스럽게 시스템을 학습하기에도 수월했어요.
이렇게 만든 컴포넌트는 공통 패키지로 배포되어, 사내 다양한 프로덕트에 적용되고 있어요. 현재는 개발자가 디자이너의 세부 가이드 없이도 컴포넌트 커스텀 여부를 쉽게 파악하거나 복잡한 컴포넌트 조합 구현을 빠르게 할 수 있도록 온보딩하는 데 집중하고 있어요.
감사하게도 개발자분께서 디자인 handoff를 위한 플러그인 HUH를 만들어주셨어요. 덕분에 디자인 시스템의 전파도 훨씬 수월해졌답니다. 이런 게 바로 '함께 만드는 시스템'의 힘이 아닐까 싶어요. HUH 또한 멈추지 않고 지속적으로 개선하고 있어요. 개발해주신 원영님께 플러그인을 만들게된 목적과 앞으로의 방향성을 여쭤보았습니다.
복+붙하면 Button 컴포넌트 하나 뚝딱!“Handoff 플러그인 HUH를 만들게 된 이유는 ‘반복 작업 제거’와 ‘휴먼에러 방지’였어요. 개발자 분들 중 단순 반복 작업을 좋아하시는 분은 아마 없을 거예요. 플러그인이 있기 전까지는 모든 컴포넌트 하나하나 피그마의 속성을 보고 컴포넌트 코드를 직접 쳐야하는 반복 작업의 연속이었어요. 심지어 속성을 눈으로 보고 옮기는 작업은 의도치 않은 휴먼에러를 만들게 되고 개발자와 디자이너 모두 QA 목록 하나가 추가되게 만들었죠. 이걸 간단하게 ‘복사+붙여넣기’로 해결할 순 없을까? 라는 생각에서 출발해 HUH(Hybrid-Userinterface-Helper)를 만들게 되었어요. HUH를 사용하면 피그마를 단일 소스로 하기 때문에 코드 상에서 항상 피그마와 같은 값으로 코드가 나오게 되어 휴먼에러를 방지할 수 있게 됩니다.
앞으로의 목표는 시스템에 새로운 컴포넌트가 추가될 때마다 새로운 코드를 작성해야 하는 구조를 개선하고, 더 크고 복잡한 컴포넌트가 포함된 디자인도 AI를 활용해서 쉽게 뽑아내는 것이에요. 그리고 더 많은 분들이 사용해 주시면서 이슈를 제보해 주시길 기다리고 있습니다. ㅎㅎ”
- FE 개발자 허원영 님
플러그인 이외에도 개발자가 복잡한 컴포넌트를 학습 없이도 쉽게 구현할 수 있도록 도와주는 시스템 MCP도 만들어 전파했답니다.
부스터를 달아야 할 때
올해 4월부터는 디자인 시스템의 ver.1을 빠르게 완성시키는 데 집중했어요. 그리고 이제는 컴포넌트 단위를 넘어 프로덕트 별로 화면에 공통적으로 적용되는 더 큰 단위인 패턴과 템플릿을 고안해야 할 때입니다.
패턴과 템플릿이 완성되면 프로덕트의 완성도는 한층 높아질 거라고 예상하고 있어요. 일관성 있는 디자인은 예측 가능성을 높이고, 시각적으로도 더욱 안정감을 주게 되면서 완성도에 기여하게 될 거예요.
기능하는 시스템에서 발전하는 시스템으로
이제 우리는 '기능하는 시스템'을 넘어서 '유지되고 발전할 수 있는 시스템'을 고민하고 있어요.
디자인 시스템이 성공하려면 도입도 중요하지만 지속가능성이 더 중요하거든요. 새로운 요구사항이 생겼을 때 시스템을 어떻게 확장할 것인지, 기존 컴포넌트는 어떻게 업데이트할 것인지, 이 모든 변화를 어떻게 팀 전체에 전파할 것인지... 이런 것들이 진짜 어려운 문제들이에요.
아직 가야 할 길이 남아있지만, 이 여정에 함께한 모든 구성원의 경험이 하나하나 쌓여 디자인 시스템을 단단하게 만들고 있다고 믿어요. 무엇보다 첫 번째 실패 경험이 있었기에, 이번에는 더 견고한 기반을 만들 수 있었다고 생각해요. 실패도 좋은 스승이니까요:)
