Redux 기초 개념 소개

Redux는 여러 화면이 함께 사용하는 client state를 예측 가능한 규칙으로 관리하는 독립적인 JavaScript 라이브러리입니다.

React에서는 공식 바인딩인 React-Redux와 함께 자주 사용하지만 Redux 자체가 React에 종속되지는 않습니다.

Redux의 핵심은 애플리케이션의 모든 상태를 한곳에 밀어 넣는 것이 아니라, Redux가 관리하기로 정한 상태를 하나의 store와 action 기반 전이 경계에서 다루는 것입니다.

컴포넌트에만 필요한 UI state는 로컬 state로, 주소로 표현할 상태는 URL로, 서버에서 가져온 데이터는 적절한 loader나 cache로 관리할 수 있습니다.

Context와 useReducer도 유용하지만 Context는 Provider 하위에 값을 전달하는 범위이고 reducer는 다음 상태를 계산하는 함수입니다. 두 기능을 함께 쓰면 그 트리에서 state와 dispatch를 공유할 수 있지만, Redux식 외부 store 객체, middleware, DevTools action 기록, selector별 동등성 비교가 자동으로 생기지는 않습니다.

Zustand나 Jotai 같은 외부 store 선택지도 있으므로, Redux는 이름이나 앱 크기보다 필요한 소유권·구독·추적 계약으로 비교해야 합니다.

Redux는 왜 필요한가?

앱 규모만으로 Redux 사용 여부가 정해지지는 않습니다.

다음 신호가 함께 나타나고 action 기반 추적과 개발 도구의 이득이 추가 비용보다 클 때 Redux를 검토합니다.

• 공유 범위: 같은 client state를 서로 멀리 떨어진 여러 화면과 기능이 읽습니다.
• 갱신 빈도: 그 상태가 시간에 따라 자주 바뀝니다.
• 전이 복잡성: 여러 사건이 관련 필드와 불변 조건을 함께 바꿉니다.
• 협업과 관찰: 변경 이유를 action 단위로 추적하고 동일한 규칙을 팀이 공유할 가치가 큽니다.
• 확장 지점: 미들웨어, DevTools, 테스트 가능한 reducer 같은 표준 경계가 필요합니다.

Redux는 action을 dispatch하는 공통 입구를 제공하지만 action 이력을 자동으로 영구 저장하지는 않습니다.

Redux DevTools 연동이 활성화되고 Extension 같은 모니터가 연결됐거나 로깅 미들웨어를 구성했으며 state와 action을 관찰 가능한 직렬화 형태로 유지했을 때 action과 전후 state를 디버깅 증거로 확인할 수 있습니다.

Redux의 세 가지 핵심 원칙

Redux의 핵심 구성 요소

Redux의 데이터 흐름 (단방향)

Redux는 “무슨 일이 있었는가”와 “그 사건으로 상태가 어떻게 바뀌는가”를 한 방향으로 연결합니다.

이전 store snapshot: count = 0
dispatch({ type: "incremented" })
getState().count → 1
useSelector(s => s.count)
→ 선택 결과 변경

이전 store snapshot: count = 0
dispatch({ type: "incremented" })
getState().count → 1
useSelector(s => s.count)
→ 선택 결과 변경

비동기 작업과 부수 효과는 reducer 밖에서 수행한 뒤 필요한 action을 dispatch합니다.

Redux Toolkit과의 관계

Redux Toolkit은 현대 Redux 로직을 작성하는 공식 권장 경로입니다.

• configureStore: root reducer, 표준 middleware, 기본 활성화된 Redux DevTools 연동을 포함한 권장 store 설정을 제공하며 devTools 옵션으로 연동을 제어할 수 있습니다.
• createSlice: action type·creator와 case reducer를 함께 만들고 Immer 기반 불변 갱신을 간결하게 작성하게 합니다.
• createAsyncThunk: 사용자 정의 Promise 작업에 대해 pending, fulfilled, rejected 생명주기 action을 만들고 condition과 AbortSignal 기반 취소 지점을 제공합니다. 재시도·자동 중복 제거·cache 정책까지 제공하는 일반 서버 데이터 해법은 아닙니다.
• RTK Query: Redux 앱에서 client data fetching과 cache를 관리할 때 공식 문서가 기본 접근으로 가르치는 도구입니다. 요청 상태와 cache 무효화를 제공하며, 서버 렌더나 route loader가 소유하는 데이터는 해당 프레임워크 경계를 따릅니다.
• React-Redux: useSelector, useDispatch 등으로 React 컴포넌트를 store에 연결하는 별도 공식 패키지입니다.

서버 응답 · 요청 상태 · 캐시
→ RTK Query
사용자 정의 Promise 작업
→ createAsyncThunk

Store에 맡길 전이를 JavaScript로 먼저 계산하기

Redux를 연결하기 전에 순수 reducer 한 개의 계약을 읽어 보겠습니다. 다음은 장바구니 수량만 관리하는 작은 계산 예이며 Redux store나 React 구독을 직접 실행하는 코드는 아닙니다. cart/itemAdded의 quantity는 양의 정수로 이미 검증되어 들어온다고 가정합니다.

function cartReducer(state = { count: 0 }, action) {
  if (action.type === 'cart/itemAdded') {
    return { ...state, count: state.count + action.quantity };
  }
  return state;
}

const before = { count: 2 };
const after = cartReducer(before, {
  type: 'cart/itemAdded',
  quantity: 3,
});

console.log(before.count, after.count); // 2 5
console.log(before === after);         // false
console.log(cartReducer(after, { type: 'theme/changed' }) === after); // true

마지막 action은 이 reducer의 관심사가 아니므로 원 상태를 그대로 반환합니다. 여러 slice reducer가 같은 action을 받을 수 있는 Redux에서는 모르는 action에도 기존 state를 반환하고, undefined state에는 초기값을 반환하는 계약이 필요합니다. Redux의 초기화 설명에 따르면 store 생성 때 초기화 action도 reducer를 통과합니다. 앞 절의 React 카운터에서 선택한 “모르는 action이면 오류” 정책을 그대로 Redux root reducer에 복사하면 안 되는 이유입니다.

그 뒤 store가 새 snapshot을 저장했다고 생각하고 selector를 추적합니다. state => state.count의 이전 결과 2와 다음 결과 5는 다르므로 이 값을 구독하는 UI에 변경이 전달됩니다. action 문자열이 UI를 직접 고치는 것이 아니라, 계산 결과를 다시 선택한 값이 달라졌기 때문입니다.

상태 변경과 선택 결과 변경을 구별하기

store의 이전 state는 { count: 5, theme: 'light' }, 다음 state는 { count: 5, theme: 'dark' }라고 가정합니다. 두 컴포넌트의 selector는 각각 state => state.count와 state => ({ count: state.count })이고, 기본 === 비교를 사용합니다. 각 선택 결과는 같은 것으로 비교될까요? 이를 근거로 “두 컴포넌트는 어떤 경로로도 다시 렌더되지 않는다”라고 결론 낼 수도 있을까요?

이 장에서는 Redux가 관리하는 state의 단일 store, dispatch를 통한 읽기 전용 변경 경계, 순수 reducer, selector 기반 구독을 살펴보았습니다.

Redux는 규모가 큰 앱의 자동 정답이 아니며 local UI state, URL, server cache와 Redux client state의 소유권을 먼저 나눠야 합니다.

다음 절에서는 useReducer와 Context를 결합한 구조를 살펴보고, 컴포넌트 state owner·reducer 계산 책임·Provider 공급 범위와 외부 store의 차이를 비교합니다.