2026 프론트엔드 상태관리 선택: Zustand vs Redux vs Jotai

TanStack Query 같은 서버 상태 도구가 자리를 잡으면서, 전역 상태 라이브러리가 담당할 몫은 확실히 줄었다. 그런데도 다크 모드, 사이드바 열림, 다단계 폼 초안, 편집기 선택 상태처럼 여러 화면이 공유하는 클라이언트 상태는 남는다. 문제는 이 남은 부분을 어떤 도구로 관리하느냐에 따라 이후 몇 년의 코드 모양이 달라진다는 점이다. 이 글은 Zustand, Redux Toolkit, 원자(atom) 단위 접근을 실무 기준으로 비교했다.

서버 상태와 클라이언트 상태의 경계

먼저 "이 값의 원본이 어디 있는가"를 묻는다. 원본이 서버에 있으면 서버 상태 도구로 간다. 원본이 브라우저에만 있고 여러 컴포넌트가 공유하면 클라이언트 전역 상태다. 이 경계를 흐리게 두면 상태 도구를 바꿔도 문제가 사라지지 않는다.

세 도구의 모델 차이 요약

스토어·슬라이스·원자 단위 접근 비교

Zustand는 스토어를 훅처럼 쓰고 필요한 조각만 선택해 구독한다. 보일러플레이트가 적고 학습 곡선이 완만하다. Redux Toolkit은 슬라이스·리듀서·미들웨어라는 정해진 구조가 있어, 큰 팀에서 상태 변경 흐름을 규율 있게 관리하고 디버깅 도구를 쓰는 데 강점이 있다. Jotai는 상태를 하향식으로 조합하지 않고, 각 원자를 필요한 곳에서 구독한다. 파생 상태가 많고 화면이 잘게 나뉠 때 유리하다.

// Zustand — 선택자로 조각 구독
const count = useCounterStore((s) => s.count);

// Jotai — 원자 단위
const countAtom = atom(0);
const [count, setCount] = useAtom(countAtom);

프로젝트 규모와 팀 역량에 따른 선택

• 소규모·빠른 시작 — Zustand가 대체로 가장 적은 코드로 시작한다
• 대규모·규율 중시·기존 Redux 자산 — Redux Toolkit의 구조가 유리하다
• 파생 상태 중심·세밀한 구독 — Jotai가 자연스럽다
• 팀이 이미 한 도구에 익숙하면 그 익숙함이 이론적 우위보다 큰 경우가 많다

마이그레이션 비용과 위험

상태 도구 교체는 단순 교체가 아니라 리팩터링이다. 기존 코드가 상태를 어떻게 읽고 쓰는지, 부수 효과가 어디에 있는지에 따라 비용이 크게 갈린다. 다음 순서를 권한다: 새 기능은 새 도구로, 기존 코드는 건드리지 않는다 → 경계가 명확한 화면부터 옮긴다 → 공유 상태를 줄인 뒤 도구를 정리한다. 서버 상태가 섞여 있다면 먼저 그 부분을 서버 액션과 데이터 페칭 계층으로 옮겨 전역 상태를 실제로 줄인 뒤 판단한다.

디버깅·테스트 관점의 차이

Redux는 시간 여행 디버깅과 액션 로그가 기본 제공되어 상태 변화 추적이 강하다. Zustand는 가볍지만 미들웨어를 붙이지 않으면 추적 정보가 적다. Jotai는 원자 의존 그래프를 그려야 복잡한 상호작용을 이해할 수 있다. 테스트는 세 도구 모두 스토어/원자를 컴포넌트 밖에서 초기화할 수 있어 단위 테스트가 어렵지 않다.

도입 전에 확인할 기준

1. 서버 상태가 섞여 있지 않은가 — 먼저 분리한다
2. 공유가 필요한 상태가 실제로 몇 개인가 — 세 개 이하면 라이프팅도 후보다
3. 파생 상태와 구독 최적화가 중요한가
4. 팀이 디버깅 도구에 얼마나 의존하는가
5. 3년 뒤 유지보수할 사람이 이해할 수 있는가

상태 경계를 어디에 두는지는 컴포넌트 경계와도 맞물린다. React Server Components 경계 설계와 함께 보면 "무엇을 클라이언트로 보낼지"와 "그 안에서 무엇을 전역으로 둘지"를 같은 기준으로 정리할 수 있다.

도입 순서와 되돌리기 기준

상태 도구는 한 번 깊게 들어가면 걷어내기 어렵다. 그래서 도입은 "필요해진 시점에, 좁은 범위로" 시작하고, 되돌리는 기준을 미리 정해 둔다.

1. 먼저 서버 상태를 전용 도구로 분리해 전역 상태의 실제 크기를 확인한다
2. 공유 상태가 세 개 이하면 라이프팅이나 컨텍스트로 충분한지 검토한다
3. 필요하다면 화면 하나에서 스토어를 도입하고 관측 가능한 지표를 정한다
4. 리렌더 횟수, 번들 증가, 디버깅 난이도를 기준선과 비교한다
5. 개선이 없거나 유지보수 부담이 커지면 되돌린다

되돌리기 기준을 정해 두면 "이미 도입했으니 계속 간다"는 매몰 비용 함정을 피할 수 있다. 특히 팀 규모가 작을수록 도구 자체보다 규약이 더 중요하다.

마지막으로 상태 이름과 소유 범위를 문서로 합의한다. 같은 값이 두 저장소에 존재하지 않도록 "이 값의 원본은 어디인가"를 한 줄씩 적어 두면, 상태 도구가 무엇이든 이후 혼란이 크게 줄어든다.

상태 이름과 소유권 합의

도구를 고르는 것보다 중요한 것은 "이 값의 원본은 어디인가"를 합의하는 일이다. 같은 개념이 서버 캐시와 전역 스토어, URL에 동시에 존재하면 어느 쪽이 최신인지 아무도 확신하지 못한다.

이 표를 팀 문서에 두고 새 상태를 추가할 때마다 어디에 속하는지 먼저 정한다. 원본이 하나로 유지되면 어떤 라이브러리를 쓰든 이후 변경이 훨씬 수월하다.

도구 선택은 프로젝트가 시작될 때보다 기능이 자라난 뒤에 더 자주 문제가 된다. 그때 되돌리기 쉽도록, 처음부터 상태의 원본과 소유 범위를 문서로 남겨 두는 것이 가장 값싼 보험이 된다.