빠른 흐름
Window > Analysis > Memory Profiler
스냅샷 캡처 -> 비교기본 흐름
메모리 프로파일링이 필요한 상황
Unity 공식 문서는 메모리 분석 도구로 기본 Memory Profiler 모듈과 추가 패키지 기반 Memory Profiler를 구분합니다. 메모리 문제는 로딩 시간 증가, 구형 기기에서의 크래시, 예상보다 큰 에셋이 그대로 런타임에 올라오는 상황 등 다양한 형태로 나타납니다. 런타임 CPU/GPU 성능과는 별개의 문제이므로, 프레임 드랍과 메모리 초과를 분리해서 접근하는 것이 중요합니다.
스냅샷 비교로 누수 추적하기
스냅샷을 저장하고 비교하면 누수, 예상보다 큰 에셋, 메모리 파편화 징후를 찾기 쉬워집니다. 전형적인 작업 흐름은 다음과 같습니다.
1. 메뉴 화면에서 스냅샷 A 캡처
2. 게임 플레이 10분 후 스냅샷 B 캡처
3. Compare Snapshots로 증가한 Texture, Mesh, Managed Object 확인
4. 해제되지 않은 참조나 큰 에셋 추적두 스냅샷을 비교하면 씬 전환 후에도 해제되지 않은 오브젝트나 불필요하게 메모리를 차지하는 에셋을 식별할 수 있습니다.
메모리 예산과 플랫폼 한도
타깃 기기의 RAM 한도와 프로젝트 메모리 예산을 먼저 정해 두면 어느 수준까지 줄여야 하는지 판단 기준이 생깁니다. 모바일 기기는 PC보다 훨씬 낮은 RAM 한도를 가지며, 한도를 초과하면 OS가 앱을 강제 종료합니다. 예산 안에서 Texture, Mesh, Audio 자산의 비중을 모니터링하고, 큰 자산은 압축 설정과 로드 방식을 함께 검토하는 것이 효과적입니다.
체크포인트
| 상황 | 적합한 선택 |
|---|---|
| 런타임 메모리 사용량 전체 파악 | Memory Profiler에서 스냅샷 캡처 |
| 씬 전환 후 메모리가 계속 늘어남 | Compare Snapshots로 증가 객체 확인 |
| 큰 Texture/Mesh가 런타임에 올라 있음 | 스냅샷에서 자산별 메모리 크기 분석 |
| 프레임 드랍 원인이 메모리인지 판단 | 메모리 문제와 CPU/GPU 병목을 분리해서 확인 |
| 의심 증상 | 먼저 볼 것 | 이유 |
|---|---|---|
| 플레이 시간이 길수록 메모리가 계속 증가 | 스냅샷 비교 | 누수와 참조 유지 여부를 추적하기 쉬움 |
| 특정 에셋 하나가 지나치게 큼 | Texture, Mesh, Audio 분포 | 메모리 예산 초과 원인을 자산 단위로 좁힐 수 있음 |
| 에디터에서는 괜찮고 기기에서 죽음 | 타깃 기기 메모리 예산 | 실제 OS 종료 한도는 기기별로 다름 |
| 프레임 드랍과 메모리 문제를 혼동함 | Profiler와 Memory Profiler 분리 | CPU/GPU 병목과 메모리 초과는 해결 방식이 다름 |
주의할 점
메모리 사용량이 높다고 바로 프레임 드랍 원인으로 단정하면 안 됩니다. 메모리 문제와 CPU/GPU 병목은 분리해서 확인해야 정확한 원인을 찾을 수 있습니다.
// ❌ "메모리 높음 → 프레임 드랍"으로 단정
// 실제 원인이 Update 루프 과부하인데 메모리만 최적화하느라 시간 낭비
// ✅ 증상별 도구 분리
프레임 드랍 → Profiler (CPU Usage, GPU 모듈)
메모리 증가/크래시 → Memory Profiler (스냅샷 비교)
// 씬 전환 후 메모리 누수 확인 흐름:
1. 메뉴 화면 → 스냅샷 A
2. 게임 플레이 → 씬 전환 반복 → 스냅샷 B
3. Compare A vs B → 해제되지 않은 Texture, Mesh, GameObject 확인스냅샷 하나만 보고 "원래 큰 씬이라서 이 정도는 정상"이라고 넘기면 누수를 놓치기 쉽습니다. 메뉴 진입 전후, 씬 반복 진입 전후처럼 같은 지점을 기준으로 비교해야 의미가 있습니다.
// ❌ 다른 장면끼리 스냅샷 비교
메뉴 화면 A vs 보스전 B
→ 장면 구성이 달라서 증가 원인 판단이 흐려짐
// ✅ 같은 조건으로 반복 비교
메뉴 화면 A
전투 진입/종료 반복
다시 메뉴 화면 B
→ B에서 남은 Texture, AudioClip, Managed Object를 확인참고 링크
2 sources