[🚗 Log] Zustand 같은 구독형 스토어를 따라해보며 연습하는 Observer pattern

👀 작성의 계기

최근 간단한 토이 프로젝트를 진행하면서 Context API처럼 props를 이용하지 않는 상태 전파 로직이 필요해졌다.
기존 Context API를 사용하면 여전히 불필요한 리렌더링 이슈를 완전히 피하기 어려웠다.

라이브러리에 의존하면 편리하지만, 작은 토이 프로젝트에 zustand를 설치하는 건 과하다는 생각이 들었다.
그러던 중, 학습하면서 얻은 Observer 패턴 기반의 상태 관리 아이디어를 구현하면서 체화시켜보자는 결심이 들게 되었다.

참고: Observer 패턴에 대한 자세한 내용은 Refactoring.Guru의 글 를 추천한다.

🧐 Observer pattern?

예전에 읽었던 글에 '디자인 패턴을 공부하는 것은 선대 위대한 개발자들의 멋진 개발 방식을 어깨넘어에서 빌려다 쓸 수 있는 좋은 방법이다.' 라는 글이 기억난다.

패턴 추종자까진 아니어도, 어느정도는 이런 개발 방식의 패턴화됨을 따라하는 것이 매우 유용하다는 것을 근래 많이 느끼고 있다.

1. 패턴 정의

   • 옵저버 패턴은 주제(Subject)의 상태가 변경될 때, 등록된 여러 관찰자(Observer)에게 일대다(one-to-many) 방식으로 알림을 전파하는 디자인 패턴이다.
   • 흔히 Pub/Sub(발행/구독) 모델로도 불린다

2. Subject 구조 정의

   • Instance State: 특정 관심사를 갖는 구조의 상태
   • Observer List: Observer을 저장하고 있는 상태
   • Observer Register: 인자로 받는 함수를 Observer State에 등록 및 해제 함수 리턴
   • Change Notification: 인스턴스 상태의 변화가 일어날 시 이를 등록된 Observer들에게 전파하는 함수

3. 동작 흐름

   1. Subject와 1:N 관계로 Observer들이 등록(구독)
   2. Subject 상태 변경 시 Observer들에게 Notification
   3. 각 Observer의 update() 메서드 실행 → 필요한 대응 수행
   4. Observer는 언제든 등록·해제 가능

4. 장단점

   • 장점
     • Subject 변경을 자동 감지 후 변경점 자동 실행.
     • OCP(개방-폐쇄 원칙) 준수 → 발행자 코드 변경 없이 옵저버 추가 가능
     • Single Responsibility Principle 준수 → Subject는 등록된 Observer 실행에만 관심이 있을 뿐, 구체적인 update 내용은 Observer의 관심!
     • 느슨한 결합(loose coupling) 유지
   • 단점
     • 옵저버 알림 순서 제어 어려움 → 이는 등록 당시에 우선순위 결정 로직을 추가하면 어느정도 개선 가능
     • 구독 해제 누락 시 메모리 누수 위험

🧐 그래서 Observer랑 리엑트 구독형 상태관리가 무슨상관인데?

리엑트에서는 "Re-rendering" 이라는 특성상 항상 상태관리에 있어 리엑트의 환경에 종속될 수 없다는 점을 늘 고려할 수밖에 없다.

대표적으로, 리액트 상태가 업데이트 되지 않으면 리랜더링이 되지 않아 웹페이지의 변동을 볼 수 없다는 점이 그 대표적인 예다.

그렇다면 Zustand와 같은 라이브러리는 어떻게 모듈 스코프 내에 있는 인메모리 상태값을 이용해서 리액트와 연동을 시킨 것일까?

그것의 해답에는 Observer을 이용한 리랜더링 요청 전파 프로세스에 그 키가 있다.

Zustand의 구조원리를 간단하게 따라해본 예시 코드를 예로 들어보려고 한다.

💡 어디까지나 최대한 간략하게 만든 예시이다. 실제론 훨씬 복잡하고 안정성을 위한 코드도 많다.

import { useReducer, useEffect, useRef, useMemo } from 'react';

/********************************************
 *
 * @createStore
 *
 ********************************************/

type Subscriber = () => void;
type Unsubscribe = () => void;
type PartialState<T> = Partial<T> | ((prev: T) => T);

export function createStore<T>(initialState: T) {
  let state = initialState;
  const subscribers = new Set<Subscriber>();

  return {
    // 1) 현재 상태 조회
    getState: () => state,

    // 2) 상태 변경 및 구독자 알림
    setState: (partial: PartialState<T>) => {
      state =
        typeof partial === 'function' ? (partial as (s: T) => T)(state) : { ...state, ...partial };

      for (const fn of subscribers) {
        fn?.();
      }
    },

    // 3) 구독하기 (컴포넌트가 여기에 등록)
    subscribe: (fn: Subscriber): Unsubscribe => {
      subscribers.add(fn);
      return () => {
        subscribers.delete(fn);
      };
    },
  };
}

위의 내용은 Observer을 관리하는 Subject 생성 함수이다.

이 함수를 호출할 경우 특정 모듈 스코프 내에서 초기화되어 리액트의 리랜더링 사이클과는 무관한 영역에서 전역적으로 유지가 된다.

export interface MainLayoutStoreState {
  headerMenuOpen: boolean;
}

// 해당 스토어는 모듈 스코프 기준으로 생명주기가 유지되는 인메모리 데이터이다.
export const mainLayoutStore = createStore<MainLayoutStoreState>({
  headerMenuOpen: false,
});

그렇다면 이제 우리에게 필요한 것은 이 단순한 인메모리 상태의 스토어의 상태 업데이트를 react의 랜더링 사이클과 연결지을 수 있는 Store-Binding Hook이 필요하게 된다.

그것을 react hook과 react state를 이용해서 구현을 하면 된다.

/********************************************
 *
 * @useStore
 *
 ********************************************/

export function useStore<T>(store: ReturnType<typeof createStore<T>>): T;
export function useStore<T, U>(store: ReturnType<typeof createStore<T>>, sel: (state: T) => U): U;
export function useStore<T, U>(
  store: ReturnType<typeof createStore<T>>,
  sel?: (state: T) => U,
): T | U {
  const selector = useMemo(() => sel ?? ((state: T) => state as unknown as U), [sel]);
  const [, forceUpdate] = useReducer((x: number) => x + 1, 0);
  const lastSelected = useRef<U>(selector(store.getState()));

  // 훅 호출 후 store 업데이트의 감지에 반응하여 리랜더링하는 옵저버 등록
  useEffect(() => {
    const checkForUpdates = () => {
      const next = selector(store.getState());
      if (!Object.is(lastSelected.current, next)) {
        lastSelected.current = next;
        forceUpdate();
      }
    };

    const unsubscribe = store.subscribe(checkForUpdates);

    checkForUpdates();

    return unsubscribe;
  }, [store, selector]);

  return lastSelected.current;
}

이 훅의 핵심은 바로 자신의 리랜더링을 유발시킬 수 있는 Observer을 props로 주입받는 observer 객체의 subscribe으로 등록시킨다는 점에 있다.

만약 이 훅을 어떤 특정 컴포넌트가 호출했다고 가정하자.

function WebMenu() {
  const { headerMenuOpen } = useStore(mainLayoutStore);
  ...

이 훅이 컴포넌트 내에서 호출되었다는 의미는 바로

"내가 리랜더링에 영향을 받지 않을 ref 상태(lastSelected.current) 를 보유하고 있을건데,

만약 외부에 위치한 store의 상태가 업데이트가 되면 내가 등록해뒀던 observer인 checkForUpdates 를 호출해주세요.

스토어 상태와 내 ref 상태를 비교해봐서 차이나면 리랜더링 해버릴거에요." 하고 선언하는 것이다.

이로 인해서 왜 Zustand가 자신을 "구독형" 상태관리라고 소개하는지 이해할 수 있다.

컴포넌트는 자신의 리랜더링을 결정해줄 수 있는 옵저버 등록 훅 "useStore" 가 호출되지 않는다면 부모가 리랜더링하지 않는 이상
본인은 리랜더링을 하지 않기 때문이다.

// 🚫 아래 컴포넌트는 store 업데이트에 대해 반응하지 않는다.
// store은 업데이트 되더라도, 이를 감지할 옵저버를 등록하지 않기 때문이다.
function WebMenu() {
  const { headerMenuOpen } = mainLayoutStore.getState();
  ...

// ✅ 아래 컴포넌트는 store 업데이트에 대해 반응하여 리랜더링한다.
// useStore의 호출이 바로 자기 자신의 리랜더링 유무를 감지할 옵저버를 등록하는 동작이기 때문이다.
function WebMenu() {
  const { headerMenuOpen } = useStore(mainLayoutStore);
  ...

즉, 다시말해 옵저버를 등록하는 행위 === store 상태변화를 "구독" 하는 행위! 가 되는 것이다.

🧐 끝맺음

디자인 패턴은 위대해.

그리고, 배우고 실제로 적용해볼수록 새삼스러운 개념처럼 보이는 것이 더 크게 다가오는 것 같다.

그냥 머릿속으로 이해하고 "아 그래" 하고 넘어갈 수 있는 내용도 다시 여러번 보게 되면 새로운 깨달음이 오는 순간이 있다.

더욱 깊은 깨달음을 얻을 수 있도록 노력하는 자세로 있어야 하겠다.