[React] 상태관리 라이브러리 비교하기 Redux vs Recoil vs Zustand

약 7주 간의 프로젝트를 진행하게 되면서 길지 않은 시간인 만큼 기술스택 선택에 많은 고민을 하게 되는 것 같다. 특히 상태 관리 라이브러리의 경우 Flux, Redux의 등장 이후 급격한 변화를 맞이했고 지금은 MobX, Recoil, Zustand, Jotai 등 너무나도 다양한 라이브러리들이 우리 앞을 기다리고 있다.

그래서 더 고민된다.. 도대체 상태 관리 라이브러리 뭘 써야되는거지..(결론 아직 안남 주의)

그럼 먼저 알고 있는 개념 먼저 생각해보자..

상태 관리 라이브러리 도입

상태 관리 라이브러리를 왜 사용하는가?

• 단순히 React Hook만을 사용해서 상태를 관리할 경우 props drilling, 컴포넌트 간 결합도 증가 등의 문제가 발생할 수 있고 이는 유지보수에 대한 어려움으로 직결된다.
• 또한 전역적인 상태가 없어 여러 컴포넌트 간의 상태를 효과적으로 공유하기 어렵고 여러 컴포넌트에서 동시에 사용하는 상태의 경우 일관성을 유지하거나 업데이트를 적용하는 것이 어렵고 복잡해진다.
• 또한 컴포넌트 재사용성에도 문제가 있다. 상태와 로직이 컴포넌트에 직접 구현되어 있다면 해당 컴포넌트를 다른 부분에서 쓰기 어려워진다.

그럼 상태관리 라이브러리를 사용하면 이 모든 것이 해결되나?

• 컴포넌트간 통신이 간소화된다. props drilling 같은 문제를 중앙화된 스토어를 통해 관리해 컴포넌트 간의 통신을 간소화하고 데이터 전달을 쉽게 한다.
• 이로 인해 비동기 작업 관리 또한 쉬워진다. 서버와의 통신 등을 효과적으로 다룰 수 있다.
• 컴포넌트와 상태/로직을 분리해 컴포넌트를 간소화하고 재사용성을 높일 수 있다.
• 라이브러리 개발자 도구를 통해 더 나은 디버깅 환경을 조성할 수 있다.

→ 이렇게 좋은 개선점을 가진 상태관리 라이브러리 안 쓸 이유가 없다!

그럼 이제 다시 처음의 질문으로 돌아간다.

상태관리 라이브러리 비교

그래서 상태관리 라이브러리 뭐 쓸건데..

방금 캡쳐한 따끈따끈한 npm trends 그래프다.(2024.01.06…)

다른 라이브러리들과 큰 차이를 보이는 Redux와 그 아래로 2023년 급격한 상승을 보이는 Zustand가 눈에 띈다. 그 아래는 비슷해 보이는 느낌..

일단은 이번 글에서는 비교해볼 대상으로 Redux, Recoil, Zustand를 꼽아봤다. 각각의 라이브러리가 갖는 확실한 이점과 단점이 있음..

Redux

전통의 강자 Redux.. 셋 중 가장 난이도 있는 라이브러리..라고 느껴진다. 초기에는 개념을 잡는 것도 복잡하다고 느낄 정도인데 보일러 플레이트, 액션 함수, 액션 생성 함수, 리듀서, 스토어… Redux의 가장 큰 단점이 진입 장벽이라고 생각될 정도.. 이 때문에 하나의 state를 관리하더라도 파생되는 함수가 많아질 수 있다.

하지만 이를 보완할 장점도 많다. 일단 npm trends의 저 위풍당당한 download 수를 보라.. 지금은 그 성장세가 꺾였지만, 여전히 Redux의 개발자 커뮤니티는 건재하고, Redux를 보조하는 라이브러리도 다른 상태관리 라이브러리에 비해 정말 다양하다! redux toolkit과 같은 개발을 쉽게 해주는 도구도 존재한다는 것이 큰 장점이라고 생각된다.

기술적인 부분에서도 장단점이 뚜렷하다고 볼 수 있는데,

먼저 장점으로는 크고 복잡한 앱에서의 확장성이 높고 액션에 따른 모든 변경을 추적할 수 있다. 앱에서 사용하는 상태의 양이 복잡하고 많으면서 안정성을 지키는 것이 중요한 경우 Redux를 사용하는 것이 큰 도움이 될 수 있다.

하지만 단점 또한 존재한다. 일단 코드 작성량이 늘어나면서 빠르게 진행되어야 하는 프로젝트에서는 걸림돌이 될 수 있다는 생각이 많이 들었다. 그리고 Redux는 만능이 아니다. 라이브러리가 많으면 뭘 하는가 바빠서 못쓰면 무용지물인 것을… 또한 Flux 구조에서 단방향 데이터 흐름에서 특정 액션의 발생으로 전체 어플리케이션의 상태를 업데이트 할 수 있는데, 이로 인해 불필요한 렌더링이 발생하는 등의 성능 변화가 생겨버릴 수도 있다.

Redux 요약: 어렵지만 강력한 커뮤니티로 극복해볼 수 있을지도? 근데 그걸 쓸 시간이 있나?

Recoil

사실 깊게 생각해보기 전에는 Recoil을 1순위로 생각했지만 알아보면 알아볼 수록 미래가…

일단 가장 큰 특징은 atom이라는 단위로 state 관리를 분리하기 때문에 앞서 말한 Flux 구조의 단점 중 한 가지를 해결할 수 있다. 또한 Recoil은 React 친화적 구조를 가지고 있어 React Hook과 비슷한 개념을 통해서 Store에 접근하고 상태를 관리할 수 있게 된다. 쉽게 배우고 쉽게 쓴다는 것이 가장 큰 장점!

하지만 단점이 좀 크다. Recoil의 깃허브에는 해결하지 못한 이슈가 240여개가 쌓여있고 Pull Request는 60여개가 쌓여있다. 코드..관리 안해..?

현재 버전 또한 0.7.7로 아직 stable한 버전이 없다는 것도 단점이다. 많은 IT회사들이 Recoil 초기에 React에서도 긍정적인 모습을 보이는 모습을 보고 Recoil을 도입하고자 했지만 지금은 메모리 누수 이슈나 메인 관리 개발자의 퇴직, 느린 업데이트를 이유로 그 열기가 많이 줄어든 것으로 보인다. 일찍이 도입한 네이버도 이제 조용함.. 추가로 Hook 관리에 대한 복잡성 얘기도 있었는데 길어지니까 생략..

또한 React의 동시성을 지원한다는 특징도 있었는데 React 18에서도 이를 아직 보완하고 있는 중이라 큰 장점이 되지 못하는 거 같다..

Recoil 요약: 좋아보였는데 너무 아쉽다..

Zustand

원래 Redux vs Recoil 둘을 비교하고 있었는데 갑자기 Zustand가 눈에 들어왔다. Redux의 Flux 구조를 사용하면서도 Redux처럼 복잡하지 않아..? Recoil에서의 Hook 관리도 Store 선언에서 할 수 있어..?

Zustand는 출시 이후 빠른 성장세를 보이고 있는 상태관리 라이브러리로 완만한 러닝커브로 도입을 쉽게 만들어준다..! 또한 Redux에서의 강제성에서 벗어나 아키텍처나 패턴을 강제하지 않는 매우 유연한 라이브러리라고 볼 수 있다. 또한 리렌더링과 관련해서 useStore 훅을 통해 상태 업데이트가 리렌더링에 관여하지 않도록 만들수도 있다.

너무 칭찬만 했나..

이런 Zustand도 아직 개발 초기라고 볼 수 있는데 그 때문에 생기는 문제점들도 있다. 일단 Redux보다 보조 라이브러리나 미들웨어가 부족하기 때문에 이를 보조할 수 있는 다른 수단이 필요하다. 그래서 보통 React query에 서버 상태 관리를 맡기는 듯 하다. 또한 DevTool이 제한적인데 자체 개발툴은 없고 보니까 Redux Dev Tools를 쓸 수 있도록 하는 확장자가 있는 거 같긴 했다.

Zustand 요약: 지금 봤을 때는 이유 있는 성장세? React-query까지 도입해볼 수 있다면 나쁘지 않을지도

---

결론

은 아직 안냈는데 마음이 Zustand 쪽으로 기운 거 같다.. 주말동안 한번 테스트 해보고 2탄 써야지