[React] 상태 관리 대전: Zustand(Flux) vs Jotai(Atomic) 아키텍처 비교 및 선택 가이드

📌 핵심 요약

  • Redux의 복잡함(Boilerplate)에 지친 개발자들이 찾는 두 가지 대안
  • Zustand: 중앙 집중식(Flux) 패턴, 직관적이고 가벼움 (Redux의 정신적 계승)
  • Jotai: 분산형(Atomic) 패턴, 컴포넌트 중심의 상태 관리 (Recoil의 정신적 계승)
  • 실무 프로젝트 성격에 따른 명확한 선택 기준 제시

지난 몇 년간 React 상태 관리의 왕좌는 Redux가 지키고 있었습니다. 하지만 Redux Toolkit(RTK)이 나왔음에도 여전히 설정해야 할 코드가 많고, Context API는 렌더링 최적화가 어렵다는 단점이 있습니다.

2026년 현재, 프론트엔드 씬은 "더 적은 코드로, 더 빠르게"를 지향합니다. 그 중심에 있는 두 라이브러리, Zustand(주스탠드)와 Jotai(조타이)를 해부해 봅니다.

주스탄 조타이 상태 관리

1. Zustand: "가장 쉬운 Redux" (Flux 패턴)

Zustand는 독일어로 '상태'를 뜻합니다. Redux처럼 단일 스토어(Single Store) 방식을 따르지만, Provider로 앱을 감쌀 필요가 없다는 것이 혁명적입니다.

핵심 철학

  • 단순함: Hook 기반으로 스토어를 생성하고 바로 사용합니다.
  • 중앙 집중: 앱의 전역 상태를 한 곳에서 관리하기 좋습니다.
  • 불변성 관리 최소화: Immer 미들웨어를 쓰면 불변성을 신경 쓰지 않고 상태를 변경할 수 있습니다.
import { create } from 'zustand' // 스토어 생성 (상태 + 액션이 한 곳에!) const useStore = create((set) => ({ bears: 0, // 액션 정의 increase: () => set((state) => ({ bears: state.bears + 1 })), removeAll: () => set({ bears: 0 }), })) // 컴포넌트 사용 function BearCounter() { // 필요한 상태만 쏙 뽑아옴 (Selector) -> 렌더링 최적화 자동 const bears = useStore((state) => state.bears) return <h1>{bears} bears</h1> }

2. Jotai: "Recoil의 경량화 버전" (Atomic 패턴)

Jotai는 일본어로 '상태'를 뜻합니다. (재미있게도 둘 다 이름 뜻이 같습니다.) Atomic 패턴을 따르며, 상태를 아주 작은 단위인 Atom(원자)으로 쪼개서 관리합니다.

핵심 철학

  • Bottom-Up: 작은 상태 조각들을 조립해서 큰 상태를 만듭니다.
  • React 친화적: useState와 사용법이 거의 똑같습니다.
  • 파생 상태(Derived State): A 아톰이 변하면 B 아톰이 자동으로 계산되는 로직을 짜기 매우 쉽습니다.
import { atom, useAtom } from 'jotai' // 원자(Atom) 생성 const priceAtom = atom(10) const taxAtom = atom((get) => get(priceAtom) * 0.1) // 파생 아톰 (자동 계산) function Cart() { const [price, setPrice] = useAtom(priceAtom) const [tax] = useAtom(taxAtom) // price가 바뀌면 tax도 자동 업데이트 return ( <div> Price: {price} + Tax: {tax} <button onClick={() => setPrice(price + 10)}>Add</button> </div> ) }

3. 비교 및 선택 가이드

두 라이브러리 모두 훌륭하지만, 사용 목적이 조금 다릅니다. 프로젝트의 성격에 맞춰 선택하세요.

비교 항목 Zustand (Flux) Jotai (Atomic)
멘탈 모델 "중앙 타워에서 전체를 통제한다" "레고 블록을 조립한다"
SSR 지원 설정이 조금 필요함 (Next.js) 매우 자연스럽게 지원 (Hydration)
DevTools Redux DevTools 사용 가능 👍 전용 디버거 제공
추천 상황 - 사용자 정보, 환경 설정 등 전역 데이터
- Redux에 익숙한 팀 		- 엑셀 시트, 캔버스 등 복잡한 상호작용
- React Suspense 적극 활용 시

4. 결론

개인적인 추천으로는 일반적인 웹 서비스(어드민, 쇼핑몰, 커뮤니티)라면 Zustand가 압도적으로 편합니다. Redux DevTools를 그대로 쓸 수 있어 디버깅이 쉽고, 코드 구조가 명확하기 때문입니다.

반면, 그래픽 에디터, 대시보드 위젯처럼 컴포넌트 간의 의존성이 복잡하게 얽혀 있고 상태가 자주 변하는 앱이라면 Jotai가 더 나은 렌더링 성능과 개발 경험을 제공할 것입니다.

이 블로그의 인기 게시물

Docker 컨테이너 'Connection Refused' (Errno 111) 오류 해결 가이드

이미지
🎯 타겟 독자: Docker 입문자, 컨테이너를 띄웠으나 localhost 로 접속이 안 되는 백엔드 개발자, MSA(마이크로서비스) 구축 중 통신 오류를 겪는 엔지니어. 📝 요약: Docker 접속 오류(Errno 111)의 90%는 애플리케이션이 '0.0.0.0'이 아닌 '127.0.0.1' 로 바인딩 되어 있거나, 포트 포워딩(-p) 설정이 누락되어 발생합니다. 이 글에서는 네트워크 인터페이스의 차이를 이해하고, 외부 접속을 허용하는 올바른 설정법을 정리합니다. 1. 문제 정의: "컨테이너는 떴는데 접속이 안 돼요" Docker 입문자들이 가장 흔하게 겪는 상황입니다. docker ps 로 확인하면 상태(STATUS)는 분명히 Up 인데, 브라우저나 Postman으로 접속하면 즉시 연결이 거부됩니다. curl: (7) Failed to connect to localhost port 8080: Connection refused Python: ConnectionRefusedError: [Errno 111] Connection refused 이 문제는 방화벽 때문이 아닙니다. "누구의 요청을 들을 준비가 되었는가(Listen Address)" 에 대한 설정이 잘못되었기 때문입니다. 2. 원인 분석: 127.0.0.1의 함정 핵심은 Loopback(127.0.0.1) 과 Any Address(0.0.0.0) 의 차이입니다. 로컬 PC에서 개발할 때 서버를 localhost 로 띄우는 건 보안상 좋은 습관입니다. 하지만 Docker 컨테이너는 독립된 IP를 ...
자세한 내용 보기

Redis 캐싱 전략 완벽 가이드: Look Aside부터 Write Back까지 (DB 부하 줄이기)

이미지
🎯 타겟 독자: 사용자가 몰릴 때마다 DB CPU가 100%를 치는 상황을 겪는 백엔드 개발자, Redis를 단순히 get/set 으로만 쓰고 있는 주니어 엔지니어. 📝 요약: 캐시(Cache)는 성능 향상의 치트키지만, 잘못 쓰면 데이터 불일치(Inconsistency) 라는 재앙을 부릅니다. 이 글에서는 가장 대중적인 Look Aside(Lazy Loading) 패턴과 쓰기 성능을 극대화하는 Write Back 패턴의 작동 원리, 장단점, 그리고 언제 무엇을 써야 하는지 명확한 기준을 제시합니다. 1. 캐싱 패턴이 왜 중요한가요? "그냥 Redis에 넣으면 되는 거 아닌가요?"라고 묻는다면 반은 맞고 반은 틀립니다. 캐시를 데이터베이스(DB)와 어떤 순서로 연동하느냐에 따라 시스템의 데이터 정합성 과 성능 이 완전히 달라지기 때문입니다. 2. 패턴 ① Look Aside (Lazy Loading) - 국룰 전략 현업에서 80% 이상 사용되는 가장 일반적인 읽기 전략입니다. 캐시를 옆(Aside)에 두고 필요할 때만 데이터를 가져옵니다. 작동 순서 앱이 데이터를 찾을 때 먼저 캐시(Redis)를 찌릅니다. 캐시에 데이터가 있으면(Cache Hit) 바로 반환합니다. (DB 부하 0) 없으면(Cache Miss) DB에서 조회 하여 가져옵니다. 가져온 데이터를 캐시에 저장 하고 반환합니다. public User getUser(Long id) { // 1. 캐시 조회 User user = redisTemplate.opsForValue().get("user:" +...
자세한 내용 보기

브라우저 렌더링 원리: Reflow와 Repaint 최적화 가이드 (CRP 심층 분석)

이미지
📌 핵심 요약 CRP(Critical Rendering Path) 의 5단계: DOM → CSSOM → Render Tree → Layout → Paint 성능의 주범 Reflow(Layout) 와 Repaint 의 차이점 애니메이션 성능 최적화: 왜 top/left 대신 transform 을 써야 하는가? (GPU 가속과 Composite) "사용자가 주소창에 URL을 입력하고 엔터를 쳤을 때, 화면에 네이버 메인이 뜨기까지 무슨 일이 일어나는가?" 이 질문은 네트워크 관점(DNS, TCP/IP)에서도 답변할 수 있지만, 프론트엔드 개발자라면 렌더링 엔진(Rendering Engine)이 HTML과 CSS를 해석해서 픽셀로 바꿔주는 과정, 즉 CRP(Critical Rendering Path)를 설명할 수 있어야 합니다. 이 원리를 알아야 "왜 리액트가 Virtual DOM을 쓰는지", "왜 애니메이션이 버벅이는지" 이해할 수 있습니다. 1. 렌더링 파이프라인 (The Pipeline) 브라우저는 다음 5단계를 거쳐 화면을 그립니다. DOM 트리 생성: HTML 문서를 파싱 하여 태그 간의 관계(부모-자식)를 트리 구조로 만듭니다. CSSOM 트리 생성: CSS 파일과 인라인 스타일을 파싱 하여 스타일 규칙 트리를 만듭니다. Render Tree 생성: DOM과 CSSOM을 결합하여 "실제로 화면에 표시될 노드" 만 추려냅니다. Layout (Reflow): 각 노드가 화면의 어느 위치에, 어떤 크기(px) 로 배치될지 기하학적 계산을 수행합니다. ...
자세한 내용 보기