Storybook 도입기

프로젝트에서 스토리북 도입기

마지막 프로젝트에서 결국 공통 UI컴포넌트를 위해 storybook을 사용하였습니다.
Storybook은 컴포넌트를 애플리케이션과 분리하여 독립적으로 개발할 수 있도록 도와주고, 프로젝트를 실행하지 않아도 Storybook 내에서 컴포넌트 상태를 다양한 시나리오로 테스트 가능한 UI전용 도구입니다.

처음에 러닝커브에도 불구하고 마지막 프로젝트에 storybook을 도입하며 저는 컴포넌트의 공용화의 시점을 어디로 해야 하는지와, 도입 배경, 장점에 대해 서술하였습니다.

도입 배경

1. 복잡한 UI 컴포넌트 구조
   SnapRoad의 주요 기능은 다음과 같이 복잡한 UI 컴포넌트를 필요로 했습니다.

• 이미지 업로드 및 다양한 필요에 의한 사용처
• 여러 상태를 가진 이미지 슬라이더
• 지도와 연동된 주소 검색 필드
• 다양한 입력 폼과 상태 처리(해시태그, 날짜 선택 등)

각 컴포넌트는 다양한 상태(로딩, 에러, 성공 등)를 처리해야 했고, 이러한 상태를 일일이 구현하고 확인하기 어려웠습니다. 따라서 UI를 독립적으로 개발 및 테스트할 수 있는 환경이 필요했습니다.

2. 생산성 문제
   컴포넌트를 개발할 때마다 앱을 실행하고 특정 페이지까지 이동해야 하는 번거로움이 있었습니다. 이를 해결하기 위해 스토리북을 통해 컴포넌트를 격리된 환경에서 개발하고 테스트할 필요성을 느꼈습니다.

3. 유지보수 및 협업
   컴포넌트가 많아지면서 재사용성과 문서화가 중요해졌습니다. 컴포넌트는 프로젝트 전체에서 자주 재사용되기 때문에, 각 컴포넌트의 상태를 시각적으로 확인하고 명확히 문서화하는 작업이 필수적이었습니다.

도입 과정

1. 스토리북 설치 및 설정
   먼저 Next.js 프로젝트에 스토리북을 설치했습니다.

npx storybook init

스토리북 초기 설정 과정에서 TypeScript와 Tailwind CSS 환경을 통합하여 해당 프로젝트의 스타일을 그대로 적용했습니다. 추가적으로 Next.js의 Image 컴포넌트를 처리하기 위해 storybook-addon-next를 설정했습니다.

2. 주요 컴포넌트 작성
   스토리북 도입 초기에는 가장 자주 사용하는 공통 컴포넌트부터 스토리를 작성하기 시작했습니다:

• 버튼(Button)
• 입력 필드(Input)
• 바텀 시트(BottomSheet)
• 공통 모달(CommonModal)
• 로딩 컴포넌트(Spinner)
• 탭(Tab)

컴포넌트별로 다양한 상태를 시뮬레이션:

버튼의 disabled, loading, full 상태
입력 필드의 에러 메시지, 기본값 상태
공통 모달과 바텀시트의 상태 관리, 및 기본 컬러 차트

3. 문서화 및 상태 관리
   스토리북을 단순히 UI 테스트뿐만 아니라 문서화 도구로 활용하기 위해 Controls를 사용하여 Props를 동적으로 조작할 수 있도록 설정했습니다.

안티패턴인 SVG in js를 활용한 공통 컴포넌트의 활용, 필요한 클래스를 직접 작성 할 수 있는

shadCn의 tweenMerge이용으로 컴포넌트를 다양한 스타일로 확장 시키게 사용하기 위해 노력하였습니다.

도입 후 변화

1. 컴포넌트 독립성 강화
   스토리북을 통해 컴포넌트를 페이지와 분리하여 개발했기 때문에, 컴포넌트 하나만으로도 모든 동작을 확인할 수 있었습니다. 특히, 상태 관리(store) 의존성을 제거하여 컴포넌트를 더욱 독립적으로 만들 수 있었습니다.

2. 디버깅 속도 향상
   스토리북을 통해 각 컴포넌트를 빠르게 테스트하고, 문제를 해결할 수 있었습니다.

예를 들어:
주소 입력 필드의 에러 메시지 렌더링 문제 해결
버튼의 상태 관리, 및 공통 컴포넌트를 활용환 프로젝트 획일화

3. 문서화로 협업 효율성 향상
   스토리북이 컴포넌트 사용법과 Props를 명확히 보여줬기 때문에, 프로젝트를 확장하거나 유지보수할 때 기억에 의존하지 않고 빠르게 이해할 수 있었습니다. 가이드 파일을 적용하여 팀원에게 스토리북에 있는 컴포넌트 사용법을 제공 하였고, 팀원들도 함께 사용하며 개선 할 점들을 서로 피드백 받아 함께 제작하였습니다.

4. 디자인 시스템 구축 가능성
   버튼, 입력 필드, 모달 등 공통 컴포넌트를 스토리북으로 관리하면서, 디자인 시스템 구축 가능성을 염두에 두게 되었습니다.

한계점 및 개선점

1. 초기 설정 시간
   스토리북을 Next.js와 통합하고 프로젝트 스타일에 맞추는 데 시간이 소요되었습니다. 특히 Tailwind CSS와 Next.js의 여러 컴포넌트를 처리하는 과정이 까다로웠습니다.
   특히 윈도우와 맥북의 시스템 설정이 다른 부분이 있어 이를 처리하며 꽤 많은 초기 시간이 소요되었습니다.

2. 페이지 기반 테스트 한계
   스토리북은 컴포넌트 단위 테스트에 적합하지만, 페이지 단위의 상호작용 테스트에는 Cypress(현대 웹 애플리케이션을 테스트하기 위한 엔드투엔드 테스트(E2E) 프레임워크)와 같은 도구가 더 적합했습니다.

스토리북의 장점

1. 컴포넌트 중심 개발
   스토리북은 컴포넌트를 독립적으로 개발하고 테스트할 수 있는 환경을 제공합니다. 이는 특히 컴포넌트 기반 구조를 사용하는 Next.js와 같은 프레임워크에서 유용합니다. 프로젝트에서는 컴포넌트가 복잡하고 재사용 가능한 경우가 많기 때문에, 각각의 컴포넌트를 독립적으로 개발하고 테스트하기에 적합합니다.

2. UI 테스트 및 검증
   SnapRoad처럼 UI 중심의 프로젝트에서는 디자인과 기능이 사용자의 경험에 큰 영향을 미칩니다. 스토리북을 통해 컴포넌트의 상태(예: 로딩, 성공, 오류)를 시각적으로 검토하고, 버그를 조기에 발견할 수 있습니다.

3. 협업 향상
   공통 프로젝트이기 때문에, 협업을 염두에 두면서, 디자이너나 팀원들에게 컴포넌트 상태를 스토리북으로 공유하여 피드백을 받을 수 있습니다. 스토리북은 문서 역할도 하기 때문에 컴포넌트의 사용법과 디자인 의도를 명확히 전달할 수 있습니다.

4. 디자인 시스템 구축
   프로젝트에서 사용하는 버튼, 폼, 모달 등과 같은 공통 UI 컴포넌트를 스토리북에 추가하면 디자인 시스템을 구축하는 데 도움을 줍니다. 마지막 프로젝트에서도 버튼, 이미지 슬라이더, 업로드 모달 등을 관리하고 테스트하기에 스토리북이 적합합니다.

5. 컴포넌트 테스트 자동화
   스토리북은 Visual Regression Testing(시각적 회귀 테스트) 도구와 함께 사용될 수 있습니다. 이는 UI 변경 사항이 의도치 않게 영향을 미치지 않도록 방지합니다.

6. 생산성 향상
   스토리북 환경에서 독립적으로 컴포넌트를 개발하면 개발 환경에서 직접 코드를 실행하지 않아도 됩니다. 마지막 프로젝트 처럼 복잡한 폼과 이미지 업로드 기능을 개발할 때, 각각의 상태를 바로 확인할 수 있어 시간과 노력을 줄일 수 있습니다.

향후 계획

프로젝트에서 스토리북을 활용하여 더 나은 UI 개발 환경을 만들기 위해,

Visual Regression Testing 도입 예정 (UI 변경 시 자동 확인)
디자인 시스템 구축으로 컴포넌트 재사용성 극대화
더 복잡한 폼과 상태 관리 컴포넌트의 시뮬레이션 강화