대부분의 게임 개발자들은 개발 완료 이후 최적화 문제를 한 번씩은 체험한다. 실제 유저의 게임 환경이 다양하기도 하고, 프로젝트 개발하는 과정에서 놓친 부분들이 발목을 잡는 경우가 있기 때문이다. 이러한 문제들이 실제 출시 단계에서 버벅대거나 심하면 꺼지는 등 치명적인 오류로 발전하면서 유저들의 악평으로 이어지기도 한다.
개발자들이 항상 대면하게 되는 이 문제에 대해 유니티 엔진은 그간 프로파일러를 비롯해 다양한 툴을 제공해왔다. 그리고 최근에는 정적 분석 도구 '오디터'로 애셋과 스크립트, 코드에 대한 인사이트 및 분석을 돕고 있다. 유니티 코리아의 오지현 시니어 애드버킷은 경기게임커넥트 2025 인디 세미나에 연사로 초청, 유니티를 사용하는 인디 개발자들이 프로젝트를 더욱 효과적으로 관리하는 '오디터' 활용법을 공유했다.
오지현 애드버킷은 최근 모바일 플랫폼이 중요해진 만큼, 최적화 이슈는 더욱 더 중요해졌다고 강조했다. 모바일에서는 메모리 사용량이 많아지면 OS 차원에서 앱을 종료시키는 일이 잦기 때문이다. PC에서는 PC에서는 강제 종료까지 이어지는 경우가 적지만, 메모리를 많이 사용하면 로딩 시간이 길어지면서 전반적인 UX가 떨어지게 된다.
이러한 문제를 해결하기 위해 유니티는 유니티 프로파일러와 메모리 프로파일러를 선보였다. 유니티 프로파일러는 런타임 이슈를 포착해 잡아낼 수 있으며, 메모리 프로파일러는 텍스처, 오디오 등 등 여러 리소스에서 메모리를 어느 정도 점유하고 있는지 자세히 파악할 수 있도록 돕는 툴이다. 특히 메모리 프로파일러는 프로젝트 내 특정 씬에서만 문제가 발생하거나, 특정 기기에서만 문제가 발생하는 상황에서도 기기별, 씬별 메모리 사용량 데이터를 비교 분석할 수 있어 더욱 세밀한 최적화 작업에 유용하게 쓸 수 있다.
이와 함께 오지현 애드버킷은 유니티 엔진 6.1부터 출시된 '유니티 프로젝트 오디터'를 소개했다. 프로젝트 오디터는 프로젝트 시작 전에 미리 리소스를 잘못된 방식으로 사용하거나 오래된 API를 사용하는 등 여러 문제를 체크할 수 있다. 또한 잠재적으로 문제 있는 코드를 진단할 수 있도록 돕는다. 이외에도 셰이더, 빌드 등 각종 탭에 들어가서 자신이 파악하고 싶은 최적화 분야를 좀 더 자세히 확인할 수 있다. '프로젝트 오디터'는 에디터에 기본 탑재되어있지 않으나, 유니티 패키지 매니저에서 간단히 다운받아 설치할 수 있다.
프로젝트 오디터는 그래프 및 수치로 최적화 관련 정보를 제공하는 것은 물론, 원인 및 해결 방안도 제공한다. 예를 들어 통상 메시 관련해서 최적화는 메시 컴프레션을 많이 찾아보지만, 실제로는 메시를 압축해도 큰 의미가 없다. 빌드 패킹할 때 메시 데이터를 압축하지만 로딩할 때는 압축을 풀기 때문에 결과적으로 동일한 메모리를 차지하기 때문이다.
그보다는 메모리 문제가 자주 발견하는 사례로는 '메시 리드/라이트 인에이블 옵션'이 꼽았다. CPU와 GPU 모두 메모리가 있는데, 메시 렌더링은 GPU 메모리까지 할당을 하기 때문이었다. 특히 모바일 게임의 경우 이 옵션을 체크할 필요가 있다고 강조했다. 모바일은 CPU와 GPU가 물리적으로 나뉜 게 아니라 논리적으로 나뉜 만큼, 접근 영역을 나누었다고 해도 비슷한 데이터가 중복 전달이 되어 메모리가 비효율적으로 처리하기 때문이다. 최근에는 이 옵션이 꺼져있으나, 종종 개발 연식이 조금 된 프로젝트는 켜져있는 경우가 있어서 이렇게 놓치기 쉬운 부분을 프로젝트 오디터를 통해 체크할 수 있다.
또한 모바일 게임에서 메모리 최적화의 핵심으로는 '텍스처 관리'가 손꼽혔다. 이를 위해서는 메모리 프로파일러 점검 외에도 텍스처 최적화도 필수다. 이와 관련해 오지현 애드버킷은 텍스처 해상도는 퀄리티가 보장되는 선에서 가능한 작게 설정해야 한다고 조언했다.
반면 텍스처 압축 포맷은 어차피 유니티에서 GPU가 쓰는 포맷으로 변환하기 때문에 임포트 세팅이 더 중요하다고 강조했다. 과거에는 ETC나 PVRTC를 많이 썼으나, 최근에는 대부분 기기에서 호환되는 ASTC를 권장했다. 또한 2D 및 UI에서 거의 필요 없는 미니맵 옵션을 비활성화하면 메모리 효율이 33% 증가하는 만큼, 모바일 게임 최적화를 위해서는 텍스처 부분을 면밀히 볼 것을 권했다.
또한 프로젝트 오디터는 코드 내 배열 할당 문제도 포착한다. 매 프레임마다 배열을 할당하는 코드는 메모리 경고를 유발하고, 메모리를 계속 잡아먹게 된다. 이때는 업데이트 대신 스타트나 어웨이크 함수에서 할당하는 방식으로 수정해 등급을 낮출 수 있다.
이보다 더 중요한 코드 이슈로는 박싱 얼로케이션이 꼽혔다. C#에서는 스택에 저장되는 값 형식을 힙에 저장되는 참조 형식으로 변환할 때 박싱이 발생한다. 이러한 과정이 많아지면 박싱할 때 쓰인 메모리가 힙에 할당되고, 한 번 쓰이고는 사용이 되지 않기 때문에 가비지 컬렉터에 의해 처리된다. 즉 박스 개체가 쌓일 수록 가비지 컬렉터에 부하가 걸리고, 이는 자연스럽게 연산에도 지연이 생겨서 프레임이 튀는 주 원인이 된다.
모바일 프로젝트의 경우, C# 스크립트는 IL2CPP를 통해서 C++로 변환된다. 그래서 일부에서는 C#에만 있는 가비지 콜렉터 문제가 모바일에서 일어나지 않을 거라고 생각하지만, C#에서 발생한 가비지 콜렉터 문제는 C++에서도 동일한 유형의 문제로 변환되어서 발생한다. 따라서 오지현 애드버킷은 스크립트 작성 시에 박싱과 가비지 콜렉터 문제도 고려해야 한다고 강조했다.
아울러 문자열에서도 종종 가비지 콜렉터 문제가 발생하는데, 그 주요 원인에 대해서도 소개했다. 통상 채팅창이나 메시지의 문자열을 +연산으로 계속 합치면서 늘리는 경우가 있는데, 그렇게 되면 매번 새로운 문자열이 힙에 생성되고 이전 문자열은 가비지로 처리된다. 즉 가비지 콜렉터가 부하가 걸리는 사태가 발생하기 때문에 스트링빌더 등 별도의 API를 사용하는 것이 훨씬 더 좋다고 조언했다.
또한 개발에서 디버깅을 위해 흔히 쓰는 Debug.Log도 실제로 실행되는 코드인 만큼, 개발 빌드에 포함되면 메모리 누수가 발생할 수 있다. 그렇기에 배포 시에는 삭제하거나 혹은 실행되지 않도록 if문 등을 활용해 처리하는 방안을 권했다. 오디오 데이터로 인한 메모리 이슈의 경우, 압축을 풀어 저장하는 '디컴프레스 온 로드' 옵션은 메모리를 많이 사용하기 때문에 주의할 필요가 있다고 설명했다.
오지현 애드버킷은 "유니티 엔진에서는 매년 최적화 관련 온라인 가이드를 공개하는 만큼, 이를 참고해서 프로젝트를 원활히 구동할 수 있기를 바란다"고 전했다.
Ruudi@inven.co.kr
페이지 구독하기
다른 기사 보기
기사 제보하기
