에셋의 버전 관리

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

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

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

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

1
작업 전 최신화
레벨과 공통 에셋을 수정하기 전에 최신 상태를 받고 Redirector를 정리합니다. sync
2
파일 잠금
동시 편집이 위험한 .umap, 공통 머티리얼, 데이터 에셋은 체크아웃과 락을 겁니다. lock
3
체인지리스트 구성
코드, 에셋, 설정 파일을 기능 단위로 묶고 임시 실험 파일을 분리합니다. CL
4
검증 빌드
수정한 레벨 로딩, 참조, 패키징 로그를 확인한 뒤 리뷰로 넘깁니다. verify
5
병합 후 정리
충돌이나 경로 이동 뒤 Fix Up Redirectors와 Reference Viewer로 깨진 참조를 확인합니다. cleanup
6
락 해제
완료된 에셋 잠금이 남아 다음 작업자를 막지 않는지 확인합니다.
7
참조 안전
파일 이동 후 Redirector가 남거나 누락 참조가 생기지 않아야 합니다.
8
LFS 추적
새 바이너리 확장자가 일반 Git 객체로 들어가지 않게 추적 규칙을 확인합니다.

버전 관리 시스템의 필요성

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

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

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

변경 이력 추적: 모든 파일의 변경 내역을 기록하여, 특정 시점으로 언제든지 되돌릴 수 있습니다.
협업 용이성: 여러 명의 개발자가 동일한 프로젝트에서 동시에 작업해도 파일 충돌을 방지하고 변경 사항을 병합(Merge)할 수 있습니다.
안정성: 예기치 않은 오류나 데이터 손실 발생 시 이전의 안정적인 상태로 쉽게 복구할 수 있습니다.
백업 및 복원: 프로젝트의 안전한 백업을 제공하며, 필요할 때 복원할 수 있습니다.

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

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

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

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

Perforce의 특징

바이너리 파일에 최적화: .uasset과 같은 바이너리 파일의 변경 사항을 효율적으로 관리하고 저장합니다. Git과 같은 다른 VCS는 바이너리 파일 변경에 취약한 경우가 많습니다.
파일 잠금(File Locking): 하나의 파일을 한 번에 한 명만 수정할 수 있도록 잠그는 기능을 제공하여, 파일 충돌을 사전에 방지합니다. 이는 .uasset 파일처럼 병합이 어려운 바이너리 파일에 특히 유용합니다.
중앙 집중식: 모든 파일이 중앙 서버에 저장되어 관리됩니다.
언리얼 엔진 통합: 언리얼 에디터 내에서 Perforce 기능을 직접 사용할 수 있도록 강력하게 통합되어 있습니다.

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

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

아래 다이어그램은 백업, 명명, 검증 단계를 함께 정리합니다.

1
Sync
팀 최신 파일을 내려받아 로컬 상태를 맞춘다.
2
Checkout
수정할 에셋을 잠가 동시 덮어쓰기를 막는다.
3
Edit
레벨, 메시, 블루프린트를 작업 단위로 수정한다.
4
Submit
변경 이유와 함께 서버에 기록을 남긴다.
5
Resolve
다른 변경이 있으면 충돌과 의존성을 확인한다.

기준	판정
백업과 다른 점	되돌릴 파일뿐 아니라 팀 작업 순서를 통제한다.
제출 기준	잠금 없이 수정한 에셋과 설명 없는 제출을 줄인다.

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

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

언리얼 에디터 연동: 언리얼 에디터에서 소스 컨트롤(Source Control)을 Perforce로 설정하고 로그인합니다. (창(Window) > 개발자 툴(Developer Tools) > 소스 컨트롤(Source Control))

파일 체크아웃(체크아웃): 파일을 수정하기 전에 해당 파일을 체크아웃하여 잠급니다. (에디터에서 파일 수정 시 자동으로 체크아웃될 수 있음)

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

체크인(체크인): 수정이 완료되면 변경 사항을 체크인(커밋)하여 서버에 반영합니다.

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

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

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

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

Git의 특징

분산형: 각 개발자가 프로젝트의 전체 복사본(레포지토리)을 가지고 작업합니다. 중앙 서버 없이도 작업이 가능하며, 네트워크 연결이 끊겨도 작업할 수 있습니다.
코드 파일에 최적화: 텍스트 기반의 코드 파일 변경 사항 관리에 매우 강력합니다.
브랜치(Branch) 시스템: 특정 기능을 개발하거나 버그를 수정할 때 메인 라인(Master/Main 브랜치)에 영향을 주지 않고 독립적인 작업 공간을 만들 수 있습니다.
LFS (Large File Storage) 필요: .uasset과 같은 바이너리 파일은 Git이 효율적으로 관리하기 어렵습니다. 따라서 Git LFS (Large File Storage)와 같은 확장 기능을 함께 사용하여 대용량 바이너리 파일을 관리해야 합니다.

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

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

Git LFS 설정: 대용량 바이너리 파일 관리를 위해 Git LFS를 설정하고 .uasset과 같은 확장자를 추적하도록 합니다. (예: git lfs track "*.uasset")

언리얼 에디터 연동: 언리얼 에디터에서 소스 컨트롤(Source Control)을 Git로 설정하고 레포지토리에 연결합니다.

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

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

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

풀(Pull): 다른 팀원들의 변경 사항을 로컬 레포지토리로 가져옵니다.

Perforce
대규모 팀 중앙 서버와 파일 잠금으로 병합이 어려운 .uasset 충돌을 사전에 줄입니다.
Git + LFS
소규모 팀 코드 브랜치 흐름을 유지하면서 대용량 바이너리는 LFS로 분리해 관리합니다.
백업 규칙
개인 실험 전문 VCS 전에도 날짜 버전, Save As, 자동 저장 범위를 명확히 둡니다.

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

소규모 개인 프로젝트의 경우, 복잡한 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를 도입할 것을 강력히 권장합니다.

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

바이너리 에셋이 많은 팀
Perforce 파일 잠금으로 레벨, 머티리얼, 블루프린트 충돌을 사전에 막는 데 강합니다.
코드와 소규모 협업 중심
Git LFS 브랜치와 코드 리뷰 흐름을 유지하되 대용량 에셋은 LFS 추적으로 분리합니다.
개인 실험과 학습 프로젝트
Save As 날짜 버전, 자동 저장 개수, 중요한 레벨의 별도 저장 이름을 규칙으로 남깁니다.

다음 보드는 개인 프로젝트에서 간이 백업으로 버틸 수 있는 범위와, 협업 단계에서 Git이나 Perforce로 넘어가야 하는 신호를 나누어 보여줍니다.

Perforce 잠금
TEAM 여러 명이 만지는 바이너리는 체크아웃 소유자를 한 명으로 제한한다.
Git LFS + 백업
SMALL 소규모 팀은 대용량 추적과 날짜별 복구 지점을 함께 둔다.

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

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

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

마지막 보드는 선택한 버전 관리 방식이 실제 프로젝트 운영에서 지켜야 할 기준을 체크리스트로 다시 묶습니다.

대규모 팀에 강함
Perforce 체크아웃 잠금과 대용량 바이너리 관리가 필요한 협업 프로젝트에서 안정적인 선택입니다.
분산 개발에 익숙함
Git 코드와 설정 파일에는 편하지만 uasset, umap은 LFS와 잠금 규칙을 함께 검토해야 합니다.
충돌 병합이 어렵다
Binary 레벨과 에셋 파일은 텍스트처럼 쉽게 합치기 어려우므로 동시에 수정하지 않는 운영이 중요합니다.
개인 프로젝트도 기준 필요
Backup 압축 백업만 하더라도 날짜, 엔진 버전, 주요 변경 내용을 함께 남겨 복구 지점을 만듭니다.

이 페이지의 목차