모바일 발열 제어의 예술: 퍼포먼스를 극대화하는 커스텀 HLSL 언릿 셰이더 설계

1. 모바일 GPU 아키텍처의 한계와 타일 기반 지연 렌더링(TBDR)의 이해

최신 스마트폰의 하드웨어 스펙이 아무리 비약적으로 발전했다 하더라도, 데스크톱 PC와 모바일 기기 사이에는 결코 뛰어넘을 수 없는 물리적 장벽이 존재합니다. 그것은 바로 '발열 해소(Thermal Throttling)'와 '배터리 수명'입니다. 스마트폰은 쿨링팬이 없는 폐쇄적인 폼팩터를 가지고 있기 때문에, GPU가 과부하되어 열이 일정 온도 이상 치솟게 되면 기기 보호를 위해 스스로 클럭 속도를 강제로 낮추는 쓰로틀링이 발생합니다. 이는 곧 끔찍한 프레임 드랍으로 이어집니다. 모바일 GPU(Adreno, Mali 등)는 전력 효율을 극대화하기 위해 PC GPU와는 다른 방식인 타일 기반 지연 렌더링(TBDR, Tile-Based Deferred Rendering) 아키텍처를 주로 사용합니다. 화면을 작은 바둑판 모양의 타일(Tile)로 쪼개어, 각 타일에 속한 폴리곤들만 온칩(On-chip) 메모리에서 초고속으로 처리한 후 최종 결과를 메인 메모리로 넘기는 방식입니다. 이 구조에서는 메인 메모리로의 대역폭(Bandwidth) 접근 횟수가 배터리 소모와 발열의 최대 적이 됩니다. 따라서 모바일 셰이더 프로그래머는 화려한 시각 효과보다, 픽셀 셰이더 연산량 감소와 텍스처 메모리 대역폭 최소화를 최우선 과제로 삼아야 합니다. 이 최적화 딜레마를 해결하기 위한 가장 강력하고 근본적인 처방전이 바로 빛의 연산을 통째로 걷어낸 '언릿(Unlit)' 셰이더를 직접 설계하는 것입니다.

2. 셰이더 연산 비용: 빛(Lighting) 연산을 버리고 얻는 압도적 이득

언리얼이나 유니티 같은 상용 게임 엔진에서 기본적으로 제공하는 Standard Shader(혹은 Lit 머티리얼)는 물리 기반 렌더링(PBR)을 지원하기 위해 내부적으로 엄청난 수학 연산을 수행합니다. 알베도, 메탈릭, 러프니스 맵을 샘플링하는 것은 물론이고, 디렉셔널 라이트, 포인트 라이트, 그림자 맵(Shadow Map), 그리고 글로벌 일루미네이션을 위한 SH(Spherical Harmonics) 프로브까지 수많은 벡터 내적 연산과 조건문이 픽셀마다 실행됩니다. 수백만 개의 픽셀이 초당 60번씩 이 연산을 수행한다면 모바일 기기는 곧바로 뜨거운 손난로로 전락합니다. 커스텀 HLSL 언릿(Unlit) 셰이더를 작성한다는 것은 바로 이 무거운 빛 연산 덩어리를 송두리째 잘라내는 외과 수술과도 같습니다. 언릿 셰이더는 버텍스의 위치를 투영 좌표계로 변환하고, 지정된 텍스처를 픽셀에 매핑하여 출력하는 가장 원초적이고 순수한 형태의 셰이더입니다. 조명 연산이 없기 때문에 입체감이 사라지는 문제가 발생하지만, 이는 텍스처 자체에 명암과 그림자를 미리 그려 넣는 손맵(Hand-painted) 아트 기법이나 라이트매핑(Lightmapping) 베이킹 기법을 통해 훌륭하게 극복할 수 있습니다. 계산은 오프라인에서 미리 처리하고, 런타임 GPU에는 단순한 픽셀 색상 복사 작업만 맡기는 것이 모바일 최적화 셰이더 설계의 대원칙입니다.

3. 커스텀 HLSL 코드 작성: 최소한의 수학으로 최대한의 표현 끌어내기

유니티의 URP 환경에서 HLSL을 이용해 커스텀 언릿 셰이더를 작성할 때 연산 비용을 줄이기 위한 몇 가지 코드 레벨의 철칙이 있습니다. 첫째, 데이터 타입의 정밀도(Precision)를 철저히 구분해야 합니다. 좌표나 깊이 값처럼 세밀한 소수점 연산이 필요한 곳에는 32비트 `float`을 쓰지만, 색상 값(0~1)이나 텍스처 UV 좌표 연산에는 반드시 절반의 메모리와 레지스터만 차지하는 16비트 `half`를 사용해야 합니다. 최신 모바일 칩셋들은 `half` 연산에 특화된 별도의 ALU 구조를 가지고 있어 성능 향상이 극명하게 나타납니다. 둘째, 비싼 내장 수학 함수의 사용을 기피해야 합니다. `pow()`, `sin()`, `cos()`, `normalize()` 같은 함수들은 매우 무거운 연산입니다. 예를 들어 반사광(Specular) 효과를 언릿 셰이더 내부에서 아주 가볍게 구현하고 싶다면 복잡한 퐁(Phong) 반사 모델의 거듭제곱 연산 대신 단순화된 근사식이나 룩업 텍스처(LUT)를 샘플링하는 방식으로 대체해야 합니다. 셋째, 픽셀 셰이더(Fragment Shader) 내부의 연산을 최대한 버텍스 셰이더(Vertex Shader)로 끌어올리는 것입니다. 화면을 채우는 픽셀의 개수는 수백만 개지만, 버텍스의 개수는 수만 개 수준에 불과합니다. 카메라와의 거리 계산이나 간단한 색상 변조 작업 등 픽셀마다 세밀하게 달라질 필요가 없는 연산은 버텍스 셰이더에서 미리 계산한 뒤 보간(Interpolate)하여 넘기는 것만으로도 막대한 발열 감소 효과를 얻을 수 있습니다.

4. 오버드로우(Overdraw)와 알파 테스팅(Alpha Testing)의 뼈아픈 함정 극복

셰이더 코드가 아무리 가볍게 최적화되었다 하더라도, 투명도 처리 방식에서 실수를 범하면 모든 노력이 물거품이 됩니다. 모바일 환경의 최대 적은 바로 '오버드로우(Overdraw)'입니다. 화면의 같은 픽셀 위치를 반투명한 이펙트나 나뭇잎들이 여러 번 덧칠하는 현상으로, TBDR 아키텍처의 온칩 메모리 대역폭을 극심하게 소모시킵니다. 초보 개발자들은 나뭇잎이나 풀잎의 외곽선을 뚫어내기 위해 흔히 `clip()` 함수나 Z-Write를 끄는 Alpha Test/Blend 셰이더를 무분별하게 사용합니다. 그러나 모바일 GPU에서 `clip()` 같은 `discard` 명령어는 하드웨어가 제공하는 강력한 최적화 기능인 Early-Z 리젝션(보이지 않는 픽셀의 셰이더 연산을 사전에 건너뛰는 기술)을 완전히 무력화시킵니다. 픽셀을 그릴지 말지를 셰이더 연산 끝부분에서야 결정하기 때문입니다. 발열을 잡기 위해 투명도가 필요한 나뭇잎이나 철조망을 표현할 때는, 알파 테스팅을 사용하는 대신 폴리곤의 개수를 조금 더 늘리더라도 투명한 영역을 칼같이 잘라낸 불투명(Opaque) 메쉬 형태로 모델링하는 것이 오히려 성능에 유리한 경우가 많습니다. 반드시 반투명이 필요한 UI나 파티클의 경우라면, 스크린 비율 대비 너무 큰 면적을 덮지 않도록 파티클 크기를 제어하고, 깊이 정렬이 필요 없는 Additive 블렌딩 모드를 활용하는 커스텀 패스를 구성해야 합니다.

5. 프로파일링과 마무리: 눈에 보이지 않는 전력 소모의 추적

완벽한 언릿 셰이더를 작성했다면, 실제 기기에서의 정밀한 프로파일링을 통해 그 효과를 입증해야 합니다. 모바일 기기의 발열을 측정하기 위해 Unity의 프레임 디버거(Frame Debugger)를 열어 렌더링 순서와 드로우 콜 횟수를 체크하고, 불필요한 풀스크린 패스(Post-processing)가 언릿 셰이더의 가벼움을 덮어버리고 있지는 않은지 확인합니다. 또한, ARM Mobile Studio나 Xcode의 Instruments와 같은 네이티브 프로파일링 툴을 기기에 연결하여 GPU 클럭 속도, 메모리 읽기/쓰기 대역폭 사용량, 그리고 가장 중요한 전력 소모(Watt) 수치를 모니터링해야 합니다. 텍스처 압축 방식 또한 중요한데, Android에서는 ASTC, iOS에서는 텍스처를 철저히 압축하여 셰이더가 텍스처 샘플링을 할 때 발생하는 메모리 대역폭 부하를 최소화해야 합니다. 언릿 셰이더 하나로 모든 그래픽 품질 문제를 해결할 수는 없지만, 씬 전체를 뒤덮는 배경 바닥, 먼 배경의 산, 그리고 자잘한 프랍들에 철저하게 최적화된 커스텀 HLSL 언릿 머티리얼을 바름으로써 우리는 GPU에 여유 공간을 마련할 수 있습니다. 이렇게 아낀 자원을 주인공 캐릭터의 디테일이나 화려한 핵심 이펙트에 재투자할 때, 발열은 잡으면서도 유저들의 눈을 사로잡는 마법 같은 모바일 그래픽 밸런싱이 비로소 완성되는 것입니다.