안녕하세요. 점핏팀의 FE파트에서 일하고 있는 신입 개발자 조던입니다.
저는 최근 어느 한 고민에 빠지게 되었는데요.
그 고민을 한 계기와 어떻게 고민을 해결할지의 내용을 이번 포스팅에 담게 되었습니다. 부족하지만 잘 부탁드려요!
우선 점핏에서 제공하고 있는 서비스를 소개해 드릴게요.
1. 개발자들께 양질의 포지션을 제공하고 구직,이직 서비스를 제공하는 점핏.
2. 기업이 원하는 핏한 인재를 확인하고 채용할 수 있는 구인서비스를 제공하는 기업전용 점핏.
3. 마지막으로 저희 팀 내에서 사용되는 관리자로 이루어져 있는데요. (이건 모르셔도 됩니다!)
갑자기 무슨 서비스 이야기냐구요? 제 고민과 관련이 있습니다.
# 😨 구성요소가 많아질수록 관리가 힘들어!
점핏의 서비스의 기능들을 개선, 추가해나가면서 프로젝트의 규모 커지고 구성요소가 점차 많아졌습니다.
구성요소가 많아지면 많아질수록 관리가 힘들어 이러한 문제가 생겼습니다.
1. 기존 만들어져있는 구성요소를 이용, 확장하지 않고 새로 만든다던지.
2. 기능이 추가되어 해당 구성요소의 수정이 필요하다면 일관성을 가지지 못하고 다른곳에 사용되었을때 사이드 이펙트가 생길 우려가 있다던지,
3. FE파트의 구성요소와 디자인파트의 디자인 모듈과의 UI 차이가 조금씩 생긴다던지…
저는 결과적으로 Storybook 도입을 고려하게 되었고 문제를 해결해나가는 과정을 겪게 되었습니다.
제가 앞서 점핏의 서비스를 소개했었죠? 그 중 개인 서비스는 Storybook을 사용하기 가장 적절한 Atomic Design 패턴을 사용하고 있습니다. 실제 적용하게 된다면 개인 서비스에 우선 적용해보면 되겠네요!
Storybook이 Atomic Design 패턴과 찰떡인 이유는 다음과 같습니다.
Storybook은 UI 구성 요소와 페이지를 분리하여 구축 가능한 오픈 소스 UI 개발, 테스팅, 문서화 툴인데요. Atomic Design 패턴 역시 페이지로부터 UI 구성 요소을 독립,분리시키고, 구성요소의 목적에 맞게 atoms, molcules, organisms로 분류하여 개발, 설계하는 패턴이거든요.
# 😁 Atomic Design 패턴에 Storybook을 적용해보자!
React + Storybook 보일러플레이트를 작성하고 실행시켜 보았습니다.
각 구성요소의 차례대로 atoms, molcules, organisms로 카테고리화 되어있고 독립적인 해당 요소 역시 확인할 수있습니다. 또한 Storybook 내부에서 독립적으로 개발, 테스트를 할 수도 있구요. 멋지지 않나요?
그러면 코드로 살펴볼까요?
폴더 구조는 다음과 같습니다 Atomic Design 패턴이고 atoms/Button 폴더에 실제 구성요소와 그 구성요소에 매칭되는 스토리 파일이 존재합니다.
Button.stories 파일을 열어보면 다음과 같이 되어있습니다.
생각보다 간단하죠? 또한 이렇게 작성한 요소들를 조립하여 만들어지는 molcules와 organism역시 작성방법은 마찬가지입니다.
스토리 파일만 작성해준다면 자동으로 문서화 해주기 때문에 FE파트나 디자인파트내에서도 원활한 협업이 가능할것 같네요.
다음으로 아까 Button 요소 폴더에 테스트 파일을 추가해볼까요?
이런식으로 요소에 해당하는 테스트 파일에 TC 코드를 작성해놓고 실행시켜 결과를 확인하는 ‘테스트 자동화 ’ 역시 Storybook은 제공하고 있습니다.
Atomic Design 패턴을 유지하며 단위 개발, 문서화, 테스트를 손쉽게 제공하니 잘만 사용하면 정말 편리한 도구겠네요!
하지만 그런 Storybook도 만능은 아닙니다.
제가 Storybook를 적용해보며 느꼈던 우려사항을 이제부터 말씀드리려고 합니다.
# 🤔 도입 시의 고려사항
1. 개발 일정에 스토리를 작성해야 할 시간을 포함시킨다면 그만큼 개발일정이 늘어납니다.
그렇다고 해서 스토리 파일 작성에 적절한 시간과 노력을 투자하지 않는다면, 안쓰느니만 못할거예요.
(입사해서 인수인계 WIKI를 열어봤는데 마지막 수정이 1년전이라면…? 이런느낌일것 같네요.)
2. Thirdy Party 라이브러리와 Storybook의 호환문제가 있습니다.
사실 위 설명엔 없지만 Storybook을 실행시키고 확장하려면 몇가지 수정이 필요합니다.
React-Router-Dom이라던지 Styled-Components 라던지 React-Query라던지 Redux라던지 이런 프로바이더를 제공하는 라이브러리를 사용하신다면 설정파일에 데코레이팅 작업이 필요해요. 개발단에 적용하고 있는 Thirdy Party 기능들을 스토리북에 적용하여 같은 환경을 만들기 위해서죠.
여기까진 공수의 범위지만 React-Hook-Form을 스토리북 환경에 세팅할때가 문제였습니다.
useFormContext라는 RHF에서 제공하는 Hook은 부모 FormProvider를 가지고 있어야 사용가능한데, 서로 독립된 atom 스토리끼리의 집합인 molcules나 organism 등에서 FormProvider를 가지고 있지 않아 Storybook을 실행시킬때 useFormContext를 호출하는 곳에서 참조에러가 발생했던 것이죠…
위처럼 withRHF란 스토리 작성만을 위한 코드를 직접 짜줘야만 했습니다…
해당 요소의 스토리 파일 데코레이팅 배열에 withRHF로 매핑하여 추가하였구요.
이처럼 라이브러리 특성과 Storybook이 맞지 않는다면 withRHF와 같이 추가 공수를 들여 맞춰줘야 하고, 최악의 경우 버전,호환 문제가 생기면 해당 기능을 사용하는 요소의 스토리를 사용할 수 없게 되어버립니다.
# 마치며
처음엔 Storybook을 도입하려고 공부했었지만 파고들수록 의문점이 생겼습니다. 또한
무작적 적용보단 현재 점핏팀의 업무방식과 개발환경, 협업구조 등을 파악하고 파트내에서 잘 사용할 수 있을지에 대한 의논을 해봐야겠다는 생각 역시 들었구요.
기존 문제를 개선하고 편하게 일하려고 도입한 도구가 우리에게 더 불편함을 가져다준다면 큰일이겠죠?
여기까지 FE팀 조던의 Storybook 탐방기였습니다. 부족한 글 끝까지 읽어주셔서 감사합니다.
만약 이 글을 읽고 FE 직군에 흥미를 가지셨다면 저희 점핏에서 이력서를 등록하고 FE 개발자로 입사지원을 해보시는 건 어떨까요?
감사합니다!
