quad/.claude/research/state-epoch-validation.md

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

**상태**: research — **사용자 제안, 에이전트 분석 완료. 2026-08-21에 세부가 세 차례 갱신됐다(중복 통지도 접음 / 선언 안 된 의존성 조항 기각 / `rawInvalid` 기제와 `emit` 인자 정정 + `seen`·`computedAt` 분리 철회). 채택 자체는 여전히 미정.**
구현 전 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. 사용자 제안 (최종 정리형) — **[2026-08-21 정정본]**

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

```
State
    sourceList : { [source (weak key)] : count }
        -- "이 소스의 이 에포크까지는 이미 봤다". 상류에서 복사, :With에서 합침
    rawInvalid : boolean
        -- "재계산이 필요하다"는 확정 플래그. emit이 실제로 통과하면 켜진다
```

- `Source:Set()`/`:Emit()`은 자기 count를 증가시킨다.
- **`emit`은 발행한 source만 전달한다**(값도, count도 안 싣는다) — 받는 쪽이
  그 source의 count 필드를 그냥 읽으면 된다. **[2026-08-21 사용자 정정]**
  앞선 정리는 `(source, count)` 쌍을 실어 보낸다고 적었는데 불필요하다.
- **emit을 받았을 때** — 판정은 O(1)이다, 그 소스 항목 하나만 본다:
  1. `sourceList[source] == source.count` → **삼킨다.** 이 에포크는 이미 다른
     경로로 봤다는 뜻이므로 뒤로 안 내려보낸다.
  2. 다르면 → **`sourceList[source]`를 먼저 갱신**하고 `rawInvalid = true`를
     둔 다음, **그러고 나서** 뒤로 emit 한다.
  - **다른 소스 항목은 건드리지 않는다** — 그 소스들은 자기가 직접 emit 하므로.
- **재계산 판정**:
  - `rawInvalid == true` → 그냥 재계산한다. `sourceList`를 훑을 이유가 없다
    (이미 확정이라 더 알아낼 게 없다).
  - `rawInvalid == false` → **그때만 `sourceList`를 훑는다.** 목적은 하나뿐 —
    **못 받은 emit을 여기서 먼저 받아주는 것**(중간 게이트에 막혀 있었다거나).
    다른 항목이 발견되면 count를 갱신하고 `rawInvalid = true`로 만든다.
  - **[2026-08-21 사용자 정정]** 앞선 정리는 이 순회 조건을 `rawInvalid == true`
    일 때로 적었는데 **반대**다.
- 재계산이 끝나면 `rawInvalid = false`. count는 emit을 통과시킬 때 이미
  갱신돼 있으므로 따로 손댈 게 없다.
- count가 싫다면 `[source] -> {}` 처럼 **유니크 테이블 identity**로 같은 판정이
  가능하다(사용자 대안).

**⭐ [2026-08-21] 그래서 카운트는 하나면 된다 — `seen`/`computedAt` 분리는
철회.** 앞선 정리는 노드가 전파 dedup용 `seen`과 캐시 검증용 `computedAt`을
따로 들어야 한다고 적었으나, 사용자 정정으로 **불필요**하다: count 갱신과
`rawInvalid = true`가 **같은 스텝에서 같이 일어나기** 때문에 "전파 시점에
갱신된 count가 캐시를 신선한 것으로 오인하게 만드는" 실패 모드 자체가
생기지 않는다. 캐시 유효성은 count가 아니라 `rawInvalid`가 들고, count는
순수하게 **"이 에포크를 봤는가"** 만 답한다. 사용자 정리: *"그냥 지금 순수
count 와 source 를 ref해두는 구현은 문제가 없어보인다. 단순 rawInvalid 가
약간 이상하게 사용/기제된 부분만 보일 뿐임."*

## 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가 발행했는지**를 실어 오므로
    **그 소스 하나만** 비교하면 된다(전체 목록 순회가 아님).
  - **⚠️ 이건 2026-08-14에 뒤집힌 옛 dedup과 다른 장치다.** 그때 폐기된 건
    *"이미 `invalid`면 더 안 내려보낸다"*로, `:Get()`을 안 부르는 Observer가
    **한 번 울고 영구히 침묵**하는 실패 모드가 있었다
    (`archive/invalidate-dedup-propagation-reversed.md`). 에포크 비교는 그
    모드가 없다 — 매 `Set`마다 카운트가 **새 값**이라 항상 통과하고, 접히는 건
    **같은 에포크가 두 경로로 도착한 두 번째**뿐이다.
  - **⚠️ [2026-08-21 철회] 여기 있던 "카운트를 `seen`/`computedAt` 둘로
    분리하라"는 요구는 사용자 정정으로 없어졌다** — §2 마지막 문단이 소스.
    캐시 유효성을 `rawInvalid`가 들고 있고 count 갱신이 `rawInvalid = true`와
    같은 스텝이라, 하나로 합쳐도 캐시를 신선한 것으로 오인하는 경로가 없다.
  - 비교는 `sourceList[source] == source.count`면 삼킨다(단조 증가라 안전).
- **선례가 있다** — 값 자체를 비교하는 게 아니라 **버전/에포크를 비교해
  lazy하게 검증**하는 건 MobX(global state version + observing 검사),
  Adapton류 incremental computing, "reactively" 계열 라이브러리가 쓰는 표준
  기법이다. Fusion처럼 **그래프를 위상정렬해 eager로 미는 방식**(quad가 이미
  기각한 것)의 대안으로 자주 쓰인다 — 즉 이 제안은 quad가 이미 택한
  pull 모델과 **결이 같다**.

## 4. 비용

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

- `sourceList`의 크기는 **그 노드 상류에 있는 서로 다른 루트 Source의 수**다.
  체인이 길어져도 안 늘고, `:With`로 합류할 때만 는다. UI 파생값에서 이 수가
  큰 경우는 드물다.
- **[2026-08-21 정정]** 순회 조건이 뒤집혔으므로 비용 구도도 뒤집힌다 —
  **훑는 쪽이 흔한 경로**(`rawInvalid == false`, 즉 "안 바뀐 것 같다")다.
  그래도 훑는 대상이 위 크기(2~4)라 상수 시간에 가깝고, 정작 비싼
  **재계산은 안 도는** 경로다. 반대로 `rawInvalid == true`면 순회를 아예
  건너뛰고 바로 재계산한다.

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

1. **[해소, 2026-08-21] 선언 안 된 의존성 — 별도 UB 조항을 만들지 않는다.**
   에이전트가 "새 모델은 더 강한 약속을 하니 예외를 UB로 못 박아야 한다"고
   제안했으나 **사용자가 기각**: *"그건 아니다. 이 동작으로 인해 이제 정말로
   항상 state 는 get 이 최신을 던지는게 맞다. 상류의 상태를 물어보므로 그러함.
   이전과 다른게 없다고 생각한다."* — 선언 안 한 Source를 클로저로 읽는 건
   **지금 모델에서도 똑같이 stale**이고 이 변경이 악화시키는 게 없으므로,
   새 조항 없이 기존 "의존성은 선언한다"는 관례 그대로 둔다.
2. **동적 의존성.** 조건에 따라 다른 상류를 읽는 계산이면 `sourceList`가
   보수적 상위집합이 된다 — 틀리진 않고 재계산이 조금 더 잦아질 뿐이다.
   그대로 감수할지 확인.
3. **⭐ [2026-08-21 확장] 순회로 발견한 변경을 뒤로 emit 할 것인가 —
   그리고 `Blocker`/`Gate`와의 상호작용.**
   `rawInvalid == false`에서 순회를 돌다 "못 받은 emit"을 발견해
   `rawInvalid = true`가 됐을 때, **그 자리에서 뒤로 emit 하는가**가 열려 있다.
   두 안:
   - **(a) 지연** — 아무것도 안 내려보내고, 나중에 그 소스의 진짜 emit이
     도착할 때 정상 경로로 처리한다.
   - **(b) 즉시** — 재계산하라는 지시를 받았고 invalid로 판정됐으니 그때 emit.

   사용자가 (b)의 위험을 먼저 의심했다가 **스스로 안전하다고 정정**했다:
   `A → {B, C} → D`에서 `B`가 `C`를 요구하다 `C`의 변경분이 흘러 `D`가 다시
   깨어나는 것처럼 보이지만, **`D`도 count를 갱신하므로 중복을 삼킨다** —
   *"안전히 C가 emit 되어도 되는 상황"*.

   남는 건 게이트 쪽이다. 게이트가 **앞에서 막아둔 emit**을, 뒤에서 `Get()`이
   촉발한 순회가 그대로 흘려보낼 수 있다(*"앞에서 막아뒀는데, 뒤에서 필요하다고
   해서 그대로 흘러버릴 가능성"*). 그래서 (b)를 택하더라도 **실제 block이 풀린
   뒤의 emit까지는 기다려야 한다**. 그리고 **게이트가 풀 때 내보내는 emit은
   여러 소스가 섞인 것**이라 어느 소스가 바뀌었는지 지목할 수 없다 — 사용자
   제안은 그 emit이 **`source = nil`을 싣고, `nil`이면 받는 쪽이 전체 목록을
   확인**하는 것. 게이트는 `Get()`은 막지 않고 emit만 유보하므로 이게 성립한다.

   **다만 사용자 판단은 "중간에 게이트가 끼는 건 원래 있던 문제이고, 게이트는
   보통 최종단에 쓰므로 실질적으로 의미 없어 보인다"**로 정리됐다 — 즉 이
   항목은 **채택을 막는 요소가 아니고**, `nil` emit 규약만 `Gate` 설계
   (`research/gate-primitive.md`)와 같이 확정하면 된다.
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) — 그러면 다이아몬드에서
  값도 통지도 한 번씩만 간다. **[2026-08-21 정정]** 여기 있던 "노드가
  `seen`/`computedAt` 두 카운트를 들어야 한다"는 추가 요구는 **철회**됐고,
  대신 확정할 것은 **게이트 해제 emit의 `source = nil` 규약**(§5의 3번)이다.
- 실측은 `luau-test`에 스파이크 하나면 충분하다 — 위 다이아몬드를 그대로 짜서
  (a) 지금 모델에서 섞인 값이 실제로 관측되는지, (b) 에포크 비교를 넣으면
  사라지는지 대조.