크레딧잡 새로운 상태 관리를 위한 여정 (feat. Zustand)안녕하세요 원티드랩 채용사업부 크레딧잡팀에 프론트엔드 개발자 조건상입니다.원티드 프론트엔드팀에서 새로운 상태 관리 라이브러리를 선택하는 과정에 대해 공유합니다.크레딧잡의 역사과정을 공유하기 앞서 기술 선택에 이해를 돕기 위해 크레딧잡에 기존 상황과 히스토리에 간략하게 정리하고 들어가겠습니다.크레딧잡은 2018년 9월 원티드랩이 인수를 결정하고 2022년 1월까지 3년이 넘는 시간 동안 코드 관리를 하고 있지 않았습니다. 그렇기 때문에 크레딧잡은 2018년 구조에 머물러있었고 이는 원티드랩에 메인 기술 스택과 상이했으며 기술 히스토리가 남아있지 않아 빠르게 달려야 하는 크레딧잡이 인내하기에는 기술 부채가 크다고 생각했습니다.짧게 어떤 구조로 상태 관리가 일어나고 있는지 예시 이미지를 첨부하겠습니다.기존 프로젝트에 store 구조와 saga 코드코드 상의 약속된 보일러 플레이트가 존재하지 않습니다.하나의 saga 파일에서 대부분을 관리하다 보니 디버깅 혹은 코드를 수정해야 할 때 사이드이펙트 발생 확률이 굉장히 높은 점을 꼽았습니다. 자세한 문제점은 아래와 같습니다.(어떤 코드는 saga를 통해 api에 response를 관리하고, 어떤 코드는action, reducer만 사용하는 보기만 해도 어지러운 코드…)대부분의 API를 Redux와 Saga를 조합하여 구현되어 있다.이는 react-query를 통해 관리하게 된 설계에서 벗어나게됩니다.하나의 파일에서 여러 Saga가 작성되어 있고 그 코드는 700줄에 해당하는 많은 코드가 뒤섞여있는 문제가 있습니다.이는 분명 사이드이펙트를 유발할 가능성이 높으며, 코드 자체에 의존성이 강하게 결속되어 있기 때문에 수정 또한 쉽지 않습니다.local 상태로 관리할 수 있는 상태임에도 불구하고 대부분 Redux로 상태 관리가 되고 있는 문제위 문제점들을 근거로 저희는 Redux 구조를 현재 상태로 freeze 하고 앞으로 개발되는 기능에는 새로운 상태 관리 라이브러리를 도입해 사용하고 문제가 없다면 기존 구조도 마이그레이션하기로 결정했습니다.새로운 상태 관리 라이브러리가 갖춰야 할 조건러닝 커브가 낮아야 한다.새로운 라이브러리를 도입하는 만큼 현재팀 이외에도 다른 개발자가 투입되어 개발을 하더라도 Redux에 대한 이해가 있는 개발자라면 최대한 적은 학습비용으로 프로젝트에 투입될 수 있어야 한다.생태계가 이루어져 있어야 하며 이미 React 생태계에 자리 잡은 라이브러리여야만 한다.새로운 라이브러리를 도입했지만 관리가 안 되거나 추후 지원을 안 했을 경우 구조가 망가지거나 코드를 바꿔야 하는 가능성을 제외.그렇게 나온 Recoil vs Zustand다음과 같은 기준으로 두 라이브러리를 비교해 봤고, 저희 크레딧잡팀이 선택한 라이브러리는. “Zustand”였습니다.Zustand를 선택한 간략한 이유는 다음과 같습니다.2022년 10월을 기점으로 주 다운로드 수는 약 2.5배 이상 차이 나고 있다. (생태계 관점)Recoil은 Facebook