React 전역 상태 선택 가이드

Context · Redux · Custom Store 비교: 상태 관리가 아니라 “복잡도 관리”의 문제

React에서 상태 관리 도구 선택은 기능 문제가 아니다.
복잡도를 어디에 두고, 어떻게 통제할 것인가에 대한 선택이다.

Context, Redux, Custom Store는 모두 “상태를 공유”할 수 있다.
하지만 공유 비용, 변경 영향 범위, 추적 가능성이 전혀 다르다.

---

Prop Drilling의 본질: “귀찮음”이 아니라 “구조적 신호”

개념

Prop Drilling은 상태를 실제로 사용하는 컴포넌트까지 도달하기 위해
중간 컴포넌트들이 의미 없는 전달자 역할만 수행하는 구조다.

App
 └─ Layout
     └─ Sidebar
         └─ Menu
             └─ MenuItem (실제 사용)

왜 중요한가

Prop Drilling 자체는 버그가 아니다. 문제는 이것이 상태 위치가 잘못되었다는 신호라는 점이다.

• 중간 컴포넌트는 해당 상태에 관심이 없다
• 하지만 구조 때문에 강제로 결합된다
• 변경 영향 범위가 불필요하게 커진다

언제 문제가 되는가

• 전달 경로가 길어질수록 props 변경이 광범위한 렌더를 유발
• 중간 컴포넌트 리팩토링이 어려워짐
• “이 props가 왜 여기 있지?”라는 질문이 반복됨

→ 이 지점에서 Context 또는 전역 상태 도구를 검토하게 된다.

---

Context API: “전역 상태”가 아니라 “트리 범위 공유”

개념

Context는 React 트리 내부에서 값을 직접 주입하는 메커니즘이다.

<MyContext.Provider value={value}>
  <Child />
</MyContext.Provider>

왜 중요한가

Context는 Prop Drilling을 구조적으로 제거한다.

• 중간 컴포넌트는 props 전달에서 해방
• 상태 소비자는 필요한 곳에서 직접 접근
• 트리 범위(scope)가 명확하다

이 때문에 Context는 다음에 적합하다.

• 테마
• 인증 정보
• 언어 설정
• 앱 전반 설정 값

Context API의 한계

1) 변경 단위가 거칠다

Context 값이 바뀌면 그 Context를 구독하는 모든 컴포넌트가 렌더된다.

• 일부 값만 바뀌어도 전체 소비자 재렌더
• 성능 최적화 난이도 상승

2) 상태 로직이 커지면 가독성 급락

Context + useState/useReducer 조합은:

• 작은 앱에서는 깔끔
• 규모가 커지면 “암묵적 전역 로직”이 된다

3) 디버깅 도구 부재

• 상태 변경 흐름 추적이 어렵다
• 언제, 왜 바뀌었는지 로그 기반 추적 필요

언제 문제가 되는가

• Context 값이 자주 바뀐다
• 여러 종류의 상태가 한 Context에 섞인다
• “사실상 전역 상태”처럼 쓰이기 시작한다

---

Redux: “상태 공유 도구”가 아니라 “변경 관리 시스템”

개념

Redux는 단순히 상태를 전역에 둔다기보다, 상태 변경을 명시적 이벤트(action)로 강제한다.

Action → Reducer → New State → Subscribers

왜 중요한가

Redux의 핵심 가치는 이것이다.

• 상태 변경이 항상 명시적
• 변경 경로가 단일하고 추적 가능
• 사이드 이펙트 관리가 구조화됨

이건 기능이 아니라 통제력이다.

Redux가 필요한 순간

다음 중 2개 이상이면 Redux 후보:

• 상태 변경 경로가 많다
• “어디서 바뀌었는지” 추적이 어렵다
• 비동기 로직이 복잡하다
• 여러 화면/기능이 같은 상태를 강하게 공유한다
• 상태 변경에 대한 규칙/정책이 중요하다

언제 문제가 되는가

• 단순 UI 상태까지 Redux로 끌어올림
• 액션/슬라이스가 과도하게 늘어남
• “보일러플레이트가 많다”는 불만이 구조 설계 문제를 가린다

Redux는 복잡할 때만 값어치를 한다.

---

Custom Store: “도메인에 맞춘 최소 전역화”

개념

Custom Store는 Context + Hook + 내부 상태 관리 로직을 조합해 프로젝트에 맞는 전역 상태를 직접 설계하는 방식이다.

useStore() → subscribe / update

왜 중요한가

• Redux보다 가볍다
• Context보다 통제력이 있다
• 도메인 특화 로직을 담기 좋다

특히 다음 상황에서 유효하다.

• Redux까지는 과하다
• 하지만 Context 단순 공유로는 부족하다
• 특정 도메인 상태만 전역화하고 싶다

언제 문제가 되는가

• 표준이 없다 → 팀 합의 필요
• 디버깅/DevTools 부재
• 설계자가 빠지면 유지보수 난이도 급상승

Custom Store는 팀 역량 의존도가 매우 높다.

---

전역 상태의 위험성: “편의성의 대가”

개념

전역 상태는 접근이 쉽다. 하지만 그만큼 결합도도 즉시 증가한다.

왜 위험한가

• 어느 컴포넌트든 접근 가능
• 변경 영향 범위 예측 어려움
• 테스트 시 격리 난이도 상승

특히 흔한 문제:

• “일단 전역에 둔다”
• “나중에 분리하자” → 거의 분리되지 않는다

원칙

전역 상태는 최후의 수단이지 기본값이 아니다.

---

기술 선택 기준 요약

상태 관리 도구는 이렇게 선택한다

상황	적합한 선택
단순 공유, 변경 적음	Context
복잡한 변경 흐름, 추적 중요	Redux
중간 복잡도, 도메인 특화	Custom Store
단일 컴포넌트 내부	Local State

결정 질문 체크리스트

• 이 상태는 누가 소유해야 하는가?
• 변경 경로를 추적할 필요가 있는가?
• 변경 빈도와 영향 범위는?
• 팀이 감당할 복잡도 수준은?

---

정리: 상태 관리 도구는 “확장성의 보험”이다

• Prop Drilling은 구조 신호
• Context는 트리 범위 공유
• Redux는 변경 통제 시스템
• Custom Store는 맞춤형 절충안
• 전역 상태는 편하지만 위험하다

한 문장으로 요약하면:

상태 관리 도구 선택은 기능 문제가 아니라, 복잡도를 어디에 둘지에 대한 결정이다.

---

• 참고: React 완벽 가이드 2025 with React Router & Redux