숏컷 코드
text
씬 안에서만 쓰는 것
-> scene scope
여러 씬이 공유하는 것
-> app/root scope
씬 로딩 때마다 전역 resolve 남발
-> 경계가 흐려짐문법과 예시
Scene DI는 "이 의존성이 씬 수명주기를 따르는가"부터 판단한다
전투 HUD, 전투용 presenter, 씬 전용 enemy spawner처럼 씬과 함께 생기고 사라지는 것은 scene scope가 자연스럽습니다. 반대로 저장, 계정, 설정, 공통 로깅처럼 여러 씬이 공유하는 것은 상위 root나 app scope에 두는 편이 맞습니다.
text
App Root
-> SaveService
-> SettingsService
Battle Scene Scope
-> BattleHUDPresenter
-> EnemySpawner
-> BattleResultCoordinator씬은 전역 서비스 해상 지점이 아니라 local composition 지점이 되는 편이 좋다
씬 로딩 후 필요한 의존성을 한 번 조립하고 나면, 그 안의 객체들은 직접 협력해야 읽기 쉽습니다. 각 컴포넌트가 아무 때나 전역 locator에서 resolve를 시작하면 scene boundary가 사라집니다.
가장 흔한 실패는 모든 것을 전역 scope에 올려 두는 것이다
처음엔 편해서 presenter, coordinator, 씬 전용 캐시까지 전부 DontDestroyOnLoad 영역이나 global container에 올리기 쉽습니다.
하지만 이 방식은 씬 종료 시점과 초기화 시점을 흐리게 만들어, 누수와 재진입 버그를 키웁니다.
scene scope를 고를 때 핵심
| 상황 | 더 자연스러운 선택 |
|---|---|
| 씬과 함께 생성되고 사라지는 협력 객체일 때 | scene scope |
| 여러 씬에서 공유되는 공통 기능일 때 | app/root scope |
| 씬 로드 직후 한 번만 wiring하면 될 때 | scene composition |
| 각 컴포넌트가 전역 resolve를 반복할 때 | scene boundary 재설계 |
| 종료 시점과 dispose 책임이 모호할 때 | scope 기준부터 다시 분리 |
특이 케이스와 주의할 점
흔한 실패는 씬 전용 presenter나 coordinator를 전역 singleton처럼 오래 살리는 것입니다. 이 방식은 씬 재진입, 테스트, 메모리 정리에서 바로 비용이 드러납니다.
text
실패 예시
- BattleHUDPresenter를 global container에 등록해 여러 전투 씬에서 재사용
- EnemySpawner가 매번 global locator에서 SaveService, AudioService, LootService를 직접 resolve
결과
- 씬 수명주기와 의존성 수명주기가 어긋남
- 초기화/해제 책임이 흐려짐