Unity 엔진의 모바일 게임 개발에서 Adaptive Performance 시스템 심층 분석
현대 모바일 게임 개발 생태계에서 하드웨어 용량이 기하급수적으로 증가함에 따라, 그래픽의 한계를 뛰어넘는 게임을 휴대용 기기에서 실행할 수 있는 길이 열렸습니다. 그러나 모바일 플랫폼은 데스크톱이나 콘솔 시스템과 달리 능동형 냉각 장치(팬 또는 수냉 시스템)가 없습니다. SoC(System-on-Chip) 아키텍처에서는 중앙 처리 장치(CPU), 그래픽 처리 장치(GPU), 메모리 컨트롤러 및 네트워크 모듈이 밀리미터 단위의 공간 안에 함께 배치되어 있습니다.¹ 이 컴포넌트들을 높은 클럭 속도(clock speed)로 지속해서 작동시키면 필연적으로 엄청난 양의 폐열이 발생합니다.
기기의 온도가 임계치에 도달하면, 운영체제는 하드웨어를 물리적 손상으로부터 보호하고 배터리의 화학적 구조가 변형되는 것을 막기 위해 "Thermal Throttling"(발열로 인한 성능 저하)이라는 방어 메커니즘을 활성화합니다.² 이 메커니즘은 CPU와 GPU의 클럭 주파수를 갑작스럽고 공격적으로 떨어뜨립니다. 게임 개발자 관점에서 이는 초당 프레임 수(FPS)의 급격한 저하, 입력 지연(input lag) 증가, 그리고 플레이어 경험의 전반적인 저하를 의미합니다.³ 바로 이 지점에서 소프트웨어와 하드웨어 사이를 연결하여 게임 엔진이 기기의 발열 동역학(thermal dynamics)에 능동적으로 적응하도록 돕는 Unity Adaptive Performance(어댑티브 퍼포먼스) 시스템이 작동하게 됩니다. 본 보고서는 개발 과정에서 자주 마주치는 구성 경고의 해부학부터 시작하여, Adaptive Performance 패키지의 기본 아키텍처, 스케일링 알고리즘, 통합 전략 및 제공하는 최적화 장점들을 학술적이고 전문적인 깊이로 검토합니다.
"Adaptive Performance Settings" 경고의 근본 원인 및 구성 솔루션
Unity 게임 엔진에서 새로운 모바일 프로젝트를 시작하거나 기존 프로젝트를 모바일 플랫폼(Android, iOS)용으로 빌드하도록 구성할 때, 콘솔 화면에 종종 다음과 같거나 유사한 메시지가 나타납니다: "No Adaptive Performance provider package installed. Adaptive Performance requires a provider to get information during runtime. Please install a provider such as Adaptive Performance Samsung (Android) from the Adaptive Performance Settings".⁴ 개발자들의 개발 프로세스를 지연시키는 이 경고의 기저에 있는 주원인은 Unity의 모듈형 패키지 관리 시스템과 하드웨어 추상화 계층(Hardware Abstraction Layer)의 작동 원리입니다.
Unity는 특히 "Mobile 2D", "Mobile 3D" 또는 "Universal Render Pipeline (URP)" 같은 템플릿으로 프로젝트를 생성할 때 Adaptive Performance 기본 패키지를 프로젝트에 미리 설치된(pre-installed) 상태로 포함합니다.⁵ 그러나 기본 패키지만으로는 기기 하드웨어에서 데이터를 읽거나 운영체제에 개입할 수 있는 네이티브(native) 라이브러리를 자체적으로 갖고 있지 않습니다. 패키지가 기능적으로 작동하려면 대상 운영체제(Android 등) 또는 테스트 환경에 특화된 "Provider"(제공자) 모듈을 프로젝트에 추가하고 구성해야 합니다.⁶ 제공자 모듈이 누락되면 기본 패키지는 런타임(runtime)에 하드웨어 센서에 도달하지 못하고 이 경고를 발생시켜 개발자에게 알립니다. 경고의 해결 방법과 구성 단계는 개발 대상 플랫폼과 사용 중인 Unity 버전에 따라 상당한 방법론적 차이를 보입니다.
개발 과정에서 직면하는 이 경고의 해결책은 플랫폼 기반으로 다루어져야 합니다. 운영체제의 하드웨어 API에 대한 접근 권한이 다르기 때문에 Unity가 제공하는 솔루션도 다릅니다.
대상 플랫폼경고의 기술적 원인적용해야 할 솔루션 방법론AndroidADPF 또는 Samsung GameSDK와 통신할 네이티브 플러그인이 프로젝트에 존재하지 않음.Unity Package Manager를 통해 Adaptive Performance Android Provider 또는 기기 지정 타깃이 있는 경우 Samsung (Android) Provider 패키지를 설치해야 합니다.⁶ 그 후 Edit > Project Settings > Adaptive Performance 메뉴에서 관련 제공자를 활성화해야 합니다.iOS (Apple)iOS 생태계에서 Adaptive Performance를 위해 Unity가 지원하는 공식 하드웨어 제공자(provider)가 존재하지 않음.⁴프로젝트에 Mobile 기능 세트가 추가되면 Adaptive Performance가 종속성(dependency)으로 포함되며 삭제할 수 없습니다. iOS 빌드의 경우 이 경고는 무해하므로 무시(ignore)할 수 있으며, 또는 종속성을 끊기 위해 패키지 관리자에서 Mobile 모듈을 제거할 수 있습니다.⁴데스크톱 에디터 (PC/Mac)Windows 또는 macOS 운영체제에 모바일 기기 고유의 발열 센서 및 SoC 아키텍처가 존재하지 않음.개발용 PC에서 모바일 조건을 시뮬레이션할 수 있도록 Simulator (Desktop) Provider를 설치하고 Device Simulator 창을 사용하여 가상 발열 환경을 조성해야 합니다.²Unity 6 (Build Profiles)Unity 6에서 도입된 빌드 프로필(Build Profiles)에서 메인 프로젝트의 Adaptive Performance 설정 외에 프로필 전용 구성을 잊어버린 경우.File > Build Profiles 메뉴에서 선택된 플랫폼에 대해 Add Settings > Adaptive Performance Settings 버튼을 클릭하여 제공자를 지정해야 합니다. Unity 6.000.x 버전에서 이러한 설정을 추가하지 않으면 "No default loader found" 오류가 발생합니다.⁹
이 경고는 본질적으로 컴파일(compile) 오류가 아니라 최적화 부족 알림입니다. 개발자는 이 경고를 무시하고 게임을 기기에서 실행할 수 있지만, 이 경우 게임은 하드웨어의 발열 상태에 대해 완전히 눈이 먼(blind) 상태로 작동하게 되며 필연적으로 운영체제의 가혹한 발열 조절 개입에 노출될 것입니다.
Adaptive Performance 시스템의 아키텍처와 제공자(Provider) 생태계
Adaptive Performance는 게임 엔진의 의사결정 메커니즘과 물리적 하드웨어 사이에 양방향 통신 브리지를 구축합니다. 이 아키텍처의 데이터 수집 계층은 제공자(providers)에 의해 구성됩니다. 안드로이드 생태계의 극도로 단편화된(fragmented) 구조로 인해 단일 하드웨어 API가 모든 기기에서 작동하는 것이 불가능하므로, Unity는 이 문제를 서로 다른 하드웨어 프레임워크(frameworks)에 통합되는 특화된 제공자들을 통해 극복하고 있습니다.
Android Dynamic Performance Framework (ADPF) 통합
Unity의 기본 "Android Provider" 모듈은 Google이 Android 12 운영체제 및 이후 버전에서 선보인 Android Dynamic Performance Framework (ADPF) 아키텍처를 기반으로 구축되었습니다.² ADPF는 게임과 운영체제의 발열 관리 간 직접적인 대화를 가능하게 하는 혁신적인 API 세트입니다. 전통적인 방식에서는 운영체제가 게임의 어떤 프레임(frame)에 얼마나 많은 프로세서 전력이 필요한지 추정하려고 시도하며, 이러한 추정은 종종 잘못된 CPU 클럭 속도 할당으로 이어집니다.
반면 Unity Adaptive Performance Android 제공자는 "Performance Hint API" (성능 힌트 인터페이스)를 통해 운영체제에 지속적인 데이터 스트림을 제공합니다.⁶ 엔진은 각 프레임이 렌더링될 때 해당 프레임의 목표 시간(예: 60 FPS를 목표로 하는 경우 16.6 밀리초)과 CPU 및 GPU가 이 프레임을 완료하는 데 소요한 실제 시간(actual duration)을 ADPF 시스템에 보고합니다.⁶ 이 정밀한 피드백 루프 덕분에 Android 운영체제는 게임에 필요한 만큼만 CPU 코어의 주파수를 높입니다. 기기가 가열되기 시작하면 운영체제는 발열 경고를 Unity로 다시 전송하므로, 하드웨어 수준에서 속도 저하가 발생하기 전에 엔진 내부 그래픽 스케일러가 작동하게 됩니다.⁶ Android Provider의 안정 버전인 1.2 이상 버전(Pixel 기기 제한을 넘어서는 버전)은 Adaptive Performance 5.0 및 Unity 2021.3 이후에서 지원됩니다.⁶
Samsung GameSDK 및 특화된 하드웨어 최적화
삼성은 안드로이드 생태계에서 가장 큰 시장 점유율 중 하나를 차지하고 있기 때문에, 자체 하드웨어의 한계를 뛰어넘기 위해 GameSDK라는 맞춤형 하드웨어 인터페이스를 제공합니다. Unity의 Adaptive Performance Samsung (Android) 제공자는 표준 ADPF 기능의 범위를 넘어 삼성 SoC의 심층적인 메트릭을 직접 획득할 수 있도록 합니다.²
삼성 제공자는 Android 10 이상의 운영체제를 탑재하고 GameSDK 3.2 및 최신 버전을 지원하는 방대한 기기 범위를 포괄합니다. 이 범위는 보급형 기기부터 플래그십 기기까지 확장되어 개발자에게 매우 넓은 최적화 영역을 제공합니다.
지원되는 삼성 Galaxy 시리즈모델 (GameSDK 3.2+ / Android 10+)Galaxy S 시리즈S9, S10e, S10, S10+, S10 Lite, S20, S20+, S20 Ultra, S20 Lite, S21, S21+, S21 Ultra, S22, S22+, S22 Ultra¹³Galaxy Note 시리즈Note9, Note10, Note10+, Note10 Lite, Note20, Note20 Ultra¹³Galaxy Z (접이식) 시리즈Z Fold2¹³Galaxy A 시리즈A10s, A11, A21s, A31, A41, A50s, A51, A51 5G, A71, A71 5G, A80, A8 2018, A9 2018, A90 5G¹³Galaxy Xcover 시리즈Xcover 4s, Xcover Pro¹³
이 기기들이 제공하는 가장 중요한 하드웨어적 장점 중 하나는 "가변 새로 침률"(Variable Refresh Rate - VRR) 기술입니다.¹³ VRR 지원은 현재 갤럭시 S20, S21, S22 및 노트 20 기기에서 활발하게 사용될 수 있습니다.¹³ Adaptive Performance는 기기가 한계에 도달했음을 감지하고 게임의 FPS 값을 예컨대 60에서 45로 낮추기로 결정할 때, 삼성 VRR API로 명령을 전송하여 화면의 물리적 새로 고침 빈도도 45 Hz로 낮춥니다.¹⁶ 이 동기화는 화면 찢어짐(screen tearing)을 방지할 뿐만 아니라 디스플레이 패널의 추가 전력 소비를 막고 기기가 더 빨리 냉각되도록 상당한 기여를 합니다. 또한 삼성 제공자는 GameSDK 3.5(Android 12) 이상 기기에서 프로세서의 big.LITTLE 아키텍처 내 대형 및 소형 코어의 부하 분산을 보여주는 "Cluster Info" 데이터에 대한 접근 기회도 제공합니다.¹³
발열 메트릭 및 병목 현상(Bottleneck) 감지 알고리즘
Adaptive Performance가 능동적 최적화를 제공할 수 있는 배경의 엔지니어링은 지속해서 데이터를 수집하는 센서 분석 시스템에 기반합니다. 게임 런타임에 생성되는 IAdaptivePerformance 인터페이스(interface)는 하드웨어로부터 두 가지 주요 범주로 데이터 세트를 읽습니다: 발열 상태 피드백(Thermal State Feedback)과 프레임 타이밍(Frame Timing). 이러한 데이터를 바탕으로 시스템의 현재 성능을 제한하는 주요 요소(병목 현상)가 무엇인지 결정됩니다.
발열 피드백 및 경고 수준
기기의 열 상태는 단순한 섭씨 온도 읽기만으로 평가되지 않습니다. 발열 동역학은 정규화되고 분석적으로 처리된 세 가지 서로 다른 메트릭을 통해 모니터링됩니다 ²:
첫 번째 메트릭인 TemperatureLevel(온도 수준)은 0.0과 1.0 사이로 정규화된(0.0은 표준 실내/작동 온도, 1.0은 절대 최대 발열 임계치) 부동 소수점(float) 값입니다.² 개발자는 이 값을 사용하여 게임 UI에서 기기의 발열 상태를 그래픽 바로 플레이어에게 제공하거나 자신만의 커스텀 최적화 로직을 구축할 수 있습니다.
두 번째이자 더 예측 가능한 메트릭인 TemperatureTrend(온도 추세)는 -1.0에서 1.0 사이로
변하며 온도의 수학적 도함수, 즉 변화 속도를 나타내는 값입니다.² 값이 1.0이라는 것은 기기가 매우 빠른 속도로 가열되고 있음을 나타내며, 0 값은 온도가 일정하게 유지되고 있음을, -1.0은 공격적인 냉각 주기에 진입했음을 보여줍니다. 시스템이 이러한 트렌드를 감지하고 유효한 평균을 도출하는 데는 대략 10초 가량의 분석 프로세스가 필요합니다.² 세 번째이자 가장 중요한 메트릭은 WarningLevel(경고 수준)이라고 하며, 운영체제가 발열 상태에 보일 반응을 결정하는 범주형 분류입니다.²
경고 수준 (WarningLevel)운영체제 상태게임 엔진에서의 Adaptive Performance 반응NoWarning (0)기기가 최적 온도에 있습니다. 어떠한 발열 기반 속도 저하도 존재하지 않습니다. 게임이 목표로 하는 가장 높은 해상도, 프레임 레이트 및 시각적 품질로 렌더링되도록 허용됩니다.²ThrottlingImminent (1)열 용량이 거의 가득 찼습니다. 운영체제가 아직 하드웨어 주파수를 낮추지 않았지만 위험이 매우 임박했습니다. 능동적 개입이 시작됩니다. 시각적 영향이 낮은 스케일러를 활성화하여(예: 그림자 거리 단축) 기기가 다음 단계로 넘어가는 것을 방해하려고 시도합니다.²Throttling (2)하드웨어가 임계 온도에 도달했으며 운영체제가 자신을 보호하기 위해 CPU/GPU 클럭 주파수를 공격적으로 낮추었습니다. 가장 공격적인 최적화 비용이 청구됩니다. 목표 프레임 레이트(Target FPS)가 극적으로 떨어지고, 메인 렌더링 해상도가 제한되며, 기기가 정상 온도로 돌아가도록 급진적인 타협이 이루어집니다.²
프레임 타이밍 및 병목 현상(Bottleneck) 감지
게임이 초당 60프레임 속도에 도달하지 못하는 원인은 여러 하드웨어적 부족함에서 비롯될 수 있습니다. 문제가 그래픽 처리 장치(GPU)의 부족 때문인지, 아니면 중앙 처리 장치(CPU)의 연산 능력이 고갈되었기 때문인지 찾아내는 것이 최적화의 첫 번째 규칙입니다. Adaptive Performance는 이 분석을 수행하기 위해 매 프레임마다 averageFrameTime(평균 총 프레임 시간) 및 averageGpuFrameTime(평균 GPU 실행 시간) 데이터를 추적합니다. CPU 시간은 Unity의 메인 스레드가 게임 로직을 실행하고, 렌더 스레드가 데이터를 GPU로 전송할 준비를 하는(드로우 콜 배치 등) 과정을 포함합니다. 17 중요한 세부 사항으로, CPU 시간 측정에는 운영 체제 수준의 차단이나 CPU가 GPU의 작업이 끝나기를 기다리며 유휴 상태로 보내는 시간(유휴/대기 시간)은 포함되지 않습니다. 17 이 시간들을 분석한 결과에 따라 시스템은 현재 병목 현상(PerformanceBottleneck)을 네 가지 범주 중 하나로 분류합니다: ● CPU: 인게임 인공지능 알고리즘, 복잡한 물리 연산 또는 과도한 수의 오브젝트 인스턴스화가 프로세서를 압박하고 있습니다. 20
● GPU: 다중 레이어 투명도 효과(오버드로우), 고해상도 텍스처 로딩, 무거운 포스트 프로세싱 효과(예: SSAO 또는 Bloom)가 그래픽 유닛을 제한하고 있습니다. 22
● TargetFrameRate (Fillrate): 시스템이 이미 목표 프레임 속도에 도달했으며, 하드웨어적 병목 현상이 없고 하드웨어가 잠재력보다 낮게 작동하더라도 충분합니다. 2
● Unknown: 지연의 원인을 정확하게 파악할 수 없는 중간 상태입니다.
개발자는 PerformanceStatus.PerformanceBottleneckChangeEvent 이벤트에 구독(대리자 패턴을 통해)하여 게임 중 병목 현상 상태가 변경되는 순간을 포착하고 이에 적절한 알고리즘적 반응을 취할 수 있습니다. 23 예를 들어, 병목 현상이 갑자기 CPU로 이동할 때 오픈 월드 내 인공지능 유닛의 시야(레이캐스트) 스캔 빈도를 초당 60회에서 15회로 낮추어 프로세서의 수학적 부하를 즉시 완화할 수 있습니다.
의사결정 및 실행 엔진: Indexer와 스케일러(Scalers)
Adaptive Performance 시스템이 자율적으로 작동하도록 하는 메커니즘은 두 가지 핵심 구성 요소의 완벽한 조화에 기반합니다. 바로 "Indexer"(인덱서)라는 두뇌와 "Scalers"(스케일러)라는 실행 기관입니다.
Indexer(인덱서) 메커니즘
Indexer는 기기에서 수신된 복잡한 발열 경향과 병목 현상 데이터를 지속적으로 수학적 필터에 통과시켜 게임의 현재 "품질 지수"를 계산하는 중앙 코디네이터입니다. 19 Indexer의 주요 임무는 하드웨어의 미세한 온도 또는 FPS 변동마다 게임 품질을 지속적으로 변경하여 시각적 불일치(진동)가 발생하는 것을 방지하는 것입니다. 이 안정성을 보장하기 위해 Project Settings 내에서 Thermal Action Delay(열 동작 지연) 및 Performance Action Delay(성능 동작 지연)를 초 단위로 정의할 수 있습니다. 23 시스템이 병목 현상을 감지하더라도 정의된 이 지연 시간 동안 상태가 영구적인지 확인한 후 작업 결정을 내리고, 연결된 스케일러에 품질을 낮추도록(StateAction.Decrease) 신호를 보냅니다. 23
스케일러(Scalers)의 수학적 및 시각적 영향 분석
스케일러는 Unity의 렌더 파이프라인 또는 물리 엔진의 특정 기능을 런타임에 변경하는 스크립트입니다. 19 각 스케일러의 기본 레벨(Level)은 0입니다. Indexer로부터 "품질 저하" 신호가 올 때마다 이 레벨이 증가하며, 레벨이 높아질수록 스케일러가 제어하는 기능의 세부 사항이 감소합니다. 19 스케일러가 언제 어떤 순서로 활성화될지는 3차원 결정 매트릭스에 의해 결정됩니다 19 :
1. 병목 현상 대상(Targeting Bottleneck): 분석 결과 병목 현상이 GPU로 판명되면, Indexer는 CPU를 최적화하는 스케일러를 건너뛰고 GPU를 직접 타겟팅하는(예: 해상도) 스케일러를 강제합니다.
2. 최저 레벨(Lowest Level): 아직 레벨이 올라가지 않은(원래 품질을 유지하는) 기능이 우선시됩니다.
3. 시각적 영향(Visual Impact): 기능의 품질이 저하될 때 플레이어가 이를 알아차릴 가능성입니다. 낮음(Low), 중간(Medium) 또는 높음(High)으로 분류됩니다. 19 시스템은 항상 시각적 영향이 낮은 기능부터 줄이기 시작합니다.
이 시스템은 표준 렌더 파이프라인과 Universal Render Pipeline(URP) 모두에 대해 매우 광범위한 스케일러 제품군을 제공합니다. 다음 표는 이러한 스케일러의 하드웨어 대상과 애플리케이션 내 이론적 영향을 자세히 설명합니다.
스케일러 클래스 병목 현상 대상 시각적 영향 렌더 파이프라인에서의 이론적 및 실무적 영향 AdaptiveFramerat e CPU / GPU / Fillrate 높음 게임의 Application.targetFr ameRate 변수를 범위 내에서 수정합니다. 특히 VSync가 꺼져 있을 때 효과적입니다. 60 FPS에서 30 FPS로의 하락은 칩의 모든 구성 요소 유휴 시간을 증가시켜 급진적인 냉각 기간을 생성합니다. 19 AdaptiveResolutio n GPU / Fillrate 높음 화면 렌더링 해상도의 스케일(Resolution Scale)을 동적으로 낮춥니다. 19 URP 프로젝트에서 Render Scale을 통해 작동합니다. 픽셀 채우기 속도(fillrate)를 기하학적 비율로 감소시키기 때문에 GPU 열 부하를 깨는 가장 강력한 무기이지만, 이미지 선명도를 직접적으로 손상시킵니다. 15 AdaptiveLOD CPU / GPU 중간 씬에 있는 3차원 모델의 상세 수준(Level of Detail - LOD) 전환 거리(LOD bias)를 조작합니다. 18 카메라도 모델에 가까워질 때 저폴리곤 버전이 화면에 유지되도록 하여 CPU 드로우 콜과 GPU 버텍스 연산을 줄입니다. 18 AdaptiveShadow mapResolution GPU 중간/낮음 URP에서 그림자 맵의 픽셀 해상도를 낮춥니다. 화면에 움직임이 많을 때 그림자 모서리가 픽셀화되는 것은 인지적으로 감지하기 어려운 상황이므로 품질 저하 없이 GPU 메모리 대역폭을 여유롭게 만듭니다. 19 AdaptiveShadowC ascade CPU / GPU 중간 URP 디렉셔널 라이트의 캐스케이드 수를 줄입니다. 각 그림자 캐스케이드는 씬에서 그림자를 드리우는 오브젝트를 한 번 더 렌더링(드로우 콜)해야 합니다. 캐스케이드 수가 감소하면 CPU 병목 현상이 직접적으로 완화됩니다. 19 AdaptiveViewDist ance CPU / GPU 높음 메인 카메라의 원거리 클립 평면(far clip plane)을 좁혀 먼 거리의 오브젝트가 렌더링 흐름에 전혀 포함되지 않도록(frustum culling) 합니다. 19 특히 오픈 월드 게임에서 가장 중요한 최적화 단계 중 하나입니다. 15 AdaptiveLayerCull ing CPU / GPU 중간 전체 시야 거리를 줄이는 대신 특정 Unity 레이어(Layers)의 가시성 거리를 조정합니다. 2 예를 들어, 환경 세부 사항(풀, 작은 장식) 레이어의 렌더링 거리를 제한하여 플레이어 주변의 큰 구조물은 보호하면서 작은 세부 사항을 지워 성능을 향상시킵니다. 16 AdaptivePhysics CPU 높음 Unity 물리 엔진(PhysX 또는 Box2D)의 업데이트 단계(fixedDeltaTime) 또는 반복 횟수를 수정하여 CPU 부하를 완화합니다. 2 물리 연산은 CPU 기반 병목 현상의 가장 큰 주범 중 하나입니다. 21 AdaptiveBatching CPU 낮음 동적 배칭(Dynamic Batching) 프로세스를 제어합니다. 과도한 버텍스 연산이 필요 없는 상황에서 CPU를 완화합니다. 19 AdaptiveDecals CPU / GPU 낮음 URP 시스템에서 벽의 탄흔, 혈흔 등 데칼의 렌더링 거리나 개수를 제한하여 머티리얼 렌더링 단계의 오버드로우 부하를 줄입니다. 2
개발자가 기본 스케일러에만 국한될 필요는 없습니다. 게임의 특정 메커니즘에 적합한 "커스텀 스케일러"(Custom Scalers)를 개발하는 것은 강력히 권장되는 관행입니다. 2 커스텀 스케일러를 작성하려면 AdaptivePerformanceScaler 클래스를 상속받고 VisualImpact, Target, MaxLevel 같은 기본 속성뿐만 아니라 OnLevel() 메서드를 오버라이드하는 것만으로 충분합니다. 19 예를 들어, 안개가 낀 환경에서 진행되는 게임에서 커스텀 스케일러를 작성하여 온도가 상승함에 따라 안개의 밀도를 높일 수 있습니다(Adaptive Fog). 이를 통해 플레이어의 시야 거리가 자연스럽게 좁아지는 동시에 백그라운드에서 카메라의 렌더링 거리가 단축되어 상당한 최적화 환영(illusion)이 만들어질 수 있습니다. 15
성능 제어 모드 및 클럭 주파수(Clock Frequency) 관리
Adaptive Performance는 게임 엔진 내의 그래픽 기능을 줄이는 것뿐만 아니라, 운영 체제가 CPU 및 GPU에 제공하는 전력과 클럭 주파수에 간접적으로 또는 직접적으로 개입할 수 있는 기능도 가지고 있습니다. 프로세서가 최대 클럭 속도로 작동하는 것은 점근적 비효율성을 초래합니다. 즉, 얻은 약간의 추가 연산 능력에 비해 엄청난 양의 에너지가 소비되고 열이 발생합니다. 17
이 에너지 균형을 관리하기 위해 Adaptive Performance 인터페이스는 세 가지 제어 모드(PerformanceControlMode)를 제공합니다: 시스템, 수동 및 자동. 20
시스템 모드(System Performance Control): Android 공급업체 외의 시스템(예: 데스크톱 시뮬레이션)에 적용되는 기본 모드입니다. 운영 체제가 기존 방식으로 CPU/GPU 주파수를 직접 결정하며, Adaptive Performance는 하드웨어에 개입하지 않고 인앱 그래픽만 줄입니다. 20
수동 모드(Manual Performance Control): 개발자가
Instance.DevicePerformanceControl.CpuLevel및GpuLevel변수를 0과 최대 레벨 사이에서 직접 할당할 수 있는 모드입니다. 23 이 제어 모드의 사용은 매우 구체적인 벤치마크 테스트를 제외하고는 절대 권장되지 않습니다. 17 모바일 하드웨어의 열 제약 및 배터리 방전 특성에 대한 깊은 지식이 없는 개발자가 CPU 레벨을 계속 높게 유지할 경우 장치가 빠르게 과열되며, 운영 체제가 방어 메커니즘을 활성화하여 게임을 "Throttling" 단계에 가두고 배터리가 무의미하게 소모될 것입니다. 20자동 모드(Automatic Performance Control): 가장 안전하고 효율적이며 강력히 권장되는 제어 모드입니다. 17 개발자가 해야 할 일은 오직
Application.targetFrameRate를 사용하여 게임의 목표 프레임 속도(예: 30 또는 60)를 설정하는 것뿐입니다. 23 자동 모드는 백그라운드에서 기기 온도, 렌더링 시간, 실행 환경(메뉴에 있는지 게임 중에 있는지)을 분석합니다. 20 게임이 60 FPS 목표에 매우 쉽게 도달하면 프로세서를 불필요하게 최대 용량으로 실행하는 대신 CPU 및 GPU 클럭 주파수를 조용히 낮춥니다. 프레임 속도는 여전히 60으로 유지되지만 하드웨어가 훨씬 적은 전력을 소비하여 게임을 시원하게 유지하고 배터리가 몇 시간 동안 지속되도록(Battery Life Preservation) 보장합니다. 20
일시적인 전력 부스트: 부스트 모드(Boost Mode)
모바일 게임의 특정 순간에는 지속 가능한 성능보다는 순간적으로 매우 큰 연산 용량이 필요합니다. 이러한 특정 시나리오를 위해 Adaptive Performance는 "Boost"(부스트) API를 포함하고 있습니다. 23 부스트 모드가 호출되면 CPU 또는 GPU의 최소 작동 주파수가 일시적으로 최대 작동 주파수와 같아지도록 강제되어 하드웨어가 최대 잠재력으로 작동하게 됩니다. 23
부스트 모드를 전략적으로 사용해야 하는 곳은 다음과 같습니다 23 :
● 게임이나 스테이지 로딩 시의 대기 화면에서(Loading Screens), 메모리로 가져올 무거운 모델의 로딩 시간(load time)을 최소화하기 위해.
● 네트워크(Network)를 통해 다운로드된 큰 패킷의 압축 해제 또는 비동기 데이터 처리 작업 중에 발생하는 대기 시간을 제거하기 위해.
● 셰이더 컴파일(Shader Compilation) 또는 절차적 콘텐츠 생성 단계에서 플레이어가 겪을 수 있는 초 단위의 마이크로 스터터링(hitches)을 방지하기 위해.
그러나 부스트 모드의 활성화는 기기의 배터리에서 엄청난 전류를 끌어내며 SoC 온도를 즉시 상승시킵니다. 23 운영 체제가 이미 Throttling(병목) 단계에 진입한 경우(기기가 과열된 경우), 하드웨어 손상을 방지하기 위해 Unity의 부스트 요청 또는 수동 CPU/GPU 레벨 조정 명령이 운영 체제에 의해 직접 거부되고 제어권이 "시스템 모드"로 강제 전환됩니다. 23 개발자가 이 인터페이스를 플레이어가 수동적으로 대기하는 로딩 화면과 짧은 시간 동안만 사용하는 것은 생명처럼 중요합니다.
개발자 인터페이스: C# API 사용 및 Visual Scripting (시각적 스크립팅)
Adaptive Performance 패키지의 유연성은 개발자가 원할 경우 한 줄의 코드도 작성하지 않고 자율 시스템을 사용할 수 있게 해 주며, 원할 경우 게임의 핵심까지 파고드는 사용자 정의 로직을 구축할 수 있게 해 준다는 점입니다.
C# API를 통한 이벤트 기반(Event-Driven) 프로그래밍
시스템의 열화상 데이터에 프로그래밍 방식으로 액세스하려는 개발자는 패키지와 함께 생성되는 싱글톤 객체인 UnityEngine.AdaptivePerformance.Holder.Instance(또는 최신 버전의 Mobile.AdaptivePerformance.Holder)를 통해 데이터에 액세스합니다. 18 특히 기기가 병목 현상에 진입하려고 할 때(ThrottlingImminent) 이를 포착하기 위해 IThermalStatus.ThermalStatus.ThermalEvent 이벤트(delegate)를 수신 대기합니다. 2
이벤트가 트리거되면(예: 발열 경고가 수신될 때), switch-case 구문을 통해 상태를 분석하고 게임 메커니즘을 제어합니다. 2 경고 수준이 Throttling인 경우 프레임 속도가 60에서 15 또는 30으로 낮아지고, 경고가 없으면 다시 60을 목표로 돌아갑니다. 2 마찬가지로 병목 현상이 CPU 측에 있는 경우, 사용자 정의 스크립트(script)를 사용하여 맵에 있는 활성 인공지능 에이전트 중 일부를 비활성화함으로써 프로세서의 부하를 즉시 줄일 수 있습니다. 2
Visual Scripting(시각적 스크립팅) 통합
프로그래머가 아닌 테크니컬 아티스트(technical artists)와 게임 디자이너를 위해 Unity 5.0 이후 버전에서는 Visual Scripting 패키지를 통해 C# API에 대한 완전한 지원이 도입되었습니다. 29
프로젝트에 Visual Scripting 패키지가 포함된 후 Edit > Project Settings > Visual Scripting > Node Library > Regenerate Units 경로를 따라 Adaptive Performance 노드(nodes)가 Fuzzy Finder 인터페이스에 추가되도록 해야 합니다. 27
이 통합 덕분에 일련의 특수 노드에 액세스할 수 있습니다 30 :
● Thermal 노드: On Thermal Metric 노드는 기기의 발열 경고 수준, 온도 백분율(Temperature Level) 및 온도 추세(Trend)가 변경될 때 즉시 트리거됩니다. 이 노드의 출력 단자는 씬에 있는 무거운 광원이나 파티클 시스템을 직접 끄는 로직에 연결할 수 있습니다.
● Performance 노드: On Bottleneck 노드는 병목 현상이 CPU, GPU 또는 Fillrate인지 신호를 보내고, Frame Timing 및 FPS 노드는 게임 화면에 실시간 성능 데이터를 출력하는 데 이상적입니다. Cluster Info 노드 덕분에 big.LITTLE 아키텍처의 코어 부하를 읽을 수 있습니다.
● Boost 및 Levels 노드: 시각적 스크립팅 그래프의 씬 로딩 블록 시작 부분에 Set Boost 노드를 추가하여 코드를 작성하지 않고도 로딩 속도를 극대화할 수 있으며, Get Performance Level을 사용하여 현재 프로세서 상태를 읽을 수 있습니다.
테스트, 프로파일링 및 최적화 방법론
Adaptive Performance 시스템을 프로젝트에 추가한다고 해서 모든 문제가 혼자서 해결되지는 않습니다. 올바르게 구성되지 않은 시스템은 게임의 그래픽 품질을 너무 일찍 떨어뜨리거나 아무런 효과가 없을 수 있습니다. 개발 과정은 과학적 측정 및 벤치마킹 방법론(profiling and benchmarking)에 기반해야 합니다.
기본 벤치마크(Baseline) 생성 및 A/B 테스트
Google과 Unity 엔지니어의 공동 최적화 관점에 따르면, 첫 번째 단계는 ADPF 또는 Adaptive Performance가 활성화되기 전 게임의 성능을 측정하는 것입니다(Baseline). 6 게임은 목표로 하는 최소 사양(min-spec)을 가진 물리적 모바일 기기에 설치되어야 하며 기기가 뜨거워질 때까지 약 20분 동안 플레이되어야 합니다. 21 이 테스트 중에 Unity Profiler 도구를 무선 네트워크(Wi-Fi)를 통해 기기와 통신하게 하고(Autoconnect Profiler) FPS가 떨어지기 시작하는 시간과 Frame Time 값을 기록해야 합니다. 1
그런 다음 Adaptive Performance 시스템이 기본 스케일러와 함께 프로젝트에서 활성화되고 동일한 테스트 시나리오가 처음부터 다시 실행됩니다. 6 Profiler 모듈의 새로운 "Adaptive Performance" 탭을 통해 기기가 ThrottlingImminent 경고를 보낸 시간, 시스템이 실행한 스케일러(예: AdaptiveResolution) 및 이것이 CPU/GPU 시간에 미친 영향이 첫 번째 테스트와 나란히 비교되어 검토되어야 합니다. 2 개발자가 "게임이 10분째에도 60 FPS를 유지하지만 해상도가 너무 많이 떨어진다"와 같은 결과를 발견하면 Indexer의 스케일러 가중치를 조정하고 게임 고유의 미세 조정(fine-tuning)을 수행해야 합니다. 6
데스크톱 환경에서의 시뮬레이션: Device Simulator
기기 테스트가 필수적이기는 하지만, 실제 전화기가 가열되고 식는 것을 기다리는 것은 코딩 단계에서의 반복 속도를 떨어뜨립니다. 이 문제를 극복하기 위해 Simulator (Desktop) Provider가 개발되었습니다. 2 데스크톱 개발 컴퓨터에서 Window > General > Device Simulator 창을 열고 가상 기기의 배터리 잔량, 발열 추세, 병목 현상을 인위적으로(artificial bottlenecks) 트리거할 수 있습니다. 2 개발자는 단 한 번의 클릭으로 가상 기기의 상태를 Throttling 단계로 전환하고, 작성한 사용자 정의 스케일러(Custom Scalers)가 게임의 안개 밀도나 모델 상세도(LOD)를 어떻게 변경하는지 몇 초 안에 즉시 테스트할 수 있습니다. 2
기존 최적화 접근 방식과의 시너지
Adaptive Performance는 기적의 알고리즘이 아닙니다. 기초가 잘못 설계된 게임을 혼자서 구할 수는 없습니다. 이 시스템은 기존의 모바일 최적화 관점과 결합할 때 엄청난 승수 효과를 창출합니다. 1
● 게임의 텍스처(textures)는 2의 제곱(POT - Power of Two) 크기로 설계되어야 하며 ASTC, ETC2와 같은 모바일 하드웨어 압축 포맷을 사용해야 합니다. 8
● 런타임에 변경되지 않을 모델과 텍스처의 Read/Write Enabled 옵션을 비활성화하여 CPU 및 GPU 메모리에 불필요한 복사본이 유지되는 것을 방지해야 합니다. 31 메모리 소비량(memory bandwidth)은 발열의 가장 큰 원인 중 하나입니다. 1
● 모바일 하드웨어의 가속도계(accelerometer) 센서가 게임에서 활발하게 사용되지 않는 경우(예: 레이싱 게임이 아닐 때) Player Settings를 통해 가속도계 스캔 빈도를 줄이거나 끄는 것은 운영 체제에 큰 부담을 덜어주어 열 엔벨로프(thermal envelope)를 넓혀줍니다. 31
● 기기 카메라의 컬링 행렬(Occlusion Culling)을 신중하게 베이크(baked)해야 하며, 카메라의 시야각에 없지만 벽 뒤에 있는 수만 개의 폴리곤 모델은 그래픽 프로세서로 전송되기 전에(draw call) CPU에서 제거되어야 합니다. 3
이러한 모든 기존 조치를 통해 발열 시간이 15분으로 연장된 게임이 최종 방어선인 Adaptive Performance의 AdaptiveResolution 또는 AdaptiveFramerate 스케일러로 지원될 때, 플레이어가 60 FPS에서 45 FPS로의 하락을 전혀 알아차리지 못하는 완벽하고 지속 가능한 모바일 걸작으로 탈바꿈합니다.
모바일 하드웨어에 냉각 팬이 없다는 점은 게임 개발자가 실리콘의 열 한계와 체스를 두도록 강제합니다. "Adaptive Performance Settings"와 같은 간단한 공급자 설치 경고로 시작된 이 기술적 여정은 운영 체제의 전력 관리 밸브에 대한 액세스, 열 분석 파생 상품 읽기 및 렌더링 파이프라인의 품질 알고리즘을 실시간으로 조작하는 숙련도로 이어집니다. 최적화 과정은 최고 성능(peak performance)에 도달하는 것보다 유창한 프레임 속도의 지속 가능성(sustained performance)에 초점을 맞출 때 플레이어의 만족도를 극대화할 뿐만 아니라 모바일 플랫폼에서의 장기적인 성공의 열쇠를 쥐게 됩니다.
*참고: 이미지는 Google Gemini에 의해 생성되었습니다.