What is StoryBook ?

Storybook is an open source tool for developing UI components in isolation for React, Vue, Angular, and more. It makes building stunning UIs organized and efficient.

• 스토리북은 컴포넌트 단위의 개발을 도와주는 툴로서 하나의 컴포넌트가 어떻게 보여지고 작동하는지 알 수 있게 해주는 툴입니다.

• 이 말은 즉슨 현재 컴포넌트 단위로 개발이 이루어지고 있는 프론트엔드 개발의 흐름에 맞춰서 사용하기 굉장히 좋은 툴이라고 볼 수 있습니다.

왜 사용하는 가?

• 모든 툴들은 필요에 의해서 개발되고 사용자가 그것을 이용하게 되는 시점은 툴을 익히고 사용하는데 투입되는 비용보다 그걸 사용함으로서 얻는 효용이 더 크다고 판단될 때 사용한다고 생각됩니다.

• 그래서 어떤 툴을 사용할때 단지 많이 쓰니까, 주위에서 사용하니까라는 이유로 사용하는 것 보다는 이것을 사용해야 하는 이유를 한번 생각해보고 적용하는 것이 옳고, 또한 실제 사용했을 시에도 고민을 했던 경험을 토대로 더 효율적으로 적용할 수 있다고 판단됩니다.

• 저는 기업협업을 나온 기업에서 스토리북을 사용하기에 기술스택의 선택에 대한 권한은 없었지만 스토리북을 사용함에 앞서 왜 사용하는지에 대해 한번 고민해봤고 그 뒤 실제로 스토리북을 사용하면서 느낀점+ 처음 적용하면서 겪었던 문제들을 정리해보려 합니다.

• 그래서 실제 현재 기업협업 과정에서 스토리북을 이용하면서 컴포넌트 단위의 개발을 하면서 느낀 점과, 스토리북이 무엇인지 알기도 전에 우연히 접하게 되어서 느낀 점을 토대로 왜 스토리북을 사용하는지에 대한 개인적인 견해를 적어보겠습니다.

사용자의 입장

• 제가 처음 스토리북을 접한 시점은 2차 프로젝트 중 airbnb클론을 하던 과정에서 airbnb에서 만든 react-dates 라이브러리를 사용하면서 처음 접해봤습니다.

• react-dates 라이브러리는 자체적으로 스토리북 사이트를 readme에 포함시켜놔서 사용자가 어떤 Props에 어떤 값을 입력했을 때 어떤 변화가 일어나는지 직관적으로 알 수 있게 해주었습니다.

• 처음으로 라이브러리를 사용해보는 시점에 문서를 보고 잘 이해가 되지 않을때 소스코드와 storybook을 함께보면서 어떤식으로 사용자의 입력에 따라 변화가 일어나는지 유추해볼 수 있다는 점이 굉장히 매력적이었습니다.

• 이는 혼자서 개발하는 것이 아니라 여러 개발자의 코드가 모여서 하나의 상품이 완성되는 개발환경의 특징 상 개발자끼리 서로의 코드를 컴포넌트단위로 직관적으로 이해할 수 있게 도와줌으로서 생산성의 향상을 이끌어 낼 수 있습니다.

개발자의 입장

• 현재 기업협업을 하면서 스토리북을 처음 접해보고 컴포넌트 단위의 개발을 시행하고 있습니다.

• 기존의 팀 프로젝트에서의 개발방식은 페이지단위로 작업을 분배하고 각자 맡은 페이지 안에서 컴포넌트를 UI 단위로 판단하고 분리하여 사용하는 식으로 개발을 했습니다.

• 이런 과정에서 서로 협의된 공용컴포넌트(헤더, 푸터, NavBar 등)를 제외한 나머지 컴포넌트는 재사용성을 크게 고려하지 않았고 어차피 제가 사용하는 컴포넌트는 제가 만든 컴포넌트기에 모든 로직을 알고 있고, 이에 따라서 자연스럽게 사용자의 입장에서 커스터마이징을 위한 고려는 거의 안하고 설계를 했었습니다.

• 하지만 스토리북을 접하고 이를 통한 개발을 시도하다보니 자연스럽게 페이지단위가 아닌 컴포넌트 단위로 생각의 확장이 일어나고 이 컴포넌트가 최대한 여러 페이지에서 사용할 수 있게 고려하면서 설계를 하게되어서 최대한 컴포넌트를 컴포넌트답게 만들게 됩니다.(독립적으로 기능하면서 재활용성을 고려하면서 설계를 하게 되는 것을 느꼇습니다.)

• 또한 현재 propTypes를 이용한 storybook documentation을 작성하고 있는데 이를 통해서 props에 어떤 type이 들어오는지, props에 어떤 값이 들어올 때 마다 어떤 형태로 컴포넌트가 변형되는지, 또한 각기 다른 용도로 쓰이는 것을 고려해서 어떤 Props를 받도록 설정해야하는지에 대한 고민을 하면서 컴포넌트를 설계하게 되는 경혐을 했습니다.

결론

• 어떠한 기술, 툴, 패러다임이 모든 상황에서 만능일수는 없기에 이를 적용하기에 앞서 충분한 고민이 필요하다고 생각합니다.

• StoryBook을 사용하면서 느낀 단점은 먼저 컴포넌트 단위로 많은 것을 고려하면서 개발을 하다보니 개발의 속도는 느려지고 스토리북에 관련된 세팅과 이슈를 해결하는데 그만큼의 시간이 더 투입된다는 점입니다.

• 따라서 개인이 진행하는 작은 토이 프로젝트나 규모가 작은 프로젝트에서는 도입합으로서 얻는 이점이 별로 없다고 생각됩니다.

• 하지만 규모가 조금이라도 큰 프로젝트와 여러명이 협업하는 환경에서는 위의 단점을 충분히 상쇄하고도 남을만큼 사용하는 입장에서도 이해하기 쉬워서 다른사람의 코드를 읽고 이해할 때 드는 비용을 줄일 수 있고, 개발하는 입장에서도 자연스럽게 사고를 컴포넌트위주로 할 수 다는 점이 결합되어서 효율적이라고 생각됩니다.

• 또한, 개발팀에서 모든 개발자는 다른사람의 컴포넌트를 사용하는 사용자의 입장이면서 동시에 컴포넌트를 개발하는 개발자의 입장이기에 조직 생산성을 향상시키기에 굉장히 적합한 툴이라고 생각이 듭니다.

• 그리고 하나의 페이지가 완성되기 전에도 결과물을 컴포넌트 단위로 불 수 있고 이러한 장점으로 인해 컴포넌트단위로 피드백을 하면서 개선해 나갈 수 있다는 점 또한 장점으로 느껴집니다.

결과적으로 아래와 같은 장점이 있기에 스토리북을 이용한 개발방식이 효율적이라고 생각됩니다.

1. 다른사람의 코드를 이해하는데 드는 노력을 줄일 수 있다.
2. 자연스럽게 컴포넌트단위로 생각하면서 개발을 진행할 수 있다.
3. 문서화를 통해서 컴포넌트의 사용성과 코드의 가독성에 대해서 다시 한번 고민하면서 개발하게 해준다.
4. 페이지단위가 아닌 컴포넌트 단위로 결과물을 보면서 진행상황을 확인할 수 있고 그로 인해 빠르고 잦은 피드백을 통해서 결과물을 개선시킬 수 있다.