핫픽스와 업데이트 전략

이전 절에서는 게임 디버깅과 로그 관리를 다뤘습니다.

배포 이후에는 피드백, 버그 보고, 콘텐츠 추가에 대응하기 위해 업데이트 절차와 배포 방식을 운영 기준으로 관리해야 합니다.

이번 절에서는 언리얼 엔진 게임의 핫픽스(Hotfix)와 업데이트(Update)의 개념을 이해하고, 다양한 업데이트 전략 및 언리얼 엔진이 제공하는 관련 시스템에 대해 자세히 살펴보겠습니다.

실행 코드
RUNTIME Executable · Build ID — 네트워크 프로토콜의 기준점
컨테이너·Chunk
CONTENT Pak / IoStore · Chunk ID — 필수·선택 다운로드 분리
파일 목록
INDEX Manifest · Asset Registry — 파일 해시와 에셋 위치 고정
영속 데이터
STATE Save version · Migration — 옛 세이브를 읽는 호환 경계
변경 분류
코드·콘텐츠·설정·스키마를 나눠 hotfix 가능 범위를 정한다.
세트 생성
Chunk, registry, manifest 해시를 한 Release ID로 묶는다.
단계 검증
전 버전 업그레이드와 필수 Chunk만 받은 첫 실행을 시험한다.
승격·복구
세트를 함께 배포하고 실패하면 같은 단위로 되돌린다.

핫픽스 vs 업데이트: 개념 이해

문제 등급화
진행 불가, 결제/보상 오류, 크래시, 밸런스 문제를 긴급도별로 나눕니다. Severity
변경 범위 확정
코드, 데이터 테이블, Pak 콘텐츠, 서버 설정 중 무엇을 바꿀지 명확히 합니다. 범위
호환성 검증
기존 클라이언트, 저장 데이터, 서버 버전과 함께 동작하는지 확인합니다. Compatibility
배포와 감시
일부 사용자 또는 스테이징 환경에서 먼저 확인하고 지표를 봅니다. Monitor
롤백 경로
배포 후 문제가 생기면 이전 상태로 돌아갈 방법이 있어야 합니다.
세이브 호환
기존 저장 파일이 새 버전에서 안전하게 열리는지 확인합니다.
서버 매칭
클라이언트와 서버 버전 불일치가 플레이를 깨지 않게 처리합니다.

핫픽스 (Hotfix)
- 목적: 게임 플레이에 심각한 영향을 미치는 긴급 버그(예: 크래시, 진행 불가 버그, 익스플로잇)를 최대한 빠르게 수정하여 배포하는 것을 목표로 합니다.
- 특징: 일반적으로 패치 크기가 매우 작으며, 게임 클라이언트를 완전히 다시 다운로드하거나 재설치할 필요 없이 적용될 수 있도록 설계됩니다. 주로 코드 변경보다는 데이터 변경(설정값, 밸런스 조정 등)에 중점을 둡니다.
- 적용 방식: 게임 실행 중 자동으로 다운로드 및 적용되거나, 매우 작은 패치 파일을 통해 적용됩니다.
업데이트 (Update) / 패치 (Patch)
- 목적: 버그 수정 외에도 새로운 콘텐츠(맵, 캐릭터, 아이템), 기능 추가, 성능 개선, 밸런스 조정 등 광범위한 변경 사항을 포함합니다.
- 특징: 핫픽스보다 패치 크기가 크고, 적용하는 데 더 많은 시간과 대역폭이 소요될 수 있습니다. 일반적으로 클라이언트 전체 또는 변경된 부분의 재다운로드를 요구합니다.
- 적용 방식: 게임 런처나 플랫폼 스토어를 통해 다운로드하여 설치됩니다.

Hotfix
크래시, 익스플로잇, 진행 불가처럼 즉시 막아야 할 때 씁니다.
Incremental
변경 파일만 내려 받아 다운로드 부담을 줄입니다.
Live Data
밸런스와 이벤트는 데이터 중심 구조일 때 빠르게 바꿀 수 있습니다.
Rollback
실패한 배포를 되돌릴 기준 버전과 절차가 필요합니다.
C++ 설계 포인트
핫픽스 가능한 값은 코드 상수보다 데이터 에셋이나 설정으로 분리합니다. 패치 파일은 무결성 검증과 버전 비교를 거쳐 마운트합니다. 서버와 클라이언트 버전 정책이 다르면 접속 차단 기준이 필요합니다.
전략 매칭
Config 작은 수정 Pak patch 에셋 변경 Launcher 대형 업데이트 CDN 전송 안정성

언리얼 엔진의 업데이트 관련 시스템

언리얼 엔진은 패치 및 업데이트를 지원하기 위한 여러 도구와 개념을 제공합니다.

패치 파일 생성

언리얼 엔진은 .pak 파일을 통해 게임 콘텐츠를 패키징합니다.

업데이트 시에는 변경된 에셋만 포함하는 .pak 패치 파일을 생성할 수 있습니다.

쿡(Cook) 과정에서 패치 생성: 언리얼 엔진의 쿠킹 프로세스는 Package 모드 외에 Patch 모드를 지원합니다.
- RunUAT.bat BuildCookRun -project="[ProjectPath]" ... -cook -pak -stage -archive -targetplatform=[Platform] -build -cookonthefly -iterativecook -basedonreleaseversion=[ReleaseVersionNumber]
- cookonthefly: 필요할 때마다 동적으로 콘텐츠를 쿠킹합니다.
- iterativecook: 이전에 쿠킹된 결과를 기반으로 변경된 내용만 다시 쿠킹합니다.
- basedonreleaseversion: 이전에 배포된 특정 릴리즈 버전을 기준으로 변경된 에셋만 포함하는 패치 파일을 생성합니다.
UnrealPak.exe: 명령줄 도구로, .pak 파일을 생성, 압축, 해제하는 데 사용됩니다. 패치 파일을 수동으로 조합할 때 유용합니다.

다운로드 및 적용

언리얼 엔진은 런타임에 .pak 파일을 마운트(Mount)하여 게임 콘텐츠로 인식할 수 있는 기능을 제공합니다.

새로운 .pak 패치 파일이 다운로드되면, 게임은 이 파일을 특정 경로에 저장하고 FCoreDelegates::OnMountPak 등의 델리게이트를 통해 마운트하여 새로운 콘텐츠나 수정 사항을 적용할 수 있습니다.
이는 일반적으로 커스텀 패치 시스템이나 런처를 통해 구현됩니다.

버전 관리와 핫리로드

콘텐츠 핫리로드: 언리얼 엔진은 에디터에서 에셋을 수정하면 실시간으로 게임에 반영되는 핫리로드 기능을 가지고 있습니다. 이 개념은 런타임 패치에도 적용될 수 있지만, 코드 변경은 일반적으로 전체 재시작이 필요합니다.
Asset Registry: 언리얼 엔진은 모든 에셋의 메타데이터를 관리하는 Asset Registry를 가지고 있습니다. 업데이트된 에셋이 로드되면 이 레지스트리가 갱신되어 최신 버전을 사용하도록 합니다.

주요 업데이트 전략

게임의 특성, 플랫폼, 개발팀의 리소스에 따라 다양한 업데이트 전략을 선택할 수 있습니다.

Full Client Download

방법: 업데이트가 있을 때마다 플레이어가 게임 클라이언트 전체를 다시 다운로드하도록 하는 가장 단순한 방법입니다.
장점: 구현이 매우 간단하고, 파일 손상이나 패치 관련 문제를 최소화할 수 있습니다.
단점: 플레이어에게 가장 큰 불편함을 주며, 대용량 게임의 경우 막대한 대역폭과 다운로드 시간을 요구합니다. 모바일 게임에서 자주 사용되지만, PC 게임에서는 기피됩니다.
적합한 경우: 게임의 규모가 매우 작거나, 업데이트 빈도가 극히 낮을 때.

Incremental Patching (증분 패치)

방법: 이전에 배포된 버전을 기준으로 변경되거나 새로 추가된 파일만 다운로드하도록 하는 방식입니다. 언리얼 엔진의 basedonreleaseversion 쿠킹 옵션이 이를 지원합니다.
장점: 다운로드 크기를 크게 줄여 플레이어의 대역폭 부담과 다운로드 시간을 줄입니다.
단점: 패치 시스템의 구현이 복잡해집니다. 어떤 파일이 변경되었는지 정확히 추적하고, 파일 무결성을 검증하며, 패치 적용 중 발생할 수 있는 오류를 처리해야 합니다.
적합한 경우: 대부분의 PC 온라인 게임, 정기적인 업데이트가 필요한 게임.

Live Patching / Hotfix System

방법: 게임이 실행 중인 상태에서 또는 재시작 시점에 매우 작은 데이터 변경 사항(설정값, 밸런스 수치, 텍스트 등)을 네트워크를 통해 다운로드하고 적용하는 방식입니다. 코드를 직접 수정하는 것은 대부분 불가능하며, 주로 데이터 테이블, JSON 파일, 또는 특정 코드 경로를 통해 동적으로 로드되는 에셋에 한정됩니다.
장점: 플레이어가 게임을 완전히 다시 시작하지 않고도 수정 사항을 즉시 경험할 수 있어 사용자 경험에 매우 긍정적입니다. 긴급 버그 수정에 매우 효과적입니다.
단점: 구현이 가장 복잡하며, 어떤 데이터를 핫픽스 가능한 형태로 만들지 설계 단계부터 고려해야 합니다. 보안 취약점(데이터 변조)에 노출될 수 있으므로 무결성 검증이 중요합니다.
적합한 경우: 라이브 서비스 중인 온라인 게임, 긴급 밸런스 조정, 이벤트 활성화/비활성화.
언리얼 엔진에서의 구현
- Data Table / UDataAsset: 게임 데이터를 FDataTableRowHandle이나 UDataAsset으로 관리하면, 서버에서 최신 버전의 데이터 테이블/데이터 에셋을 다운로드하여 메모리에 로드함으로써 즉시 밸런스 변경 등을 적용할 수 있습니다.
- Config Files (.ini): .ini 파일에 저장된 설정 값들을 핫픽스로 업데이트할 수 있습니다.
- Asset Management (Asset Manager): FStreamableManager를 사용하여 특정 에셋을 비동기적으로 로드하고 언로드하는 방식으로 핫픽스 데이터를 관리할 수 있습니다.
- 커스텀 서버-클라이언트 통신: 게임 서버에서 최신 핫픽스 데이터를 클라이언트에게 푸시(Push)하거나, 클라이언트가 시작 시 서버에 업데이트 요청을 보내는 커스텀 로직을 구현해야 합니다.

핫픽스 안정성을 높이려면 C++ 측 데이터 로드/검증 코드를 함께 설계해야 합니다.

구체적인 구현 예시는 7장 3절의 Data Asset / Data Table 섹션을 참고하세요.

CDN (Content Delivery Network)

방법: 패치 파일이나 전체 클라이언트 빌드를 CDN에 호스팅하여 전 세계 플레이어에게 빠르고 안정적인 다운로드 서비스를 제공합니다.
장점: 높은 대역폭, 낮은 지연 시간, 높은 가용성을 제공하여 플레이어의 다운로드 경험을 향상시킵니다.
단점: CDN 서비스 비용이 발생합니다.
적합한 경우: 모든 규모의 온라인 게임.

업데이트 과정의 고려 사항

하위 호환성 (Backward Compatibility): 새로운 업데이트가 이전 버전의 세이브 파일이나 게임 데이터와 호환되는지 확인해야 합니다. 호환되지 않는다면 데이터 마이그레이션 또는 초기화 로직이 필요합니다.
버전 관리: 클라이언트와 서버의 버전 충돌을 방지하기 위해 엄격한 버전 관리 시스템을 유지해야 합니다. 서버는 구 버전 클라이언트의 접속을 거부하거나 강제 업데이트를 유도할 수 있습니다.
패치 노트(Patch Notes): 업데이트 내용을 상세하게 설명하는 패치 노트를 제공하여 플레이어가 변경 사항을 이해하도록 돕습니다.
롤백(Rollback) 계획: 업데이트 배포 후 심각한 문제가 발생할 경우를 대비하여 이전 버전으로 롤백할 수 있는 비상 계획을 마련해야 합니다.
A/B 테스트 및 단계별 배포: 새로운 기능이나 큰 변경 사항은 모든 플레이어에게 동시에 배포하기보다, 일부 사용자에게 먼저 A/B 테스트를 진행하거나, 점진적으로 배포하여 위험을 최소화할 수 있습니다.
다운로드 중 플레이: 일부 게임은 다운로드 중에도 게임 플레이를 허용하여 플레이어가 기다리는 시간을 줄입니다. (예: 필수 콘텐츠만 먼저 다운로드 후 플레이 가능)

수정 범위 분류
classify Data Table, config, asset, C++ 코드 중 어느 층을 바꾸는지 먼저 나눕니다.
패키지 생성
package 릴리즈 기준 버전과 변경 파일 목록을 고정해 pak 패치를 만듭니다.
마운트 검증
verify 해시, 서명, Asset Registry 갱신, 서버 버전 정책을 함께 확인합니다.
단계 배포
rollout 일부 채널에서 크래시와 접속 지표를 본 뒤 전체 배포로 넓힙니다.
호환성
pass 이전 세이브, 서버 프로토콜, 필수 에셋 경로가 깨지지 않아야 합니다.
복구 경로
pass 런처 캐시 삭제, 이전 pak 재마운트, 강제 업데이트 경로가 준비되어야 합니다.
관측 지표
hold 크래시율, 다운로드 실패율, 매치메이킹 오류가 기준선을 넘으면 멈춥니다.

지속적인 통합 및 배포 (CI/CD) 와의 연계

자동화된 CI/CD 파이프라인은 핫픽스 및 업데이트 전략의 효율성을 크게 높일 수 있습니다.

코드 변경 -> 자동 빌드 -> 자동 테스트 -> 패치 파일 생성 -> CDN 업로드 -> 런처 업데이트 알림 -> 플레이어 다운로드.
이러한 자동화는 업데이트 주기를 단축하고, 수동 오류를 줄이며, 개발팀의 부담을 경감시킵니다.

핫픽스와 정기 업데이트는 속도만 다른 것이 아니라 승인 기준, 롤백 준비, 플레이어 공지 방식까지 다른 운영 트랙입니다.

핫픽스 트랙
크래시, 진행 불가, 밸런스 악용처럼 서비스 중단 위험이 큰 변경입니다. 대상 Config, Data Table, 작은 Pak처럼 즉시 교체 가능한 데이터 검증 재현 케이스와 롤백 파일을 한 묶음으로 승인
업데이트 트랙
신규 콘텐츠, 코드 변경, 플랫폼 제출처럼 전체 빌드 흐름을 거칩니다. 대상 클라이언트 빌드, 대용량 에셋, 스토어 배포, CDN 반영 검증 자동 빌드, 패치 노트, 단계 배포, 호환성 테스트

업데이트를 안정적으로 운영하려면 빌드 산출물뿐 아니라 플레이어가 실제로 받는 버전, CDN 파일, 런처 안내, 서버 허용 버전이 같은 기준으로 맞아야 합니다.

기준 릴리즈 고정
BUILD basedonreleaseversion과 클라이언트 표시 버전을 같은 값으로 둡니다.
파일 경로 검증
CDN Pak, manifest, checksum이 런처가 읽는 위치에 올라갔는지 확인합니다.
접속 허용 조정
SERVER 구 버전 차단, 강제 업데이트, 단계 배포 비율을 서버에서 제어합니다.
플레이어 안내
NOTICE 다운로드 크기, 점검 시간, 주요 변경점을 패치 노트에 맞춥니다.

게임 배포 이후의 핫픽스와 업데이트 전략은 게임의 지속적인 성공과 플레이어 커뮤니티 유지를 위해 매우 중요합니다.

긴급 버그 수정에는 핫픽스를, 광범위한 변경에는 업데이트를 활용하며, Incremental Patching과 Live Patching/Hotfix System과 같은 전략을 게임의 특성과 운영 환경에 맞게 선택해야 합니다.

언리얼 엔진의 쿠킹 및 패키징 시스템과 런타임 로딩 기능을 이해하고 활용하며, 효과적인 버전 관리, 테스트, 그리고 자동화된 배포 파이프라인을 구축하는 것이 안정적이고 효율적인 게임 운영의 핵심입니다.

판단 축	승인 기준	남길 기록
증상 등급	크래시, 결제, 세이브 손상처럼 플레이 지속을 막는가	영향 버전과 재현 조건
변경 범위	코드, 데이터, 서버 설정, 콘텐츠 패치 중 수정면이 좁은가	수정 파일과 위험 범위
필수 검증	수정 재현, 주변 기능, 플랫폼별 실행을 확인했는가	QA 체크와 생략 근거
배포 관찰	크래시율, 접속 실패, 롤백 기준을 준비했는가	태그, 패치 노트, 모니터링 지표

핫픽스와 업데이트 전략은 패치 청크, 매니페스트, 버전 게이트, 롤백 경로, 배포 승인 기준으로 점검합니다.

이 페이지의 목차