게임을 만들다 보면 처음에는 잘 돌아가던 프로젝트가 오브젝트가 늘어날수록 끊기기 시작합니다. 특히 모바일 기기에서는 같은 게임도 훨씬 무겁게 느껴집니다. 최적화는 감으로 하는 일이 아니라 원인을 측정하고 하나씩 줄이는 일입니다. 이 글은 유니티에서 최적화를 시작할 때 알아야 할 기본기를 다룹니다.

먼저 측정하기: 프로파일러

최적화의 첫 원칙은 추측하지 말고 측정하라는 것입니다. 유니티에는 프로파일러(Profiler)라는 도구가 있어 한 프레임 안에서 CPU, GPU, 메모리가 각각 얼마나 쓰이는지 그래프로 보여 줍니다. 렌더링이 문제인지, 스크립트가 문제인지, 물리 계산이 문제인지를 여기서 먼저 구분합니다.

에디터에서 측정한 결과는 실제 기기와 다를 수 있습니다. 모바일 게임이라면 개발용 빌드를 기기에 설치하고 프로파일러를 연결해 실제 환경에서 확인하는 것이 정확합니다.

렌더링 최적화: 드로우콜 줄이기

드로우콜(Draw Call)은 CPU가 GPU에게 무언가를 그리라고 보내는 명령입니다. 명령 수가 많을수록 CPU 부담이 커집니다. 화면에 보이는 오브젝트와 재질 종류가 많을 때 드로우콜이 늘어납니다.

• 움직이지 않는 배경 오브젝트는 Static으로 설정해 묶어 그리기(배칭) 대상이 되게 합니다.
• 같은 재질을 여러 오브젝트가 함께 쓰도록 텍스처를 한 장에 모읍니다. 이를 텍스처 아틀라스라고 합니다.
• 같은 모델이 많이 반복되면 GPU 인스턴싱을 켭니다.
• 멀리 있는 물체는 LOD(Level of Detail) 그룹으로 단순한 모델로 바꿔 그립니다.
• 벽 뒤에 가려져 안 보이는 물체는 오클루전 컬링으로 그리지 않게 합니다.

Frame Debugger를 열면 한 프레임이 어떤 순서로 그려지는지 단계별로 볼 수 있어 불필요한 그리기 작업을 찾기 쉽습니다.

스크립트 최적화: 매 프레임 하는 일 줄이기

Update 함수 안의 코드는 1초에도 수십 번 실행됩니다. 여기서 GetComponent나 오브젝트 검색(Find)을 반복하면 작은 비용이 쌓여 큰 부담이 됩니다. 필요한 참조는 시작할 때 한 번 가져와 저장해 둡니다.

가비지 컬렉션(GC)도 주의해야 합니다. 가비지 컬렉션은 쓰지 않는 메모리를 자동으로 정리하는 기능인데, 정리하는 순간 게임이 잠깐 멈칫할 수 있습니다. 매 프레임 문자열을 합치거나 새 리스트를 만드는 코드를 줄이고, 자주 생겼다 사라지는 오브젝트는 오브젝트 풀로 재사용하면 이런 멈춤을 줄일 수 있습니다.

메모리와 리소스 관리

텍스처는 메모리를 가장 많이 차지하는 경우가 많습니다. 모바일에서 작게 보이는 아이콘에 큰 이미지를 그대로 쓰는 일이 흔하니 임포트 설정의 최대 크기부터 점검해 보세요.

최적화는 언제 하나

개발 초반부터 모든 코드를 최적화하려고 하면 진도가 나가지 않습니다. 기능을 먼저 완성하고, 목표 기기에서 정기적으로 측정하다가 기준보다 느려지는 지점에서 원인을 찾아 고치는 방식이 현실적입니다. 다만 오브젝트 풀이나 참조 저장처럼 처음부터 지켜도 부담이 없는 습관은 미리 들여 두는 것이 좋습니다.

목표를 정해 두면 판단이 쉬워집니다. 예를 들어 우리 게임은 어떤 기기에서 어느 정도 프레임을 유지한다는 기준을 팀이 함께 정하고, 그 기준 아래로 떨어지는 장면만 집중해서 고치는 식입니다. 기준이 없으면 끝없이 최적화만 하다가 일정이 밀리기 쉽습니다.

관련 수업 안내

SBS아카데미게임학원 유니티3D(Unity) 과정은 오브젝트 풀, 렌더링, 셰이더 등 엔진 고급 내용을 다루고 포트폴리오 제작 단계에서 실제 프로젝트에 적용해 볼 수 있도록 구성되어 있습니다.

자주 묻는 질문