Unreal 프로젝트의 Git 관리와 대용량 자산

관리 대상과 재생성 파일을 나누기

Unreal 프로젝트를 Git에 넣는 목적은 코드뿐 아니라 작업한 Blueprint, 맵, 설정과 자산의 관계를 함께 복구하는 것입니다. 캐시나 빌드 중간 산출물을 모두 저장하면 변경 내역이 시끄러워지고 저장소가 불필요하게 커집니다. 프로젝트의 Content, Config, Source와 uproject 등 필요한 입력은 관리하고 DerivedDataCache, Intermediate 같은 재생성 영역은 구분합니다.

Binaries를 무조건 지워도 된다고 일반화하지 않습니다. 소스가 없는 외부 플러그인의 바이너리는 재생성할 수 없을 수 있습니다. 무시 규칙을 추가하기 전에 프로젝트와 플러그인의 배포 형태를 확인합니다. 원본 FBX, 제작용 PSD나 Blender 파일을 어디에 보관할지도 결정해야 합니다. 게임 실행에 필요 없다는 이유와 다시 만들 수 있다는 이유는 다릅니다.

첫 커밋 전에 바이너리 정책 세우기

uasset과 umap은 일반 텍스트 코드처럼 줄 단위 병합하기 어렵고 크기도 클 수 있습니다. Git LFS를 선택했다면 해당 패턴을 추적하도록 정한 뒤 생성된 .gitattributes도 함께 커밋합니다. LFS는 저장소에 작은 포인터를 두고 실제 콘텐츠를 별도로 관리하는 방식이며, 모든 용량 문제가 자동으로 사라지는 것은 아닙니다. 원격 서비스의 저장·전송 한도와 백업 방식도 함께 확인합니다.

이미 일반 Git 이력에 큰 파일이 여러 번 들어갔다면 뒤늦게 추적 패턴을 추가해도 과거 이력이 자동으로 줄지 않습니다. 이력 재작성은 동료의 복제본과 기존 참조에 영향을 주므로 별도 계획이 필요합니다. 당장 폴더가 커졌다고 커밋 수를 줄이거나 옛 이력을 무작정 삭제하는 것은 복구 가능성을 잃는 선택입니다.

복구 지점을 안전하게 사용하기

커밋 전에는 상태와 스테이징된 파일 목록을 확인해 비밀키, 로컬 로그, 임시 출력이 섞이지 않도록 합니다. 옛 상태를 조사할 때는 현재 변경을 먼저 보존하고, 그 지점부터 계속 개발하려면 새 브랜치를 만듭니다. Git은 저장소 자체가 있는 디스크 고장까지 막는 백업은 아니므로 별도 사본이나 적절한 원격도 필요합니다.

1. .gitignore를 검토한 뒤 관리할 파일 목록을 확인합니다.
2. LFS를 쓰는 경우 첫 자산 커밋 전에 패턴과 .gitattributes를 준비합니다.
3. 작은 기능 단위로 커밋하고 메시지에 변경 목적을 남깁니다.
4. 복구 실험은 새 브랜치에서 진행하고 공유 이력 삭제는 별도로 판단합니다.

# 새 저장소에서 LFS를 사용하기로 결정한 경우의 예시
# 실행 전 Git LFS 설치와 프로젝트 무시 규칙을 확인한다.
git lfs install
git lfs track "*.uasset" "*.umap"
git add .gitattributes
git status --short

# 과거 커밋에서 새 작업을 시작하는 예시
# <commit>을 확인한 커밋 해시로 교체한다.
git switch -c investigate-animation <commit>