React state vs Zustand: 언제 전역 상태가 필요할까

state가 많아졌다고 바로 Zustand를 쓰거나, 여러 컴포넌트가 공유하는 값을 계속 props로 넘기면서 구조가 복잡해지는 경우가 생깁니다.

state가 많다는 이유만으로 전역 상태가 필요한 것은 아닙니다

React 컴포넌트 안에 가 몇 개 늘어나면 상태관리 도구를 써야 하나 고민하게 됩니다. 하지만 state 개수보다 중요한 것은 그 상태를 누가 쓰는지입니다. 버튼 하나의 열림 여부, 입력 폼의 임시 값, 카드 컴포넌트 안에서만 쓰는 선택 상태라면 로 충분합니다. 반대로 여러 화면이나 멀리 떨어진 컴포넌트가 같은 값을 보고 바꿔야 한다면 전역 상태를 검토할 때입니다.

useState는 가까운 화면 상태에 잘 맞습니다

모달 내부 입력값, 드롭다운 열림 여부, 탭 선택처럼 특정 컴포넌트 주변에서 끝나는 값은 가 가장 단순합니다. 이 값을 전역 store로 옮기면 오히려 수정 위치가 멀어집니다. React state의 기본 감각이 약하다면 React useState 사용법을 먼저 확인하는 것이 좋습니다. state는 값을 저장하는 문법이 아니라 화면 업데이트를 만드는 신호라는 점을 잡아야 합니다.

function ProductCard({ name, price }) { const [count, setCount] = useState(1); return ( <article className="product-card"> <h3>{name}</h3> <p>{price * count}원</p> <button onClick={() => setCount(count + 1)}>수량 추가</button> </article> );
}

props drilling은 도구보다 구조 신호로 봅니다

부모에서 자식, 손자, 더 아래 컴포넌트까지 같은 값을 계속 넘기면 props drilling이 생깁니다. 이때 무조건 Zustand로 옮기기 전에 컴포넌트 구조를 먼저 볼 필요가 있습니다. 상태를 더 가까운 부모로 옮기면 해결되는지, Context로 충분한지, 정말 여러 독립 영역에서 공유하는 값인지 확인합니다. 장바구니 수량이나 로그인 사용자 정보처럼 앱 여러 곳에서 동시에 쓰는 값이라면 전역 store가 자연스럽습니다.

Zustand는 공유 UI 상태를 작게 분리할 때 잘 맞습니다

Zustand는 store를 작게 만들고 필요한 컴포넌트에서 꺼내 쓰는 방식이 단순합니다. 여러 컴포넌트가 공유하는 필터, 사용자 설정, 장바구니 상태처럼 클라이언트 안에서 원본이 정해지는 값과 잘 맞습니다. 기본 구조는 Zustand란 무엇인가도입 기준은 Zustand를 사용하는 이유를 같이 보면 좋습니다.

서버 상태까지 Zustand에 넣지는 않습니다

API에서 가져온 상품 목록이나 게시글 상세는 서버 상태입니다. 이런 데이터는 캐시, 재요청만료 시간에러 처리 기준이 필요하므로 TanStack Query 같은 도구가 더 잘 맞습니다. Zustand는 화면 안의 UI 상태와 사용자가 조작하는 클라이언트 상태에 집중시키는 편이 역할이 선명합니다. 값의 원본이 서버인지, 브라우저 안의 UI 판단인지 먼저 나눠보면, Zustand, TanStack Query의 경계가 훨씬 명확해집니다.

실제로 나눌 때는 값의 이동 거리를 봅니다

컴포넌트 안에서만 쓰는 값은 가까운 곳에 두는 것이 읽기 쉽습니다. 예를 들어 입력 폼의 임시 값이나 드롭다운 열림 여부는 다른 화면이 알 필요가 없습니다. 이런 값을 전역 store로 옮기면 수정할 파일이 멀어지고, 나중에 어떤 화면에서 값이 바뀌는지 추적하기 어려워집니다.

반대로 여러 컴포넌트가 같은 값을 기준으로 동시에 움직이면 이야기가 달라집니다. 헤더의 장바구니 개수, 상품 목록의 필터로그인 사용자 정보처럼 화면의 여러 지점이 같은 상태를 공유한다면 props로 계속 전달하는 구조가 금방 무거워집니다. 이때 Zustand 같은 store를 쓰면 값의 위치가 분명해지고, 필요한 컴포넌트만 상태를 구독하게 만들 수 있습니다.

작성할 때는 “이 값이 한 컴포넌트 안에서 끝나는가”, “형제나 멀리 떨어진 컴포넌트가 같이 쓰는가”, “새로고침 후에도 유지되어야 하는가”를 순서대로 확인하면 됩니다. 이 세 질문만 통과해도, Zustand, persist 중 어디에 둘지 대부분 판단할 수 있습니다.

마지막에는 독자가 바로 적용할 기준을 남깁니다

React state vs Zustand: 언제 전역 상태가 필요할까을 읽는 독자는 단순한 정의보다 “그래서 지금 내 코드에서는 무엇을 먼저 확인해야 하는가”를 알고 싶어 합니다. 그래서 글을 작성할 때는 개념을 설명한 뒤 바로 판단 질문으로 이어지는 흐름이 필요합니다. 이 값은 어디에서 만들어졌는지, 어느 컴포넌트나 페이지가 책임지는지, 배포나 빌드 뒤에도 같은 방식으로 동작하는지처럼 실제 작업에서 바로 확인할 수 있는 질문을 남겨야 합니다.

또 하나 중요한 기준은 기존 글과의 거리입니다. 이미 자세히 다룬 문법이나 오류 해결 절차를 다시 길게 반복하면 새 글의 역할이 흐려집니다. 이 글은 독자가 흩어진 글을 어떤 순서로 읽을지 알려주는 입구이거나, 서로 다른 개념을 연결하는 브릿지여야 합니다. 세부 구현은 관련 글로 넘기고, 현재 글에서는 왜 그 글을 그 시점에 읽어야 하는지 설명하는 것이 더 좋습니다.

실제 작성 과정에서는 예시를 하나 정해 끝까지 밀고 가는 편이 자연스럽습니다. 카드 UI, 블로그 상세 페이지, 장바구니 상태, 코딩테스트 입력 배열처럼 작은 상황 하나를 잡고 설명하면 개념이 공중에 뜨지 않습니다. 독자가 자신의 코드에 대입할 수 있는 기준이 생기면, 글은 단순 요약이 아니라 다음 작업을 결정하는 안내문 역할을 하게 됩니다.

마지막 정리는 “무엇을 외울 것인가”보다 “무엇부터 확인할 것인가”로 끝내는 것이 좋습니다. 처음 볼 파일, 먼저 나눌 상태, 우선 점검할 설정, 다음에 읽을 기존 글을 짧게 안내하면 독자가 바로 움직일 수 있습니다. 이런 마무리가 있어야 허브 글과 브릿지 글이 기존 글을 반복하지 않고도 충분한 가치를 가집니다.

읽는 순서를 정하면 글도 덜 흩어집니다

React state vs Zustand: 언제 전역 상태가 필요할까의 핵심은 모든 개념을 한 번에 외우는 것이 아니라, 실제 작업에서 마주치는 순서대로 판단 기준을 세우는 데 있습니다. 먼저 작은 화면이나 문제 하나를 기준으로 시작하고, 필요한 순간에 다음 글로 넘어가면 학습 흐름이 끊기지 않습니다.