[ COCOMU ] 왜 이제서야 Storybook을 도입했냐고요?

MVP 개발 당시, 저희 팀은 컴포넌트를 구현할 때 임시 페이지를 하나 비워두고 해당 컴포넌트를 렌더링한 화면을 보며 작업했습니다.
또한 각 기능이 잘 동작하는지 확인하려면, props를 직접 수정해가며 상태를 하나씩 확인해야 했습니다.

 

하지만 이런 과정을 매번 반복하는 건 매우 번거로웠고, 자연스럽게 이런 생각이 들었습니다.

“컴포넌트를 따로 떼서 테스트하고 문서화할 수 있으면 좋지 않을까?”
“다른 팀원에게 보여줄 때도, 상태별로 정리된 화면이 있으면 편할 텐데…”

 

그러다 다시 떠오른 도구, Storybook

사실 Storybook은 전부터 알고 있던 도구였습니다. 하지만 당시에는 MVP 개발 제한 기간이 짧았고, 기능 구현 속도가 최우선이었죠.

 

저희는 프로젝트의 요구사항과 우선순위에 따라 테스트 코드는 작성하지 않기로 했고, Storybook 도입 역시 그 시점에서는 개발 효율보다 빠른 구현이 더 중요한 상황이었습니다. 그렇게 빠르게 MVP를 완성해 나갔지만, 컴포넌트를 독립적으로 테스트하고 다양한 상태를 확인하는 작업이 점점 비효율적이고 반복적인 과정이라는 걸 절감하게 되었습니다.

그래서 MVP가 완료되고 프로젝트를 고도화하는 지금, 개발 과정에서 느꼈던 불편함을 해결하기 위해 Storybook 도입을 결정하게 되었습니다.

 

이미 구축된 모킹 환경

코코무 프로젝트의 MVP 개발 당시, 백엔드 인원이 1명뿐이었습니다. 이에 따라 프론트엔드에서는 백엔드 API가 배포되기 전에 먼저 화면을 구현해야 했고, API 응답 없이도 화면이 동작하도록 개발 환경을 구성하는 것이 매우 중요했습니다.

 

이런 상황에서 저희는 프로젝트 초기부터 MSW(Mock Service Worker)를 도입했습니다.

 

MSW는 네트워크 요청을 가로채어 미리 정의한 응답을 반환해주는 라이브러리로, 실제 서버 없이도 프론트엔드에서 네트워크 연동 흐름을 자연스럽게 테스트할 수 있습니다. 덕분에 프론트엔드는 실제 API 없이도 각 컴포넌트의 로직과 UI를 자유롭게 개발할 수 있었고, 백엔드와의 작업 속도 차이를 효과적으로 해소할 수 있었습니다.

 

이렇게 구축한 모킹 기반 개발 환경은, 컴포넌트를 독립적으로 개발하고 상태를 나눠 시각적으로 확인해야 하는 Storybook과의 궁합이 매우 뛰어납니다. Storybook 내부에서도 MSW 핸들러를 그대로 사용할 수 있기 때문에, 실제 서비스 환경과 거의 동일한 조건에서 컴포넌트를 테스트하고 문서화할 수 있는 기반이 이미 갖춰져 있었던 셈입니다.

 

그래서 지금, 준비 중입니다

Storybook을 단순히 "보기 좋게 정리해주는 툴"이 아니라, 우리의 개발 생산성을 끌어올릴 핵심 도구로 바라보고 있습니다.

 

이미 갖춰진 MSW 기반의 모킹 환경에 Storybook을 연동하는 것부터 시작해, 각 컴포넌트마다 다양한 상태를 스토리로 정의하고, 추후에는 디자인 시스템 정리와 테스트 자동화까지 확장하는 것을 목표로 하고 있습니다.

 

Storybook 도입이 우리 팀의 컴포넌트 개발 방식을 어떻게 바꿔줄지, 앞으로의 변화가 기대됩니다.