.jpg)
공식홈페이지에서 소개하고 있는 스토리북의 소개는 다음과 같다.
Storybook is a user interface development environment and playground for UI components. The tool enables developers to create components independently and showcase components interactively in an isolated development environment.
— 스토리북은 UI 개발 환경이자 UI 컴포넌트를 위한 놀이터입니다. 개발자들이 컴포넌트를 독립적으로 만들고, 격리된 개발 환경에서 상호작용이 가능한 컴포넌트를 선보일 수 있도록 해줍니다
사실 소개를 봐도 좀 감이 안 오고 여러가지로 찾아봐도 잘 감은 안 왔는데,
실무에서 사용하게 될 때의 이야기를 좀 찾아보니까 그제서야 감이 좀 왔다.
스토리북은 철저하게 디자인적인 부분만을 떼어서 볼 수 있게 도와주는 개발 환경을 구성해준다는 것이었다.
이게 무슨 소리냐면, 어쨌든 어떤 컴포넌트를 만들면 그것이 기능이 작동을 해야 하니까 이런 기능도 넣고 저런 기능도 넣고 하다보니 결국 코드가 복잡해지고 서로 섞여있어서 온전히 디자인만을 놓고 고민하게 될 때는 약간 불편해지는 지점이 있다. 수정하다가 기능 관련한 코드를 잘못 건드리면 동작하지 않게 되는 경우도 있다보니 조심해야 하기도 하고. 하지만 디자인이라는 것이 정말 미세한 부분에서 차이를 가지고 그것에 따라 느낌이 바뀌기도 하기 때문에 아무리 조심한다한들 실수를 하기 마련이기도 하다. 그런 때에 스토리북을 사용해서 개발을 하다보면 코드와 독립된 환경에서 디자인만을 알아볼 수 있는 것 같았다.
또 아무래도 프론트엔드 개발자가 디자인적인 부분을 어느정도 담당하고는 있다고 하지만 전문적인 디자이너만큼의 감각을 갖는 것은 어려운 부분이기도 한데, 그래서 정말 실무에서는 디자이너와의 협업을 많이 하게 되는 것으로 안다. 그런데 반대로 디자이너들은 개발자가 아니기 때문에 개발적인 부분에서의 디테일 같은 것을 생각하지 못하는 경우가 있는 것 같다. 정적인 부분에서야 보여지기 때문에 소통이 쉽게 가능하지만 동적인 부분에서는 소통 오류가 생길 수 있는 가능성이 높아지는 것이다. 예를 들면 버튼을 클릭해서 모달창을 띄울 때 이 모달창은 바깥 영역을 클릭해도 꺼지는지 아니면 x버튼을 눌러야 꺼지는지 와 같은 경우가 될 것 같다. 스토리북인 이런 동적인 부분까지 디자이너와 소통 할 수 있게 도와주어서 좋은 개발도구가 되는 것 같다.
