안동민 개발노트

이전 절에서 우리는 게임 디버깅과 효율적인 로그 관리에 대해 알아보았습니다. 게임이 성공적으로 배포되어 서비스가 시작되면, 개발의 끝이 아니라 운영(Operations) 의 시작입니다. 플레이어 피드백, 버그 보고, 새로운 콘텐츠 추가 등의 이유로 게임을 업데이트해야 할 필요성이 끊임없이 발생합니다. 이러한 업데이트를 효율적으로 관리하고 배포하는 것은 플레이어 만족도를 유지하고 게임의 수명을 연장하는 데 매우 중요합니다.

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

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

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

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

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

패치 파일 생성

언리얼 엔진은 .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)하거나, 클라이언트가 시작 시 서버에 업데이트 요청을 보내는 커스텀 로직을 구현해야 합니다.

CDN (Content Delivery Network)

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

업데이트 과정의 고려 사항

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

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

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

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

게임 배포 이후의 핫픽스와 업데이트 전략은 게임의 지속적인 성공과 플레이어 커뮤니티 유지를 위해 매우 중요합니다. 긴급 버그 수정에는 핫픽스를, 광범위한 변경에는 업데이트를 활용하며, Incremental Patching과 Live Patching/Hotfix System과 같은 전략을 게임의 특성과 운영 환경에 맞게 선택해야 합니다. 언리얼 엔진의 쿠킹 및 패키징 시스템과 런타임 로딩 기능을 이해하고 활용하며, 효과적인 버전 관리, 테스트, 그리고 자동화된 배포 파이프라인을 구축하는 것이 안정적이고 효율적인 게임 운영의 핵심입니다.

핫픽스와 업데이트 전략

On this page