당신2 9하던 Storybook

Sanghyup Jeong

Published in

29CM TEAM

8 min readSep 20, 2022

안녕하세요, 29CM 프론트엔드 개발자 정상협입니다.

29CM 기술블로그에 모바일이나 백엔드 관련 글은 꾸준히 올라오는 반면 프론트엔드는 고요한 바다처럼 아무런 소식이 없었는데요 🏖

저희 팀의 첫 글로는 여러 프론트엔드팀에서 이미 사용하고 있거나 도입을 고민하시는 Storybook 에 대해 간략히 소개드리고, 저희 팀에서 이를 어떻게 활용해 나가고 있는지, 그리고 Storybook 의 여러 장점들에 대해 소개드리고자 합니다.

📚 Storybook 이 무엇인가요?

Storybook 은 비즈니스 로직과 맥락으로부터 분리된 UI 컴포넌트를 만들 수 있도록 도와주는 툴입니다. 독립적으로 UI 컴포넌트가 어떻게 렌더링 되는지 시각적으로 테스트 할 수 있으며, 코드를 보지 않아도 컴포넌트가 어떻게 동작하는지 빠르게 확인해볼 수 있습니다.

🤔 Storybook 왜 도입했나요?

Storybook 을 이용한 컴포넌트 개발 방식을 도입한 것은 기존 Angular 기반 이었던 프론트엔드 환경을 React 로 변경하면서였습니다.

제가 작년에 입사했을 당시에는 전부 Angular 로 프론트엔드 환경이 구성되어있었고 React 코드는 한 줄도 찾아볼 수 없었습니다.

29CM 의 비즈니스가 커져가는 속도에 맞춰 저희 팀도 빠른 비즈니스 속도에 맞추어 더 많은 가치를 만들어 내야만 했었는데요, Angular 기반으로는 개발 생태계, 채용 등 여러 상황을 고려했을 때 어려움이 있었기에 긴 기간에 걸쳐 React 기반으로 프론트엔드 환경을 전환하게 되었습니다.

저는 React 개발 경험이 더 많았었기에 새로운 React 환경에서 개발을 한다는 것은 너무나도 즐거운 일이었습니다.

하지만 엘리자가 말했어요 세상은 생각하는대로 되지 않는다고

시간이 지날수록 현실은 우리 모두에게 피보나치 수열처럼 증가하는 어려움을 주었습니다.

👨‍👨‍👧‍👦 개발은 혼자서 하는게 아니다

한 사람이 모든 컴포넌트를 만드는 것이 아니라 여러 명이 동시에 작업을 하다 보니 아래와 같은 어려움이 있었습니다.

이미 만들어져있는 컴포넌트인지 몰라서 중복된 컴포넌트가 생성된다.
이미 있는 컴포넌트를 사용하려고 해도 어떻게 동작하는지 확인하는데 시간이 걸린다.
UI 테스트를 할 때 많은 시간이 걸린다.

29CM 프론트엔드팀은 컴포넌트 개발 방식을 개선해서 빠르게 개발하면서도 컴포넌트를 효율적이고 재사용성을 증가시키기 위해 Storybook 을 도입했습니다.

👨‍🎨 그래서 어떻게 사용하나요?

컴포넌트와 1:1 매칭

29CM 프론트엔드팀은 컴포넌트와 스토리를 1:1 매칭해서 스토리를 작성하고 있습니다. 작은 컴포넌트부터 페이지까지 전부 스토리로 저장합니다.

가벼운 스토리는 VSCode의 사용자 코드 조각의 기능을 이용해서 빠르게 스토리를 생성할 수 있도록 하였습니다.

데이터를 요청하는 컴포넌트

컴포넌트 내부에서 API 호출을 하고 있는 경우에는 MSW 를 이용해서 다양한 API 응답에 따른 렌더링을 확인하고 있습니다.

MSW 는 리소스 요청을 가로채서 수정할 수 있는 API 모킹 도구입니다.
Storybook 뿐만 아니라 Node.js 에서도 사용할 수 있어 활용 범위가 넓습니다.

이를 이용해 어떻게 다양한 응답을 확인할 수 있는지 확인해볼까요?

Storybook 에서 MSW 사용하기

먼저 msw 와 msw-storybook-addon 을 설치해야합니다.

$ yarn add -D msw msw-storybook-addon

그리고 .storybook/preview.js 파일에서 MSW 를 초기화하고 decorator 를 제공하여 Storybook 에서 MSW 를 활성화합니다.

이제 리소스 요청을 가로채볼까요?

아래의 코드는 상품 상세페이지에 이벤트 배너들을 렌더링하는 EventBannerSection 컴포넌트의 스토리입니다.

API 를 호출했을 때 만약 이벤트 배너가 없어도 MSW 로 응답을 가로채서 eventBannerMock 데이터를 내려주게됩니다.

반대로 이벤트 배너가 있어도 빈 값을 응답하고, 이벤트 배너가 없는 경우의 컴포넌트를 확인할 수 있습니다.

PR 내에서 컴포넌트를 Storybook 으로 확인하기

컴포넌트 개발을 끝내고 팀원들의 코드 리뷰를 받으러 PR 을 올릴 때 팀원들은 어떻게 남이 개발한 컴포넌트를 확인할 수 있을까요?

PR 에 스크린샷이나 영상을 첨부해서 컴포넌트를 확인할 수도 있지만 github actions 와 vercel 의 preview 기능을 이용해서 PR 별로 Storybook URL 을 생성할 수 있습니다.

PR 을 올리고 코멘트에 명령어를 입력하면 아래와 같이 github action 이
Storybook URL 을 생성해 코멘트를 달아줍니다!

Storybook 이 생성되니 리뷰어 입장에서 팀원이 작성한 코드를 UI와 함께 볼 수 있게 되니 코드의 동작 원리를 더 잘 알 수 있고 이는 좋은 리뷰를 만드는데 많은 도움이 됩니다.

PR 내의 Storybook 세팅 부분도 풀어볼 만한 좋은 주제인지라 기회가 된다면 별도의 글로 설명 드리겠습니다 :)

🎨 Storybook 의 장점

팀에서 Storybook 을 계속 도입해가다 보니 아래와 같은 장점들을 많이 느꼈습니다.

1. 자연스러운 컴포넌트 주도 개발 (CDD)

컴포넌트 주도 개발은 소프트웨어 엔지니어 Tom Coleman 이 컴포넌트 아키텍처 및 프로세스 UI 의 개발 변화를 설명하기 위해 소개한 개발 방법론인데요. 구성 요소를 중심으로 빌드 프로세스를 고정하는 개발 방법론입니다.

컴포넌트 수준에서 시작해 페이지나 화면 수준에서 끝나는 “bottom up” 방식으로 UI 를 구축하는 과정을 말합니다.

Storybook 과 함께 컴포넌트 개발을 하게 되면, 가장 기본적이고 독립적인 컴포넌트부터 개발을 하게 되기에 컴포넌트 주도 개발(CDD)이 자연스럽게 됩니다. 그와 함께 컴포넌트의 적용 범위가 확대되면서 재사용성 역시 증가하게 됩니다.

Storybook 과 함께 컴포넌트를 개발하게 되면 전체 페이지를 먼저 보면서 개발하기 보단 독립적인 UI 개발에 대한 집중이 강제되기 때문에 Props 설계에 대한 고민이 줄어드는 것을 많이 느꼈습니다.

이전에는 저도 모르게 Props 를 특정 페이지에 의존하도록 만든 경험이 종종 있었거든요 😅

2. 신규입사자 온보딩의 용이성

저희 팀은 신규입사자 분들이 오실 때마다 온보딩 프로세스를 진행하는데요, 일정 기간 온보딩을 진행한다 하더라도 코드베이스에 대해 문서만으로는 이해하기가 어려운게 사실입니다.

저희 서비스에 어떤 페이지가 존재하는지, 개발할 때 어떤 컴포넌트를 사용해야하는지 등 코드나 결과물을 직접 보면서 파악하기 전까진 알 수 있는 방법이 없었는데요, Storybook 은 API 명세서인 Swagger 처럼 컴포넌트의 명세서 개념으로 신규 입사자분들이 쉽고 빠르게 컴포넌트를 확인하고 테스트해볼 수 있었습니다.