qwreey
2688409ebd
- use-after-destroy 검증 안전망: rbvm 영역/quad-debug 스코프 밖으로 최종 기각, Ref 사용 관례(useRef급 스코프) 명문화 - :With 동적 의존성: State immutable 가정과 모순되어 의도적 비지원 확정 - Operator 콤비네이터 카탈로그: 서브 에이전트 외부 리서치로 포함 범위/ 네임스페이스 이름 근거 보강(Clamp/Min/Max 추가 후보, 비트/비교/Sub/Div 드랍 후보, Debounce/Throttle 별도 질문으로 분리) - State 용어 정리 최종 확정(현재 이름 유지), Pipe 기각 근거·Compute vs Computed 네이밍 근거 문서화, :With와 Tag/Modifier clone 체이닝 혼동 방지 경고 추가 Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01VVG74qV2nQVykhvMRQW2UC
3.2 KiB
2026-08-12 열여덟 번째 세션 — framework-comparison-findings.md 남은 두 항목 "고칠 필요 없음"으로 최종 판단
배경: question.md 낮은 우선순위 목록에 남아있던
framework-comparison-findings.md의 "고칠 만한 것" 2번 절 두 항목
(use-after-destroy 검증 안전망 부재, :With의 정적 의존성/동적 With
미지원)이 여전히 "사용자 판단 전" 상태였음. 사용자가 이번 세션에서 둘 다
명확한 근거를 들어 "고칠 필요 없음, 의도된 설계"로 확정.
use-after-destroy 검증 안전망
사용자 논지: quad는 bindLifetime으로 대부분의 연산을 GC-native하게
지원하도록 이미 설계돼 있고, 말단 leaf에 직접 연결하지 않는 이상 Instance를
직접 관리하는 건 quad가 처리하는 영역이 아님. 만일을 위한 부작용 정리
수단으로 Effect도 이미 제공됨. Destroy 시 정리해야 할 게 있다면, 그
부작용을 만들어낸 코드가 처리할 책임을 짐(Ref의 "Destroy 무관" 철학과
동일선상). 만약 quad가 이 영역에서 에러를 내주는 방향으로 간다면, 그건
언제나 명시적 Destroy() 호출을 강제하게 되어버려 "가볍게 GC가 알아서
치울 때 같이 처리되도록 놔두고 네이티브가 처리 성능을 올려주는" 아키텍처
전체와 모순됨. 완전한 UB 영역으로 두는 게 정확한 아키텍처 — quad가 할 수
있는 유일한 대응은 유저가 그런 행동을 안 하도록 문서화로 돕는 것뿐.
:With의 동적 의존성(동적 With 미지원)
사용자 논지: 동적 의존성을 지원한다는 것 자체가 "State는 immutable하다"는
현재 가정을 깨뜨림 — 의존성 목록이 바뀔 수 있다면 그 변경이 후행하는 다른
노드들 전체에 영향을 미치는 걸 허용해야 하는데, 이건 quad가 계속 원치
않아온 것. 애초에 동적 의존성이라는 것 자체가 사용 사례가 사실상 없음 —
React를 봐도 useMemo(fn, [...])의 deps 리스트를 동적으로 조립하는 경우는
거의 없고(그러면 그 훅이 거의 항상 실행돼버려 메모이제이션 의미가 없어짐),
보통 정적으로 나열함. 억지로 끼워넣는 건 무리 — 의도적 비지원 요소로 확정.
(State 이외의 다른 방법으로 유사한 걸 지원할 수 있는지 리서치는 나중에
해볼 수 있으나, 이미 결론에 다다른 현재 State 설계에 손을 대는 방향은
아님.)
반영
research/framework-comparison-findings.md: 2번 절(고칠 만한 것)에서 두 항목 제거, 3번 절(못 고치는 것 — 의도된 트레이드오프)로 근거와 함께 이전. "다음 단계" 절도 "해소됨"으로 갱신 — 이 문서는 더 이상 사용자 판단 대기 항목이 없음..claude/question.md: 낮은 우선순위 목록의 해당 항목을[해소됨]으로 표시.
부수 확인 (문서 반영 불필요, 현황 재확인만)
사용자가 같은 메시지에서 quad-v1-compat/quad-debug는 여전히
quad-base/quad-roblox 완성 전에 착수 가능해 보이지 않는다고 재확인 —
기존 CLAUDE.md/question.md가 이미 못박아둔 우선순위와 정확히 일치,
변경 없음.