React(리액트)는 Storybook(스토리북)을 적극 사용하자.

React는 컴포넌트를 기반으로 재사용성을 통해 빠른 개발과 유지 보수를 용이하게 하고 컴포넌트(기능이든 뷰 단위든)별 독립적인 테스트가 가능한 장점이 있다.

 

근데 가장 큰 문제는 신입 개발자가 프로젝트에 긴급히 투입되거나, 너무 오래 방치해있던 프로젝트에 큰 대규모 유지 보수를 진행해야 하는 경우 이 컴포넌트가 어떤 컴포넌트인지 잊어버릴 때가 있다.

 

이게 도대체 무슨 기능을 하는 컴포넌트?

 

컴포넌트가 명확한 기능만 하고 간소화된 프롭들만 제공한다면 큰 문제는 없겠지만 프롭이 많고 복잡하게 구성된 컴포넌트를 보고 있자니 일단 차근히 코드 분석부터 시작해야 한다. 

 

물론 개발 단계에서 미래를 생각하며 잘 구성된 컴포넌트는 이런 자원적 낭비가 없겠지만 현실적으로는 프로젝트 기간에 시달리며 작성한 코드들이 대단히 많을 것이다. 누구나 처음에는 잘 만들고 싶지만 복잡하거나 난감한 요구...에 따라 심하게 변동되는 경우도 있을 것이다.

 

테스트 페이지에다가 컴포넌트를 렌더링하여 어떤 기능을 하는 컴포넌트인지 확인하거나 이 코드를 작성한 개발자에게 물어봐야 되는 상황까지 오게 되는데 한시 개발하기 바쁜 프로젝트에 괜한 자원 낭비가 심하다. 그렇다고 새로 만들자니, 그거마저 번거롭고 시간 소모가 크다.

  

 

오열

 

 

빠르게 이 컴포넌트가 무엇을 하는 컴포넌트인지 알 수 없을까? 라는 니즈에 따라 Storybook이 여러분들의 눈물을 닦아준다.

 

 

우리에겐 스토리북이 있다.

 

협업을 하다보면 재사용 컴포넌트가 분명히 있을 것이고 개발자들끼리 그 컴포넌트를 재사용한다면 빠른 개발과 용이한 유지 보수가 가능하겠지만 현실적으로 남의 코드를 보고 해석하고 내 코드에 맞게 적용해야 하는 시간 소요가 있을 수 밖에 없다.

 

Storybook은 컴포넌트를 시각화하여 이 컴포넌트가 무엇을 하는 기능이 있고 어떤 렌더링을 거치는지 보여주는데 코드를 보며 분석하거나 직접 테스트 페이지에 렌더링하며 확인하는 불편한 과정을 거치지 않고도 빠른 분석이 가능하다!

 

단점은 아무래도 컴포넌트를 제작할 때 스토리북에 적용시키기 위해 조금의 시간을 투자해야 하는 점이 있지만 보다 완성도 있는 프로젝트를 위해 스토리북을 적극 도입했으면 좋겠단 생각을 한다. 개인적으로는 React의 끝판왕은 Storybook이 아닐까 싶을 정도로 컴포넌트 기반의 React의 극명한 단점을 아주 잘 보완해주고 있다.

 

Storybook!