스토리북을 적용하는 과정에서 느낀 점을 간략히 정리했습니다.
storybook 도입 이유
여느 서비스가 그렇듯, 코드는 쪼개지기 마련이며 재활용을 위한 공통 컴포넌트가 생기기 마련이다.
하지만 이제 3달을 겨우 넘긴 신입 사원의 입장에서,
그렇게 구성된 어떠한 코드나 컴포넌트가 어디서 온 건지 별도의 문서 없이 빠르게 파악하는 데에는 다소 어려움이 있었다.
컴포넌트 뿐 아니라 색상의 경우도,
어딘가에선 색상을 정의한 이름으로, 어딘가에선 hex코드로 나타나있는 경우가 종종 있어서 검색창 켜고 샵어쩌구저쩌구 검색해서 아 이거군! 하고 적용했던 적도 한두번이 아니었다.
그런데 스토리북을 사용하면 디자인 시스템을 정리할 수 있단다!
안 할 이유가 없어 보였다.
도입 과정
도입하기 전 망설여졌던 포인트는 크게 두개였다.
- 작은 팀에도 적합한가?
- 자유도가 높은 컴포넌트에도 적합한가?
1. 작은 팀에도 적합한가?
현재 개발과 디자인팀의 규모가 크지 않기 때문에, “소통을 원활히 할 수 있음”의 이점을 크게 가져갈 수 없진 않을까 걱정이 되었다.
나를 제외한 팀원들은 이미 이 서비스를 너무 잘 알고 있고, 컴포넌트의 구조나 색상 등에 대해 잘 알고 있다.
그러니 사실 도움이 필요한 사람은 신입 사원인 나 혼자 뿐 인 거다.
하지만 일단 언제 새로운 사람이 들어올지 모르고
(미래의 나 같은 사람을 위해)
플러스로 다행히 이 작업을 할 수 있는 시간이 어느 정도 확보가 되어서
못 먹어도 고! 심정으로 일단 적용해보기 시작했다.
2. 자유도가 높은 컴포넌트에도 적합한가?
현재 서비스에서 가장 작게 쪼개어진 컴포넌트 단위는 base 폴더에 위치하고 있다.
이 base들에는 몇가지 특징이 있는데, 그 중 가장 큰 특징을 꼽아보자면
자유도가 매우 높다는 것이다.
따라서 인자를 하나도 넘겨주지 않았을 때의 defult 값이 위의 이미지처럼 텅 비어있는 상황이 발생하기도 한다.
사실상 UI 컴포넌트의 역할보다는 하나의 html 태그 역할을 한다고 하는 게 더 맞는 표현일 것 같다.
가장 기본이 되는 버튼의 크기는 패딩이 몇 정도에, 폰트는 어떤 사이즈가 들어가고, 이런 게 코드로 정의되어 있지 않은 상황이라
임의로 가장 많이 썼던 것 같은 (추정에 의한..) 코드를 바탕으로 스토리를 만들어야 했다.
그러면 디자이너랑 얘기해서 기본 디자인을 정의하면 되지 않나요!?
물론 할 계획은 있겠으나 타 업무 대비 업무의 우선순위가 매우 낮다.
(눈물...)
그럼 결국 다시 처음 가졌던 의문으로 돌아가,
자유도가 높은 컴포넌트에 적합하냐 라고 물어본다면
"그래도 아예 쓸모 없는 건 아닌 것 같다." 정도로 답할 수 있겠다.
예를 들어 Button을 하나 만들 때, 다른 코드에서는 어떻게 만들었는지 몇가지를 참고해서 만들고는 했는데
이러려면 코드 + 해당 코드가 구현된 페이지까지 가는 여정을 거쳐야 했다.
하지만 스토리북을 적용해보면서
동시에 @storybook/addon-storysource이라는 addon을 설치해 해당 스토리에 대한 소스코드를 확인할 수 있게 했다.
어떤 인자를 전했을 때 어떤 UI가 나오는지 한눈에 확인할 수 있게 되어서,
내가 겪었던 불편함의 단계를 확 줄여주는 역할을 해줬다.
결론
스토리북 무조건 좋나요?
아니오.
- 모든 상황에 좋은 라이브러리나, 툴 같은 게 있다는 게 말이 안 되기도 한다.
- 실상 스토리북 만들도 제대로 써보지 않은 단계라 벌써 판단하기엔 이르다.
그럼에도 불구하고 이럴 때 좋겠다 싶은 건 대충 이렇다.
애초에 어느 정도 디자인 시스템이 잡혀 있었거나,
아예 처음 프로젝트를 시작하는 상황이라거나,
그것도 아니면 쫙 정비할 마음을 먹었거나
셋 중 하나 정도에 해당했을 때 스토리북의 이점을 최대한으로 가져갈 수 있을 것 같다.
그래서 "진짜 결론"이 뭐냐?
무엇보다 스토리북을 배워봤고 적용해봤고 이런 생각이 들더라!하는 자체가 나에겐 남았다는 것이 현 시점의 결론이 되겠다.
