환경 설정의 배포 준비
프로젝트·플랫폼·코드·콘텐츠 설정을 릴리스 기준으로 최종 점검해 개발 환경과 사용자 빌드의 차이를 줄입니다.
기능을 만들고 성능을 점검했다면, 이제 결과물을 실제 사용자의 환경으로 옮길 준비를 할 차례입니다. 에디터에서는 잘 동작하던 게임이 패키징한 뒤에는 엉뚱한 맵에서 시작하거나, 일부 에셋이 빠져 깨지거나, 다른 컴퓨터에서는 실행조차 되지 않는 일이 흔합니다. 개발 환경과 사용자 환경이 다르기 때문입니다.
10장에서는 게임을 플레이어에게 전달하고, 그 뒤에도 안정적으로 운영하는 흐름을 다룹니다. 그 첫 단계인 이 글에서는 개발 환경에서만 동작하던 설정이 사용자 환경에서도 그대로 동작하도록, 배포 직전에 확인할 프로젝트 설정과 플랫폼 설정, 코드와 콘텐츠를 차례로 점검하고, 첫 패키지를 만들어 시험하는 순서를 정리합니다. 이 과정을 거치면 출시 직후에 생기기 쉬운 실행 환경의 문제를 크게 줄일 수 있습니다.
배포 준비가 필요한 이유
배포 준비는 개발의 마지막 단계이자, 플레이어가 받는 게임의 첫인상을 정하는 과정입니다. 먼저 실행 호환성을 확인합니다. 개발 환경과 플레이어의 환경은 다를 수 있으므로, 지원하기로 한 사용자 환경에서 게임이 실행되는지 확인해야 합니다. 그리고 최종 빌드에 필요한 최적화 설정이 제대로 적용되어, 지원 사양에서 목표 성능이 나오는지 확인합니다.
필요 없는 데이터를 빼고 효율적으로 패키징하면 설치 용량과 로딩 시간이 줄어듭니다. 게임 데이터를 알맞게 암호화하거나 패키징하면 데이터를 꺼내거나 고치기 어렵게 만들 수 있지만, 패키징 자체가 무단 변조나 복제를 막아 주는 것은 아닙니다. 마지막으로 PC와 모바일, 콘솔은 각자의 배포 기준과 인증 절차가 있으므로 그것도 맞춰야 합니다.
프로젝트 설정 최종 점검
Edit 메뉴의 Project Settings에는 배포에 필요한 전체 설정이 모여 있습니다. 다음 항목들을 점검합니다.
Project 항목
Maps & Modes에서는 시작 맵을 확인합니다. Editor Startup Map은 에디터를 시작할 때 여는 개발용 맵이고, Game Default Map은 게임을 시작할 때 여는 배포용 맵이므로, 반드시 게임의 시작 맵으로 정합니다. Transition Map은 맵을 끊김 없이 옮기는 심리스 트래블(seamless travel)에서 잠깐 거쳐 가는 맵으로, 일반적인 로딩 화면과는 다른 것입니다. Default GameMode도 게임의 기본 게임 모드 클래스로 제대로 정해져 있는지 확인합니다.
Packaging에서는 무엇을 어떻게 묶을지 확인합니다. List of maps to include in a packaged build는 빌드에 넣을 맵의 목록으로, 필요한 맵이 쿠킹되는지 확인합니다. 이 목록 말고도 에셋 매니저(Asset Manager)나 명령행 같은 쿠킹 규칙이 영향을 줍니다. Build Configuration은 개발용 Development, 최종 배포용 Shipping, 디버그 정보가 들어간 DebugGame 가운데 Shipping을 고릅니다. Shipping은 출시용 최적화를 적용하고 콘솔과 통계를 제한하는데, 디버그 심볼을 만들어 보관할지와 패키지에 넣을지는 따로 관리합니다.
Use Pak File을 켜면 쿠킹한 콘텐츠를 하나 이상의 .pak 파일로 묶습니다. 압축은 별도의 옵션이고, 아이오 스토어(Io Store)를 쓰면 .utoc와 .ucas 컨테이너도 함께 만들어지므로 확인합니다. For Distribution은 앱 스토어 같은 대상 플랫폼의 배포용 구성을 고르는 옵션인데, 인증서와 서명, 암호화 설정까지 저절로 갖춰지지는 않습니다. Cook everything in the project content directory는 콘텐츠 폴더의 모든 에셋을 쿠킹할지로, 모든 콘텐츠가 필요할 때 씁니다. 크기를 줄이고 싶다면 이 옵션 대신 필요한 맵과 참조, 실행 중에 불러오는 에셋을 명시하고, 빠진 것이 없는지 시험합니다.
Description에서는 Project Name, Company Name, Copyright Notice 같은 게임의 이름과 회사명, 저작권 정보를 정확히 적습니다. 이 정보는 설치 파일이나 실행 파일의 정보에 표시될 수 있습니다. Project Version에는 게임의 지금 버전을 적습니다.
Engine 항목
Rendering에서는 프레임 제한과 동기화, 백그라운드에서의 동작을 실제 패키지에서 확인합니다. 에디터 환경설정의 Use Less CPU when in Background는 에디터의 설정이므로, 배포한 게임의 동작으로 생각하지 않습니다. 모션 블러, 안티에일리어싱 방식, 간접광과 반사 방식처럼 환경 설정의 성능 영향 분석에서 다룬 렌더링 품질 설정을 최종으로 검토하고, 저사양 플랫폼에서는 필요 없는 고품질 효과를 끄는 것처럼 목표 플랫폼에 맞는 균형을 찾습니다.
Input에서는 기존 방식의 Action Mappings와 Axis Mappings, 또는 향상된 입력의 입력 액션과 매핑 컨텍스트에서 모든 조작이 제대로 연결되었는지, 겹치거나 빠진 키가 없는지 확인합니다. 특히 Esc처럼 시스템이 쓰는 기본 키와 겹치지 않는지 봅니다. Physics에서는 기본 물리 엔진 설정과 물리 시뮬레이션 성능 조정에서 다룬 Max Physics Delta Time과 Max Substeps 같은 설정이 게임의 물리 안정성에 알맞은지 확인합니다.
플랫폼별 설정 점검
Windows, Android, iOS 같은 플랫폼은 각자의 배포 요구사항이 있습니다. Project Settings의 Platforms 항목에서 대상 플랫폼을 골라 점검합니다.
Windows에서는 게임 아이콘과 실제 패키지의 실행 파일 이름을 확인합니다. 필수 런타임을 함께 넣을지는 Packaging의 Prerequisites 설정에서, 설치 위치는 별도의 설치 프로그램이나 스토어 설정에서 확인합니다.
Android와 iOS에서는 확인할 것이 더 많습니다. Android의 패키지 이름과 버전 코드, iOS의 번들 식별자(Bundle Identifier)와 버전, 빌드 번호 같은 플랫폼별 식별 정보를 확인합니다. 앱 서명을 위해 Android는 키스토어(keystore)를, iOS는 인증서와 프로비저닝 프로필(provisioning profile)을 설정합니다. 텍스처 압축 형식은 엔진 버전과 대상 기기가 지원하는 ASTC나 ETC2 같은 형식인지 확인합니다.
Android의 Minimum SDK Version은 앱이 실행될 수 있는 최소 API 수준이고, Target SDK Version은 앱이 맞춰 만든 API 수준입니다. Target SDK가 지원하는 최대 OS 버전을 뜻하지는 않으며, iOS의 최소 지원 버전은 따로 정합니다. 화면 방향(Orientation)을 세로나 가로로 정하고, 64비트 ARM64 아키텍처를 지원하는지도 확인합니다.
콘솔은 Sony, Microsoft, Nintendo 같은 각 제조사의 개발자 프로그램에 등록해 SDK와 배포 지침을 받아야 합니다. 언리얼 엔진은 그 SDK와 연동해 빌드를 만듭니다. 플랫폼마다의 차이는 크로스 플랫폼 배포 고려사항에서 자세히 다룹니다.
코드와 콘텐츠 정리
코드와 블루프린트
개발 중에 쓴 Print String이나 Draw Debug Sphere가 개발용으로만 동작한다는 점과, 직접 만든 디버그 경로가 배포 빌드에 남지 않는지를 확인합니다. C++에서는 에디터에서만 쓰는 코드는 WITH_EDITOR로, Shipping에서만 다르게 할 코드는 UE_BUILD_SHIPPING으로 나누며, WITH_EDITORONLY_DATA를 실행 코드를 나누는 일반 스위치로 쓰지 않습니다. 더 이상 쓰지 않는 함수와 변수, 이벤트 그래프의 노드는 정리하고, 남은 코드에는 주석과 문서를 남겨 나중의 유지보수를 쉽게 합니다.
콘텐츠
콘텐츠 브라우저에서 레퍼런스 뷰어로 에셋이 어디에서 쓰이는지 확인하고, 실행 중에 불러오는 경로와 에셋 매니저의 규칙까지 확인한 뒤 정말 쓰지 않는 에셋만 지웁니다. 같은 에셋이 여러 개 복제되어 있지 않은지 확인해 하나로 통일하고, 에셋과 레벨 최적화 기법에서 다룬 LOD와 충돌 형상이 모든 메시에 제대로 적용되었는지 다시 확인합니다. 마지막으로 모든 텍스처와 재질, 메시가 결함 없이 의도대로 보이는지 검토합니다.
첫 패키지를 만들고 시험하기
배포 준비의 마지막은 실제 빌드를 만들어 시험하는 것입니다. 에디터에서 플레이할 때는 프로젝트의 모든 에셋과 엔진이 이미 열려 있지만, 패키지는 쿠킹한 콘텐츠만 담고 엔진이 없는 컴퓨터에서도 실행되어야 합니다. 그래서 앞에서 점검한 설정이 맞았는지는 패키지를 직접 만들어 실행해 봐야 알 수 있습니다. 아래에서는 플랫폼 하나로 첫 패키지를 만들고, 그 결과를 여러 환경에서 시험하는 순서로 진행합니다.
한 플랫폼으로 시작하기
첫 패키지는 지금 개발하는 장치에서 지원되는 플랫폼 하나를 골라 만듭니다. 다른 플랫폼의 SDK와 서명까지 동시에 바꾸면, 실패했을 때 원인을 가르기 어렵기 때문입니다. 맵과 블루프린트를 모두 저장하고, 시작 맵과 플레이할 맵이 쿠킹 대상인지 확인한 뒤, 프로젝트 원본과 다른 출력 폴더로 패키징합니다. 실행할 때는 그 폴더의 실행 파일과 콘텐츠를 함께 두고 실행하며, .exe 하나만 떼어 옮기지 않습니다.
진단은 Development 패키지로 먼저 하고, 출시 후보는 같은 소스로 만든 Shipping 패키지에서 다시 확인합니다. Shipping에서는 개발용 콘솔로 게임을 끌 수 없으므로, 사용자에게 줄 종료 입력이나 UI를 준비해 둡니다. 이 과정은 실제 패키지를 점검하는 절차이며, PIE로 실행해 보는 것으로 대신할 수 없습니다.
패키징하기
툴바의 Platforms 메뉴에서 대상 플랫폼을 고르고 Package Project를 눌러 Windows나 Android 같은 플랫폼으로 패키징합니다. Build Configuration을 출시 후보라면 Shipping으로 정하는 것을 잊지 않습니다. 패키징 중에 오류가 생기면 출력 로그(Output Log)에서 컴파일 오류나 에셋 참조 오류 같은 원인을 찾아 해결합니다. 패키징 설정은 패키징 및 빌드 설정에서 자세히 다룹니다.
최종 시험
만든 게임은 가능한 한 여러 하드웨어 사양과 운영체제 버전에서 시험합니다. 찾은 버그는 빨리 보고하고 고치며, 로딩 시간이 허용할 수 있는 범위인지 잽니다. 성능은 Development나 Test 빌드의 통계로 원인을 분석하고, 콘솔과 Stat이 제한되는 Shipping에서는 플랫폼의 측정 도구나 프로젝트에 미리 넣어 둔 계측으로 목표 성능을 확인합니다.
엔진이 설치되지 않은 지원 장치에서 설치, 첫 실행, 저장, 종료, 다시 실행을 확인하는 것도 중요합니다. 개발 컴퓨터에는 엔진과 런타임이 이미 깔려 있어서 드러나지 않는 문제가 있기 때문입니다. 그리고 빌드 번호와 설정, 필수 런타임, 측정 결과를 함께 보관합니다. 에디터에서 성공했다는 사실만으로 패키지도 성공한다고 판단하지 않습니다.
정리
- 배포 준비는 개발 환경에서 동작하던 설정이 사용자 환경에서도 그대로 동작하도록 점검하는 과정이며, 패키징 자체가 변조나 복제를 막아 주지는 않습니다.
Game Default Map은 게임의 시작 맵으로 정하고, 필요한 맵이 쿠킹되는지 확인하며, 출시 후보는Shipping으로 빌드합니다.Use Pak File과 아이오 스토어,For Distribution은 각각 묶는 방식과 배포 구성을 정할 뿐, 압축과 서명, 암호화는 따로 확인합니다.- 플랫폼마다 식별 정보와 서명, 텍스처 압축 형식, SDK 버전을 점검하며, Android의 Target SDK는 지원하는 최대 OS 버전이 아닙니다.
- 디버그 코드와 쓰지 않는 에셋은 실행 중에 불러오는 경로까지 확인한 뒤 정리합니다.
- 첫 패키지는 플랫폼 하나로 만들고, Development로 진단한 뒤 Shipping으로 다시 확인하며, 엔진이 없는 장치에서 설치부터 다시 실행까지 시험합니다.
연습 문제
1. 패키지는 어느 맵에서 시작할까
Editor Startup Map은 Lab, Game Default Map은 MainMenu입니다. 두 맵 모두 정상적으로 쿠킹되었고, 실행 인자나 코드, 플랫폼 설정에서 시작 맵을 덮어쓰지 않습니다. 패키지를 실행하면 어느 맵에서 시작할까요? PIE에서 Lab을 잘 플레이했다는 기록만으로 이 시작 화면도 확인했다고 할 수 있을까요?
해설 보기
패키지는 MainMenu에서 시작합니다. Editor Startup Map은 에디터를 시작할 때 쓰는 맵이라, 이 조건에서 게임의 시작 맵을 대신하지 않습니다.
PIE에서 Lab을 잘 플레이한 것은 Lab의 플레이를 확인한 것일 뿐, 패키지에서 MainMenu가 처음 열리고, 입력을 받고, 종료하고, 다시 실행되는 것까지 확인한 것은 아닙니다. 두 맵이 패키지에 들어갔는지와 어느 맵에서 시작하는지도 서로 다른 설정입니다.
2. 실행 파일만 복사했더니
패키징한 폴더에서 게임의 .exe 파일만 다른 컴퓨터로 복사해 실행했더니 바로 오류가 납니다. 개발 컴퓨터의 패키지 폴더에서는 잘 실행됩니다. 무엇이 문제일까요?
해설 보기
실행 파일은 같은 패키지 폴더에 있는 콘텐츠 파일, 예를 들어 .pak이나 .utoc, .ucas 같은 컨테이너를 함께 읽어야 실행됩니다. .exe 하나만 옮기면 콘텐츠를 찾지 못합니다.
또 다른 컴퓨터에는 개발 컴퓨터에 깔린 필수 런타임이 없을 수 있습니다. 그래서 패키지 폴더를 통째로 옮기고, 필수 런타임을 함께 넣거나 설치하게 한 뒤, 엔진이 없는 장치에서 설치부터 다시 실행까지 시험합니다.
3. 쓰지 않는 것 같아서 지웠더니
레퍼런스 뷰어에서 아무도 참조하지 않는 것으로 보이는 이펙트 에셋을 지우고 패키징했습니다. 그런데 패키지에서 특정 상황에 이펙트가 나오지 않고 경고가 남습니다. 무엇을 놓쳤을까요?
해설 보기
그 에셋이 코드나 데이터 테이블에서 이름이나 경로로 실행 중에 불러오는 에셋이었을 가능성이 큽니다. 이런 참조는 레퍼런스 뷰어의 그래프에 나타나지 않을 수 있습니다.
에셋을 지우기 전에는 레퍼런스 뷰어뿐 아니라 실행 중에 불러오는 경로와 에셋 매니저의 규칙까지 확인해야 합니다. 그런 에셋은 지우지 말고, 패키징 설정에서 쿠킹 대상에 포함되도록 명시합니다.
패키징 설정의 전체 항목은 Epic의 프로젝트 패키징 안내에서 확인할 수 있습니다.
다음 글 패키징 및 빌드 설정에서는 빌드 구성의 차이와 쿠킹, 패키징의 과정을 자세히 살펴보고, 목적에 맞는 빌드를 만드는 방법을 다룹니다.