스토리북 작성을 통해 얻게 되는 리팩토링 효과

모든 컴포넌트를 Storybook 스토리와 병행 작성하면서 자연스럽게 리팩토링이 이루어진 카카오엔터테인먼트의 실전 경험담이다. '과로·발작 증세·피터팬 증후군'이라는 유머러스한 병명으로 분류한 3가지 컴포넌트 설계 문제를 스토리 작성 과정에서 강제로 발견하고 개선한 사례를 코드로 설명한다.

핵심 포인트

Storybook에서 잘 그려지는 컴포넌트, 테스트하기 쉬운 컴포넌트, 설계가 잘 된 컴포넌트 사이에는 양의 상관관계가 있음
스토리 작성의 핵심 특징 두 가지: 독립적인 환경에서 그리기 + 컴포넌트를 재사용하여 다시 그리기 → 이 두 조건이 자연스럽게 설계 결함을 노출
과로(하나의 컴포넌트가 너무 많은 책임): 렌더링 외 사이드이펙트를 분리해 Presentational 컴포넌트로 추출하는 리팩토링 유발
발작 증세(때로 잘못된 결과로 렌더링되는 경우): 스토리에서 재현하면서 조건부 렌더링 버그 발견
피터팬 증후군(독립적으로 그리면 의도와 다르게 나오는 경우): 부모 컨텍스트에 과도하게 의존하는 컴포넌트 발견
Container/Presentational 패턴 분리와 FaceFetcher 같은 Loader 컴포넌트 분리가 스토리 작성을 쉽게 만들고 재사용성도 향상

상세 정리

결제 완료 모달 같이 특정 조건이 필요한 컴포넌트는 앱에서 직접 확인하려면 재현 비용이 크지만 스토리로 즉시 확인 가능
스토리는 결과물 확인뿐 아니라 설계 결함 발견 도구로서 부수적 효과를 제공
과로 해결: 데이터 로딩·라우팅·상태 관리 등 사이드이펙트를 담당하는 컨테이너와 순수 렌더링만 담당하는 Presentational 컴포넌트 분리
아토믹 디자인 참고해 컴포넌트를 분리하고 디렉터리 계층 구조(hierarchy)도 함께 정비
데이터 패칭이 내부에 캡슐화된 컴포넌트는 스토리에서 모킹이 필요해 번거로움 → Container/Presentational Pattern으로 외부 주입 형태로 변경
FaceFetcher 패턴: Suspense fallback + 패칭 컴포넌트 + 순수 Face 컴포넌트로 3단 분리
react-query 캐싱 덕분에 여러 곳에서 동일 데이터를 패칭해도 부담이 줄지만, 이미 상위에서 패칭했다면 상태 관리로 가져오는 게 더 깔끔함
과하게 작은 범위로 분리하지 않는 것이 중요 — 재사용 가능하거나 시맨틱으로 구분되는 단위면 충분

왜 읽나Storybook 도입 효과를 시각화 도구에 그치지 않고 설계 개선 강제 장치로 활용하는 시각이 실제 코드 변환 사례와 함께 담겨 있다.

카카오 엔터테인먼트 FE 블로그

원문은 여기서 이어서 읽을 수 있어요

원문 읽기

읽음 (0)

·takedown 요청

스토리북 작성을 통해 얻게 되는 리팩토링 효과

이 글과 비슷한

토스는 어떻게 광고 속에 게임을 넣었을까

RxJS로 우아하게 사이드 이펙트 통제하기

항공 프론트엔드 구축기 (7/10): 창구를 하나만 두었습니다