에셋의 버전 관리

프로젝트가 진행되면 에셋은 계속 수정되고 교체됩니다.

문제는 변경 자체가 아니라 변경 이력이 관리되지 않을 때 발생합니다.

잘못된 수정 되돌리기, 충돌 해결, 누가 언제 무엇을 바꿨는지 추적하는 작업은 특히 팀 개발에서 필수입니다.

이번 절에서는 언리얼 프로젝트에서 에셋 중심 버전 관리를 안정적으로 운영하는 방법을 정리합니다.

버전 관리 시스템의 필요성

버전 관리 시스템은 소프트웨어 개발 프로젝트에서 코드나 파일의 변경 사항을 추적하고 관리하는 도구입니다.

언리얼 엔진 프로젝트 역시 방대한 양의 에셋 파일(주로 .uasset 파일)을 다루기 때문에 VCS의 도입은 선택이 아닌 필수입니다.

VCS를 사용하면 다음과 같은 이점을 얻을 수 있습니다.

변경 이력 추적: 추적 대상으로 등록하고 커밋·제출한 변경 이력으로 되돌릴 수 있습니다.
협업 용이성: 변경을 나누어 공유하고 충돌을 확인할 수 있습니다. 바이너리 에셋은 텍스트처럼 자동 병합되지 않으므로 편집 담당과 잠금 정책이 필요합니다.
안정성: 예기치 않은 오류나 데이터 손실 발생 시 이전의 안정적인 상태로 쉽게 복구할 수 있습니다.
백업 및 복원: 원격 저장소에 제출한 이력을 복원할 수 있습니다. 미제출 작업과 외부 원본, 저장소 자체의 백업도 별도로 관리합니다.

언리얼 엔진 프로젝트에서 주로 사용되는 VCS는 Perforce (Helix Core)와 Git이 있습니다.

Perforce: 대규모 팀에 최적화된 선택

Perforce (Helix Core)는 대규모 프로젝트와 팀 환경에서 가장 널리 사용되는 버전 관리 시스템 중 하나입니다.

언리얼 엔진과 매우 강력하게 통합되어 있으며, 특히 바이너리 파일(컴파일된 에셋 파일처럼 사람이 읽기 어려운 형태의 파일) 관리에 특화되어 있습니다.

Perforce의 특징

바이너리 파일에 최적화: .uasset과 같은 바이너리 파일의 변경 사항을 효율적으로 관리하고 저장합니다. 대규모 바이너리 저장·동기화와 팀 잠금 정책을 함께 운영할 수 있습니다.
파일 잠금(File Locking): 하나의 파일을 한 번에 한 명만 수정할 수 있도록 잠그는 기능을 제공하여, 동시 편집 충돌을 줄입니다. .uasset·.umap 등에 배타적 체크아웃(+l)을 적용한 typemap과 팀 정책이 전제입니다. 이는 .uasset 파일처럼 병합이 어려운 바이너리 파일에 특히 유용합니다.
중앙 집중식: 제출한 파일의 이력을 중앙 서버에서 관리합니다.
언리얼 엔진 통합: 언리얼 에디터 내에서 Perforce 기능을 직접 사용할 수 있도록 강력하게 통합되어 있습니다.

Perforce 사용 워크플로우 (간략)

에셋 버전 관리는 새 파일을 덮어쓰기 전에 변경 이유와 되돌릴 기준을 남기는 습관에서 시작됩니다.

서버 설정: Perforce 서버를 구축하고 프로젝트 레포지토리(저장소)를 생성합니다. (별도의 서버 구축 및 관리 지식 필요)

클라이언트 설정: 각 개발자는 Perforce 클라이언트(P4V)를 설치하고 서버에 연결합니다.

언리얼 에디터 연동: 언리얼 에디터에서 소스 컨트롤(Source Control)을 Perforce로 설정하고 로그인합니다. (툴바의 Source Control 또는 버전에 따른 Revision Control 메뉴)

최신 버전 동기화와 체크아웃: 작업 전 최신 리비전을 동기화하고 편집할 파일을 체크아웃합니다. 배타적 잠금이 적용되는 파일 유형인지 확인합니다.

파일 수정: 언리얼 에디터에서 에셋을 수정합니다.

제출(Submit): 참조 에셋·레벨을 함께 저장하고 변경 목록을 확인합니다. 필요한 동기화와 충돌 해결을 마친 뒤 서버에 제출합니다.

이때 변경된 파일 목록과 함께 변경 내용을 설명하는 메시지를 남깁니다.

Git: 분산형 버전 관리의 표준

Git은 전 세계적으로 가장 널리 사용되는 분산형 버전 관리 시스템입니다.

소규모 팀이나 개인 프로젝트에서 특히 인기가 많으며, GitHub, GitLab, Bitbucket 등 다양한 호스팅 서비스를 통해 쉽게 사용할 수 있습니다.

Git의 특징

분산형: 개발자는 로컬 저장소에서 이력을 기록합니다. 네트워크 없이도 로컬 커밋은 가능하지만, 아직 내려받지 않은 Git LFS 객체나 원격 변경은 연결이 필요합니다.
코드 파일에 최적화: 텍스트 기반의 코드 파일 변경 사항 관리에 매우 강력합니다.
브랜치(Branch) 시스템: 특정 기능을 개발하거나 버그를 수정할 때 메인 라인(Master/Main 브랜치)에 영향을 주지 않고 별도의 변경 이력을 만들 수 있습니다.
LFS (Large File Storage): 대용량 바이너리는 Git LFS 사용을 검토합니다. 파일 내용은 별도 객체로 저장하지만 자동 병합 기능은 아니며, 잠금은 서버 지원과 팀의 사용 규칙이 필요합니다.

Git 사용 워크플로우 (간략)

Git 설치 및 초기화: Git을 설치하고 프로젝트 폴더에서 Git 레포지토리를 초기화합니다.

Git LFS 설정: 대용량 바이너리 파일 관리를 위해 Git LFS를 설정하고 .uasset과 같은 확장자를 추적하도록 합니다. (예: git lfs track "*.uasset"). .umap 등 팀에서 사용하는 바이너리 유형도 포함하고 생성된 .gitattributes를 커밋합니다.

편집 도구 연결: 에디터의 Git 제공자·플러그인 지원을 확인해 연결하거나 외부 Git 클라이언트를 사용합니다. 작업 전 원격 변경을 가져와 로컬 변경과 통합하고 잠금 정책을 확인합니다.

파일 수정: 언리얼 에디터에서 에셋을 수정합니다.

변경 사항 커밋(Commit): 수정이 완료되면 변경된 파일을 스테이징(Staging)하고 커밋하여 로컬 레포지토리에 기록합니다.

푸시(Push): 로컬에 커밋된 변경 사항을 원격(GitHub 등) 레포지토리에 푸시하여 공유합니다.

동기화 반복: 다른 팀원의 변경을 가져와 통합합니다. 로컬 미커밋 변경을 먼저 확인하고, 바이너리 충돌은 어느 에셋 버전을 채택할지 담당자와 결정합니다.

개인 프로젝트를 위한 간이 버전 관리

소규모 개인 프로젝트의 경우, 복잡한 VCS를 구축하는 것이 부담스러울 수 있습니다.

이때는 다음과 같은 간이 방법을 고려해 볼 수 있습니다.

주기적인 프로젝트 폴더 백업: 중요한 변경 사항이 있을 때마다 프로젝트 폴더 전체를 압축하여 날짜나 버전명으로 백업합니다. (예: MyProject_20250624_v1.0.zip)
언리얼 엔진 자동 저장 기능 활용: 에디터 환경설정 > 일반 > 자동 저장에서 자동 저장 간격과 대상 설정을 확인합니다. 자동 저장은 전체 프로젝트 이력이나 별도 장치의 백업을 대신하지 않습니다.
Level Save As (다른 이름으로 레벨 저장): 중요한 레벨을 수정하기 전에 파일(File) > 다른 이름으로 레벨 저장(Save Current Level As)을 통해 별도의 버전으로 저장해두는 습관을 들입니다. (예: MyLevel_v1.umap, MyLevel_v2_Test.umap). 두 레벨이 같은 재질·블루프린트를 참조하면 그 에셋 변경은 공유되므로 전체 스냅샷은 아닙니다.

물론 이러한 방법들은 전문적인 VCS에 비할 바는 아니지만, 간단한 개인 프로젝트에서는 유용하게 사용할 수 있습니다.

그러나 프로젝트의 규모가 커지거나 협업을 시작한다면, 반드시 Perforce나 Git과 같은 전문 VCS를 도입할 것을 강력히 권장합니다.

버전 관리 방식은 팀 규모보다 먼저 병합 가능한 파일인지, 잠금이 필요한 파일인지를 기준으로 판단하면 선택이 쉬워집니다.

대상	관리할 경계
코드	텍스트 diff와 테스트로 변경을 검토합니다.
에셋	바이너리 충돌을 피하도록 담당·잠금을 정하고 관련 레벨까지 함께 확인합니다.
백업	원본 파일·엔진 버전·변경 설명을 남기고 실제 복원 가능 여부를 확인합니다.

버전 관리는 안정적인 개발 환경을 유지하고 효율적인 협업을 가능하게 하는 핵심적인 요소입니다.

처음에는 어렵게 느껴질 수 있지만, 이 절에서 다룬 개념들을 바탕으로 여러분의 프로젝트에 적합한 버전 관리 시스템을 선택하고 꾸준히 사용하는 습관을 들이는 것이 중요합니다.

이는 장기적으로 여러분의 소중한 작업물을 보호하고 프로젝트의 성공에 기여할 것입니다.

이 페이지의 목차