모바일·저사양 게임 그래픽 최적화 우선순위 체크리스트

모바일 그래픽 최적화는 에셋을 무작정 줄이는 작업이 아니라 목표 기기에서 가장 큰 병목을 측정한 뒤 CPU 제출 비용, GPU 픽셀 비용, 메모리 대역폭 순으로 제거하는 작업이다. 일반적으로는 드로우 콜과 해상도·오버드로를 먼저 확인하고 이후 셰이더 변형과 텍스처·메시 메모리를 조정하는 편이 재작업이 적다.

모바일 및 저사양 기기 그래픽 최적화의 우선순위

먼저 목표 기기와 성능 목표를 수치로 고정한다. 예를 들어 30 FPS가 목표라면 한 프레임의 전체 예산은 다음과 같다.

frame\ budget=\frac{1000}{30}=33.33\ ms

60 FPS 목표라면 프레임 예산은 16.67 ms다. CPU와 GPU 중 어느 쪽이 초과하는지 확인하지 않은 상태에서 텍스처만 압축하거나 폴리곤만 줄이면 병목이 그대로 남을 수 있다.

우선순위	먼저 측정할 항목	대표 증상	주된 대응
1	CPU/GPU 프레임 시간	특정 장면에서 지속적인 FPS 저하	프로파일러로 병목 구간 분리
2	드로우 콜, 배치 수	CPU 프레임 시간이 높음	배칭, 머티리얼 통합, 가시성 제어
3	렌더 해상도, 오버드로	GPU 시간이 높고 투명 효과가 많음	렌더 스케일, UI·파티클 겹침 축소
4	셰이더 복잡도	화면 채움이 큰 객체에서 GPU 부하	텍스처 샘플·분기·패스 축소
5	텍스처·메시 메모리	로딩 끊김, 메모리 경고, 강제 종료	압축, 밉맵, LOD, 스트리밍
6	라이팅·그림자	카메라 이동 또는 광원 변화 시 급락	베이크, 그림자 거리·캐스케이드 축소

모바일 게임 장면에서 드로우 콜과 오버드로를 프로파일링하는 화면

어떤 병목부터 고쳐야 할까?

1. 목표 기기에서 CPU 병목과 GPU 병목을 분리한다

에디터 성능은 판단 근거가 되기 어렵다. 실제 Android 또는 iOS 빌드에서 Unity Profiler, Frame Debugger, Android GPU Inspector(AGI), Xcode Metal System Trace 같은 도구로 확인한다.

CPU 시간이 GPU 시간보다 크면 드로우 콜, 애니메이션 스킨닝, 파티클 시뮬레이션, 렌더 큐 제출을 우선 점검한다.
GPU 시간이 더 크면 렌더 해상도, 투명 오브젝트, 포스트 프로세싱, 그림자, 셰이더 픽셀 비용을 우선 점검한다.
프레임 시간이 주기적으로 튀면 GC, 에셋 로딩, 셰이더 컴파일, 텍스처 업로드도 함께 확인한다.

측정은 재현 가능한 조건에서 수행한다. 같은 기기, 같은 해상도, 같은 품질 설정, 같은 카메라 경로를 유지해야 수정 전후의 차이를 신뢰할 수 있다.

2. 드로우 콜은 머티리얼과 렌더 상태부터 줄인다

저사양 기기에서는 오브젝트 개수보다 서로 다른 머티리얼과 렌더 상태가 많은 장면이 더 비쌀 수 있다. 서로 다른 셰이더, 텍스처, 블렌드 모드, 렌더 큐는 배치를 끊는다.

실행 순서는 다음과 같다.

프레임 디버거에서 반복되는 머티리얼과 작은 메시 드로우를 찾는다.
같은 용도의 오브젝트는 가능한 한 같은 셰이더와 머티리얼을 공유한다.
정적 배칭, GPU Instancing, SRP Batcher 또는 Unreal Engine의 Instanced Static Mesh를 적용한다.
카메라에 보이지 않는 오브젝트는 컬링하고 먼 배경은 LOD 또는 임포스터로 교체한다.

Unity에서는 URP 프로젝트에서 SRP Batcher 호환 셰이더를 사용하고 인스턴싱 대상에는 동일한 Mesh와 Material을 유지해야 한다. 인스턴스마다 고유 머티리얼을 생성하면 배칭 이점이 사라질 수 있다.

오버드로와 투명 VFX는 왜 모바일 GPU를 느리게 만드는가?

투명 오브젝트는 대개 깊이 버퍼에 기록하지 않으며 뒤에서 앞 순서로 그려진다. 같은 화면 픽셀이 여러 번 셰이딩되면 픽셀 비용이 누적된다.

pixel\ cost\approx screen\ pixels\times overdraw\ count\times shader\ cost

특히 큰 반투명 파티클, 전체 화면 블러, 겹쳐진 UI 패널은 타일 기반 모바일 GPU의 메모리 대역폭과 필레이트를 빠르게 소모한다.

투명 효과를 줄이는 실무 체크리스트

큰 파티클은 화면 점유 면적과 최대 동시 재생 수를 제한한다.
알파 블렌드가 꼭 필요하지 않다면 컷아웃 또는 디더링 페이드 사용을 검토한다.
파티클의 소프트 파티클, 왜곡, 노멀 맵, 다중 텍스처 샘플은 저사양 품질 단계에서 끈다.
UI는 불필요한 중첩 패널과 전체 화면 반투명 이미지를 줄인다.
모바일 전용 품질 설정에는 렌더 스케일과 포스트 프로세싱 토글을 둔다.

렌더 해상도를 1/2로 낮추면 처리 픽셀 수는 대략 1/4가 된다.

\frac{W}{2}\times\frac{H}{2}=\frac{WH}{4}

따라서 GPU 병목 장면에서는 메시 폴리곤을 조금 줄이는 것보다 렌더 스케일, 오버드로, 전체 화면 효과를 조정하는 편이 더 큰 개선을 낼 때가 많다.

셰이더 최적화는 어떻게 우선순위를 정할까?

셰이더는 코드 길이보다 화면에서 실행되는 횟수가 중요하다. 화면을 크게 차지하는 물, 지면, 하늘, UI, 대형 VFX부터 확인한다.

셰이더 항목	비용이 커지는 조건	저사양 대응
텍스처 샘플	마스크·노멀·노이즈를 여러 장 사용	채널 패킹, 불필요한 샘플 제거
투명 블렌딩	대형 파티클과 중첩 레이어	면적·개수 축소, 컷아웃 검토
실시간 그림자	다수의 픽셀과 광원	그림자 거리·해상도 축소, 베이크
셰이더 키워드	변형 수가 과도하게 증가	품질별 변형만 유지, 미사용 제거
조건 분기	픽셀마다 다른 분기 발생	가능하면 머티리얼·변형으로 분리

Unity Shader Graph나 HLSL을 사용할 때는 텍스처 조회 횟수와 추가 렌더 패스를 우선 확인한다. 예를 들어 림라이트, 노멀 맵, 마스크, 디졸브, 왜곡을 하나의 이펙트에 모두 넣는 대신 저사양 품질에서는 디졸브와 왜곡을 끄는 식으로 기능을 계층화할 수 있다.

텍스처와 3D 에셋 메모리는 무엇을 확인해야 할까?

메모리 최적화의 목적은 파일 크기만 줄이는 것이 아니다. 런타임 텍스처 메모리, 로딩 시 업로드 비용, 대역폭, 캐시 효율을 함께 관리해야 한다.

텍스처 체크리스트

화면에서 거의 보이지 않는 텍스처가 2048 이상인지 확인한다.
플랫폼별 압축 포맷을 설정한다. Android는 기기 지원 범위를 고려해 ASTC 또는 ETC2를 iOS는 ASTC를 우선 검토한다.
3D 오브젝트 텍스처에는 밉맵을 유지하고 UI처럼 축소 표시되지 않는 텍스처만 밉맵 제거를 검토한다.
알파 채널이 필요 없는 텍스처는 불필요한 알파 저장을 피한다.
여러 작은 텍스처를 무조건 아틀라스로 묶기보다 반복 사용량과 밉맵 블리딩, 배칭 효과를 함께 확인한다.

메시에서는 카메라 거리별 LOD가 기본이다. 실루엣 변화가 적은 원거리 모델은 정점 수를 낮추고 보이지 않는 내부 면과 중복된 장식 메시를 제거한다. 스킨드 메시가 많다면 본 수와 동시 표시 캐릭터 수도 함께 제한한다.

라이팅과 그림자는 어디까지 실시간으로 유지해야 할까?

모바일에서는 실시간 그림자와 다수의 픽셀 라이트가 장면 전체 비용을 키우기 쉽다. 고정된 환경 조명은 라이트맵, Light Probe, Reflection Probe로 베이크하고 게임 플레이에 꼭 필요한 광원만 실시간으로 남긴다.

방향광 그림자는 거리, 해상도, 캐스케이드 수를 목표 기기에서 측정하며 줄인다.
작은 장식 광원은 베이크 조명 또는 Emissive 텍스처로 대체한다.
실시간 그림자가 필요한 캐릭터는 그림자 투사 거리와 대상 수를 제한한다.
포스트 프로세싱의 Bloom, SSAO, Depth of Field, Motion Blur는 저사양 품질 단계에서 기본 비활성화한다.

모바일 그래픽 최적화 작업 순서

flowchart TD
  A[목표 기기와 FPS 예산 고정] --> B[실기기 프로파일링]
  B --> C{CPU 병목인가?}
  C -->|예| D[드로우 콜·배칭·컬링 점검]
  C -->|아니오| E{GPU 병목인가?}
  E -->|예| F[해상도·오버드로·셰이더·그림자 점검]
  E -->|아니오| G[메모리·로딩 스파이크 점검]
  D --> H[수정 후 동일 경로 재측정]
  F --> H
  G --> H
  H --> I{목표 FPS 충족?}
  I -->|아니오| B
  I -->|예| J[품질 단계와 회귀 측정 고정]

이 순서를 지키면 “저사양 옵션”을 먼저 만들고 원인을 나중에 찾는 일을 줄일 수 있다. 변경 하나마다 평균 FPS뿐 아니라 1% low FPS, 최대 프레임 시간, 메모리 사용량도 기록한다. 평균이 좋아져도 짧은 끊김이 남으면 플레이 체감은 나쁠 수 있다.

자주 묻는 질문 (FAQ)

폴리곤 수를 줄이면 모바일 성능이 항상 좋아지는가?

아니다. GPU가 픽셀 셰이딩이나 투명 오버드로에 묶여 있다면 폴리곤 감소 효과는 작을 수 있다. 먼저 CPU·GPU 병목을 분리해 측정해야 한다.

드로우 콜은 몇 개 이하여야 하는가?

절대값보다 목표 기기에서의 CPU 프레임 시간이 기준이다. 장면 특성, 엔진 파이프라인, 배칭 상태에 따라 달라지므로 특정 숫자만 목표로 삼기보다 프레임 디버거로 배치가 끊기는 원인을 찾는 편이 안전하다.

텍스처 압축 품질이 나쁘면 해상도를 올려야 하는가?

대개 아니다. 먼저 ASTC 블록 크기, 채널 구성, 밉맵, 샘플러 설정을 조정한다. 해상도 증가는 메모리와 대역폭을 함께 높이므로 실제 화면 크기와 중요도를 기준으로 결정한다.

정리

모바일 및 저사양 기기 그래픽 최적화의 핵심은 측정 후 우선순위를 정하는 것이다. CPU 병목이면 드로우 콜과 배칭을 GPU 병목이면 해상도·오버드로·셰이더를 메모리 병목이면 텍스처와 에셋 구성을 먼저 고친다. 모든 변경은 목표 기기에서 같은 조건으로 다시 측정해 성능 개선과 시각 품질 손실을 함께 확인하자.