본문 바로가기
Frontend/React & Next.js

전역 상태 관리 라이브러리들(Redux, Recoil, jotai, zustand...)

by 이의찬 2023. 9. 13.

작년에 멋쟁이 사자처럼을 하면서 Front에 입문했는데, 그 때 나를 가장 고통에 빠트린게 바로 Redux였다. html, css와 함께 즐겁게 배우다가 Js와 React를 거치면서 점점 어려워지더니 Redux라는 '전역 상태 관리 라이브러리'의 등장은 정말...

전역? 상태? 관리? 라이브러리??

물론 꽤 예전 이야기라, 새싹톤과 StarGate에서는 각각 Redux와 Recoil을 사용했고, 이번 프로젝트에서는 Jotai를 사용하고 있다. 이렇게 여러가지 라이브러리를 사용하면서 각자의 장단점에 대해서 알게 되었고 이에 대해서 글을 적어보려고 한다.

 

우선 Flux 패턴의 대표주자인 Redux와 Atomic 상태 관리의 대표 Recoil을 비교해보고(Proxy의 대표주자인 Mobx는 안써봐서 다음 기회에...), Redux에서 영감을 받은 Zustand와 Recoil에서 영감을 받은 Jotai가 어떤 강점을 가지고 있는지에 대해서 순서대로 써보려 한다.

Redux와 Recoil 비교

Redux

Redux

특징

  • Redux는 Flux패턴에 알맞게 단방향으로 state를 변경하는 라이브러리
  • 앱의 전체 상태를 하나의 중앙 집중식 저장소(store)에서 관리
  • Action 객체는 Dispatch메서드에 전달되고, Dispatch는 Reducer를 호출해서 새로운 state를 생성
  • Reducer는 순수 함수이기 때문에 동일한 입력에 항상 동일한 출력을 반환
더보기

Flux 패턴이란? 

 

사용자 입력을 기반으로 Action을 만들고, Action을 Dispatcher에 전달하여 Store(Model)의 데이터를 변경한 뒤 View에 반영하는 단방향의 흐름

장점

  • 일관된 Flux 패턴과 아키텍처
  • 전역 상태 수정을 위해서는 action 선언과 수행이 필수기에 데이터의 흐름을 좀 더 쉽게 예측 가능
  • 직관적으로 전역 상태들을 볼 수 있는 Redux Devtools이라는 개발자 도구 존재 
  • 가장 많은 사용자를 보유하고 있기에 커뮤니티가 활성화 되어있고 트러블 슈팅에도 유리

npm trends에서 볼 수 있는 4가지 라이브러리, redux가 압도적이다.

단점

  • 이 글에 소개된 4가지의 상태 관리 라이브러리 중 가장 러닝커브 높음(고통스러웠던 이유가...)
  • 보일러 플레이트 코드가 많음

=> 대규모 앱에서 유리

Recoil

Recoil

특징

  • Atomic한 상태 관리 라이브러리로 Atom과 Selectors를 사용
  • atom은 컴포넌트에서 구독 가능한 상태 조각으로, 변경 시 구독중인 컴포넌트들도 모두 리렌더링 됨.
  • Selector는 순수 함수로, Atom 또는 다른 Selector의 상태를 기반으로 계산된 데이터를 반환.

장점

  • React를 개발한 Meta에서 만들어 React의 useState와 유사한 직관적인 구조
  • 간결한 상태 관리와 직관적인 API

단점

  • 개발자 도구가 없음(직접 console.log를 찍어봐야 한다)
  • 고로 유지 보수가 쉽지 않다. 사이즈가 커질수록 더욱
  • 3월에 나온 0.7.7 버전 이후로 버전 업데이트가 멈춤

Recoil은 버려진건가?

=> 소규모 앱에서 유리

Zustand와 Jotai

저번 프로젝트를 진행하면서 Recoil이 나온지 꽤 지났는데도 버전이 0.7.7밖에 되지 않는게 이상해서 찾다보니 Recoil의 버전 업데이트가 지난 3월 이후로 되지 않았다는 것을 알게되고, 이를 찾는 과정에서 Jotai와 Zustand의 존재와 강점들도 알게 되었다. 

Zustand

장점(Redux 대비)

  • 매우 가벼운 번들 사이즈(4개 중 가장 가볍다)
  • 적은 보일러 플레이트 코드
  • Redux Devtools 사용 가능
  • Type Script 기반으로 작성되어 있음

Jotai

장점(Recoil 대비)

  • Zustand 만큼은 아니지만 가벼운 번들 사이즈
  • Recoil과는 다르게 Key가 필요없음
  • SSR에 대한 지원 활발(공식 문서에도 SSR Part가 있음)
  • Type Script 기반으로 작성되어 있음

 

이번 프로젝트에서는 이런 점들을 고려해서 어떤 상태 라이브러리를 사용할지에 대한 회의를 진행했다. 그 결과

  • 프로젝트 설계 시, 많은 Client 상태 관리가 필요하지 않음
    • 따라서 대규모 시스템에 적합한 Flux 패턴 상태 관리보다, 가벼운 Atom 패턴 기반의 상태관리 선정
  • Jotai의 경우, Recoil에 비해 최신 업데이트 지원이 자주 되고 있음
  • SEO를 고려하여 Next.js로 개발중인데, SSR에 대한 지원이 활발함

위의 점들을 고려하여 Jotai를 우리가 사용할 라이브러리로 선정하고, 프로젝트 구현을 진행중이다. 아직까지는 다행히도 트러블이 일어나지는 않은 상태로 무사히 진행중인데, 만약 트러블 슈팅을 할 일이 생긴다면 추가적으로 글을 쓰겠다.

참조

더보기