최종의 최종.system
리디의 디자인 시스템은 크게 버전 1과 버전 2로 나눌 수 있습니다. 버전 1은 리디가 '전자책' 플랫폼을 추구하고 있을 당시 만들어지기 시작한 디자인 시스템입니다. 하지만 리디는 웹툰을 중심으로한 콘텐츠 서비스로 도약하고 있기 때문에, 이전에 만들어진 디자인 시스템의 비주얼을 서비스에 적용하기엔 올드함이 있었습니다. 또 버전 1의 시스템 개발의 진도가 많이 나가지 않았었기에 비주얼을 비롯해 시스템의 구성 자체를 바꾸는 데 큰 제약이 없었습니다. 따라서 버전 1에서 만든 큰 틀을 기반으로 버전 2를 만들기로 결정했습니다.
디자인 시스템의 시작
그럼 버전 1의 리디 디자인 시스템은 어떻게 시작되었을까요? 대부분의 디자인 팀이 다 그렇겠지만, 리디도 여러 프로덕트와 플랫폼간의 일관된 시스템의 필요성을 느껴 디자인 시스템을 만들게 되었고, 제가 합류했을 때는 이미 디자인 원칙과 UX 라이팅, 컬러 파운데이션은 정의가 된 후였습니다. 그러고 나선 웹 컴포넌트를 정의하고 있던 차에 함께 작업을 시작하게 되었습니다.
함께 작업하기
여기서 '함께' 작업이란 프로덕트 디자이너 모두가 디자인 시스템에 오너십을 갖게되는 것을 의미하는데요. 시스템화 해야하는 여러 컴포넌트들을 1인 1개씩 맡아 작업하는 방식으로 진행했습니다. 농담식으로 서로를 '스낵 바 위원장', '다이얼로그 위원장', '다크테마 위원장'이라고 부르기도 했습니다.
이렇게 프로덕트 디자이너이자 디자인 시스템 위원장 모두가 일주일에 한 번, 3시간정도 디자인 시스템 작업을 하는데요. 저희는 이 날을 '디자인 시스템 데이'라고 부르며 모든 프로덕트 디자인 업무를 내려놓고 디자인 시스템에만 집중해 작업하는 시간을 따로 마련했습니다.
디자인 시스템 데이는 각자 맡은 컴포넌트가 현재 프로덕션에서 어떻게 사용하고 있는지, 어떤 부분을 개선해야하는지의 리뷰를 거쳐 글과 가이드라인의 형태로 완성해 디자인 시스템 홈페이지에 올라가게 됩니다. 디자인 리뷰는 디자인 시스템 데이에 모든 구성원들이 함께 진행하고, 글 리뷰는 1인당 2인의 리뷰어를 정해 서로의 글을 리뷰해주는 방식으로 진행했습니다.
글 쉽게 올리기
디자인 시스템 홈페이지는 지킬로 만들어져 디자이너들이 마크다운 문서로 작성해 소스트리를 통해서 직접 업로드하는 방식이었는데요. 아무래도 코드에 익숙하지 않는 디자이너는 글을 업로드하는 데 장벽이 생길 수 밖에 없었습니다. 이 문제로 고민하던 와중에 디자인 시스템 문서를 효과적으로 만들고 관리할 수 있는 제로하이트라는 툴을 만나게 되었고, 지킬에서 제로하이트로 이사를 결정하게 되었습니다.
버전 2의 서막
제로하이트로 이사도 어느정도 끝내고 디자인 시스템을 마무리해가던 중, 리디에 큰 변화가 생겼습니다. 앞서 말한 웹툰을 중심으로 한 비전과 디자인 팀 구성원의 변화였습니다. 이전엔 프로덕트 디자이너 모두가 디자인 시스템에 참여했다면, 새로운 구성원은 디자인 시스템에 특화된 멤버들만 참여하기로 했습니다.
또한 전체적인 디자인 룩을 변경하기로 결정되어, 그동안 만들었던 파운데이션과 컴포넌트의 룩이 전부 변화해야 하는 상황에 놓였습니다. 이를 위해 모든 디자인 룩을 다 만들기 전까지는 작업 속도를 느리게 만드는 가이드라인 문서화 작업은 지양하고 우선 시안 위주의 작업을 해나가기로 결정했습니다.
새로운 시스템의 방식
새로운 디자인 룩과 함께 새롭게 고안한 방식은 바로 아토믹 디자인 방식이었습니다. 이전에 리디가 일하던 방식은 이해관계자가 수차례 리뷰를 거쳐 하나의 버전으로 제품을 릴리즈하는 방식이었다면, 이제는 A/B 테스트로 가설을 실험하고 빠르게 검증하는 방식으로 변화하고 있기 때문입니다. 따라서 새로운 디자인 시스템도 이전보다 좀 더 구조적이며 변화에 유연한 시스템이 필요했습니다.
또 한가지 새로운 방식은 디자인 토큰의 도입입니다. 디자인 토큰은 파운데이션 요소 중 컬러부터 적용하기로 결정했는데요. 이전엔 디자이너 개인의 판단으로 컬러를 적용하는 작업 방식을 사용하다보니, 같은 위계를 가져야 하는 컬러도 각기 다른 컬러가 적용되어 있는 일이 빈번했습니다. 이를 방지하기 위해 컬러 토큰을 Global 수준에서 Alias, 또는 Component-specific 수준까지 끌어올려 알맞은 위계를 일관되게 적용할 수 있도록 설계했습니다.
아토믹 디자인 적용하기
아토믹 디자인 방식을 사용하기 위해서는 먼저 무엇이 원자이고 분자인지 정의하는 일이 필요했습니다. 여러 방면으로 실험해 본 결과, 리디 디자인 시스템에는 아래와 같은 원칙을 적용할 수 있었습니다. (모든 컴포넌트에 동일하게 적용할 수는 없지만 대략의 뼈대가 이러합니다.)
•
Atom: 컴포넌트를 이루는 작은 단위, 혼자 독립적으로 존재할 수 없음
•
Molecule: Atom을 모아 만든 하나의 유기체, 컴포넌트의 모습을 띄고 있음
•
Instance(Organism이상): Molecule에서 파생되는 베리에이션, 실제 시안에 쓰이며 컬러 테마를 포함하고 있음
처음에는 기존 컴포넌트를 아토믹 방식으로 해체하고 재구성하는데 꽤 많은 시간이 소요되었습니다. 제가 해보겠다고 호기롭게 외쳤지만 너무 많은 시간이 소요되니 "헉" 하는 두려움도 들기 시작했습니다. 하지만 실험 끝에 원칙을 세우고 작업에 익숙해지다보니 아토믹으로 변환하는 작업 시간이 확 줄어들기 시작했습니다.
무엇보다 실제로 어떤 한 요소를 전부 변경해야 하는 일 앞에서 아토믹 디자인 시스템이 빛을 발하게 되는데요. 말 그대로 "유연한" 시스템이 되어가는 것을 눈앞에서 지켜보고 있으니. 아토믹 방식으로 바꾸기 잘했다는 생각이 들었습니다.
디자인 토큰 적용하기
파운데이션 요소를 다시 정리하면서 라이트 테마, 다크 테마에 호응하는 컬러 팔레트도 재정리하게 되었는데요. 기존엔 컬러 명도에 따라 모두 같은 컬러를 적용했다면, 새로 만든 시스템엔 디자인 토큰을 이용해 같은 컬러라도 다른 쓰임새라면 다른 컬러 팔레트를 적용하게 됩니다. 다만 가장 기초가 되는 글로벌 토큰의 컬러 값을 그대로 계승해야하기 때문에 figma tokens를 이용해 Alias 토큰과 Component-specific 토큰을 구축했습니다.
예를 들어 #ffffff라는 hex코드를 라이트 테마의 글로벌 토큰에 #255라는 이름으로 등록했다면, bg의 base는 #ffffff를 그대로 적용하는 것이 아니라 $colors.light.global.255라는 이름으로 적용하는 것입니다.
이렇게 되면 어떤 한 컬러를 바꿨을 때 영향 받지 않아야하는 컬러들까지 변화하는 불상사를 막을 수 있는데요. 다만 작업자 입장에서는 각 쓰임새마다 컬러를 다르게 입혀야 하기 때문에 이전보다 손이 더 많이 가게 됩니다. 때문에 작업 시간을 줄일 수 있는 방법도 함께 고민하기 시작했습니다.
이전에는 컬러 팔레트가 1:1 호응이 됐었기 때문에 작업자가 컴포넌트를 만들 때 손수 컬러 값을 입혀놓고 컴포넌트의 오버라이드만 바꾸는 식으로 작업을 했었는데요. 지금의 컬러 팔레트는 색을 입히는 작업이 까다롭기 때문에 테마를 바꾸는 공수를 덜어보고 싶었습니다. 그러던 도중 themer라는 툴을 만나게 되었고 이미 컬러를 토큰화 시켜놓은 뒤라 themer가 손쉽게 동작할 수 있는 환경이 되었습니다. 덕분에 작업 소요 시간도 기하급수적으로 줄어들 수 있게 되었고요!
글을 마치며
제품과 마찬가지로 디자인 시스템도 완성이 없으며 계속해서 개선해 나가야합니다. 그 과정 안에서 어떻게하면 제품 디자이너와 엔지니어가 더 좋은 생산성을 낼 수 있고, 사용자에게 일관된 경험을 줄 수 있는지 계속 고민하면서 말입니다. 프로덕트 디자이너가 시스템을 만드는 일은 진도는 조금 더디지만, 시스템과 제품의 싱크를 맞추는 가장 좋은 방법일 수도 있겠습니다. 시스템이 견고해질 수록 우리는 더 많은 시간을 사용자에게 쓸 수 있으니까 말입니다. 모쪼록 제품과 사용자 경험 개선에 긍정적인 영향을 미칠 수 있는 디자인 시스템이 되었으면 좋겠습니다.
