인프런 커뮤니티 질문&답변
작성한 질문수
스토리북에 대해서
작성
·
14
0
안녕하세요. 좋은 강의 감사합니다.
강의를 듣다 보니 Storybook과 Chromatic이
컴포넌트 검증과 협업에 도움이 된다는 점은 이해할 수 있었습니다.
다만 한 가지 궁금한 점이 생겨 이렇게 메시지를 드립니다.
개인 프로젝트나 소규모 프로젝트에서도 Storybook을 사용하는 것이 적절한지,
아니면 디자인 시스템을 갖추거나 컴포넌트 재사용이 많은 프로젝트에서
주로 사용하는 도구인지 판단 기준이 궁금합니다.
규모, 협업 인원, 유지보수 관점에서
Storybook 도입 여부를 결정할 때
어떤 기준으로 판단하는 것이 좋은지도 알고 싶습니다.
모든 프로젝트에서 Storybook을 사용하는 것이
오히려 관리 비용이 될 수도 있겠다는 생각이 들어,
Storybook을 사용하는 것이 효과적인 경우와
굳이 사용하지 않아도 되는 경우를
어떻게 구분하면 좋을지 조언을 듣고 싶습니다.
감사합니다.
답변 1
0
결론부터 말씀 드리자면 개인 프로젝트나 소규모 프로젝트에는 적합하지 않다고 생각합니다.
엔지니어마다 생각이 다르겠지만, 저는 기술을 도입할 때는 해당 기술이 필요할 때 도입하는 것이 맞다고 생각합니다. Storybook도 기술이라고 본다면, Storybook이 필요할 때 도입하는 게 맞다고 생각합니다.
예를 들면
Storybook 도입이 권장되는 경우 (효과가 비용을 상회함)
복잡한 UI 상태가 많은 프로젝트: 특정 조건(에러, 로딩, 데이터 만료, 다양한 권한 등)에서만 보이는 UI가 많을 때, 이를 확인하기 위해 매번 앱의 복잡한 비즈니스 로직을 타는 것은 비효율적입니다. Storybook은
UI를 격리된 환경에서 즉시 확인할 수 있게 해줍니다.컴포넌트 단위의 협업이 필요한 팀: 기획자나 디자이너가 개발 중인 UI를 수시로 확인해야 하거나, 개발자가 만든 컴포넌트의 사양을 문서화하여 공유해야 할 때 매우 유용합니다.
시각적 회귀 테스트(Visual Regression Test)가 중요할 때: Chromatic과 연동하여 CSS 수정이 엉뚱한 페이지의 버튼 디자인을 깨뜨리지 않았는지 자동으로 검증하고 싶을 때 필수적입니다.
자체 디자인 시스템을 구축할 때: 여러 프로젝트에서 공통으로 사용할 컴포넌트 라이브러리를 만든다면, Storybook은 선택이 아닌 필수입니다.
2. Storybook 도입을 재고하거나 나중에 해도 되는 경우 (관리 비용이 더 큰 경우)
UI 요구사항이 단순하고 정적인 경우: 표준 UI 라이브러리(MUI, Tailwind UI 등)를 거의 그대로 사용하고 커스텀 컴포넌트가 적다면 Storybook 관리 비용이 더 큽니다.
비즈니스 로직 중심의 프로젝트: UI보다는 서버 사이드 로직이나 복잡한 계산이 핵심인 대시보드 형태의 앱이라면, UI 격리 개발의 이점이 줄어듭니다.
프로토타이핑 단계: 내일 당장 디자인이 뒤엎어질 수 있는 초기 가설 검증 단계에서는 스토리북을 작성하는 행위 자체가 낭비가 될 수 있습니다.
꼭 필요하지 않은 상황에 도입하면 오히려 관리 포인트가 늘어난다고 생각합니다. 질문해주신 내용과는 다르지만 예전에 프로토타입단계에서 백엔드에 쿠버네티스를 도입했던 적이 있는데, 관리할 것도 없는데 관리 툴을 너무 과대한 걸 쓰다보니 오히려 고생햇던 경험이 있습니다.
다만 제 의견이 정답은 아니니 다양한 분들의 의견을 들어보시고 최종적으로 판단하시면 좋겠습니다!
감사합니다!