상태관리

처음 React를 배울 때는 상태관리가 그렇게 중요하게 느껴지지 않았다.

컴포넌트 안에서

const [count, setCount] = useState(0);

정도만 써도 대부분 동작했다.

문제는 프로젝트 규모가 커지면서 발생했다.

예를 들어 로그인한 사용자 정보를 여러 컴포넌트에서 같이 사용해야 하는 상황이 생긴다.

App
└── Layout
    └── Header
        └── Profile
            └── UserName

실제로 UserName만 user 데이터가 필요하다.

그런데 데이터를 전달하려면 중간 컴포넌트들이 전부 props를 받아서 다시 내려줘야 한다.

<App user={user} />

<Layout user={user} />

<Header user={user} />

이런 구조가 반복된다.

이걸 보통 props drilling이라고 한다.

초기에는 단순해 보이지만 규모가 커질수록

props 전달 경로 추적 어려움
불필요한 리렌더링
중간 컴포넌트 책임 증가
유지보수 비용 증가

문제가 생긴다. 진짜 처음에 리액트할때는 정말정말 복잡했다.

Zustand

최근 React 생태계에서 가장 많이 사용하는 상태관리 중 하나다.

import { create } from 'zustand';

const useUserStore = create((set) => ({
  user: null,
  count: 0,

  setUser: (user) => set({ user }),

  incrementCount: () =>
    set((state) => ({
      count: state.count + 1,
    })),
}));

사용할 때는 필요한 값만 선택한다.

const count = useUserStore((state) => state.count);

Zustand의 장점

처음 Zustand를 썼을 때 가장 좋았던 건 "쉽다"는 점이었다.

Redux처럼

action
reducer
dispatch

구조를 강하게 요구하지 않는다.

즉

진입장벽이 낮고
코드량이 적고
빠르게 상태를 만들 수 있다.

selector 기반 구조

Zustand의 중요한 특징은 selector 기반 사용이다.

const count = useUserStore((state) => state.count);

즉 필요한 상태만 구독한다.

그래서

불필요한 리렌더링 감소
Context보다 세밀한 구독 가능

장점이 있다.

실제로 규모가 커질수록 “무엇이 리렌더링되는가” 추적하는 게 중요해진다.

middleware 생태계

persist도 실무에서 자주 썼다.

persist(...)

예를 들어:

다크모드
상품 필터
view mode

같은 상태를 localStorage에 저장할 수 있다.

또 devtools middleware도 지원한다.

devtools(...)

그래서 Redux 없이도 꽤 편하게 상태 흐름을 추적할 수 있었다.

Zustand의 단점

반대로 Zustand의 가장 큰 단점은

구조를 강제하지 않는다는 점

이다. 작은 프로젝트에서는 장점이다.

근데 규모가 커지면

store 구조 제각각
action naming 불일치
상태 책임 분산

문제가 생길 수 있다.

자유도가 높은 대신
팀 컨벤션이 중요해진다.

Redux

Redux는 React 상태관리의 대표적인 표준이었다.

지금도

금융
대규모 서비스
레거시 프로젝트

에서 많이 사용된다.

현재는 보통 Redux Toolkit(RTK) 기반으로 사용한다.

const counterSlice = createSlice({
  name: 'counter',
  initialState: { count: 0 },

  reducers: {
    increase: (state) => {
      state.count += 1;
    },
  },
});

Redux의 진짜 장점

많은 사람이

보일러플레이트 많다

만 이야기한다. 근데 실무에서 Redux의 진짜 장점은 상태 변경 흐름이 강제된다는 점 이었다.

모든 상태 변경이

action
→ reducer
→ state update

흐름을 따른다.

상태 변경 추적 가능
액션 로그 추적 가능

하다. 대규모 조직에서는 이게 꽤 중요하다.

Redux가 여전히 강한 영역

특히

복잡한 비즈니스 로직
액션 기반 상태 흐름
미들웨어 중심 구조

에서는 Redux가 여전히 강하다.

Redux의 단점

반대로 단점은 명확하다.

구조가 무겁다
학습 비용이 있다
작은 프로젝트에는 과하다

특히 App Router 이후

서버 상태는 React Query / Server Component
UI 상태는 Zustand

로 분리되는 흐름이 많아지면서 Redux 사용량이 줄어든 느낌도 있다.

Recoil

Recoil은 Meta에서 만든 상태관리 라이브러리다.

핵심 개념은 atom이다.

const countAtom = atom({
  key: 'count',
  default: 0,
});

상태를 atom 단위로 잘게 나눈다.

Recoil의 문제

문제는 생태계였다.

2023년 이후 업데이트가 활발하지 않았다.

실제로 신규 프로젝트에서는

유지보수 리스크
생태계 불확실성

때문에 선택을 조심하게 된다.

그래서 최근에는

Zustand
Jotai
Redux Toolkit

쪽을 더 많이 본다.

Jotai

Jotai는 개인적으로 Recoil의 흐름을 더 단순하게 가져간 느낌이었다.

const countAtom = atom(0);

굉장히 가볍다.

atom 단위 상태 관리 방식도 직관적이다.

Jotai의 장점

특히

작은 상태 단위 관리
React Suspense 친화성
App Router 궁합

이 좋았다.

또 Zustand보다

더 fine-grained subscription
atom 기반 dependency

구조가 강하다.

Jotai의 단점

반대로 atom 수가 많아지면

상태 관계 추적
atom 의존성 관리

가 어려워질 수 있다.

즉

작은 상태 단위에는 강하지만
앱 전체 구조 관리 관점에서는 팀 컨벤션이 중요하다.

내가 Zustand를 선택한 이유

결국 현재는 대부분 Zustand를 가장 많이 사용한다.

이유는 단순하다.

1. App Router와 궁합이 좋았다

App Router 이후에는

Server Component
→ 서버 상태 처리

Client Component
→ 최소 UI 상태만 관리

흐름이 강해졌다.

즉 예전처럼 거대한 Redux store가 꼭 필요하지 않은 경우가 많아졌다.

2. 필요한 상태만 빠르게 만들 수 있었다

예를 들어

modal open
sidebar toggle
theme state
filter state

같은 건 Zustand가 굉장히 편했다.

코드량이 적고, selector 기반이라 리렌더링도 비교적 예측 가능했다.

3. persist middleware가 실무에서 유용했다

persist(...)

로

다크모드
상품 필터
최근 검색어

같은 상태를 쉽게 저장할 수 있었다.

특히 localStorage와 연결되는 UI 상태 관리에서 생산성이 좋았다.

4. Redux만큼 무겁지 않았다

솔직히 작은~중간 규모 프로젝트에서는

action
reducer
dispatch
slice
middleware

구조가 과하다고 느껴질 때가 많았다.

반면 Zustand는

진입장벽 낮고
코드량 적고
React스럽게 사용할 수 있었다.