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

**상태**: base — 확정됨(2026-08-04 세션에 `research/`에서 승격). 남은 건
가이드 문서 내 배치 위치 정도로 기술적 결정 사항은 없음. 원본:
`.claude/initreq/raw-userinput.md` "순수함수에 대한 범위를 정할 필요가 있음" /
"진짜 부작용은 외부에 만들어버린다" 절.

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

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

### 구체적 문제 상황

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

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

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

## 문서화 방향

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

## 열린 질문

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