위메프로그

안녕하세요! 저는 위메프 디자인시스템(이하 WDS)을 만들고 있는 프론트엔드 개발자입니다.

WDS 스쿼드에서 함께 일하고 있는 디자이너 위즈가 지난 글에서 WDS의 개념과 탄생 배경에 대해 자세히 소개했는데요. 저는 오늘 좀 더 실무적 관점에서 WDS 구축 과정과 또 효율적인 시스템 운영을 위해 어떤 개선점에 주력하고 있는지 이야기를 해볼까 해요!

WDS가 뭐였더라… 왜 필요한 거죠?

위메프 WDS 개념 알기

우리는 언어를 통해 소통하죠. 컴퓨터도 프로그래밍 언어가 있고요. 하나의 프로덕트를 만들 때도 언어가 필요해요. 디자이너, 기획자, 개발자 등 많은 직군들이 참여하다 보니 가끔은 같은 사안에 대해서도 서로 이해하는 맥락이 달라 커뮤니케이션이 어긋날 때가 종종 있거든요.

WDS는 그래서 만들어졌어요! 말 그대로 공통된 약속이라고 할 수 있죠! 예를 들어, 자주 사용하는 HEX, RGBA 값을 primary, secondary 등의 알기 쉬운 이름으로 바꿔서 color에 대한 기준을 마련해요. 이것을 디자인시스템을 이루는 파운데이션 혹은 디자인 토큰이라고도 부르는데요.

뜻이 있는 이름으로 색깔을 부르면 기억하기 쉽고 사용하기도 편해요. 가령 아래 그림 예시처럼 '#DC3535' 대신 primary라고 쓰는 거예요. 확실히 커뮤니케이션 비용도 줄고 생산성이 절로 올라갈 것 같지 않나요?

그래서 어떻게 만드나요?

WDS를 만들기 위해 우선 디자이너, 개발자, 기획자가 공동의 목표를 가진 스쿼드 조직에 함께 모였는데요.

일의 순서는 이렇습니다. 기획, 디자인팀에서 컴포넌트에 대한 정의와 디자인을 한 후, UI개발팀에서 디자인된 컴포넌트에 CSS 작업을 해요. 그 후 프론트엔드 개발자가 컴포넌트 구조 props에 대한 정리를 하고 최종적으로 NPM에 라이브러리를 배포하죠.

이후 실제로 디자인 시스템 컴포넌트를 적용하면서 생기는 여러 피드백을 받아서 WDS를 더욱 견고하게 다지고 있어요. 조금 더 보기 쉽게 설명하자면 다음 그림과 같아요.

이렇게 만들어진 WDS를 NPM에서 설치하고요. 피그마에서 필요한 디자인 시스템 컴포넌트를 구상합니다.

디자인 시스템 컴포넌트를 사용하기 위해 컴포넌트의 props, 사용 방법 등을 조회할 수 있는 스토리북 혹은 컴포넌트 내 정의되어 있는 JSDoc에서 해당 컴포넌트를 파악해요.

이제 직접 사용할 차례입니다. NPM 저장소에 배포된 WDS를 설치 후 불러옵니다.

이렇게 불러온 디자인 시스템을 통해서 다음과 같은 화면을 뚝딱 만들 수 있죠. WDS를 사용하니까 일일이 스타일을 정의했던 것에 비해서 확실히 쉽네요!

솔직히 해보니 어때요?

진짜 좋아요! 일단 개발 시간이 단축됐거든요. 개발자 입장에서 이보다 더 좋을 순 없죠. 실제 WDS를 도입하기 전과 비교했을 때, 한 페이지를 개발하는데 드는 소요시간이 약 33% 정도 줄었어요. 코드 라인도 50%가량 감소했는데, 작성할 코드 양이 줄어서 무엇보다 눈이 편합니다!😎

이런 개선이 어떻게 가능한 걸까요? 미리 약속된 디자인 컴포넌트들을 이용해서 페이지를 만들 수 있기 때문이에요. 모두가 아는 디자인 언어로 통일해서 쉽게 커뮤니케이션할 수 있다는 뜻이죠.

디자인 정의에 대한 예외 사항을 줄이고 약속된 컴포넌트 중심으로 작업을 진행하니 커뮤니케이션 비용을 절약할 수 있고요. 이전보다 페이지를 만드는 데 투입하는 시간이 줄었으니 당연히 다른 페이지를 개발하거나, 개선 사항을 유동적으로 반영하는 일에 더 집중할 수 있겠죠.

WDS 어디까지 왔니…어떻게 더 잘 쓸 수 있죠?

라이브러리 형태의 디자인시스템이 얼마나 적용(사용)되고 있는지는 어떻게 알 수 있을까요? 원초적인 방법으로는 직접 수동으로 하나하나 세는 것이 있죠. 컴포넌트의 수가 적다면 사실 가장 빠르고 정확한 방법일 거예요! 하지만 컴포넌트의 수가 적지 않다면 직접 세는 것만으로는 어렵고, 지라 태스크로 관리해야 할 수도 있습니다.

WDS가 효율성 높은 완성형 시스템이 되려면 더 쉽게 잘 쓸 수 있는 방법을 찾아야 할 텐데요. 그래서 만든 것이 ‘Analytics for WDS’입니다.

Analytics for WDS

많은 프론트엔드 개발자는 크롬 브라우저를 이용해서 개발을 해요. 웹사이트 품질을 확인할 때 사용하는 Google Chrome의 Lighthouse를 통해 현재 부족한 부분이 무엇인지 확인하고 개선하는 지표를 볼 수 있죠.

Google Lighthouse가 성능적인 부분의 통계를 보여준다면, WDS는 효율적인 디자인시스템 구조와 최적화된 컴포넌트 제공을 위해서 크롬 익스텐션인 'Analytics for WDS'를 사용하는 거예요.

현재 만든 페이지에서 WDS를 얼마나 사용했는지 알 수 있으니 더 필요한 컴포넌트와 필요하지 않은 컴포넌트를 파악하고 피드백 할 수 있어요. 예컨대 잘 사용되지 않는 컴포넌트는 원인을 파악해 사용률이 높아지도록 고도화할 수 있고, 미적용 애플리케이션에 대한 적용 계획을 수립하는데도 도움이 되죠.

Pipeline for WDS

그런데 개발 중인 페이지 현황을 보는 것을 넘어서 현재 프로젝트 단위 혹은 회사 단위에서 얼마나 WDS를 사용하는지 파악하기 위해서는 크롬 익스텐션 이상의 무언가가 필요했어요.

WDS를 사용하는 저장소에서 메인 브랜치가 업데이트 될 때 AWS Codebuild가 이를 감지하는데요. WDS 자동 통계로직을 트리거해서 해당 프로젝트의 WDS 사용 비율을 하나의 보고서에 만드는 파이프라인을 구성했어요. 자동 통계 파이프라인을 통해 24시간 내 사내 전체의 WDS의 이용률을 확인해 보다 빠르고 효율적인 지표 관리를 할 수 있게 된 거죠!

아직 모든 문제점을 개선한 것은 아니에요! 다만 한정된 시간에 최대의 효율을 제공하고, 이를 통해 구성원들이 불필요한 업무에서 벗어날 수 있게끔 계속해 서포트하고 있습니다.

무엇보다 기술적 문제 해결을 통해 유저 중심이라는 가치 창출의 기반을 만들 수 있다는 확신을 가지고 일하고 있어요! 불편함은 기회라는 문제 정의에 집중한 것이 WDS의 시작이었으니까요. 사용자를 위한 서비스, 좋은 고객 경험을 주는 제품을 만들기 위해 WDS 스쿼드는 오늘도 달립니다!