props drilling이 싫어서 Redux를 꺼냈다고요?
최근 velog에 올라온 「Redux로 전역 상태 관리하기」 포스트를 읽다가 멈칫했습니다. createSlice, configureStore, Provider 래핑, useSelector와 useDispatch — 익숙한 보일러플레이트가 예제 코드 네 파일에 걸쳐 펼쳐져 있었거든요. 글 자체의 품질은 나쁘지 않습니다. Redux Toolkit(RTK) 기본 흐름을 빠르게 익히기엔 좋은 튜토리얼이에요. 문제는 2025년에 이 글이 '전역 상태 관리의 대표적인 방법'으로 읽힌다는 사실 그 자체입니다.
해당 예제의 핵심 상태는 activeButton과 title, 단 두 개의 문자열입니다. 사용자 입장에서는 탭 버튼 세 개를 누르면 제목이 바뀌는 — 솔직히 말하면 useState 하나와 콜백 한 줄이면 끝나는 인터랙션이에요. 그런데 이걸 위해 store 파일을 만들고, slice를 정의하고, Provider로 감싸고, selector를 작성하는 과정이 정말 필요했을까요?
맥락: Redux가 '기본값'이 된 역사적 관성
Redux가 React 생태계를 지배했던 건 2016~2019년, Context API가 불안정하고 훅(Hooks)이 없던 시절의 이야기입니다. 그 시절엔 prop을 5단계 이상 내려야 하는 순간 Redux가 거의 유일한 선택지였죠. RTK가 2019년에 등장하면서 보일러플레이트를 줄여줬지만, 근본적인 구조 — 단일 store, reducer 등록, dispatch 액션 — 는 그대로입니다.
2025년 현재, 상태 관리 지형은 완전히 달라졌습니다. Zustand는 보일러플레이트 없이 create 한 줄로 store를 만들고, 컴포넌트에서 훅처럼 꺼내 씁니다. Jotai는 atom 단위로 상태를 쪼개서 리렌더 범위를 원자적으로 제어하고요. React 자체의 useContext + useReducer 조합도 중소 규모에선 충분합니다. 심지어 React 19의 use 훅과 Server Components 패러다임에서는 서버 상태와 클라이언트 상태의 경계가 무너지면서 "전역 상태"라는 개념 자체를 다시 질문해야 합니다.
실무에서 마주치는 '과잉 설계'의 비용
사실 이건 px 단위로 봐야 하는 문제가 아니라 번들 사이즈 단위로 봐야 하는 문제입니다. @reduxjs/toolkit + react-redux의 minified 번들은 약 11kB(gzip)입니다. Zustand는 약 1.1kB. 열 배 차이예요. Lighthouse 퍼포먼스 점수에 민감한 프로젝트라면, 탭 두 개 전환하려고 11kB를 태우는 건 Core Web Vitals 관점에서도 아까운 트레이드오프입니다.
더 큰 비용은 인지 부하입니다. 주니어 개발자가 프로젝트에 합류했을 때, store.js → communitySlice.js → Provider 래핑 → useSelector/useDispatch 네 단계를 이해해야 탭 전환 로직을 수정할 수 있습니다. Zustand로 같은 기능을 구현하면 파일 하나, 줄 수 열다섯 줄 이내입니다. 코드 리뷰 시간, 온보딩 비용, 디버깅 시 DevTools에서 액션 히스토리를 뒤지는 시간 — 이 모든 게 상태 두 개에 대한 오버헤드입니다.
그래서 Redux는 언제 쓰라는 건가요?
Redux가 빛나는 순간은 분명히 있습니다. 복잡한 비동기 워크플로우(RTK Query), 시간 여행 디버깅이 필수인 에디터류 앱, 수십 개 이상의 slice가 교차 참조되는 대규모 엔터프라이즈 앱 — 이런 케이스에서 Redux의 엄격한 단방향 흐름과 미들웨어 아키텍처는 여전히 강력합니다. 하지만 대부분의 프로젝트는 이 규모에 도달하지 않아요.
기획자가 "이 상태를 전역으로 관리해 주세요"라고 말할 때, 개발자가 첫 번째로 해야 할 질문은 "이 상태가 정말 전역이어야 하나요?"입니다. 디자인 시스템의 테마(다크 모드), 인증 토큰, 국제화 로케일 — 이런 건 진짜 전역입니다. 하지만 특정 페이지의 탭 활성 상태? 그건 해당 페이지 컴포넌트의 로컬 상태로 충분합니다.
전망: 상태 관리는 '도구 선택'이 아니라 '설계 판단'이다
2025년 프론트엔드에서 상태 관리 라이브러리 선택은 기술 스택 결정이 아니라 아키텍처 설계 판단입니다. 서버 상태는 TanStack Query(React Query)에, 전역 클라이언트 상태는 Zustand나 Jotai에, 폼 상태는 React Hook Form에, 나머지는 useState에 — 이렇게 관심사별로 분리하는 게 2025년형 프론트엔드의 현실적인 정답에 가깝습니다.
Figma에서 볼 때는 같은 화면인데, 상태 설계가 다르면 유지보수 난이도가 완전히 달라집니다. 여기서 로딩 스켈레톤 하나 넣으려고 했더니 Redux 미들웨어부터 건드려야 하는 상황 — 다들 한 번쯤 겪어보셨잖아요. 도구가 문제를 풀어주는 게 아니라, 문제의 크기에 맞는 도구를 고르는 것. 사실 이게 시니어와 주니어를 가르는 가장 조용한 기준선이 아닐까 싶습니다.