버전 관리 및 패치 적용

유지보수 흐름을 잡았다면, 이제 그 흐름을 실제 배포 체계로 연결해야 합니다.

핵심은 버전 관리(Version Control)와 패치 적용(Patch Application)입니다.

개발 과정의 변경 이력을 체계적으로 남기지 않으면 협업 충돌과 회귀 이슈가 반복되고, 패치 전달 체계가 약하면 사용자 경험이 빠르게 악화됩니다.

이번 절에서는 언리얼 프로젝트에서 버전 변화와 패치 배포를 안정적으로 운영하는 방법을 다룹니다.

이 구조를 갖추면 개발 단계와 운영 단계를 하나의 일관된 프로세스로 묶을 수 있습니다.

버전 관리
Git: 코드 중심과 중소규모 프로젝트에 적합 Perforce: 대용량 바이너리 에셋과 잠금 흐름에 강함 Tag: 릴리즈 기준점을 되돌아갈 수 있게 고정
패치 적용
Base Build: 첫 출시 pak 파일을 기준으로 삼음 Patch Build: 변경된 에셋만 포함한 pak 생성 Launcher: 다운로드, 배치, 재시도, 무결성 검증 담당

게임 프로젝트 버전 관리의 중요성

버전 관리 시스템(Version Control System, VCS)은 게임 개발 팀이 코드 및 콘텐츠 변경 사항을 추적하고 관리하는 데 사용하는 필수 도구입니다.

변경 이력 추적: 누가, 언제, 무엇을 변경했는지 기록하여 문제 발생 시 원인을 쉽게 파적하고 되돌릴 수 있습니다.
협업 용이성: 여러 개발자가 동시에 같은 파일을 작업해도 충돌을 최소화하고 변경 사항을 병합(Merge)할 수 있도록 돕습니다.
백업 및 복구: 프로젝트 파일을 안전하게 저장하고, 실수로 인한 파일 손상이나 삭제 시 이전 버전으로 복구할 수 있습니다.
안정적인 빌드 관리: 특정 버전의 코드로 돌아가 특정 빌드를 생성하거나, 문제가 없는 안정적인 버전으로 되돌릴 수 있습니다.
지점(Branch) 관리: 새로운 기능 개발이나 버그 수정을 메인 개발 라인에 영향을 주지 않고 별도의 지점(Branch)에서 안전하게 작업할 수 있습니다.

Sync
작업 전 최신 리비전 받기
Checkout
에셋 잠금 후 수정
검토
맵·블루프린트 영향 확인
Submit
빌드 가능한 단위로 반영
Git
C++ 코드, Config, 머티리얼 함수처럼 텍스트 변경이 많고 팀이 작을 때 시작 비용이 낮습니다.
Git LFS
.uasset, .umap, .fbx, .wav를 LFS와 lockable 속성으로 관리해 바이너리 충돌을 줄입니다.
Perforce
P4V 체크아웃, exclusive lock, stream 분기가 필요한 대규모 콘텐츠 제작에 적합합니다.
Branch
release, hotfix, feature, engine-upgrade 흐름을 나눠 에셋 마이그레이션 회귀를 줄입니다.
에셋 저장소 운영 규칙
DerivedDataCache, Saved, Intermediate는 무시하고 Content와 Config 변경만 의도적으로 올립니다. 큰 바이너리 파일은 처음 가져오기 전에 .gitattributes와 LFS 추적 규칙을 먼저 확정합니다. 안정 빌드 태그와 엔진 버전 기록을 남기면 패치나 마이그레이션 실패 시 빠르게 되돌릴 수 있습니다.
저장소 실패 신호
uasset merge 잠금 없는 동시 편집 LFS pointer 대용량 파일 일반 Git generated dirs 생성물 커밋 no release tag 패치 기준 없음

주요 버전 관리 시스템

언리얼 엔진 프로젝트에 주로 사용되는 버전 관리 시스템은 다음과 같습니다.

Git (Git)

특징: 분산 버전 관리 시스템(Distributed VCS). 각 개발자가 코드의 전체 이력 사본을 가집니다. 빠르고 유연하며, 브랜칭(Branching)과 병합(Merging)이 강력합니다.
장점
- 오프라인 작업 가능.
- 작업 속도가 빠름.
- 커뮤니티 지원이 활발하고 다양한 GUI 툴(Sourcetree, GitKraken, GitHub Desktop)이 존재.
단점
- 대용량 바이너리 파일(언리얼 에셋) 관리가 상대적으로 비효율적입니다. Git LFS (Large File Storage)를 사용하여 보완할 수 있지만 설정이 필요합니다.
- 히스토리가 길어지면 리포지토리 크기가 매우 커질 수 있습니다.
활용: 중소규모 프로젝트, C++ 코드 중심의 프로젝트에 적합. Git LFS를 설정하여 언리얼 에셋도 관리할 수 있습니다.

Perforce (Helix Core)

특징: 중앙 집중식 버전 관리 시스템(Centralized VCS). 모든 변경 사항이 중앙 서버를 통해 관리됩니다. 대용량 바이너리 파일 관리에 매우 최적화되어 있습니다.
장점
- 언리얼 엔진과 에픽게임즈에서 공식적으로 권장하고 사용합니다.
- 대규모 프로젝트와 수많은 언리얼 에셋 파일 관리에 탁월합니다.
- 체크아웃(Checkout)/체크인(Checkin) 방식이 명확하여 바이너리 파일 충돌을 줄여줍니다.
- 강력한 권한 관리 기능을 제공합니다.
단점
- 중앙 서버가 다운되면 작업이 불가능합니다.
- 라이선스 비용이 발생할 수 있습니다(소규모 팀의 경우 무료 버전 사용 가능).
활용: 대규모 상업용 게임 프로젝트, 콘텐츠가 많은 프로젝트에 가장 적합합니다.

SVN (Subversion)

특징: 중앙 집중식 버전 관리 시스템. Git보다 오래되었으며, Perforce와 유사하게 중앙 서버 기반입니다.
장점
- 설정이 비교적 간단.
- Git LFS 없이도 바이너리 파일 관리 가능.
단점
- 브랜칭/병합 기능이 Git보다 취약.
- 대규모 프로젝트에서는 성능 문제가 발생할 수 있습니다.
활용: 소규모 팀이나 간단한 프로젝트에서 Perforce 구축이 어려운 경우 대안으로 사용될 수 있습니다.

언리얼 엔진에서 버전 관리 설정

언리얼 엔진은 Source Control 플러그인을 통해 주요 VCS를 지원합니다.

플러그인 활성화: 편집(Edit) > 플러그인(Plugins) 메뉴에서 사용하고자 하는 버전 관리 시스템(예: Perforce, Git) 플러그인을 활성화합니다.

소스 컨트롤 연결: 에디터 우측 하단의 소스 컨트롤(Source Control) 아이콘을 클릭하거나, 파일(File) > 소스 컨트롤 연결(Connect To Source Control)을 선택합니다.

VCS 서버 정보 입력: 선택한 VCS에 따라 서버 주소, 포트, 사용자 이름 등을 입력하고 연결합니다.

Perforce: P4V 클라이언트를 설치하고 워크스페이스를 설정한 후, 언리얼 엔진에서 해당 워크스페이스에 연결합니다.
Git: Git 리포지토리를 초기화하고, Git LFS를 설정하여 .uasset 파일 등 대용량 파일을 추적하도록 .gitattributes 파일을 구성합니다.

파일 관리: 연결이 완료되면 콘텐츠 브라우저의 에셋 아이콘 옆에 VCS 상태 아이콘(예: 잠금, 수정됨, 추가됨)이 표시됩니다.

체크아웃 (Checkout): 파일 수정 전에 콘텐츠 브라우저에서 파일을 우클릭하여 소스 컨트롤(Source Control) > 체크아웃(체크아웃)을 선택하여 파일을 잠급니다. (Perforce)
체크인 (Checkin) / 커밋 (Commit): 수정이 완료되면 소스 컨트롤(Source Control) > 체크인(체크인) 또는 커밋(Commit)을 선택하여 변경 사항을 VCS에 반영합니다. 이때 변경된 내용을 명확하게 설명하는 메시지를 남깁니다.

패치 생성 및 적용 전략

Mainline
일상 개발은 main 또는 develop에서 통합하며 자동 검사를 붙입니다. 통합 기준
Release Cut
출시 후보는 release 브랜치로 고정하고 위험 변경을 제한합니다. 안정화
Hotfix
출시 버전에서 필요한 최소 수정만 분리해 검증합니다. 최소 변경
Merge Back
핫픽스 수정이 다음 개발 흐름에서 사라지지 않게 되돌려 병합합니다. 재발 방지
기준 태그
패치 대상 릴리스 커밋과 콘텐츠 빌드 번호가 고정되어야 합니다.
에셋 잠금
동시에 수정하면 위험한 레벨과 데이터 에셋은 잠금 정책을 둡니다.
역병합
릴리스 브랜치의 수정이 개발 브랜치에도 반영됐는지 확인합니다.

게임 출시 후 패치와 업데이트를 효율적으로 배포하는 것은 플레이어 경험에 직결됩니다.

패치 생성 (Pak 파일 기반)

언리얼 엔진은 Pak 파일을 기반으로 패치를 생성하는 기능을 제공합니다.

베이스 버전 패키징: 첫 번째 출시 빌드(베이스 버전)를 Shipping 구성으로 패키징합니다.

이 빌드의 .pak 파일들이 패치 생성을 위한 기준이 됩니다.

프로젝트 변경: 게임 프로젝트에서 버그 수정이나 새로운 콘텐츠 추가 등의 변경 작업을 수행합니다.

패치 빌드 생성

Project Settings > Packaging으로 이동합니다.
Build Configuration을 Shipping으로 설정합니다.
List of maps to include in a packaged build가 올바른지 확인합니다.
Generate Patch (패치 생성) 옵션을 활성화합니다.
Based on Release Version (릴리즈 버전 기반): 이전에 패키징했던 베이스 버전의 릴리즈 이름을 입력합니다. 이 릴리즈 이름은 Build.version 파일에 기록된 이름입니다.
Asset Registry Version (에셋 레지스트리 버전): 패치할 릴리즈의 에셋 레지스트리 버전을 입력합니다.
파일(File) > 프로젝트 패키징(Package Project) > [대상 플랫폼]을 다시 선택하여 패키징을 진행합니다.
결과: 엔진은 베이스 버전과의 차이점만 포함하는 새로운 .pak 파일을 생성합니다. 이 파일은 베이스 .pak 파일보다 훨씬 작습니다.

패치 적용 (Patch Application)

생성된 패치 파일을 플레이어의 게임 클라이언트에 적용하는 방법입니다.

수동 적용: 가장 기본적인 방법으로, 플레이어가 패치 .pak 파일을 다운로드하여 게임 설치 경로의 Content\Paks 폴더에 직접 복사하도록 안내합니다. (일반적으로 상업 게임에서는 사용되지 않음)

런치 프로그램 (Launcher) 활용

대부분의 상업 게임은 자체적인 런치 프로그램(Launcher) 또는 플랫폼 제공 런치 프로그램(Steam, Epic Games Launcher 등)을 사용합니다.
런치 프로그램은 게임 서버 또는 CDN(Contents Delivery Network)에서 최신 패치 파일을 다운로드하고, 이를 플레이어의 게임 설치 경로에 자동으로 배치하여 적용합니다.
언리얼 엔진의 UnrealFrontend: 개발 단계에서 런치 프로그램의 기능을 테스트할 때 사용될 수 있습니다. (고급 기능)

Hot-Reload / Live Update (핫-리로드 / 라이브 업데이트)

런타임 중에 게임을 재시작하지 않고도 일부 데이터를 업데이트하는 기술입니다. 주로 서버 기반 게임에서 밸런스 수치, 이벤트 데이터 등을 즉시 변경할 때 사용됩니다.
언리얼 엔진의 FHotfixManager나 커스텀 빌드된 라이브 업데이트 시스템을 통해 구현합니다. (매우 고급 기능)

릴리즈 태그와 빌드 이름
기준 고정 첫 출시 pak, Build.version, 에셋 레지스트리를 같은 기준점에 묶는다.
패치 pak 생성
변경 묶음 버그 수정과 콘텐츠 추가분만 포함해 다운로드 크기를 줄인다.
QA와 무결성 확인
검증 세이브 호환, 재현 버그, 파일 해시, 설치 경로를 함께 확인한다.
런처와 CDN 적용
배포 다운로드 실패 재시도와 롤백 절차를 배포 계획에 포함한다.

버전 관리 및 패치 적용 시 고려사항

명확한 커밋/체크인 메시지: 모든 변경 사항에 대해 명확하고 간결한 설명을 남겨 변경 이력을 쉽게 파악할 수 있도록 합니다.
브랜칭 전략: 새로운 기능 개발, 버그 수정, 릴리즈 준비 등 목적에 따라 적절한 브랜칭 전략(예: Git Flow)을 사용합니다. 메인 브랜치(Master/Main)는 항상 안정적인 상태를 유지하도록 합니다.
태그(Tag) 활용: 주요 릴리즈 버전이나 패치 버전에 태그를 지정하여 특정 시점의 코드를 쉽게 참조할 수 있도록 합니다.
자동화된 빌드 시스템: Jenkins, TeamCity, Unreal Build Tool (UBT)과 같은 CI/CD(Continuous Integration/Continuous Deployment) 툴을 사용하여 빌드 및 패치 생성 과정을 자동화합니다. 이는 오류를 줄이고 빌드 시간을 단축시킵니다.
QA 및 테스트 빌드: 패치 적용 전에 QA 팀이나 베타 테스터에게 테스트 빌드를 배포하여 충분한 테스트를 거치도록 합니다.
파일 크기 관리: 패치 파일의 크기를 최소화하기 위해 노력합니다. 이는 플레이어의 다운로드 시간을 줄이고 데이터 비용 부담을 경감시킵니다.
네트워크 고려: 플레이어의 네트워크 환경이 불안정할 수 있음을 고려하여 패치 다운로드 실패 시 재시도 로직 등을 구현합니다.

작고 급한 수정
Hotfix 밸런스 수치, 긴급 버그처럼 영향 범위가 좁으면 최소 변경과 짧은 QA로 처리합니다.
베이스 기준 변경분
Patch pak Release Version과 에셋 레지스트리를 기준으로 변경된 pak만 생성해 다운로드 부담을 줄입니다.
구조가 바뀐 업데이트
Full build 저장 형식, 맵 구성, 코드 구조가 크게 바뀌면 전체 빌드와 회귀 테스트가 더 안전합니다.

버전 관리와 패치 적용은 기준 버전, 변경 범위, 배포 파일, 롤백 절차를 추적하는 과정입니다.

언리얼 프로젝트에서는 소스 관리 설정과 패치 산출물 검증을 함께 관리해야 합니다.

패치 관리는 파일을 만드는 일보다 기준 버전과 변경 범위를 추적하는 일이 더 중요합니다.

수정 분리
Branch 출시 버전과 실험 기능을 분리해 긴급 수정이 섞이지 않게 합니다.
변경 확인
Diff 맵, 설정, 에셋, 코드 중 무엇이 바뀌었는지 배포 전에 봅니다.
회귀 확인
Test 고친 기능뿐 아니라 시작, 저장, 종료 같은 기본 루프도 다시 실행합니다.
적용 기록
Release 패치 파일, 날짜, 영향 범위, 되돌림 방법을 함께 남깁니다.

이 페이지의 목차