유니티 프로젝트가 느려지는 흔한 원인

이 글과 연결된 과정유니티 과정 알아보기

유니티는 혼자서도 게임 하나를 끝까지 만들 수 있게 해 주는 엔진입니다. 수업은 C 언어로 변수와 조건문, 반복문 같은 프로그래밍 기본기를 먼저 다지고, C#…

먼저 프로파일러로 어디가 느린지 확인하기

느려졌다고 느끼면 의심 가는 코드부터 고치고 싶어지지만, 실제 원인이 다른 곳에 있는 경우가 많습니다. 유니티에는 프레임마다 어떤 작업에 시간이 쓰였는지 보여 주는 프로파일러가 들어 있습니다. 이것으로 CPU 쪽 스크립트가 문제인지, 그리기가 문제인지, 메모리 정리가 문제인지 먼저 구분하세요.

확인할 때는 에디터에서만 보지 말고 가능하면 실제 기기용 빌드에 프로파일러를 연결해 측정합니다. 에디터는 그 자체로 추가 작업이 많아서 실제 기기와 결과가 다를 수 있습니다. 화면이 끊기는 순간 그래프가 튀는 지점을 골라 그 프레임에서 시간을 많이 쓴 항목을 위에서부터 살펴보면 원인의 방향이 잡힙니다. 고친 뒤에는 같은 조건에서 다시 측정해 실제로 나아졌는지 숫자로 확인하세요.

매 프레임 찾고, 매 프레임 새로 만드는 코드

가장 흔한 원인은 Update 함수 안의 코드입니다. Update는 매 프레임 실행되기 때문에, 그 안에서 이름으로 오브젝트를 찾거나 컴포넌트를 가져오는 코드를 쓰면 같은 탐색을 계속 반복하게 됩니다. 오브젝트가 많아질수록 이 비용도 커집니다. 처음 만들 때는 오브젝트가 적어 문제가 보이지 않다가, 콘텐츠가 늘어난 뒤에 갑자기 느려지는 이유가 여기에 있습니다.

필요한 오브젝트와 컴포넌트는 시작할 때 한 번 찾아 변수에 저장해 두고 재사용하세요. 매 프레임 확인할 필요가 없는 일, 예를 들어 주변 적 탐색이나 UI 숫자 갱신은 일정 간격으로만 하거나 값이 바뀔 때만 실행되게 바꿉니다. 이벤트 방식으로 '바뀌었을 때 알려 주는' 구조를 쓰면 불필요한 확인이 크게 줄어듭니다.

개발 중에 넣어 둔 로그 출력도 빼먹기 쉬운 원인입니다. 매 프레임 로그를 찍으면 생각보다 큰 비용이 들고, 빌드에서도 남아 있을 수 있습니다. 확인이 끝난 로그는 지우거나 개발 빌드에서만 나오게 정리하세요.

가비지와 잦은 생성·삭제가 만드는 주기적 끊김

유니티의 C# 코드는 쓰지 않게 된 메모리를 가비지 컬렉터가 모아서 정리합니다. 이 정리가 일어나는 순간 게임이 잠깐 멈출 수 있는데, 매 프레임 새 메모리를 많이 할당하면 정리가 자주 일어나 화면이 주기적으로 끊깁니다. 프로파일러에서 일정한 간격으로 튀는 그래프가 보인다면 이 경우를 의심해 볼 만합니다.

• 매 프레임 문자열을 이어 붙여 UI 글자를 만드는 코드
• 매 프레임 새 리스트나 배열을 만드는 코드
• 총알, 이펙트, 적을 계속 생성하고 삭제하는 구조
• 자주 불리는 곳에서 편하지만 할당이 많은 문법을 쓰는 경우

자주 나왔다 사라지는 오브젝트는 오브젝트 풀링으로 바꾸는 것이 대표적인 해결책입니다. 미리 몇 개를 만들어 두고, 필요할 때 켜서 쓰고, 다 쓰면 끄고 다시 보관하는 방식입니다. 리스트도 한 번 만들어 두고 내용만 비워서 재사용하면 할당이 줄어듭니다.

그리기 비용: 드로우 콜, 그림자, 텍스처

스크립트가 가벼워도 그리는 작업이 무거우면 느려집니다. 서로 다른 머티리얼을 쓰는 오브젝트가 많으면 그래픽 장치에 보내는 그리기 명령, 즉 드로우 콜이 늘어납니다. 같은 머티리얼을 공유하고, 텍스처를 한 장에 모으고, 움직이지 않는 배경 오브젝트는 정적으로 표시해 묶어 그리게 하면 이 수를 줄일 수 있습니다.

실시간 그림자와 조명도 비용이 큽니다. 모든 조명이 그림자를 만들 필요는 없으니 중요한 조명만 그림자를 켜고, 움직이지 않는 조명은 미리 구워 두는 방식을 검토하세요. 텍스처는 화면에서 보이는 크기에 비해 너무 큰 해상도를 쓰지 않았는지, 플랫폼에 맞는 압축 설정을 했는지 확인합니다. 모바일에서는 텍스처 메모리가 부족해져 느려지거나 앱이 종료되는 경우도 있습니다.

UI와 물리에서 숨어 있는 비용

UGUI를 쓸 때 하나의 캔버스 안에서 요소 하나가 바뀌면 그 캔버스 전체를 다시 계산하는 경우가 있습니다. 매 프레임 바뀌는 타이머나 체력바가 큰 메뉴 화면과 같은 캔버스에 들어 있으면, 화면 전체가 계속 다시 계산됩니다. 자주 바뀌는 요소와 거의 바뀌지 않는 요소를 다른 캔버스로 나누면 부담이 줄어듭니다.

물리도 확인합니다. 복잡한 모양 그대로 충돌을 계산하는 메시 콜라이더를 많이 쓰면 계산이 무거워집니다. 가능하면 상자, 구, 캡슐 같은 단순한 충돌체로 대신하세요. 서로 부딪힐 필요가 없는 오브젝트끼리는 레이어 설정으로 충돌 검사를 끄면 불필요한 계산을 줄일 수 있습니다.

에디터 자체가 느릴 때와 정리 습관

게임이 아니라 에디터가 느리다면 원인이 다릅니다. 스크립트를 고칠 때마다 컴파일이 오래 걸린다면 스크립트를 어셈블리 단위로 나누는 방법을, 플레이 버튼을 누를 때마다 오래 기다린다면 플레이 모드 진입 설정을 살펴볼 수 있습니다. 쓰지 않는 에셋과 패키지가 많이 쌓여 있어도 가져오기와 검색이 느려지니 주기적으로 정리하세요.

성능 문제는 프로젝트가 커진 뒤에 한꺼번에 고치려면 어렵습니다. 기능을 하나 추가할 때마다 프로파일러를 잠깐 열어 보는 습관을 들이면 원인을 빨리 찾을 수 있습니다. 내 프로젝트에서 어디부터 손봐야 할지 판단이 서지 않는다면, SBS아카데미게임학원 유니티 과정 상담에서 프로젝트 구조와 코드를 함께 보며 최적화 순서를 정리해 보세요.

자주 묻는 질문

가까운 캠퍼스에서 유니티 알아보기

사는 곳과 가까운 캠퍼스를 고르면 수업 내용, 오시는 길, 상담 신청을 한 번에 볼 수 있습니다.

함께 읽으면 좋은 글