오늘은 프론트엔드 개발할 때 가장 많이 고민하는 주제인 React 상태관리에 대해 이야기해볼게. 9년 동안 실무에서 수많은 프로젝트를 거치며 다양한 상태관리 라이브러리를 써봤는데, 여전히 많은 후배들이 "무조건 Redux를 배워야 하나요?" 혹은 "요즘 대세는 Zustand라는데 그것만 쓰면 되나요?" 같은 질문을 하더라고. 결론부터 말하자면 정답은 없고, 프로젝트의 규모와 팀의 상황에 맞는 '적정 기술'을 선택하는 게 핵심이야.
1. 가볍고 강력한 대세, Zustand로 시작해봐
최근 실무에서 가장 선호도가 높은 라이브러리를 꼽으라면 단연 Zustand야. 예전에는 상태관리를 하려면 보일러플레이트 코드를 엄청나게 작성해야 했지만, Zustand는 정말 심플하게 상태를 정의하고 사용할 수 있거든.
- 장점: 설정이 극도로 간결하고, 패키지 크기가 매우 작아서 번들 사이즈에 영향이 거의 없어.
useState를 쓰는 것처럼 직관적이면서도, 불필요한 리렌더링을 방지하는 셀렉터 기능을 기본으로 제공하지. - 실무 팁: 중소규모 프로젝트나 빠르게 MVP(최소 기능 제품)를 만들어야 할 때 Zustand만큼 효율적인 도구는 없어. Context API의 리렌더링 이슈를 피하고 싶을 때 가장 먼저 고려해봐.
2. 세밀한 상태 제어가 필요하다면 아토믹 패턴의 Jotai
Zustand가 전역 스토어 중심이라면, Jotai는 아주 작은 상태 단위인 '아톰(Atom)'을 조립해서 사용하는 아토믹(Atomic) 패턴을 따르고 있어.
- 장점: 상태를 아주 잘게 쪼갤 수 있어서, 특정 컴포넌트가 필요한 아주 미세한 상태 변화에만 반응하도록 설계하기 쉬워. 리렌더링 최적화가 자동으로 이루어지는 셈이지.
- 실무 팁: 대시보드처럼 화면 곳곳에서 서로 연관된 미세한 값들이 실시간으로 변하고, 각 컴포넌트의 독립성이 중요할 때 Jotai를 도입하면 복잡한 상태 의존성을 깔끔하게 해결할 수 있어.
3. 대형 프로젝트와 레거시의 제왕, Redux Toolkit
여전히 많은 대기업이나 대형 프로젝트에서는 Redux와 이를 개선한 **Redux Toolkit(RTK)**을 사용하고 있어. 예전에 비해 점유율이 낮아졌다고는 하지만, 여전히 실무에서 무시할 수 없는 거인이지.
- 장점: 엄격한 규칙과 단방향 데이터 흐름 덕분에, 수십 명의 개발자가 협업하는 대규모 프로젝트에서 상태가 어떻게 변경되는지 추적하기가 매우 유리해. 강력한 개발자 도구(Redux DevTools)도 큰 강점이야.
- 실무 팁: 이미 구축된 대형 서비스나, 상태 변화의 흐름을 엄격하게 관리하고 디버깅해야 하는 금융권/엔터프라이즈급 프로젝트라면 Redux Toolkit을 사용하는 것이 유지보수 관점에서 훨씬 안전해.
4. 기본기로 충분할 땐 Context API
외부 라이브러리를 설치하기 전에 React가 기본으로 제공하는 Context API로 해결할 수 없는지 먼저 고민해봐야 해.
- 장점: 추가적인 라이브러리 설치가 필요 없고, React 자체 기능이라 러닝 커브가 없어.
- 실무 팁: 다크모드 설정, 유저 로그인 세션 정보, 다국어 설정처럼 자주 바뀌지 않고 애플리케이션 전반에 공유되어야 하는 '정적인 데이터'를 전달할 때는 Context API가 가장 깔끔한 선택이야. 빈번하게 바뀌는 상태에 쓰면 하위 컴포넌트 전체가 리렌더링되니 주의하고!
💡 핵심 정리
- Zustand: 빠르고 직관적인 상태관리가 필요할 때 (현재 실무 트렌드 1순위)
- Jotai: 미세한 단위의 상태 제어와 최적화가 중요할 때
- Redux Toolkit: 대규모 협업 프로젝트와 엄격한 아키텍처가 필요할 때
- Context API: 거의 변하지 않는 전역 설정을 가볍게 공유할 때 9년 차 개발자로서 조언하자면, 트렌디한 라이브러리를 쫓아가기 전에 각 도구가 해결하고자 하는 페인 포인트(Pain Point)가 무엇인지 먼저 파악하길 바래. 지금 담당하는 프로젝트의 규모, 팀원들의 숙련도, 그리고 데이터가 얼마나 자주 바뀌는지를 종합적으로 고려해서 최적의 도구를 선택하는 눈을 기르는 게 진짜 시니어 개발자로 가는 지름길이란다.