도구 이름을 아는지가 아니라, 도입의 실무 가치와 유지 비용을 같이 두고 어디까지 적용할지 끊을 수 있는지 가르려는 질문이다.
Storybook은 UI 컴포넌트를 실 애플리케이션 실행 환경과 분리해 독립된 페이지에서 개발·문서화·검증하게 해주는 도구다. Story는 한 컴포넌트의 특정 상태나 변형(기본·비활성·에러·로딩 등)을 props·mock으로 고정해 둔 단위라, 디자인·QA·개발이 같은 화면을 보고 검수하는 기준이 된다. 그래서 디자인 시스템 운영, 회귀 방지, 디자이너·QA 피드백 루프에 큰 효용이 있다. 다만 스토리 작성과 mock 데이터 유지, MDX·애드온 설정 같은 비용이 따로 붙기 때문에, 어디까지 스토리로 고정할지 범위를 정해 두지 않으면 유지비용이 조용히 부풀어 오른다.
Storybook 도입 전후로 UI 회귀 대응 속도·검수 사이클을 비교해 본 경험이 있다면 효과 측정 사례로 연결할 수 있다
어떤 상태(에러·빈 데이터·로딩)까지 스토리로 고정할지 팀 컨벤션을 잡아 본 적이 있다면 범위 설계 관점으로 말할 수 있다
비동기·데이터 의존 컴포넌트의 mock 전략을 정리해 본 경험이 있다면 유지보수 부담을 통제한 사례로 엮을 수 있다
아직 공개된 답변이 없어요. 첫 공개 답변을 남겨보세요.