크로스 플랫폼 배포 고려사항

한 플랫폼에만 배포하면 운영은 단순하지만, 만날 수 있는 플레이어도 그만큼 제한됩니다. 반대로 PC와 모바일, 콘솔을 함께 노리면 기회는 커지지만, 입력 방식과 성능의 한계, 심사 규정이 모두 달라 준비할 것이 크게 늘어납니다. 같은 게임이라도 PC에서는 부드럽게 돌아가던 장면이 모바일에서는 끊기고, 키보드로는 잘 되던 메뉴가 게임패드로는 움직이지 않는 일이 생깁니다.

이 글에서는 여러 플랫폼에 배포할 때의 이점과 과제를 정리하고, 모바일과 콘솔, PC마다 성능을 맞추는 방법, 입력과 UI를 플랫폼에 맞게 바꾸는 방법, 각 스토어와 콘솔의 배포와 인증 절차를 살펴봅니다. 마지막으로 플랫폼을 고르는 순서와, 같은 기능을 플랫폼마다 확인하는 방법을 예와 함께 정리합니다. 이 글을 마치면 프로젝트에 맞는 크로스 플랫폼(cross-platform) 전략을 스스로 고를 수 있습니다.

---

여러 플랫폼에 배포하는 이점과 과제

하나의 게임을 여러 플랫폼에 배포하면 분명한 이점이 있습니다. PC 게이머뿐 아니라 모바일과 콘솔의 플레이어에게도 게임을 제공해 만날 수 있는 플레이어가 크게 늘고, 구매나 앱 안의 결제 기회도 늘어 매출이 높아집니다. 여러 플랫폼에서 게임을 만날 수 있게 되면 브랜드가 알려지고 팬이 생깁니다. 또 언리얼 엔진 같은 크로스 플랫폼 엔진을 쓰면, 플랫폼마다 완전히 다른 게임을 만드는 것보다 개발 비용과 시간을 아낄 수 있습니다.

반면 풀어야 할 과제도 있습니다. 플랫폼마다 하드웨어 성능의 차이가 커서, 저사양 기기에서도 원활하게 돌아가도록 세밀하게 최적화해야 합니다. 키보드와 마우스, 게임패드, 터치스크린처럼 플랫폼마다 다른 입력을 모두 지원해야 하고, 화면 크기와 해상도, 조작 방식에 따라 UI와 사용 경험을 다시 설계해야 합니다.

배포 쪽의 과제도 있습니다. Google Play, Apple App Store, Steam, PlayStation, Xbox, Nintendo 같은 플랫폼마다 고유한 기술 요구사항과 콘텐츠 지침, 인증 절차를 지켜야 합니다. 플랫폼마다 생기는 버그가 다를 수 있으므로 모든 플랫폼에서 충분히 품질을 확인(QA)해야 하고, 특히 모바일이나 오래된 콘솔은 메모리와 저장 공간의 제약이 더 엄격합니다.

---

플랫폼마다 성능 맞추기

언리얼 엔진은 기본적으로 여러 플랫폼의 렌더링을 지원하지만, 성능을 제대로 내려면 플랫폼마다의 특성에 맞춰 세밀하게 조정해야 합니다. 같은 레벨이라도 개발용 PC에서 측정한 프레임 시간은 모바일 기기나 콘솔의 프레임 시간을 알려 주지 않기 때문입니다. 아래의 세 플랫폼은 조정하는 방향이 서로 다릅니다. 모바일은 비용 자체를 크게 줄이고, 콘솔은 정해진 하드웨어 하나에 맞추며, PC는 다양한 사양을 위해 플레이어가 고를 수 있는 품질 단계를 둡니다.

모바일

모바일은 PC나 콘솔보다 하드웨어 성능이 낮으므로, 그리기 호출과 텍스처 크기, 이펙트의 비용을 더 엄격하게 제한해야 합니다. 화면에 보이는 삼각형의 수와 제출, 픽셀의 비용은 실제 기기에서 측정해 예산을 정합니다. 모든 모바일 기기에 통하는 고정된 폴리곤 상한은 없습니다. 액터 병합과 HISM 컴포넌트로 그리기 호출을 최대한 줄입니다.

텍스처는 Max Texture Size를 낮게 정하고, ASTC나 ETC2처럼 엔진 버전과 대상 기기가 지원하는 압축 형식을 고르며, 기기마다의 품질과 메모리, 실제 쿠킹 결과를 확인합니다. 재질은 Shader Complexity 뷰 모드로 복잡한 셰이더를 찾아 단순하게 만들고, 불투명 재질을 우선 씁니다. 마스크드와 반투명 재질은 겹친 층마다 다시 셰이딩되므로 화면의 작은 부분에만 아껴 쓰고, 조명 계산이 필요 없는 곳에는 Unlit 재질을 검토합니다.

조명과 그림자는 고른 모바일 렌더링 경로가 지원하는 광원 이동성과 그림자 기능을 먼저 확인합니다. 정적 조명이 알맞은 장면은 굽는 방식을 검토하고, 실시간 조명의 비용은 실제 기기에서 측정합니다. 실시간 그림자는 되도록 줄이거나 품질을 크게 낮춥니다. 화면 공간 반사나 앰비언트 오클루전, 복잡한 블룸 같은 비싼 후처리는 대부분 끄거나 매우 낮은 품질로 정하고, LOD와 컬링 거리를 적극적으로 써서 필요 없는 물체를 그리지 않게 합니다.

프로젝트 설정에서는 Engine의 Rendering에 있는 Mobile HDR과 모바일 렌더링, 안티에일리어싱 설정을 확인합니다. Mobile HDR을 끄면 색 공간과 쓸 수 있는 후처리 기능도 함께 바뀌고, MSAA를 쓸 수 있는지는 렌더링 경로에 따라 다릅니다.

콘솔

콘솔은 PC와 달리 하드웨어 사양이 고정되어 있어서, 특정 콘솔에 맞춰 최적화하기가 비교적 쉽습니다. 각 콘솔에서 목표로 하는 30 FPS나 60 FPS의 프레임과 720p, 1080p, 4K 같은 해상도를 맞추도록 최적화합니다. 콘솔마다 정해진 메모리 한도를 지켜야 하므로, memreport나 언리얼 인사이트로 메모리 사용량을 꼼꼼히 분석합니다. 콘솔 개발 키트에 들어 있는 프로파일링 도구와 엔진의 Stat 명령, ProfileGPU를 함께 쓰고, 로딩 시간이 길어지지 않도록 레벨 스트리밍과 비동기 로딩 같은 에셋 로딩 전략을 다듬습니다.

PC

PC는 저사양부터 고사양까지 하드웨어가 매우 다양합니다. 그래서 스케일러빌리티 프리셋과 설정 파일, 게임 사용자 설정(Game User Settings)을 써서, 플레이어가 게임 안의 옵션 메뉴에서 Low, Medium, High, Epic, Cinematic 같은 그래픽 품질을 직접 고르게 합니다. 이 내용은 환경 설정의 성능 영향 분석에서 다뤘습니다.

렌더링 API는 대상 하드웨어와 필요한 기능에 맞춰 DirectX 12나 Vulkan 같은 RHI를 고릅니다. API의 이름만으로 성능이 좋아진다고 보장하지 말고, 드라이버와 셰이더, 프레임 시간을 비교합니다. 여러 GPU와 CPU의 조합에서 성능을 시험할 수 있도록 게임에 벤치마크 기능을 넣어 두는 것도 좋습니다.

---

입력과 UI를 플랫폼에 맞추기

플랫폼마다 다른 입력 방식과 화면의 특성을 반영해야 합니다. 마우스로는 화면의 아무 곳이나 바로 누를 수 있지만, 게임패드는 포커스를 옮겨 가며 고르고, 터치는 손가락이 화면을 가립니다. 그래서 한 플랫폼에서 편했던 조작과 화면 배치가 다른 플랫폼에서는 쓰기 어려워질 수 있습니다. 아래에서는 입력 방식의 차이와, 그 차이에 맞춰 UI를 설계하는 방법을 나눠 봅니다.

입력 방식

키보드와 마우스는 PC에서 정밀한 조작에 유리합니다. 게임패드는 PC와 콘솔에서 쓰며, 진동과 아날로그 스틱 조작이 있고, UI를 탐색할 때 어느 요소에 포커스가 있는지를 관리하는 것이 중요합니다. 모바일의 터치스크린은 여러 손가락의 터치와 스와이프, 핀치 줌 같은 직관적인 제스처를 쓰며, 버튼의 크기와 간격, 터치했을 때의 반응을 고려해야 합니다.

언리얼 엔진의 향상된 입력은 하나의 입력 액션을 여러 장치의 입력에 연결할 수 있게 만들어져 있어서, 여러 플랫폼의 입력을 관리하기 쉽습니다. 예를 들어 상호작용 액션 하나에 키보드의 E와 게임패드의 버튼, 화면의 터치 버튼을 함께 연결할 수 있습니다.

UI와 사용 경험

해상도와 화면 비율이 다양하므로, UMG 위젯의 앵커(Anchor)와 여백(Padding)을 DPI 배율(DPI Scaling)과 안전 영역(Safe Zone)과 함께 써서 대응합니다. TV는 멀리서 보고, 모바일은 화면 위쪽의 노치(notch) 영역이 있으므로 둘 다 확인합니다. 작은 모바일 화면에서는 한 번에 보여 주는 정보를 줄이고, 큰 PC나 TV 화면에서는 더 많은 정보를 보여 줄 수 있게 설계합니다.

모바일의 터치 환경에서는 버튼이 충분히 크고 간격도 알맞아야 잘못 누르는 일이 줄어듭니다. 작은 화면에서도 글자가 잘 읽히도록 크기와 색, 대비를 조절하고, 게임패드나 키보드로 UI를 탐색할 때 포커스가 옮겨 가는 순서를 분명하게 정합니다.

---

플랫폼마다의 배포와 인증

각 플랫폼에서 게임을 출시하려면 그 플랫폼의 고유한 요구사항과 절차를 따라야 합니다.

Google Play(Android)에서는 개발자 계정을 등록하고, 키스토어로 앱에 서명하며, 스토어의 지금 요구에 맞는 Android 앱 번들(AAB) 같은 배포 파일을 만들고, 앱 정보와 스크린샷을 등록합니다. 버전 관리와 출시는 Google Play Console에서 합니다. Apple App Store(iOS)에서는 Apple Developer Program에 등록하고, 인증서와 프로비저닝 프로필로 앱에 서명하며, IPA 파일을 만들고, 앱 정보와 스크린샷을 등록합니다. 버전 관리와 출시는 App Store Connect에서 합니다.

PC에서 Steam은 Steamworks 파트너 프로그램에 등록하고, SteamPipe로 빌드를 올리고 업데이트를 관리합니다. Steam API 기능을 쓸 때는 그 SDK를 연동하며, 상점 페이지와 도전 과제, 클라우드 저장 같은 Steam 기능을 설정합니다. Epic Games Store는 Epic Developer Portal에서 제품과 스토어 배포를 설정하고, 그 포털에서 빌드를 올리고 관리합니다.

PlayStation, Xbox, Nintendo 같은 콘솔은 각 제조사의 공식 개발자 프로그램에 등록하고 비밀유지협약(NDA)을 맺어야 합니다. 전용 개발 키트(Dev Kit)를 쓰고, 플랫폼 SDK를 통합하며, 엄격한 인증(certification) 절차를 통과해야 합니다. 언리얼 엔진은 각 콘솔의 SDK와 연동해 빌드를 만들지만, 콘솔마다 고유한 빌드 과정과 추가 설정이 필요합니다.

---

여러 플랫폼을 다루는 작업 흐름

여러 플랫폼에 배포할 생각이라면 처음 기획할 때부터 그것을 고려합니다. 모든 플랫폼을 처음부터 지원할지, 어느 플랫폼을 먼저 할지 정하고, 그에 맞춰 게임 디자인과 아트를 설계합니다. 그다음 출시 목표와 콘텐츠의 요구에 따라 기준 플랫폼을 정하고, 공통 콘텐츠가 가장 낮은 지원 사양에서도 성립하는지 확인한 뒤 플랫폼마다 품질을 조정합니다.

플랫폼마다 다르게 할 것은 되도록 데이터로 관리합니다. 기기 프로필(Device Profiles)과 스케일러빌리티 같은 데이터 설정으로 품질의 차이를 다루고, 로직을 나눠야 한다면 블루프린트의 Get Platform Name이나 C++의 PLATFORM_ANDROID 같은 실제 플랫폼 매크로를 씁니다. 이때 플랫폼 분기를 공통 게임 규칙 곳곳에 흩뿌리지 말고, 플랫폼과 맞닿는 부분에 모아 둡니다. 여러 플랫폼의 빌드는 지속적 통합과 배포(CI/CD) 시스템으로 자동화해 패키징과 시험을 효율적으로 하고, 플랫폼마다 저사양, 중사양, 고사양의 여러 기기에서 철저히 QA를 진행합니다.

플랫폼을 고르는 순서

플랫폼은 다음 순서로 정하는 것을 권장합니다. 먼저 수익과 플레이어 기반을 보고 첫 출시 플랫폼을 정하고, 나머지는 뒤에 옮기는 포팅으로 계획합니다. 그다음 게임패드와 터치, 키보드의 입력 차이를 기준으로 UI와 사용 경험의 공통 컴포넌트를 나눕니다. 가장 낮은 사양의 플랫폼에서 안정된 FPS를 먼저 확보한 뒤, 더 높은 사양의 플랫폼으로 품질을 넓혀 갑니다. 각 스토어의 인증 요구사항, 예를 들어 개인정보와 결제, 저장 정책은 거꾸로 기능 요구사항으로 바꿔 미리 반영합니다. 마지막으로 빌드 자동화와 기기별 QA 기준표를 함께 운영해 출시의 위험을 줄입니다.

운영 전에 점검할 것

운영을 시작하기 전에는 다음을 점검합니다. 플랫폼마다 버튼 연결이나 포커스 이동에서 입력이 충돌하는 문제를 빠짐없이 시험했는지, 저사양 기기에서 열이나 메모리 때문에 성능이 떨어질 때의 프레임 저하를 측정했는지, 아이콘과 권한, 개인정보 고지 같은 스토어 인증 항목을 미리 확인했는지, 여러 플랫폼 사이의 저장 데이터 호환 정책, 즉 버전과 변환 방식을 정했는지, 출시 뒤의 핫픽스 절차를 되돌리기까지 포함해 운영 문서로 준비했는지입니다.

공통으로 둘 것과 플랫폼마다 확인할 것

실행 파일 하나를 복사해 여러 플랫폼에 쓰는 것이 아니라, 대상 플랫폼마다의 결과물과 QA 결과를 따로 관리합니다. 스토어와 SDK의 세부 요구는 제출하는 시점의 공식 지침을 확인합니다.

같은 기능을 다른 입력으로 확인하기

예를 들어 문에 상호작용한다는 액션의 의미와 문이 열리는 규칙은 공통으로 두고, PC의 키보드와 게임패드, 모바일의 버튼이 각각 그 액션으로 이어지는지 확인합니다. 키 이름만 바꾸고 끝내지 말고, 게임패드로 버튼까지 포커스를 옮겨 실행할 수 있는지, 터치 영역이 옆 버튼과 겹치지 않는지, 화면 비율이 바뀌어도 안내가 읽히는지 확인합니다. 이 검사는 플랫폼마다의 입력과 UI 연결을 만든 상태에서 하는 것이며, 공통 함수가 있다는 사실만으로 연결까지 완성되지는 않습니다.

---

정리

• 여러 플랫폼에 배포하면 플레이어와 매출이 늘지만, 성능, 입력, UI, 인증, QA, 메모리의 과제가 함께 늘어납니다.
• 모바일은 그리기 호출과 텍스처, 재질, 그림자, 후처리를 실제 기기에서 측정한 예산으로 줄이며, 고정된 폴리곤 상한은 없습니다.
• 콘솔은 고정된 하드웨어의 목표 프레임과 메모리 한도를, PC는 다양한 하드웨어를 위한 스케일러빌리티와 RHI의 선택을 다룹니다.
• 향상된 입력으로 하나의 액션에 여러 장치의 입력을 연결하고, UI는 앵커와 DPI 배율, 안전 영역, 포커스 순서로 플랫폼에 맞춥니다.
• 각 스토어와 콘솔은 등록, 서명, 배포 파일, 인증 절차가 다르며, 제출 시점의 공식 지침을 따릅니다.
• 품질의 차이는 기기 프로필과 스케일러빌리티 같은 데이터로 다루고, 플랫폼 분기는 한곳에 모으며, 플랫폼마다의 결과물과 QA 결과를 따로 관리합니다.

---

연습 문제

1. 수치가 통과했으니 포팅을 마쳤을까

같은 기능을 PC와 모바일에 제공합니다. PC의 목표는 60 FPS이고 측정한 프레임은 15 ms, 모바일의 목표는 30 FPS이고 측정한 프레임은 29 ms입니다. 그런데 모바일에서는 상호작용 버튼을 누르면 옆 버튼의 동작이 실행됩니다. 두 수치만으로 포팅을 마쳤다고 볼 수 있을까요? 무엇을 고치고, 어떤 입력으로 다시 확인해야 할까요?

해설 보기

마쳤다고 볼 수 없습니다. 두 수치는 각각 약 16.67 ms와 33.33 ms의 예산 안에 있지만, 모바일에서는 입력이 다른 동작을 실행하므로 기능의 조건을 통과하지 못했습니다.

터치 영역의 크기와 겹침, 버튼 이벤트의 연결을 조사해 고치고, 실제 모바일 화면에서 각 버튼과 연속 입력, 여러 화면 비율에서 의도한 게임 액션이 실행되는지 다시 확인합니다. 성능도 오래 플레이해 기기가 뜨거워진 상태와 더 복잡한 장면까지 다시 측정해야 합니다. PC에서의 성공이나 짧은 대표 프레임만으로 모바일의 검사를 대신하지 않습니다.

2. 플랫폼 분기가 흩어져 있다

게임 규칙 곳곳에 "모바일이면 이렇게, PC면 저렇게" 하는 플랫폼 분기가 수십 군데 들어가 있습니다. 새로 콘솔을 지원하려니 고칠 곳을 다 찾기 어렵습니다. 어떻게 정리해야 할까요?

해설 보기

품질의 차이처럼 데이터로 다룰 수 있는 것은 기기 프로필과 스케일러빌리티 같은 데이터 설정으로 옮겨, 코드의 분기 없이 플랫폼마다 값만 다르게 합니다.

로직을 정말 나눠야 하는 부분은 입력 연결이나 플랫폼 서비스 호출처럼 플랫폼과 맞닿는 곳에 모아, 공통 게임 규칙은 플랫폼을 몰라도 되게 만듭니다. 그러면 새 플랫폼을 더할 때 그 모아 둔 곳만 고치면 됩니다.

3. 게임패드로 메뉴를 움직일 수 없다

PC에서 마우스로는 잘 동작하던 옵션 메뉴가, 콘솔의 게임패드로는 어느 버튼에도 포커스가 가지 않아 아무것도 고를 수 없습니다. 무엇을 확인해야 할까요?

해설 보기

마우스는 원하는 곳을 직접 클릭하므로 포커스가 필요 없지만, 게임패드는 포커스를 옮겨 가며 고르므로 메뉴가 열릴 때 처음 포커스를 받을 위젯과, 방향 입력에 따라 포커스가 옮겨 갈 순서가 정해져 있어야 합니다.

메뉴가 열릴 때 첫 버튼에 포커스를 주는지, 각 버튼이 포커스를 받을 수 있게 설정되어 있는지, 위아래와 좌우의 이동 순서가 분명한지 확인하고, 실제 게임패드로 메뉴의 모든 항목을 고를 수 있는지 시험합니다.

여러 플랫폼의 기기 설정은 Epic의 기기 프로필 안내에서 확인할 수 있습니다.

이것으로 10장과 언리얼 기본 트랙을 마칩니다. 10장에서는 배포 직전에 프로젝트와 플랫폼, 코드, 콘텐츠를 점검하는 방법, 빌드 구성과 쿠킹, 패키징의 단계와 오류를 읽는 방법, 출시한 뒤 패치와 크래시 보고, 운영 지표로 게임을 유지보수하는 방법, 버전 관리와 pak 기반 패치, 사용자 피드백을 재현할 수 있는 기록으로 바꿔 개선하는 방법, 그리고 여러 플랫폼에 배포할 때의 차이까지 배포와 유지보수의 흐름을 다뤘습니다. 이 트랙 전체로는 엔진을 설치하고 에디터를 익히는 데서 시작해, 에셋과 레벨, 조명, 날씨와 시간, 물리, 환경 상호작용을 만들고, 그 성능을 측정하며 다듬은 뒤 배포하고 운영하는 데까지 언리얼 엔진으로 환경을 만드는 전체 과정을 따라왔습니다. 처음부터 다시 훑어보고 싶다면 언리얼 기본 교재의 목차로 돌아가세요.