전역 상태관리 도구들 비교와 분석 정리 3.Zustand

 

스타트업에서 MVP를 만드는 알바를 할 때 정해진 스택이 있었다.

 

TypeScript, Next.js, 그리고 Zustand.

 

그 당시 세 가지를 모두 처음 사용해본 터라 부랴부랴 검색해가며 공부와 개발을 병행했던 기억이 있다.

 

시키니까 일단 사용은 하는데... 사실 잘 이해하지 못하고 주도해주셨던 프론트 팀장님 말 듣고 사용하라는 데로 사용하기만 한 기억이 있다.

 

그래서 스타트업에 특화 된 어떤 장점이 있으니까 사용했을 거라는 생각이 들어 미리 좀 알아보고자 한다.

 

---

 

 

Zustand 바로가기

Zustand

 

내가 생각하는 Zustand의 가장 큰 장점은 로고가 귀엽다 .. 다른 상태 관리 도구들은 너무 공대틱한 느낌이 심한데 갑자기 곰돌이가 있어서 큐티한 느낌이 난다.

 

홈페이지에 들어가봐도 큐티한 곰돌이 월페이퍼에 어떻게 코드를 작성하는 지 간단한 카운터 예시가 들어가 있다.

 

코드를 보고 어떻게 사용하는 지 한 번 분석해 봤다.

 

import { create } from 'zustand'

const useStore = create((set) => ({
  count: 1,
  inc: () => set((state) => ({ count: state.count + 1 })),
}))

function Counter() {
  const { count, inc } = useStore()
  return (
    <div>
      <span>{count}</span>
      <button onClick={inc}>one up</button>
    </div>
  )
}

 

 

zustand에서 create를 import합니다

 

그리고 useStore라는 함수를 만들어 create 전역 스토어를 설정합니다

 

기본 상태 count의 초기값을 1로 정의하고, inc 액션 함수를 정의합니다

 

set 함수를 사용하여 현재 상태인 1을 업데이트하네요

 

카운터 컴포넌트는 위에서 만든 useStore 함수를 호출해 count와 inc 함수를 가져오네요

 

그리고 그 상태인 count를 화면에 표시합니다

 

onClick에는 useStore에서 만든 inc 함수를 넣을 수 있네요

 

이것으로 간략하게 어떻게 Zustand가 돌아가는 지 이해 했습니다

 

 

---

 

Zustand는 작고 빠르며 React 프로젝트에서 사용하는 상태관리 라이브러리입니다.

 

아래는 간략하게 정리한 Zustand의 특징들입니다.

 

1. 사용하기 쉬운 API이다

Zustand의 API는 매우 간단하고 직관적이다. 복잡한 설정이 필요 없으며 create 함수를 통해 상태와 상태 변경 함수를 쉽게 정의할 수 있습니다. 또한, 전역 상태와 로컬 상태를 분리하거나 다양한 상태를 혼합해서 사용할 수 있는 유연성을 제공합니다.

 

2. 최소한의 러닝커브를 가진다

다른 상태 관리 라이브러리와 비교해 상태 정의와 구성이 쉬워 비용이 적게 듭니다.

 

3. 선택적으로 구독할 수 있다

특정 상태에만 구독할 수 있는 기능을 제공합니다. 즉, 컴포넌트는 필요한 상태 부분만 구독하여 렌더링 성능을 최적화할 수 있으며, 상태가 변경될 때마다 전체 컴포넌트가 리렌더링되지 않도록 방지합니다.

 

4. 비동기 로직에 대한 간편한 지원

비동기 함수나 동기화가 필요한 상태 관리도 쉽게 지원합니다. useStore 훅을 통해 간단하게 비동기 작업을 정의할 수 있으며, Redux의 Middleward와 유사한 기능도 포함되어 있어 복잡한 비동기 로직을 쉽게 관리할 수 있습니다.

 

5. Context API와의 통합이 필요 없음

Zustand는 React의 Context API를 사용하지 않으므로, 성능상의 이점을 누릴 수 있습니다. 상태를 전역적으로 사용할 때 Context API의 단점을 피하면서도 상태에 직접 접근할 수 있는 구조입니다.

 

6. 크기와 성능

Zustand는 가볍고 빠르며, 특히 웹이나 모바일 애플리케이션에서 사용하기가 적합합니다. 크기가 작은 만큼 로딩 속도가 빠르고, 상태 변경 시 최적화 된 구독 구조 덕분에 불필요한 리렌더링이 발생하지 않아 성능에 큰 이점을 줍니다.

 

 

이렇게 언뜻 보면 다른 상태 관리 도구들과 함께 옵션에 있는 경우에도 Zustand를 선택해야 하는 이유를 딱 찾지는 못하겠네요 ..

 

 

 

그럼 얘를 왜 써요..?

 

 

---

 

빠르고 가벼운 전역 상태 관리가 필요한 컴포넌트 기반 애플리케이션
비동기 API 데이터를 효율적으로 캐싱하고 필요한 곳에만 제공해야하는 경우
Context API의 한계를 경험하며 단순하지만 유연한 전역 상태 관리가 필요한 경우
다수의 독립적인 상태 관리가 필요한 복잡한 구조의 프로젝트

 

Zustand는 가벼운 API와 성능 최적화 덕분에 간단한 전역 상태 관리를 빠르고 효율적으로 제공합니다. 특히, 상태를 컴포넌트 간에 빠르고 공유할 수 있으며 React Context의 단점인 전체 리렌더링을 피해 필요한 부분에만 상태를 제공하는 선택적 구독을 할 수 있습니다.

 

결론적으로 Zustand의 핵심 키워드는 선택적 구독이라는 생각이 드는데요. 리액트를 공부하면서 코드 최적화를 통해 전체 리렌더링을 줄이는 방법을 공부한 적이 있기 때문에 zustand가 얼마나 효율적일 지 궁금하기도 합니다. 

 

하지만 Recoil도 atom과 selector 단위로 상태를 관리하기 때문에 선택적 구독이 가능해 익숙한 Recoil에 더 손이 많이 갈 것 같다는 생각을 합니다. 두 방식에 약간의 차이는 있다고 합니다.

 

- Recoil은 상태 의존성 그래프를 생성하여 상태를 세밀하게 구독하고 업데이트를 전달합니다.

 

- Zustand는 선택적 구독과 독립적인 스토어 개념을 사용해, 상태를 단순하게 관리하면서도 필요한 컴포넌트에만 상태를 전달하는 방식으로 성능을 최적화합니다.

 

사실 지난 번 Recoil을 공부할 때 다크모드/라이트모드 등을 예시로 들었었는데 단순 가벼운 전역 상태 관리를 위한 도구로는 zustand가 더 어울린다는 상황이 드네요.

Recoil은 그보다는 조금 더 복잡한 여러 개를 선택하는 필터 옵션, 정렬 옵션 등에 더 어울리는 것 같습니다.

 

 

상황에 맞는 상태 관리 쓰기!! 중요 체크체크