이전 회사에서 디자이너와 함께 디자인 시스템을 만들었던 적이 있었다. 레퍼런스가 없어서 일단 디자이너가 만들어준 디자인을 가지고 재사용에 용이하도록 만들어서 사용하긴 했었는데, 만들고 사용해도 막상 새로운 작업을 하려고 보면 여백, 색상, 높이, 너비, 폰트 굵기 등등 규칙 없이 바뀌는 요소들이 너무 많아 결국 다시 퍼블리싱을 하게 되는 상황이 반번했다. 그래서 그 이후로 항상 도대체 잘 만든 디자인 시스템이 어떻게 구성되어 있는지 알고 싶다는 생각이 있었는데, 이번에 [유즘 우아한 개발] 책을 읽으면서 디자인 시스템에 대한 내용이 있어 읽은 내용을 정리할 겸 이전에 만들었던 디자인 시스템이 뭐가 잘못되었었는지 회고를 해보려고 합니다. 참고로 책에는 디자인 시스템이 개발자 관점의 이야기만 서술되어 있어서 우아한 형제들 테크 블로그에서 디자이너 관점의 이야기를 추가로 찾아서 읽었습니다.
디자인 시스템이 필요한 이유
일단 디자인 시스템이 필요한 이유는 일을 더 효율적으로, 잘 할 수 있도록 하기 위해서 입니다.
디자인 시스템을 이용하면 일관된 디자인과 UI를 사용하여 반복적으로 낭비되는 리소스를 줄이기 때문에 개발자는 디자인이 없이도 이미 만들어놓은 컴포넌트를 통해 화면을 만들 수 있고, 디자이너는 픽셀 단위로 QA를 하지 않아도 되기 때문에 UX를 좀 더 거시적 관점에서 고민할 수 있게 됩니다.
디자인 시스템을 만들 때 협의할 것
- 디자인 시스템은 일종의 프로토콜임으로 디자인 시스템의 룰을 따를 것. 커스텀마이징은 꼭 필요할 경우에만. 커스터마이징을 반복하다보면 시스템이 시스템이 아니게 됩니다.
- 디자인 토큰(색상, 폰트 사이즈, 간격...)
- 스타일 가이드(색상, 타이포그라피, 스페이싱, 브레이크 포인트...)
- 강조할 것과 그렇지 않은 것을 어떻게 구분할 것인가? 강조가 겹치면?
- Form 유효성 체크에 대한 일관성 있는 인터렉션 시나리오
- 점검, 장애 시의 UI 피드백
- ....
디자인 토큰과 스타일 가이드의 차이
디자인 토큰은 기본적인 디자인 속성을 코드로 정의하여 플랫폼에서 일관성을 유지하는데 사용됩니다. 스타일 가이드는 디자인 시스템의 시각적 요소와 사용 지침을 문서화하여 일관된 디자인을 유지하는데 도움을 줍니다. 디자인 토큰은 스타일 가이드의 일부로서 작동할 수 있습니다.
폰트에 대한 스타일을 정의해본다고 합시다. 이 때 폰트 사이즈를 '24px', '30px', '32px' 등등 중구난방으로 정의하면 일관성이 없고, 매번 픽셀을 확인하여 개발해야하며, 디자인 QA도 번거롭습니다. 이를 개선하기 위해서 폰트의 사이즈를 sm, md, lg, xl ... 같이 몇 가지로 제한을 하여 font-size: 36px를 font-2xl로 정의하여 사용하는 것을 디자인 토큰이라고 합니다.
스타일 가이드는 여기서 더 나아가 디자인 토큰을 조합하여 구체적인 스타일 규칙을 정하고, 이를 특정 컴포넌트나 요소에 적용하는 방법을 설정힌 것을 말합니다. 앞에서 예시를 들었던 font-2xl이외에 font-weight: 700을 font-bold로 정의한 디자인 토큰이 있다고 가정해봅시다. 헤드라인의 스타일을 정의하기 위해서 앞에서 정해줬던 디자인 토큰들을 조합하여 font-2xl font-bold로 스타일을 적용해도 되겠지만, 디자인 토큰을 한 번 더 감싸서 font-2xl font-bold를 headline이라고 정의할수도 있습니다. 이렇게 디자인 토큰을 이용해 구체적인 스타일 요소를 구성하고 이를 어디에 어떻게 사용할지를 규정하는 것을 스타일 가이드라고 합니다.
쉽게 말하면 타이포그라피 컴포넌트가 있을 때 font-size: 36px; -> font-2xl, font-weight: 700 -> font-bold로 만들어 정의하는 것을 디자인 토큰, font-2xl font-bold -> headline으로 정의하여 가장 상단의 제목으로 정의하는 것을 디자인 가이드라고 합니다.
개발에서의 디자인 시스템
이 부분들은 제가 여기에 자세히 적는 것은 의미가 없을 것 같아 적용 방법을 중심으로 정리정도만 하겠습니다. 자세한 내용은 여기로
배민 셀프서비스 디자인시스템의 구조 사진입니다. 이걸 보면 개발에 있어서의 디자인 시스템은 시각적 디자인 외에 컴포넌트들이 자주 사용하는 기능의 공통화(공통 컴포넌트, 라이브러리 등)로 생각하면 될 것 같습니다.
개발을 하면서 자바스크립트에서 클래스를 사용해본 적이 없고 그렇기에 당연히 클래스 컴포넌트를 만들어본 적도 없습니다.. 그나마 최근에 모던 자바스크립트 딥 다이브 책을 읽으며 클래스를 공부했기에 어떤 경우에 쓰는구나 하고 막연하게 생각하고 있었는데, 여기서 좀 더 구체적인 예시를 볼 수 있었습니다.
배민 셀프서비스에서는 BaseComponent라는 컴포넌트를 추상 클래스로 정의해두고 모든 컴포넌트들이 상속받아 사용하도록 하고 있다고 합니다. 그리고 이 컴포넌트는 새로운 라이프사이클 정의, 이벤트 자동 해제, 로그 자동화의 기능을 수행합니다. 또 다른 예시로는 PageContainer가 있습니다. URL이 있는 모든 페이지가 상속받아야 하는 추상 클래스 컴포넌트입니다. 뷰 로그를 남기도록 강제하고, 서버에서 점검일 진행될 경우 도메인 별로 페이지에 점검을 걸어 render 함수를 바꿔치기 할 수 있도록 되어 있습니다. 서버 사이드에서 많이 쓰이는 캐시 관리 기법을 적용한 추상 클래스같이 라이브러리에 적용된 추상클래스의 예시도 있었습니다.
그 외에도 구성요소들을 만들 때 공통적인 부분은 최대한 추상 클래스로 구현하여 비지니스 로직과 관련된 부분만 작성할 수 있도록 영역을 격리시키는 방법을 적용했다고 합니다.
회고
이번에 알아보면서 생각해보니 이전에 만들었던 디자인 시스템은 디자인 토큰까지는 잘 지켜졌는데 스타일 가이드는 제대로 지켜지지 않은 것이 문제였던 것 같습니다. 경우에 따라서는 디자인 토큰 외의 스타일이 적용되는 경우도 더러 있었고.. 그러다보니 매번 픽셀을 확인해가며 개발을 해서 있으나 마나한 디자인 시스템이 되었었습니다... 당시엔 들어오는 일을 정신없이 쳐내느라 바빠서 디자이너와 더 협의를 할 여력이 없었고, 원래 이런건가? 하고 넘어갔었는데 지금 와서 생각해보니 그러지 말았어야했다는 생각이 듭니다. 하지만 이미 지나간건 지나간거고 지금 알았으면 됐죠..!
+) 프론트엔드 개발을 하면서 드는 생각 중에 하나가 코드가 왜 이렇게 정리가 안 될까 하는 것이었는데 추상 클래스 컴포넌트를 통해 이 부분을 개선할 수 있는 인사이트를 얻어가는 것 같아 기분이 좋습니다.