quad/.claude/research/purity-and-effects-plan.md

컴포넌트 순수성이 아니라 "이식성" 문제 (재정의됨)

상태: research — 사용자 확인 완료로 문제 자체는 명확해짐, 남은 건 문서화 강도 정도. 원본: .claude/initreq/raw-userinput.md "순수함수에 대한 범위를 정할 필요가 있음" / "진짜 부작용은 외부에 만들어버린다" 절.

정정: "순수함수 여부"가 아니라 "이식성(portability)" 문제였다

사용자 확인 완료 — 이전 초안의 프레이밍이 부정확했음. quad는 vdom이 없으므로 컴포넌트(Class 함수)는 딱 한 번만 실행된다. 모든 부작용은 그 한 번의 실행에서 전부 등록됨 — store에 의해 렌더 함수 안 특정 부분이 다시 트리거될 순 있지만, 함수 자체가 반복 실행되는 구조가 아님. 이 전제 위에서 실제로 문제였던 것은 "순수함수냐 아니냐"가 아니라 컴포넌트가 자신이 받은 파라미터(store) 대신 전역(global) store를 직접 참조하는 경우의 이식성이었음.

구체적 문제 상황

컴포넌트가 특정 store를 받아서 렌더하도록 설계되어야 하는데, 그렇게 안 하고 전역 store를 직접 참조해버리는 경우:

• 그 컴포넌트가 한 게임 안에서 한 번만 쓰이는 존재(예: 특정 페이지에 해당하는 컴포넌트)라면 전혀 문제 없음 — 오히려 그게 자연스러울 수 있음.
• 하지만 여기저기서 재사용하려고 만들어둔 컴포넌트가 전역을 건드린다면 이식성이 망가짐 — 다른 프로젝트/다른 컨텍스트에 갖다 쓸 수 없게 됨.
• 라이브러리 내부적으로만 쓰는 공유 값(라이브러리가 의도적으로 내부에서 전역 상태를 만들어 쓰는 경우)은 문제 없을 수도 있음 — 이식성 문제는 "재사용을 의도한 컴포넌트가 자기가 받은 입력 밖의 것에 은밀히 의존하는가"에 국한됨.

결론: 입력받은 store만 처리하는 함수가 좋은 컴포넌트

재사용/이식을 의도하는 컴포넌트는 파라미터로 받은 store만 처리하는 게 좋다는 게 결론 — 다만 이건 기술적으로 막을 문제가 아니라 UB로 두고 사용자에게 경고해야 할 문서화 문제. 라이브러리가 "전역 참조 금지"를 런타임/타입 시스템으로 강제하려는 시도는 좋은 접근이 아니라고 명시적으로 판단함(과도한 엔지니어링, 정당한 유스케이스까지 막을 위험).

문서화 방향

• base/store-semantics.md("Store는 부작용을 허용하는 게 기본 디자인")와 같은 결의 문제 — Store 자체의 부작용 허용 여부와는 별개로, 컴포넌트가 "자기 입력 밖의 상태"에 의존하면 이식성이 깨진다는 원칙을 문서에 별도로 명시.
• 가이드 문서에 "재사용 가능한 컴포넌트를 만들 땐 store를 파라미터로만 받고 전역을 직접 참조하지 말 것 — 페이지/앱 최상위 컴포넌트처럼 애초에 재사용 의도가 없다면 상관없음"이라는 원칙과, 그 이유(이식성)를 예시와 함께 기술.
• 린트 규칙이나 런타임 경고 같은 기술적 강제는 하지 않음(확정) — 순수 문서 수준의 권장.

열린 질문

• 문서에 이 원칙을 얼마나 두드러지게(가이드 최상단 vs 각주 수준) 배치할지 — 급하지 않음, 실제 문서 작성 단계에서 결정.