Zustand 글은 여러 개 있지만 각 글을 어떤 순서로 읽어야 하는지 정리되지 않으면 store와 action, selector가 따로 노는 개념처럼 보입니다.
Zustand는 store 하나부터 시작하면 덜 헷갈립니다
Zustand를 처음 볼 때는 전역 상태 관리라는 말보다 store 하나를 컴포넌트 밖에 두는 구조로 보는 편이 이해가 빠릅니다. 카운터 값, 로그인 사용자 정보, 장바구니 수량처럼 여러 컴포넌트가 같이 보는 값이 생기면 props로 계속 넘기기보다 별도 저장소가 필요해집니다. 이때 가장 작은 출발점이 store입니다. Zustand가 왜 필요한지 감을 잡고 싶다면 Zustand란 무엇인가와 Zustand를 사용하는 이유를 먼저 보면 좋습니다.
state를 읽은 다음에는 action으로 변경 기준을 나눕니다
store를 만들었다면 다음 문제는 값을 어디에서 바꿀지입니다. 컴포넌트 안에서 set 함수를 직접 부를 수도 있지만, 변경 규칙이 늘어나면 action으로 묶는 편이 유지보수에 유리합니다. 예를 들어 장바구니에 상품을 추가할 때 수량 증가, 중복 상품 처리, 총액 계산이 같이 움직인다면 이 로직은 컴포넌트보다 store action에 두는 것이 자연스럽습니다. 기본 store 구조는 Zustand 설치와 기본 Store 만들기, 값 변경은 Zustand State 읽기와 변경하기로 이어서 보면 됩니다.
const useCartStore = create((set) => ({
items: [],
addItem: (item) => set((state) => ({
items: [...state.items, item],
})),
}));selector는 성능 최적화보다 구독 범위를 줄이는 기준입니다
selector를 너무 어렵게 볼 필요는 없습니다. 컴포넌트가 store 전체를 보는 대신 필요한 값만 골라 보는 방식입니다. 화면에 username만 필요한데 cartItems까지 같이 구독하면 관련 없는 변경에도 리렌더링을 의심하게 됩니다. selector는 이런 구독 범위를 줄이는 기준으로 보면 됩니다. 처음부터 모든 컴포넌트에 selector를 과하게 넣기보다, store가 커지고 리렌더링 이유가 헷갈리는 지점에서 적용하면 충분합니다.
persist는 저장할 값과 저장하지 않을 값을 나누는 단계입니다
persist는 새로고침 후에도 상태를 유지하게 해주지만, 모든 상태를 저장 대상으로 넣으면 문제가 생깁니다. 모달 열림 여부처럼 순간적인 UI 상태는 새로고침 뒤에도 남을 필요가 없습니다. 반대로 테마, 사용자 설정, 임시 장바구니처럼 유지되어야 하는 값은 persist와 잘 맞습니다. 저장 대상의 기준을 먼저 나눈 뒤 Zustand persist로 새로고침 후에도 상태 저장하기를 보면 실제 코드가 더 선명하게 들어옵니다.
추천 순서는 store에서 persist까지 한 번에 이어집니다
처음에는 Zustand를 쓰는 이유, 기본 store, state 읽기와 변경, action 분리 순서로 보는 것이 좋습니다. 그 다음 selector로 필요한 상태만 구독하는 기준을 보고, 마지막에 persist로 유지할 값을 고릅니다. TypeScript 타입 지정이나 리렌더링 문제는 이 기본 흐름을 잡은 뒤에 보는 편이 덜 흔들립니다.
작성 전에 한 번 더 확인할 기준
이 주제는 개별 개념보다 실제 사용 순서를 기준으로 읽을 때 더 잘 이해됩니다. 처음에는 작은 예시 하나로 시작하고, 그 예시에서 어떤 값이 움직이는지, 어떤 설정이 필요한지, 어디에서 오류가 날 수 있는지 차례대로 확인하는 방식이 좋습니다.
작성 전에 한 번 더 확인할 기준
이 주제는 개별 개념보다 실제 사용 순서를 기준으로 읽을 때 더 잘 이해됩니다. 처음에는 작은 예시 하나로 시작하고, 그 예시에서 어떤 값이 움직이는지, 어떤 설정이 필요한지, 어디에서 오류가 날 수 있는지 차례대로 확인하는 방식이 좋습니다.
마지막에는 독자가 바로 적용할 기준을 남깁니다
Zustand 학습 순서: store, action, selector, persist까지을 읽는 독자는 단순한 정의보다 “그래서 지금 내 코드에서는 무엇을 먼저 확인해야 하는가”를 알고 싶어 합니다. 그래서 글을 작성할 때는 개념을 설명한 뒤 바로 판단 질문으로 이어지는 흐름이 필요합니다. 이 값은 어디에서 만들어졌는지, 어느 컴포넌트나 페이지가 책임지는지, 배포나 빌드 뒤에도 같은 방식으로 동작하는지처럼 실제 작업에서 바로 확인할 수 있는 질문을 남겨야 합니다.
또 하나 중요한 기준은 기존 글과의 거리입니다. 이미 자세히 다룬 문법이나 오류 해결 절차를 다시 길게 반복하면 새 글의 역할이 흐려집니다. 이 글은 독자가 흩어진 글을 어떤 순서로 읽을지 알려주는 입구이거나, 서로 다른 개념을 연결하는 브릿지여야 합니다. 세부 구현은 관련 글로 넘기고, 현재 글에서는 왜 그 글을 그 시점에 읽어야 하는지 설명하는 것이 더 좋습니다.
실제 작성 과정에서는 예시를 하나 정해 끝까지 밀고 가는 편이 자연스럽습니다. 카드 UI, 블로그 상세 페이지, 장바구니 상태, 코딩테스트 입력 배열처럼 작은 상황 하나를 잡고 설명하면 개념이 공중에 뜨지 않습니다. 독자가 자신의 코드에 대입할 수 있는 기준이 생기면, 글은 단순 요약이 아니라 다음 작업을 결정하는 안내문 역할을 하게 됩니다.
마지막 정리는 “무엇을 외울 것인가”보다 “무엇부터 확인할 것인가”로 끝내는 것이 좋습니다. 처음 볼 파일, 먼저 나눌 상태, 우선 점검할 설정, 다음에 읽을 기존 글을 짧게 안내하면 독자가 바로 움직일 수 있습니다. 이런 마무리가 있어야 허브 글과 브릿지 글이 기존 글을 반복하지 않고도 충분한 가치를 가집니다.
발행 전에는 중복과 연결 흐름을 한 번 더 봅니다
이 글은 단독으로 읽혀도 의미가 있어야 하지만, 동시에 기존 글로 독자를 보내는 안내 역할도 해야 합니다. 그래서 발행 전에는 제목이 기존 글과 너무 비슷하지 않은지, 본문에서 이미 발행된 글의 설명을 그대로 반복하지 않았는지, 내부 링크가 실제 다음 행동으로 이어지는지 확인합니다.
특히 허브 글은 자세한 구현보다 순서와 판단 기준이 더 중요합니다. 독자가 글을 다 읽은 뒤 어떤 기존 글을 먼저 열어야 하는지, 어떤 문제를 만나면 어떤 체크리스트로 이동해야 하는지 알 수 있어야 합니다. 이 기준이 분명하면 비슷한 주제의 글이 많아도 서로 경쟁하지 않고 블로그 안에서 길을 만들어줍니다.
읽는 순서를 정하면 글도 덜 흩어집니다
Zustand 학습 순서: store, action, selector, persist까지의 핵심은 모든 개념을 한 번에 외우는 것이 아니라, 실제 작업에서 마주치는 순서대로 판단 기준을 세우는 데 있습니다. 먼저 작은 화면이나 문제 하나를 기준으로 시작하고, 필요한 순간에 다음 글로 넘어가면 학습 흐름이 끊기지 않습니다.
“Zustand 학습 순서: store, action, selector, persist까지”에 대한 7개의 생각