Redux는 왜 아직도 쓰이는가

 

 

 

Redux는 왜 아직도 쓰이는가

— 과설계처럼 보여도, 어떤 순간에는 대체제가 없는 이유

Zustand까지 이해했다면 이런 생각이 든다.

“이 정도면 Redux는 필요 없지 않나?”

대부분의 UI 중심 앱에서는 맞는 말이다.
그런데도 Redux는 여전히 쓰인다.
이유는 관성도, 유행도 아니다. 문제의 성질 때문이다.

---

1️⃣ Redux는 “상태 저장 도구”가 아니다

이 문장부터 고쳐야 한다.

❌ Redux = 전역 상태 관리 라이브러리
⭕ Redux = 상태 흐름을 설계하는 아키텍처

Redux가 강제하는 건 딱 세 가지다.

1. 상태는 하나의 트리다
2. 상태 변경은 액션으로만 일어난다
3. 변경 규칙은 순수 함수(reducer)로 정의된다

이 세 가지가 불편함의 원인이자,
Redux가 필요한 이유 그 자체다.

---

2️⃣ Redux가 빛나는 진짜 상황

🔥 상태 자체가 “비즈니스 로직”인 경우

다음 질문에 “그렇다”가 많을수록 Redux 쪽이다.

• 상태 변경 순서가 중요하다
• 과거 상태를 되돌려야 한다
• 누가 언제 무엇을 바꿨는지 기록이 필요하다
• 비동기 흐름이 복잡하다
• 팀원이 많고, 규칙이 필요하다

예를 들면 이런 도메인이다.

- 주문 / 결제 / 정산
- 승인 / 반려 / 재처리
- 재고 이동 / 취소 / 롤백
- 워크플로우 기반 화면

이때 상태는 단순 UI 편의가 아니다.
👉 업무의 진실 원본(source of truth) 이다.

---

3️⃣ “액션 → 리듀서”가 왜 중요한가

Redux의 가장 큰 장점은 이 구조다.

Action (의도)
  ↓
Reducer (규칙)
  ↓
New State (결과)

이 구조가 주는 것

• 상태 변경의 의도가 코드로 남는다
• 변경 규칙이 한 곳에 모인다
• 상태가 왜 이렇게 됐는지 설명 가능해진다

Zustand에서는 이렇게 쓸 수 있다.

set(state => ({ count: state.count + 1 }))

Redux에서는 이렇게 된다.

dispatch({ type: "INCREASE_COUNT" })

불편해 보이지만, 이 차이가 크다.

Redux는
“값을 바꾸는 코드”보다
“왜 바꾸는지”를 중요하게 여긴다

---

4️⃣ 디버깅에서 Redux는 독보적이다

Redux DevTools가 왜 아직도 강력한지 보자.

• 모든 상태 변경이 기록된다
• 액션 단위로 이동 가능 (time travel)
• “이 상태가 된 이유”를 되짚을 수 있다

이건 구조가 보장해주기 때문에 가능한 일이다.

Context / Zustand는:

• 자유롭다
• 빠르다
• 하지만 이력 추적은 선택 사항이다

Redux는:

• 느릴 수 있다
• 귀찮다
• 하지만 흐름을 강제한다

---

5️⃣ 그래서 Redux는 “조직 친화적”이다

Redux는 개인 개발자에게는 과하다.
하지만 팀이 커질수록 평가가 달라진다.

팀 관점에서 Redux가 주는 것

• 상태 변경 규칙의 표준화
• 코드 리뷰 포인트 명확
• 신규 인력 온보딩 쉬움
• “이 로직은 왜 여기 있지?”가 줄어듦

이건 성능 문제가 아니다.
👉 커뮤니케이션 비용 문제다.

---

6️⃣ Redux가 과설계가 되는 순간도 명확하다

아래에 해당하면 Redux는 독이다.

• 화면 한두 개짜리 앱
• 상태 변경 규칙 단순
• UI 상태 위주
• 빠른 실험이 목적

이런 곳에 Redux를 쓰면:

• 코드만 늘고
• 생산성은 떨어지고
• “왜 이렇게 복잡해?”만 남는다

---

7️⃣ 실무에서 쓰는 최종 선택 가이드

이 흐름으로 판단하면 거의 틀리지 않는다.

화면 한정 상태 → 로컬 / 페이지
전달만 필요 → Context
여러 화면 + UI 중심 → Zustand
상태 흐름이 도메인 → Redux

Redux는 마지막 카드다.
하지만 그 카드가 필요한 게임도 분명히 존재한다.

---

8️⃣ 이 문장 하나로 Redux를 정의하자

이 글의 결론은 이 문장이다.

Redux는
상태를 “편하게” 다루는 도구가 아니라
상태를 “틀리지 않게” 다루기 위한 도구다

그래서:

• 작을 땐 부담이고
• 클 땐 생명줄이 된다

---

다음 글 예고 (이제 마무리 단계)

다음 글에서는 이 시리즈를 묶는다.

👉 “React 상태 설계, 한 장으로 정리하기”

• 로컬 / 페이지 / 전역 판단 맵
• Context / Zustand / Redux 선택표
• 실무에서 가장 많이 터지는 설계 실수 TOP 5

여기까지 따라왔다면,
이제 전역 상태를 습관으로 쓰지 않게 된다.