빠른 흐름
Window > Analysis > Profiler기본 흐름
Profiler가 하는 일
Unity Profiler는 에디터와 연결된 디바이스 빌드에서 CPU, GPU, 메모리, 렌더링 흐름을 계측하는 핵심 도구입니다. 어느 스크립트가 얼마의 시간을 쓰는지, GC 할당이 어디서 발생하는지, 렌더링 병목이 어느 구간인지를 프레임 단위로 추적할 수 있습니다. Unity 공식 가이드는 성능 측정을 출시 직전 한 번이 아니라, 프로젝트 전반에 걸쳐 반복적으로 하라고 권장합니다.
타깃 기기에서 측정해야 하는 이유
에디터 수치만 믿기보다 실제 타깃 기기 빌드에서 확인해야 더 정확한 병목을 찾을 수 있습니다. 에디터에서는 빠르게 동작하던 코드가 모바일 기기에서는 전혀 다른 병목 패턴을 보이는 경우가 흔합니다. Development Build로 빌드한 뒤 Profiler를 연결해 실제 장면을 재현하면 에디터에서는 보이지 않던 문제를 발견하기 쉽습니다.
1. Development Build로 기기 실행
2. Profiler에서 CPU Usage 모듈 확인
3. 프레임 스파이크 구간 선택
4. Main Thread / Render Thread / Scripts 원인 추적프레임 시간 관점으로 읽기
프레임 시간 관점으로 보는 습관이 중요하며, 목표 프레임 시간과 현재 측정값을 계속 비교해야 합니다. CPU Usage 모듈에서는 스크립트와 메인 스레드 비용을, GPU 모듈에서는 렌더링 병목을, Memory 모듈에서는 메모리 사용량 흐름을 확인합니다. 반복 계측을 통해 성능 회귀를 일찍 발견할수록 수정 비용이 줄어듭니다.
체크포인트
| 상황 | 적합한 선택 |
|---|---|
| 어느 스크립트가 시간을 쓰는지 모름 | CPU Usage 모듈 → Main Thread 계층 확인 |
| 렌더링이 느린지 물리가 느린지 구분 필요 | GPU 모듈 + CPU Render Thread 분리 확인 |
| GC 할당 발생 지점 파악 | CPU 모듈에서 GC.Alloc 마커 추적 |
| 에디터에서 빠른데 기기에서 느림 | Development Build → 타깃 기기 연결 후 측정 |
| 먼저 구분할 질문 | 먼저 열 것 | 이유 |
|---|---|---|
| 프레임 시간이 CPU 쪽 문제인가 | CPU Usage | Scripts, Physics, UI 비용을 바로 좁힐 수 있음 |
| 렌더링 병목이 의심되는가 | GPU 모듈 + Rendering 구간 | 렌더링과 스크립트 병목을 분리할 수 있음 |
| 메모리 증가가 핵심인가 | Memory Profiler | Profiler만으로는 스냅샷 비교가 부족함 |
| draw call 흐름을 눈으로 봐야 하는가 | Frame Debugger | 명령 순서와 overdraw는 별도 도구가 더 직관적임 |
주의할 점
에디터 수치를 실기기 성능이라고 신뢰하면 안 됩니다. 실제 병목은 Development Build를 타깃 기기에서 측정해야 정확하게 보입니다.
// ❌ 에디터에서만 프로파일링 — 모바일 병목 놓침
Window > Analysis > Profiler
// 에디터에서 4ms → 기기에서 22ms 인 경우 흔함
// ✅ 타깃 기기에서 측정
1. Build Settings → Development Build 체크
2. 기기에서 앱 실행
3. Profiler → 기기 선택 → Record
4. 실제 병목 장면 재현 → 스파이크 구간 분석평균 프레임 시간만 보고 넘어가면 짧은 스파이크를 놓치기 쉽습니다. 특히 로딩 직후, 전투 진입, UI 열기 같은 재현 구간은 타임라인에서 스파이크 패턴까지 같이 보세요.
// ❌ 평균 14ms라서 괜찮다고 판단
평균만 확인 → 실제로는 1초마다 45ms 스파이크 발생
// ✅ 평균 + 스파이크 구간 같이 확인
1. 타임라인에서 튀는 프레임 선택
2. 해당 프레임의 Main Thread 계층 열기
3. GC.Alloc, Physics.Simulate, Canvas rebuild 같은 급증 구간 확인참고 링크
2 sources