quad/.claude/session/2026-08-07-05-override-peek-isstate.md

2026-08-07 다섯 번째 세션 — Modifier 결합(Override)/읽기 접근자(Peek)/isState 확정, FuncSource 기각 사유 문서화

출발점: :Apply(4번째 세션 신설)처럼 Modifier에 더 있으면 좋을 게 있는지 사용자가 제기 — Merge류 결합 유틸의 우선순위 문제, 그리고 Modifier 자신이 자기 필드 값을 못 읽는 게 애매하다는 지적(예: Boldify가 폰트별 굵기 보정을 하려면 현재 Font 필드를 읽어야 함). 같은 스레드에서 "Source가 항상 정해진 값만 담아야 하는 이유가 확정된 건지, FuncSource(람다로 계산+self-emit하는 Source) 같은 건 왜 없는지"도 같이 물어옴.

핵심 결론(전부 base 문서에 반영 완료):

• Modifier.Override(mod1, mod2, ...) — component-composition-plan.md 3번 절에 2026-08-04부터 가칭 Merge로 이미 확정돼 있던 결합 유틸의 실제 동작을 확정하고 이름을 Override로 개명(중립적 "합침"이 아니라 명시적 "덮어쓰기"라 이름이 의미를 정직하게 반영해야 함). 뒤 인자가 필드 단위로 이김(기존 배열 flatten 규칙 재사용), 구현은 단순 필드별 raw 교체 — setter가 이미 호출 시점에 함수/State를 즉시 처리해 저장하므로 Modifier 필드는 항상 baked 값이라 특별한 분기 불필요. "baked 값 교체는 거기서 파생된 다른 필드에 소급 반영 안 됨"(Boldify가 FontWeight를 계산해 둔 뒤 Font가 Override로 바뀌어도 FontWeight는 예전 값 그대로)과 순서 의존성(A:Override(B) ≠ B:Override(A)) 둘 다 문서 경고 대상으로 확정. Apply로 전부 대체해 Override를 없애는 방안도 검토했으나 기각 — 컴포넌트 경계(props.Modifier는 단일 named parameter라 배열 flatten이 안 닿음)라는 이미 확정된 실사용 니즈를 Apply만으로는 못 풀어서. base/modifier-plan.md 9번 절.
• :Peek<<T>>(key): T|State<T>|nil — Modifier 필드를 확정(pull+recompute) 하지 않고 raw 그대로 읽는 접근자. Get이 아니라 Peek인 이유는 이 프로젝트에서 State:Get()이 이미 "확정한다"는 의미로 굳어져 있어서 — Modifier의 읽기는 정반대(State면 State 핸들 그대로) 동작이라 같은 동사를 못 씀. 반환 타입을 T로 자동 확정하지 않고 union 그대로 노출하는 이유는 4-1번 절 함수형 setter의 old 인자와 같은 원칙("현재 저장된 그대로 넘김") 재사용 — 자동 확정하면 타입에 안 드러나는 채로 반응성이 조용히 끊김. .RealValue 같은 별도 인덱싱 표면은 기각(이미 __index가 setter 합성용으로 예약돼 있어 표면이 겹침).
• isState(x): boolean — Peek의 raw union을 분기하려면 필요. Source가 State를 구조적으로 만족하므로 이거 하나로 Source도 같이 잡힘(isSource 불필요). duck-typing 대신 weak-key 레지스트리로 구현 (rbvm 네임스페이스 추적과 같은 패턴 재사용) — Peek가 돌려주는 T가 임의의 테이블/userdata일 수 있어 duck-typing은 false positive나 일부 Roblox userdata의 인덱싱 에러(pcall 필요)로 이어질 위험이 있음. 이 판별 로직 자체는 새 개념이 아니라 4-1번 setter가 이미 내부적으로 해야 했던 "필드가 State냐 plain이냐" 판별을 public 유틸로 승격한 것. base/bind-system-plan.md의 isState 절.
• FuncSource(값이 람다로 계산되고 self-emit하는 Source) 기각 — 사용자가 스스로 기각 논리를 제시했고("이미 Compute가 커버함"), 검증 결과 이미 확정된 두 원칙에서 그대로 연역됨: (1) Source는 "시작점"이라 다른 반응형 값에 자동 연결 안 됨(2026-08-04 6차 라운드, "Store가 Store를 담지 않는다" 확정 때 나온 원칙) — FuncSource는 다른 반응형 값에 종속된 계산이면서 겉으로는 origin인 척하는 것이라 이 원칙과 직접 충돌. (2) :With가 clone 빌더가 아니라 진짜 노드여야 하는 이유(2026-08-07 세 번째 세션)가 "의존성이 구조적으로 안 보이면 디버그 그래프가 깨진다"였는데, FuncSource의 람다가 클로저로 캡쳐한 의존성은 정확히 그 문제를 재현함. 실제로 커버 안 되는 유스케이스도 없음 — "다른 반응형 값에서 계산"은 Compute, "clone 불가능한 값을 밖에서 바꾸고 알림"은 원천 Source+Emit으로 이미 전부 커버됨. 새 결정이 아니라 기존 확정 사항의 논리적 귀결이라 별도 base 절 신설 없이 여기 세션 요약으로만 기록(quadnomicon 소재로 재사용 가능하도록).

같은 세션 바로 후속 — 문서화 톤 보강(사용자 강조): Override는 범용 조합 도구가 아니라 Frame{mod1, mod2}의 컴포넌트 경계판(단일 named parameter 슬롯에 독립적으로 만들어진 값 두 개 이상을 넣어야 하는 특수 상황)으로 좁게 문서화할 것 — "특정 modifier를 계속 바꿔나간다"는 요구는 항상 Apply + 커링/일급 함수 전달을 기본 관용구로 유도. Apply 자체도 factory(self) 호출 sugar 그 이상이 아니라는 걸 명시 — factory가 Peek한 값이 기대와 다르면 error를 던지든 뭘 하든 전부 factory 저작자 책임, Apply가 검증/보장을 대신 해준다고 오해하면 안 됨. 둘 다 base/modifier-plan.md 8/9번 절에 반영 완료.

같은 세션 두 번째 후속 — Apply vs Override 성능 기준 확정. "무거운 Modifier를 대량 생성할 때 Apply의 clone 비용이 누적되지 않냐"는 우려에서 두 방안 검토 후 결론: Apply를 mutable로 바꾸는 방안은 기각(3번 절 immutable 확정 이유 — 형제 서브트리 오염 방지 — 가 clone 비용 절감보다 우선순위 높음, 재확인). 대신 판단 기준을 "이질적/동질적 프로퍼티"가 아니라 "필드 간 계산 의존성 유무"로 명확화 — 한쪽이 Peek으로 다른 쪽의 baked 값을 읽어 반영해야 하면 이질적으로 보여도 Apply, 서로 완전히 독립이면 동질적으로 보여도 Override 가능. 계산 의존성 없는 재사용 조각(배경/텍스트/레이아웃처럼 서로 다른 서브시스템이 한 번만 만드는 값)은 모듈 상수로 만들어두고 인스턴스마다 Override로 결합하는 게 실제 최적화 패턴 — 단 이건 "Override가 내부적으로 캐싱해준다"가 아니라 사용자가 값을 재사용하는 평범한 패턴일 뿐, 라이브러리에 새 캐싱 레이어가 생기는 게 아님을 문서에 명시하기로 함. base/modifier-plan.md 9-1번 절.

같은 세션 세 번째 후속 — "Apply 경계에서만 clone, 안쪽은 mutable" 절충안도 검토 후 기각. clone 횟수를 체인 길이가 아니라 Apply 호출당 1번으로 줄이는 절충을 사용자가 직접 제시했으나, Apply를 거치지 않고 setter를 단발로 직접 호출하는 흔한 경로는 여전히 mutable이라 공유 레퍼런스가 그대로 오염될 수 있음(서브트리에서 폰트 두께만 바꿔도 터짐) — "어디서 터지느냐만 달라지는" 비일관적 절충이라 실익 없다고 판단해 기각. 전부 clone하는 현재 방식 유지 확정. base/modifier-plan.md 9-1번 (a-1) 절.

같은 세션 네 번째 후속(당시 CLAUDE.md에 미기록 — 2026-08-07 여섯 번째 세션에서 뒤늦게 발견/보강) — Override가 서브타입 관계인 Modifier끼리 섞일 때의 타입 시그니처는 미검증으로 열어둠. FrameModifier가 GuiObjectModifier의 서브타입이어야 자연스러운데, 필드 setter 메소드의 리턴 타입이 각자 자기 자신이라(self) 단순 구조적 서브타이핑만으로 Modifier.Override(guiObjectMod, frameMod)류가 통과하는지 추론만으로는 결론 못 냄 — 후보안(메소드 필드는 any로 뭉개고 데이터 필드만 구조적 체크)을 실 Luau로 검증 필요, 안 되면 Override(...: any): any로 느슨하게 열고 이 항목으로 되돌아오는 걸 fallback으로 남김. base/modifier-plan.md 9-2번, ROADMAP.md M7에 체크박스 반영 완료.

다음 세션이 할 일: 안 바뀜(위 2026-08-06 네 번째 세션 절 참고, ROADMAP.md M0부터) — 이번 세션도 순수 설계 확정이라 M0 착수 우선순위 자체는 그대로.

미해결로 남긴 것 — 임의로 결론내지 않음: Effect가 state:Effect() 형태로 Observer를 확장하는 변형인지, 완전히 독립된 free function인지가 불명확함(사용자가 "확인 필요, 아니라면 논의해야 할 상태로 남겨두라"고 명시). 관련 하위 질문으로 state:Observer(fn)가 생성 시 fn을 즉시 1회 실행하는지도 문서 어디에도 명시돼 있지 않음이 이번에 드러남(Effect는 "즉시 1회 실행"이 스펙에 명시돼 있어 이 부분만 보면 둘이 겹쳐 보임). base/effect-plan.md의 "미해결" 절과 .claude/question.md 0번에 반영 — 구현 착수(M3~M4 전후) 전에 반드시 재확인할 것.

다음 세션이 할 일: 안 바뀜(위 2026-08-06 네 번째 세션 절 "다음 세션이 할 일" 참고, ROADMAP.md M0부터). 이번 세션은 순수 문서 정리라 설계 결정 자체는 늘지 않았음 — 단, M3 체크리스트에 Blocker.luau 항목이 하나 추가된 것과, 위 Effect/Observer 미해결 항목은 M3~M4 착수 전에 확인해야 함.