최근 팀에서 디자인 시스템 구축을 맡게 되면서 자연스럽게 관련 리서치와 작업들을 진행하게 되었다. 디자이너와 개발자 사이에서 중간 다리를 연결하는 역할은 항상 꿈에 그리던 일이었다. 그러나 한편으로 이번 프로젝트는 개발자의 시선에서 디자인을 해석해야 하는 쉽지 않은 경험이었다. 이에 대한 간략한 후기를 공유하려 한다.
디자인 시스템이 필요한 이유
설 연휴 다음날 대표님과의 1:1 미팅 중에 갑자기 디자인 시스템에 관한 이야기가 나왔다. "근데 지금 우리한테 필요한 건 디자인 시스템인 것 같아요". 백엔드 개발자 출신 대표님은 지금도 종종 직접 코드를 작성하신다. 그럴 때마다 우리에게 요청하시는 부분은 바로 디자인 작업이다. "라디오 버튼이 들어간 기능을 개발했는데 디자인만 우리 서비스에 맞게 적용되면 될 것 같아요. 그런데 MUI 처럼 디자이너가 따로 작업하지 않고도 바로 적용해 볼 수 있는 정리된 시스템은 없을까요?". 부끄럽지만 나름 UX나 디자인 분야에 관심이 많다고 생각했던 나도 우리가 가진 디자인 시스템이 무엇인지 전부 파악하고 있지는 못한 상태였다. 디자인 시스템 구축에 대한 강한 동기부여가 일어나는 시점이었다.
디자인 시스템은 광범위하고 모호하다. 무엇을 정리해야 할까? 버튼부터 시작해야 할까? 디자이너가 먼저 정리를 시작해야 개발자가 이를 따라가는 것 아닌가? 쏟아지는 요청사항 때문에 바쁜 와중에 따로 디자인 시스템 구축을 위해 시간을 내기는 쉽지 않아 보였다. 그러나 누군가 시간을 내서 정리하지 않으면 계속 기존 코드를 복붙해서 사용할 수밖에 없었고, 이는 이미 심각한 문제를 일으키고 있었다.
"이 코드는 왜 여기에 들어 있는 거지?". 그동안 비슷한 기능을 하지만 디자인만 살짝 변형되는 경우 이를 복사해서 새로운 컴포넌트를 마법처럼 뚝딱 만들어 내는 경우가 많았다. 그러나 이렇게 되면 작성 의도가 다른 코드를 그대로 사용하게 되므로 새로운 기능에선 불필요한 코드까지 컴포넌트에 포함될 수밖에 없다. 이러한 방식은 당연히 좋지 않으며 최대한 기존 컴포넌트를 재사용하는 방식으로 작업을 진행하는 것이 바람직하다고 생각한다. 그런데 문제는 정리된 디자인 시스템이 없으면 특정 컴포넌트가 이미 만들어져 있는지조차도 알 수가 없다는 점이다!
디자인 시스템을 디자이너에게 부탁해야 할까?
이제 디자인 시스템이 정리되어야 하는 이유는 분명해졌다. 그런데 디자인 시스템을 정리하는 주체는 누가 되어야 할까? '디자인'이라는 단어가 들어갔다는 것은 이미 디자이너의 업무를 의미하는 것 아닐까? 그러나 디자이너가 과연 실제 인터랙션에 대한 결과를 미리 정의하고 정리할 수 있을까? 결론적으로는 개발자와의 협업 없이 완벽한 시스템 구축은 불가능하다고 생각된다.
개발자는 컴포넌트를 코드 뭉치로 바라본다. 디자이너는 컴포넌트를 주로 시각적인 박스 단위로 바라본다. 여기에서부터 관점의 차이가 발생하고, 이는 네이밍 방식에서 극명하게 나타난다. 개발자는 주로 컴포넌트의 기능을 중심으로 이름을 짓는 것 같다. 예를 들어 특정 컴포넌트가 사진 업로드를 위한 버튼이라면 PhotoUploaderButton 등의 이름으로 명명한다. 그러나 디자이너 입장에선 직접 눌러볼 수 없기 때문에 특정 버튼이 무슨 기능을 하는지보다는 시각적 특성이 더욱 중요하게 고려될 수밖에 없고, 따라서 Button_50(px) 등의 이름을 더욱 선호하게 되는 것 같다.
이처럼 디자이너와 개발자가 통일된 언어를 사용하기 위해서라도 디자인 시스템 구축의 시작점부터 함께 기준을 정리하는 것은 매우 중요하다고 생각된다.
디자인 시스템 구축 여정
그렇다면 어떤 방식으로 디자인 시스템 구축을 진행할까? 우리 팀은 최종적으로 디자이너가 개별적으로 정리해 오던 Figma와 노선의 디자인 시스템 내용을 storybook으로 옮기기로 하였다. 관련 내용이 여러 곳에 파편화되어 정리되면 열람 및 관리가 모두 어려워질 것으로 예상되었기 때문이다. 이를 위해서 Next.js 마이그레이션이 진행 중인 레포에 storybook을 함께 붙이고 배포까지 성공적으로 진행하였다.
storybook을 이용하면 위와 같이 기존 코드를 컴포넌트 별로 분리해서 문서화 및 테스트가 가능해진다
출처: storybook.js.org
이제 다음 과정으로 기존 코드에서 어떤 컴포넌트가 공통으로 사용되고 있는지 찾아서 이를 디자인 시스템으로 발라내는 작업이 남았다. 플러터로 구축된 앱과 웹의 공통 컴포넌트를 찾아 이름을 비슷하게 통일하려는 시도도 진행해보려 한다.
결론은 앞으로 갈 길이 멀었다!
디자인 시스템을 통해 얻을 수 있는 장점
그렇다면 과연 이 모든 고생을 통해 우리가 얻을 수 있는 장점은 무엇일까?
-
디자인을 다시 하지 않아도 된다!
가장 큰 장점은 디자이너의 작업 속도가 빨라진다는 점이다. 디자이너는 기획안을 보고 디자인 시스템에서 없는 부분만 다시 만들어서 개발자에게 전달하면 된다. 디자인 시스템에 새로운 컴포넌트가 추가되는 경우 기존에 정해진 룰을 통해 빠르게 작업이 가능해진다. -
코드를 다시 작성하지 않아도 된다
개발자들 또한 약속된 디자인 시스템을 이용하면 대부분의 작업을 기존 컴포넌트를 이용해서 빠르게 진행할 수 있게 된다. 가장 이상적인 환경은 관리자 페이지에서 디자인 시스템을 조합해서 개발자 없이 새로운 페이지 구성이 가능하도록 만드는 것이 아닐까. -
더 중요한 부분에 집중할 수 있게 된다!
디자인 시스템을 통해 추가적인 시간을 확보한 디자이너와 개발자는 이제 더 큰 단위의 고민을 할 수 있게 된다. 예를 들면 마이크로 서비스로의 이전이나 신규 스택 적용 및 사용성 개선 등... -
브랜딩 및 마케팅 분야에서도 일관성 있는 기획이 가능해진다!
디자인 시스템을 스토리북 등으로 공유하면 마케터는 기존에 어떤 시스템들이 있는지를 파악하고 광고 콘텐츠 제작 등에 응용할 수 있다. 마찬가지로 콘텐츠 팀의 경우도 현재 어떤 기능들이 추가적인 작업 없이 바로 제작 가능한지 파악할 수 있게 된다. -
기타 ...
수많은 장점들이 존재한다!
마무리
엔지니어들 사이에는 바퀴를 재발명하지 말라는 말을 자주 사용한다. 직접 모든 것들을 불필요하게 처음부터 만들기보단 이미 만들어져 있는 것들을 적용하는 편이 훨씬 효율적이라는 의미일 것이다. 디자인 시스템은 바퀴를 만들기에 앞서서 적어도 팀 내부에서 바퀴 비슷한 것을 만들었던 적이 있었는지 확인해 볼 수 있는 도구라고 생각된다. 대부분의 비용이 인건비로 투입되는 개발 환경에서 나와 팀원들의 작업 시간을 단축해 줄 도구를 만든다면 모두가 환영할 것이다.
집 정리도 그때그때 하지 않으면 나중에는 정리할 엄두가 나지 않을 정도로 할 일이 많아지게 된다. 지금부터라도 바쁘다고 미루고 정리하지 못했던 것들에 대해서 조금 더 관심을 가져본다면 어떨까.
