버전 관리 및 패치 적용

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

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

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

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

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

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

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

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

주요 버전 관리 시스템

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

Git (Git)

특징: 분산 버전 관리 시스템(Distributed VCS). 일반적인 전체 clone은 각 개발자가 이력 사본을 가집니다. shallow/partial clone과 LFS 객체의 다운로드 범위는 다를 수 있습니다. 빠르고 유연하며, 브랜칭(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/Revision Control provider와 외부 클라이언트를 연결합니다. Perforce·SVN 지원과 Git 플러그인의 설치·기능 범위는 사용 버전에서 확인합니다.

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

소스 컨트롤 연결: 에디터의 Source Control/Revision Control 메뉴에서 provider와 연결 설정을 엽니다. 버전에 따라 메뉴 위치가 다릅니다.

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

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

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

체크아웃 (Checkout): 파일 수정 전에 콘텐츠 브라우저에서 파일을 우클릭하여 소스 컨트롤(Source Control) > 체크아웃(체크아웃)을 선택하여 편집용으로 엽니다. 바이너리의 동시 편집을 막는 exclusive lock은 Perforce typemap 등의 정책도 확인합니다.
체크인 (Checkin) / 커밋 (Commit): 수정이 완료되면 소스 컨트롤(Source Control) > 체크인(체크인) 또는 커밋(Commit)을 선택하여 변경 사항을 VCS에 반영합니다. 이때 변경된 내용을 명확하게 설명하는 메시지를 남깁니다.

패치 생성 및 적용 전략

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

패치 생성 (Pak 파일 기반)

여기서는 Pak 기반 콘텐츠 패치를 다룹니다. Io Store나 각 스토어·콘솔의 패치 방식은 해당 경로의 지침을 따릅니다. 실행 코드 변경은 콘텐츠 Pak만으로 전달할 수 없습니다.

베이스 릴리스 생성: Platforms > Project Launcher의 Custom Launch Profile에서 대상 플랫폼·Shipping·Cook by the Book을 설정합니다. Release/DLC/Patching의 릴리스 생성 옵션으로 이름을 지정하고 패키징합니다.

Releases/[릴리스 이름]/[플랫폼]의 에셋 레지스트리와 Pak, 원래 쿠킹된 콘텐츠 및 빌드 설정을 보관합니다. 이 릴리스 이름은 엔진의 Build.version과 다릅니다.

프로젝트 변경: 기준 태그에서 변경한 에셋과 코드를 구분합니다. 직렬화·엔진·쿠킹 설정의 변경이 기존 콘텐츠와 호환되는지 확인합니다.

패치 프로필 생성: Project Launcher의 Custom Launch Profile에서 Cook by the Book과 대상 맵·플랫폼을 확인합니다. Release/DLC/Patching에서 Release Version This is Based On에 보관한 기준 이름을 넣고 Generate Patch를 선택합니다. 별도 Asset Registry Version 숫자를 입력하는 절차로 대체하지 않습니다.

산출물 확인: 패치의 변경 단위는 에셋 패키지(.uasset 등)입니다. 내부 값 하나만 바뀌어도 패키지 전체가 포함되므로 패치가 항상 작다고 보장할 수 없습니다. 원래 설치본에 적용해 로드 우선순위와 세이브 호환성을 테스트합니다.

패치 적용 (Patch Application)

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

수동 적용: 가장 기본적인 방법으로, 개발 검증에서는 패치 Pak을 해당 빌드가 탐색하는 Pak 폴더에 배치하고, _p.pak 우선순위로 원래 콘텐츠를 덮어 읽는지 확인합니다. 실제 사용자 배포는 설치 프로그램·스토어의 무결성·업데이트 절차를 사용합니다.

런치 프로그램 (Launcher) 활용

대부분의 상업 게임은 자체적인 런치 프로그램(Launcher) 또는 플랫폼 제공 런치 프로그램(Steam, Epic Games Launcher 등)을 사용합니다.
런치 프로그램은 게임 서버 또는 CDN(Contents Delivery Network)에서 최신 패치 파일을 다운로드하고, 이를 플레이어의 게임 설치 경로에 자동으로 배치하여 적용합니다.
언리얼 엔진의 UnrealFrontend: 개발용 빌드·배포 도구입니다. 사용자가 패치를 받는 제품 런처나 CDN을 자동으로 제공하는 것은 아닙니다.

런타임 데이터 업데이트

런타임 중에 게임을 재시작하지 않고도 일부 데이터를 업데이트하는 기술입니다. 주로 서버 기반 게임에서 밸런스 수치, 이벤트 데이터 등을 즉시 변경할 때 사용됩니다.
UOnlineHotfixManager 등의 비실행 데이터 적용 경로를 구현합니다. 변경된 Pak·이미 로드된 레벨은 재시작/재로드가 필요할 수 있으며, 에디터의 Hot Reload/Live Coding과는 다른 기능입니다.

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

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

저장소와 릴리스 보관

.uproject, Content, Config, Source와 필요한 Plugins·Build 원본을 관리하고, Saved·Intermediate·DerivedDataCache 등 생성물과 구분합니다.
바이너리 에셋의 잠금·LFS 정책을 가져오기 전에 정하고, LFS 포인터만 있고 실제 객체가 없는 상태를 확인합니다.
소스 태그, 엔진·SDK 버전, 쿠킹 규칙, 기준 릴리스와 패치 산출물을 연결합니다.
핫픽스를 개발 흐름에도 병합하고, 이전 설치본→패치 적용·실패 복구·저장 데이터 호환을 함께 검증합니다.

이 페이지의 목차