state를 위한 publish/subscribe(발행/구독) 패턴이란 무엇이며, 그 절충은 무엇인가요?

Question

Accepted Answer

**Publish/subscribe(발행/구독, pub/sub)**는 **발행자(publisher)**가 이벤트를 방출하고 **구독자(subscriber)**가 그에 반응하되 서로를 직접 알지 못하는 메시징 패턴입니다. 많은 state 라이브러리(그리고 이벤트 시스템)가 이 위에 구축됩니다 — store가 변경을 *발행*하고 컴포넌트가 그것을 *구독*합니다.

## 최소한의 pub/sub store

```js
function createStore(initial) {
  let state = initial;
  const subscribers = new Set();

return {
    getState: () => state,
    setState(next) {
      state = { ...state, ...next };
      subscribers.forEach((fn) => fn(state)); // PUBLISH: 모든 구독자에게 알림
    },
    subscribe(fn) {
      subscribers.add(fn);                     // SUBSCRIBE
      return () => subscribers.delete(fn);      // 구독 해제 함수 반환
    },
  };
}
```

컴포넌트는 알림을 받기 위해 `subscribe(callback)`을 호출하고, state가 바뀌면(`setState`) store가 모든 구독자를 호출합니다. 이것이 본질적으로 Redux의 `store.subscribe`, Zustand, 이벤트 이미터가 내부에서 동작하는 방식입니다.

## 디커플링 이점

```text
발행자(store)는 누가 듣고 있는지 모릅니다.
구독자는 누가 발행했는지 모릅니다.
→ 그들은 디커플링되어 이벤트/store를 통해서만 소통합니다.
```

이 느슨한 결합은 앱의 무관한 부분들이 서로에 대한 직접 참조 없이 동일한 변경에 반응하게 해줍니다 — 유연하고 확장 가능합니다.

## 절충

```text
✓ 장점: 디커플링, 유연함, 다대다 통신, 리스너 추가가 쉬움
✗ 단점:
  - 암시적 흐름 — 누가 이벤트에 반응하는지 추적하기 어려움(명시적 호출 대비)
  - 메모리 누수 — 구독 해제를 깜빡하면 죽은 리스너가 살아 있음
  - 디버깅 — 간접화로 "왜 이게 실행됐지?"에 답하기 어려움
  - 순서 — 구독자 실행 순서가 명확하지 않을 수 있음
```

가장 큰 실무적 위험은 **구독 해제를 깜빡하는 것**(예: 컴포넌트 언마운트 시)이며, 이는 메모리를 누수시키고 죽은 컴포넌트에서 콜백이 실행되게 할 수 있습니다.

```jsx
useEffect(() => {
  const unsub = store.subscribe(handleChange);
  return unsub; // ✅ 정리 — 언마운트 시 구독 해제
}, []);
```

## 왜 중요한가

Pub/sub은 대부분의 state 라이브러리와 이벤트 시스템의 **근간 메커니즘**입니다 — 이를 이해하면 store가 어떻게 컴포넌트에 알리고 `subscribe`/`unsubscribe`가 어떻게 작동하는지가 명확해집니다.

이는 힘(디커플링된 유연한 통신)과 함정(추적하기 어려운 암시적 데이터 흐름, 정리되지 않은 구독으로 인한 메모리 누수)을 모두 설명합니다.

pub/sub을 인식하면 내부의 반응성을 추론하는 데 도움이 되고, 구독을 항상 정리하는 것의 중요성을 강화합니다.