Storybook

스토리북은 프론트엔드에 유용한 문서화를 할수있는 도구이며, 디자인 시스템을 확인/검증 할수있는 라이브러리이다. 일반적으로 하나의 컴포넌트는 하나의 스토리를 사용하고
여기서 말하는 스토리는 하나의 단위이다

사용하는 이유

• 시각적 테스트

• 컴포넌트 단위 개발

• 재사용성 /일관성

• 외부공개용 디자인 시스템

  시각적 테스트

  
  그림과 같이 길이를 측정하거나 또한 시각적으로 컴포넌트가 정확하게 원하는대로 랜덩링이되는지 확인할수있는 역할을 해준다.

  컴포넌트 단위 개발

  
  여러가지의 variant를 주어서 컴포넌트를 확인하고 또한 컴포넌트를 나누어서 작업할수있게 도와준다, 개인의 차이가 있겠지만 실제로 storybook을 사용하면 그냥 개발할때보다는 더 쉽게 컴포넌트 분리를 할수있었고 더 비슷한 디자인을 더 쉽게 찾을수있게 되었다.

재사용성 / 일관성

디자인 시스템이 다 갖추어진 프로젝트이면 좋겠지만 사이드 프로젝트같은 경우 디자인 시스템이 갖추어지지 않고 진행을 많이 한다 이때 피그마에서 만들어 놓은 버튼들 만 해도 여러 종류가 되는데 이러한 컴포넌트를 재사용하게끔 생각을 정리할수있게 도와주고 또한 일관성을 유지 할수있게 해준다. 실제 페이지에서 보는것과 컴포넌트를 분리시켜서 보는건 차이가 있기 때문에 하나하나의 컴포넌트를 확인해볼수있는 좋은 방법이 되는 것 같다.

외부 공개용 디자인 시스템

개인적으로 가장 중요한 역할을 하는 부분이라고 생각합니다, 디자이너와 협업을 할때 디자이너가 확인을 할수있는 환경이 제한적인데 storybook을 사용할때는 디자이너에게 개발모드( github 부터 개발모드 까지)의 방법으로 설명해서 디자이너의 로컬 환경에서 확인하는 방법을 사용하다가 배포된 이후로 배포된 사이트를 확인했는데, 이때 문제가 디자인을 조금만 수정해도 재배포를 해야되거나 로직을 완성되지않았는데 디자인을 확인해야되는 경우가 많이 있었는데 storybook을 배포해서 디자이너는 배포된 storybook으로 확인하고 개발자는 계속해서 로직을 구현할수있게 되었다 따라서 더이상 불완전한 코드를 배포할 필요도 없어지고 디자인이 바뀌였을때 매번 배포하는것도 더이상 필요가 없어졌다.

개인적인 의견

UI의 문서화, 작은 프로젝트에서는 문서화의 필요성이 그렇게 크지는 않았지만 디자이너와 협업을 진행했을때는 많은 도움이 되었다.
디자인도 당연히 중요하지만 개발로서 로직이 더 중요했고, 매번 디자인이 바뀔때만 배포를해서 보여주기에는 시간적으로나 안정성적으로 너무 좋지않은 방법이기때문에 디자이너가 실제 웹에서 보여지는 컴포넌트를 확인할수있는 환경이 필요했을때 storybook을 사용해서 디자이너는 해당 storybook을 확인하면서 수정을하고, 개발자는 계속해서 로직작업을 진행하면 되기에 시간과 스트레스? 를 많이 해소해주었다. 배포된 후에도 전체적으로 확인하는 작업이 필요하겠지만, 간단한 디자인 수정사항같은 경우 storybook으로 충분히 확인하고 수정사항을 체크할수있어서 아주 좋은 중간 다리 역할이 되었다. 추가적으로 addon 같은 기능을 추가적으로 활용해서 개선해볼 생각이다.