모듈 로딩 단계와 LoadingPhase 선택 기준
8강. 모듈 로딩 단계와 LoadingPhase 선택 기준
1. 이번 강의에서 해결할 문제
Reflection 타입을 사용하는 Asset이 초기 로드될 때 플러그인 클래스가 없어 실패하거나, 반대로 단순 Editor 도구가 너무 이른 단계에 로드돼 초기화되지 않은 Subsystem을 접근합니다. LoadingPhase를 무조건 PreDefault로 당기면 문제를 숨길 수 있지만 시작 비용과 초기화 순서 결합이 커집니다.
2. 학습 목표
3. 핵심 개념
Module Type은 어떤 Target에서 로드 가능한지 정하고 LoadingPhase는 해당 Target 시작 과정에서 언제 로드할지 정합니다. Runtime 모듈이 반드시 일찍 로드되는 것도, Editor 모듈이 항상 늦게 로드되는 것도 아닙니다.
| Phase | 대표 판단 | 주의점 |
|---|---|---|
PreDefault | Default Game Module보다 먼저 타입 등록이 필요 | 남용하면 초기화 순서 결합 증가 |
Default | 일반 Runtime·게임플레이 Module | 대부분의 기본 선택 |
PostDefault | Default Module 뒤 의존 초기화 | 선행 모듈 준비를 명시 |
PostEngineInit | Engine 초기화 뒤 Editor UI·도구 | 매우 초기 Asset 로드에는 늦을 수 있음 |
None | 명시적으로 필요할 때 Load | 호출자가 실패·Unload를 관리 |
세부 Phase 목록과 의미는 UE 버전의 ELoadingPhase::Type을 확인합니다.
4. 단계별 실습
{
"FileVersion": 3,
"Modules": [
{
"Name": "ReusableInteraction",
"Type": "Runtime",
"LoadingPhase": "Default"
}
]
}
{
"FileVersion": 3,
"Modules": [
{
"Name": "DataGuardEditor",
"Type": "Editor",
"LoadingPhase": "PostEngineInit"
}
]
}
DataGuard 메뉴가 PostEngineInit에서도 정상 등록되는지 확인합니다. 특정 Asset이 Runtime 클래스 등록 전에 Deserialize된다는 로그가 실제로 있을 때만 ReusableInteraction을 PreDefault로 조정합니다. Phase 변경 전후에 Module Startup 시간과 호출 가능한 Subsystem을 기록합니다.
5. 코드가 동작하는 이유
Descriptor는 ModuleManager가 시작 단계별 목록을 만들 때 사용합니다. 같은 Phase 안의 Module 간 순서는 의존성 없이 결정적이라고 가정할 수 없습니다. 특정 Module이 반드시 먼저 필요하면 Build.cs 의존성과 명시적 LoadModuleChecked 등 코드 계약을 사용합니다.
6. 자주 하는 실수와 해결법
7. 직접 실습
8. 이해 점검 질문 3개
9. 핵심 요약
모듈 로딩 단계와 LoadingPhase 선택 기준 미니 퀴즈
선택 즉시 정답과 해설을 확인할 수 있습니다. 결과는 이 브라우저에만 저장됩니다.
학습을 마쳤나요?
직접 실습과 점검 질문까지 확인한 뒤 완료로 표시하세요.