플랫폼별 고려: 모바일/PC/콘솔/VR

on

유니티 플랫폼별 고려사항: 모바일 · PC · 콘솔 · VR의 설계 전략

목표: 모든 게임은 “어디서 실행되는가”에 따라 기술적 전략이 달라집니다. 본 장에서는 모바일, PC, 콘솔, VR 네 가지 대표 플랫폼의 특성과 제약을 분석하고, 각 환경에서 최적의 퍼포먼스와 UX를 구현하기 위한 유니티 설계 원칙을 다룹니다.

1. 모바일 (Android / iOS)

모바일 플랫폼은 가장 접근성이 높지만, 동시에 가장 제약이 많은 환경입니다. CPU, GPU, 메모리, 발열, 배터리 — 모든 리소스가 제한적이므로, “필요한 만큼만 계산하는 게임”이 되어야 합니다.

1.1 최적화 전략

  • 📦 드로우콜 최소화: SpriteAtlas 또는 Texture Atlas 사용.
  • 🔄 오브젝트 풀링(Object Pooling): Instantiate/Destroy 반복 방지.
  • 🧠 LOD(Level of Detail): 원거리 모델은 단순화된 버전으로 교체.
  • 🪶 압축 포맷: ASTC/ETC2 텍스처, AAC 오디오 활용.
  • 🎯 UI Canvas 분리: 갱신이 잦은 UI와 정적 UI를 나눠 리렌더링 최소화.

1.2 해상도와 디바이스 대응

  • Canvas Scaler를 “Scale with Screen Size”로 설정.
  • 비율(Aspect Ratio)에 따라 UI 앵커 고정.
  • Screen.dpi 값을 기반으로 터치 감도 보정.

1.3 플랫폼별 코드 분기

#if UNITY_ANDROID Debug.Log("Android 빌드 환경"); #elif UNITY_IOS Debug.Log("iOS 빌드 환경"); #endif
⚙️ Tip: 모바일 디바이스 테스트는 에디터 시뮬레이션이 아닌, 실제 단말(특히 저가형)에서 반드시 진행해야 합니다. 성능 병목은 CPU가 아니라 GPU 스로틀링에서 발생하는 경우가 많습니다.

2. PC (Windows / macOS / Linux)

PC는 하드웨어 스펙이 다양하지만, 상대적으로 높은 자원을 제공합니다. 따라서 모바일 대비 비주얼 품질 향상과 입력의 정밀도에 초점을 맞춰야 합니다.

2.1 품질 세분화

유니티의 Quality Settings에서 플랫폼별 그래픽 옵션을 구분할 수 있습니다.

  • Shadow Resolution / Anti-aliasing / Anisotropic Textures 조정.
  • Post-processing Volume을 프로파일 단위로 분리.
  • GPU에 따른 동적 품질 설정 (예: RTX 시 DLSS 사용).

2.2 입력 처리

PC에서는 키보드·마우스·패드 등 입력 장치가 다양합니다. New Input System을 활용해 디바이스 독립적으로 설계합니다.

public class InputExample : MonoBehaviour { private PlayerInput input; void Awake() { input = new PlayerInput(); } void Update() { Vector2 move = input.Gameplay.Move.ReadValue(); Debug.Log("입력값: " + move); } }

2.3 멀티해상도 및 윈도우 모드

Screen.SetResolution(1920, 1080, FullScreenMode.Windowed);

PC는 프레임 제한과 VSync 설정을 통해 GPU 부하를 제어해야 합니다.

💡 Tip: 고사양 PC에서도 렌더링 병목이 발생할 수 있습니다. GPU보다는 CPU → GPU 전송 파이프라인(드로우콜 과다)이 원인인 경우가 많습니다.

3. 콘솔 (PlayStation / Xbox / Nintendo Switch)

콘솔은 폐쇄적 플랫폼이지만, 성능과 최적화 일관성이 뛰어납니다. 대신 개발자 인증 절차와 전용 SDK를 반드시 거쳐야 하며, 유니티는 각 콘솔 벤더와 공식 통합된 빌드 파이프라인을 제공합니다.

3.1 콘솔 개발 시 유의점

  • 🔒 NDA(비밀 유지 계약) 체결 후 SDK 접근 가능.
  • 🎮 입력 디바이스: DualSense, Xbox Controller, Joy-Con 등 전용 API 사용.
  • 🧩 빌드 타깃 변경은 전용 Unity Build Target 필요.

3.2 메모리 및 파일 구조

콘솔의 메모리는 고정되어 있으며, 초과 시 즉시 크래시가 발생합니다. Addressables 또는 AssetBundle을 통해 스트리밍 로드 구조를 설계해야 합니다.

3.3 인증 (Submission) 준비

  • FPS, 해상도, UI 가독성 검증.
  • 저장 데이터 무결성 (세이브 파일 손상 방지).
  • 플랫폼 정책 준수 (로고, 종료 절차, 언어 지역화 등).
⚙️ Tip: 콘솔은 최적화가 필수입니다. QA 단계에서 “Frame Pacing” 문제 — 즉, 프레임 간 간격 불균등 — 이 감지되면 인증이 거부될 수 있습니다.

4. VR / AR (Meta Quest, Pico, Vision Pro 등)

VR 플랫폼은 전통적인 게임보다 지각(Perception)과 지연 시간(Latency)에 민감합니다. 1프레임(16ms)의 지연도 멀미를 유발할 수 있으므로, 프레임 유지가 최우선 목표입니다.

4.1 렌더링 최적화

  • Foveated Rendering (시선 중심 고해상도 렌더링).
  • Multi-View 또는 Single-Pass Instanced Rendering 사용.
  • Post-processing 효과 최소화 (Bloom, DOF, Motion Blur 비활성화).

4.2 VR 인터랙션

XR Interaction Toolkit을 사용하여 입력, 트래킹, 상호작용을 관리합니다.

using UnityEngine.XR.Interaction.Toolkit; public class GrabObject : XRGrabInteractable { protected override void OnSelectEntered(SelectEnterEventArgs args) { base.OnSelectEntered(args); Debug.Log("오브젝트 잡힘!"); } }

4.3 성능 기준

  • Meta Quest 2 기준: 72fps 이상 유지.
  • Late Latching과 TimeWarp 활성화.
  • 고정 해상도 렌더링 대신 Dynamic Resolution 사용.
💡 Tip: VR에서는 “보이는 프레임”보다 “예측된 프레임”이 중요합니다. Asynchronous TimeWarp을 통해 사용자의 머리 움직임을 보정해야 멀미를 방지할 수 있습니다.

5. 크로스플랫폼 전략 (Cross-Platform Design)

여러 플랫폼에 동시에 대응하는 것은 기술적 복잡도를 높이지만, 유지보수 비용 절감의 핵심입니다.

5.1 공통 코드 구조

  • 플랫폼 분기를 Platform Service Layer로 캡슐화.
  • 입력, 저장, 로딩, 결제 등 공용 API 설계.
public interface IPlatformService { void SaveData(string key, string value); string LoadData(string key); }

이 구조를 사용하면 Android, iOS, PC별로 서로 다른 구현을 주입할 수 있습니다.

5.2 공통 에셋 전략

  • URP를 통한 통합 렌더링.
  • Addressables 그룹 분리: “Mobile / Desktop / VR”.
  • 플랫폼별 압축 및 해상도 버전 관리.

정리: 플랫폼은 기술이 아니라 ‘맥락’이다

모바일은 “가볍게”, PC는 “자유롭게”, 콘솔은 “안정적으로”, VR은 “몰입감 있게” 설계해야 합니다. 각 플랫폼은 단순히 다른 장치가 아니라, 다른 사용 맥락과 기대치를 가진 세계입니다.

즉, 플랫폼 대응의 본질은 “성능”이 아니라 “경험의 일관성”을 유지하는 일입니다.

✅ 다음 학습 추천:

Comments

Post a Comment