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

작성일 : 2026년 02월 21일

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

데스크톱 게임 최적화에서는 프로파일러로 병목을 찾아 개별 프레임의 실행 시간을 줄이는 것이 핵심입니다. 단일 프레임의 비용만 줄이면 대부분의 성능 문제가 해결됩니다.

모바일에서는 프레임 단위 병목을 모두 제거한 후에도 게임을 10분 이상 실행하면 프레임레이트가 떨어집니다. 칩이 발생시킨 열을 버티지 못해 운영 체제가 클럭을 강제로 낮추기 때문입니다. 이 현상을 서멀 쓰로틀링(Thermal Throttling)이라 하며, 코드 최적화만으로는 해결할 수 없는 물리적 제약입니다.

데스크톱 PC는 전원 케이블에 연결되어 에너지 제약이 없고, 공냉 팬이나 수냉 라디에이터가 열을 적극적으로 배출합니다. 반면 모바일 기기는 배터리라는 유한한 에너지원으로 동작하며, 팬 없는 밀폐 구조 안에서 자연 방열만 가능합니다. 배터리와 발열, 이 두 물리적 제약이 모바일 게임 설계의 근본 한계입니다.

실제로 게임 시작 직후 측정한 프레임레이트가 30~60fps이더라도, 30분 이상 지속 실행하면 피크의 30~70% 수준까지 떨어집니다. 이 글에서는 서멀 쓰로틀링의 메커니즘, 이에 대응하는 플랫폼 API, 전력 예산의 구조, 그리고 프레임레이트 선택의 트레이드오프를 다룹니다.

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

모바일 기기의 SoC(System on Chip)에는 CPU, GPU, 메모리 컨트롤러, 모뎀 등이 하나의 칩 위에 집적되어 있습니다. 이 칩이 전력을 소비하면 열이 발생하고, 칩 온도가 임계치에 도달하면 OS가 클럭 속도를 강제로 낮춥니다. 서멀 쓰로틀링의 직접적인 메커니즘입니다.

벤치마크 앱이 측정하는 점수는 기기의 피크 성능(Peak Performance)입니다. 기기 온도가 낮고 칩이 최대 클럭으로 동작하는 상태에서, 짧은 시간 동안 달성하는 최고치입니다. 게임은 10분, 30분, 한 시간 이상 연속으로 CPU와 GPU를 동시에 고부하로 사용하므로, 피크 성능을 유지할 수 없습니다. 이 지속적 부하에서 실제로 유지할 수 있는 성능이 지속 성능(Sustained Performance)이며, 최신 플래그십 SoC에서는 피크의 50% 이하로 떨어지는 경우도 있습니다.

서멀 쓰로틀링에 의한 성능 변화

  fps
  60 ──────┐
           │ 쓰로틀링 시작
  50       └───┐
               │
  40           └───┐
                   │
  30               └──────────────────────
  ──┬──┬──┬──┬──┬──┬──┬──┬──┬──┬──┬── 시간
   0  2  4  6  8 10 12 14 16 18 20 (분)

  피크 성능 (0~5분): 60fps
  → 쓰로틀링 구간 (5~10분): 점진적 하락
  → 지속 성능 (10분~): 30~35fps로 안정화

게임 시작 직후 60fps가 나오다가 10분 플레이 후 30~40fps로 떨어지는 현상은 코드의 문제가 아니라, 하드웨어의 물리적 한계에서 비롯됩니다. 프로파일러에서 특정 프레임의 CPU/GPU 시간이 갑자기 길어진 것처럼 보이지만, 실제로는 클럭이 낮아져서 같은 작업에 더 많은 시간이 걸리는 것입니다.

발열의 메커니즘

서멀 쓰로틀링을 제어하려면, 열이 어디에서 발생하고 어떤 경로로 빠져나가는지를 알아야 합니다.

열 발생

SoC가 전력을 소비하면 전기 에너지의 일부가 열로 변환됩니다. 트랜지스터가 더 빠르게 스위칭할수록 더 많은 전력이 필요하고, 그에 따라 발열도 증가합니다. 칩의 동적 전력 소비는 P = C x V² x f로 근사할 수 있으며, 여기서 C는 회로의 커패시턴스, V는 전압, f는 클럭 주파수입니다. 클럭(f)을 올리면 트랜지스터의 안정적인 동작을 위해 전압(V)도 함께 올라가야 합니다. 수식에서 V가 제곱으로 들어가므로, 클럭을 2배로 올리면 전력 소비는 2배보다 훨씬 크게 증가합니다. 이것이 고성능 모드에서 발열이 급격히 늘어나는 이유입니다.

SoC의 열 설계 전력(TDP, Thermal Design Power)은 칩이 정상 동작 범위에서 발생시킬 수 있는 최대 열량을 나타냅니다. 데스크톱 CPU의 TDP가 65~125W인 반면, 모바일 SoC의 지속 가능 전력은 2.5~5W 수준이고 피크 전력은 8~12W에 달합니다. 발생하는 열의 총량 자체는 작지만, 그 열을 방출할 수 있는 구조도 그만큼 제한적입니다.

데스크톱 vs 모바일의 냉각 구조 비교

데스크톱 PC (TDP 65~425W):
  CPU (125W) → 대형 방열판 + 팬 (공냉) 또는 수냉 라디에이터
  GPU (300W) → 전용 쿨러 + 팬 (공냉) 또는 수냉
  케이스 팬으로 내부 공기 순환
  → 열 방출 >> 열 발생: 장시간 최대 클럭 유지 가능

스마트폰 (TDP 2.5~5W, 피크 8~12W):
  SoC (5W) → 구리 시트/베이퍼 챔버 → 금속 프레임 → 외기
  팬 없음, 자연 방열만 가능
  → 열 방출 < 열 발생: 수 분 후 클럭 강제 하락

열 방출의 한계

스마트폰의 열 방출 경로는 칩 → 기판 → 금속 프레임(또는 후면 유리) → 외기입니다. 팬이 없으므로 기기 표면에서의 자연 방열이 유일한 경로입니다. 일부 고사양 기기에는 베이퍼 챔버(Vapor Chamber)나 구리 히트파이프가 내장되어 있습니다. 이들은 액체가 기화할 때의 엔탈피 변화를 이용하여 칩의 열을 기기의 넓은 면적으로 빠르게 분산시키는 열 전달 부재입니다. 열을 넓게 퍼뜨려 방열 면적을 늘리는 역할이지, 열 자체를 외부로 밀어내는 능동 냉각은 아닙니다.

열 방출 속도보다 열 발생 속도가 빠르면 칩 온도가 지속적으로 올라갑니다. 기기의 표면 온도와 칩 내부의 정션 온도(Junction Temperature)는 다릅니다. 정션 온도는 트랜지스터가 실제로 동작하는 반도체 접합부의 온도이며, 표면 온도보다 20~40도 높습니다. 임계치는 제조사마다 다르지만, 기기 표면 온도가 40~45도에 도달할 때 칩의 정션 온도는 80~90도에 이르며, 이 시점에 OS가 쓰로틀링을 시작합니다.

쓰로틀링 발생 과정

  열 발생 > 열 방출 → 칩 온도 상승
  → 정션 온도 임계치 도달 (80~90도)
  → OS가 CPU/GPU 클럭 강제 하락
  → 전력 소비 감소 → 열 발생 감소
  → 온도 안정화 (열 발생 = 열 방출)
  → 이 균형점의 성능 = 지속 성능

쓰로틀링은 단계적으로 진행됩니다. SoC 내부에서 CPU와 GPU는 전력 버짓(Power Budget)을 공유합니다. 온도가 약간 올라가면 OS는 두 장치의 클럭을 균형 있게 낮춰 전력을 절감합니다. 온도가 더 올라가면 클럭이 더욱 급격히 하락하며, 극단적으로는 저전력 코어만 활성화되거나 일부 코어가 완전히 비활성화됩니다. 가장 심한 경우 기기가 앱을 강제 종료합니다.

외부 환경도 쓰로틀링에 영향을 줍니다. 외기 온도가 30도를 넘으면 기기 표면과 외기의 온도 차이가 줄어 자연 방열 효율이 급격히 떨어지고, 휴대폰 케이스도 열 배출 경로를 차단합니다. 여름철 테스트와 겨울철 실내 테스트, 케이스 착용 여부에 따라 쓰로틀링이 시작되는 시점과 강도가 달라지므로, 테스트 환경을 통일하고 기록해 두어야 합니다.

Adaptive Performance

서멀 쓰로틀링은 OS가 일방적으로 클럭을 낮추므로, 게임 코드에서는 프레임레이트가 예측 불가능하게 흔들리는 것으로 나타납니다. 쓰로틀링이 발생하기 전에 미리 품질을 낮춰 발열을 억제하면, 이 성능 저하를 완화할 수 있습니다.

Samsung Adaptive Performance

Samsung은 GameSDK를 통해 기기의 온도 상태와 성능 모드 정보를 게임에 제공합니다. Unity는 Samsung GameSDK를 감싼 Adaptive Performance 패키지를 제공하여, Samsung 기기에서 이 기능을 쉽게 활용할 수 있도록 지원합니다.

Adaptive Performance 동작 구조

Samsung GameSDK (온도 센서, 성능 모드, 쓰로틀링 경고)
  ↓
Unity Adaptive Performance 패키지
  WarningLevel: NoWarning → ThrottlingImminent → Throttling (3단계)
  BottleneckStatus: CPU-bound / GPU-bound / Balanced
  Indexer: 현재 상태에 따라 품질 수준 결정
  ↓
게임의 품질 조절
  NoWarning          → 최고 품질 유지
  ThrottlingImminent → 후처리 축소, LOD 거리 단축
  Throttling         → 해상도 스케일, 그림자 끔

Adaptive Performance가 제공하는 핵심 정보는 경고 수준(WarningLevel)이며, 세 단계로 나뉩니다.

NoWarning. 온도가 정상 범위에 있고, 쓰로틀링 위험이 없으므로 최고 품질을 유지할 수 있는 상태입니다.

ThrottlingImminent. 온도가 올라가기 시작한 단계입니다. 아직 쓰로틀링은 아니지만, 현재 부하가 계속되면 쓰로틀링에 진입할 가능성이 있습니다. 이 단계에서 품질을 약간 낮추면 쓰로틀링을 예방할 수 있습니다.

Throttling. 쓰로틀링이 발생하고 있는 상태로, 해상도, 셰이더 복잡도, 후처리 등을 적극적으로 낮춰야 합니다. 이 상태가 지속되면 성능이 크게 제한되며, 기기가 앱을 강제 종료할 수도 있습니다.

Adaptive Performance 패키지는 품질 항목별로 Scaler를 제공합니다. 해상도 스케일, 그림자 해상도, LOD(Level of Detail) 바이어스 등 각 항목에 대해, 개발자가 허용 범위(최솟값~최댓값)를 미리 설정해 두면 온도 상태에 따라 자동으로 값이 조절됩니다. 예를 들어 해상도 스케일의 범위를 0.6~1.0으로 설정하면, NoWarning에서는 1.0(풀 해상도), ThrottlingImminent에서는 0.8, Throttling에서는 0.6까지 자동으로 내려갑니다. 개발자가 경고 단계마다 어떤 품질을 얼마나 낮출지 직접 코드로 분기할 필요 없이, 범위만 지정하면 패키지가 단계적으로 조절하는 구조입니다.

iOS의 Thermal State API

Samsung Adaptive Performance는 Samsung 기기에 한정됩니다. iOS에서는 ProcessInfo.thermalState를 통해 기기의 온도 상태를 조회할 수 있습니다.

iOS Thermal State (ProcessInfo.thermalState)

  .nominal   → 정상 온도, 제한 없음
  .fair      → 약간 상승, 예방적 조치 권장
  .serious   → 높은 온도, 적극적 부하 감소 필요
  .critical  → 위험, 즉시 부하 최소화

iOS에는 Unity가 직접 제공하는 통합 패키지가 없으므로, Objective-C 네이티브 플러그인으로 thermalState 값을 읽어 C#에 전달하고, 상태에 따라 Quality Settings를 전환하는 방식으로 구현합니다.

Adaptive Performance 없이 대응하기

Samsung Adaptive Performance와 iOS Thermal State API가 제공되지 않는 기기에서도, 프레임 시간을 모니터링하면 쓰로틀링을 간접적으로 감지할 수 있습니다.

게임 로직의 복잡도가 변하지 않았는데 프레임 시간이 점진적으로 길어진다면, SoC의 클럭이 낮아지고 있다는 신호입니다. 최근 N초 동안의 평균 프레임 시간을 추적하고, 이 값이 임계치를 넘으면 품질을 한 단계 낮춰 발열을 완화하는 방식으로 구현합니다.

프레임 시간 기반 쓰로틀링 감지 (개념)

  매 프레임:
    frameTime = 현재 프레임 시간
    rollingAverage = 최근 300프레임의 평균 프레임 시간

    if rollingAverage > 목표 프레임 시간 * 1.2:
        qualityLevel -= 1    (품질 한 단계 낮춤)
        cooldownTimer = 30초  (너무 자주 변경하지 않기 위한 대기)

    if rollingAverage < 목표 프레임 시간 * 0.8 and cooldownTimer == 0:
        qualityLevel += 1    (부하가 줄어 온도가 내려가면 품질 복원)

하드웨어 온도 데이터에 직접 접근하지 않으므로 반응이 느리지만, 플랫폼에 무관하게 적용할 수 있어 범용 대응책으로 유용합니다.

전력 예산

Adaptive Performance나 프레임 시간 모니터링으로 쓰로틀링에 대응할 수 있지만, 근본적인 해결은 전력 소비 자체를 줄이는 것입니다. 발열은 전력 소비의 직접적인 결과이므로, 어디에서 전력이 소모되는지 파악하는 것이 출발점입니다.

전력 소비의 분포

게임 실행 중 모바일 기기의 전력 소비 분포 (개략적)

███████████████ GPU ~40~50%
████████ CPU ~20~30%
█████ 디스플레이 ~15~20%
██ 메모리(DRAM) ~5~10%
█ 네트워크(모뎀) ~3~5%
█ 기타 ~2~3%

→ GPU 부하를 줄이면 전력 절약 효과가 가장 크다

GPU가 가장 많은 전력을 소비합니다. 프래그먼트 셰이더가 화면의 수백만 픽셀마다 텍스처 샘플링과 라이팅 계산을 수행하기 때문입니다. 오버드로우(Overdraw)가 심하면 같은 픽셀을 여러 번 처리하므로 전력 소비가 배로 늘어납니다.

CPU는 스크립트 실행, 물리 연산, 애니메이션 평가, UI 리빌드, 렌더 준비 등을 처리합니다. 현대 모바일 SoC는 빅 코어(고성능 코어)와 리틀 코어(고효율 코어)를 함께 내장하고 있으며, 부하에 따라 어느 코어를 활성화할지 동적으로 선택합니다. 빅 코어는 고속이지만 전력 소비가 크고, 리틀 코어는 느리지만 전력 효율이 높아서, 같은 CPU 작업이라도 어떤 코어에서 실행되느냐에 따라 전력 소비가 크게 달라집니다.

디스플레이도 15~20%의 비중을 차지합니다. 특히 OLED 디스플레이에서는 밝은 화면이 어두운 화면보다 전력을 더 소비합니다. 게임의 전반적인 톤이 밝을수록 디스플레이 전력이 높아지지만, 이 부분은 최적화보다는 아트 디렉션의 영역입니다.

메모리 대역폭과 전력

GPU의 전력 소비에서 특히 중요한 요소가 메모리 대역폭(Memory Bandwidth)입니다. 메모리 대역폭은 GPU가 초당 메모리로부터 읽고 쓸 수 있는 데이터량을 나타냅니다. GPU가 텍스처를 읽거나 프레임 버퍼에 쓸 때는 칩 바깥의 DRAM에 접근해야 합니다. 칩 내부의 연산은 짧은 배선 위에서 이루어지지만, DRAM 접근은 칩 밖으로 신호를 보내야 하므로 물리적으로 더 많은 전력이 필요합니다. 외부 메모리 접근 한 번이 소비하는 전력은 GPU 내부의 ALU(산술 논리 장치) 연산 20~50회에 해당합니다.

연산 vs 메모리 접근의 전력 비용 비교

████ GPU 내부 ALU 연산 1회 ~1x
████████ GPU 내부 레지스터 접근 ~2x
████████████ GPU 내부 캐시(L1) 접근 ~3x
████████████████████████████████ 외부 메모리(DRAM) 접근 ~20~50x

→ 셰이더에서 텍스처 샘플링을 줄이면 연산량뿐 아니라 전력도 절약
→ 밉맵을 사용하면 캐시 히트율이 높아져 외부 메모리 접근 감소
→ ASTC 같은 압축 텍스처는 대역폭을 줄여 전력 절약에 기여

렌더링 기초 (2) - 텍스처와 압축에서 다룬 텍스처 압축과 밉맵은 메모리 사용량만 줄이는 것이 아니라 전력 소비에도 직접적으로 영향을 미칩니다. 압축 텍스처는 같은 정보를 더 적은 바이트로 전달하므로 메모리 대역폭 사용량이 줄고, 밉맵은 멀리 있는 오브젝트에 작은 텍스처를 사용하여 캐시 히트율을 높입니다. 두 기법 모두 외부 메모리 접근 횟수를 줄여 전력을 절약합니다.

셰이더 복잡도도 전력에 직결됩니다. 프래그먼트 셰이더에서 텍스처를 여러 장 샘플링하거나, 복잡한 라이팅 모델을 계산하거나, 분기(if-else)가 많으면 GPU의 ALU 사용률과 메모리 접근 횟수가 모두 늘어나 전력 소비가 증가합니다. 텍스처 샘플링 최소화, 셰이더 분기 최소화, 라이팅 계산 단순화 같은 모바일 셰이더 최적화 기법들은 실행 시간뿐 아니라 전력 효율을 직접적으로 개선합니다.

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

모바일 게임에서 목표 프레임레이트를 선택하는 것은 부드러움의 문제가 아니라, 전력과 발열의 문제입니다.

60fps의 비용

60fps는 30fps 대비 GPU 작업량이 2배이지만, 전력 소비 차이는 단순한 2배가 아닙니다. 핵심은 유휴 시간의 유무입니다.

30fps에서 실제 작업이 20ms에 끝나면, 프레임 예산 33.33ms 중 나머지 13ms는 SoC가 유휴 상태입니다. 유휴 시간 동안 OS는 클럭(f)과 전압(V)을 낮추고, 앞서 살펴본 P = C × V² × f 관계에 의해 전력 소비가 급격히 줄어듭니다. 60fps에서는 예산이 16.67ms이므로 같은 작업량에 유휴 시간이 거의 없고, SoC가 높은 클럭과 전압을 계속 유지해야 합니다. 전압이 제곱으로 영향을 미치므로, 작업량 2배 이상의 전력 차이(약 1.5~2배)가 발생합니다.

30fps vs 60fps

  30fps — 예산 33.33ms, 유휴 시간 있음(클럭 하강), 전력 1x
  60fps — 예산 16.67ms, 유휴 시간 없음(클럭 유지), 전력 ~1.5~2x

결과적으로, 60fps에서는 기기가 더 빨리 뜨거워지고 쓰로틀링이 더 일찍 시작됩니다. 30fps에서 30분 플레이할 수 있는 배터리가 60fps에서는 15~20분으로 줄어들 수 있습니다.

30fps의 이점

30fps의 이점은 프레임 예산이 두 배라는 것만이 아닙니다. 매 프레임 사이에 유휴 시간이 생기면서 SoC가 냉각될 여지가 있다는 점이 핵심입니다. 이 유휴 시간 덕분에 칩 온도가 낮게 유지되어 쓰로틀링 없이 장시간 안정적인 프레임레이트를 유지할 수 있습니다.

여유 예산의 활용 방법은 두 가지입니다. 60fps에서는 적용하기 어려운 복잡한 셰이더, 더 많은 오브젝트, 더 풍부한 후처리를 적용하여 화면 품질을 높이거나, 같은 품질을 유지하면서 GPU 클럭을 낮춰 발열을 억제할 수 있습니다.

많은 상용 모바일 게임이 30fps를 기본으로 선택하는 이유입니다. 부드러움에서는 60fps에 못 미치지만, 열적 안정성, 배터리 수명, 장시간 플레이 안정성에서 크게 유리합니다.

장르별 판단

장르별 프레임레이트 선택

30fps — 캐주얼/퍼즐, 턴제 RPG/전략
  입력 반응보다 배터리와 화면 품질 우선

60fps — 경쟁 FPS/격투, 리듬 게임, MOBA
  입력 지연과 판정 정확도가 승패에 직결

30~60fps 동적 전환 — 액션 RPG
  탐색 시 30fps로 전력 절약, 전투 시 60fps로 전환

동적 전환을 채택하는 경우, 전환 시점에 프레임레이트 변화가 체감될 수 있습니다. 씬 전환이나 페이드 연출 중에 Application.targetFrameRate를 변경하면 플레이어가 차이를 느끼기 어렵습니다. 모바일 플랫폼에서는 QualitySettings.vSyncCount가 무시되므로, Application.targetFrameRate만으로 프레임레이트를 제어합니다.

지속 성능 기준의 설계

모바일 게임은 피크 성능이 아니라 지속 성능을 기준으로 설계해야 합니다.

피크 성능 기준 (잘못된 접근):
  벤치마크 60fps → 60fps 목표로 설계
  → 5~10분 후 쓰로틀링 → 불규칙 하락
  → "시간이 지나면 점점 버벅거린다"

지속 성능 기준 (올바른 접근):
  10분 이상 연속 실행 후 측정 → 지속 성능 파악
  → 지속 성능에서 유지되는 fps를 목표로 설계
  → "항상 일정하게 부드럽다"

프로파일링도 지속 성능 상태에서 수행해야 합니다. 기기를 충분히 예열한 상태(게임을 10분 이상 실행한 후)에서 측정한 값이 실제 플레이 환경을 대표합니다. 기기가 차가운 상태에서 측정한 수치를 기준으로 최적화하면, 쓰로틀링이 시작된 후 프레임 예산을 초과합니다.

마무리

모바일 SoC는 발열로 인해 클럭을 강제로 낮추며(서멀 쓰로틀링), 지속 성능은 피크의 50% 이하까지 떨어질 수 있습니다.
스마트폰은 팬이 없고 자연 방열만 가능하므로, 고부하 작업이 수 분만 지속되어도 쓰로틀링이 발생합니다.
Samsung Adaptive Performance, iOS Thermal State API, 또는 프레임 시간 모니터링으로 쓰로틀링을 감지하고 품질을 단계적으로 조절할 수 있습니다.
전력 소비에서 GPU가 가장 큰 비중(40~50%)을 차지하며, 외부 메모리 접근 한 번은 ALU 연산 20~50회에 해당하는 전력을 소비합니다.
60fps는 유휴 시간이 사라져 SoC가 높은 클럭을 유지해야 하므로, 30fps 대비 약 1.5~2배의 전력을 소비합니다.
피크 성능이 아니라 지속 성능을 기준으로 설계하고, 프로파일링도 기기를 충분히 예열한 상태에서 수행해야 합니다.

모바일 게임의 성능은 코드의 효율성만으로 결정되지 않습니다. 배터리와 발열이라는 물리적 제약이 근본적인 한계를 설정하며, 이 한계 안에서 안정적인 경험을 설계하는 것이 모바일 최적화의 출발점입니다.

발열과 배터리 제약은 모든 모바일 기기에 공통으로 적용되지만, 기기마다 SoC 성능과 방열 능력이 다릅니다. 같은 게임이라도 저사양 기기에서는 해상도와 셰이더를 낮추고, 고사양 기기에서는 풀 품질을 유지하는 분기가 필요합니다.

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

관련 글

시리즈

모바일 전략 (1) - 발열과 배터리 (현재 글)
모바일 전략 (2) - 빌드와 품질 전략

전체 시리즈