상태 관리: Redux, Recoil, Zustand, 그리고...

상태 관리 논쟁은 라이브러리 이름만 바뀔 뿐 매년 반복됩니다. 하지만 실무에서 실패 원인은 도구 선택이 아니라 상태 분류 실패에 더 가깝습니다. 서버에서 받아오는 데이터, 화면 UI 상태, 폼 입력 상태를 한 저장소에 섞으면 어떤 라이브러리를 써도 복잡해집니다. 먼저 분류를 정리하면 도구 선택은 훨씬 단순해집니다.

저는 상태를 세 가지로 나눕니다. 서버 상태, 세션/전역 UI 상태, 화면 로컬 상태. 이 분리만 해도 전역 스토어가 필요 없는 영역이 크게 늘어납니다. 특히 API 응답 데이터를 전역 상태에 무조건 복사하는 패턴은 동기화 비용이 커서 운영 단계에서 버그를 만들기 쉽습니다.

1. 서버 상태와 UI 상태를 분리하라

서버 상태는 캐시, 재시도, 백그라운드 갱신이 핵심이므로 해당 역할에 맞는 도구를 쓰는 편이 좋습니다. 반면 UI 상태는 토글, 모달, 필터 패널처럼 즉시 반응이 중요하고 구조가 비교적 단순합니다. 둘을 같은 방식으로 다루면 한쪽 요구사항이 다른 쪽을 복잡하게 만듭니다.

실무에서는 "서버 상태 전용 계층"과 "클라이언트 UI 스토어"를 분리하는 구성이 가장 안정적이었습니다. 이 구조를 쓰면 디버깅 시 원인 범위를 빠르게 줄일 수 있고, 팀원 온보딩도 쉬워집니다.

2. 라이브러리보다 운영 규칙이 먼저

어떤 스토어를 쓰든 규칙이 없으면 금방 무너집니다. 예를 들어 누가 상태를 수정할 수 있는지, 비동기 처리는 어디서 하는지, 파생 상태를 어디에 두는지 같은 기준이 없으면 프로젝트가 커질수록 일관성이 사라집니다. 그래서 도입 초기에는 기술적 화려함보다 규칙 문서를 먼저 만드는 것이 효과적입니다.

권장 규칙은 간단합니다. 상태 소유자 명시, 변경 경로 단일화, 파생 계산은 셀렉터로 관리, 화면 컴포넌트에서 비즈니스 로직 최소화. 이 네 가지를 지키면 도구를 바꿔도 코드 구조를 유지하기 쉽습니다.

3. 팀 규모별 추천 접근

소규모 팀이라면 경량 스토어와 단순 패턴이 유리합니다. 도구 학습보다 기능 출시 속도가 중요하기 때문입니다. 반대로 대규모 팀은 엄격한 패턴과 리뷰 규칙이 필요합니다. 팀원이 많아질수록 자유도가 높은 도구는 일관성 비용을 크게 만듭니다.

핵심은 "우리 팀이 감당 가능한 복잡도"를 선택하는 것입니다. 미래 확장성을 이유로 과도한 아키텍처를 먼저 도입하면, 실제 기능 개발이 느려지고 리팩터링 부담이 커집니다.

4. 상태 관리 체크리스트

• 현재 상태를 서버/UI/로컬로 분리해 설명할 수 있는가
• 서버 응답 데이터를 전역 스토어에 중복 저장하고 있지 않은가
• 상태 수정 경로가 여러 곳으로 흩어져 있지 않은가
• 파생 상태 계산 로직이 컴포넌트마다 중복되지 않는가
• 신규 팀원이 상태 흐름을 문서만 보고 따라갈 수 있는가

결론적으로 상태 관리의 정답은 특정 라이브러리가 아니라 상태 경계를 명확히 하는 설계입니다. 도구는 바꿀 수 있어도 경계가 무너지면 팀 생산성은 빠르게 떨어집니다. 먼저 상태를 분리하고, 그다음 도구를 선택하세요.

5. 마이그레이션 전략

이미 전역 스토어가 커진 프로젝트라면 한 번에 갈아엎지 말고 도메인 단위로 분리하는 것이 안전합니다. 먼저 변경이 잦은 기능부터 상태 소유권을 재정의하고, 서버 상태는 전용 계층으로 이동합니다. 다음으로 컴포넌트에서 직접 상태를 수정하는 경로를 줄이고 액션/셀렉터 경유 규칙을 적용하면 회귀 버그가 크게 줄어듭니다. 마지막으로 문서와 코드 리뷰 체크리스트를 맞춰야 새 규칙이 유지됩니다. 상태 관리는 도구 교체보다 운영 규칙 정착이 성과를 더 빠르게 만듭니다.

6. 도입 실패를 줄이는 팁

가장 먼저 고쳐야 할 것은 기술 스택이 아니라 팀 합의입니다. 상태 변경 위치를 강제하지 않으면 어떤 도구를 써도 코드가 다시 흩어집니다. 스프린트 초기에 "이번 주 상태 구조에서 반드시 지킬 규칙 1개"를 정해 점진적으로 강화하면 저항이 적고 정착 속도가 빠릅니다. 작은 규칙이라도 반복하면 구조는 안정화됩니다.

실전에서는 규칙을 크게 만들기보다 작게 시작하는 편이 좋습니다. 작은 규칙을 지키는 팀이 결국 큰 구조도 안정적으로 운영합니다.