언리얼 프로젝트 용량이 커지는 이유와 정리법

이 글과 연결된 과정언리얼 과정 알아보기

블루프린트만으로도 게임을 만들 수 있지만, 회사에서는 성능과 유지보수를 위해 C++과 함께 쓰는 경우가 많습니다. 수업에서는 어떤 기능을 블루프린트로, 어떤 …

용량을 차지하는 주범은 자동 생성 폴더입니다

프로젝트 폴더를 열어 보면 Content 말고도 여러 폴더가 보입니다. 이 가운데 Intermediate, Saved, DerivedDataCache, Binaries는 엔진이 작업 중에 만들어 내는 폴더입니다. 셰이더 컴파일 결과, 빌드 중간 파일, 자동 저장본, 로그가 여기에 쌓입니다.

특히 DerivedDataCache는 셰이더와 텍스처 변환 결과를 저장하는 곳이라 머티리얼을 많이 고칠수록 빠르게 늘어납니다. Saved 폴더 안의 자동 저장본과 크래시 로그도 몇 달 지나면 상당한 양이 됩니다. 이 폴더들은 지워도 다음 실행 때 다시 만들어지지만, 첫 실행에서 셰이더를 다시 컴파일하느라 시간이 오래 걸린다는 점은 알고 지워야 합니다.

반대로 Content와 Config 폴더, 그리고 프로젝트 이름으로 된 uproject 파일은 프로젝트의 본체입니다. 이 셋은 정리 대상이 아니라 백업 대상입니다. 용량 정리를 시작하기 전에 이 구분부터 분명히 해 두면 실수할 일이 크게 줄어듭니다.

실수 1: 마켓 에셋을 통째로 넣고 그대로 두기

학생 프로젝트에서 가장 흔한 원인은 무료 에셋 팩을 통째로 추가하는 습관입니다. 나무 하나가 필요해서 숲 팩 전체를 넣으면, 쓰지 않는 메시와 고해상도 텍스처, 예제 맵까지 함께 들어옵니다. 이런 팩이 몇 개만 쌓여도 Content 폴더가 순식간에 커집니다.

문제는 용량만이 아닙니다. 쓰지 않는 에셋이 많으면 에디터를 열 때마다 불러올 목록이 길어지고, 패키징 시간도 늘어납니다. 팀원에게 프로젝트를 넘길 때 전송 시간이 길어지고, 어떤 에셋이 실제로 쓰이는지 파악하기도 어려워집니다.

고치는 법은 두 가지입니다. 먼저 에셋 팩은 별도의 보관용 프로젝트에 받아 두고, 필요한 에셋만 마이그레이트(Migrate) 기능으로 작업 프로젝트에 옮깁니다. 이렇게 하면 그 에셋이 참조하는 머티리얼과 텍스처만 함께 따라옵니다. 이미 통째로 넣었다면, 콘텐츠 브라우저에서 어떤 파일이 실제 레벨에 쓰이는지 참조를 확인한 뒤 쓰지 않는 묶음을 정리합니다.

실수 2: 탐색기에서 에셋 파일을 직접 지우거나 옮기기

용량을 줄이려고 윈도우 탐색기에서 uasset 파일을 바로 지우는 경우가 있습니다. 언리얼은 에셋끼리 서로를 참조하기 때문에, 엔진 밖에서 지우면 그 파일을 쓰던 머티리얼이나 블루프린트가 깨진 참조를 갖게 됩니다. 다음에 열었을 때 경고가 쏟아지거나 레벨이 제대로 열리지 않는 원인이 됩니다.

삭제와 이동은 반드시 에디터의 콘텐츠 브라우저에서 합니다. 에디터에서 지우면 어떤 에셋이 참조하고 있는지 먼저 알려 주고, 대체할 에셋을 고르게 해 줍니다. 폴더를 옮긴 뒤 남는 리디렉터(이전 위치를 가리키는 작은 파일)는 폴더 우클릭 메뉴의 리디렉터 정리 기능으로 정리하면 됩니다.

실수 3: 텍스처 해상도와 버전 관리를 신경 쓰지 않기

4K 텍스처를 작은 소품에도 그대로 쓰면 디스크 용량과 메모리가 함께 늘어납니다. 화면에서 손바닥만 하게 보이는 물체라면 훨씬 낮은 해상도로도 충분한 경우가 많습니다. 텍스처 에디터에서 최대 크기를 제한하거나, 원본을 처음부터 알맞은 크기로 만들어 가져오는 습관을 들이면 좋습니다.

팀 프로젝트에서는 버전 관리 설정도 용량에 영향을 줍니다. 깃(Git)으로 관리하면서 캐시 폴더까지 올리면 저장소가 금세 무거워집니다. 무시 목록에 자동 생성 폴더를 넣고, 큰 바이너리 파일은 대용량 파일 관리 방식이나 퍼포스(Perforce) 같은 도구로 다루는 것이 일반적입니다.

한 번 커밋된 큰 파일은 나중에 지워도 저장소 기록에 남는다는 점도 기억해야 합니다. 그래서 무시 목록은 프로젝트를 처음 올리기 전에 정해 두는 것이 좋습니다. 팀원마다 다른 설정으로 올리지 않도록 규칙을 문서로 공유해 두면 더 안전합니다.

정리 전에 확인할 체크리스트

1. 에디터를 완전히 닫고 프로젝트 폴더 전체를 다른 드라이브에 백업했는가
2. Content 폴더의 크기와 나머지 폴더의 크기를 따로 확인했는가
3. Intermediate, Saved, DerivedDataCache 중 무엇이 가장 큰지 확인했는가
4. Saved 폴더 안에 따로 보관해야 할 스크린샷이나 설정 파일이 없는가
5. 콘텐츠 브라우저의 사이즈 맵(Size Map)으로 덩치 큰 에셋을 찾아봤는가
6. 쓰지 않는 에셋을 에디터 안에서 참조 확인 후 지웠는가
7. 정리 후 프로젝트를 다시 열어 주요 레벨이 정상으로 열리는지 확인했는가

Binaries 폴더는 C++ 프로젝트라면 다시 빌드해야 생기므로, 빌드 환경이 갖춰져 있을 때만 지웁니다. 블루프린트 전용 프로젝트라면 부담이 적지만, 처음에는 캐시 폴더만 지워 보고 결과를 확인하는 편이 안전합니다.

처음부터 가볍게 유지하는 작업 습관

가장 좋은 방법은 커지기 전에 막는 것입니다. 프로젝트를 시작할 때 폴더 구조와 이름 규칙을 정하고, 테스트용 에셋은 한 폴더에 모아 두면 나중에 한 번에 정리하기 쉽습니다. 한 달에 한 번 정도 사이즈 맵을 열어 보는 것만으로도 이상하게 큰 파일을 일찍 찾을 수 있습니다.

포트폴리오를 제출할 때도 이 습관이 드러납니다. 정리된 폴더 구조와 적절한 용량은 협업을 아는 사람이라는 인상을 줍니다. 지금 프로젝트 구조가 너무 엉켜서 어디서부터 손대야 할지 모르겠다면, SBS아카데미게임학원 언리얼엔진 과정 상담에서 현재 작업물을 기준으로 정리 방향을 함께 잡을 수 있습니다.

자주 묻는 질문

가까운 캠퍼스에서 언리얼 알아보기

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

함께 읽으면 좋은 글