quad/.claude/session/2026-08-21-01-detach-keygone-owned-and-attachslot-decomposition.md

2026-08-21-01 — Detach 보존 주체 / KeyGone / Owned 확정, attachSlot 분해

한 줄: QA 4라운드 followup의 마지막 열린 항목(F-3)이 사용자 회신으로 전량 닫히면서, :List의 요소 소유권 모델(slot._detached + KeyGone + Owned)과 attachSlot의 책임 분해(materializeSlotTree/mountSlotTree)가 확정돼 base/slot-plan.md에 반영됐다.

소스 관계: 지금 유효한 설계는 항상 base/slot-plan.md가 소스이고, 처리 경과 요약은 qa-request/pre-implementation-qa-round4-followup.md의 H절, 분해 근거는 reference/slot-attach-decomposition.md. 이 파일은 그 결정들이 어떤 논의를 거쳐 나왔는지의 원문 기록이다.

---

1. 발단 — F-3을 제안하게 된 관측

3차 처리(G절)까지 오면서 Detach(옛 PopOnly) 경로에 두 개의 구멍이 남아 있었다.

1. 보존 주체가 userdata였다. 기존 문서는 updateFn이 Detach, { old = ..., source = ... }를 반환하면 "보존은 반환한 userdata가 담당"한다고 확정해뒀다.
2. 키가 데이터에서 사라졌을 때의 처분이 미결이었다(question.md 3번, ROADMAP.md M6에 ⚠️로 박혀 있었음).

2번을 파다가 1번이 함께 무너졌다. 결정적인 근거는 gcconn 트릭이다 — base/lifecycle-pattern.md가 확정해둔 대로 quad가 만든 모든 Instance는 GetPropertyChangedSignal("ClassName") 커넥션의 클로저가 자기 자신과 gchold를 캡처하므로 참조를 놓는 것만으로는 회수되지 않는다. 즉 detach된 요소를 userdata 안에 넣어두고 :List가 그 키를 잊어버리면 GC 폴백이 아예 없이 영구 누수다. userdata는 :List에게 opaque라 "이 안에 뭐가 들었으니 죽여라"를 알 수 없다.

그래서 세 가지를 묶어 제안했다: (1) 보존은 Slot 필드가 한다, (2) owner가 죽을 때의 정리는 Effect가 한다, (3) 키가 사라지면 updateFn에게 한 번 더 묻는다.

2. 사용자 회신 — 두 가지를 더 얹었다

"Detach 요소는 slot 안에 보관하는게 내 생각이였어서 (2) 제안에 동의. ud 에 넣는거로는 최종 처분이 불가하다에 동의함. 이미 detach 인데 또 detach 를 보내도록 하면 nop하게 두고, detach 를 다시 안 보내고 prev 를 사용하게 된다면 재마운트 해주는거 괜찮은 아이디어같음. base에 전부 반영해줘."

여기서 **"이미 detach인데 또 detach → nop"**과 **"prev를 그대로 반환 → 재마운트"**가 확정됐다. 이 둘은 원래 제안에 없던 것으로, 보존 주체가 slot._detached로 옮겨간 순간 ud에 홀드할 필요 자체가 없어진다는 따름정리를 사용자가 먼저 짚은 것이다 — reconcile이 prev로 그대로 돌려주니까 사용자 코드가 old를 ud에 담아 다니지 않아도 된다.

3. 반영 — settle()이 두 경로를 강제로 합친다

구현상 가장 중요한 판단은 정상 사이클과 소멸 루프가 같은 처분 함수를 공유하게 만든 것이다. settle(key, result, detach, pos) 하나가 wasMounted/wasDetached를 함께 보고 분기한다:

• detach면 → rawDetach(언마운트하되 소유권 유지), _detached로 이동. 이미 _detached에 있으면 wasMounted == nil이라 자연히 nop.
• result == prev인데 wasDetached면 → _detached에서 빼고 rawAdd = 재마운트.
• result == nil이면 → releaseElement(self, prev, wasDetached ~= nil).

두 경로가 갈라질 수 없게 만든 이유는 명확하다. 이 코퍼스에서 반복적으로 났던 버그(RC-1/RC-3/RC-4)가 전부 "비슷한 두 경로 중 한쪽만 고쳤다" 계열이었다.

rawRemove(소유권 해제 + 파괴) / rawUnmount(소유권 해제 + 파괴 안 함) / rawDetach(소유권 유지 + 파괴 안 함) 3형제로 분화한 것도 같은 이유 — "파괴하는가"와 "소유권을 놓는가"가 원래 한 축에 뭉쳐 있었는데, Detach는 정확히 파괴 안 하면서 소유권은 유지하는 조합이라 기존 둘로는 표현이 안 됐다.

4. Owned — Detach와 직교하는 두 번째 축

C-2(:List의 "밀려난 prev는 dispose"가 state<Frame> 의미론과 충돌)를 닫은 것이 이 축이다. 정리하면:

• Detach = 사이클 단위. "내 건데 잠깐 빼둠."
• Owned = 설치 단위. "애초에 내 게 아님."

이 둘이 직교한다는 걸 명시하고 나니 충돌이 사라졌다 — 값 교체 시 파괴는 Owned = true일 때 맞다(그 요소는 updateFn이 만들었고, :List가 안 지우면 아무도 못 지운다). 사용자가 state<Frame>에 담아 넘긴 요소는 Owned = false로 설치되고 어떤 경로로도 파괴되지 않는다.

5. attachSlot 분해 — 사용자가 비용 논거로 확정

3차 처리에서 F-4-3(setLength 위치)을 물었을 때, 사용자가 문제를 더 크게 재정의했다: "attachSlot 의 기능이 너무 다양해진게 문제같음."

핵심 진단은 C6과 C7이 한 함수 안에서 동시에 만족될 수 없다는 것이었다:

• C6: 부모에게 미는 길이(setLength(ownerKey, position, ...))는 flush가 끝나야 정해지는 최종값이어야 한다.
• C7: 부기는 물리 트리 조작보다 항상 먼저 끝나야 한다.

한 함수엔 setLength 슬롯이 하나뿐이라, 앞에 두면 C6 위반(부모가 1회 헛돎), 뒤에 두면 C7 위반이다. 함수를 둘로 쪼개면 각자 하나씩 만족한다.

사용자가 분해안(B)을 검토하고 낸 판단이 결정적이었다:

"오히려 안 쪼갤 이유가 정당하지 않아보이는게, 안 쪼갰을 때 구현 상 실수가 많아질 위험이 보임."

"이게 하나의 큰 복잡한 복합 함수라 여러 session 간의 실수가 발생하던 부분이고, 지금 적절한 방향으로 이동하지 않으면 계속 실수에 의한 시간/기술비용이 축적될것 같음. 지금 의사코드를 건들이는 비용이, 추후 실수가 누적되는 비용보다 싸다고 생각함."

이건 conventions.md의 "드문 오용이나 가상의 미래 요구까지 방어/최적화하려고 구조를 복잡하게 만들지 않는다" 원칙과 충돌하지 않는다 — 이 분해가 방어하는 건 가상의 미래 요구가 아니라 이미 세 번 관측된 버그 클래스(RC-1/RC-3/RC-4, 전부 "줄 순서를 잘못 잡아서")이기 때문이다. 분해하면 그 순서 제약이 줄 순서가 아니라 함수 경계로 강제된다.

사용자가 스스로 답한 우려

같은 회신에서 사용자가 유일한 우려를 제기하고 스스로 결론까지 냈다:

"다만 이렇게 된다면 얼마나 nested 든, 하나 마운트되고 하나 마운트되고... 각 객체들이 Parent = inst 되어가며 피지컬에 붙어가는 일자 진행인데, 이건 관측 이후 일괄 등록이라는 차이가 있는듯. 하지만 이미 리스트 액티베이션이 자신의 길이를 정확히 알려면 재귀를 뛰어야하는 부분이고 … 이런 사소한, 문제를 야기하기 어려운 동작을 원래와 동치시키기 위해 디버깅이 어려운 함수를 만드는건 옳지 않아보임."

확인해보니 Parent 대입 순서 자체는 안 바뀐다 — 바뀌는 건 ChildAdded 핸들러가 볼 때 서브트리의 Length/Offset이 이미 최종값이라는 점뿐이고, 옛 코드는 거기서 미완성 스냅샷을 보여줬다. 즉 이 변화는 동치성 손실이 아니라 엄밀히 더 정확해지는 방향이다. 분석 원문은 reference/slot-attach-decomposition.md 7절.

6. 이 세션이 안 한 것

• 5라운드 문항지를 만들지 않았다 — D절 회신의 "이후 stale 만 잡는것으로 끝낼 수 있어보임"에 따름.
• 스파이크 두 건은 미실행(01 재작성 = 단일 generalized for, table.insert 구멍 재사용 = R-11). 상태의 소스는 luau-test/STATUS.md.
• 이 분해로 Dispatch.drive도 같은 모양(부기/물리 분리)으로 맞출지는 일부러 미뤘다 — 지금 그게 아프다는 증거가 없다.

---

7. 반영 후 감사 — 트레이싱 각도가 문서 대조로는 안 보이던 크래시를 잡았다

H절 반영을 커밋한 뒤 사용자 요청으로 quad-doc-auditor를 6라운드 돌렸다 (관례대로 한 턴에 하나씩, 라운드마다 각도를 바꿈). 발견 추이:

라운드	각도	확실 발견
1	base/slot-plan.md 내부 문장 정합성	4
2	인덱스 레이어(README/ROADMAP/question/todos/STATUS)	6
3	archive/ + 바깥 base/ + reference/	2
4	의사코드 시나리오 손 트레이싱	3 (실제 크래시)
5	그 수정분의 회귀 트레이싱	3
6	수렴 확인	0

이 표에서 배울 것은 "단조 감소하지 않았다"는 점이다. 1~3라운드는 전부 "고친 결정이 다른 자리에 안 옮겨졌다"는 문서 정합성 유형이었고, 각도를 트레이싱으로 바꾼 4라운드에서야 실행이 깨지는 결함이 나왔다. 문서 대조를 몇 번 더 돌렸어도 이건 안 나왔을 것이다 — 세 건 다 각각의 문장은 정확했고, 서로 다른 두 문서의 정확한 문장이 한 실행 경로에서 만나면 죽는 종류였기 때문이다.

4라운드가 잡은 것의 공통 구조

셋 다 Detach가 신설한 새 경로가 기존 불변식과 부딪히는데 그쪽이 안 고쳐진 것이다. 특히 I-1이 뼈아프다:

• rawDetach는 일부러 releaseOwner를 안 부른다 — 소유권 유지가 이번 세션 설계의 핵심이었다.
• claimOwner는 일부러 같은 owner의 재클레임도 error다 — 2026-08-13 감사가 Slot { a, a }를 막으려고 엄격하게 만든 것이다.
• 둘 다 각자 맞는데, "prev를 그대로 돌려주면 재마운트"라는 이 세션이 확정한 권장 패턴이 정확히 그 교차점을 지난다. 그대로 구현했으면 문서가 권장하는 사용법이 첫 실행에서 죽었다.

claimOwner의 옛 논증 문단이 *"nested에서 '이미 내가 갖고 있는 걸 다시 클레임'하는 정당한 경로가 하나도 없으므로 무조건 error가 맞음"*이라고 단정하고 있었는데, 이번 세션이 그 "하나도 없는" 경로를 만들어놓고 그 문단을 안 읽은 것이다. 5라운드가 그 문단 자체를 따로 잡아냈다.

내가 감사 결론을 한 번 넘어선 곳

I-2의 멱등 가드는 사용자가 고른 안이지만, 그것만으로는 반쪽이었다. :List의 data:Observer는 bindLifetime(inst, observer)로 물리 target에 앵커돼 있는데 unmountSlotTree가 푸는 건 bk.observers뿐이라, 가드만 넣으면 포탈 재마운트 후 옛 target이 죽는 순간 살아있는 Slot의 :List가 조용히 반응을 멈춘다. _listObserver 핸들을 보관해 앵커만 옮기는 방식으로 마저 닫았고, 이건 _detachCleanup이 이미 받고 있던 처리와 같은 모양이라 새 패턴을 만든 것도 아니다. 5라운드가 그 수정의 파괴 경로 누락( destroySlotTree에는 안 넣은 것)을 다시 잡았다 — 비대칭 처리를 하나 추가하면 그 짝을 반드시 같이 훑어야 한다는 걸 다시 확인.

사용자가 판단한 것 (선택지 3개 제시 → 전부 추천안 채택)

1. 재마운트 경로 → claimOwner에 fromDetached 예외(대안: 전용 rawReattach 신설 / rawDetach가 소유권을 놓게 변경).
2. activateList 재실행 → 멱등 가드(대안: 인자로 전달 / 전용 경로에서만).
3. materializeSlotTree 중 예외 시 Blocker 잔류 → 문서화만 하고 pcall 안 씀. 근거는 conventions.md의 "드문 오용이나 가상의 미래 요구까지" 절 — 아직 실제로 밟은 적 없는 경로이고, 에러 경계는 base/fallback-plan.md가 담당한다. 이건 이번 분해가 만든 창이 아니라 옛 단일 attachSlot에도 있었을 구조적 갭이다.

부수 정리

2라운드가 luau-test/STATUS.md의 자기 규칙 위반을 잡았다 — "폴더가 곧 상태"라면서 재작성 대상 스파이크 01을 done/에 둔 채 ⚠️ 마커만 달아둔 것. git mv로 실제 이동시키고 개수를 맞췄으며, 같이 만들어야 할 스파이크 절을 신설했다. "아직 파일조차 없는 실측 항목"은 어느 폴더로도 표현이 안 돼 구조적으로 잊히는 자리였고, 실제로 followup H-7이 그 소스로 STATUS.md를 지목했는데 정작 항목이 없었다.

감사 종료 후 하나 더 — 사용자가 다른 에이전트와 상의해 가져온 두 건

_detachCleanup Effect 설치를 mountSlotTree → activateList로 이관, 그리고 activateList(self, inst)의 2번째 인자를 physicalTarget으로 리네이밍. 상세는 followup I-7.

여기서 짚어둘 것은 상호작용 하나다. 이관 제안의 근거가 *"materializeSlotTree가 _listed면 재마운트 때도 activateList를 다시 부르니 lifecycle이 보존된다"*였는데, 그건 오늘 오후에 내가 멱등 가드를 넣기 전의 동작이고 사실 그게 I-2의 버그였다. 가드가 있는 지금은 두 번째 호출이 early return하므로, 가드 분기가 _detachCleanup도 같이 재앵커하지 않으면 포탈 재마운트 후 detached가 영영 안 치워진다. 결론(이관)은 맞지만 근거가 한 세대 낡아 있었고, 그 자리를 메워 반영했다.

부수적으로 _listObserver와 _detachCleanup이 같은 범주로 통일됐다 — "activateList가 소유하고 물리 target에 앵커되는 자원"(생성 1회 / 언마운트는 앵커만 해제하고 핸들 보존 / 재마운트는 가드가 재앵커 / 파괴만 nil). 오늘 5라운드가 잡은 게 "비대칭 처리를 하나 추가하면 그 짝을 반드시 같이 훑어야 한다"였는데, 아예 비대칭을 없애는 쪽으로 정리된 셈이다.