디자인 시스템과 스토리북 도입기

0. 도입 배경

토스, 리디북스 등 다양한 스타트업에서 디자인 시스템을 도입했다는 글을 많이 봤을 것이라고 생각합니다.

디자인시스템을 구축한다는 것은 기존 방식보다는 초기 개발 cost를 감안해야 합니다. 요소 하나하나에 대한 정의가 필요하고, 재사용성에 대해 고려해야하며, 더 나아가 디자인시스템을 기존 시스템에 주입하기 위한 프로세스도 정의를 해야할 것 입니다. 결국 새로운 시스템을 도입하는 것이므로, 초기 설계의 완성도가 매우 중요하고 이에 따라 초기에 많은 리소스가 필요할 수 밖에 없습니다.

그러나 장기적인 측면에서 접근한다면 오히려 초기 cost는 감안해도 될만큼 좋은 경험을 제공했다는 글을 보았고, 프로젝트에 사용해보기로 했습니다.

리디 디자인시스템 아우디 디자인시스템

왜 디자인 시스템이 필요한가요?

우선 결론은, 디자인 시스템은 꼭 필요하지 않으나 도입하면서 기대할 수 있는 이익이 있습니다.

디자인 시스템을 도입하는 가장 넓은 범주의 이유는 재사용가능한 컴포넌트를 만드는 것일 것입니다. 그러나 재사용이 가능한 사용자 인터페이스는 새로운 개념이 아닙니다. 스타일 가이드, UI키트 및 공유 가능한 위젯은 이전에도 존재했습니다.

반면 기존과 다르게 디자인 시스템은 디자이너와 개발자 모두 참여하여 사용자가 접근하기에 용이한 사용자 인터페이스를 구축할 수 있는 환경을 제공합니다.

이때 개발자의 경우 디자인 시스템의 기술적인 파트 3가지를 다룹니다.

• 재사용이 가능한 공용 UI 컴포넌트
• 디자인 토큰: 브랜드 색상, 간격과 같은 스타일 변수
• 문서: 사용 방법 및 설명

꼭 필요한가요?

당연한 말이지만 프로젝트의 환경, 여건, 상황마다 다릅니다. 만약 소규모의 팀에서 단일 앱으로 작업하는 경우, 디자인 시스템을 사용하는 것보다는 컴포넌트로 이루어진 디렉토리를 사용하는 것이 유지보수, 생상선 측면에서 유리합니다. 대규모 프로젝트일 경우, 장기적인 측면에서 접근했을 때 재사용성, 커뮤니케이션에서 발생하는 비용 감소 등 여러 비즈니스적인 이점을 기대할 수 있습니다. 이러한 이유로, 토스 및 버즈빌 등 다양한 스타트업들이 도입하고 있습니다.

본인은 어떤 이유로 팀프로젝트에 사용하기로 생각했나요?

팀에게는 개발 프로세스적인 측면에서, 개인적으로는 교육적인 측면에서 모두 득이 되는 상황이라고 생각했습니다.

1. 협업의 관점에서 개발 프로세스를 강제할 수 있다는 점은 큰 메리트였다고 생각합니다. 동일한 개발 환경 및 프로세스를 정립하여 불필요한 커뮤니케이션을 줄이고 싶었습니다. 팀원 모두가 작은 컴포넌트 단위부터 시작하여 페이지 단위까지 개발을 진행하다보니, 같은 단계에서 발생하는 이슈들을 빠르게 해결할 수 있었습니다. 또한 다른 사람이 만든 컴포넌트라도 Storybook을 통해 문서화하여 보다 쉽고 빠르게 자신의 화면에 적용시킬 수 있었습니다.

2. 통일된 UI 제공 및 디자인 QA에서 발생하는 비효율성을 줄이기 위해서 입니다. 기존에 경험했던 팀 프로젝트들에서는 개발 단계에서 지속적인 UI 수정이 이루어졌습니다. 또한 각자 화면을 맡아 진행하다보니, 동일한 컴포넌트임을 동시에 개발하는 과정도 있었습니다.이러한 과정들은 저로 하여금 비효율성을 느끼게하는 부분이 었습니다. 또한 각자 개발하다보니 불가항력적으로 화면 별 UI 컴포넌트가 틀어지는 경우도 많이 겪었습니다. 그러다보니 최종 결과물을 확인하는 과정에서 결국 다시 수정하는 과정을 거쳐야 했습니다. 디자인 시스템 또는 CDD의 이점일수도 있는데, 재사용성을 고려하여 컴포넌트를 분리하고 보다 효율적이고 빠르게 개발과 수정을 할 수 있었습니다.

3. 배우는 사람 입장에서 최근에 많이 도입되는 기술에 대해 공부하고 사용해불 수 있는 기회라고 생각했습니다. 토스, 리디, 버즈빌뿐만 아니라 카카오, 네이버 등 IT 대기업도 스토리북을 도입하기 시작했다는 점입니다. 특히 CIC 형태를 지닌 기업에게 통일된 UX/UI를 제공하고, 높은 생산성을 기대할 수 있기 디자인 시스템을 사용한다고 생각합니다. 실제 사용하면서, 익숙해진다면 기존 개발 방식보다 훨씬 효율적으로 접근할 수 있겠다고 생각했습니다.

이번 디자인 시스템을 도입하면서 컴포넌트 설계 단계부터 재사용성을 높이기 위해 고민했습니다. 직접 사용해보면서 느꼈던 지점은, 기존 계획과는 다른 기획이나 기능을 추가할 때도 빠르게 대응할 수 있었습니다. 또한 개발 프로세스에 대한 가이드라인을 명시적으로 세울 수 있어 협업 측면에서도 좋은 경험을 했습니다.

1. 스토리북 도입기

스토리북이란

스토리북은 사실 테스트 도구라기 보다는 UI 개발 환경에 가깝습니다. 스토리북의 가장 큰 목적은 “UI 컴포넌트를 애플리케이션 외부의 독립된 환경에서 개발할 수 있도록” 하는 것이라고도 합니다. 그러나 스토리북도 테스트 도구의 역할을 일부 수행하고 있다는 것을 알 수 있습니다.

스토리북 도입을 통해 이루려고 했던 목적

이번 프로젝트에서 사용한 주목적은 UI 컴포넌트를 비즈니스 로직에서 분리하기 위함이었습니다. 개발 프로세스상에 스토리북을 통한 UI 컴포넌트 제작에 강제성을 두어, UI 컴포넌트 로직에서 UI를 제외한 로직이 포함되지 않게 노력했습니다. 이를 통해, 세명의 프론트엔드 개발자가 공통적인 개발 프로세스를 공유하며 비효율적인 커뮤니케이션을 줄일 수 있었습니다.

두 번째 이유는 간단한 UI 테스팅과 문서화였습니다. 기획된 디자인과 최대한 유사한 UI와 인터렉션을 구현하기 위해 노력했고, 이를 Chormatic을 통해 빌드테스트와 Netlify를 통해 Documentation을 생성했습니다. 특히 빌드 테스트를 통해 간단한 Code Inspection을 수행할 수 있다는 점이 좋았습니다. 솔직히 테스팅의 기능으로서 작동하기에는 기능을 잘 활용하지 못했던 것이 아쉬웠습니다.

스토리북을 활용하며 겪은 개발 과정

1. 컴포넌트의 구조화 Foundation > Components > Patterns > Layouts

전체적인 구조는 Atomic Design을 기반으로 설계했습니다. Atom > Molecule > Organism 을 컴포넌트, 패턴, 레이아웃으로 매칭시켰습니다.

Container와 Pages는 비즈니스로직이 포함되기 때문에 스토리북으로 관리하지 않았습니다.모든 화면에 대해 레이아웃을 만드는 것은 효율적인 개발방식이 아니라고 생각했습니다. 재사용성이 높은 컴포넌트와 패턴 레이아웃에 대해서만 스토리북으로 관리하는 것을 생각했습니다.

2. 컴포넌트의 상태에 다크모드 Theme 적용

아직 개선이 많이 필요한 부분이라고 생각합니다. 저희의 경우 컴포넌트에서 props를 받아 UI를 제공하는 방식을 생각했습니다. 그러다보니, 최상단에서 Props로 계속 Theme에 대한 상태값을 내려보내줘야했습니다. 추후에는 ThemeProvider를 사용하여 보다 깔끔한 형태로 컴폰넌트의 스타일링을 구현하는 것이 필요할 것 같습니다.

3. styled-component를 CSS in JS

CDD 기반으로 개발을 진행하기 때문에, CSS 또한 컴포넌트 간의 확실한 분리가 필요했습니다. 다만, 같은 컴포넌트라도 커스텀이 필요한 경우가 있기 때문에, CSS 중첩을 통해 해결했습니다.

4. 컴포넌트의 확장성

컴포넌트들이 높은 확장성을 갖기 위해서는, 다양한 유즈케이스들에 대응할 수 있어야 합니다. 이에 필요한 기능들을 Props로 정의하고, default Props 또한 명시하여 관리했습니다. 다만, 사용하면서 모든 케이스들을 고려하기 힘들었고, 다양한 종류의 에러가 발생하기도 했습니다. 이에 나중에는 TypeScript로 개발해보면 좋겠다는 생각이 들기도 했습니다.

Loading State에 대한 UI

React Suspense를 도입할 예정이었기 때문에, Loading State에 대한 UI 역시 고려해야했습니다.

Loading State에 대한 컴포넌트의 UI을 Component > Pattern의 영역까지 설정했습니다.

• Componenet의 단위에서는 Loading UI 에 대한 css, animation을 정의 했습니다.

• Pattern의 단위에서는 Loading state에 대한 컴포넌트 구조를 정의했습니다.

컴포넌트의 로딩 상태에 대해, 컴포넌트 내부에서 관리하는 것이 맞는 방식인지는 아직 확신이 들지 않았습니다. 다만, 사용하면서 편했던 부분은 isLoading Props만 넘겨준다면 Pattern까지는 로딩 UI를 구현하지 않아도 되어서 좋았습니다.

2. 끝맺음

프로젝트를 통해 제작한 디자인 시스템입니다.

짧은 기간동안 스토리북을 사용하면서 느낀 부분을 정리하다보니 제가 알고 있는 내용이 사실과 다를 수도 있습니다.또한 확장성 있는 컴포넌트를 개발하는 것이 쉽지 않았습니다. ‘어디까지 사용자의 자율성을 보장해줘야하는지’, ‘상태에 따른 UI를 어디까지 분리하고 포함해야하는지’ 아직 확실한 답은 얻지 못했다고 생각합니다. 다른 best practice를 찾아보며, 확장성 및 안정성이 높은 컴포넌트를 개발하고 싶은 욕심이 생기기도 했습니다. 차후에 Storybook의 다양한 기능들을 효율적으로 사용할 수 있도록 따로 공부해볼 계획입니다.

앞으로의 공부하거나 구현해 볼 내용.

1. TypeScript를 사용하여 컴포넌트 개발
2. Global ThemeProvider를 사용하여 U I관리

참고

• 스토리북|디자인 시스템 소개
• 실용적인 프론트엔드 테스트 전략 (2)
• 리디 디자인 시스템