Dorong Dorong 💻😴

오늘은 제가 Context API에서 Zustand로 상태관리 도구를 전환하게 된 과정과 2024년 현재 리액트 상태관리 라이브러리들의 현황에 대해 이야기해보려 합니다.

1. Context API의 한계와 상태관리 라이브러리의 필요성

Context API로 시작한 이유

처음 알리니 프로젝트를 시작할 때는 Context API만으로 충분하다고 생각했습니다. 사용자 인증, 테마, 언어 설정 등 전역적으로 공유되어야 하는 상태들을 관리하는 데 Context API 만으로 충분했습니다.

// 초기 Context API 사용 예시
const PetContext = React.createContext<PetContextType | undefined>(undefined);

export const PetProvider: React.FC<PropsWithChildren> = ({ children }) => {
  const [petData, setPetData] = useState<PetData>({
    allergies: [],
    symptoms: [],
    foodLog: []
  });

  return (
    <PetContext.Provider value={{ petData, setPetData }}>
      {children}
    </PetContext.Provider>
  );
};

한계점 발견

하지만 프로젝트가 커지면서 여러 가지 한계점이 드러나기 시작했습니다:

• 불필요한 리렌더링: Context의 값이 변경될 때마다 해당 Context를 구독하는 모든 컴포넌트가 리렌더링되었습니다. 
• 코드 복잡도 증가: 여러 개의 Context를 중첩해서 사용하다 보니 Provider Hell이 발생했습니다.
• 상태 업데이트 로직 관리의 어려움: 비동기 작업과 복잡한 상태 업데이트 로직을 처리하는 데 한계가 있었습니다.

2. 주요 상태관리 라이브러리 비교 분석

Redux

Redux는 오랫동안 리액트 생태계의 표준과 같은 상태관리 라이브러리 입니다.

Redux의 핵심 개념

• Action: 상태 변경을 위한 이벤트를 설명하는 객체
• Reducer: Action을 받아 상태를 변경하는 순수 함수
• Store: 애플리케이션의 전체 상태를 보관하는 객체

Redux 미들웨어 생태계

• Redux Thunk: 비동기 작업을 처리하기 위한 가장 기본적인 미들웨어
• Redux Saga: 복잡한 비동기 흐름을 제어하기 위한 미들웨어
  • Generator 함수를 사용한 선언적 비동기 처리
  • 복잡한 시나리오(API 요청 취소, 재시도 등) 처리 가능
• Redux Toolkit: 보일러플레이트 코드를 줄이기 위한 공식 도구

그러나 Redux는 다음과 같은 단점이 있습니다:

• 많은 보일러플레이트 코드
• 학습 곡선이 가파름
• 작은 상태 변화에도 많은 코드 필요

Recoil

Facebook에서 만든 상태관리 라이브러리입니다.

장점

• React와의 높은 호환성
• 간단한 API (atom, selector)
• 비동기 데이터 처리가 쉬움

단점

• 아톰으로 관리되는 전역 상태를 어떤 컴포넌트라도 바로 아톰을 구독해서 업데이트를 받기에, 의존성이 여러 방향으로 엮이면서 예측하기 힘들어집니다.

Zustand

가볍고 직관적인 API를 제공하는 현대적인 상태관리 라이브러리입니다.

주요 특징

• 최소한의 보일러플레이트
• TypeScript 지원이 훌륭함
• Redux DevTools 지원
• 미들웨어 시스템 (persist, devtools 등)

예시 코드:

import create from 'zustand'

interface PetStore {
  symptoms: Symptom[]
  addSymptom: (symptom: Symptom) => void
  foodLogs: FoodLog[]
  addFoodLog: (log: FoodLog) => void
}

const usePetStore = create<PetStore>((set) => ({
  symptoms: [],
  addSymptom: (symptom) => set((state) => ({
    symptoms: [...state.symptoms, symptom]
  })),
  foodLogs: [],
  addFoodLog: (log) => set((state) => ({
    foodLogs: [...state.foodLogs, log]
  }))
}))

3. 실제 프로젝트에서의 선택: Zustand

알리니 프로젝트에서의 요구사항

1. 실시간 데이터 업데이트
2. 복잡한 상태 관리 (알레르기 증상, 음식 기록, 분석 데이터)
3. 성능 최적화
4. TypeScript 지원

Zustand 선택 이유

1. 간단한 설정과 사용법: 별도의 Provider 설정이 필요 없고, 직관적인 API를 제공합니다.
2. 성능 최적화: 필요한 상태만 구독하여 불필요한 리렌더링을 방지합니다.
3. TypeScript 지원: 타입 추론이 잘 동작하여 개발 생산성이 향상되었습니다.
4. 미들웨어 지원: persist 미들웨어를 통해 로컬 스토리지 연동이 쉬웠습니다.

Context API와의 조화

Context API와 Zustand를 함께 사용할 수 있습니다. 저는 다음과 같이 역할을 구분했습니다:

• Context API: 테마, 인증 등 애플리케이션의 전반적인 설정과 관련된 상태 관리 (단어 그대로 특정 맥락을 씌울때 사용했습니다.)
• Zustand: 비즈니스 로직과 관련된 복잡한 상태 관리

4. 결론

2024년 현재, 저는 다음과 같은 기준으로 상태관리 라이브러리를 선택했습니다:

1. 작은 프로젝트: Context API만으로도 충분
2. 중간 규모 프로젝트: Zustand
3. 대규모 프로젝트: Redux Toolkit 또는 Zustand

알리니와 같이 실시간 데이터 처리와 복잡한 상태 관리가 필요한 프로젝트에는 Zustand가 특히 적합했습니다. 코드가 간결하면서도 강력한 기능을 제공하며, 특히 TypeScript와의 호환성이 뛰어나 개발 경험이 매우 좋았습니다.