초기 스타트업, 디자인 시스템 도입을 결정한 이유

초기 스타트업 팀에서 디자인 시스템을 도입하는 것은 관점에 따라 쉬울 수도 어려울 수도 있는 일 같습니다. 하지만 상대적으로 쉬운 일이라는 관점으로 바라보더라도 실행을 하려고 하면 벽에 부딪히게 됩니다. 하지 않아도 될 이유 역시 많기 때문입니다.

하지 않아도 될 이유, 해야만 하는 이유

아직 성숙하지 않은 프로덕트에 시스템을 만든다는 것이 섣부른 추상화로 이어질 수도 있고, 필요한 기능을 사용자에게 전달하기까지 시간적인 지연을 가하는 일인 것도 사실입니다. 팀을 설득하려면 그것들을 넘어서 해야만 하는 이유를 강력하게 어필해야 하는데, 이 시점에서 실행에 대한 의지는 약해지기 쉽습니다.

Yess 팀의 프론트엔드 개발자 채용 미팅에서 자주 듣는 피드백 중의 하나는 디자인 시스템을 어떻게 도입하게 되었느냐는 질문인데요, 초기 스타트업인 Yess 팀에서 어떻게 디자인 시스템을 도입하자는 결정이 이루어졌고, 실제로 실행까지 이어질 수 있었는지 정리해 보겠습니다.

우리의 가치 기준에 따라 의사 결정하기

해야만 하는 이유를 어떤 기준으로 판단할 수 있을까요? Yess 팀에서는 모두가 공감하고 지향하는 핵심 가치를 총 7가지로 정의하고 있습니다. 이 핵심 가치에 부합하는 이유라면 Yess 팀은 대담하고 집요하게 실행합니다. 디자인 시스템 도입의 경우 Customer Obsession, Insanely Great이라는 두 가지의 핵심 가치를 기준으로 판단하였고 그 가치를 달성하기 위해 집중했습니다.

Customer Obsession

Yess 웹앱은 매주 스프린트를 반복하며 쌓아 온 레거시와 새로운 시도의 집합체입니다. 열심히 구현한 기능들이 제각각 파편화되어 원칙이 없는 겉모습을 하고 있다 보니 사용자가 우리의 가치를 알아서 이해해 주기를 기대하기는 어려워 보였습니다. 우리는 그간의 히스토리에 대해 잘 알고 있으니 어쩔 수 없는 일이라고 생각할 수도 있지만, 사용자는 우리의 히스토리를 알 길이 없으므로 현재의 웹앱을 스냅샷으로서 보고 판단할 뿐입니다. 결국 디자인 시스템은 웹앱 전체적으로 일관성 있고 쉬운 UI/UX를 제공함으로써 사용자를 적은 비용으로 학습하게 하고 engage 시켜주는 도구이기 때문에 꼭 필요하다는 데 팀원 모두가 공감했습니다.

Insanely Great

Yess는 훌륭한 프로덕트 팀이란 퀄리티와 스피드를 모두 지향하는 팀으로 정의합니다. 프로덕트의 개선 사이클에서 두 가지 요소가 서로 배타적이면 퀄리티가 엉망인 개선이 자주 이루어지거나, 퀄리티에 집착하느라 개선 주기가 길어지는 상황이 벌어질 수 있습니다. 디자인 시스템은 그 두 가지를 모두 챙길 수 있게 해 주는 도구입니다. 매주 새로운 기능을 구현하더라도 디자인 시스템이 지원하는 영역은 큰 고민을 하지 않아도 기본적인 퀄리티를 보장할 것이고, 그걸 가져다 쓰기만 함으로써 별도의 설계나 작업에 대한 리소스가 필요 없어지기 때문입니다.

디자인 시스템 구현 여정

의사 결정을 했다면 실행을 할 차례입니다. Yess의 디자인 시스템 첫 버전을 만들기 위해서 거친 네 가지 과정을 하나씩 차례로 정리해 보겠습니다.

디자인 토큰 정의하기

디자인 토큰은 UI의 빌딩 블록이며 가장 많은 곳에서 자주 쓰이기 때문에 중요합니다. 예를 들면 컬러나 폰트 스타일 등을 미리 체계화된 네이밍으로 랩핑해 두는 것인데, Tailwind CSS 같은 라이브러리에서 디자인 토큰을 클래스명으로 제공하는 방식을 볼 수 있습니다.

Yess 팀에서는 디자인 토큰 기반의 컴포넌트 라이브러리를 구현할 계획이었기 때문에 Material 디자인 시스템의 접근 방식을 차용했습니다. 이 방식에 의하면 디자인 토큰은 reference, system, component 세 가지 레벨로 구성되어 있는데, Yess 팀의 경우 아직 컴포넌트 라이브러리가 만들어지기도 전이었기 때문에 reference, system 레벨의 정의부터 시작했습니다.

토큰의 레벨은 첫 번째 순서부터 그 이후 순서의 기반이 되는 위계로 이루어져 있고, 순서대로 토큰 이름이 더 강한 의미를 지니게 되는 특징이 있습니다. reference 토큰이 팔레트처럼 값을 나열하듯 정의해 둔 형태라면 system 토큰은 그 값이 어떤 성격을 지니는지(밝음, 어두움 등)를 포함해서 한 단계 랩핑하는 식입니다. 추후 component 토큰이 정의된다면 해당 값의 역할(default, focused, disabled 등)까지도 반영하게 됩니다.

Reference token 예시	System token 예시

Headless UI 라이브러리 레버리지하기

토큰을 정의한 후에는 컴포넌트를 구현하는 단계로 넘어갑니다. 토큰 레벨에 Tailwind CSS와 같은 라이브러리가 있듯이 컴포넌트 레벨의 디자인 시스템 라이브러리도 많은데요. Material처럼 역사가 긴 디자인 시스템은 강력하고 편하지만, 실제 프로덕트에 적용하기에는 커스텀의 자유도가 떨어집니다. 이런 문제를 해결하기 위해 비교적 최근에는 Headless UI 라이브러리가 등장하여 많이 쓰이고 있습니다. Headless UI 라이브러리는 디자인 시스템에서 자주 쓰이는 컴포넌트의 코어 로직만을 패턴화해 두고, 나머지는 사용자에게 완전히 커스텀으로 맡기는 방식을 취합니다.

Yess 팀에서는 Radix Primitives라는 라이브러리를 선택했고, 바퀴부터 만들지 않아도 되어 굉장히 빠르고 편하게 디자인 시스템을 구축할 수 있었습니다. 참고로 Radix Themes도 있는데 이 라이브러리는 디자인까지 입혀진 컴포넌트를 제공하기 때문에 필요하다면 스타일을 직접 입힐 필요 없이 최신 스타일의 완성도 높은 디자인을 레버리지하여 빠르게 앱을 구현할 수 있습니다. shadcn 역시 비슷한데, 이 라이브러리는 Tailwind CSS를 기반으로 하고 있어 필요에 맞게 선택하면 될 것 같습니다.

우선순위에 따라 적용하기

컴포넌트를 구현하고 적용하는 단계에서부터는 우선순위에 대한 고민이 많았습니다. Yess 팀에서는 가장 시급한 건 웹앱의 1 depth 페이지들이라는 결론을 내렸습니다. 이 페이지들의 경우 사용자가 웹앱에 진입한 직후 GNB 메뉴를 왔다 갔다하며 빠르게 훑어볼 수 있기 때문에 파편화 정도가 클수록 부작용도 큽니다.

우선은 1 depth 페이지에서 많이 사용되는 컴포넌트와 레이아웃의 패턴을 추출했습니다. 여기서 꼭 구현되어야 할 필수 컴포넌트 목록이 정해졌고, 이에 대해 개발 설계를 진행했습니다. 디자인 토큰을 기반으로 하여 Header, Contents Box, List, Card 등의 주요 UI 컴포넌트와 함께 Button, Modal, Dropdown, Popover 등의 기본적인 사용자 인터랙션 요소들이 구현 및 적용되었습니다. 선택과 집중을 한 결과 적어도 1 depth 페이지에서는 일관된 UI/UX를 제공할 수 있게 되었고 그 결과는 다음과 같습니다. 이전과 비교했을 때 확연히 개선된 모습이 보여 뿌듯했던 순간이었습니다.

Before	After

지속적으로 팀과 커뮤니케이션하기

디자인 시스템을 도입한 후로 시안을 보고 스타일을 작성하는 과정에 효율이 증가하기도 했지만, 무엇보다도 직군을 막론하고 팀 전체가 디자인 시스템을 바라보는 관점과 개념에 대해서 싱크를 맞추어 나가는 과정이 의미 있었습니다. 특히 디자인 의도와 코드 사이의 갭이 없도록 서로 동일하게 이해하고 있는지 계속해서 확인하는 것이 중요하다는 것을 느꼈습니다. 그 결과 이전에 비해 불필요한 스타일 관련 커뮤니케이션이 확연히 줄었고, 새로운 기능들을 구현하더라도 파편화의 정도를 제어할 수 있게 되었습니다.

다만 디자인 시스템은 최초 구현보다 지속적으로 개선하고 유지 보수하는 것이 더 중요합니다. 그렇기 때문에 불필요한 커뮤니케이션은 최소화하더라도, 성숙한 시스템으로 발전하기 위해서 필요한 비정기적 리뷰 프로세스를 진행하고 있습니다.

우선 새로운 요구사항에 대해 프론트엔드 설계를 진행하기 전, 디자인과 프론트엔드 파트가 함께 디자인 시스템 관련 논의를 진행합니다. 이 논의에서는 시안에서 기존 디자인 시스템의 변경을 가해야 하는 부분이 있는지, 혹은 새로운 디자인 시스템 컴포넌트를 구현해야 하는 부분이 있는지 등을 확인합니다. 여기서 확인된 내용을 설계에 반영하여 작업 및 배포까지 이루어진 후에는 프론트엔드 파트 내에서 디자인 시스템 리뷰를 진행합니다. 지난 배포에 있었던 디자인 시스템 관련 변경 사항을 리뷰하고 의견을 나눔으로써 더 나은 시스템으로 발전하기 위한 노력을 지속하고 있습니다.

앞으로의 과제

Yess의 디자인 시스템은 이제 막 태어난 참입니다. 지금도 매주 새로운 컴포넌트를 구현하고, 적용하고, 리뷰하는 과정을 반복하고 있습니다. 이 과정에서 빠르게 실행하기는 어렵지만 장기적인 관점으로 잊지 않고 챙겨야 하는 과제들 역시 남아 있습니다.

다중 테마 지원

디자인 시스템을 통해 기본적인 일관성을 보장할 수 있지만 커스텀의 필요성이 여전히 존재합니다. Yess는 Vertical SaaS로써 UI/UX적으로나 기술적으로나 굉장히 다양한 성격의 기능들을 종합적으로 제공하고 있기 때문입니다. 특히 사용자가 본인의 브랜딩을 적용해서 외부에 공개해야 하는 성격의 기능, 예를 들면 Lead Form, Widget을 비롯해서 프로젝트를 진행하는 과정에 클라이언트와 커뮤니케이션이 필요한 요소들(Portal, Meeting Note, Proposal 등)이 그러합니다. 이때 다중 테마는 Yess의 디자인 정체성을 유지하면서 사용자의 브랜딩 테마를 적용할 수 있게 해줍니다. 디자인 토큰 정의나 Headless UI 도입에 있어서도 이러한 미래를 염두에 두고 진행했던 만큼 아무래도 가장 높은 우선순위로 진행하게 될 과제라고 예상됩니다.

의존성 최소화를 위한 노력

라이브러리는 빠르게 실행할 수 있는 도구로 유용하지만 코드베이스에 의존성을 늘리는 요소이기도 합니다. 무분별하게 늘려 나가다 보면 특정 라이브러리의 문제 또는 라이브러리 간의 충돌로 인해 Uncontrollable한 상황을 마주하게 되므로 주의해야 합니다.

Yess 팀에서는 Radix UI를 도입한 이후 react-router의 메이저 버전을 업데이트하게 되었는데 이때 예상치 못했던 Radix Dialog의 렌더링 방식이 문제가 되었습니다. 기존에 Radix Dialog를 react root를 통해 렌더링하고 있었는데 새로운 react-router 메이저 버전에서는 서로 다른 root 사이에 history context가 유지되지 않는 원칙과 위배되었고 그 결과 Dialog가 포지셔닝 되는 과정의 애니메이션이 버벅이는 현상이 발생했습니다. 또한 연쇄적으로 react-select라는 드롭다운 컴포넌트의 포지셔닝 역시 문제가 생기면서 라이브러리 3중 충돌 현상으로 이어졌습니다. 이 과정에서 의존성을 Controllable한 상태로 최소화하는 것이 중요하다는 배움을 얻었습니다. 이 현상으로 인해 결과적으로는 Radix Dialog를 잘못된 방식으로 사용하고 있었다는 사실을 알게 되기도 해서, 의존성을 도입할 때 충분한 리서치와 지식이 필요하다는 배움도 얻게 되었습니다. 앞으로는 레거시 의존성을 점진적으로 제거하고, 디자인 시스템을 더욱 고도화하여 안정성이 보장되는 코드베이스를 만들어 나가고자 합니다.

문서화 및 전파

Yess 팀은 현재 Storybook으로 디자인 시스템을 비롯해 컴포넌트 테스트를하고 있습니다. 다만 문서화를 위해 TSDoc을 충분히 활용하지 못하고 있습니다. 또한 바쁘게 일하다 보면 디자인 시스템 구현에 온전히 집중하기는 어렵다 보니, 컴포넌트를 최초 구현할 때 스토리를 작성하고 나서는 유지보수가 잘 안되는 문제도 있습니다. 어쩔 때는 코드 리뷰가 제대로 이루어지지 않아서 구현한 사람 이외에 변경이 가해진 부분을 잘 인지하지 못하기도 합니다.

이런 문제들을 해결하기 위해서는 Storybook을 디자인 시스템에 대한 One source of truth로 사용할 수 있게끔 더 철저하게 문서화하고, 지속적으로 전파하는 것이 필요합니다. 이 영역은 사람이 노력하는 데 시간적, 인지적 한계가 있다보니 자동화할 수 있는 방법을 고민하고 있습니다. AI로 TSDoc을 생성하거나 피그마에서 디자인 시스템 컴포넌트와 사용된 옵션들을 자동으로 코드까지 연동할 수 있는 플러그인 등 여러가지로 창의력을 발휘하여 개선해야 할 부분이 아닐까 싶습니다. (후자는 실제로 피그마에서 개발중이라고 하네요!)

진정한 디자인 시스템이 되기 위해 필요한 것

앞으로의 과제들을 하나씩 해결해 나가면서, 멀지 않은 때에 더 의미있고 깊은 인사이트로 디자인 시스템에 대한 회고를 소개할 수 있으면 좋겠습니다. 그 텀이 너무 길어지지 않도록 Yess의 프론트엔드 개발자로 함께 해주실 분들을 찾고 있습니다. 진정한 디자인 시스템이 되기 위해서는 지금보다는 더 많은 인풋이 필요합니다. Agency, Studio, Freelancer들이 번창하는 미래를 그리며 열정적으로 달리고 있는 Yess 팀에 흥미가 생기신다면, 이 글에서 드러난 Yess 팀의 지향점에 공감하고 그렇게 일하는 분이시라면, 주저 말고 연락 주세요.