CTO와 UI/UX 디자이너 단 둘이 do it
Design System
최근 design system이 핫합니다. 토스뿐만 아니라 원티드도 그렇고 스타트업 씬에서 가파르게 성장하고 있는 스타트업들을 보면 기본으로 디자인 시스템을 가지고 있습니다. 토스의 영향이 크겠지만 (콘퍼런스를 통해) 왜 필요한지에 대한 배경 지식이 없는 디자이너들에게 마치 마법처럼 들리기도 하는 듯합니다. 자칫 주니어 디자이너들에겐 디자인 시스템만 있으면 일을 덜 하면서 개발자랑 소통도 더 잘된다는 환상을 가지기 쉬워 막연한 동경을 가지게 될 수도 있다고 생각하니 조금 걱정이 되기도 합니다.
지난주 디자인 스펙트럼 X 원티드의 스펙트럼콘 2019에 참석해 김세홍 원티드 공동창업자의 연사에서부터 첫 번째 세션 (라이트닝 세션 전까지)까지 디자이너의 역할의 확장을 이야기를 듣고 많은 공감을 했습니다. 과거의 디자인이 시각화에 중점을 두었다면 (이미지 작업이 주된 업무) 이제는 아이디어나 리서치, 사용자 분석을 통한 디자인으로 확장이 되었기 때문에 어찌 보면 자연스러운 영역의 확장이 된다는 생각이 들었습니다. 자연스러웠나 알아보기 위해 지난 10년간 제가 겪은 프로세스를 한번 되돌아보겠습니다
과거의 워터폴 방식에서는 기획을 하고 그 기획서에 따라 디자인을 하고 개발에서는 그것을 가져다 쓰는 정도로만 분업화가 되어 있었습니다. 산출 파일의 정리와 분류가 중요했고 그것이 일을 잘하는지 못하는지의 척도가 되었던 시기였음을 겪어보신 분들은 이해하시리라 믿습니다. 포토샵과 일러스트레이터의 달인들이 최고 주가를 찍을 시절 최종의 최종 최종 진짜 최종 파일이 난무하던 시절이 되겠습니다. (이 시절에도 정리나 분류에 의해 미약하게나마 디자인 시스템이라는 게 존재했다고 생각합니다.)
그에 비해 현재의 서비스는 끊임없이 변합니다. 사용자들의 반응에 대응하고 사로잡아 우리가 원하는 CTA(Call To Action)까지 도달하게 하기 위해선 수도 없이 퍼널(Funnel)을 만들고 실험을 해야만 하기에 에자일 방식의 주 단위 스프린트(하...)를 달리는 게 일상입니다. 이 과정에서 누구보다 중요한 사람은 아마 사용자를 분석하고 설득해내는 디자이너가 될 것입니다. 이들은 자연스러운 서비스 흐름을 만들기 위해 UI/UX를 wireframe으로 만들고 지표 데이터를 이용해 사용자의 행동을 분석해 Interaction으로 유도하는 등 서비스 전반에 걸쳐 깊이 관여하고 있습니다. 이렇듯 기획에 걸치고 개발에 걸치다 보니 기획자와 개발자와 더욱 긴밀할 소통을 위한 방법이 필요하게 됩니다. 서로 다른 국적의 사람들이 만나면 공용어를 써서 소통하는 것처럼 말입니다. 그래서 디자이너들은 가이드라인을 만들고 브랜드를 녹여내 design system을 만들게 됩니다. 그런데 design system은 어디서부터 시작되었을까요?
꽤 오래전부터 개발자들은 style guide라는 것을 만들어서 관리해 사용해왔습니다. 디자이너들이 공급해준 에셋들을 자신들이 개발해야 하는 style code로 정리를 해두는 것이었죠. 아마 개발자들에겐 습관적인 일이었을 것입니다. 개발자들에게는 "DRY (Do not Repeat Yourself)"라는 좌우명이 있기 때문이죠. 시스템을 설계하고 코드를 작성할 때처럼 재사용을 위해 style code들도 정리를 하기 시작하게 된 거죠.
많은 개발자들이 디자인을 입히는 작업이 반복적이고 고되다는 것을 알고 있습니다. 하지만 이렇게 정리를 해놓으면 반복하는 작업들이 줄어들어 편-안 해지는 뽕을 맞을 수 있는 것이죠. 하지만 위 사진에서 보시면 알겠지만 개발자들이 디자인 감각을 가지기란 쉽지 않습니다. (타고나는 것 같습니다.) 그래도 많은 노력을 거쳐 서로의 업무를 줄여주고자 너도 나도 정리해 공유하기 시작합니다.
트위터에서 만든 bootstrap은 아마 모르시는 분이 없을 정도로 유명할 거라고 생각됩니다. 이러한 템플릿들이 많아지면서 디자이너가 없는 개발이 가능해지게 되었고, 수많은 MVP들이 탄생하면서 스타트업에 힘을 보탠 건 자명한 사실일 테니까요.
이런 style guide처럼 잘 정리된 템플릿이 있으면 빠르게 성장하는 스타트업에서 일하는 디자이너는 일이 정말 편해지는 건 당연한 일일 것입니다. 하지만 정해진 템플릿으로는 브랜드를 녹여내기 더 힘들뿐더러 종속성 때문에 커스터마이징이 힘들다는 한계가 있기 때문에 자체 템플릿이 필요해지게 됩니다. 더 나아가 내 의도를 명확히 보여 주고 내가 디자인한 버튼의 색과 모양 그리고 버튼을 눌렀을 때나 마우스가 올라갔을 때 또는 버튼이 비활성화되었을 때의 귀여운 interaction을 생각대로 구현해 내려면 design system이 필요해지게 됩니다. 또 최대한 내 의도와 근접하게 구현되길 바란다면 coding에 대한 필요성도 생깁니다. 실제 샘플 코드를 작성함으로써 가이드를 해주는 것이죠. 이런 이유로 최근 coding에 관심을 가지는 디자이너가 많아지는 건 아마 대부분 느끼고 계시리라고 생각합니다.
style guide는 design system의 일부입니다. marketing design guide나 interaction guide도 포함될 수 있는 것이죠. 더 나아가 위에서 언급한 내용처럼 브랜드를 녹여내 일관성 있는 서비스들을 제공할 수 있게 된다고 생각하면 design system을 안 할 이유는 없다고 생각합니다. 토스니까 가능한 거야, 그래도 큰 투자를 받고 사람이 많아서 가능한 거야 라는 이야기를 많이 들었지만, 규모에 맞게 시작하면 된다고 생각합니다. 큰 호흡보다는 작은 호흡으로 하나하나 만들어 나가다 보면 언젠간 큰 똥이 되기 마련이니까요. 작게 시작하면 됩니다. 처음엔 style guide에서부터 interaction, composition 등 확장해 나아가면 되는 것이죠.
결국 제가 생각하는 design system이란 역할에 대해 고민하고 정리하고 또 소통을 위한 노력이 배경이 되어야 나오는 결과라고 생각합니다. 아무래도 시니어 디자이너들의 무수한 투쟁의 경험을 바탕으로 만들어지게 되는 것인 게 아닐까 생각합니다. 대부분의 사람들은 자신이 아는 범위에서 일을 마무리하고 싶어 하고 새로운 것을 익히는 것에 대해 두려워하는 경향이 있으니까요. 그렇기 때문에 당연한 이야기지만 주니어보다는 시니어의 역량이 중요한 것 같습니다. 팀장의 능력에 따라 제한이 생기는 건 자명하지만 팀원의 능력에 팀의 능력이 좌우되진 않으니까요.
저는 개발자이고 CTO로써 design system을 꽤 오래전부터 구상하던 중 최근에 운이 좋게도 열정이 있는 UI/UX 디자이너분을 채용하게 되었습니다. 그래서 이제 막 MVP를 마친 스타트업에서 CTO와 UI/UX 디자이너 단 둘이 본격적으로 작은 규모에서의 design system은 어떻게 만들어 나가는지를 공유할 예정입니다. 디자인 시스템에 대해 정리를 해 나갈 예정입니다.