컴포넌트는 외부 상태의 영향을 받지 않는 독립된 개체로서, 고립된 환경에서도 자신만의 스타일과 상태를 가질 수 있어야 한다.
이 같은 컴포넌트의 철학을 가지고 프론트엔드 개발에서 현재 컴포넌트 단위로 개발이 이루어지고 있다.
다음과 같은 철학으로 개발을 진행하는 중, 개발자들은 모순에 봉착하게 되었다. 개발은 컴포넌트 단위로 진행하지만 실제 개발환경은 항상 페이지 단위로 만들어진다는 점이었다.
이는 서비스에서 사용하는 수 많은 버튼의 상태를 의존성과 환경 변수가 걸려있는 페이지에서 일일이 테스트를 해야 했기 때문이다. 이 경우, 개발자는 온전히 뷰에 집중하기 어려워지고 컴포넌트의 의존성을 쉽게 파악하기가 어려워진다. 컴포넌트를 온전히 고립시키지 못하는 것이다.
이에 컴포넌트를 완전히 고립시키기 위하여 컴포넌트 단위의 개발 환경을 지원해주는 StoryBook이라는 개발 도구가 생기게 되었다.
컴포넌트 단위 개발을 위해 스토리북을 사용해라
01. 컴포넌트 갤러리, 스토리북
공식 홈페이지에서는 storybook을 “UI 개발 환경”이라고 소개하고 있다. 일종의 컴포넌트 갤러리라고 할 수 있는데, 위의 사진과 같이 애플리케이션에서 사용되는 모든 컴포넌트의 조합을 페이지별로 등록해 놓고 편리하게 눈으로 확인할 수 있도록 네비게이션을 제공한다.
다음과 같이 컴포넌트를 나누어 네비게이션을 제공하는 것은 개발자가 컴포넌트의 뷰에 온전히 집중할 수 있도록 도와주게 된다.
02. 스토리북을 이용한 컴포넌트 테스트
스토리북은 단순한 갤러리가 아니다. 위의 그림을 보게 되면 Actions, Controls를 볼 수있는데, 이 기능들은 더욱 컴포넌트의 분리가 가능하도록 도와준다.
먼저 Actions의 경우, 컴포넌트를 통하여 특정 함수가 호출 되었을 때 어떤 함수가 호출 되었는지 그리고 함수에 어떤 파라미터를 넣어서 호출 했는지에 대한 정보를 확인할 수 있게 해준다.
Controls의 경우, 아래의 그림과 같이 Props로 전달받은 것들을 변화시켜Canvas에서 시각적 테스트를 진행할 수 있도록 도와준다.
03. 관심사 분리(SoC)를 극대화 시키는 컴포넌트 단위 개발
위와 같이 하나의 컴포넌트에서 UI, 기능 등 다양한 것을 테스트할 수 있게 스토리북이 만들어졌다. 이는 기존에 빌드하여 페이지내에서 여러 컴포넌트들의 테스트를 진행해야 했던 것들을 컴포넌트 내에서 일일이 테스트를 진행할 수 있다.
이렇게 컴포넌트 단위로 테스트를 하며 개발을 할 수 있다는 것은 관심사 분리 패턴을 이용하여 개발을 진행할 수 있도록 도와줄 수 있다.
SoC(Separation of Concerns)는 프로그램을 작은 조각으로 나누어 각각 간단한 개별 작업을 완료할 수 있도록 만드는 것이다.
이로 인해 개발자들은 컴포넌트 단위의 개발을 진행하며, 컴포넌트의 재사용성을 높여 개발을 진행할 수 있게 되었다.
디자인 시스템과 함께 도입해라
컴포넌트 단위의 개발에서 Storybook은 디자인 시스템과 같이 도입하는 것이 효율성이 높다. 이를 증명하듯, Storybook은 문서화와 같은 기능을 추가하며 디자인 시스템을 구축하기 위한 발전을 진행하고 있다.
01. 디자인 시스템이란
디자인 시스템의 기본적인 목적은 팀의 작업을 용이하게 하는 것이다.
디자인 시스템은 디자인 원칙, 규격, 다시 사용할 수 있는 UI 패턴과 컴포넌트, 코드를 포괄하는 종합 세트이다. 그렇기에 팀이 제품을 디자인하고 실현화하고 개발할 수 있는 요소들을 그룹화하는 단일 기준을 제공하게 된다.
디자인 시스템은 디자이너, 개발자, 기획자 등 관련 이해 관계자들이 프로젝트를 일관성이 있게 구축할 수 있도록 도와준다. 또 프로젝트가 제품 군/ 기능 확장, 새로운 시장 진출 체널 매개체 확장등의 경우 재사용이 가능하도록 도와준다.
02. 디자인 시스템과 스토리북
디자인 시스템은 여러 프로젝트가 같은 UI 컴포넌트를 공유할수록 이점이 생긴다. 다른 앱이나 여러 팀 간에 같은 UI 컴포넌트를 공유하는 경우라면 이러한 디자인 시스템이 더욱 필요할 것이다.
디자인 시스템의 재사용성을 위해 컴포넌트 단위 개발의 필요성이 대두되었다. 또, 스토리북은 개발한 컴포넌트를 다양한 기능을 통하여 기획자, 디자이너가 손 쉽게 보고 테스트 할 수 있게 도와준다.
또한 스토리북은 Docs로 문서화를 지원하며 일회성 생명주기를 가진 컴포넌트가 아닌 이상 어떤 구조로 만들어졌고, 어떤 속성변화에 의존하여 UI가 변경되는지 문서화 하는 작업이 가능하도록 하였다.
03. 디자인 툴과의 협업
최근의 디자인을 보면 위와 같이 컴포넌트 단위로 디자인이 이루어지는 것을 볼 수 있다. 디자이너 또한 컴포넌트의 재사용성을 위해 UI 컴포넌트 구조화를 위해 노력하고 있다. 이는 디자인 시스템을 기반으로 프로젝트가 구성되고 있기 때문이다.
디자인 시스템을 기반으로 재사용성을 높인 컴포넌트가 만들어지고 개발이 진행된다. 때문에 개발자들에게 디자인 시스템에 맞추어 컴포넌트 기반의 개발을 지원하는 스토리북이 필요하다 생각한다.
다음 기능으로 스토리북 효율을 극대화 해라
01. docs
위와 같이 스토리북을 실행했을 때, docs는 이와 관련된 문서화를 지원해주는 기능이다. argType 별로 어떤 역할을 수행하고, 어떻게 사용되는지 문서화 작업을 도와주는 역할을 한다.
02. snapshot 테스트
Storybook을 다루면서 Snapshot Testing에 대해 다루지 않을 수가 없다. 그 이유는 바로 Snapshot Testing이 CSS, UI를 테스트할 때 이루어지는 테스트 방법이기 때문이다.
Snapshot Test는 UI가 예기치 않게 변경되지 않도록 하려는 경우 매우 유용한 도구이다. 일반적으로 UI 구성 요소를 렌더링하고 스냅샷을 만든 다음 테스트와 함께 저장된 참조 스냅샷 파일과 비교한다. 두 스냅샷이 일치하지 않는 경우 테스트가 실행한다.
03. Chromatic
Chromatic은스토리북 배포, UI Test, UI Review를 지원한다.
Github과 연동하여 UI Test의 승인이 되었는가도 PR merge 여부에 포함시킬 수 있다. 또한 Github과 Slack을 연동할 시에 Storybook을 볼 수 있도록 지원이 가능하여 개발에 관여하지 않는 사람도 컴포넌트에 대해 간단히 볼 수 있다.
이와 같은 기능들을 익혀 스토리북을 더 잘 활용할 수 있다. 또 스토리북의 장점을 극대화 시킬 수 있어 사용을 추천한다.
맺음말
개발을 시작할 때, 스토리북을 처음으로 사용해보았다. 그때는 무엇을 위해 이 툴을 사용하는 지에 대해 알지 못하였고, 사용법만 익혀 사용하였던 기억이 있다.
하지만 최근 한 회사에서 프리랜서 일을 하며, 스토리북을 사용하는 방식을 보고 스토리북을 다시 보며 되짚어보고 싶은 마음에 이 글을 다시금 작성하게 되었다.
이 글이 스토리북에 대한 이해도를 높일 수 있는 기회가 되었으면 좋겠다.
