실제로 사용해보면서 느끼는 것은 zustand는 Redux와 유사한 면이 있고, Jotai는 recoil과 유사한 면이 있다고 한다.
늘 그렇지만 두 도구중 어떤 것이 더 우월하다기 보다는 만든이의 철학과 설계에 있어서 차이가 있을 뿐, 전역 상태 관리와 리렌더링 성능 측면에서는 큰 차이가 없다. 그렇기 때문에 개인의 취향(?) 혹은 프로젝트 요구사항에 맞춰서 사용하면 된다고 생각한다.
Zustand
Zustand의 Redux와 비슷하게 중앙 집중형 방식을 차용하고 있다고 생각한다.
즉, 하나의 Store를 생성하고, 필요한 모든 상태를 그 안에서 정의하고 관리하는 방식이라는 것이다.
그리고 각 컴포넌트는 Store에서 필요한 상태를 가져와 사용하는 방식이다.
이러한 특성으로 인해 개발하는 애플리케이션의 전반적인 상태를 쉽게 파악할 수 있다는 장점이 있다.
예를 들어, 이전에 실시간 성이 필요한 서비스 개발을 위해 websocket 연결 상태를 관리해야할 필요가 있었는데, 이때 Zustand가 굉장히 적절한 선택이었다고 느꼈다.
하지만 반대로, 관리해야 하는 상태가 늘어나고, 복잡해질수록 오히려 관리가 힘들어질수도 있다는 단점이 있다.
Jotai
반대로 Jotai의 경우, 상태를 원자(atom) 단위로 쪼개어 관리하는 방식을 차용하고 있다.
그렇기 때문에 각 컴포넌트는 필요한 atom을 구독하여 해당 상태를 사용하고, 중앙에서 관리되는 zustand와 달리 각 컴포넌트에서 독립적으로 관리된다는 차이점이 있다.
개인적으로 사용하면서 느끼는 점은 React의 useState와 사용하는 방법이 유사하다는 것인데, 각 상태를 개별적으로 정의하고 관리함으로써 Zustand에 비해서 더 세밀한 리렌더링 제어가 가능하다는 것이다.
하지만 각 컴포넌트에서 개별적으로 관리된다는 측면 때문에 애플리케이션의 전반적인 상태를 파악하는데 어려움이 있을 수 있고, 이는 개인적으로 디버깅하는데 있어서 어느정도 체감하는 부분이다.
Zustand vs Jotai
그럼 둘 중 뭘 쓰는게 더 좋을까?
늘 그렇듯 정답은 없다.
하지만 개인적으로 느끼는 바는 다음과 같다.
Zustand
1. 많은 개발자들과 협업하는 경우
2. Redux devTools를 선호하는 경우
3. Websocket 연결 상태를 관리해야하는 경우
Jotai
1. useContext의 대체제정도를 찾는 경우
2. 프로젝트 규모가 그리 크지 않은 경우 (사실 필자와 같이 신입 레벨에서의 프로젝트에서는 대부분 이에 해당한다고 생각한다)
3. 코드 분할에 미친(?) 개발자
'프론트엔드' 카테고리의 다른 글
[프론트엔드] 리액트는 어쩌다 모든걸 함수로 작성하게 되었을까? (1) | 2025.05.09 |
---|---|
[프론트엔드] localhost에 https 적용하기 (0) | 2025.05.03 |
[프론트엔드] SEO 최적화 (2) | 2024.12.11 |
[프론트엔드] dvh (CSS 단위) (0) | 2024.11.22 |
[프론트엔드] SSR/CSR 환경별 쿠키 관리 방법 (0) | 2024.11.04 |