모바일 전략 (1) - 발열과 배터리 - soo:bak

작성일 : 2026년 02월 21일

모바일만의 제약: 발열과 배터리

데스크톱 게임 최적화에서는 보통 한 프레임 안에서 CPU나 GPU가 어디에 시간을 쓰는지 찾고, 그 병목을 줄이는 것이 핵심입니다. 냉각 여유와 전력 공급이 비교적 크기 때문에, 개별 프레임의 실행 시간을 줄이면 성능 문제가 상당 부분 해결되는 경우가 많습니다.

모바일에서는 상황이 다릅니다. 시작 직후에는 목표 프레임레이트를 유지하더라도, CPU와 GPU 부하가 계속 누적되면 기기가 감당할 수 있는 전력과 열의 한계에 가까워집니다. 이때 문제는 특정 함수 하나의 비용이 아니라, 장시간 유지 가능한 부하 수준입니다.

데스크톱은 전력 공급과 냉각에 비교적 여유가 있지만, 모바일 기기는 제한된 배터리와 작은 방열 면적 안에서 동작합니다. 같은 16.6ms 프레임 예산을 만족하더라도 전력 소모가 크면 배터리가 빠르게 줄고, 열이 누적되면 이후의 성능도 흔들립니다.

따라서 모바일 성능은 짧은 시간의 피크 성능만으로 판단하기 어렵습니다. 실제 플레이 시간에 가깝게 실행했을 때 프레임레이트, 입력 반응, 배터리 소모, 기기 온도가 함께 안정적으로 유지되는지를 봐야 합니다. 이 글에서는 이런 관점에서 서멀 쓰로틀링의 메커니즘, 이에 대응하는 플랫폼 API, 전력 예산의 구조, 그리고 프레임레이트 선택의 트레이드오프를 다룹니다.

서멀 쓰로틀링 — 모바일 성능의 근본 제약

모바일 기기의 SoC(System on Chip)에는 CPU, GPU, 메모리 컨트롤러, ISP, 모뎀 같은 여러 블록이 밀집해 있습니다. CPU와 GPU가 높은 클럭으로 오래 동작하면 전력 소비가 열로 바뀌고, 칩 온도가 안전 범위에 가까워지면 시스템은 과열을 막기 위해 CPU와 GPU의 최대 클럭을 낮춥니다. 이것이 서멀 쓰로틀링(Thermal Throttling)입니다.

짧은 벤치마크나 앱 실행 직후의 측정값은 대체로 기기가 차갑고 클럭을 높게 유지할 수 있는 상태의 피크 성능(Peak Performance)에 가깝습니다. 반면 게임은 렌더링, 물리, 애니메이션, UI 같은 작업을 실제 플레이 시간 동안 계속 반복합니다. 시간이 지나 열이 누적된 뒤에도 유지할 수 있는 성능이 지속 성능(Sustained Performance)이며, 모바일 게임의 프레임레이트와 품질 설정은 이 지속 성능을 기준으로 잡아야 합니다.

게임 시작 직후에는 목표 프레임레이트가 나오다가 시간이 지난 뒤 같은 장면에서 프레임 시간이 길어지는 현상은, 코드 경로가 갑자기 바뀌어서가 아니라 클럭 제한으로 같은 작업을 더 낮은 성능에서 처리하기 때문에 발생할 수 있습니다. 따라서 모바일에서는 초반 피크 성능보다 열이 누적된 뒤의 지속 성능을 기준으로 설계해야 합니다.

발열의 메커니즘

서멀 쓰로틀링을 줄이려면 먼저 열이 왜 쌓이는지 이해해야 합니다. 모바일 게임이 직접 제어할 수 있는 것은 기기의 냉각 구조가 아니라, CPU와 GPU가 매 프레임 소비하는 전력과 그로 인해 발생하는 열입니다.

열 발생

SoC가 전력을 소비하면 그 에너지의 상당 부분은 결국 열로 바뀝니다. 게임 부하에서는 CPU와 GPU의 트랜지스터가 계속 스위칭하고, 화면 해상도, 셰이더 복잡도, 물리 연산, 메모리 접근이 늘어날수록 소비 전력도 증가합니다. 동적 전력은 보통 $P_{dynamic} \approx \alpha C V^2 f$로 근사할 수 있습니다. 여기서 $\alpha$는 실제로 스위칭되는 비율, $C$는 회로의 커패시턴스, $V$는 전압, $f$는 클럭 주파수입니다.

클럭만 높아져도 전력은 증가하지만, 실제 고성능 상태에서는 안정적인 동작을 위해 전압도 함께 올라가는 경우가 많습니다. 전압은 수식에서 제곱으로 작용하므로, 높은 클럭과 높은 전압이 겹치면 전력과 발열이 빠르게 늘어납니다. 모바일에서 해상도나 프레임레이트를 높였을 때 발열이 급격히 증가하는 이유가 여기에 있습니다.

데스크톱 CPU와 GPU는 수십~수백 W의 열을 처리할 수 있는 냉각 구조를 전제로 설계됩니다. 반면 스마트폰 SoC는 기기와 방열 구조에 따라 다르지만, 장시간 지속해서 감당할 수 있는 전력 범위가 훨씬 좁습니다. 모바일 SoC가 순간적으로 높은 성능을 낼 수 있더라도, 얇은 기기 안에서 그 열을 계속 배출할 수 없다면 결국 클럭을 낮춰야 합니다.

데스크톱과 모바일의 열 처리 방식 비교

항목	데스크톱 PC	스마트폰
전력 공급	콘센트 전원을 사용하므로 순간 전력 사용에 비교적 여유가 있음	배터리 전력을 사용하므로 전력 소비가 사용 시간과 발열에 직접 연결됨
열 발생 위치	CPU와 GPU가 별도 칩과 별도 쿨러를 사용하는 경우가 많음	CPU와 GPU가 같은 SoC 안에 있어 열이 한 지점에 집중되기 쉬움
열 배출 방식	방열판, 팬, 수냉 라디에이터 등 능동 냉각 사용 가능	베이퍼 챔버, 금속 프레임, 후면 커버를 통한 수동 방열에 의존
지속 성능	냉각 설계가 충분하면 높은 클럭을 오래 유지하기 쉬움	열이 누적되면 클럭 제한으로 성능이 단계적으로 낮아질 수 있음

열 방출의 한계

스마트폰에서 SoC의 열은 기판, 흑연 시트나 베이퍼 챔버, 금속 프레임, 후면 커버를 거쳐 기기 표면으로 퍼지고, 마지막에는 주변 공기로 빠져나갑니다. 팬이 없으므로 열을 밖으로 밀어내는 능동 냉각보다는, 기기 내부에 열을 넓게 분산시키고 표면에서 자연스럽게 방출하는 방식에 의존합니다.

베이퍼 챔버나 히트파이프는 이 과정에서 칩 주변의 열을 더 넓은 면적으로 옮기는 역할을 합니다. 하지만 열을 분산시킬 뿐, 팬처럼 외부로 강제로 배출하지는 않습니다. 그래서 열 발생 속도가 표면을 통한 방열 속도보다 빠르면 내부 온도는 계속 올라갑니다.

기기 표면 온도와 칩 내부의 정션 온도(Junction Temperature)도 다르게 봐야 합니다. 정션 온도는 트랜지스터가 실제로 동작하는 반도체 접합부의 온도이며, 사용자가 손으로 느끼는 표면 온도보다 먼저 위험 구간에 가까워질 수 있습니다. 구체적인 임계치는 SoC, 기기 설계, 제조사 정책에 따라 다르지만, 내부 온도가 안전 범위에 가까워지면 시스템은 CPU와 GPU의 클럭을 낮춰 열 발생을 줄입니다.

쓰로틀링은 보통 한 번에 끝나는 이벤트가 아니라 단계적으로 진행됩니다. SoC 내부의 CPU와 GPU는 같은 전력·열 예산을 공유하므로, 한쪽의 부하가 커지면 다른 쪽이 사용할 수 있는 여유도 줄어듭니다. 온도가 올라가면 시스템은 먼저 최대 클럭을 낮추거나 고성능 코어 사용을 제한하고, 상황이 더 나빠지면 더 강한 성능 제한을 적용할 수 있습니다. 극단적인 경우에는 앱이 종료되거나 기기가 성능 보호 모드로 들어갈 수 있습니다.

외부 환경도 쓰로틀링 시점에 영향을 줍니다. 주변 온도가 높으면 기기 표면에서 공기로 열이 빠져나가기 어렵고, 두꺼운 케이스나 충전 중 사용도 발열 조건을 악화시킬 수 있습니다. 같은 빌드라도 여름철 실외 테스트와 겨울철 실내 테스트, 케이스 착용 여부, 충전 상태에 따라 쓰로틀링이 시작되는 시점이 달라질 수 있으므로, 성능 테스트에서는 이런 조건을 통일하고 함께 기록해야 합니다.

Adaptive Performance

서멀 쓰로틀링이 시작된 뒤에는 게임이 원하는 성능을 유지하기 어렵습니다. 시스템이 온도 보호를 위해 클럭을 제한하면, 같은 작업도 더 오래 걸리고 프레임레이트가 흔들릴 수 있습니다. Adaptive Performance는 이 상태에 도달하기 전에 기기의 열 상태를 읽고, 해상도, 그림자, LOD, 후처리 같은 품질 항목을 단계적으로 조절해 부하를 낮추는 접근입니다.

Unity Adaptive Performance Provider

Unity Adaptive Performance는 기기의 열 상태, 전력 상태, 병목 정보를 가져오기 위해 플랫폼별 Provider를 사용합니다. Android에서는 ADPF 기반 Android Provider를 우선 검토하고, 대상 기기가 Samsung Galaxy 중심이라면 Samsung Android Provider를 함께 고려할 수 있습니다. Samsung Provider는 GameSDK 기반으로 기기별 열 상태와 성능 정보를 Adaptive Performance에 전달하지만, 신규 프로젝트에서는 대상 OS와 provider 지원 범위를 먼저 확인해야 합니다.

Adaptive Performance에서 먼저 확인할 값은 열 상태를 나타내는 WarningLevel과 현재 병목을 나타내는 BottleneckStatus입니다. WarningLevel은 품질을 얼마나 적극적으로 낮출지 판단하는 신호로 사용할 수 있으며, 대표적으로 다음 세 단계가 있습니다.

WarningLevel	의미	대응 방향
NoWarning	일반적인 열 상태	현재 품질 설정을 유지하되, 프레임 시간과 병목 상태를 계속 관찰
ThrottlingImminent	쓰로틀링이 가까워질 수 있는 상태	해상도, LOD, 그림자 거리처럼 체감이 작은 항목부터 단계적으로 낮춤
Throttling	이미 열 제한의 영향을 받고 있는 상태	평균 부하를 더 적극적으로 낮춰 정상 열 상태로 돌아가도록 조정

품질 조절은 Scaler 단위로 구성합니다. Scaler는 해상도 스케일, 프레임레이트, 그림자, LOD, 후처리처럼 개별 품질 항목을 조절하는 구성 요소입니다. Indexer는 열 상태와 성능 상태를 바탕으로 어떤 Scaler를 어느 정도 적용할지 결정하고, Scaler는 개발자가 미리 정한 범위 안에서 값을 조절합니다.

예를 들어 GPU 병목과 열 경고가 함께 나타난다면, 해상도 스케일이나 그림자 관련 Scaler를 먼저 낮추는 식으로 구성할 수 있습니다. 반대로 CPU 병목이 주요 원인이라면 렌더 해상도를 낮추는 것보다 오브젝트 수, 애니메이션, 물리 빈도처럼 CPU 부하에 영향을 주는 항목을 우선 조정하는 편이 적절합니다. 중요한 것은 모든 품질을 한 번에 낮추는 것이 아니라, 체감 영향이 작은 항목부터 단계적으로 조정하도록 범위와 우선순위를 미리 설계하는 것입니다.

iOS의 Thermal State API

iOS에서도 목적은 같습니다. 기기의 열 상태를 읽고, 열 제한이 본격적으로 걸리기 전에 게임의 부하를 낮추는 것입니다. 다만 Android Adaptive Performance Provider처럼 Unity 패키지 안에서 상태 수집과 Scaler 조정을 함께 처리하기보다, Apple의 ProcessInfo.thermalState로 현재 시스템의 열 상태를 확인한 뒤 게임 쪽 품질 정책에 연결하는 방식으로 접근합니다. 이 값은 실제 온도 수치가 아니라, 앱이 부하를 줄여야 하는 정도를 나타내는 단계 정보입니다.

iOS Thermal State (ProcessInfo.thermalState)

상태	의미
`.nominal`	일반적인 열 상태. 별도 조정 없이 현재 품질 유지 가능
`.fair`	열 상태가 올라가는 단계. 체감이 작은 품질 항목부터 완만하게 조정
`.serious`	높은 열 상태. 해상도, 후처리, 그림자, 프레임레이트 등 부하를 적극적으로 낮춤
`.critical`	매우 높은 열 상태. 가능한 작업량을 최소화하고, 복구될 때까지 품질을 크게 낮춤

iOS에서는 thermalState를 한 번 읽는 것뿐 아니라, 상태 변화 알림을 받아 품질 정책에 연결하는 방식이 적절합니다. Unity 프로젝트에서는 Swift나 Objective-C 네이티브 플러그인으로 thermalState와 변경 알림을 C#에 전달하고, 상태에 따라 렌더 해상도, 후처리, 그림자, 목표 프레임레이트 같은 항목을 단계적으로 조정합니다.

Adaptive Performance 없이 대응하기

Adaptive Performance Provider나 iOS Thermal State API를 사용할 수 없는 환경에서는 열 상태를 직접 알기 어렵습니다. 이 경우 프레임 시간 변화를 관찰해 쓰로틀링 가능성을 간접적으로 추정할 수 있습니다.

다만 프레임 시간 증가는 에셋 로딩, GC, 네트워크, 장면 복잡도 변화로도 발생할 수 있으므로, 단일 프레임 스파이크를 쓰로틀링으로 판단하면 안 됩니다. 같은 장면과 비슷한 작업량이 유지되는 상황에서 최근 몇 초 동안의 평균 프레임 시간이 점진적으로 길어지고, 이 상태가 일정 시간 이상 지속될 때 품질을 한 단계 낮추는 방식이 더 안전합니다. 품질을 복원할 때도 바로 되돌리기보다, 충분한 안정 구간과 쿨다운을 둬야 품질 단계가 자주 흔들리지 않습니다.

이 방식은 실제 온도나 클럭 상태를 직접 읽는 것이 아니므로 쓰로틀링을 정확히 판별하지는 못합니다. 대신 별도 플랫폼 API 없이도 적용할 수 있으므로, 열 상태 정보를 얻기 어려운 기기에서 보수적인 fallback으로 사용할 수 있습니다.

전력 예산

Adaptive Performance나 프레임 시간 모니터링은 열 상태가 나빠졌을 때 부하를 조절하는 대응책입니다. 하지만 장시간 안정적인 성능을 얻으려면, 애초에 게임이 사용하는 전력을 기기가 지속적으로 감당할 수 있는 범위 안에 두어야 합니다. 발열은 전력 소비의 결과이므로, 먼저 게임 실행 중 어떤 요소가 전력을 많이 쓰는지 파악해야 합니다.

전력 소비의 주요 요인

그래픽 부하가 큰 게임에서는 GPU가 주요 전력 소비원이 되는 경우가 많습니다. 프래그먼트 셰이더가 화면의 수많은 픽셀에서 텍스처 샘플링과 조명 계산을 수행하고, 렌더 타깃을 읽고 쓰기 때문입니다. 오버드로우(Overdraw)가 심하면 같은 픽셀을 여러 번 처리하므로 GPU 작업량과 메모리 대역폭 사용량이 함께 증가합니다.

CPU 전력은 스크립트 실행, 물리 연산, 애니메이션 평가, UI 리빌드, 렌더 준비처럼 매 프레임 반복되는 작업에 영향을 받습니다. 모바일 SoC는 보통 고성능 코어와 고효율 코어를 함께 사용하며, 운영 체제 스케줄러가 부하와 열 상태에 따라 스레드를 배치합니다. 게임이 코어 배치를 직접 통제하기는 어렵지만, 메인 스레드의 지속 부하를 줄이고 불필요한 작업 빈도를 낮추면 고성능 코어를 오래 점유하는 시간을 줄일 수 있습니다.

디스플레이 전력은 화면 밝기, 주사율, 표시되는 색과 면적의 영향을 받습니다. 특히 OLED 디스플레이에서는 밝은 픽셀이 많을수록 소비 전력이 늘어날 수 있습니다. 다만 화면을 무조건 어둡게 만드는 것은 해법이 아닙니다. 가독성, 접근성, 아트 방향을 유지하면서 과도하게 밝은 전체 화면 효과, 긴 시간 유지되는 흰색 UI, 불필요한 최대 밝기 유도처럼 전력 소모를 키우는 요소를 줄이는 쪽으로 접근하는 편이 적절합니다.

메모리 대역폭과 전력

모바일 SoC에서 메모리 대역폭(Memory Bandwidth)은 GPU만의 자원이 아닙니다. CPU, GPU, 디스플레이 컨트롤러, 비디오 디코더, 운영 체제 작업이 같은 DRAM을 공유하며, 이들이 초당 읽고 쓰는 데이터량이 전체 대역폭과 전력 소비에 영향을 줍니다. 게임 실행 중에는 텍스처, 버퍼, 렌더 타깃을 반복해서 읽고 쓰는 렌더링 작업이 많기 때문에 GPU가 대역폭 사용량을 크게 끌어올리는 경우가 많습니다.

문제는 DRAM 접근이 칩 내부 캐시나 레지스터 접근보다 에너지 비용이 크다는 점입니다. 같은 장면을 그리더라도 큰 텍스처를 자주 읽고, 렌더 타깃을 여러 번 읽고 쓰고, CPU에서 만든 데이터를 GPU가 반복해서 참조하면 공유 DRAM 사용량이 늘어납니다. 따라서 메모리 대역폭 최적화는 외부 메모리에서 오가는 바이트 수와 접근 횟수를 줄이는 작업입니다. 텍스처 압축은 읽어야 할 데이터 크기를 줄이고, 밉맵은 축소되어 보이는 오브젝트에서 더 작은 텍스처 레벨을 샘플링하게 해 불필요한 고해상도 텍스처 접근을 줄입니다. 렌더 타깃 축소와 오버드로우 감소는 프레임 버퍼 접근을 줄이고, 불필요한 버퍼 복사 제거는 CPU와 GPU 사이의 데이터 이동을 줄입니다.

렌더링 기초 (2) - 텍스처와 압축에서 다룬 텍스처 압축과 밉맵은 전력 관점에서도 중요합니다. 텍스처 압축은 저장되는 텍스처 크기와 런타임 대역폭을 함께 줄입니다. 반면 밉맵은 전체 텍스처 메모리를 조금 더 사용하지만, 멀리 있거나 작게 보이는 오브젝트에서 낮은 해상도 레벨을 샘플링하게 해 캐시 효율을 높이고 대역폭 낭비를 줄입니다. 즉 압축은 메모리 사용량과 대역폭을 줄이는 기법이고, 밉맵은 추가 메모리를 감수하는 대신 샘플링 비용과 대역폭을 줄이는 기법에 가깝습니다.

셰이더 복잡도도 전력에 영향을 줍니다. 프래그먼트 셰이더에서 텍스처를 여러 장 샘플링하거나, 복잡한 라이팅 모델을 계산하거나, 분기(if-else)가 많으면 GPU의 연산량과 메모리 접근이 함께 늘어납니다. 텍스처 샘플링 최소화, 셰이더 분기 최소화, 라이팅 계산 단순화 같은 모바일 셰이더 최적화 기법은 실행 시간을 줄일 뿐 아니라, 공유 메모리 대역폭을 덜 사용하게 만들어 전력 효율도 개선합니다.

30fps vs 60fps — 프레임레이트의 트레이드오프

모바일 게임에서 목표 프레임레이트는 부드러움과 입력 반응성을 좌우하지만, 동시에 전력과 발열을 크게 바꾸는 설정입니다. 높은 프레임레이트가 항상 더 좋은 선택은 아니며, 장르의 조작 요구와 기기의 지속 성능을 함께 고려해야 합니다.

60fps의 비용

같은 장면을 같은 품질로 그린다면 60fps는 30fps보다 초당 프레임을 두 배 더 만들어야 합니다. 그만큼 CPU는 게임 로직과 렌더 준비를 더 자주 처리하고, GPU는 셰이더 실행과 렌더 타깃 쓰기를 더 자주 수행합니다. 동시에 각 프레임에 쓸 수 있는 시간은 33.33ms에서 16.67ms로 줄어들기 때문에, 작업을 끝낸 뒤 SoC가 쉬거나 낮은 클럭으로 내려갈 여지도 줄어듭니다.

예를 들어 한 프레임의 CPU/GPU 작업이 10ms 정도라면, 30fps에서는 33.33ms 예산 안에 비교적 긴 여유 시간이 남습니다. 이 시간 동안 운영 체제는 클럭과 전압을 낮추거나 일부 블록을 쉬게 하여 평균 전력을 낮출 수 있습니다. 반면 60fps에서는 프레임 예산이 16.67ms로 줄어들어 같은 작업이라도 유휴 시간이 크게 줄고, SoC가 더 높은 클럭과 전압을 유지하는 시간이 길어집니다. 앞에서 본 것처럼 동적 전력은 전압과 클럭의 영향을 크게 받기 때문에, 60fps는 평균 전력과 발열을 빠르게 끌어올릴 수 있습니다.

30fps vs 60fps

프레임레이트	프레임 예산	유휴 시간	클럭·전압 경향	전력·발열 경향
30fps	33.33ms	상대적으로 많음	낮아질 여지 있음	상대적으로 낮음
60fps	16.67ms	상대적으로 적음	높은 상태가 오래 유지됨	상대적으로 높음

결과적으로 60fps는 30fps보다 더 부드럽고 입력 반응도 좋지만, 같은 품질을 유지한다면 기기가 더 빨리 뜨거워지고 배터리도 더 빠르게 소모됩니다. 냉각 여유가 작은 기기에서는 실행 초반에 60fps를 유지하더라도, 열이 누적된 뒤에는 클럭 제한으로 목표 프레임레이트를 계속 유지하기 어려울 수 있습니다.

30fps의 이점

30fps의 가장 큰 이점은 같은 품질을 유지할 때 초당 처리해야 하는 프레임 수가 줄어든다는 점입니다. 프레임 예산은 33.33ms로 길어지고, 한 프레임의 작업을 끝낸 뒤 남는 시간 동안 SoC가 낮은 클럭으로 내려갈 여지가 생깁니다. 이 차이는 순간 성능보다 평균 전력을 낮추는 데 중요하며, 결과적으로 열이 누적되는 속도를 늦출 수 있습니다.

이 여유를 어디에 사용할지는 별도의 결정입니다. 같은 그래픽 품질을 유지하면 평균 부하를 낮추는 데 도움이 되고, 남는 예산을 그림자, 후처리, 오브젝트 밀도 같은 항목에 사용하면 화면 품질을 높일 수 있습니다. 대신 그만큼 전력과 발열 이점은 줄어듭니다.

따라서 30fps는 단순히 성능을 낮추는 선택이 아니라, 부드러움과 입력 반응성, 화면 품질, 발열, 배터리 사이의 우선순위를 정하는 선택입니다. 조작 정밀도보다 장시간 안정성과 배터리 지속 시간이 중요한 장르에서는 30fps가 더 현실적인 기준이 될 수 있습니다.

장르별 판단

프레임레이트는 장르 이름만으로 결정하기보다, 플레이어가 얼마나 빠르게 반응해야 하는지와 한 세션을 얼마나 오래 유지해야 하는지를 기준으로 정하는 편이 안전합니다. 아래 표는 고정 규칙이 아니라 목표 프레임레이트를 정할 때의 출발점입니다.

프레임레이트 선택 기준

우선순위	적합한 목표	예시
장시간 안정성, 배터리, 화면 품질	30fps	퍼즐, 방치형, 턴제 RPG, 전략 게임
입력 반응성, 조준, 판정 정확도	60fps	경쟁 FPS, 격투, 리듬 게임, 실시간 대전
상황별 부하와 조작 강도가 크게 달라짐	30~60fps 동적 전환	탐색과 전투가 분리된 액션 RPG, 오픈월드

동적 전환을 사용할 때는 전환 시점이 중요합니다. 전투 중처럼 입력이 민감한 구간에서 30fps와 60fps를 자주 오가면 프레임 페이싱 변화가 바로 체감될 수 있습니다. 씬 전환, 로딩, 컷신, 메뉴 진입처럼 조작 부담이 낮은 시점에 Application.targetFrameRate를 바꾸고, 한 번 전환한 뒤에는 일정 시간 동안 같은 설정을 유지해야 합니다. 낮출 때와 다시 올릴 때의 조건도 다르게 두어야 프레임레이트가 짧은 간격으로 오르내리는 현상을 피할 수 있습니다. Unity 모바일 빌드에서는 목표 프레임레이트를 정할 때 Application.targetFrameRate를 우선 확인하고, 플랫폼별 동작은 실기기에서 검증합니다.

지속 성능 기준의 설계

프레임레이트와 품질 기준을 정했다면, 그 목표가 실제 플레이 시간 동안 유지되는지 확인해야 합니다. 모바일에서 중요한 것은 기기가 차가울 때 잠깐 도달한 최고 성능이 아니라, 열이 누적된 뒤에도 유지할 수 있는 프레임 시간과 품질입니다.

기준	설계 흐름	결과
피크 성능 기준	차가운 기기나 짧은 테스트에서 나온 프레임레이트를 기준으로 목표 설정	열이 누적된 뒤 클럭 제한이 걸리면 프레임 시간이 늘어나고 목표 프레임레이트를 유지하기 어려움
지속 성능 기준	기준 기기에서 실제 플레이 시나리오를 충분히 연속 실행한 뒤, 예열 후 프레임 시간과 열 상태를 기준으로 목표 설정	장시간 플레이에서 유지 가능한 프레임레이트, 해상도, 품질 수준을 정할 수 있음

프로파일링도 이 지속 성능 상태를 포함해야 합니다. 측정 시간은 고정된 숫자보다 프로젝트의 실제 플레이 세션과 기준 기기의 열 특성에 맞추는 편이 적절합니다. 기기가 차가운 초반 구간의 데이터만 보면 피크 성능은 알 수 있지만, 열이 오른 뒤 프레임 예산을 계속 지킬 수 있는지는 확인하기 어렵습니다.

마무리

이 글의 핵심은 모바일 성능을 순간적인 처리 속도가 아니라, 제한된 전력과 방열 조건 안에서 오래 유지할 수 있는 성능으로 봐야 한다는 점입니다.

모바일 SoC는 CPU, GPU, 메모리, 디스플레이가 좁은 전력·열 예산을 공유하므로, 한 부분의 부하 증가가 전체 지속 성능에 영향을 줄 수 있습니다.
서멀 쓰로틀링은 OS가 기기를 보호하기 위해 클럭과 전력 사용을 제한하는 과정이며, 게임 쪽에서는 평균 부하를 낮추고 품질을 단계적으로 조정해 대응해야 합니다.
Adaptive Performance, iOS Thermal State API, 프레임 시간 모니터링은 열 상태 악화를 감지하는 수단이며, 실제 효과는 어떤 품질 항목을 언제 낮추는지에 따라 달라집니다.
전력 최적화는 GPU 연산만 줄이는 문제가 아닙니다. 반복되는 CPU 작업, 텍스처와 렌더 타깃 접근, 오버드로우, 디스플레이 밝기, 목표 프레임레이트가 모두 배터리와 발열에 영향을 줍니다.
30fps와 60fps의 선택은 단순한 화질 설정이 아니라, 부드러움과 입력 반응성, 화면 품질, 발열, 배터리 지속 시간 사이의 우선순위 결정입니다.
목표 프레임레이트와 품질은 차가운 기기의 피크 성능이 아니라, 기준 기기에서 열이 누적된 뒤에도 유지되는 지속 성능을 기준으로 정해야 합니다.

모바일 게임의 성능은 코드의 효율성만으로 결정되지 않습니다. 같은 코드라도 기기 크기, SoC, 방열 구조, 배터리 상태, 주변 온도에 따라 유지 가능한 품질이 달라집니다. 따라서 모바일 최적화는 “가장 빠른 순간”을 만드는 작업이 아니라, 실제 플레이 시간 동안 감당 가능한 부하를 설계하는 작업에 가깝습니다.

다음 단계는 이 원칙을 품질 설정과 빌드 전략으로 옮기는 것입니다. 기기 등급에 따라 해상도, 그림자, 셰이더, 에셋 압축, 스트리핑 수준을 나누어야 같은 게임도 다양한 모바일 기기에서 안정적으로 동작할 수 있습니다.

Part 2에서는 Quality Settings 계층 설계, 기기 등급 분류, IL2CPP 스트리핑, 에셋 압축 등 빌드와 품질 전략을 다룹니다.

관련 글

전체 시리즈