본문 바로가기
FrontEnd/others

[ Storybook ] 왜 스토리북을 써야 할까?

by ウリ김영은 2024. 3. 8.

새로운 프로젝트를 시작하는데, 

스토리북 도입에 대해 고민해봤습니다.

 

당연히 사용하는 게 안 하는 것보다 좋지만, 

시간이라는 자원은 한정적이기에

스토리북을 통해 얻을 이점이 시간을 투자할만큼의 가치가 있는지를 따지게 됐습니다.

 

고뇌를 하던 중,

피그마를 통해 대략적인 디자인을 확인했을 때,

두둥, 탁!  

스토리북을 사용해야 한다.

라고 생각했습니다. 

 

혼자하는 작업에 도입을 하는 거면 이렇게 이야기는 끝났겠지만, 

당연히 아니겠죠? 

 

개발을 할 때 이미 컴포넌트로 나눠서 관리를 하는데, 

굳이 스토리북 까지 사용해야할까?

라고 생각할 수도 있습니다.

 

왜 스토리북을 쓰는 게 이로울까?

.

.

.

1. 디자이너와 개발자의 소통이 수월해지고, 시간도 절약할 수 있다. 

스토리북은 UI 컴포넌트를 독립적인 환경에서 그려볼 수 있는 툴 중 하나입니다. 

그래서

디자인이나 코드가 변경되어도 즉각적으로 확인하기에 좋습니다.

 

즉, 결과물을 쉽고 빠르게 확인할 수 있습니다.  

 

2. 컴포넌트의 재사용성이 좋다.  

컴포넌트를 분리하는 과정에서

SRP(Single Responsibility Principle)의 원칙을 지키려고 하는데,

* SRP란 단일 책임 원칙이라고 하는데, 하나의 객체는 하나의 책임만 가져야 한다는 것입니다.

 

덕분에 우리가 항상 강조하는

재사용과 유지보수 중, 재사용성이 좋다는 점입니다. 

 

왜 재사용성이 중요할까요?

 

첫째, 불필요한 작업을 줄여주고,

둘째, 안정적으로 검증된 코드를 사용할 수 있고, 

셋째, 캡슐화를 통해 테스트가 쉬워집니다. 

 

3. 디버깅 및 수정이 수월하다. 

로직이 UI 와 분리되어 있어서 

디버깅을 할 때 해당 부분을 빠르게 찾을 수 있습니다. 

그리고 UI와 무관하게 동작하기에 좀 더 코드 수정이 수월해집니다. 

 

3. 더 괜찮은 컴포넌트 설계를 고민하게 한다. 

컴포넌트를 작게 재사용성이 좋게 만들다보면, 

조금만 꼬여도 구조가 상당히 복잡해집니다. 

그렇기 때문에 더 신경써서 구조에 대해 생각할 수 있습니다. 

4. (SRP 덕분에) 테스트하기 좋다. 

 

이렇게 있습니다. 

 

끝!