같은 reducer인데, 왜 매번 헷갈릴까
프론트엔드 개발자라면 한 번쯤 이런 순간이 있습니다. PR 리뷰에서 "이거 useReducer로 충분한데 왜 Redux 붙였어요?"라는 코멘트가 달리거나, 반대로 Context + useReducer 조합이 세 컴포넌트를 넘어가면서 props drilling 지옥이 열리는 순간. dev.to에 올라온 Aneeqa Khan의 useReducer or Redux Reducer? 글이 다시 화제가 된 건, 2026년에도 이 경계선이 여전히 모호하기 때문입니다.
원문의 핵심은 간결합니다. 둘 다 (state, action) => newState라는 동일한 순수 함수 DNA를 공유하지만, useReducer는 컴포넌트 로컬, Redux는 글로벌 스토어라는 거주지가 다르다는 것. 원문은 이걸 '자전거 vs 버스'로 비유했는데, 솔직히 말하면 이 비유가 너무 깔끔해서 오히려 위험합니다. 실제 프로젝트에서는 자전거로 출발했다가 중간에 버스로 갈아타야 하는 상황이 훨씬 많거든요.
진짜 기준은 '상태의 반경'입니다
사용자 입장에서 생각해볼게요. 모달 안의 폼 상태 — step 1, 2, 3을 오가며 입력값을 누적하는 경우 — 이건 useReducer가 완벽한 영역입니다. useState를 네다섯 개 늘어놓는 것보다 하나의 reducer에서 NEXT_STEP, SET_FIELD, RESET 같은 액션으로 관리하면 상태 전이가 예측 가능해지죠. 여기서 Redux를 꺼내는 건 솔직히 과잉 엔지니어링입니다.
그런데 문제는 그 모달의 결과가 대시보드 전체의 리스트를 갱신해야 하고, 동시에 사이드바의 뱃지 카운트도 바뀌어야 하는 순간입니다. useReducer + Context로 끌고 가면 어떻게 되냐면, Context의 value가 바뀔 때마다 해당 Context를 구독하는 모든 하위 컴포넌트가 리렌더링됩니다. React.memo로 막아보겠다고 발버둥 치지만, 사용자 입장에서는 리스트 스크롤할 때 미세하게 끊기는 그 16ms의 프레임 드롭을 느낍니다. Lighthouse 퍼포먼스 점수가 5점 빠지는 건 덤이고요.
Redux Toolkit(RTK)의 createSlice는 이 지점에서 빛을 발합니다. selector의 메모이제이션, 미들웨어를 통한 사이드이펙트 분리, 그리고 Redux DevTools의 타임트래블 디버깅. 특히 상태가 세 개 이상의 독립된 컴포넌트 트리에 영향을 미치는 순간, 글로벌 스토어의 정당성이 생깁니다. 기획자가 "이 필터 바뀌면 저쪽 차트도 바뀌어야 해요"라고 말하는 순간, 그게 Redux의 입장권입니다.
도구 선택은 설계 문제이고, 설계는 협업 문제입니다
여기서 시야를 넓혀보면, 상태관리 도구 선택은 결국 팀의 컴포넌트 아키텍처 설계 역량에 달려 있습니다. dev.to의 또 다른 사례를 보면, Next.js 프로젝트에 Shadcn 스타일의 CLI 기반 블로그 자동화 라이브러리를 만들어 20시간 작업을 5분으로 줄인 사례가 있는데, 핵심은 Organization ID 하나로 상태(콘텐츠)의 스코프를 명확히 정의한 것이었습니다. 상태의 경계를 먼저 그리고, 그다음에 도구를 골랐다는 점이 인상적이에요.
Figma 중심의 디자인 협업도 같은 맥락입니다. velog의 디자인 도구 정리 글에서 Figma가 강조된 이유는 실시간 협업과 컴포넌트 라이브러리의 일관성인데, 이걸 개발로 번역하면 Design Token → 컴포넌트 props → 상태 구조로 이어지는 파이프라인의 문제입니다. Figma Dev Mode에서 넘어온 컴포넌트 스펙이 로컬 상태로 충분한지, 글로벌 테마 상태와 연결되어야 하는지 — 이 판단을 디자이너와 개발자가 같이 해야 합니다. 혼자 결정하면 나중에 1px이 아니라 아키텍처 단위로 어긋나요.
2026년의 선택 기준: Zustand도 있고, Jotai도 있지만
솔직히 말하면, 2026년에 useReducer vs Redux 만 고민하고 있다면 선택지를 좁게 보고 있는 겁니다. Zustand는 보일러플레이트 없이 글로벌 상태를 다루고, Jotai는 atom 단위로 상태를 쪼개며, TanStack Query(구 React Query)는 서버 상태를 아예 별도 레이어로 분리합니다. 하지만 이 모든 도구의 선택 기준은 결국 하나로 수렴합니다: 이 상태는 어디서 태어나고, 어디까지 살아야 하는가?
컴포넌트 안에서 태어나고 그 안에서 죽는 상태 → useState 또는 useReducer. 형제·사촌 컴포넌트까지 퍼져야 하지만 페이지를 벗어나지 않는 상태 → Zustand나 Jotai. 앱 전역에서 살아야 하고 미들웨어·디버깅·타임트래블이 필요한 상태 → Redux Toolkit. 서버에서 온 데이터이고 캐싱·무효화가 핵심인 상태 → TanStack Query. 이 네 줄이 2026년 상태관리 의사결정 트리의 거의 전부입니다.
결국 도구를 고르는 건 기술 문제가 아니라 설계 문제이고, 설계는 "이 상태의 생명주기가 어디까지인가"를 기획 단계에서 정의하는 것에서 시작합니다. useReducer와 Redux가 같은 DNA를 가졌다는 원문의 지적은 정확합니다. 하지만 DNA가 같다고 적재적소가 같은 건 아니에요. 사용자가 버튼을 누르는 그 0.3초 안에 상태가 어떤 경로로 흘러서 어떤 컴포넌트를 깨우는지 — 그 흐름도를 먼저 그리세요. 도구는 그다음입니다.