상태 트랙 - Zustand, React Context
백엔드 전환자가 프론트에서 상태 공유의 경계를 정리할 때 보는 큰그림입니다.
React를 다루다 보면 상태가 어디에 있어야 할지부터 헷갈립니다.
이전에는 서버의 단일 소스에서 내려오는 데이터 중심으로 설계했지만,
프론트엔드에서는 같은 화면 안에서도 상태의 성격이 달라집니다.
이 문서는 Zustand와 React Context를 도입할 때 필요한 큰 기준을 정리합니다.
프론트엔드에서 상태가 어려운 이유
백엔드에서의 상태는 보통 “요청이 끝나면 값이 바뀌는 것”으로 수렴합니다.
프론트에서는 그 안에 서로 다른 종류의 상태가 섞입니다.
- 화면에서 즉시 바뀌는 값(입력값, 토글, 포커스)
- 서버 응답으로 얻는 값(목록, 상세 정보, 인증 결과)
- 화면 이동 전후를 넘어야 하는 값(사용자 세션, 접근권한)
섞인 상태를 하나로만 관리하면 갱신 기준이 뒤섞여,
디버깅 시 “어떤 경로에서 바뀌었는지”가 잘 안 보입니다.
라이브러리가 해결하는 큰 문제
1) 전역 전파의 비용
상위에서 아래로 props를 너무 깊게 전달하면 코드가 늘어나고 추적성이 떨어집니다.
상태를 어디서, 누구와 공유할지 정하지 않으면 “전역이든 지역이든 결국 난잡”해집니다.
Context는 하위 트리에 값과 함수를 전달하는 형태로,
컴포넌트 트리에서 의존해야 할 값을 명시적으로 주입하는 방식에 가깝습니다.
Zustand는 필요한 화면 구간에서 상태를 모아 공유하는 데 유리합니다.
특히 라우트별로 동일한 값이 필요할 때 공유 범위를 빠르게 맞추기 쉽지만,
공유 범위를 넓혀 남용하면 상태가 멀리 퍼져 변경 경로가 추적하기 어려워질 수 있습니다.
2) 렌더 경계가 흐려지는 문제
모든 값이 거의 항상 리렌더를 유발하면 화면이 잦고 큰 규모로 다시 계산될 수 있습니다.
상태를 성격별로 나누면 렌더 경로가 줄어들고, 상태 변화 추적이 쉬워집니다.
핵심은 공유 위치의 의도를 정하는 것입니다.
- UI 임시 상태는 좁은 범위로
- 데이터 캐시/도메인 상태는 공유 기준이 있는 곳으로
3) 컴포넌트 간 의존성의 난이도
컴포넌트가 단순히 값을 받기만 하는지, 직접 상태를 바꾸는지 구분되지 않으면
상태 트랙의 목표는 이 의존성을 분해하는 것입니다.
값을 공유할지, 계산해 내려보낼지, 혹은 이벤트로만 주고받을지 구분해야 합니다.
백엔드 사고로 보는 상태 구분법
백엔드 전환자에게 가장 익숙한 기준을 그대로 쓰면 정리가 빨라집니다.
- 트랜잭션 기반 값: 서버에서 바뀌는 값
- 화면 오퍼레이션 값: 사용자 인터랙션에서 즉시 변하는 값
- 세션/권한 값: 화면 전환에 따라 유지되어야 하는 값
이 기준을 먼저 정하면, 어디에서 상태를 읽고 누가 바꿔야 하는지가 한 번에 보입니다.
정리
Zustand와 React Context는 “상태를 어떻게 공유할 것인가”에 대한 서로 다른 레벨의 선택지입니다.
둘 다 맞는 도구이지만, 해결하려는 문제는 같습니다.
- props 전달이 과한가?
- 공유 기준이 모호한가?
- 공유 범위가 화면 단위인지 화면 외부인지?
상태 트랙은 이 3가지를 먼저 정리해주는 출발점입니다.