StoryBook을

프론트엔드 팀에 테스트를 도입하면서 Storybook 을 함께 붙여 본 기록이다. 자릿수에 따라 폰트 크기가 바뀌는 카운터 컴포넌트를 예로, 상태를 일일이 바꿔 가며 확인하던 방식을 여러 케이스를 한 화면에서 보는 방식으로 대체한다.

핵심 포인트

보통은 init state 를 바꿔 가며 UI 케이스를 확인하는데, Storybook 을 쓰면 여러 케이스를 한 번에 늘어놓고 볼 수 있다.
UI 개발이 끝난 뒤 디자이너·기획자와 공유해 QA 를 수월하게 진행할 수 있다는 협업상의 이점도 있다.
스토리로 만들어야 하다 보니 관심사에 따른 컴포넌트 분리도 자연스럽게 잘 된다.
대신 두 가지 비용이 있다. 디자인이 컴포넌트 단위로 잘 정리돼 있어야 효과가 크고, 단일·복합 컴포넌트의 엣지 케이스를 전부 커버하려면 개발과 유지 비용이 늘어난다.
예제 구성은 CRA + TypeScript + styled-components 이며, E2E 도구인 Cypress 도 함께 적용한다.

상세 정리

도입 배경: 잠재 이슈를 줄이고 구조 변경 리팩터링을 안전하게 하려고 TDD 기반 개발을 도입하는 흐름에서 Storybook 이 함께 검토됐다.
첫 인상: 여러 케이스를 나눠 한 번에 확인하며 UI 를 개발할 수 있다는 점 하나만으로도 기대가 크다고 밝힌다.
디자인 전제: 컴포넌트 단위로 잘 나뉜 디자인이 있어야 효과가 극대화되며, 이는 디자이너·기획자와의 긴밀한 협업과 숙련도의 문제라고 본다.
설치: 프로젝트에 Storybook 을 init 하면 stories 폴더와 예제 코드가 생성되고, 별도 명령으로 로컬에서 띄운다.
예제 컴포넌트: `src/components/Counter.tsx` 는 자릿수에 따라 폰트 크기가 90·70·50px 로 바뀌는 카운터다.
문제 제기: 두 자리까지는 + 버튼을 눌러 확인할 수 있지만 세 자리는 결국 init state 를 고쳐야 한다. 테이블·카드처럼 UI 가 많아질수록 이 방식이 부담이 된다.
해결: `Counter.stories.tsx` 에 케이스별 스토리를 정의하면 Storybook 화면에서 한꺼번에 확인된다.
저자는 예제가 단순해 필요성을 못 느낄 수 있다고 인정하면서도 실제 UI 개발에서는 유용할 것이라고 덧붙인다.