320x100
320x100

 

상태 관리 라이브러리의 역할

- 상태를 중앙에서 관리

앱이 커지면 여러 컴포넌트들이 같은 데이터를 사용해야 하는 경우가 많은데, 상태 관리 라이브러리를 활용하면 공통 상태를 중앙 저장소에 두고 필요한 컴포넌트들이 그 값을 구독 (로그인 상태, 사용자 정보, 테마 등등)

 

- 컴포넌트 간 데이터 전달 단순화

기본 React에서는 props drilling 문제 (부모 > 자식 > 손자 > ...) 가 생김

상태 관리 라이브러리는 중앙에서 직접 접근 할 수 있어 불필요한 데이터 전달을 줄임

 

- 일관된 상태 흐름 보장

특정 액션(버튼 클릭, API 응답)이 발생했을 때 상태가 어떻게 변하는지 명확히 관리

예측 가능한 상태변경으로 인해 디버깅과 유지보수가 쉬워짐

 

- 비동기 데이터 관리

API 호출 같은 서버 상태를 다룰 때 로딩/에러/성공 상태를 쉽게 관리

 

- 성능 최적화

상태 관리 라이브러리들은 보통 필요한 컴포넌트만 리렌더링 되도록 설계되어 있어 불필요한 렌더링을 줄임

 

 

 

 

 

Redux Toolkit

가장 전통적이고 널리 쓰이는 상태 관리

Redux의 보일러플레이트를 줄여주는 툴킷

 

- 장점

대규모 프로젝트에서 상태 흐름이 명확해짐

미들웨어 (Redux Trunk, Saga) 활용 가능

디버깅 툴 (Redux DevTools) 지원

 

 - 단점

작은 프로젝트엔 다소 무겁고 코드량 많음

러닝 커브 존재

 

 

 

 

Recoil

Facebook에서 개발한 상태 관리. 원자 단위로 세분화 가능

 

- 장점

컴포넌트 기반 상태 관리 (필요한 컴포넌트란 리렌더링)

비동기 상태 관리가 쉬움 (selector async 지원)

React와 궁합이 좋음

 

- 단점

아직 실험적인 라이브러리로 생태계가 작음

공식 유지보수가 Redux 만큼 활발하지 않음

 

 

 

 

Zustand

경량 상태 관리 라이브러리로 Redux보다 단순함

 

- 장점

코드량이 적고 간단함 (보일러플레이트 최소화)

작은/중간 규모 프로젝트에 적합

immer 내장으로 불변성 관리가 쉬움

 

- 단점

아주 큰 프로젝트에서는 구조 관리가 힘들 수 있음

미들웨어 활용은 Redux 만큼 다양하지 않음

 

 

 

 

MobX

반응형 프로그래밍 기반 상태 관리. 옵저버 패턴을 활용

 

- 장점

선언적 코드, 자동으로 상태 추적 가능

러닝 커브가 낮음 (코드가 직관적임)

성능 최적화가 잘되어있음 (필요한 부분만 리렌더링)

 

- 단점

마법 같은 동작이 많아 디버깅이 어려움

대규모 프로젝트에서는 상태 추적이 헷갈릴 수 있음

 

 

 

 

Jotai

Recoil과 비슷한 철학, 더 미니멀한 상태 관리

 

- 장점

매우 가볍고 단순한 API

원자 단위 관리로 필요한 부분만 리렌더링

React Suspense 지원

 

- 단점

생태계가 작음

복잡한 상태 트리에서는 관리가 어려울 수 있음

 

 

 

React Query (TanStack Query)

서버 상태 관리 전문. 클라이언트 상태보다 API 호출 상태 관리에 강점

 

 - 장점

API 요청/캐싱/리페치/동기화 관리 용이

서버 상태에 대해 오프라인 지원

로딩 / 에러 상태 자동 관리

 

- 단점

클라이언트 로컬 상태 전반 관리에는 적합하지 않음

Redux / Zustand 같은 전역 상태 관리와 병행이 필요할 수 있음

 

300x250
728x90