Optimizing Deep Rock Galactic Survivor for mobile

3줄 요약

1. Unity가 2026년 9월 18일에 게시한 개발자 인터뷰다. 펀데이 게임즈의 로그라이트 <딥 록 갤럭틱: 서바이버>를 Piktiv(픽티브)가 모바일로 이식했다. 엔지니어링 매니저 마르쿠스 에켈룬드와 수석 엔지니어 프레드리크 오케르블롬이 답했다.
2. 적의 수가 늘어날수록 비용이 커지는 시스템을 전부 다시 만들었다. 경로 탐색에서는 Unity 내장 NavMesh를 버리고 플로 필드를 새로 만들었고, 무거운 물리 쿼리는 KD 트리 질의로 바꿨다. 적 캐릭터는 애니메이션 키프레임을 텍스처에 구워 GPU에서 정점 애니메이션으로 재생한다.
3. 기술 목표를 규정한 것은 램이 3GB뿐인 아이패드 한 대였다. 이 기기에서 게임이 쓸 수 있는 용량은 약 1,850MB였다. Addressables로 바이옴별 에셋을 분리해 그 한도를 맞췄다.

PC 브랜치에서 갈라져 나온 모바일 빌드

Piktiv는 PC 버전이 1.0에 도달하기 전, 아직 개발 중인 상태에서 브랜치를 따로 만들어 모바일 작업을 시작했다. 원래 계획은 모바일 쪽 변경을 메인 브랜치로 다시 합치는 것이었지만, 개발이 진행되는 동안 두 버전의 차이가 너무 커져서 지금도 따로 관리한다. 병합은 PC에서 모바일 쪽으로만 한다.

에켈룬드는 이 구조 덕분에 오히려 작업 속도가 났다고 말했다.

이식 작업의 기술적인 부분에서는 협업이 많지 않았습니다. UI와 UX, 그리고 UI를 어떻게 맞출지를 두고는 협업이 훨씬 많았고요. 덕분에 우리는 아주 빠르게 진행할 수 있었고, 브랜치를 따로 땄기 때문에 그쪽이 구축해 둔 시스템 상당수를 과감하게 부수고 다르게 만들 수 있었습니다. 최적화 목표가 달랐으니까요.

램이 3GB뿐인 아이패드 한 대가 정한 기술 목표

오케르블롬이 밝힌 초기 기술 목표는 단순했다. 이 게임을 모바일에서 돌릴 수 있는가, 그리고 얼마나 넓은 기기 범위를 감당할 수 있는가.

애플 제품을 보면 실제로 출시 대상으로 삼을 만한 등급 구분이 그렇게 촘촘하지 않습니다. 가장 최신 기기들이 있고, 현재 유통되는 제품 상당수를 포함하는 조금 더 넓은 분류가 있고, 그다음이 나머지 전부입니다. 최소한 중간 분류까지는 지원하고 싶었습니다.

그런데 그 범위 안에 램을 3GB만 탑재한 아이패드가 한 대 섞여 있었다. 나머지 기기는 전부 4GB다. 게임에 허용된 용량은 약 1,850MB였고, 이 한도를 넘기면 그대로 끝이었다. 초기 작업의 상당 부분이 램 사용량을 한도 안으로 줄이는 데 들어갔다. 그 작업이 끝난 뒤에야 플랫폼별 실제 성능을 들여다볼 수 있었다. 안드로이드 쪽은 기기가 9,000종 가까이 된다. 전부 제대로 돌아가게 만드는 일만으로도 별도의 전문 분야라고 오케르블롬은 말했다.

적의 수에 비례해 비용이 커지는 시스템

병목이 두드러진 시스템은 활성 오브젝트를 수천 개씩 들고 있는 쪽이었다. 오케르블롬은 데미지 숫자와 투사체, 레벨 자체, 애니메이션이 붙은 3D 적 캐릭터를 그런 시스템으로 꼽았다.

데미지 숫자. 원래는 TextMesh Pro를 쓰는 게임오브젝트였다. 화면에 적이 1,000마리 있는 상태에서 수류탄을 던지면 그 전부가 데미지 숫자를 띄워야 한다. 비용이 드는 곳은 텍스트 메시 생성, 그러니까 폰트가 문자열을 눈에 보이는 형태로 바꾸는 과정이다. Piktiv는 0부터 9까지 숫자를 담은 스프라이트 시트를 만들고, Unity의 일반 파티클 시스템으로 그것을 뿌리는 방식으로 정리했다.

적 캐릭터 렌더링. 스킨드 메시 렌더러가 화면에 1,000개씩 올라가면 제대로 돌아가지 않는다. 확인해 보니 이 적들은 거의 전부 애니메이션이 하나뿐이어서, 여러 애니메이션을 지원할 이유가 없었다. 그래서 애니메이션의 각 키프레임을 텍스처에 구워 넣고, 모든 프레임을 GPU 셰이더가 정점 애니메이션으로 처리하게 했다. CPU 비용은 거의 사라졌다. 단일 정적 메시와 텍스처로 구워 두면 전부 같은 메시에 같은 머티리얼이 되므로 GPU 인스턴싱 같은 기법도 함께 쓸 수 있다.

경로 탐색과 물리 쿼리. PC에서는 Unity 내장 NavMesh를 썼다. 여기에 Unity 엔지니어 팀이 지원에 들어왔고, 그중 한 명이 플로 필드 내비게이션을 쓰는 해법을 만들기 시작했다. 다른 엔지니어는 KD 트리를 구현해 무거운 물리 쿼리 상당수를 없앴다.

플로 필드와 KD 트리

오케르블롬의 설명에 따르면 플로 필드는 경로 탐색 비용이 어디에 붙는지를 뒤집은 방식이다. 에이전트가 20~30개일 때는 환경 메시를 굽고 각 에이전트가 자기 경로를 계산하게 한다. 그런데 에이전트가 수천 개가 되면 비용이 에이전트 수에 비례하므로 여기서 상당한 병목이 생긴다.

플로 필드는 이렇게 만든다. 레벨 전체에 격자를 두고 목표 지점에서 시작한다. 목표 주변의 타일들이 목표를 향한 화살표를 그린다. 한 칸 바깥으로 나가면 이미 화살표가 있는 가장 가까운 타일 쪽으로 다시 화살표가 생긴다. 격자 전체가 채워질 때까지 반복한다. 그러면 비용이 에이전트 하나당 붙지 않고, 경로 탐색을 수행할 영역의 크기로 정해진다.

범위는 더 줄일 수 있다. Piktiv는 모든 적과 플레이어를 감싸는 경계 상자를 만들고, 그 안쪽 공간만 갱신한다.

공간 쿼리에는 KD 트리를 썼다. 넓은 방 한가운데에 선을 하나 그으면 공간이 둘로 구분된다. 이렇게 만든 트리 구조에는 “여기 점 하나와 반지름이 있으니 그 안에 있는 것을 전부 달라"는 식의 질의를 쉽게 던질 수 있다. 수류탄이 터진 지점을 중심으로 원 안의 적을 전부 찾는 일, 이런 무거운 물리 쿼리를 이 구조로 대체했다.

오케르블롬은 이 선택에 대해서는 유보를 남겼다.

결과적으로 완벽하게 들어맞았는지는 잘 모르겠습니다. KD 트리를 자주 다시 만들어야 하거든요. 적들이 계속 이동하기 때문에 KD 트리도 자주 재구축해야 합니다.

시나리오 6개를 자동으로 돌리는 측정 빌드

기기 대응은 기준 기기를 정하는 것에서 출발했다. 비교적 사양이 낮은 기기로, 여기서 최소 30fps는 나와야 한다고 봤다.

그다음 Piktiv는 자동 성능 측정 시스템을 만들었다. 시나리오를 여러 개 설정할 수 있고, <딥 록 갤럭틱: 서바이버>에서는 총 6개를 돌렸다. 측정 모드 전용으로 빌드하면 기기에서 실행되자마자 바이옴에 진입해 6개 시나리오를 차례로 수행한다.

시나리오는 예를 들면 이런 식이다. 하나는 플레이어가 가만히 선 상태를 기준선으로 잡고 적 1,000마리를 소환해 플레이어 쪽으로 이동시킨다. 다른 하나는 적 500마리를 소환하고 플레이어에게 무기를 전부 들려 준 뒤 사방으로 자동 발사하게 한다. 이렇게 서로 다른 상황을 갖춰 두고, CPU와 GPU와 메모리 등 잴 수 있는 것은 전부 잰다. 모든 바이옴에 대해 돌려서 특정 바이옴에만 성능 문제가 있는지 확인한다.

CPU 성능을 점검할 때 주력 도구는 Unity 프로파일러였다. 특히 초기에 손쉽게 처리할 수 있으면서 효과가 큰 항목을 찾을 때 유용했다고 한다.

Addressables와 메모리 예산

아이패드의 3GB 한도를 맞추는 데는 Addressables가 중요한 역할을 했다. 분리하기 쉬워 보이는 것부터 먼저 떼어냈다. 바이옴이 대표적이다. 플레이어가 동시에 두 개 이상의 바이옴에 있을 수 없으므로, 바이옴별 그래픽 에셋과 설정을 통째로 분리할 수 있다.

대가도 있다. Addressables를 쓰면 그때까지 전부 동기로 돌던 코드에 비동기 동작이 들어온다. 시스템 전체를 비동기로 다시 짜는 일은 게임에 따라 꽤 큰 아키텍처 과제가 될 수 있다고 오케르블롬은 말했다. 이 게임에서는 맞는 선택이었다고 덧붙였다.

추적한 지표와 그 뒤의 개선

Piktiv가 성공 기준으로 삼은 수치는 다음과 같다.

초기에 성능을 크게 깎아먹은 것은 경험치 큐브였다. 벌레를 죽일 때마다 파랗게 빛나는 큐브가 여러 개 튀어나오고, 플레이어가 그것을 주워 레벨업한다. 자동 측정 시나리오 하나에서 10초 동안 약 4,000개가 생성됐고, 처음에는 이 때문에 성능이 크게 떨어졌다. 첫 최적화를 마친 뒤로는 측정에 잡히지 않게 됐다.

적의 이동과 물리를 최적화하자 최저 fps도 크게 올라갔다. 이 작업이 플로 필드로 이어졌다. 동시에 종속성이 10~15단계에 걸친 긴 Burst 작업(job) 체인이 만들어져, 모든 적의 이동을 이 체인이 담당하게 됐다. 이 전부가 일반 물리 시스템 바깥에서 실행된다.

레벨은 절차적으로 생성되므로 바닥과 벽이 전부 개별 오브젝트다. 카메라는 항상 같은 각도의 탑다운이라 화면에 보이는 영역을 쉽게 계산할 수 있다. 그 영역 안의 오브젝트를 모아 직접 묶은 배치(batch) 드로우 명령으로 렌더러에 넘겼다. 드로우 콜을 하나씩 개별로 보내는 CPU 쪽 비용이 꽤 컸기 때문에, 이 변경으로 GPU와 CPU 양쪽이 모두 크게 나아졌다.

PC 게임을 모바일로 옮기려는 개발자에게

에켈룬드의 조언은 은탄환을 찾지 말라는 쪽이었다.

하나짜리 은탄환을 찾는 문제라기보다, 언제나 서로 다른 시스템 사이의 협업 문제입니다.

오케르블롬은 데이터를 옮기는 비용을 지목했다.

매 프레임 수천 개의 엔티티를 처리하게 되면, 여러 컴포넌트 사이로 데이터를 넣고 빼는 비용이 실제로 누적되기 시작합니다. 데이터를 전부 네이티브 컨테이너에 담고, 전 과정에서 같은 네이티브 컨테이너를 쓰도록 관리할 수 있다면 거기서 성능을 많이 벌 수 있습니다.

에켈룬드가 덧붙인 마지막 교훈은 전면 재작성을 말리는 내용이었다. 게임을 다 만들고 나서야 ECS for Unity나 DOTS로 만들었어야 했다는 생각이 들더라도, 게임 전체를 변환해 다시 쓸 필요는 없다는 것이다. Piktiv가 실제로 쓰는 것은 Burst 컴파일러와 네이티브 데이터 타입 상당수뿐이다.

가장 인상에 남은 대목

오케르블롬이 KD 트리를 두고 “완벽하게 들어맞았는지는 잘 모르겠다"고 말한 부분을 여러 번 다시 읽었다. 성공 사례를 소개하는 엔진사 블로그 인터뷰에서 자기가 도입한 구조에 유보를 남기는 답변은 흔하지 않다. 그는 유보의 이유도 함께 밝혔다. KD 트리는 비교적 정적인 공간을 전제로 이득을 보는 자료 구조인데, 이 게임의 적은 매 프레임 이동한다. 재구축 비용이 쿼리에서 아낀 비용을 어디까지 상쇄하는지는 콘텐츠 구성에 따라 달라진다.

플로 필드는 교환 조건이 명확하다. 에이전트 수에 비례하던 비용을 영역 크기에 비례하는 비용으로 바꾼다. 적이 많아질수록 이득이 커진다. KD 트리는 그만큼 깔끔하지 않다. 잘 들어맞은 교체와 애매하게 남은 교체를 한 인터뷰가 함께 담았다. 흔한 이식 후일담에서는 보기 어려운 구성이라 나는 이 글을 오래 들여다봤다.

출처

Unity, “Optimizing Deep Rock Galactic Survivor for mobile”, 2026년 9월 18일. 글쓴이는 Unity 시니어 콘텐츠 마케팅 매니저 Adam Axler, 인터뷰 상대는 Piktiv의 엔지니어링 매니저 Marcus Ekelund(마르쿠스 에켈룬드)와 수석 엔지니어 Fredrik Åkerblom(프레드리크 오케르블롬)이다.

원문: https://unity.com/blog/optimizing-deep-rock-galactic-survivor-for-mobile 한국어 기계 번역판: https://unity.com/kr/blog/optimizing-deep-rock-galactic-survivor-for-mobile

본문 이미지는 모두 원문 아티클에서 인용했다. 저작권은 Funday Games와 Unity에 있다.