# State 재계산 판정을 "소스 에포크" 비교로 바꾸는 안 (2026-08-21 신설)

**상태**: research — **사용자 제안, 에이전트 분석 완료, 세부 두 건은 2026-08-21에 추가 확정(중복 통지도 접음 / 선언 안 된 의존성 조항 기각). 채택 자체는 여전히 미정.**
구현 전 QA 5라운드(`SS-2`/`SS-3`)에서 나왔고 사용자 스스로 *"더 생각해볼
이야기라 백로깅이나 리서치에 들어가야할듯"*이라 함. 회신 원문은
`qa-request/pre-implementation-qa-round5-response.md`.

**⚠️ `base/source-state-plan.md`가 여전히 정본이다** — 이 문서는 아무것도
확정하지 않는다. 다만 **State 내부 표현을 바꾸는 제안이라 M3(=State 구현)
착수 전에 결론이 나야 한다.**

## 1. 사용자가 지목한 문제 (실재함)

```
A ──> B ──┐
 └──> C ──┴──> D
```

`A:Set()` 한 번에 대해 지금 모델(push-invalidate + pull-recompute)에서:

1. `A`가 구독자에게 무효화 신호를 전파한다. 순회가 DFS라 **`B` 쪽 가지가 먼저
   끝까지 내려간다** — `D`가 `B`를 통해 신호를 받고, 그 아래 Observer가 발화한다.
2. 그 Observer가 `D:Get()`을 부른다. `D`는 상류를 `Get()`하는데, **`C`는 아직
   신호를 못 받아 `invalid`가 아니다** → `C`는 **옛 캐시를 그대로 반환**한다.
3. `D`는 `(B_new, C_old)`라는 **섞인 값**을 계산해 캐시하고 `invalid`를 끈다.
4. 뒤늦게 `C` 가지의 전파가 도착해 `D`가 다시 무효화되고, Observer가 또 울고,
   그때서야 `(B_new, C_new)`로 교정된다.

즉 **(a) 한 사이클 안에서 잘못된 값이 한 번 관측되고**(그 값으로 이미 프로퍼티가
써지는 등 부작용이 나간다), **(b) 같은 계산이 두 번 돈다.** 리액티브 문헌에서
말하는 전형적인 **glitch**이고, 지금 quad 문서 어디에도 이 현상이 서술돼 있지
않다. `base/source-state-plan.md`의 "다이아몬드 의존성은 무엇이 푸는가" 절은
**중복 재계산이 없다**고만 말하는데, 그 논증은 *"누군가 `d:Get()`을 부르는
시점"이 전파 파동이 끝난 뒤*라고 암묵적으로 가정한다 — Observer가 전파 도중에
발화한다는 사실과 겹쳐 읽으면 그 가정이 깨진다.

## 2. 사용자 제안 (최종 정리형)

각 State가 **자기에게 영향을 주는 루트 `Source`들의 에포크**를 들고 있다가,
`Get()` 때 그것과 실제 Source의 현재 에포크를 비교해 재계산 여부를 정한다.

```
State
    sourceList : { [source (weak key)] : count }   -- 상류에서 복사, :With에서 합침
    rawInvalid : boolean                            -- emit이 오면 그냥 true(값싼 캐시)
    invalid    : rawInvalid가 true일 때만 sourceList를 훑어 "정말 계산이 필요한가" 판정
```

- `emit`은 **발행한 source와 그 count를 같이 전달**한다(값은 여전히 안 싣는다).
- `Source:Set()`/`:Emit()`은 자기 count를 증가시킨다.
- 캐시를 채울 때 그 시점의 각 source count를 같이 기록해두고, `Get()` 때
  하나라도 다르면 재계산한다.
- count가 싫다면 `[source] -> {}` 처럼 **유니크 테이블 identity**로 같은 판정이
  가능하다(사용자 대안).

## 3. 에이전트 분석 — 이게 실제로 무엇을 고치는가

**결론부터: 문제 진단도 해법 방향도 맞다. 그리고 이건 성능 최적화가 아니라
`Get()`의 의미론을 바꾸는 결정이다.**

- **고쳐진다 — 섞인 값.** 위 3단계에서 `D`가 `C:Get()`을 부르면, `C`도 자기
  `sourceList`에서 `A`의 count가 자기가 기록한 것보다 앞선 걸 보고 **신호가
  아직 안 왔어도 스스로 재계산**한다. 그래서 `D`는 항상 `(B_new, C_new)`를
  얻는다. **`Get()`이 "지금 이 순간의 일관된 값"을 반환한다는 보장이 처음으로
  성립**한다.
- **고쳐진다 — 중복 재계산.** 뒤늦게 `C` 쪽 신호가 도착해 `rawInvalid`가 켜져도,
  count 비교가 "이미 최신"이라 재계산이 안 일어난다.
- **⭐ [2026-08-21 후속 확정] 중복 *통지*도 같이 접는다.** 처음엔 "값만
  고쳐지고 통지는 두 번 그대로"로 정리했는데, **사용자 판정으로 통지도
  같은 장치로 접기로 했다**: *"중복 통지는 단순히, count 목록을 순회해보고
  이미 모든 소스가 최신이면 무시하는게 맞아보인다. 특히 emit 은 자신 소스를
  주게 되므로, 자신 소스 카운트만 빠르게 비교가 쉽다. 우리에게 중요한 점은,
  앞단의 변경이 뒤로 흘렀냐일 뿐이라서 해당 방식을 택하는데 있어 문제가 없다."*
  - **판정은 O(1)이다** — emit이 `(source, count)`를 실어 오므로 **그 소스
    하나만** 비교하면 된다(전체 목록 순회가 아님).
  - **⚠️ 이건 2026-08-14에 뒤집힌 옛 dedup과 다른 장치다.** 그때 폐기된 건
    *"이미 `invalid`면 더 안 내려보낸다"*로, `:Get()`을 안 부르는 Observer가
    **한 번 울고 영구히 침묵**하는 실패 모드가 있었다
    (`archive/invalidate-dedup-propagation-reversed.md`). 에포크 비교는 그
    모드가 없다 — 매 `Set`마다 카운트가 **새 값**이라 항상 통과하고, 접히는 건
    **같은 에포크가 두 경로로 도착한 두 번째**뿐이다.
  - **그래서 노드가 기록해야 하는 카운트가 둘이다**: 전파 dedup용
    "이 소스의 이 에포크를 이미 내려보냈다"(`seen`)와, 캐시 검증용 "이 값을
    계산할 때의 에포크"(`computedAt`). 하나로 합치면 전파 시점에 갱신되는
    쪽이 캐시를 신선한 것으로 오인하게 만든다 — **구현 시 반드시 분리할 것.**
  - 비교는 `incoming <= seen[source]`면 삼킨다(단조 증가라 안전).
- **선례가 있다** — 값 자체를 비교하는 게 아니라 **버전/에포크를 비교해
  lazy하게 검증**하는 건 MobX(global state version + observing 검사),
  Adapton류 incremental computing, "reactively" 계열 라이브러리가 쓰는 표준
  기법이다. Fusion처럼 **그래프를 위상정렬해 eager로 미는 방식**(quad가 이미
  기각한 것)의 대안으로 자주 쓰인다 — 즉 이 제안은 quad가 이미 택한
  pull 모델과 **결이 같다**.

## 4. 비용

사용자 추산(*"해시 for은 이미 빠르고, Source가 … 수 자체가 적다. 2~4개에 대해
인덱싱 하는 정도"*)에 동의한다. 덧붙일 것 둘:

- `sourceList`의 크기는 **그 노드 상류에 있는 서로 다른 루트 Source의 수**다.
  체인이 길어져도 안 늘고, `:With`로 합류할 때만 는다. UI 파생값에서 이 수가
  큰 경우는 드물다.
- `rawInvalid`가 false면 훑지도 않으므로, **정말 안 바뀐 흔한 경로는 지금과
  같은 비용**(플래그 하나)이다.

## 5. 열린 질문 (채택 전에 답이 필요)

1. **[해소, 2026-08-21] 선언 안 된 의존성 — 별도 UB 조항을 만들지 않는다.**
   에이전트가 "새 모델은 더 강한 약속을 하니 예외를 UB로 못 박아야 한다"고
   제안했으나 **사용자가 기각**: *"그건 아니다. 이 동작으로 인해 이제 정말로
   항상 state 는 get 이 최신을 던지는게 맞다. 상류의 상태를 물어보므로 그러함.
   이전과 다른게 없다고 생각한다."* — 선언 안 한 Source를 클로저로 읽는 건
   **지금 모델에서도 똑같이 stale**이고 이 변경이 악화시키는 게 없으므로,
   새 조항 없이 기존 "의존성은 선언한다"는 관례 그대로 둔다.
2. **동적 의존성.** 조건에 따라 다른 상류를 읽는 계산이면 `sourceList`가
   보수적 상위집합이 된다 — 틀리진 않고 재계산이 조금 더 잦아질 뿐이다.
   그대로 감수할지 확인.
3. **`Blocker`/`Gate`와의 상호작용.** 게이트는 **통지만** 막고 `Get()`엔 영향이
   없다는 게 확정 계약이므로(`base/blocker-plan.md`), 게이트 아래에서 `Get()`하면
   에포크 비교가 "갱신 필요"로 판정해 **막아둔 값이 그대로 보인다**. 지금도
   같은 동작이지만, 새 모델에선 그게 더 또렷해지므로 문서에 명시할 것.
4. **`:Emit()`(값을 제자리에서 mutate하고 알리는 경로)** — count만 올리면 되므로
   그대로 동작한다. 확인만.
5. **weak 키.** `[source] -> count`를 weak-key로 두면 source가 죽을 때 항목이
   사라진다. 다만 `base/relate-plan.md`가 경고하듯 **값이 키를 되참조하면 안
   된다** — count는 숫자라 문제없다(테이블 identity 방식을 택하면 그 테이블이
   source를 참조하지 않게 할 것).
6. **`Get`의 계약 문구.** 사용자 지적(*"Get 이 항상 최신 상태를 가져온다라는
   말이 여기서 무력화되는 부분"*)의 방향은 사실 **반대**다 — 지금 모델이
   "최신"을 못 지키고 있었고, 이 제안이 그걸 지키게 만든다. 채택하면
   `base/source-state-plan.md`의 전파 모델 절을 그렇게 다시 써야 한다.

## 6. 곁가지 — 폴링용 sugar

사용자 제안: *"폴링을 위해서는 Apply(Realtime()) 같은 슈거를 주면 된다.
옵져버로 항상 get 하고 value 를 실시간으로 읽을 수 있게 해주는것. 단순하게
Ref<T> 로 변환해주는 등"*. 즉 "항상 최신 값을 필드로 들고 있는 박스"를 만드는
순수 슈가. **이건 이 문서의 결정과 독립**이고(에포크를 채택하든 안 하든 쓸 수
있다), `research/operator-sugar-plan.md`의 콤비네이터 계열에 더 가깝다 —
채택되면 그쪽으로 옮길 것.

## 7. 권고

- **채택 방향에 찬성.** "선제 최적화가 아니라 확정 동작으로의 승격"이라는
  사용자 판단에 동의한다 — 이건 성능이 아니라 **정확성** 결정이고, State
  내부 구조를 정하는 M3보다 **뒤에 하면 되돌리는 비용이 크다**.
- **[2026-08-21] 에이전트가 붙였던 조건(선언 안 된 의존성을 UB로 명문화)은
  사용자 기각으로 빠졌다** — §5의 1번 참고.
- **채택 시 같이 확정되는 것: 중복 통지도 접는다**(§3) — 그러면 다이아몬드에서
  값도 통지도 한 번씩만 간다. 대신 노드가 `seen`/`computedAt` 두 카운트를
  들어야 한다는 게 구현 요구사항으로 추가된다.
- 실측은 `luau-test`에 스파이크 하나면 충분하다 — 위 다이아몬드를 그대로 짜서
  (a) 지금 모델에서 섞인 값이 실제로 관측되는지, (b) 에포크 비교를 넣으면
  사라지는지 대조.