# [기각됨] 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하는 지금 방식이 버그 클래스를 균일하게
없애는 유일한 방법 — 확정 유지.
