스토리북이란?

story란 무엇인가요?

story는 컴포넌트를 특정 props와 상태로 렌더링한 예제다.
예를 들어 버튼 컴포넌트가 있다면 기본 버튼, 강조 버튼, 비활성 버튼을 각각 story로 만들 수 있다.

import type { Meta, StoryObj } from '@storybook/react'
import { Button } from './Button'

const meta = {
  component: Button,
} satisfies Meta<typeof Button>

export default meta

type Story = StoryObj<typeof meta>

export const Primary: Story = {
  args: {
    children: '저장',
    variant: 'primary',
  },
}

export const Disabled: Story = {
  args: {
    children: '저장',
    disabled: true,
  },
}

이런 식으로 컴포넌트 상태를 문서처럼 남겨두면 디자이너, 기획자, 다른 개발자가 실제 화면에 들어가기 전에도 UI를 확인할 수 있다.

문서화와 테스트

Storybook은 단순히 컴포넌트 모음집만 만드는 도구가 아니다.
stories를 기준으로 컴포넌트 문서를 생성하고, 상호작용 테스트나 접근성 점검 같은 품질 확인 흐름과도 연결할 수 있다.

특히 디자인 시스템이나 공통 컴포넌트가 많은 프로젝트라면 효과가 크다.
컴포넌트가 어떤 props를 받고, 어떤 상태를 가져야 하며, 어떤 UI 회귀가 발생했는지 팀이 같은 화면에서 이야기할 수 있기 때문이다.

언제 도입하면 좋을까요?

다음 상황이라면 Storybook 도입을 고려해볼 만하다.

• 공통 컴포넌트를 여러 화면에서 재사용한다.
• 컴포넌트 상태가 많아 실제 페이지에서 모두 확인하기 어렵다.
• 디자인 시스템이나 UI 가이드를 코드와 함께 관리하고 싶다.
• UI 변경이 의도한 범위 안에서만 일어났는지 테스트하고 싶다.

반대로 아주 작은 프로젝트에서 컴포넌트 수가 적고 상태도 단순하다면, 처음부터 Storybook을 붙이는 것이 오히려 부담일 수 있다.
공통 컴포넌트가 늘어나고 화면 재현 비용이 커질 때 도입해도 늦지 않다.

참고 자료

• Storybook docs: Install
• Storybook docs: What's a story?
• Storybook docs: Testing