서장: Unity의 진화와 튜닝의 현주소

전작 『Unity Performance Tuning Bible』 이후 수년이 지나는 동안 Unity, 기기, 튜닝을 진행하는 방식 모두에 변화가 있었습니다. 이 서장에서는 먼저 엔진과 기기의 변화를 대략적으로 되돌아본 다음, 2026년 시점에 튜닝이 어디로 향하고 있는지를 서술합니다.

변한 전제, 변하지 않은 전제

Unity에서 가장 크게 움직인 것은 렌더링입니다. Unity 6에서 URP에 Render Graph가 도입되면서, 최적화 작업의 중심은 커맨드를 직접 재배열하는 일에서 리소스의 사용 방식을 엔진에 올바르게 선언하고 그 결과를 확인하는 일로 옮겨 갔습니다. 셰이더 웜업이나 오브젝트별 파라미터를 전달하는 방식에도 Unity 6 세대에서 새로운 선택지가 추가되었습니다. C# 쪽은 Unity 6에서는 크게 달라지지 않지만, Unity 7에서는 에디터와 일부 데스크톱 플레이어에 CoreCLR가 도입되어 GC의 구조도 크게 바뀝니다. 한편 모바일은 당분간 IL2CPP와 Boehm GC가 유지되므로, 지금까지의 메모리 최적화 방식은 계속 유효합니다. 빌드와 배포 주변에서는 코드를 수정하지 않고도 용량·메모리·속도의 균형을 조절할 수 있는 설정이 늘었습니다.

기기도 크게 달라졌습니다. GPU의 Geekbench 점수*1로 비교하면, 전작을 집필하던 2022년의 하이엔드인 iPhone 14 Pro(A16)는 18,691이었지만, 2026년의 iPhone 18 Pro와 iPhone Duo에 탑재된 A20 Pro는 55,120으로 약 3배가 되었습니다. Android 쪽도 Galaxy S22(Snapdragon 8 Gen 1, Adreno 730)의 6,179에 비해 Galaxy S26 Ultra(Snapdragon 8 Elite Gen 5 for Galaxy, Adreno 840)는 27,501로 4배를 넘습니다.

다만 로우엔드는 그다지 달라지지 않았습니다. 일본 국내에서 2022년에 발매된 Galaxy A23 5G는 Dimensity 700(Mali-G57 MC2)과 메모리 4GB 구성이었습니다. 2025년에 발매된 같은 시리즈의 Galaxy A25 5G도 SoC는 Dimensity 6100+로 바뀌었지만 GPU는 같은 Mali-G57 MC2로 점수는 1,400이고, 메모리도 4GB 그대로입니다. Galaxy S26 Ultra와는 약 20배의 차이가 있습니다.

iPhone도 2022년 시점에는 iPhone SE(2세대)를 비롯해 메모리 3GB 이하의 기기가 아직 널리 사용되고 있었습니다. 2026년에는 iPhone 14 이후의 메모리 6GB 이상 기기가 주류가 되었지만, 이미 2022년 시점에 일상 사용에 충분한 성능의 기기가 보급되어 있었기 때문에 새 기기가 나와도 교체가 잘 진행되지 않습니다. 2025년 초까지 판매된 iPhone SE(3세대)나 iPhone 13 등 4GB 기기가 지금도 많이 남아 있으며, 3GB인 iPhone SE(2세대)도 아직 일부에서 사용되고 있습니다.

그 결과 어느 기기까지를 타깃으로 삼을 것인가 하는, Android에서 오래 고민해 온 문제가 iOS에서도 무시할 수 없게 되었습니다. 위로는 메모리 12GB의 iPhone 18 Pro에서 아래로는 3GB의 iPhone SE(2세대, 2020년 발매)까지, 같은 타이틀이 대응해야 하는 기기의 폭이 넓어졌습니다. 게임 장르에 맞춰 기기 성능에 따라 렌더링 표현이나 품질 설정을 전환하는 방안이 이전보다 더 요구됩니다(제3부 3장 「기기에 따른 렌더링 설정 전환」).

[*1] Geekbench Browser https://browser.geekbench.com/

그렇다 해도 해결하려는 문제 자체는 전작 때와 크게 다르지 않습니다. 모바일 GPU의 메모리 대역폭, 대량의 오브젝트를 그릴 때의 CPU 부하, 셰이더 컴파일로 인한 스파이크, 에셋 해제 누락, 기기별 메모리 상한. 새로운 기능의 대부분은 이러한 기존 문제에 대한 새로운 도구입니다. 그래서 이 책은 Unity 6 이후에서만 쓸 수 있는 기능만 다루지 않습니다. 캐릭터 애니메이션 부하 대책, 셰이더 초월 함수의 근사, AssetBundle의 수명 관리, iOS 메모리 상한 상향 등 그 이전 버전의 프로젝트에도 그대로 적용할 수 있는 내용도 많이 포함하고 있습니다.

제1부부터 제3부의 첫머리에서는 해당 영역에서 2026년에 무엇이 달라졌고 각 장에서 무엇을 다루는지를 다시 정리합니다. 증상에서 장을 찾고 싶다면 권두의 「과제별 역방향 찾기 가이드」를 참조하시기 바랍니다.

튜닝의 현주소 — 계측과 자동화

한편 개발 현장에서 2026년에 가장 큰 관심사가 된 것은 AI입니다. AI 코딩 에이전트는 구현과 리뷰의 일부를 맡기는 도구로 일상적으로 쓰이게 되었고, 퍼포먼스 튜닝도 예외가 아닙니다. 이 책의 제4부 3장 「튜닝 바이블을 AI 코딩 에이전트의 스킬로 만들기」에서는 전작과 이 책의 지식을 에이전트의 평가 규칙으로 변환하는 시도를 다룹니다.

다만 튜닝에는 AI에 맡기기 이전의 전제가 있습니다. 계측입니다. 어디가 느린지 측정하지 않고 손을 대면 빨라졌는지 판단할 수 없습니다. 그래서 업계 전체적으로는 먼저 계측 자동화를 향한 노력이 진행되고 있습니다. 빌드마다 정해진 절차로 실기기의 수치를 취득하고 과거 측정값과 비교해 열화를 자동으로 감지함으로써, 사람이 Profiler를 여는 횟수를 줄이고 발견이 늦어지지 않도록 하는 방향입니다.

저자들이 소속된 사이버에이전트 게임·엔터테인먼트 사업부에서도 자동화의 일환으로 AI 에이전트가 Unity 앱을 실시간으로 관찰하고 조작하기 위한 런타임 브리지를 갖추고 있습니다. 이를 디바이스 팜과 결합하여, CI에서 「기종을 확보하고 앱을 설치한 뒤 정해진 절차대로 조작하고 계측하여 결과를 가져오는」 것까지를 에이전트에 맡기는 구성입니다. 계측에는 실기기 앱에 내장한 런타임 프로파일러를 사용하고, 취득한 데이터를 서버로 전송하여 브라우저에서 과거 측정값과 나란히 확인하거나 임계값을 넘은 변화를 알릴 수 있도록 했습니다. 서버로 전송한 데이터는 이후 AI 에이전트가 가져와 병목 진단부터 수정까지를 수행합니다(제4부 2장 「데일리 빌드의 실기기 프로파일링을 자동화합니다」).

물론 이로써 사람의 판단이 필요 없어지는 것은 아닙니다. 무엇을 보고, 무엇과 비교하고, 어디서 멈출 것인가 하는 기준은 여전히 사람이 갖고 있어야 합니다. 자동화할 수 있는 것은 그 기준이 이미 있는 부분뿐입니다. 이 책이 실측값과 함께 판단의 재료를 나열하는 것도 그 때문입니다.