최적화
게임 개발을 비롯한 다양한 소프트웨어 개발에서 **최적화(Optimization)**는 필수적인 요소다.(튜닝 이라고 말하기도 한다.)
혹시 프레임이 끊기고, 한 시간에 여러 번 크래시가 발생하는 앱을 계속 실행하고 싶은가?
당연히 아니다.
하지만 개발 중 최적화를 소홀히 한다면, 이런 예시가 자신이 만든 제품에서 현실이 될 수 있다.
그래서 이 글에서는 기본적으로 어떤 부분을 고려해야 하는지를 정리해보려 한다.
0. 마음가짐
0.1 튜닝은 추측이 아닌 원인 파악
- 성능 튜닝은 정확한 원인 분석이 핵심이다.
- 절대 추측으로 접근하지 말고, 반드시 원인을 확인하고 작업할 것.
0.2 튜닝 전후 비교는 필수
- 튜닝을 했으면 반드시 튜닝 전과 후를 프로파일러로 비교해야 한다.
- 성능이 좋아졌다고 생각했지만, 다른 부분의 부하로 전체 성능이 오히려 나빠질 수 있음.
- 본말이 전도된 튜닝은 다시 검토하자.
0.3 반드시 실제 기기에서 테스트
- 에디터가 아닌 실제 기기에서 성능 측정 진행.
- 에디터의 프로파일링 결과는 신뢰도가 낮음.
- 실제 환경에서 발생하는 이슈는 기기에서만 확인 가능하다.
1. 목표 기기 선택
- 스마트폰 기종이 너무 다양해 모든 기기를 지원하는 건 불가능.
- 따라서 **목표 기기(Target Device)**를 정해 해당 기기에서 성능 테스트를 진행하자.
- 해당 기기의 사양을 기준으로 최소 권장 사양을 결정하면 된다.
2. 품질 설정
- 아래 항목들을 고 / 중 / 저 품질로 구분하여 사용자 선택이 가능하도록 설정하자.
설정 항목 예시:
- 화면 해상도
- 오브젝트 표시 수
- 그림자 유무
- 포스트 이펙트 기능
- 프레임 속도 제한
- CPU 부하가 높은 스크립트 생략 기능
단, 시각적인 품질이 낮아질 수 있으므로 프로젝트 관리자와 협의 필수.
3. 실시간 성능 시각화
- 성능 저하는 일종의 버그와 같다.
- 시간이 지나면 원인을 찾기 어려워지므로, 실시간으로 모니터링하자.
예시: 화면에 성능 정보 띄우기
- 현재 프레임 속도 (FPS)
- 현재 메모리 사용량
- 메모리 누수 여부 확인
색상 구분 예시:
- 25~30 FPS → 초록색
- 20~25 FPS → 노란색
- 20 FPS 이하 → 빨간색
4. 성능 저하의 종류
4.1 크래시
- 대부분 메모리 초과 또는 실행 오류 두 가지로 구분됨.
- 실행 오류는 튜닝과는 무관, 메모리 초과에만 집중하자.
4.2 프레임 드랍 또는 로딩 지연
- 대부분 CPU 또는 GPU 처리 시간이 원인.
4.1 메모리 초과 원인: 메모리 누수
- 메모리 누수 여부를 확인하기 위한 기본적인 방법:
- 해결 팁: 중간에 빈 씬을 한번 로딩해 리소스를 강제로 정리할 수 있음.
4.2 단순 메모리 사용량 과다
- 누수는 없지만 사용하는 리소스가 너무 많아서 발생하는 경우
- 이럴 경우 리소스 구조나 압축률 등 최적화 전략 필요
4.3 메모리 누수 조사 툴
- Unity 기본 제공 툴: Profiler, Memory Profiler
- 유용한 외부 툴: Heap Explorer (패키지 매니저 통해 설치 가능, Unity 2020 기준)
4.4 메모리 최적화 관련
- 가장 큰 부분부터 줄이는 것이 중요하다.
1.Assets
Simple view에서 Assets 관련 항목이 많은 경우 불필요한 리소스나 메모리 누수 가능성이 많다. 에셋 관련은 노란색 박스로 표시해 놓았다.
불필요한에셋조사
불필요한에셋은현재씬에전혀필요하지않은리소스를말합니다.
예를들어타이틀화 면에서만사용하는BGM이게임내에서도메모리에상주하고있는경우등이있습니다
규정체크하기
• 크기는적절한가?
• 압축설정이적절한지
• MipMap 설정이적절한가?
• Read/Write 설정이 적절한지
2. 버벅거림 원인 파악
화면 처리 지연은'순간적인 처리지연'인지 '상시적인 처리지연'인지에 따라 대처 방법이 달라진다.
순간척인 처리지연은 프로파일러에서 순간적으로 튀는 구간이 있는데 해당 구간을 스파이크라고 이야기한다.
위의 사진에서는 정적부하와 순간부하가 같이 나오고 있다.
3.조사하기
우선 정적과 순간 스파이크가 동시에 뜬다면 순간 스파이크를 먼저 해결해야한다.
우선 원인이 GC인지 아닌지 구분을 해야 하는데 원인 규명 자체에는 Deep Profile이 필요하지 않지만 해결을 위해서는 필요하다.
3.1GC가 원인이라면?
GC.Alloc<유니티의 GC가 메모리를 차지하는 양>을 줄여야 한다.
어떤 프로세스가 얼마나 많이 할당하고 있는지는 DeepProfile을 이용하면 좋다.
우선적으로 줄여야 할 부분은 비용 효율성이 높은 부분입니다.
- 매 프레임마다 할당하는 부분
- 대량의 할당량이 발생하는 부분
할당량은 적을수록 좋지만 , 반드시 제로가 되어야 한다는 의미가 아니다.
EX)Instantiate등 에서 할당하는 GC는 어쩔수가 없다.
3.2과부하로 인한 스파이크
GC가 원인이 아니라면 어떤 무거운 처리가 순간적으로 이루어지고 있다는 것이다. 이 경우에 도 딥프로파일을 이용하여 어떤 처리가 무거운지 조사하고,가장 많은 시간이 소요되는 부분을 찾아본다.
- 대량의 Instantiate가 실행되는지
- 대량의 오브젝트 또는 계층 구조가 깊은 오브젝트 활성 전환
- 화면 캡처 처리등
이렇게 프로젝트에서 다양한 원인들이 존재하므로 절대적인 원인은 존재하지 않는다.
프로파일러를 통해 원인을 분석하고 팀원과의 회의를 통해 해결해야한다.
3.3정적 부하 조사하기
정적부하를 처리할때는 1 프레임 내 처리를 어떻게 줄일 수 있느냐가 중요하다.
1프레임 내에서 이루어지는 처리는 크게 CPU 처리와 GPU 처리가 있는데 우선 이 두가지 처리 중 어떤 부분에서 병목 현상이 일어나는지 확인을 해야한다. 아니면 동일한 수준의 처리 부하인지도 확인 해야한다.
CPU의 병목현상을 CPU바운드 GPU 병목현상을 GPU바운드라고 한다.
3.4CPU 바운드
DeefProfile을 이용하여 조사하고 특정 알고리즘에 큰 처리 부하가 걸리지 않는지 확인한다.
큰 처리 부하가 없다면 균등하게 무겁다는 뜻이므로 꾸준하게 개선을 하거나 품질 설정 부분에서 추가 최적화를 진행한다.
3.5GPU 바운드
대부분 렌더링 과정에서 일어나는 경우가 많으며 반드시 Frame debugger을 통해서 조사하는 것이 좋다.
해상도가 적절한지 확인한다. GPU 바운드 중에서도 해상도는 GPU처리의 큰 부분을 차지한다.
따라서 해상도를 적절하게 설정하지 않은 상태라면 우선적으로 적절한 해상도를 설정하는 것이 최우선이다.
3.51 해상도 설정
Frame Debugger 내에서 처리하고 있는 렌더 타깃의 해상도에 주목하는 것이 좋다.
만약 의도적으로 다음 사항을 구현하지 않았다면 최적화 작업을 진행해야 한다.
- UI 요소만 디바이스의 전체 해상도로 렌더링 되고 있다.
- 포스트 이펙트를 위한 임시 텍스터츼 해상도가 높은 경우
3.52 불필요한 오브젝트 존재 여부
Frame Debugger의 에서 불필요한 렌더링하는 객체가 없는지 확인해야한다.
예시로 필요없는 카메라가 켜져있다거나 오버드로우가 일어나는 경우가 있다.
또한 3D 같은 경우에는 오클루전 컬링등을 통해 렌더링 과정을 최소화 해야 한다.
*단 오클루전 컬링은 미리 계산하여 메모리에 저장을 하므로 필요에 맞게 사용을 해야 한다.
3.53 적절한 배칭
그리기 대상을 한꺼번에 그리는 것을 일괄적으로 처리하는 것을 배치라고 한다. 한꺼번에 그려짐으로써 그리기 효율이 높아지기 때문에 GPU바운딩에서 큰 효과가 있다.
하단은 GPU바운딩이 일어났을때 최적화를 진행하는 대표적인 방법들이다
- Static Bating
- Dynamic Batching
- GPU 인스턴싱
- SRP Batcher등
3.54 개별적으로 부하 살펴보기
개별적으로 부하가 심한 경우
- 오브젝트의 버텍스 수가 너무 많거나<리덕션 , LDO를 고려한다>
- 그리는 오브젝트가 너무 많거나 <최소한의 드로우콜로 진행이 가능한지 확인>
- 복잡한 Shader에서 간단한 Shader로 변경이 가능한지
그외에 GPU연산이 쌓여서 무거워 졌다고 말 할 수 있다.
이또한 최적화 진행 후 목표치에 달성하지 못했다면 품질 설정을 다시 시작하는게 좋다.
'최적화' 카테고리의 다른 글
| 튜닝<그래픽> (1) | 2025.06.17 |
|---|---|
| 튜닝 - 물리(Physics) (1) | 2025.06.15 |
| 에셋 관련 최적화 (1) | 2025.06.01 |
| 튜닝 기본 상식(2) (0) | 2025.05.17 |
| 최적화<튜닝>의 기본상식1 (4) | 2025.05.11 |
