qa: 10라운드 결정 반영 (H-147~H-158) — fn/cleanup 자기 구독 금지, Refresh 캐치업 폐기, 루트는 Claim으로

- H-147 (A): fn/cleanup은 자기 구독을 못 바꾼다 — rawRerun(force)/Rerun 분리, 진입 canExecute 게이트,
  네 진입점+_bindDestroying에 _running/_cleanupRunning 가드, H-143(원샷) 소멸, 자기 leaf 파괴 UB
- H-148: 루트는 밖에서 .Parent=가 아니라 quad가 Claim으로 소유 → research/existing-mount-plan.md 신설,
  H-146 예외·전용 문구 폐기, archive 부활 배너
- H-149 Observer 진입점 인라인 / H-150 Effect._blocker 제거 / H-151 _epochs는 emit 때만(게이트는 emit 경로만
  미룬다 계약) / H-152 GateNode StateBrand:register / H-153 Store 예약 이름 런타임 가드 + 그림자=store 자신 /
  H-154 InstanceChildHandler dedup / H-155~H-157 stale
- 감사 3→5→2→3→1→0, /code-review high 10건 중 7 반영, 셋(H-159~H-161)은 -round10.md §4 문항으로

Co-authored-by: qwreey <me@qwreey.moe>
Claude-Session: https://claude.ai/code/session_01546hjsYNLSMZdHdPyTZaGb

2026-08-28 13:00:49 +09:00

6 KiB

Raw Blame History

[기각됨] 이미 생성된 인스턴스에 대한 바인드

⛔ [2026-08-14 세션, 사용자 확정 — 기각] research/에서 archive/로 이전. 더 이상 "열린 가능성"이 아니라 미지원으로 확정.

⭐ [2026-08-28] 좁은 형태로 부활 — research/existing-mount-plan.md. 여기서 기각된 것은 *"이미 있는 Instance에 나중에 새 props를 다시 바인드"*이고 그 사유(바깥이 자식 구성을 밀고 당기면 부기가 깨진다)는 그대로 유효하다. 부활한 것은 그 반대 방향 — 한 번 Claim하면 quad가 소유하고 직계 자식은 사용자가 전부 매핑한다(claim-once · own-all, 재바인드는 여전히 미지원). 루트(PlayerGui)와 Clone() 템플릿이 그 용도다.

기각 사유(사용자): 이게 가능하다고 하면 Dispatch.setOffsetSource/ setLength(base/dispatch-core-plan.md의 "Length/Offset" 절) 같은, quad가 자기가 만든 트리에 대해서만 성립한다고 전제하고 세운 부기를 바깥에서 밀고 당기는 부가 작용이 전부 가능해짐 — 즉 기능 하나가 열리는 게 아니라 버그를 일으키기에 치명적인 표면이 대량으로 노출됨. 그 표면을 다 막으려면 quad가 "내가 만들지 않은 Instance의 자식 구성이 언제 어떻게 바뀌는지"까지 추적해야 하는데, 그건 research/framework-comparison-findings.md가 use-after-destroy 안전망을 기각할 때 쓴 것과 같은 이유(Instance 가상화/추적은 rbvm 같은 전문 라이브러리의 영역, quad가 재발명하면 오버엔지니어링)로 스코프 밖임.

아래 원문은 기각 전 서술 그대로 보존(당시엔 "미정 유지"가 결론이었음). 관련해서 이미 지적돼 있던 긴장은 두 곳 — research/pre-implementation-audit.md 2-4(Slot의 "엄격한 단일 마운트 소유권" 불변식과 근본적으로 충돌), base/architecture.md의 "복사 구현 지양, store 바인드 변경은 전체 변경" 원칙. 둘 다 이번 기각으로 해소됨.

관련 기능이 필요해지면: quad가 만들지 않은 Instance를 다루는 정상 경로는 Ref(외부 관리 instance를 점진적으로 다루기 위한 직접 참조 획득, base/ref-plan.md)와 Effect(base/effect-plan.md)뿐 — 그 둘로 안 되는 걸 이 문서로 되살리려 하지 말 것.

상태: 기각됨(원래 research/ — 명시적으로 후순위/UB 후보였음). 원본: .claude/initreq/raw-userinput.md "이미 생성된 객체에 대한 바인드?" 절.

문제

이미 생성된 Roblox Instance에 새로운 {k=v} 프롭 테이블을 나중에 바인드하는 걸 허용할지. 허용하려면 이전 바인드를 끊는 처리가 필요한데, retract가 구현되어 있어도 바로 지원하는 건 엔지니어링 비용이 높음.

기울어진 방향

UB로 두거나, 마일스톤(추후 구현)으로 미룬다. retract가 이미 있고 store 바인드도 우선순위 높은 플러그라면 이론적으로는 가능해 보이지만(핸들러 레지스트리가 이미 "우선순위 스캔 후 bind" 구조라 재바인드도 같은 경로를 타면 됨), 초기 구현에서 우선순위를 낮게 잡아야 함 — 문제 유무가 많을 수 있어서.

Default 값과 얽히는 문제

Default를 넣으면 더 어려워짐 — Default로 쓰다가 실제 쓰인 값으로 되돌아가는 케이스를 생각해야 함. Modifier 설계와 맞물려 있는 문제로, 결과적으로 매번 테이블을 flattening 해야 할 수도 있음 — 그런데 그걸 위해 클론까지 해야 하나? 사용자 스스로도 "약간 애매" 하다고 남김.

후보 아이디어(미확정): ref로만 다시 바인드 가능한 걸 얻게 하고, ref가 되면 복사(clone) 모드를 켜야 하나 — 근데 그러면 너무 복잡해질 것 같다는 우려까지만 기록. 결론 없음.

관련: Modifier flatten 자체의 clone 정책(변환마다 table.clone, immutable 확정)은 이미 base/modifier-plan.md의 "3. Immutable 값 + clone 기반 체이닝" 절에서 다뤄짐 — 단 그건 "Modifier 값 자체의 clone"이고, 여기서 미정인 건 "이미 마운트된 Instance에 대한 재바인드 시점의 Default→실값 flatten"이라 층위가 다름, 새로 설계하지 않고 참고 링크만.

사용자 확인 결과: 진짜로 모르겠음 — 열린 가능성으로 유지

사용자 확인 완료, 그러나 결론은 "미정 유지". 실제로 이 기능을 원한다고 말한 사용자를 본 적은 없지만, 막상 만들어진다면 유용하게 쓸 수 있을 것 같다는 느낌은 있음. 근거:

retract(구 cleanup)이 이미 존재한다면, store 바인드도 이미 retract되는 경로가 있는 셈 — 재바인드를 지원하기 위한 인프라가 어느 정도 이미 깔림.
Modifier를 잘 설계하면 나중에 오버라이드가 자연스럽게 가능해질 수도 있음 — 미래에 어떤 방법을 생각해낼 여지가 있다는 것.
역사적 맥락: quad는 원래 "script 스니펫"이라고 부를 정도로, react.lua 같은 당대 대안 대비 압도적으로 쉽고 단순해서 누구나 빠르게 이해해 쓸 수 있는 걸 의도적으로 지향한 도구였음. 라이브러리가 지금처럼 몸집이 커지는 후속 단계에선 이런 기능성을 충분히 고려할 만함.

결론: v2 초기 스코프에서 제외하되, "미지원"으로 확정 명문화하지는 않음 — 진짜 열린 가능성으로 남겨두고, 실사용 중 필요성이 드러나면 그때 설계. base/architecture.md의 "복사 구현 지양, store 바인드 변경은 전체 변경" 원칙과 긴장 관계에 있다는 점은 여전히 유효 — 나중에 설계할 때 이 원칙과 어떻게 공존할지부터 다시 볼 것.

열린 질문 (`.claude/question.md`에도 취합)

구체적 설계는 완전히 미정 — 실사용 패턴이 쌓이기 전까지는 착수하지 않음. 급하지 않음.

6 KiB Raw Blame History