스토리북 도입이 중요한 이유!

스토리북이란?

스토리북은 개발 모드에서 앱과 함께 실행된다. 비지니스 로직과 분리된 UI 컴포넌트를 만들 수 있도록 도와주며 목적에 따라 다양한 방식으로 사용된다.

회사 내부 UI 라이브러리를 문서화하기 위해서 사용하거나 외부 공개용 디자인 시스템을 위해 사용되기도 한다. 처음에는 리엑트를 기반으로 개발되었고 현재는 다양한 프레임워크들을 지원한다.

스토리북 특징

스토리북은 아래와 같은 특징이 있다.

• UI 컴포넌트가 독립적으로 어떻게 렌더링되는지 직접 시각적으로 테스트하면서 개발을 진행할 수 있다.
• 페이지가 아닌 컴포넌트 단위의 결과물을 볼 수 있다.
• 자연스럽게 컴포넌트 단위로 생각하며 개발 진행이 가능합니다.
• 문서화가 되므로 디자이너 또는 타 팀원들과 디자인관련 소통이 원활해진다.

스토리북 도입 계기

현재 회사에서 개발하고 있는 서비스는 실시간으로 변경되는 데이터에 따라서 표출해야 할 UI가 달라진다. 이 부분 때문에 디자이너가 디자인을 검수하는데 많은 불편함을 느끼고 있었다.

기존 검수 방법은 개발자가 개발을 완료하면 develop 환경으로 배포된 페이지에서 검수를 진행했다. 하지만 디자이너가 실제로 데이터를 조작하면서 실시간으로 변경되는 UI를 검수할 수 없어서 개발자들에게 데이터 조작을 부탁을 하거나 일부 UI는 제외하고 검수를 진행했다.

따라서 기존 방법은 불편하다고 판단했고 디자인 검수를 위한 방법을 찾기 시작했으며 그 때 스토리북이 적절하다고 판단했다. 회사 내부에서 사용하고 있는 디자인 시스템도 스토리북으로 문서화하면 좋을 것 같고 디자인 검수도 실시간으로 변경되는 데이터를 신경쓰지 않고 검수할 수 있어서 좋다고 판단했다.

따라서, 프로젝트 매니저(PM)에게 도입을 제안했고 개발 기간을 할당받아 진행했다.

스토리북 도입 후기

디자이너에게 디자인 검수 요청 시 스토리북 배포 주소만 전달해주면 되기때문에 상당히 간편해 졌지만 다른 문제가 발생했다.

지금 프로젝트에는 비지니스, 뷰 로직이 분리되지 않은 컴포넌트들이 존재했다. 그러다보니 비니지스, 뷰 로직이 함께있는 컴포넌트에 스토리북을 적용하면, API를 모킹하거나 상태 관리 라이브러리를 사용하는 경우 Mock 컴포넌트를 감싸주는 번거로움이 발생했다.

위 문제들을 팀원들과 논의한 결과 현재 컴포넌트 분리가 잘 안되어있다고 판단했고 스토리북을 적용하는 컴포넌트들을 시작으로 비지니스 컴포넌트(Container component)와 뷰 컴포넌트(Presentational component)로 분리를 시작했으며 점차적으로 모든 컴포넌트에 적용하기로 했다.

비지니스, 뷰 로직을 분리하니 불필요한 모킹과정이 줄여들고 스토리북에서는 뷰 컴포넌트만 import해서 작업하면 되므로 상당히 편하게 작업할 수 있었다.