quad/.claude/research/framework-comparison-findings.md

quad vs Fusion/Vide/react-lua — 정직한 비교 (2026-08-06)

상태: research — 3개 에이전트가 각각 Fusion(.claude/initreq/fusion 실 소스), Vide(.claude/initreq/vide 실 소스), react-lua(로컬 클론 없어 웹 리서치)를 직접 읽고 quad의 확정 설계와 대조. 목적은 마케팅이 아니라 정직한 자가점검 — "quad가 진짜 나은 부분"(나중에 초심자/quadnomicon 문서의 "왜 quad인가" 소재)과 "quad가 진짜 불리한 부분, 그중 고칠 수 있는 것"을 사용자가 직접 검토하기 위함. quad는 구현 0줄 상태라 모든 비교가 "검증된 프로덕션 코드 vs 종이 설계"라는 근본적 비대칭을 안고 있음 — 아래 모든 강점/약점은 이 전제하에 읽을 것.

1. quad가 실제로 나은 점 (소스 근거 있음, 향후 "왜 quad인가" 문서 소재)

• Slot 단일 마운트 가드 — Fusion·Vide 둘 다 없음, 실재하는 버그 클래스를 막음. Fusion Children.luau엔 -- TODO: check for ancestry conflicts here 주석이 그대로 남아있고 이미 마운트된 인스턴스를 조건 없이 재부모화함(조용한 이중 마운트). Vide mount.luau도 중복 마운트 체크가 전혀 없음. quad의 "이미 마운트된 Slot 재마운트 시 즉시 throw"는 둘 다에 없는 실질적 안전장치.
• 열린 우선순위 축 — Fusion의 하드코딩된 4단계보다 확장성 좋음. Fusion applyInstanceProps.luau는 {self, descendants, ancestor, observer} 정확히 4개 버킷만 갖고 5번째를 쓰면 에러남. quad의 열린 숫자 우선순위 레지스트리는 커스텀 bind key를 라이브러리 수정 없이 임의 우선순위에 끼워넣을 수 있음.
• 명시적 의존성이 여러 버그 클래스를 원천 차단. Vide는 전역 scopes 스택 기반 암묵 추적이라 리액티브 스코프 안 yield가 그래프를 깨는 걸 막기 위해 별도 ycall 장치까지 둠(graph.luau). quad의 명시적 :With 의존성 전달은 이 버그 클래스 자체가 발생하지 않음.
• 다이아몬드 의존성 재계산 dedup — Vide가 스스로 미해결로 남긴 문제를 더 구조적으로 해결. Vide todo.md가 diamond 그래프 중복 재평가 방지를 미해결로 인정했고, 실제로 test/tests.luau의 "recursive queue flush diamond" 테스트가 이상적 2회 대신 3회 실행됨을 재현함. quad의 invalid 플래그 dedup은 이걸 원시 레벨에서 막도록 설계됨.
• fine-grained라 vdom 특유의 버그 클래스가 통째로 없음(vs react-lua). react-lua는 리스트 diffing을 위해 key 관리가 필요하고(불안정하면 자식 상태 유실), hooks 호출 순서 규칙이 있으며(위반 시 "Rendered fewer/more hooks" 에러), 고빈도 갱신엔 리렌더를 우회하는 별도 API(Bindings)를 공식적으로 추가해야 했음(react-lua 스스로 "vdom 재조정만으론 부족하다"고 인정한 셈). quad는 모든 값이 동일한 push-invalidate/pull-recompute 모델이라 이 세 문제 자체가 없음.
• Tween을 그래프 밖에 둬서 구조적 복잡도를 회피. Fusion Animation/ Tween.luau는 Stopwatch+ExternalTime 그래프 노드와 checkLifetime.bOutlivesA 교차 lifetime 검증까지 필요한 3중 장치. quad엔 이 장치 자체가 없음(단, 반대급부는 아래 3번 참고).

2. quad가 불리한 점 중 — 고칠 만한 것(fixable, 검토 가치 있음)

• use-after-destroy 검증 안전망 부재. Fusion Memory/checkLifetime.luau는 "짧게 사는 스코프가 오래 사는 대상에 바인딩됐다" 같은 실수를 사람이 읽을 수 있는 에러 메시지로 즉시 잡아줌. quad base/lifecycle-pattern.md엔 이런 사전 검증 개념이 없음. GC-native 프로덕션 동작 자체를 바꿀 필요는 없고, 개발/Studio 모드 한정 옵트인 검증 레이어(quad-debug류와 결합 가능)로 추가하는 정도는 GC-native 철학과 안 부딪히고 고려해볼 만함.
• :With(...) 정적 의존성 목록 — Fusion의 동적 재평가보다 약함. Fusion evaluate.luau는 매 평가마다 실제 use()된 의존성만 다시 구독해 특정 라운드엔 조건부로 일부 의존성을 아예 구독 안 할 수 있음. quad는 :With 에 나열한 목록이 Compute 시점에 고정돼, lazy handle로 재계산 트리거는 피해도 무효화 신호 자체는 계속 도착해 불필요한 재-Get이 누적될 수 있음. 동적 With 등록/해제 API 정도로 완화 가능해 보임 — 우연한 갭에 가까움.
• Store dot-access가 매 접근마다 새 State를 할당 — [해소됨, 2026-08-06 세 번째 세션] 이 항목이 직접 트리거가 되어 Source/State 관계 자체를 재구성(store-semantics.md "Source가 State를 만족함" 절) — Store가 이제 생성 시 만들어둔 Source를 그대로 반환해 wrapper 할당 자체가 없어짐, 구현 단계 최적화가 아니라 설계로 완전히 없앰(캐싱/풀링보다도 쌈).

3. quad가 불리한 점 중 — 못 고치는 것(의도된 트레이드오프, "고친다" 개념 자체가 안 맞음)

• 암묵적 추적의 인체공학적 우위(vs Vide) — derive() 안에서 그냥 호출하면 의존성이 잡히는 Vide 대비, quad는 전부 :With에 나열해야 해 보일러플레이트가 늘어남. quad가 "Lua에서 암묵 추적은 부작용 관찰이 필요해 지저분하다"는 이유로 의도적으로 거부한 결과라, 명시성을 유지하는 한 고칠 개념 자체가 아님(경감책은 있을 수 있음 — 아래 4번 참고).
• Tween이 그래프 밖이라 다른 Compute의 입력으로 자유롭게 합성 불가(vs Fusion/Vide) — Fusion Tween/Spring, Vide spring()은 그래프 노드라 다른 파생값의 입력으로 얽어 쓸 수 있음. quad는 Fusion을 반면교사 삼아 의도적으로 이 경로를 포기한 것이라 원 설계 취지와 충돌. 필요해지면 옵트인 브릿지 추가가 현실적 타협(지금 급한 건 아님).
• GC-native 라이프사이클 자체가 안고 있는 리스크 — Vide는 GC와 Instance.Destroying 순서가 비결정적이라는 알려진 함정 때문에 의도적으로 eager·수동 cleanup을 택함. quad의 "수동 dispose 불필요"는 GC 의존을 없애려면 결국 Vide식 수동 owner 트리로 돌아가야 해서 철학과 충돌 — 다만 base/lifecycle-pattern.md의 rbvm 실물 검증 근거로 리스크는 이미 어느 정도 완화돼 있음(기존 base 문서 참고).
• DOMless+컴포넌트 1회 실행 때문에 "지금 트리가 어떻게 생겼는가"를 한눈에 재구성하기 어려움(vs react-lua) — react-lua는 렌더마다 전체 서브트리를 선언적으로 다시 기술해 현재 상태가 코드 한 곳에 드러남. quad는 변화가 개별 leaf bind에 흩어져 처리돼 복잡한 조건부 트리 추론이 어려움. 근본 선택에서 필연적으로 따라오는 트레이드오프라 설계 변경으론 해소 안 되고, quad-debug 같은 관측 도구로만 보완 가능(이미 백로그에 있음 — research/debug-tooling-plan.md).

4. 성숙도 격차 — 설계 결함 아니지만 지금 시점 비교에선 정직하게 명시해야 함

Fusion(~5000줄+테스트+수년 실사용), Vide(2800줄+테스트+0.1.0→0.4.1 하드닝 이력), react-lua(Roblox 사내 실사용+전용 벤치마크 레포)는 전부 실전에서 발견되고 고쳐진 문제들의 산물. quad는 구현이 0줄이라 이 비교의 강점 항목도 전부 M0 스파이크 이후 실제 Luau로 검증돼야 신뢰할 수 있고, 구현이 진행되면 유사한 이유로 비슷한 안전장치를 뒤늦게 추가하게 될 가능성이 있음(1번의 use-after-destroy 검증처럼). "hooks 없는 quad의 :With/:Compute가 React 커스텀 훅만큼의 합성성을 실사용 규모에서 주는가"도 지금은 데이터 없음 — 고칠 문제인지조차 판단 이를 정도로 이름.

다음 단계

이 문서 자체는 지금 당장 뭘 바꾸라는 결정문이 아님 — 사용자가 직접 검토 후 판단할 항목:

• 2번의 남은 두 가지(use-after-destroy 검증, 동적 With)를 실제로 설계에 반영할지, 반영한다면 언제(M0 스파이크 때 같이 검증할지, 나중 최적화 패스로 미룰지). 세 번째(Store dot-access 할당)는 위에서 이미 해소됨.
• 1번 강점 목록은 research/documentation-content-map.md의 "왜 quad를 쓰는가" 초심자/quadnomicon 콘텐츠 소재로 재사용 가능.