스토리북은 무언인가?
UI 컴포넌트를 완성된 프로그램으로 생각하게 만들어주는 도구 라고 생각한다.
우리는 storybook을 사용하게 되면서, UI 컴포넌트에 대해
- 문서화 작업
- 기능테스트
- 시각적테스트
등의 작업을 진행하면서, UI컴포넌트 자체를 하나의 완성된 프로그램으로서 만들어 나간다.
문서화 작업
React나 컴포넌트 기반의 프론트엔드 개발을 진행하면, 꼭 겪게되는 문제가 있다. 다른사람 (과거의 나를 포함해서) 이 만든 컴포넌트의 존재를 모르거나, 이해할 수 없는 경우이다.
컴포넌트가 있는지도 몰라서 다시 똑같은 기능의 컴포넌트를 만든다거나, 이미 만들어진 컴포넌트지만 그 컴포넌트의 기능을 제대로 이해하지 못해, 결국 다시 만들어 버린다던가하는 일이다.
아마 React기반의 프론트엔드 개발을 진행해본 사람이라면 특히 공감하리라 생각한다. 이러한 상황에서 Storybook은 문서화를 통해 중복된 작업을 막을 수 있다.
위 문서는 BBC에서 사용하고 있는 Storybook의 한 부분이다. 위와같이 Storybook을 사용하게 되 면, 따로 문서페이지를 제작하지 않고도 문서페이지를 만들어줘, 각 개발자 _(역시나 과거의 나와의 협업)_와 서로 겹친다던가, 컴포넌트를 이해하지 못해 새로 만드는 불상사를 막아 줄 수 있다.
기능과 시각적 테스트 진행
스토리북에서 가장 중요한건 역시나, 스토리이다. 그렇다면 스토리는 무엇일까? 스토리란, '컴포넌트가 가질 수 있는 하나의 상태'를 의미한다. 예를 들어보면, input 태그의 checkbox형태는 checkbox가 '체크됨', '체크되지 않음' 두개의 상태를 가지며이는 각각 하나의 스토리에 대응된다.
즉, '스토리1: 체크됨', '스토리2: 체크되지 않음' 을 가지게 된다.
위를 통해서, 각 컴포넌트에 대해서 부가적인 과정을 없애고 컴포넌트가 가지는 '스토리' 에 대해서만 시각적, 기능적 테스트를 진행할 수 있다.
Add-ons
chromatic
- UI요소의 시각적 피드백을 도와주는 도구
- 각 요소가 변경되면, 왼쪽은 기존, 오른쪽은 변경 후로 초록색영역을 통해 바뀐 부분이 어디진이 어떻게 바뀌었는지 시각적으로 보여준다.
addon-a11y
- 웹 접근성의 상태파악을 알려주는 도구
- 각 컴포넌트가 웹 접근성항목을 만족시키는지 확인 시켜준다.
좋은것만 있나?
좋은것 1. 리팩토링 과정의 단순화
React로 개발한 프로젝트를 리팩토링을 하면, 일단 어떤 컴포넌트가 있는지, 중복된 컴포넌트가 무엇인지 확인하며 부터 시작했었다. 위 스토리북을 사용하면, 일단 중복된 컴포넌트가 생길 이유가 없고, 또한 컴포넌트를 확인하는 과정도 문서화가 모두 되어 있기 때문에 그 과정을 굉장히 빠르고, 단순화 할 수 있다.
좋은것 2. 신규 개발자의 학습 단축
백엔드의 잘 구성된 API문서가 그렇듯, 신규 개발자가 팀에 들어오게 되면, 위 문서를 읽음으로서 프로젝트의 진행상황을 보다 쉽게 학습할 수 있다.
나쁜것 1. 초기 구성이 힘들다.
기존 프로젝트가 스토리북을 사용하지 않으면, 위 환경을 구성하는데 많은 노력과 시간이 들어갈 수 있다.
나쁜것 2. 전 팀원의 적극적인 참여가 필요
자기가 만든 부분을 문서화 하고, 또 개발시 마다 문서를 확인하고 개발을 진행하는 등, 경험해보지 못한 팀원의 교육이 필요하다.
그래서, 상황에 맞는 적용이 필요하다.
정말 간단한 몇페이지 SPA 프로젝트에는 위 스토리북 솔루션이 들어가는 비용에 비해 큰 효과를 갖지 못할 수 있다.
'Web' 카테고리의 다른 글
Typescript: Union 형식, Intersection 형식, 상속 (2) | 2025.01.24 |
---|---|
프론트엔드를 좀 더 자세히 들여다 보기 위해서 (0) | 2023.09.12 |