디자인 시스템 그거 중요해요?
디자인 시스템 도입기
나의 첫 디자인 시스템
디거에서 새로운 서비스(디고)를 기획하고 개발을 시작할 때쯤의 시기였다. 프론트엔드의 팀원 중 한 명이 아토믹 디자인 이라는 토픽을 가지고 팀에 공유하면서 처음으로 디자인 시스템에 대해서 알게 되었다. 이후 디자인 시스템에 관해서 공부하면서 우리에게 충분히 도움이 될 거라는 생각이 들었고 팀 내에서 잘 활용해 보자는 공통의 목표 / 합의가 이루어지는 순간이었다.
사실, 이때까지만 해도 나는 디자인 시스템과 디자인 패턴을 정확하게 이해하지 못하고 있었고 코드의 영역에서도 이런 시스템을 많이 적용하려고 노력을 같이했었다. 성공적이지는 못했지만 나름의 성과들은 있었다.
아토믹 디자인
이야기를 시작하기 전에 간략하게 아토믹 디자인(시스템/패턴)에 대해서 이야기하고 넘어가야 한다. 아토믹 디자인은 가장 작은 컴포넌트를 원자(Atomic)로 정의하고 원자의 합을 분자(Molecules) 그리고 이런 분자로 이루어진 동작하는 컴포넌트를 유기체(Organics)로 정의한다. 추가로 동일한 디자인 구조를 정의하는 템플릿(Template), 실제 유저에게 서빙하는 페이지(Page)로 이루어진 꽤 복잡하고 각각의 개념이 사람에 따라 다르게 받아들여질 수 있는 위험성이 있는 시스템이다.
물론 처음에는 이런 위험성에 대해 크게 받아들이지는 않았다. 하지만 시간이 지남에 따라 서서히 깨달았다. 특히 분자와 유기체의 구분이 엄청나게 힘들었는데 내부적으로 비즈니스 로직을 유기체에 담는 거로 팀 내의 룰로 정의했다. 여기서부터 컴포넌트로서의 디자인 시스템과 개발 아키텍처에서의 디자인 패턴(시스템)을 혼동해서 사용했다. 이런 혼합 사용은 장점도 있지만 단점도 크게 있다. 모든 코드의 위치 결정이 어려워지고 억지로 끼워서 맞추는 작업이 필요하다. 마치 똑똑하진 않지만, 힘쎈 아기처럼..
성공적인 디자인 시스템 적용
이런 다양한 어려움이 있었지만 아토믹 디자인을 팀 내 적용하기 시작했다. 먼저 디자인 팀원들과 컴포넌트를 두고 이야기하기가 엄청나게 편리해지기 시작했다. 기존에 단순히 큰 버튼 / 작은 버튼처럼 규칙 없이 각자의 용어로 이야기하던 내용이 BaseButton / DisabledButton 등등 팀 내에서 정의한 이름으로 부르기 시작했다.
프론트엔드 내에서도 이런 효과가 긍정적으로 일어났는데 각 컴포넌트 이름을 디자인팀과 맞추어 개발하기 시작했고 컴포넌트에 대한 고민 없이 개발을 원활하게 진행할 수 있었다.
위에서 이야기했던 유기체에만 비즈니스 로직을 통합시키기로 했던 팀 내 룰도 생각보다 유효해서 개발 생산성이 높아졌고 비즈니스 로직을 각 컴포넌트로 분산시키거나 디펜던시가 중복되는 여러 문제를 해결해 주었다. (경험이 많은 개발팀이였다면 다른 방법을 사용해 볼 수 있겠지만 당시 주니어들로만 이루어져 있던 작고 소중한 팀이었던 점을 감안해야 한다. 모두 비즈니스 로직을 어떻게 어떤 방식으로 배치해야 좋은지 아무도 몰랐다.)
이런 경험덕에 나는 팀 내 통일된 디자인 시스템과 설계 방법이 큰 영향을 미친다는 걸 깨달았고 팀 크기의 정도를 떠나 중장기적인 목표를 이룰 수 있게 도와준다는걸 느꼈다. 이후 진행하는 모든 프로젝트에 디자인 시스템을 도입하기 위해 노력했다.
디자인 시스템 설득하기
디거의 경험은 여기서 마무리하고 시너지 에이아이에서 프론트엔드에 조금 더 많은 영향을 미칠 때 이야기이다. 당시 디자이너분과 이야기하는데 디자인 시스템을 처음 경험해 보시는 분이었다. 이때 경험이 재밌었는데 디자인 시스템에 대한 중요성을 전파하고 실제 서비스에서 디자인 시스템이 어떻게 사용되고 있는지 깊게 찾아보는 계기가 되었다.
에어비엔비 디자인 시스템이나 토스의 디자인 시스템을 참고했다. (에어비엔비 디자인 시스템: https://www.figma.com/community/file/1233410639171582044/airbnb-design-system) 해당 사이트에 들어가 어떤 방법으로 디자인 시스템이 활용되는지 분석했으며, Material Design System (https://m3.material.io/) 등 다양한 디자인 표준들을 경험할 수 있었다.
이런 자료를 기반으로 팀내에서 잘 사용될 수 있는 디자인 시스템을 찾고 적용시키는 작업을 팀내에서 함께 진행했다. 이런 디자인 시스템을 도입하고 개발 생산성과 디자인 생산성이 비약적으로 상승하여 우리는 빠르게 원격 진료 앱을 0 to 1 할 수 있었다.
디자인 시스템 그거 중요해요?
누군가가 나에게 "디자인 시스템 그거 중요해요?"라고 물어본다면 나는 "네! 당연하죠. 엄청나게 중요합니다!"라고 대답할 것 같다. 위의 두 경험을 제외하고도 다양한 프로젝트에서 디자인 시스템이 유효했고 팀이 지속적인 속도를 내는 데 큰 영향력을 미쳤다.
같은 용어로 컴포넌트를 부르고 규격화된 디자인은 단순히 메이커들뿐만 아니라 사용자들도 편안함을 느끼게 해주며 같은 Theme으로 통일성을 부여하여 내가 어떤 서비스를 사용하는지 무의식적으로 파악할 수 있게 해준다.
"팀이 작아서 디자인 시스템을 구축하는 것 보다 개발이 우선이에요." 이런 의견을 피력해 주시는 분도 있을 것으로 생각한다. 디자인 시스템은 엄청나게 어렵고 시간을 많이 쏟아야하는 것이 아니다. 앱에 어떤 테마의 색상들을 사용하고, 어떤 폰트를 사용할 건지 먼저 정하는 것만으로도 디자인 시스템 구축의 첫 단추를 끼웠다고 할 수 있다.
그다음 할 일은 버튼은 어떻게 쓸 건지, 입력창은 어떻게 디자인하고 이름은 어떻게 부를 것인지에 대해 정하면 된다. 디자인 시스템은 어려운 게 아니라 자연스럽게 정의해나가면 된다. 팀이 작아서 초기에 개발 속도를 저하시킬까봐 걱정하지 말고 바로 디자인 시스템을 구축해 나갔으면 좋겠다.
