스토리북(storybook) ui란?

만약 우리가 IT계열이 아닌 그 어떤 다른 직업을 가지고 있다고 가정할 때, storyBook이라는 말을 처음 듣는다면 어떤 생각이 떠올랐을까? 나는 단연 이야기, 혹은 동화책 등에 관한 내용일거라 생각한다.

이야기를 뜻하는 story라는 단어의 뜻이 가장 크게 와닿기 때문이다.

만약에 우리가 고려해야하는 사용자 시나리오 혹은 기획자 의도 혹은 비즈니스 로직 혹은 테스트 케이스 등등이 하나의 이야기라고 생각하면 본 포스팅에서 소개해 볼 storyBook이 조금 더 쉽게 이해될까?

---

마크업도 백엔드도 중요하지만 그 사이 다리를 이어주는 프론트는 적당히 백엔드를 커버하면서도 적당히 마크업을 커버하면서도 사용자에게 최고의 경험을 제공하기 위하여 그 이상의 코드를 구현하면서 날이 갈수록 방대해지고 복잡해지는 경험을 하는 것은 비단 내가 경험했던 프로젝트에서만 한정되는 이야기는 아닐 것이다. 우리는 이 복잡도를 낮추어줄 무언가가 절실하게 필요한데, 이 때 사용되는 것이 바로 '스토리북'이다.

https://storybook.js.org/

https://storybook.js.org/

Storybook: UI component explorer for frontend developers

한 문장으로 정의하자면 '컴포넌트 기반의 View를 위한 UI 개발 환경' 정도가 될 것 같은데, 개인적으로는 스토리북의 개념이 문자를 통하여 명확하게 잘 정의되지 않아서 포스팅을 작성하게 되었다.

우리가 프로젝트를 진행할 때를 생각해보자. (설명은 React를 기준으로 작성되겠지만 사실 Vue와 Angular도 똑같은 구성으로 진행되기 때문에 이해하는데에 어려움은 없을것이다.)

보통은 하나의 루트 컴포넌트가 있고, 그 하위에 여러 모듈로 된 컴포넌트들이 props 등을 통하여 서로가 필요한 상태를 주고 받으면서 각자가 맡은 역할을 수행하며 서비스를 제공하게 된다. 깔끔하게 구조를 구성한다고 하더라도 그 규모가 점점 커지다보면 거미줄처럼 얽혀있는것이 우리네 현실이다.

거미줄처럼 얽히고 설킨 컴포넌트들 가운데 우리가 필요한 컴포넌트가 깊숙하게 숨어있는 컴포넌트라면?
거미줄처럼 얽히고 설킨 컴포넌트들 가운데 우리가 필요한 컴포넌트가 이곳 저곳에서의 상태 변화값에 따라 A 또는 B 또는 C로 변해야하는 컴포넌트라면?

하나의 로직을 체크하는데에만도 컴포넌트 간의 관계, 파라미터의 의존성을 파악하는데 많은 시간이 들 뿐더러 로직 변경 후, 체크 테스트에도 하나씩 노가다를 하며 상태를 변경하며 확인해야하는 시간도 만만치 않을 것이다.

스토리북은 하나 혹은 여러 컴포넌트에서 실행되는 로직을 하나의 이야기라고 생각하고, 스토리를 만들어 상태값을 이야기에 주입하여 보면서 그 결과를 쉽게 확인할 수 있도록 해준다.

스토리는 만들고 싶은대로 자유롭게 만들 수 있는데, 필요한 컴포넌트들을 생성하여 나열해보면 거미줄 같던 컴포넌트들이 이내 하나의 라인처럼 정리되는 것을 느낄 수 있을 것이다.

또한 단순히 뷰를 보여주는 것 뿐 만 아니라 개발자가 인터렉티브하게 테스트가 가능하고, 또 스토리북을 통하여 PM 혹은 디자이너 혹은 기획자 등 다양한 파트들과 협업하는데에 서로의 이해를 배가시켜 줄 수 있는 장점이 있다.(고 생각한다. 아직 현업에서 커뮤니케이션 용으로 사용해보지는 않았지만, 공부하면서 어떻게 사용하는 것이 효율적일까 함께 공부하는 시간이 되었으면 좋겠다.)

자, 이제 상단에 언급했던 조금은 이해하기 난해했던  '컴포넌트 기반의 View를 위한 UI 개발 환경' 이라는 스토리북의 뜻이 조금은 이해되었으리라 믿고싶다.