스타트업에서 디자인 시스템 만들기 1
어떻게 시작해야 할까?
회사를 그만둔 2017년까지 일해왔던 회사들에서의 디자이너들과의 협업은 시각적인 부분을 어떻게 할 것인지 정도만 협의하고 에셋 파일들을 퍼블리셔가 받아 마크업을 하고 그 파일을 받아 서버 데이터를 입히는 작업의 연속이었고 저도 그게 당연하다고 생각하면서 일을 했었습니다. 하지만 웹 컴포넌트들을 이용한 프레임워크들이 프런트엔드 쪽에 등장하기 시작하면서 퍼블리싱 영역을 개발자들이 대체하기 시작했고(물론 퍼블리셔 분들이 프런트엔드 개발로 확장하기도 합니다), 그 과정에서 새로운 협업 방식이 필요하다고 판단했습니다. 디자인을 적용할 프런트엔드 구조에 맞게 디자인 에셋들을 정리를 하고 반복되어서 사용되는 항목들을 줄이고 싶었던 것이죠.
하지만 시작조차 하지 못했었습니다. 시각화에 중점을 두고 주로 photoshop과 illustrator를 쓰고 있던 당시 디자이너들에게는 툴들(sketch, zeplin)을 도입하고 갑작스럽게 CSS나 웹 컴포넌트를 이해하기가 아마 힘들었을 것이라고 생각은 되지만, 정말 심각한 문제는 안타깝게도 스스로 자신들의 영역 한정시키며 그대로 머물 것을 원했기 때문이었습니다. 그래서 저와 당시 CTO는 아쉬운대로 CSS 템플릿들을 적극적으로 도입해 활용하기 시작했습니다. 디자이너들이 잡은 컨셉을 살리면서 큰 틀은 부트스트랩을 확장하거나 작은 프로젝트들 같은 경우에는 유료 템플릿을 결제해 사용했습니다. 하지만 메인 서비스들에 브랜드를 녹여내기엔 한계가 있고 디테일한 커스터마이징이 힘든 건 이러한 CSS 템플릿들의 cons였기 때문에 조금 더 함께 놀아봤으면(각종 툴들을 이용한 협업) 좋겠다는 아쉬움을 항상 가지고 있었던것 같습니다.
시간은 흘러 스타트업의 코 파운더가 되어 밤새 계속하여 바뀌는 MVP를 개발하다 보니 자연스레 CSS 템플릿을 적극적으로 활용했습니다. (초기 스택은 vuejs + nuxt + vuetify) 덕분에 빠른 프로토타이핑이 가능해 회의를 할 때 라이브로 코딩을 해가며 빠른 의사 결정에 많은 도움을 되었었습니다. 하지만 템플릿에 맞춰 UI/UX를 만들어갈수록 우리만의 디자인 시스템의 필요성을 절실히 느꼈습니다. 커스터마이징을 위해 여러 CSS 템플릿을 뜯어보기 시작했고 공통적으로 쓰이는 패턴들이나 아쉬운 부분은 어떻게 개선을 해야 할지 머릿속에 그리고 계획을 세우기 시작했고(매일 밤을 머리를 쥐어 뜯으며 고민을 합니다) 다음 서비스를 위해 UI/UX 디자이너분들 채용(디자인 시스템에 대해 이해도가 있는)하게 되면서 더 이상 미룰 필요가 없겠다라는 생각에 본격적으로 시작을 하게 됐습니다.
We’re not designing pages, we’re designing systems of components.
- Stephen Hay
케어닥의 첫 MVP를 시작했을 때 고민할 것도 없이 부트스트랩을 확장해서 사용하면서도 최소한의 정리는 해나가며 개발을 하고 싶었습니다. (언제 올지 모르는 협업의 날을 위해...) style guide 정도는 만들어야겠다는 생각에 레퍼런스를 찾아보다 접한 것이 atomic design (http://bradfrost.com/blog/post/atomic-web-design)이라는 방법론 이었습니다. 이 방법론은 단위를 나누고 하위 단위가 모여 상위 단위가 되는 개념으로 웹 컴포넌트에 상당히 fit하게 느껴졌기 때문에 저에게는 굉장히 인상적인 방법론이었습니다. 그래서 atomic design을 바탕으로 CSS 템플릿을 만들기 시작했고 style guide를 만든 경험을 토대로 조금 변형해서 케어닥 디자인 시스템의 단위를 정의하기로 했습니다.
케어닥 디자인 시스템의 요소 단위요소 단위
atoms - 가장 작은 단위 (icon, text, image 등 더 이상 쪼갤 수 없는 요소)
elements - interaction이 가능한 atoms로 이루어진 최소 단위
components - functions와 events를 가지는 atoms, elements들로 이루어진 단위
templates - components들로 이루어진 구성의 의도를 가진 단위
pages - templates들로 이루어진 page
그 외 요소
layouts - container, grid, flex 등 틀을 잡아주는 요소들
variables - color, font, spacing 등 값을 가지는 요소들
animations - interaction시 사용되는 각 종 효과들
atomic design의 단위를 그대로 따르지 않은 이유는 단순히 단어가 생소하고 실제 코드레벨에서 나누기 수월하게 하기 위함입니다. 그리고 나름의 정의를 해야 모호한 순간이 왔을 때 따를 기준이 있는 것이 나을 것 같다는 이유에서죠. 모든 요소 단위는 코드 레벨에서 구현될 때 native(web, android, ios등 코드 레벨) 라이브러리의 폴더 단위가 될 것입니다. 또 templates와 pages를 제외한 요소 단위는 모두 native library의 component로 작성될 것입니다. 예를 들어 text atom component는 props로 크기, 서체 스타일, 굵기 등을 가진 native library component가 될 것이고, button element component는 props로 크기, 색상, 비활성화 여부 등을 가지며 text atom component와 icon atom component을 포함하고 fade animation을 가진 native library component가 될 것입니다. 실제 코드레벨에서 사용하는 native 라이브러리와 요소 단위들을 통일함으로써 직관성을 획득해 디자이너와 개발자의 소통을 원활하게 해 주고 또 처음 시작하는 팀 동료들의 러닝 커브를 줄이는데도 도움이 될 것입니다.
단위 정리를 마쳤으니 어떻게 일할 것인가에 대해 고민을 해보겠습니다. 먼저 스케치에 디자이너가 심벌 기능을 이용해 합의된 모든 요소들을 정리를 하는 것부터 시작을 합니다. 초안과 시안 등을 관리하는 것이죠. abstract를 이용하면 굳이 sketch를 통하지 않고도 개발자들이나 기획자들이 쉽게 확인 할 수 있습니다.
abstract로 sketch의 symbol을 preview할 수 있습니다.
그리고 그 작업 결과물을 zeplin에 있는 스타일 가이드를 이용해 native의 style code로 뽑아냅니다. (extension을 설치해 css나 sass 혹은 안드로이드, iOS같은 native 스타일로도 뽑아낼 수 있습니다) 이렇게 뽑아낸 스타일 코드를 개발자들이 디자인 시스템 native 라이브러리의 해당 요소 컴포넌트에 style code를 적용하는 것이죠.
sketch를 기준으로 style guide기능을 이용해 style code를 뽑아냅니다.디자이너는 sketch에서 zeplin까지, 그리고 개발자는 zeplin에서 native 코딩까지 하게되며 zeplin으로 협업을 하고 소통을 할 수 있는 명확한 창구가 생겼습니다. 물론 디자이너와 개발자 사이에서 단위에 대한 협의가 선행되어 zeplin의 components group과 native library의 폴더 구조가 일치 하므로 소통이 수월해 집니다.
수정 사항이나 추가 사항이 있을 때는 결정권자와 디자이너 그리고 개발자가 함께 초안과 시안을 보고 결정이 되면 디자이너가 sketch(혹은 abstract)에서 시안을 확인하고(추가 요소 생성이나 변경 등) 작업 후 zeplin에 올리기만 하면 개발자는 디자인에 신경 쓰지 않고 zeplin에서 얻은 스타일 코드만 넣으면 되기 때문에 시안과 실제 구현의 격차가 없어지게 되고 추가적으로 TDS(toss design system)을 보신 분들은 아시겠지만 실제 화면을 보듯이 스토리보드를 만들 수 있게되는 것이죠.
PS. sketch 원본에 대한 버전 관리와 추 후 추가 디자이너 채용을 대비해 abstract로 형상관리를 하고 디자인 시스템의 릴리즈 버전을 맞추게 되면 상황 파악까지 수월해지게 됩니다. (abstract에 관련된 내용은 추 후 독립된 article을 작성 할 예정입니다)
결과적으로 스토리보드와 실제 구현의 격차가 줄어드는 것이 가장 중요한 포인트이고 기능 추가가 이루어질때마다 기획 -> 디자인 -> 개발이라는 비효율적인 워터폴 구조에서 함께 화면을 봐가면서 기획의도에 맞는 구성만 합의하고 디자인이 나올때까지 개발을 미뤄둘 필요 없이 만들어 놓은 라이브러리에서 그에 맞는 컴포넌트를 가져다 쓰기만 하면 되기 때문에 빠른 기능 개발이 가능해지게 되는 것이죠. (실제로는 엣지 케이스들이 수도 없이 생기겠지만...)
이번 글에서는 전체적인 플로우를 어떻게 해야할지에 대한 고민과 과정을 공유했습니다. 코드 레벨까지 어떻게 진행이 되는지 봤으니 이제 개발자들이 어떻게 놀지를 정하고 놀 판(git 저장소, 보일러플레이트)을 만들어야 하겠습니다(물론 CTO가...)
