📑 목차
- 리액트 상태 관리, 정말 이렇게 어려워야만 할까요?
- 경량 상태 관리 라이브러리의 등장: 왜 필요할까요?
- Zustand: 미니멀리즘과 성능의 만남
- 주요 특징
- Zustand 사용 예시
- Jotai: 아톰 기반의 유연한 접근 방식
- 주요 특징
- Jotai 사용 예시
- Recoil: 리액트 친화적인 페이스북의 제안
- 주요 특징
- Recoil 사용 예시
- Zustand, Jotai, Recoil 핵심 비교: 한눈에 보기
- 그래서, 어떤 라이브러리를 선택해야 할까요? 선택 가이드
- 1. 프로젝트의 규모와 복잡성
- 2. 팀의 숙련도와 선호도
- 3. 성능 및 번들 사이즈 요구사항
- 4. 특정 기능 요구사항
- 마무리하며: 현명한 선택으로 더 나은 개발 경험을!
Image by Olga_Fil on Pixabay
리액트 상태 관리, 정말 이렇게 어려워야만 할까요?
리액트(React) 개발자라면 한 번쯤은 상태 관리의 늪에 빠져본 경험이 있으실 거예요. 컴포넌트 트리가 깊어질수록 데이터를 전달하기 위해 props drilling을 하거나, 전역 상태를 관리하기 위해 복잡한 boilerplate 코드를 작성해야 하는 상황 말이죠. 특히 프로젝트 규모가 커지거나 여러 개발자가 협업하게 되면, 상태 관리 전략은 애플리케이션의 유지보수성과 성능에 결정적인 영향을 미치게 되는데요.
저도 예전에는 Redux 같은 강력한 라이브러리를 주로 사용했었어요. 물론 Redux는 견고하고 예측 가능한 상태 관리를 제공하지만, 때로는 그 복잡한 설정과 방대한 양의 코드에 지치기도 했죠. 작은 프로젝트나 특정 부분의 상태만 관리하고 싶은데도 Redux Saga나 Redux Thunk 같은 미들웨어까지 동원해야 하는 건 좀 과하다는 생각이 들 때도 있었거든요.
하지만 리액트 생태계는 빠르게 진화하고 있고, 개발자들의 이러한 고충을 덜어주기 위한 다양한 시도들이 계속되고 있습니다. 그중에서도 경량 상태 관리 라이브러리들은 "더 적은 코드로, 더 빠르게, 더 유연하게" 상태를 관리하자는 기치 아래 많은 주목을 받고 있어요. 오늘 우리는 그 대표 주자들인 Zustand, Jotai, Recoil에 대해 깊이 파고들어 보고, 어떤 상황에서 어떤 라이브러리가 빛을 발할지 함께 고민해 볼 겁니다. 여러분의 리액트 개발 경험을 한층 더 즐겁고 효율적으로 만들어 줄 지름길을 찾아보자구요!
경량 상태 관리 라이브러리의 등장: 왜 필요할까요?
기존의 대규모 상태 관리 라이브러리들이 가진 장점은 분명했어요. 예측 가능성, 디버깅 용이성, 강력한 미들웨어 생태계 같은 것들이죠. 하지만 모든 프로젝트가 이러한 풀 스택 상태 관리 솔루션을 필요로 하는 건 아니거든요. 때로는 다음과 같은 이유로 경량 라이브러리가 더 좋은 선택지가 될 수 있습니다.
- 보일러플레이트 코드 감소: 복잡한 액션, 리듀서, 셀렉터 등을 작성할 필요 없이, 상태 정의와 업데이트가 훨씬 간결해집니다.
- 번들 사이즈 축소: 라이브러리 자체가 가볍기 때문에 최종 빌드 파일 크기가 줄어들어 애플리케이션 로딩 속도 향상에 기여합니다.
- 학습 곡선 완화: 새로운 개념을 익히는 데 드는 시간이 줄어들어 팀원들이 빠르게 생산성을 높일 수 있습니다.
- 리액트 훅(Hooks)과의 자연스러운 통합: 대부분의 경량 라이브러리들은 리액트 훅의 철학을 따르며, 컴포넌트 내에서 자연스럽게 상태를 구독하고 업데이트할 수 있도록 설계되었습니다.
- 유연한 아키텍처: 특정 패턴이나 아키텍처를 강요하지 않아, 프로젝트의 필요에 따라 자유롭게 상태 관리 방식을 구성할 수 있습니다.
이러한 장점들은 특히 작은 규모의 프로젝트, 프로토타이핑, 특정 컴포넌트의 로컬 상태를 넘어선 공유 상태 관리, 혹은 마이크로 프론트엔드 환경에서 빛을 발하죠. 이제 각 라이브러리의 특징을 자세히 들여다볼 시간입니다!
Zustand: 미니멀리즘과 성능의 만남
Zustand는 독일어로 '상태'를 의미하는데요, 이름처럼 정말 미니멀리즘을 추구하는 라이브러리입니다. 상태 관리를 위한 보일러플레이트 코드를 극단적으로 줄이고, 빠르고 유연하게 작동하는 데 초점을 맞추고 있어요. Redux 개발팀 중 일부가 만들어서 'Redux의 정신을 계승하되 더 가볍게'라는 느낌도 강하게 받을 수 있습니다.
주요 특징
- 단일 스토어와 훅 기반 API: 하나의 스토어를 생성하고, 이 스토어를 React 훅처럼 컴포넌트에서 직접 가져와 사용합니다. Context Provider로 컴포넌트를 감싸줄 필요가 없다는 점이 가장 큰 매력이죠.
- 직관적인 API: 상태를 정의하고 업데이트하는 방식이 매우 직관적이에요. Redux처럼 액션 타입, 리듀서, 미들웨어 등을 따로 정의할 필요가 없어서 학습 곡선이 매우 낮습니다.
- 성능 최적화: 상태 업데이트 시 필요한 컴포넌트만 리렌더링하도록 설계되어 뛰어난 성능을 보여줍니다. 내부적으로는 옵저버 패턴을 활용하여 효율적인 업데이트를 가능하게 하죠.
- 미들웨어 지원: Redux devtools, immer, persist 같은 유용한 미들웨어들을 간단하게 적용할 수 있습니다.
- 타입스크립트 완벽 지원: 타입스크립트와 함께 사용하기에 매우 편리하도록 설계되었습니다.
Zustand 사용 예시
import { create } from 'zustand';
// 1. 스토어 생성
interface CounterState {
count: number;
increase: (by: number) => void;
decrease: (by: number) => void;
reset: () => void;
}
const useCounterStore = create((set) => ({
count: 0,
increase: (by) => set((state) => ({ count: state.count + by })),
decrease: (by) => set((state) => ({ count: state.count - by })),
reset: () => set({ count: 0 }),
}));
// 2. 컴포넌트에서 스토어 사용
function CounterComponent() {
const { count, increase, decrease, reset } = useCounterStore(); // 필요한 상태와 함수만 선택적으로 가져올 수 있어요.
return (
<div>
<h1>Count: {count}</h1>
<button onClick={() => increase(1)}>+1</button>
<button onClick={() => decrease(1)}>-1</button>
<button onClick={reset}>Reset</button>
</div>
);
}
export default CounterComponent;
보시는 것처럼 `create` 함수로 스토어를 만들고, `set` 함수를 이용해 상태를 업데이트하는 방식이 정말 직관적이죠? 컴포넌트에서는 `useCounterStore()` 훅을 호출해서 필요한 상태와 액션을 가져다 쓰면 끝이에요. 특정 상태만 구독해서 불필요한 리렌더링을 줄일 수도 있습니다.
장점: 매우 작은 번들 사이즈(약 1KB), 제로 보일러플레이트, Context Provider 불필요, 빠른 성능, 쉬운 학습 곡선.
단점: 대규모 애플리케이션에서 상태 간의 복잡한 의존성 관리가 Redux처럼 명시적이지 않을 수 있음.
Jotai: 아톰 기반의 유연한 접근 방식
Jotai는 일본어로 '아톰'을 의미하는데, 라이브러리의 핵심 개념이 바로 이 아톰(Atom)입니다. 아톰은 독립적인 상태 조각을 의미하며, 이 아톰들을 조합하여 전체 애플리케이션의 상태를 구성하는 방식이에요. Recoil과 매우 유사한 아키텍처를 가지지만, 더 미니멀하고 유연한 API를 제공하는 것이 특징입니다.
주요 특징
- 아톰 기반 상태 관리: 상태를 아톰이라는 작은 단위로 쪼개어 관리합니다. 각 아톰은 독립적으로 존재하며, 필요에 따라 다른 아톰을 참조하거나 파생된 상태를 만들 수 있어요.
- 미니멀한 API: Recoil보다도 더 적은 API를 제공하며, `atom`과 `useAtom` 두 가지 핵심 훅으로 대부분의 상태 관리가 가능합니다.
- 렌더링 최적화: 아톰이 업데이트될 때, 해당 아톰을 구독하는 컴포넌트만 리렌더링되도록 설계되어 있습니다. 이는 리액트의 Context API보다 훨씬 효율적이죠.
- 타입스크립트 친화적: 강력한 타입 추론을 제공하여 타입스크립트와 함께 사용하기에 매우 편리합니다.
- No Context Provider: Recoil과 달리, Jotai는 별도의 Context Provider를 필요로 하지 않기 때문에, 어느 컴포넌트에서든 아톰을 사용할 수 있다는 장점이 있습니다. (정확히는 React Context를 사용하지만, 개발자가 직접 Provider로 감싸줄 필요가 없도록 내부적으로 처리합니다.)
Jotai 사용 예시
import { atom, useAtom } from 'jotai';
// 1. 아톰 정의
const countAtom = atom(0); // 기본적인 숫자 상태 아톰
const messageAtom = atom('Hello Jotai'); // 문자열 상태 아톰
// 파생된 상태 (Derived State) 아톰: 다른 아톰의 값을 기반으로 새로운 값을 계산
const doubledCountAtom = atom((get) => get(countAtom) * 2);
// 비동기 아톰: Promise를 반환하는 함수로 정의하여 비동기 데이터 로딩
const fetchDataAtom = atom(async (get) => {
// 실제 API 호출 로직
// const response = await fetch('/api/data');
// const data = await response.json();
// return data;
return new Promise(resolve => setTimeout(() => resolve('Async Data Loaded!'), 1000));
});
// 2. 컴포넌트에서 아톰 사용
function MyJotaiComponent() {
const [count, setCount] = useAtom(countAtom); // count 아톰을 사용 (useState와 유사)
const [message] = useAtom(messageAtom); // message 아톰 읽기 전용으로 사용
const [doubledCount] = useAtom(doubledCountAtom); // 파생된 상태 읽기
const [asyncData] = useAtom(fetchDataAtom); // 비동기 아톰 읽기
return (
<div>
<h1>Count: {count}</h1>
<button onClick={() => setCount(c => c + 1)}>Increase</button>
<button onClick={() => setCount(0)}>Reset</button>
<p>Message: {message}</p>
<p>Doubled Count: {doubledCount}</p>
<p>Async Data: {asyncData}</p>
</div>
);
}
export default MyJotaiComponent;
Jotai는 상태를 작은 조각인 아톰으로 나누어 관리하는 방식이 인상적이죠. `atom()` 함수로 상태를 정의하고, `useAtom()` 훅으로 컴포넌트에서 사용할 수 있습니다. 특히 다른 아톰을 기반으로 새로운 아톰을 만들거나, 비동기 데이터 fetching 로직을 아톰 내부에 포함시킬 수 있는 유연성이 돋보입니다.
장점: 매우 작은 번들 사이즈(약 2KB), 유연한 아톰 기반 아키텍처, 렌더링 최적화, Context Provider 불필요(개발자 관점), 뛰어난 타입스크립트 지원.
단점: 아톰의 개수가 많아질 경우 관리의 복잡성이 증가할 수 있음, Recoil 대비 커뮤니티 자료가 적을 수 있음.
Image by C1ri on Pixabay
Recoil: 리액트 친화적인 페이스북의 제안
Recoil은 페이스북(현 Meta)에서 개발한 리액트 상태 관리 라이브러리로, 리액트의 내부 동작과 완벽하게 통합되도록 설계되었습니다. 리액트의 Concurrent Mode와 같은 미래 지향적인 기능들과 잘 어울리도록 만들어진 것이 특징이죠.
주요 특징
- 아톰(Atom)과 셀렉터(Selector): Jotai와 마찬가지로 아톰이라는 독립적인 상태 단위를 사용합니다. 셀렉터는 이 아톰을 기반으로 파생된 상태를 계산하거나, 비동기 데이터를 가져오는 역할을 합니다. 이는 Redux의 `mapStateToProps`나 `reselect`와 유사한 기능을 제공하지만, 훨씬 더 리액트 친화적인 방식으로 구현되었습니다.
- 리액트 친화적 API: `useState`, `useCallback` 등 리액트 훅과 유사한 API를 제공하여 리액트 개발자에게 매우 익숙하게 느껴집니다.
- 선택적 구독: 특정 아톰이나 셀렉터에 대한 변경 사항이 있을 때만 해당 컴포넌트를 리렌더링하여 효율적인 업데이트를 가능하게 합니다.
- 동시성 모드 지원: 리액트의 Concurrent Mode와 Suspense를 완벽하게 지원하여, 비동기 데이터 로딩 시 UI 깜빡임 없이 부드러운 사용자 경험을 제공할 수 있습니다.
- 스냅샷 및 디버깅: Recoil은 스냅샷 기능을 제공하여 상태의 변화를 추적하고 디버깅하는 데 유용합니다. Recoil Devtools와 같은 도구를 활용하면 더욱 편리하죠.
Recoil 사용 예시
import React from 'react';
import {
atom,
selector,
useRecoilState,
useRecoilValue,
useSetRecoilState,
RecoilRoot // Recoil을 사용하려면 반드시 RecoilRoot로 감싸줘야 합니다.
} from 'recoil';
// 1. 아톰 정의
const counterState = atom({
key: 'counterState', // 고유한 키
default: 0,
});
// 2. 셀렉터 정의 (파생된 상태 또는 비동기 처리)
const doubledCounterSelector = selector({
key: 'doubledCounterSelector',
get: ({ get }) => {
const count = get(counterState);
return count * 2;
},
});
const asyncDataSelector = selector({
key: 'asyncDataSelector',
get: async ({ get }) => {
// 실제 비동기 데이터 로딩 로직
// const response = await fetch('/api/data');
// const data = await response.json();
// return data;
return new Promise(resolve => setTimeout(() => resolve('Recoil Async Data!'), 1500));
},
});
// 3. 컴포넌트에서 아톰/셀렉터 사용
function RecoilCounter() {
const [count, setCount] = useRecoilState(counterState); // 상태 읽기 및 쓰기
const doubledCount = useRecoilValue(doubledCounterSelector); // 상태 읽기 전용
const setCounter = useSetRecoilState(counterState); // 상태 쓰기 전용
return (
<div>
<h1>Count: {count}</h1>
<button onClick={() => setCount(c => c + 1)}>Increment</button>
<button onClick={() => setCounter(0)}>Reset</button>
<p>Doubled Count: {doubledCount}</p>
</div>
);
}
function AsyncDataLoader() {
const asyncData = useRecoilValue(asyncDataSelector); // 비동기 셀렉터 사용
return (
<div>
<h2>Async Data</h2>
<p>{asyncData}</p>
</div>
);
}
function App() {
return (
<RecoilRoot> {/* Recoil을 사용하는 모든 컴포넌트는 RecoilRoot 내부에 있어야 합니다. */}
<RecoilCounter />
<React.Suspense fallback={<div>Loading Async Data...</div>}>
<AsyncDataLoader />
</React.Suspense>
</RecoilRoot>
);
}
export default App;
Recoil은 `atom`과 `selector`라는 핵심 개념으로 상태를 관리합니다. 특히 `useRecoilState`, `useRecoilValue`, `useSetRecoilState` 등 용도에 따라 세분화된 훅을 제공하여 상태 접근 방식을 명확하게 할 수 있다는 장점이 있어요. 단, 모든 Recoil 관련 컴포넌트는 반드시 `RecoilRoot`로 감싸줘야 한다는 점을 기억해야 합니다. Jotai와는 달리 `RecoilRoot`가 필수적이죠.
장점: 리액트 내부 동작과의 깊은 통합, Concurrent Mode 및 Suspense 완벽 지원, 강력한 셀렉터 기능, 디버깅 도구 제공.
단점: Context Provider(RecoilRoot) 필요, 다른 경량 라이브러리에 비해 상대적으로 큰 번들 사이즈(약 10KB), 페이스북에서만 사용되는 기술이라는 인식이 있을 수 있음.
Zustand, Jotai, Recoil 핵심 비교: 한눈에 보기
세 라이브러리 모두 각자의 강점과 특징을 가지고 있는데요, 주요 기능들을 표로 비교해보면 어떤 차이가 있는지 좀 더 명확하게 파악할 수 있습니다.
| 특징 | Zustand | Jotai | Recoil |
|---|---|---|---|
| 핵심 개념 | 단일 스토어, 훅 기반 | 아톰(Atom) 기반 | 아톰(Atom) & 셀렉터(Selector) |
| Context Provider 필요 여부 | 필요 없음 | 개발자 관점에서는 필요 없음 (내부적으로 사용) | 필요함 (<RecoilRoot>) |
| 번들 사이즈 (압축 기준) | 약 1KB | 약 2KB | 약 10KB |
| 학습 곡선 | 매우 낮음 | 낮음 | 중간 (아톰/셀렉터 개념 이해 필요) |
| API 스타일 | 간결하고 함수형 | 미니멀하고 아톰 중심 | 리액트 훅과 유사 |
| 파생 상태 (Derived State) | 스토어 내 셀렉터 함수로 구현 | atom((get) => ...) |
selector (매우 강력) |
| 비동기 처리 | 내부적으로 Promise 관리 | atom(async (get) => ...) |
selector (Suspense와 통합) |
| 리액트 동시성 모드 지원 | 부분적 지원 (Suspense 통합 가능) | 완벽 지원 | 완벽 지원 |
| 개발 주체 | Poimandres (Redux 개발자 일부) | Daishi Kato (React-Query, React-Hook-Form 기여자) | Facebook (Meta) |
표를 보면 각 라이브러리가 지향하는 바가 명확하게 드러나죠? Zustand는 최소한의 노력으로 최대의 효과를 내는 데 집중하고, Jotai는 아톰을 통해 극강의 유연성과 미니멀리즘을 제공하며, Recoil은 리액트의 미래와 완벽하게 동기화된 경험을 목표로 합니다.
Image by wiggijo on Pixabay
그래서, 어떤 라이브러리를 선택해야 할까요? 선택 가이드
결국 "어떤 라이브러리가 가장 좋은가요?"라는 질문의 답은 "프로젝트의 특성과 팀의 상황에 따라 다르다"입니다. 하지만 각 라이브러리가 빛을 발하는 특정 시나리오들을 제시해 드릴 수는 있습니다. 여러분의 프로젝트에 가장 적합한 라이브러리를 선택하는 데 도움이 되길 바랍니다.
1. 프로젝트의 규모와 복잡성
- 작고 단순한 애플리케이션 또는 특정 컴포넌트 상태 관리: Zustand가 가장 좋은 선택일 수 있습니다. 학습 곡선이 낮고, 보일러플레이트가 거의 없어 빠르게 개발을 시작할 수 있어요. 번들 사이즈도 가장 작아서 가벼운 애플리케이션에 최적입니다.
- 중간 규모의 애플리케이션, 유연한 상태 구성이 필요할 때: Jotai 또는 Recoil을 고려해볼 만합니다. 아톰 기반의 접근 방식은 상태를 독립적인 단위로 관리하고 필요에 따라 조합할 수 있어 유연성이 높아요.
- 대규모 애플리케이션, 복잡한 비즈니스 로직, 리액트의 최신 기능을 적극 활용하고 싶을 때: Recoil이 강력한 후보입니다. 셀렉터를 통한 파생 상태 관리와 비동기 처리, 그리고 Concurrent Mode 및 Suspense와의 깊은 통합은 대규모 애플리케이션에서 발생할 수 있는 복잡성을 효과적으로 관리할 수 있도록 돕습니다.
2. 팀의 숙련도와 선호도
- 리액트 훅에 익숙하고, 새로운 개념 학습에 대한 부담을 줄이고 싶을 때: Zustand가 가장 친숙하게 느껴질 거예요. `useState`와 유사한 직관적인 API는 빠르게 적응할 수 있도록 돕습니다.
- 아톰 기반의 상태 관리에 관심이 있고, 미니멀한 API를 선호할 때: Jotai가 좋은 선택입니다. Recoil보다 API가 더 간결해서 빠르게 익힐 수 있습니다.
- 리액트의 최신 기능과 페이스북의 기술 스택에 익숙하거나, 안정성과 커뮤니티 지원을 중요하게 생각할 때: Recoil이 매력적일 수 있습니다. 페이스북이 개발하고 있어 리액트 생태계와의 호환성이 가장 높다고 볼 수 있죠.
3. 성능 및 번들 사이즈 요구사항
- 번들 사이즈가 매우 중요하고, 최소한의 오버헤드를 원할 때: Zustand가 압도적으로 유리합니다. 약 1KB라는 놀라운 크기는 성능에 민감한 애플리케이션에 큰 이점으로 작용하죠. Jotai도 약 2KB로 매우 가벼운 편입니다.
- 번들 사이즈보다는 리액트의 미래 기술과의 통합이 더 중요할 때: Recoil은 약 10KB로 다른 두 라이브러리보다는 크지만, 제공하는 기능과 리액트와의 깊은 통합을 고려하면 충분히 감수할 만한 수준입니다.
4. 특정 기능 요구사항
- Context Provider 없이 전역 상태를 쓰고 싶을 때: Zustand와 Jotai는 이 부분에서 큰 장점을 가집니다. 특히 Zustand는 정말 아무런 Provider 없이 스토어를 가져다 쓸 수 있죠.
- 비동기 데이터 로딩 및 Suspense 통합이 중요할 때: Recoil이 가장 강력한 기능을 제공합니다. 셀렉터를 통해 비동기 데이터를 효율적으로 관리하고 Suspense와 함께 매끄러운 사용자 경험을 구현할 수 있습니다. Jotai도 비동기 아톰을 지원하여 유사한 경험을 제공할 수 있습니다.
- Immutable 업데이트를 선호하고 싶을 때: 세 라이브러리 모두 `immer`와 같은 라이브러리와 함께 사용하기 편리합니다. 특히 Zustand는 미들웨어로 `immer`를 쉽게 통합할 수 있는 가이드가 잘 되어있습니다.
요약하자면,
- Zustand: 빠르고 가벼운, 최소한의 코드로 전역 상태를 관리하고 싶을 때. 미니멀리즘과 성능을 최우선으로 한다면 최고의 선택입니다.
- Jotai: 아톰 기반의 유연한 상태 관리와 미니멀한 API를 선호할 때. Recoil과 유사하지만 더 가볍고 자유로운 아키텍처를 원한다면 좋습니다.
- Recoil: 리액트의 미래 지향적인 기능(Concurrent Mode, Suspense)을 적극 활용하고, 아톰/셀렉터 기반의 강력한 상태 파생 로직이 필요할 때. 페이스북 기술 스택에 대한 신뢰도도 중요한 고려 요소가 될 수 있습니다.
마무리하며: 현명한 선택으로 더 나은 개발 경험을!
Zustand, Jotai, Recoil은 모두 리액트 상태 관리의 복잡성을 줄이고 개발 경험을 향상시키기 위해 등장한 훌륭한 라이브러리들입니다. 어떤 라이브러리가 다른 것보다 '절대적으로 좋다'고 말하기는 어려워요. 중요한 건 여러분의 프로젝트가 어떤 요구사항을 가지고 있는지, 팀원들의 숙련도는 어떤지, 그리고 어떤 아키텍처를 지향하는지에 따라 가장 적합한 도구를 선택하는 것이겠죠.
각 라이브러리의 장단점을 충분히 이해하고, 작은 토이 프로젝트나 개념 증명(PoC)을 통해 직접 경험해보는 것이 가장 현명한 방법이라고 생각합니다. 어떤 선택을 하시든, 이 글이 여러분의 리액트 상태 관리 여정에 작은 도움이 되었기를 바랍니다!
여러분은 어떤 경량 상태 관리 라이브러리를 사용하고 계신가요? 혹은 어떤 라이브러리에 가장 관심이 가시나요? 댓글로 여러분의 경험과 생각을 자유롭게 공유해주세요! 함께 더 나은 개발 문화를 만들어나가요!