들어가며
전역 상태 관리 라이브러리는 언제 어떤 것을 선택해 사용하는 것이 현명한 것일까?
물론 회사에 들어가면 회사에서 사용하는 라이브러리를 채택해 사용해야겠지만 오늘은 각 라이브러리가 갖고있는 탄생 비화, 장점에 대해서 살펴보면서 그래도 어느정도 내가 이것을 왜 사용해야 하는지에 대한 견문을 넓혀보는 시간을 가질 예정이다.
비교 대상은 대표적인 라이브러리 Redux, Zustand, Jotai 3개이다.
각자가 어떤 배경에서 탄생을 했고 어떤 장점과 단점이 있는지 살펴볼 예정이다.
🐶 Redux
배경
첫번째는 Redux이다. 2015년에 나왔으며 가장 오래된 라이브러리이다. 단방향 데이터 흐름인 Flux에서 영감을 많이 받아 나온 라이브러리이며 그래서인지 Flux에서의 액션과 스토어 개념을 기반으로, Redux 또한 액션을 통해 상태 변화를 설명하고, 리듀서라는 녀석을 통해 상태를 업데이트한다는 것이 특징이다. 목적은 변함없이 상태 변화의 예측 가능성을 높이는데 있다.
Redux의 등장이 획기적이었던 이유는 이 때부터 하나의 글로벌 상태 객체를 만들어 하위 컴포넌트로 전파시키는 것이 가능해져 Context api에서 또는 props drilling 현상으로 인해 발생하는 불필요한 리렌더링을 최적화 할 수 있게 되었다.
장점
Redux가 나온 시점에 장점은 다음과 같았다.
1. 예측 가능한 상태 관리: 상태 변화를 예측하기가 쉬워져 디버깅과 테스트가 용이하다.
2. 편리한 미들웨어 지원: Redux는 비동기 작업을 처리하기 위한 미들웨어(예: Redux Thunk, Redux Saga)를 지원한다.
단점
하지만 명확한 단점 또한 존재한다. 보일러플레이트(기틀을 다지는 작업)나 러닝 커브가 너무 높다라는 점이었다. 말 그대로 이를 적용할 때 필요한 부수 작업들이 너무 많고 그것을 완전히 이해하고 사용하는 문턱이 너무 높앗다. 라는 점이다. 전역으로 관리해야 하는 상태가 많지 않은 상태에서 Redux를 채택할 때 구축하는데 시간을 많이 할애해 버리니 배보다 배꼽이 더 커지는 상황이 연출된다.
🐱 Zustand
Redux가 나온 시점에서 hook이라는 패러다임이 등장하면서 나온 녀석들이 대표적인게 Recoil, Zustand, Jotai이다. Recoil과 Jotai는 Context와 Provider, 그리고 훅을 기반으로 가능한 작은 상태를 효율적으로 관리하는데 초점을 맞추고 있다면 그 중에 Zustand는 리덕스오 비슷하게 하나의 큰 스토어를 기반으로 상태를 중앙집중관리하는 라이브러리라고 한다. Zustand에 대해서 더 자세히 살펴보자.
배경
Zustand는 앞서 다뤘던 Redux에 영감을 받아 만들어졌다. 즉 하나의 스토어를 중앙 집중형으로 활용해 이 스토어 내부에서 상태를 관리한다. 특징은 보일러플레이트 코드가 많이 필요하다는 Redux의 단점을 보완해 보다 훨씬 간단한 API를 제공하며, 개발자들이 빠르게 사용할 수 있도록 설계되었다는 것이 특징이다. 또한 구독 기반 업데이트가 추가되어 상태가 변경되었을 때 이 상태를 구독하고 있는 컴포넌트만 업데이트되도록 설계되어 있다.
장점
이처럼 Redux에 단점을 보완한 Zustand의 장점은 다음과 같다.
- 간단한 API: 학습 곡선이 낮고, 설정이 간편하여 빠르게 사용할 수 있다.
- 최적화: 상태가 변경될 때 구독한 컴포넌트만 업데이트되므로 성능상 이점이 있다.
- 커스터마이징이 유연함: Zustand는 여러 개의 스토어를 쉽게 만들 수 있어, 애플리케이션의 구조에 맞게 상태를 모듈화할 수 있다. 이는 특히 대규모 애플리케이션에서 유리하다.
단점
이처럼 Redux에 비해 간편한 api를 제공하는 Zustand 또한 몇 가지 단점은 존재한다.
- 상태 간의 의존성: Zustand는 상태를 간단하게 관리할 수 있지만, 상태 간의 복잡한 의존성을 처리하는 데는 한계가 있다. 여러 상태가 서로 의존하는 경우, 이를 관리하기가 어려워진다.
- 일관성 유지의 어려움: Zustand는 상태를 더 자유롭게 업데이트할 수 있지만, 이로 인해 상태 관리의 일관성이 떨어질 수 있습니다. 상태 변경이 명확하게 정의되지 않으면, 애플리케이션의 예측 가능성이 감소할 수 있습니다.
🐰 Jotai
마지막으로 Jotai이다. Jotai는 이번 포스팅에서는 다루지 못한 Recoil이라는 라이브러리에서 영감을 받아 탄생한 라이브러리이다.
배경
Jotai는 Recoil과 똑같이 atom 기반의 접근 방식을 채택했다는 점이 특징이.
atom이란 상태를 말 그대로 원자 단위로 작게 관리한다는 철학이다. 각 원자는 독립적으로 존재하며, 필요한 컴포넌트에서만 구독할 수 있기에 상태를 보다 세밀하게 관리할 수 있게 해준다.
장점
- 간결한 API : Jotai 또한 Zustand와 마찬가지로 간편한 api를 제공한다. 나는 개인적으로 zustand보다 훨~신 간편하다고 생각한다.
- 모듈화된 상태 관리: 상태를 원자 단위로 나누어 관리하므로, 각 상태를 독립적으로 업데이트할 수 있어 코드의 유지보수성이 높다고 볼 수 있다.
- 성능 최적화: 성능 최적화 또한 zustand와 동일하다. jotai는 원자 기반으로 상태를 관리하기 때문에, 상태가 변경될 때 해당 원자에 의존하는 컴포넌트만 업데이트된다. 이는 성능을 최적화하는 데 도움이 됩니다.
단점
이러한 Jotai도 단점이 있다면 다음과 같다.
- 상태 관리의 일관성: Zustand가 상태 간에 의존성을 주입하기가 비교적 쉬웠다면 이 친구는 one atom one state이기 때문에 상태간에 의존성을 연결하기가 쉽지가 않다. 상태 간의 의존성을 잘못 관리하면 일관성이 떨어지기에 이는 예기치 못한 리렌더링을 초래할 수 있다.
위에 한가지 말고는 두각으로 나타나는 단점은 없는 것 같다. Zustand와 Jotai만 비교한다면 얼마나 나는 확장성도 일관성도 고려하고 싶을 떄에는 zustand를, 아니다 나는 라이브러리로 관리할 상태가 많이 없고 서로간에 의존성도 중요하지 않은 것 같다 싶을 때에는 Jotai가 훨씬 작업속도가 빨라질 것으로 예상이 된다.
요약
Redux는 기존에 양방향 패턴에서 가지고 있었던 "상태 추적이 어렵다"라는 치명적인 단점을 Flux 패턴과 Elum 아키텍처를 채용해 보완해 낸 최초의 "단방향 데이터 추적 라이브러리"라고 생각하면 편할 것 같다.
하지만 보일러 플레이트 코드가 두껍고 러닝커브 또한 높다는 치명적인 단점이 존재해 이제는 레거시 한 라이브러리라는 생각이 든다.
고로 이제 막 프로젝트를 시작한 개발자라고 한다면 개발의 생산성을 생각했을 때 Jotai나 Zustand를 선택할 것 같다.
