quad/.claude/archive/modifier-apply-mutable-rejected.md

[기각됨] Modifier Apply/setter를 mutable로 바꾸는 방안 (전체·절충안 둘 다)

상태: 후보였다가 채택 안 됨(확정한 적 없이 검토 후 기각) — base/ modifier-plan.md 9-1번 절에서 이 판단의 결론(판단 기준 자체는 "동질적/ 이질적"이 아니라 "계산 의존성 유무")만 남기고 아래 전체 경위는 이 문서로 옮김. batch-rejected.md/context-rejected.md와 같은 카테고리 — quadnomicon 소재 후보.

배경

2026-08-07 다섯 번째 세션 후속. Apply 체이닝이 호출마다 clone을 만들기 때문에, 항목 수천 개짜리 리스트 UI처럼 무거운 Modifier를 대량으로 재생성하는 상황에서 이 clone 비용이 누적되는 게 아닌지 사용자가 우려 — 대안으로 (a) Apply/setter를 아예 mutable로 바꾸는 방안, (b) Overridden를 "여러 값을 합칠 특수 상황"이 아니라 "성능 최적화 수단"으로 승격하는 방안을 검토했음(이 문서는 (a)와 그 절충안만 다룸 — (b)는 기각되지 않고 "계산 의존성 유무" 판단 기준으로 정리되어 modifier-plan.md 본문에 그대로 남음).

(a) Apply를 mutable로 바꾸는 방안 — 기각

3번 절에서 immutable+clone을 확정한 이유가 정확히 "같은 modifier 레퍼런스를 공유하는 형제 서브트리가 mutate로 오염되는 것"을 막기 위해서였음 — 이건 특정 세션 판단이 아니라 2026-08-04부터 계속 지켜온 하드 제약. Apply/setter가 mutable이면 여러 컴포넌트가 참조하는 공유 테마 상수 하나에 어느 한쪽이 체이닝만 해도 다른 쪽까지 같이 바뀌는 클래스의 버그가 그대로 돌아옴 — clone 비용 절감이 이 안전성보다 우선순위가 높다고 볼 근거가 없어 기각. (단, table.clone은 Luau native shallow-copy라 Modifier 필드 수(한 자리~여남은 개) 기준 개별 clone 비용 자체는 이미 3번 절에서 무시 가능하다고 판단됨 — 이번에 새로 문제 삼는 건 "한 번 비용의 크기"가 아니라 "체인 길이 × 인스턴스 수로 누적되는 clone 횟수"라는 별개 축.)

(a-1) 절충안 — "Apply 진입 시 한 번만 clone하고 그 안에서는 mutable로" — 검토했으나 기각

clone 횟수를 체인 길이만큼이 아니라 Apply 호출당 1번으로 줄이자는 아이디어(Apply 경계에서만 복사, 내부 setter들은 그 복사본을 그대로 mutate).

기각 이유: 이렇게 해도 버그 클래스 자체가 안 없어짐 — Apply를 거치지 않고 setter를 직접 호출하는 흔한 경로(mod:FontSize(...)처럼 체이닝 자체가 아니라 단발 호출)는 여전히 mutable이라, 공유 레퍼런스에 대고 단발 setter 하나만 불러도(예: 서브트리 어딘가에서 폰트 두께만 살짝 바꾸는 경우) 그대로 오염됨 — "Apply 안에서는 안전, 밖에서는 안 안전"처럼 어디서 터지느냐만 달라질 뿐 문제 자체는 그대로 남는 비일관적인 절충이라 실익이 없음. 전부 clone하는 지금 방식이 버그 클래스를 균일하게 없애는 유일한 방법 — 확정 유지.