🎧

원문

https://tkdodo.eu/blog/deriving-client-state-from-server-state

휴가에서 막 돌아왔는데, Zustand를 사용할 때 가장 큰 트레이드오프에 대한 Reddit 질문을 보게 되었다.
코드는 대략 이렇다(최신 문법으로 조금 수정하고, 커스텀 훅 안에 넣었다).

Manual-sync

const useSelectedUser = () => {
  const { data: users } = useQuery({
    queryKey: ['users'],
    queryFn: fetchUsers,
  })
  const { selectedUserId, setSelectedUserId } = useUserStore()

  // If the selected user gets deleted from the server,
  // Zustand won't automatically clear selectedUserId
  // You have to manually handle this:
  useEffect(() => {
    if (!users?.some((u) => u.id === selectedUserId)) {
      setSelectedUserId(null) // Manual sync required
    }
  }, [users, selectedUserId])

  return [selectedUserId, selectedUserId]
}

물론, useEffect—특히 그 안에서 setState를 호출하는 경우—를 볼 때마다 나는 더 나은 해결책이 없을까 생각하게 된다.
내 경험상, 거의 항상 더 나은 방법이 존재하며, 보통 그 방법을 찾는 것이 가치 있는 일이다.
그러니 한 걸음 물러서서 우리가 먼저 무엇을 달성하고 싶은지를 먼저 살펴보자.

상태 동기화 유지하기 (Keeping State in Sync)

간단히 말하면, 우리는 클라이언트 상태(Client State)인 selectedUserId를 서버 상태(Server State)인 사용자 목록(users)과 동기화하고 싶다.
이것은 당연한 일이다.

예를 들어, useQuery를 통해 백그라운드에서 다시 데이터를 가져왔는데, 사용자가 목록에서 삭제되었음에도 여전히 상태에 저장되어 있다면, 그 선택은 유효하지 않다.

클라이언트 상태(Client State)

이 접근 방식은 Zustand에만 국한된 것이 아니다.
useUserStore()를 단순히 로컬 상태로 바꿔도 똑같이 적용할 수 있다:

const [selectedUserId, setSelectedUserId] = useState()

또는 URL 상태(nuqs 같은)를 사용해도 된다:

const [selectedUserId, setSelectedUserId] = useQueryState('userId')

중요한 건 상태가 어디에 저장되느냐가 아니라,
서버 상태(Server State)가 바뀔 때 업데이트해야 하는 클라이언트 상태(Client State)라는 점이다.

const useSelectedUser = () => {
  const { data: users } = useQuery({
    queryKey: ['users'],
    queryFn: fetchUsers,
  })
  const { selectedUserId, setSelectedUserId } = useUserStore()

  const selectedId = users?.some((u) => u.id === selectedUserId)
    ? selectedUserId
    : null

  return [selectedId, setSelectedUserId]
}

이 코드는 매우 간단하다.
스토어 값을 직접 업데이트하는 대신, Selection 자체는 그대로 두고,
서버 상태(Server State)에서 더 이상 해당 id를 찾을 수 없는 경우 커스텀 훅에서 다른 값을 반환하도록 한다.

즉, useSelectedUser()를 호출하는 곳에서는 이전처럼 null을 받게 된다.

그리고 스토어를 건드리지 않기 때문에 추가적인 이점도 있다:

• 사용자가 다시 목록에 추가되면, 선택(selection)이 자동으로 복원된다.
• UX 요구사항이 바뀌어 선택을 제거하고 싶지 않고, 단지 선택이 유효하지 않음을 시각적으로 표시하고 싶을 때도 가능하다.
  → 원래 값을 항상 유지하기 때문에 쉽게 구현할 수 있다.

isSelectionValid

const useSelectedUser = () => {
  const { data: users } = useQuery({
    queryKey: ['users'],
    queryFn: fetchUsers,
  })
  const { selectedUserId, setSelectedUserId } = useUserStore()
  const isSelectionValid = users?.some((u) => u.id === selectedUserId)

  return [selectedUserId, setSelectedUserId, isSelectionValid]
}

함정은 어디에 있을까요?

"상태 파생 솔루션"의 명백한 단점 중 하나는 사용자 저장소에 저장된 내용을 더 이상 "신뢰"할 수 없다는 것입니다. useUserStore에서 다른 곳의 selectedUserId를 읽어오면 추가 검사를 받지 못하므로 항상 사용자 정의 hook에서 읽어야 합니다.

저는 저장소를 최종 검증된 값의 소스라기보다는 UI에서 실제로 선택된 항목의 기록으로 보기 때문에 이 점에 대해서는 전혀 문제가 없습니다.

또, Reddit 질문에서 Redux Toolkit이 “이 문제를 해결한다”고 언급했지만, 실제로 크게 다르지 않을 것이다.
보통 API 슬라이스와 사용자 선택 슬라이스를 읽어 두 값을 결합하는 selector를 작성하게 되는데,
이것이 바로 우리가 커스텀 훅에서 하고 있는 방식과 동일하다.

오히려 이 방식은 상태를 파생(derive)하도록 유도하므로, 좋은 접근입니다.

다른 예시

서버 상태(Server State)가 바뀌어도 클라이언트 상태(Client State)를 업데이트하지 않는 개념은 여러 경우에 유용하다.
흔한 예시는 서버에서 가져온 기본값으로 폼을 미리 채울 때(prefilling forms)이다.

default-value-effect

function UserSelection() {
  const { data: users } = useQuery({
    queryKey: ['users'],
    queryFn: fetchUsers,
  })
  const [selection, setSelection] = useState()

  // use the first value as default selection
  useEffect(() => {
    if (users?.[0]) {
      setSelection(users[0])
    }
  }, [users])

  // return markup
}

이 효과는 장황할 뿐만 아니라, 쿼리에서 새 데이터가 들어올 때 현재 선택 항목을 덮어쓰는 버그도 있습니다. 🐛

이 문제는 다른 검사를 추가하면 쉽게 해결할 수 있지만, 더 나은 해결책은 여전히 ​​상태를 파생하는 것입니다.

derived-default-value

function UserSelection() {
  const { data: users } = useQuery({
    queryKey: ['users'],
    queryFn: fetchUsers,
  })
  const [selection, setSelection] = useState()

  const derivedSelection = selection ?? users?.[0]

  // return markup
}

지금 우리가 해야 할 일은 selection 대신 derivedSelection을 계속 사용하는 것뿐이며, 그렇게 하면 항상 원하는 값을 얻을 수 있습니다. 🚀

프론트엔드 애플리케이션을 개발하다 보면, 컴포넌트 간 상태를 공유하고 변경 사항을 일관성 있게 반영하는 것이 중요한 과제가 된다.

이를 위해 다양한 상태관리 라이브러리가 존재하며, 대표적으로 Redux, Recoil, MobX 등이 있다. 최근에는 보다 단순하고 가벼운 접근 방식을 제공하는 Zustand가 주목받고 있다.

1. Zustand란 무엇인가

https://zustand-demo.pmnd.rs/

Zustand의 공식문서이다.
공식문서에 따르면,

작고, 빠르며 확장 가능한 최소한의 상태 관리 솔루션입니다.
Zustand는 훅(Hooks)에 기반한 편안한 API를 제공합니다. 보일러플레이트 코드가 많거나 특정한 의견(opinion)에 치우치지 않지만, 명시적이고 Flux와 유사한 구조를 유지할 수 있는 충분한 규칙을 가지고 있습니다.

귀엽다고 무시하지 마세요. 발톱이 있습니다!
많은 시간을 들여 흔히 겪는 문제들을 해결했습니다. 예를 들어, 악명 높은 좀비 자식(zombie child) 문제, React의 동시성(concurrency), 서로 다른 렌더러 간의 컨텍스트 손실(context loss) 등을 다룹니다.
React 생태계에서 이러한 모든 문제를 올바르게 처리하는 거의 유일한 상태 관리 라이브러리일지도 모릅니다.

라고 한다.

✔️종합해보면

1. Zustand는 핵심 기능만 제공하는 가벼운 상태 관리 라이브러리

2. Redux처럼 복잡한 설정이나 파일 구조 없이도 쓸 수 있고, 프로젝트 규모가 커져도 무리 없이 확장할 수 있다는 장점

3. React의 useState, useEffect 같은 방식으로 쉽게 사용할 수 있다는 의미

4. 복잡한 action, reducer, dispatch 같은 개념을 강제로 쓰게 하지 않아서 진입 장벽이 낮음

5. 특정 패턴을 강제하지 않지만, Flux 아키텍처처럼 데이터 흐름이 단방향이라 구조가 명확합니다.

6. 좀비 자식 문제(zombie child problem)
→ 상태가 업데이트됐는데 이미 언마운트된 컴포넌트가 옛 데이터를 참조하는 버그를 의미합니다.

7. React 동시성(Concurrency)
→ React 18의 concurrent mode에서도 상태 관리가 안전하게 동작하도록 설계됨.

8. 컨텍스트 손실(Context loss)
→ React Native, Web, Three.js 같이 렌더러가 혼합된 환경에서도 상태를 안전하게 공유 가능.

요약: Zustand는 단순하지만 깊이 있는 상태 관리 라이브러리이고, React에서 발생하는 까다로운 버그 상황도 대부분 해결해주는 거의 유일한 선택지이다

2. 기본사용방법

import { create } from 'zustand'

const useStore = create((set) => ({
  bears: 0,
  increasePopulation: () => set((state) => ({ bears: state.bears + 1 })),
  removeAllBears: () => set({ bears: 0 }),
  updateBears: (newBears) => set({ bears: newBears }),
}))

function BearCounter() {
  const bears = useStore((state) => state.bears)
  return <h1>{bears} bears around here...</h1>
}

function Controls() {
  const increasePopulation = useStore((state) => state.increasePopulation)
  return <button onClick={increasePopulation}>one up</button>
}

1. create()
• Zustand 스토어를 만드는 최초 함수.
• 인자로 전달하는 함수 안에서 상태(state)와 상태 변경 로직(setter)을 정의합니다.


2. set()
• 상태를 변경하는 함수.
• 부분 업데이트 가능(merge 동작).

3. get()
• 스토어의 현재 상태를 즉시 읽는 함수.
• React 훅 없이도 외부에서 상태를 읽을 수 있음.

4. subscribe()
• 특정 상태 변화에 대해 리스너 등록.
• React 컴포넌트 바깥에서도 상태 변화를 감지 가능.

const unsubscribe = useStore.subscribe(state => {
  console.log('count changed:', state.count);
});

unsubscribe(); // 구독 해제

다른 라이브러리들과의 차이점 (Zustand vs 다른 상태관리 라이브러리 비교)

우리 팀은 현재 상태관리 라이브러리의 과도기를 겪고 있다.
과거 프로젝트 요구사항과 팀원의 선호도 차이로 인해 Jotai, Redux, Recoil이 혼합된 구조가 형성되었고, 그 결과 전역 상태의 흐름이 복잡해지고 유지보수가 점점 어려워졌다.

이에 따라 우리는 상태관리 방식을 Zustand로 통합하기로 결정했다.

Zustand는 비교적 가벼우면서도 명시적이고 확장 가능한 구조를 제공하므로, 기존에 분산된 상태를 한 곳으로 모으기에 적합하다고 판단했다.

다만, 통합 과정에서 고려해야 할 중요한 점이 있다.

현재 Redux에서는 비동기적 라우팅 처리 로직이 전역에서 관리되고 있는데, 이 기능을 단순히 Zustand로 옮기는 것만으로는 동일한 유연성을 확보하기 어렵다.
Zustand에서는 이러한 비동기 흐름을 미들웨어 또는 subscribe 기반 이벤트 처리로 재구성해야 하며, 상태 변경과 라우팅 전환이 끊김 없이 동작하도록 설계하는 것이 핵심 과제였다.

다음 글에서는 어떻게 이러한 과제들을 적용시켰는지 써보도록 하겠다!