[warrr-ui 디자인 시스템 개발기] 디자인 시스템 정의

2주차 과제는 바로 각자가 생각하는 디자인 시스템에 대한 정리 및 리서치였다.

생각보다 다들 다 다른 내용으로 구성해 와서 그거마저 의미 있는 시간이었던 것 같다.

디자인 시스템에 대한 본인만의 철학을 가져온 사람도 있었고, 딥하게 리서치해온 분도 있었다.

나도 꽤 리서치를 많이 해갔었는데, 다들 다른 관점으로 리서치를 해와서 인사이트를 얻을 수 있는 시간이었던 것 같다.

 

디자인 시스템 정의

일단, 나는 디자인 시스템 정의부터 알아봤다.

 

디자인 시스템이란 다양한 페이지와 채널을 걸쳐 공통의 언어와 시각적 일관성을 만들고 반복되는 작업을 줄임으로써, 규모에 맞게 디자인을 관리하기 위한 표준 집합이다.

 

라고 권위 있는 UX 컨설팅 기업 Nielsen Norman Group이 정의했다고 한다.

 

디자인 시스템 구성 요소

이후, 나는 몇몇 글을 찾아보다가, 아래 글을 발견했다.

https://github.com/orgs/InnerCircleA/discussions/2

 

누군가가 디자인 시스템에 대해서 상당히 많은 고민을 한 흔적이었다.

그래서 좀 더 신뢰가 갔었던 것 같고, 해당 내용 위주로 디자인 시스템을 이해해 나간 것 같다.

해당 글에서는 컴포넌트 기반 디자인 시스템과 파운데이션 기반 디자인 시스템을 설명하는데, 사실 나는 이해가 안 가기 시작했다.

 

파운데이션은 아이콘, 팔레트, 스페이싱처럼 일관된 레이아웃과 그에 따른 사용자 경험을 만드는 데 필수적인 시각적 요소이고, 컴포넌트는 버튼, 아코디언과 같이 재사용 가능한 UI 구성 요소이다.

내가 알기론, 파운데이션과 컴포넌트는 디자인 시스템의 구성 요소인 것 같은데, 왜 둘 기반 디자인 시스템을 비교하고 있는 것인가?라는 생각이 있었지만, 시간에 쫓겨 그에 대해서는 더 알아보지 못한 채로 과제를 제출하게 되었다.

이 부분을 다른 분과도 이야기를 나눴고, 이후 리서치도 해봤지만, 둘 다 디자인 시스템 구성 요소로 생각하면 될 것 같다.

크게 비교를 할 이유는 없는 것 같다.

 

헤드리스 UI, 컴포넌트 기반 UI

헤드리스 UI라고 하면, 다들 잘 알겠지만, 스타일링 담당부와 상태 담당부를 분리해서 코드를 작성하는 것이라고 보면 된다.

주요 비즈니스 로직과 스타일링 코드가 잘 분리돼서 관심사가 분리된다는 장점이 있지만, 사용자 입장에서 일관적인 디자인이 없을 수 있다는 점이 단점일 수 있다.

컴포넌트 기반 UI의 경우, 우리가 일반적으로 아는 방식이다.

스타일링 담당부와 기능 담당부가 함께 존재하는 것이라고 보면 된다.

이 방식은 사용자 입장에서 바로 가져다 쓰기 편하지만, 스타일 커스텀이 상당히 불편할 수 있다는 단점을 가지고 있다.

 

나는 처음에는, 사용자 입장에서 사용하기 편하고 일관된 사용자 경험을 제공하는 부분도, 커스텀이 편한 부분도 모두 중요하다고 생각했다.

하지만, 굳이 따지자면, 컴포넌트 기반 UI가 더 우선순위가 높지 않나 라는 생각을 하게 되었고, 그 부분을 발표 때 얘기했었다.

 

그런데, 상상치도 못하게 좋은 의견이 나왔다.

사실, mui에서는 headless 기반 디자인 시스템을 Base UI로 구성했고, 그에 디자인을 입힌 것을 material UI로 구성해서 사용하도록 했다.

왜 이 생각을 못했나 싶었다.

그래서 나는 이 방식이 너무 마음에 들었다.

이 방식으로 밀고 나가야 겠다는 마음이 살짝 들었다.

 

웹 접근성

완성도 있는 디자인 시스템이라면,,, 웹 접근성에 대해서 고려를 하지 않을 수가 없다.

그래서 웹 접근성에 대해서 아주 간단하게 알아보았고, 어떤 사항들을 지켜야 하는지도 대략적으로 알아보았지만 다른 부분 위주로 리서치를 하다 보니 부족했다.

간단하게만 말해보자면, 대체 텍스트 제공, 키보드 등 입력 장치의 접근성, 시멘틱 태그와 같은 부분을 신경써야 한다는 것이다.

사실, 여러 디자인 시스템 레퍼런스를 참고했지만, 키보드 조작을 빼먹은 곳은 없더라.

그만큼 중요한 부분이라는 것을 알게 되었다.

추후, 꼭 더 리서치해보려고 한다.

 

디자인 시스템에 필요한 확장성과 제약성

레퍼런스로 두 영상을 참고했는데, 아래 영상들이다.

https://www.youtube.com/watch?v=21eiJc90ggo

https://www.youtube.com/watch?v=yR1g_A1-xFs

 

사실 첫 번째 영상은 Flex 디자인 시스템에 대한 내용이고, 두 번째 영상은 배민의 백오피스 디자인 시스템에 대한 내용이다.

상당히 반대되는 성격을 지닌 발표 내용이라고 할 수 있겠다.

처음 영상은 우리가 흔히 아는 디자인 시스템에 대한 내용이었는데, 생각보다 원칙 같은 부분이 인상 깊었다.

 

Flex 디자인 시스템 원칙은 다음과 같다.

• 기능은 형태와 독립적
• 기본 동작을 보장, 기본 동작이 아닌 것은 정의하지 않음
• 최소한의 제약만 가짐 (자유도)

그리고 배민의 백시시 디자인 시스템은 백오피스였기 때문에 높은 자유도보다는 정형화된 컴포넌트 개발을 목적으로 했다.

백오피스에서 필요한 기능들을 모두 미리 정의해놓고 사용할 수 있도록 컴포넌트를 정의했다.

 

둘만 보면 정반대의 성격을 가졌다고 할 수 있다.

사실 우리가 원하는 디자인 시스템 형태는 Flex 디자인 시스템이기는 하다만, 배민의 백시시 디자인 시스템 영상 덕분에 확장성과 제약성이라는 관점에서 생각을 해볼 수 있었던 것 같다.

 

이 부분은 사실, 이지벗 프로젝트를 진행하면서도 상당히 고민이 많이 됐던 지점이었다.

당시 필요했던 것은 단순 텍스트용 텍스트 필드와 금액용 텍스트 필드였다.

기능이 생각보다 많이 달랐고, 디자인만 동일해서 어느 정도까지 둘을 공통적으로 가져가야 하냐는 고민이었다.

둘을 공통으로 가져가기엔 props에 조건부 타입들이 계속해서 늘어나고, 책임이 무거워진다는 생각이 들었다.

결국 나는 둘을 분리해서 가져가자는 결론을 내렸다.

 

이에 대해서 팀원들과도 얘기를 나눴고 한 팀원은 분리하는 것이 맞다, 다른 팀원은 디자인이 동일하니 분리하는 게 맞나?라는 의견이었다.

지금 내 생각으로는 분리하는 것이 맞는 것 같기는 하다.

둘을 공통으로 가져가기에는 복잡성이 너무 증대되는 것 같고, 이를 그렇다고 합성 컴포넌트 패턴을 도입하기에도 기능이 워낙 달라서 의미가 없을 것 같았다.

추후, 디자인 시스템을 만들면서 이런 부분도 다 같이 논의해 보면서 보다 개선된 로직을 가져갈 수 있도록 해보고 싶다.

 

진행 방식에 대한 건의 (+ 스크럼)

사실 이번 주차도 저번 주차처럼 같은 방식으로 발표가 진행되었고, 보다 마무리되지 않은 부분이 있다고 느꼈다.

물론 발표 자체는 상당히 의미 있는 시간이었지만, 각자 생각이 다 다르다 보니 이걸 정리하는 시간 또한 필요하다고 생각했다.

그래서 나는, 토요일 정기 발표 말고도 일주일에 두 번 정도 각자 발표에서 디벨롭하고 싶었던 내용이나 수정하고 싶었던 부분을 보완해서 더 얘기를 나눠보자고 했고, 이게 받아들여져서 스크럼 제도를 도입하기로 했다.

 

발표 때 모든 얘기를 나누면 좋겠지만, 워낙 내용이 방대하다보니 그게 쉽지 않았다.

그래서, 회의 때 회의 내용 정리, 스크럼 당시 디벨롭할 내용과 같이 논의해봐야 하는 내용으로 세 가지를 구분해서 회의록을 정리한 후, 이를 바탕으로 다음 스크럼을 진행해 보기로 했다.

그래서 과제가 두 배,,,지만, 건설적인 대화와 솔직한 소통으로 가는 과정인 것 같아 좋았다.