# 2026-08-24 — 6라운드 손 트레이싱 전량 처리·반영, 그리고 세 번의 재검토

**한 줄**: 발견 보고 `H-1`~`H-54`를 사용자와 대화형으로 하나씩 결정하고
`base/` 24개 문서에 반영했다. 그 뒤 `/code-review high`가 7건(그중 셋은 이번
반영이 만든 회귀), 감사 1라운드가 5건, 2라운드가 7건을 더 잡았다.

**결정과 근거의 소스는 `qa-request/pre-implementation-handtrace-round6-followup.md`**
— 여기서 반복하지 않는다. 이 문서는 **어떻게 진행됐고 무엇이 잘못됐는가**의 기록이다.

## 진행 방식 — 사용자 요청

*"`pre-implementation-handtrace-round6.md` 에 대해서 같이 하나하나 처리해나가보자.
질문 모드로 계속 물어보며, 처리할 방법들을 찾거나 택하거나 해보자. 전부 사람이
직접 읽기엔 양이 많아서 그래. 다만 네 질문과 원 파일은 같이 볼테니, 어디에 원문이
있는지만 알려줘"*

54건을 4·5라운드 같은 문항지로 만들지 않고, **갈래 선택이 필요한 것만 추려
급한 순서로** 물었다(M2/M3를 막는 것 먼저). 단순 정정은 마지막에 한 번에 묶어
확인받았다("전부 그대로 반영"). 답변마다 원문 줄 번호를 같이 줬다.

## 사용자가 제 선택지를 뒤집은 자리들 — 이번 세션의 핵심

에이전트가 낸 갈래가 **틀렸거나 부족했던** 경우가 여럿이고, 그게 결과를 크게
바꿨다. 기록해둘 가치가 있는 것만:

### `H-1` — 제 세 갈래가 전부 차선이었다

`:List`의 `keyIndex`가 사이클 도중 stale이라는 발견에 (1) 라이브 인덱스 맵
(2) `indexOfRaw`를 기본 경로로 (3) reconcile 2패스를 냈는데, 사용자가 **역제안**:

> *"raw* 가 층위를 알아야할 이유를 모르겠는 상태. 그냥 k->realElem 을 list 에선
> 저장하고, raw 는 realElem -> index 를 indexOf 로 하거나, 보통 읽기가 더
> 빈번하므로 realElem->index 해시맵을 만들어주고, index 밀고 당기는 동작에서
> 이걸 같이 업데이트해주는 편이 나아보이기도. quad-base 의 현 모양에서 더 확장
> 될 땐, index 를 알아야하게 되는 경우가 많아질것이라, 선제 처리로 해결하는게
> 맞아보이는데, 어떻게 생각하는지?"*

제 1번 안은 `raw*`가 `:List`의 클로저를 알아야 해서 층이 섞이는 게 단점이었는데,
**맵을 `_elements`와 같은 층에 두면 그 단점 자체가 없어진다**는 게 요지였다.
채택. 부수로 `keyIndex`가 단순 키 집합으로 강등되며 `H-16`도 같이 사라졌다.

### `H-2` — "offsetAt으로 구하라"가 초기 경로에서 안 맞았고, 그걸 되물었다

사용자 답:
> *"offsetAt 으로 구함 -> 기본적으로 activation 자체는 순차로 일어나므로 length
> 자체는 확정되는게 맞을것임."*

확인해보니 **최초 population에서만 안 맞았다** — `materializeSlotTree`가
`_mounted = false`인 채 `activateList`를 부르고 `rawAdd`가 부기까지 얼리리턴해서
`bk.lengthList`가 비어 있었다. 그걸 보고했더니 사용자가 되물었다:

> *"1. 안이 맞긴 한데, length 자체는 설정하지 않아? offset 을 넘겨주는건
> updateFn 기준으로 부기이지, 물리 마운트와는 무관해서 말이야. … 부기 확정에서
> length 를 확정해도 되는거 아님?"*

맞는 지적이었다. **`_mounted`가 "물리 인스턴스 유무"만 뜻하도록 좁히고 부기는
실체화 시점부터 항상** 하는 것으로 정리됐고, `slot._physicalTarget`이 신설됐다.

### `H-40` — 제가 낸 "브랜드로 판정" 안이 성립 불가였다

> *"브랜드를 두는건 못 해, 이제 brand 는 각각 따로 생성되어서 있는지 없는지
> 보는건 결국 전부 봐야한다는 의미일껄? 난 3. 을 추천해. isInst 같은걸 백엔드
> 계약에 넣고, quad-roblox 가 채워주는게 맞아보이는데 어떻게 생각해?"*

2026-08-21의 `Brand` 재작성(인스턴스 브랜드)을 제가 못 따라간 것. 화이트리스트로
뒤집되 **base는 `T`를 모른 채 주입 술어만 부르는** 형태로 닫혔다.

### `H-33`/`H-49` — 제 중첩 합성안이 창을 안 끝나게 만들었다

`Gate` 정책 합성에서 제가 `blocker:Policy(debounceOnEmit)`(블로커가 바깥) 형태를
제안했는데:

> *"맞는 모양 같긴 해. 근데 저러면 unblock 될 때 다시 타이머 셋팅됨. 타이머
> 끝난건데, 다시 셋팅되잖아. … 사실 debounce 는 emit 핸들 조차 필요 없는거지.
> 그냥 blocker 를 자신이 가지니까, 껐다 켰다로 emit/block 을 하고(내부 구현을
> 위임). On/Off 할 시기만 본인이 결정한다는 생각이였는데, 이 구조가 불가한거였음?"*

가능했고 더 나았다. 제 트레이스는 "디바운스도 진짜 `emit`을 쥔다"를 전제했는데,
**디바운스가 emit을 아예 안 쥐면** 순차 호출이 성립한다.

### 사용자가 먼저 발견한 것 둘

- **`Ref.Callbacks`를 해시맵으로** — `H-7`을 "해제 경로 추가"로 정하자마자
  *"그렇다면 Effect 의 callback 들은 해시맵이 되는게 나아보이는데 [callback/루틴]=true
  그렇지 않아?"* 로 자료구조까지 바꿨다. 부수로 `ref-plan.md`의 `#t` border 실측
  항목이 폐기됐다.
- **`Ref` 콜백의 `canExecute`** — `H-11` 재결정 중에 *"그런데, Effect 또한
  canExecute 를 거쳐서 Ref 의 Callback 이 실제 Effect 의 Callback 을 실행할 지
  결정해야하는데, 그것도 되어있는지 봐줘요"*. 확인해보니 없었고, 오히려 제가
  `H-7` 처리 때 "그 대안은 채택하지 않았다"고 적어놨었다. **해제는 누수를,
  게이팅은 발화를** 막는 별개 역할이라 둘 다 필요했다.

## 반영 후 세 번의 재검토에서 나온 것 — 실패 기록

### `/code-review high` — 7건, 그중 **셋이 이번 반영이 만든 회귀**

`conventions.md`가 *"`/code-review`는 감사자를 대체하지 않는다"*고 적어둔 그대로였다.
셋 다 **코퍼스 정합성 각도로는 구조적으로 안 보이는** 종류였다:

1. **`rawAdd`가 미실체화 가드를 통째로 잃음** — 상태가 셋이 됐다고 산문에 쓰고
   코드엔 `_mounted` 경계만 남겼다. `Slot { frameA }` 생성자가 즉시 크래시.
2. **`rawRemove`가 마운트 전 창에서 아무도 안 죽임** — `nativeRemove`가 곧
   파괴였는데 `_mounted`로 가리기만 하고 `else`를 비워뒀다. 영구 누수.
3. **`_listed` 분기가 포탈 재마운트를 깸** — 제가 "`:List`와 CRUD가
   상호배타이니 안전"이라 말하고 승인받았는데 **재마운트 경로를 안 봤다.**
   `activateList`가 멱등 가드로 즉시 리턴하는 경우를 놓친 것.

그리고 `H-11`의 두 결정이 **서로 모순**이라는 지적(4번)이 나와 재결정했다 —
*"`EffectHandle`이 자기 `bindLifetime` 직후에 건다"*는 **그 호출부가 실재하지
않았다.** 사용자 판단으로 `bindLifetime`/`unbindLifetime`이 직접 처리하는 것으로
바뀌었다:

> *"Destroying 자체가 엔진이 아는 요소이기 때문에, 엔진이 처리하는 곳에 두긴
> 해야합니다. 옵져버는 바로 생성되기 때문에, bind 상 옵져버 목록을 가져와 자신이
> 재귀하고, bindLifetime 이 처리하는게 나아보입니다."*

제가 반대 근거로 인용했던 *"게이트는 값 타입을 안 가린다"*는 **인용 자체가
틀렸다** — `source-state-plan.md`의 그 절은 `canBound` 판정이 두 진입점에서
같다는 얘기지 부수 배선 얘기가 아니었다.

### 감사 루프 — 9라운드, 34건 (라운드별 5→7→2→2→3→9→2→4→0)

라운드별 각도와 발견 목록은 **followup의 E절이 소스**. 여기엔 교훈만 적는다.

**2라운드**: **`.claude/README.md`를 한 줄도 안 고쳤다.** `base/` 19개 파일
1300줄을 바꿔놓고 색인을 안 건드렸으니 체크리스트 6번을 통째로 빠뜨린 것.

**6라운드가 9건으로 가장 많이 잡았고, 그게 각도 전환의 증거다.** 앞선 다섯
라운드는 전부 "문서가 서로 맞는가"를 물었는데, 6라운드만 **"이 체크박스로
코드를 짜면 무엇이 나오는가"**를 물었다. 그러자 `ROADMAP.md`의 미완료 항목이
대거 stale인 게 드러났다 — 폐기된 `pos` 공식이 "확정"으로 남아 있고, 접두합
캐시 무효화 계약이 통째로 없고, `bindLifetime`이 "둘만 한다"고 적혀 `H-11`과
직접 모순이었다.

**반복된 실패 패턴은 하나 — "N개 중 일부만 고쳤다".** 1라운드(배너를 달고 그
배너가 부정하는 문장을 안 고침), 2라운드(README를 통째로 안 고침),
7·8라운드(그 README를 고칠 때 11행 중 6행만). 8라운드를 아예 **완결성 축**으로
잡은 게 그래서고 4건이 더 나왔다. **세 번 다 `conventions.md`의 핸드오버
체크리스트가 명시적으로 경고하는 항목이었다**(2번·6번) — 규율이 없어서가
아니라 규율을 지켰는지 스스로 확인하지 않아서 생긴 실패다.

**감사에서 파생된 새 결정 셋**도 `base/`에 반영했다 — 주입 op
`onDestroying(inst, fn)` 신설(`_bindDestroying` 의사코드를 쓰다 드러났다),
`EffectHandle`의 필드 다섯, `quad-types`의 `Quad` 갱신을 M3/M6/M7/M8/M10에도
항목화(확정은 "마일스톤마다"였는데 M2에만 있었다).

## 남은 것

- **백로그 1건**: `Fallback`/`Traceback` 중 생성된 부분 트리 회수(`H-26`).
  그 둘이 슈가라 구현 시점에 같이 다룬다.
- **M2 착수를 막는 설계 항목은 없다.** 남은 건 `question.md` 2번(M2↔M3 양방향
  의존, 마일스톤 순서)뿐이다.