크로스 플랫폼 호환성 기본 이해
PC·콘솔·모바일·VR의 GPU·메모리·렌더링 차이를 반영해 플랫폼별 스케일러빌리티와 효과 예산을 설계합니다.
요즘 게임은 플랫폼 하나만 겨냥하기보다 PC와 콘솔, 모바일, VR과 AR을 함께 고려하는 경우가 많습니다. 그런데 개발용 PC에서 멋지게 보이던 폭발이 모바일에서는 프레임을 반으로 떨어뜨리고, VR에서는 한쪽 눈에서만 잘려 보이기도 합니다. 그래서 나이아가라 효과도 플랫폼마다 다른 하드웨어의 특성과 성능의 제약을 반영해 설계해야 합니다. 크로스 플랫폼 호환성(cross-platform compatibility)을 이해해야 모든 대상 플랫폼에서 의도한 화면과 안정적인 성능을 함께 얻을 수 있습니다. 이 글에서는 플랫폼마다의 차이를 살펴보고, 스케일러빌리티와 머티리얼, 입자 수, 기능 끄기, 시험의 전략을 정리한 뒤, 예산표를 만들어 부분 예산과 전체 프레임을 함께 확인해 봅니다.
플랫폼마다 다른 하드웨어와 API
플랫폼마다 CPU와 GPU, 메모리의 사양이 다르고, 쓸 수 있는 그래픽스 API(Application Programming Interface)도 다릅니다. 이런 차이가 나이아가라 효과의 동작과 성능에 바로 영향을 줍니다.
모바일(iOS, Android)은 GPU 성능이 낮고 VRAM이 적으며, CPU 클럭이 낮고 발열 문제도 있습니다. 그래서 복잡한 셰이더나 대량의 입자, 복잡한 물리 시뮬레이션, 실시간 그림자, Light Renderer가 성능을 떨어뜨릴 가능성이 크고, 특히 Translucent의 오버드로우에 약합니다. 주로 쓰는 API는 Vulkan과 Metal이며, OpenGL ES는 예전 기기를 위한 것입니다.
콘솔(PlayStation, Xbox, Switch)은 기종마다 하드웨어가 정해져 있지만, 세대와 휴대 모드, 해상도에 따라 예산이 달라집니다. PC와 성능을 단순히 줄 세우기보다 지원하는 기종마다 실제로 재어 봐야 합니다. PC만큼 자유롭지는 않아도 충분히 풍부한 효과를 만들 수 있으며, 메모리 사용량과 GPU 최적화는 여전히 중요합니다. 쓰는 API는 콘솔 공급자의 SDK와 엔진의 RHI 지원에 따르며, 모든 콘솔이 DirectX나 Vulkan, Metal을 공통으로 쓰는 것은 아닙니다.
PC는 하드웨어 사양이 아주 다양합니다. 고사양 PC도 RHI와 드라이버, 렌더링 방식, 프레임 예산의 제약이 있고, 오래되거나 사양이 낮은 PC까지 고려해야 한다면 최적화가 꼭 필요합니다. 가장 자유로운 플랫폼이지만 넓은 사용자층을 생각해 스케일러빌리티(Scalability)로 저사양 PC에서도 부드럽게 동작하게 해야 합니다. 주로 DirectX와 Vulkan을 씁니다.
VR과 AR은 기기의 목표 주사율, 예를 들어 72Hz나 90Hz, 120Hz에 맞는 안정적인 프레임 시간이 필요합니다. 두 눈을 따로 그리므로 비용이 늘지만, 멀티뷰나 인스턴스드 스테레오, 작업의 공유 덕분에 모든 비용이 정확히 두 배가 되는 것은 아닙니다. 오버드로우와 복잡한 셰이더, 대량의 입자, 고해상도 텍스처에 아주 민감하고, 시차(parallax)를 고려한 입자의 위치와 깊이감이 중요합니다. 또 입자가 플레이어의 눈 가까이에서 갑자기 나타나거나 사라지면 멀미를 일으킬 수 있으므로 조심합니다.
여러 플랫폼에 맞추는 전략
스케일러빌리티 쓰기
먼저 엔진의 Effects 품질과 나이아가라의 품질 수준, Device Profile과 Platform Set을 구분해 목표 기기마다 규칙을 정합니다. 여러 효과가 함께 쓰는 나이아가라 이펙트 타입에서는 거리와 가시성, 인스턴스 수, 예산에 따른 컬링을 정하고, 시스템마다 필요한 덮어쓰기를 둡니다. 이미터에서는 플랫폼과 품질 단계별 포함 여부, Spawn Count Scale 같은 설정을 씁니다. 거리에 따라 생성률이나 수명을 연속적으로 바꾸려면 실제 거리 입력을 그 모듈에 연결하는 식으로 따로 구성해야 하며, 모든 모듈이 저절로 거리 LOD를 갖는 것은 아닙니다.
머티리얼 다듬기
대부분의 입자는 Unlit 셰이딩 모델을 쓰는 것이 가장 효율적입니다. 조명 계산이 필요 없어 GPU의 부담이 크게 줄기 때문입니다. 블렌드 모드는 Additive와 Translucent 모두 겹친 픽셀을 여러 번 칠할 수 있으므로, 원하는 표현에 맞는 모드를 고르고 스프라이트의 면적과 겹침, 셰이더의 비용을 줄입니다. 알파를 낮추는 것만으로 그리는 비용이 사라지지는 않습니다.
텍스처는 플랫폼의 메모리 제약에 맞게 해상도를 알맞게 낮추고, 대상 플랫폼의 압축 형식과 밉, 스트리밍 예산을 확인합니다. 스트리밍을 무조건 끄면 늘 메모리에 남는 양이 늘어날 수 있습니다. 머티리얼 그래프에서는 필요 없는 계산이나 복잡한 함수 호출을 피해 셰이더의 명령 수를 줄입니다.
입자 수와 계산량 관리
생성량에는 상한을 설계합니다. Spawn Rate와 버스트, 수명, 동시 시스템 수를 제한하는데, 일정하게 계속 만드는 경우 정상 상태의 입자 수는 대략 생성률 × 수명으로 예상할 수 있고, 버스트와 수명의 분포는 따로 더합니다. 수명은 되도록 짧게 해 동시에 살아 있는 입자를 줄입니다.
Collision은 비용이 크므로 꼭 필요할 때만 쓰고, 지원되는 CPU 트레이스나 GPU의 Scene Depth, Distance Fields 방식과 대상 기기에서의 비용을 확인합니다. 부딪히면 없애야 하는지 정하고, CPU 트레이스를 언제나 더 싼 대안으로 여기지 않습니다. Curl Noise Force나 복잡한 데이터 인터페이스, 틱마다 계산이 많은 직접 만든 스크립트도 성능에 큰 영향을 줄 수 있으므로, 조심해서 쓰거나 더 단순한 대안을 찾습니다.
플랫폼에 따라 기능 끄기
모바일이나 낮은 사양의 콘솔에서는 Light Renderer를 끄는 것이 일반적입니다. 동적인 조명을 만드는 비용이 크기 때문입니다. 입자가 그림자를 드리우는 Cast Shadows도 성능에 큰 영향을 주므로 모바일이나 저사양 플랫폼에서는 끕니다. 피사계 심도(Depth of Field)나 모션 블러 같은 후처리도 효과에 영향을 주므로 플랫폼의 성능을 생각해 조절하거나 끕니다.
실제 기기에서 시험하기
개발용 PC에서만 효과를 확인하지 말고, 목표하는 모든 플랫폼에서 효과가 어떻게 보이고 성능이 어떤지 주기적으로 시험합니다. 언리얼 엔진의 stat 명령과 Unreal Insights, GPU 프로파일러를 기본으로 쓰고, 플랫폼 SDK가 제공하는 CPU와 GPU 도구도 함께 확인합니다. 에디터에서 잰 값과 실제 기기의 패키지에서 잰 결과는 구분합니다.
플랫폼 예산과 스케일러빌리티의 기준선
아래 수치는 예산표를 만드는 방법을 보여 주는 가상의 예이며, Epic이 권장하는 값이나 실제로 잰 결과가 아닙니다. 목표 기기와 해상도, 장면, 품질 단계, 그리고 전체 프레임 예산에서 효과(FX)에 나눠 줄 몫을 정한 뒤 실제 값으로 바꿉니다.
| 플랫폼 | 예시 프레임 목표 | 나이아가라 GPU 예산(프레임당) | 기본 Spawn Count Scale |
|---|---|---|---|
| 모바일 | 30–60FPS | 1.0–1.5ms | 0.4–0.6 |
| 콘솔 | 60FPS | 2.0–2.5ms | 0.8–1.0 |
| PC | 60–120FPS | 2.5–3.0ms | 1.0(옵션 메뉴로 올리거나 내림) |
| VR | 90FPS 이상 | 0.8–1.2ms | 0.5–0.7 |
예산을 넘으면 측정으로 찾은 병목에 맞춰 조절합니다. 시뮬레이션이 비싸면 생성량과 모듈을, 픽셀의 비용이 크면 화면 면적과 겹침, 머티리얼을, 인스턴스의 비용이 크면 시스템의 수와 풀링, 컬링을 먼저 비교합니다.
품질 단계가 달라져도 공격의 방향과 위험한 범위, 발동 시점 같은 게임의 정보는 지켜야 합니다. 대표 장면의 CPU와 GPU 시간, 메모리, 오래 실행한 뒤의 발열을 함께 기록하고, 품질이 바뀔 때 효과가 갑자기 사라지거나 VR에서 한쪽 눈에서만 잘리는 일이 없는지 확인합니다.
부분 예산과 전체 프레임 함께 확인하기
예산표를 숫자로 확인해 봅니다. 생성률 80개/초와 수명 1.5초가 일정하고, 실제 생성률에 Spawn Count Scale 0.5를 곱했다고 합시다. 그러면 정상 상태에서 계속 만들어지는 입자는 80 × 0.5 × 1.5 = 60개입니다. 아직 모두 살아 있는 버스트 20개를 더하면 그 순간 인스턴스 하나는 80개이고, 같은 인스턴스가 세 개라면 80 × 3 = 240개입니다. 다른 버스트나 수명의 분포, Kill, 컬링이 있다면 그 조건은 따로 계산합니다.
이번에는 시간 예산입니다. 90FPS 기기의 전체 프레임 예산은 1000 ÷ 90 ≈ 11.11ms입니다. 효과에 1.2ms를 나눠 주었고, 주어진 기록이 나이아가라 GPU 1.0ms, Frame 12ms라면, 효과의 예산은 지켰지만 전체 프레임 시간은 90FPS의 목표를 넘습니다. 같은 프레임의 나이아가라 시간과 전체 GPU, Frame을 서로 따로인 작업처럼 모두 더해 두 번 계산하지 않습니다. 병목과 재는 범위를 대조한 뒤 다음에 무엇을 바꿀지 정합니다.
정리
- 모바일과 콘솔, PC, VR은 하드웨어와 그래픽스 API, 목표 주사율이 서로 달라, 같은 효과도 비용과 모습이 달라집니다.
- 스케일러빌리티는 엔진의 Effects 품질과 나이아가라 품질 수준, Device Profile, Platform Set, 이펙트 타입을 구분해 직접 설계합니다.
- 여러 플랫폼에서는
Unlit과 알맞은 블렌드 모드, 텍스처 예산, 생성량의 상한, 조심스러운 충돌과 노이즈 사용으로 비용을 줄입니다. - 저사양에서는
Light Renderer와 그림자, 무거운 후처리를 끄되, 공격 방향이나 위험 범위 같은 게임 정보는 다른 방법으로 지킵니다. - 효과의 부분 예산을 지키는 것과 전체 프레임 예산을 지키는 것은 다르므로, 실제 기기에서 둘을 함께 확인합니다.
연습 문제
1. 네 인스턴스의 입자와 120FPS 목표
생성률 60개/초, Scale 0.5, 수명 2초이고, 인스턴스마다 살아 있는 버스트가 10개, 같은 인스턴스가 네 개입니다. 그 순간 전체 입자 수를 구해 보세요. 목표가 120FPS이고 나이아가라 0.9ms가 효과 예산 1.0ms 안이며 Frame이 8.5ms라면 전체 목표도 통과했을까요? 낮은 품질 단계에서 경고 범위를 나타내는 입자를 모두 없애도 될까요?
해설 보기
인스턴스 하나에서 계속 만들어지는 입자는 60 × 0.5 × 2 = 60개이고, 버스트를 더하면 70개, 네 개를 합치면 70 × 4 = 280개입니다.
120FPS의 전체 예산은 1000 ÷ 120 ≈ 8.33ms이므로, Frame 8.5ms는 이를 넘습니다. 효과의 부분 예산을 통과했다고 전체 목표를 통과한 것은 아닙니다. 또 낮은 품질에서도 위험한 범위와 방향, 발동 시점은 비용이 적은 다른 표현으로 전해야 하며, 필요한 게임 정보를 없애는 것으로 성능을 통과하는 것은 대신할 수 없습니다. 이 수치와 기록은 연습을 위해 정한 조건이며, 기기에서 잰 값이나 권장 예산이 아닙니다.
2. 모바일에서만 끊기는 연기
PC에서는 부드럽던 연기 효과가 모바일에서만 심하게 끊깁니다. 입자 수는 많지 않습니다. 무엇을 먼저 의심하고 어떻게 줄이면 좋을까요?
해설 보기
입자 수가 많지 않다면, 모바일이 약한 반투명 오버드로우를 먼저 의심합니다. 연기 스프라이트가 크고 여러 겹으로 겹치면 같은 픽셀을 여러 번 칠해 GPU 비용이 크게 늘어납니다.
스프라이트의 크기와 겹침을 줄이고, 머티리얼의 셰이더를 단순하게 하며, 모바일용 품질 단계에서 생성량을 줄이거나 컬링을 강하게 둡니다. 바꾼 뒤에는 실제 모바일 기기의 패키지에서 다시 잽니다.
3. VR에서 눈앞에 나타나는 불꽃
VR에서 캐릭터 가까이 생기는 불꽃이 갑자기 눈앞에 나타났다 사라져 어지럽다는 의견이 있습니다. 어떻게 다듬으면 좋을까요?
해설 보기
입자가 눈 가까이에서 갑자기 나타나거나 사라지면 멀미를 일으킬 수 있으므로, 생겨나고 사라질 때 크기나 알파를 서서히 바꿔 부드럽게 등장하고 퇴장하게 합니다. 카메라 가까이의 입자는 페이드하거나 생기지 않게 하는 방법도 검토합니다.
또 두 눈에서 깊이가 다르게 보이도록 입자의 위치와 깊이감을 확인하고, 품질 단계가 바뀔 때 한쪽 눈에서만 잘리는 일이 없는지도 봅니다.
여러 플랫폼에 공통으로 적용할 정책은 Epic의 나이아가라 스케일러빌리티와 권장 사항을 참고하되, 지원되는 기능과 실제 예산은 목표 기기에서 확인합니다.
이것으로 10장과 언리얼 나이아가라 트랙을 마칩니다. 10장에서는 나이아가라에 영향을 주는 프로젝트 설정과 에셋의 규칙에서 시작해, 버전 관리와 디버깅, 참조를 확인하며 에셋을 정리하는 방법, 그리고 여러 플랫폼에 맞춰 효과의 예산을 나누는 방법까지 프로젝트를 꾸려 가는 방법을 살펴봤습니다. 이 트랙 전체로는 입자의 생성과 소멸에서 시작해 모듈과 데이터, 스크립트, 렌더링, 충돌과 물리, 블루프린트 연동, 실전 효과 제작, 프로젝트 관리까지 나이아가라로 효과를 만들고 다루는 흐름을 이어 왔습니다. 처음부터 다시 훑어보고 싶다면 언리얼 나이아가라 교재의 목차로 돌아가세요.