Storybook의 필요성 설명

nyongho·2022년 3월 7일
1

📌 Styled Component + Storybook 도입 과정

  1. 사내 서비스는 현재까지 어느정도 antd 라이브러리에 의존하고 있음. (antd를 사용하는 것이 나쁜 것이 아님, 초기 애자일하게 개발할 때는 오히려 이득인 측면이 강함)

애자일 방법론 이란, ‘Agile = 기민한, 날렵한’ 이란 뜻으로 좋은 것을 빠르게 취하고, 낭비 없게 만드는 다양한 방법론을 통칭해 일컫는 말이다. 앞을 예측하며 개발하지 않고, 일정한 주기를 가지고 계속 검토해 나가며 필요할 때마다 요구사항을 더하고 수정하여 커다랗게 살을 붙이면서 개발해 프로세스 모델 방식이다. 미리 정해진 몇 개의 단계에 따라 엄격한 순서대로 이루어지는 일직선의 과정인 폭포수의 프로세스와는 비교가 많이되는 반대의 개념이다.

  1. 하지만 현재 어느정도 핵심적인 기능은 나온 상태이고 추후 서비스 볼륨이 커질 경우 지속적으로 외부적인 라이브러리에 의존할 수는 없으니 사내 개발팀만의 독립적인 라이브러리를 개발하고 싶다는 이사님의 의견

  2. 이전에는 프로젝트 React 버전이 16버전 (구 버전)이라 Styled Component 설치 자체가 불가했는데 버전업 함으로써 가능하게 돼 이를 도와줄 수 있는 CSS Framework로 Styled Component를 검토 후 도입함.

  3. Styled Component를 도입한 김에 독립적인 UI 컴포넌트를 개발하는데 도움이 되는 Storybook 개발 도구 도입 검토

  4. Styled Component + Storybook 도입


🔎 Storybook 이란?

Storybook은 컴포넌트 단위의 UI 개발 환경을 지원하는 도구입니다.
Storybook을 사용하면 실제 웹 어플리케이션의 환경과 별개로 컴포넌트 단위의 UI 개발 진행이 가능합니다.
그 외에도 컴포넌트의 문서화 도구로도 사용이 가능합니다.


🤔 Storybook을 쓰면 뭐가 좋은거죠?

1. 개발자 측면

  1. 컴포넌트 단위의 UI 개발 환경을 독립적으로 지원하기 때문에 굳이 로컬 서버를 띄워놓고 컴포넌트 안에 집어넣어 직접 새로고침 해가며 테스트하지 않아도 됨.

2. 협업 측면

💢 기존 프로세스 : 공통 컴포넌트 개발 => 로컬 서버에 적용 => 디자인 시안과 비교해 개발자 스스로 1차적인 검수 => 디자이너 혹은 기획자에게 2차적인 검수 요청

  1. 디자이너가 직접 개발자 자리에 와서 확인
  2. 개발자가 보내주는 스크린샷으로 확인
  3. 개발 서버에 배포된 것으로 확인

이를 기획자, 디자이너 두 사람이 같은 절차를 밟음. => 수정사항 발생 시 위 절차 반복 =>

개발자 및 디자이너 둘 다 피로도 증가 🤦‍♂️

적용 프로세스: 공통 컴포넌트 개발 => 로컬 서버 적용 => 해당 컴포넌트 스토리북에 적용 후 배포 => 디자이너 및 기획자 배포된 서버에서 직접 컴포넌트를 만져보며 확인 => 수정사항 발생 시 스토리북 내에서 이슈 등록 및 슬랙 메세지 =>

시간적인 비용 감소 및 커뮤니케이션 관련 피로도 감소 🙆‍♂️

그래서 Storybook은 필요한 것인가요?

현 상황에서는 Storybook을 사용하는 것이 큰 기대효과를 불러 일으킬 것으로는 어렵다고 봄.

현재는 인원 편성이 작은 상황이고 자리 배치 또한 디자이너와 개발자가 가깝게 배치 됐기 때문에 즉각적인 피드백이 가능하지만, 나중에 인원과 서비스의 볼륨이 커지게 되면 이러한 종류의 협업에 대한 고민과 피로도는 지속적으로 쌓이게 될 수 밖에 없음.

결국 Storybook을 도입한 것은 단기적인 측면보다는 장기적인 측면에서 현재의 단계에서 서비스 내재화를 통해 이후의 비용적인 측면을 아끼기 위한 것임.

Storybook을 어디까지 적용할 것인가요?

이 문제도 꽤 많은 고민을 했고 이에 대한 답은 의외로 간단했다. "가장 많이 재반복되는 컴포넌트"에만 적용하면 된다.

재반복되는 컴포넌트는 오히려 디자인이나 기획의 면에서 다른 컴포넌트보다 더 견고 해야겠다는 생각이 들었고 이런 컴포넌트를 쉽게 관리할 수 있게 하는 것이 Storybook의 장점.

이에 대한 프로세스는 기획 => 디자인 => 개발순이 맞는 단계이지만 현 단계에서는 이사님의 피드백 => 공통 컴포넌트 개발 => 이후 디자인 수정 순으로 이뤄질 것이기 때문에 일단 내 입장에서는 조금 피곤한 상황.

profile
두 줄 소개

0개의 댓글