환경 설정의 성능 영향 분석
후처리·그림자·광원·안개·반사와 Nanite·Lumen·World Partition을 규모와 플랫폼 예산에 맞춰 선택합니다.
에셋과 레벨 구조를 정리했다면, 다음 병목은 레벨 전체에 걸리는 환경 설정에서 자주 생깁니다. 후처리, 그림자, 광원, 안개, 반사 같은 환경 설정은 화면의 품질을 크게 좌우하는 동시에 렌더링 비용도 크게 바꿉니다. 같은 맵이라도 어떤 옵션을 켜고 끄느냐에 따라 프레임의 안정성이 완전히 달라질 수 있습니다.
이 글에서는 환경 설정마다 성능에 어떤 영향을 주는지, 무엇으로 측정하고 어떤 설정이 실제 계산량을 바꾸는지를 차례로 정리합니다. 그다음 목표 FPS의 예산과 품질 기준을 함께 놓고 어느 설정을 남길지 판단하는 방법을 계산 예와 함께 익히고, 마지막으로 나나이트(Nanite), 루멘(Lumen), 월드 파티션(World Partition), 가상 섀도 맵(VSM) 같은 기능을 프로젝트의 규모와 플랫폼에 맞춰 고르는 기준을 다룹니다.
환경 설정과 성능의 관계
언리얼 엔진의 환경 설정은 그림자, 조명, 후처리처럼 서로 다른 렌더링 단계와 메모리에 영향을 주며, 화면 품질과 성능은 서로 맞바꾸는(trade-off) 관계에 있습니다. 해상도나 샘플 수, 보이는 범위를 늘리면 비용이 커질 수 있는데, 얼마나 커지는지는 효과와 장면마다 다릅니다.
그래서 PC, 콘솔, 모바일처럼 플랫폼마다의 하드웨어 성능을 생각해 품질 목표를 따로 정해야 합니다. 또 어떤 환경 효과는 게임의 분위기에 꼭 필요하고, 어떤 효과는 성능을 위해 줄여도 되는지를 판단해야 합니다.
설정마다의 성능 영향
아래에서는 후처리 볼륨, 디렉셔널 라이트, 스카이 라이트, 지수형 높이 안개 같은 액터로 조정하는 주요 환경 설정을 살펴봅니다. 이 설정들은 앞 장들에서 하나씩 다뤘으므로, 여기서는 비용의 관점에서 다시 정리합니다.
후처리
후처리는 렌더링한 최종 이미지에 블룸, 앰비언트 오클루전, 화면 공간 반사 같은 효과를 더하는 단계입니다. 주요 GPU 비용 후보이며, 화면 해상도와 효과의 구현에 따라 비용이 달라집니다. 다만 모든 장면에서 가장 큰 병목인 것은 아닙니다. ProfileGPU의 PostProcess 항목으로 자세한 비용을 확인합니다.
쓰지 않거나 눈에 띄지 않는 후처리 효과는 끕니다. 남기는 효과는 품질과 해상도, 샘플 수처럼 계산량을 바꾸는 설정부터 비교합니다. Intensity나 앰비언트 오클루전의 Power처럼 겉모습을 바꾸는 값만 낮추면, 같은 단계가 계속 실행될 수 있기 때문입니다.
효과마다 보면 다음과 같습니다. 블룸의 Intensity와 Threshold는 겉모습을 맞추는 값이므로, 비용을 줄였는지는 블룸의 방식과 품질을 바꾸거나 끄기 전후를 측정해 판단합니다. 피사계 심도(Depth of Field)의 초점 거리와 조리개는 연출을 정하는 값이라, 비용은 피사계 심도의 품질과 해상도, 흐려지는 영역을 함께 측정하며, 초점 거리를 바꾸는 것 자체를 최적화로 보지 않습니다. 렌즈 플레어는 필요 없다면 끕니다.
그림자
그림자는 공간감과 깊이감을 주지만, 광원 계산과 함께 GPU 부담의 주요 원인입니다. 특히 Movable 광원의 실시간 그림자는 매 프레임 섀도 맵을 그려야 하므로 비용이 큽니다. ProfileGPU나 GPU 트레이스에서 지금 쓰는 그림자 방식의 단계 시간을 확인합니다.
사전 계산 조명을 쓰는 프로젝트라면 Static이나 Stationary를 검토할 수 있습니다. 다만 Stationary에도 실시간 그림자의 비용이 남고, 루멘 글로벌 일루미네이션은 정적 라이트맵의 간접광을 쓰지 않습니다. 그림자의 해상도는 방식마다 다르게 다룹니다. 기존 섀도 맵은 광원마다의 해상도 설정을, 가상 섀도 맵은 그 방식의 품질과 페이지, 캐시 지표를 보며, 설정이 어디까지 적용되는지와 실제 비용을 먼저 확인합니다.
캐스케이드 섀도 맵을 쓰는 디렉셔널 라이트라면 Dynamic Shadow Distance로 실시간 그림자의 거리를 조절하고, 그 거리 밖의 그림자를 어떤 방식으로 처리하는지도 함께 확인합니다. 캐스케이드 수를 줄여 비용과 단계가 바뀌는 지점의 품질을 비교할 수도 있는데, 이 설정은 가상 섀도 맵에는 그대로 적용되지 않습니다. 엔진 스케일러빌리티의 그림자 품질과 프로젝트의 그림자 방식도 함께 확인합니다. 자세한 내용은 그림자 옵션과 성능 최적화에서 다뤘습니다.
광원
Movable 광원이 많고, 광원마다 영향을 주는 범위인 Attenuation Radius가 넓을수록 GPU 부담이 커집니다. 픽셀 하나에 영향을 주는 광원이 많아질수록 그 픽셀의 계산이 늘어나기 때문입니다. Light Complexity 뷰 모드로 표면에 영향을 주는 정적이지 않은 광원의 수를 보고, 실제 시간은 ProfileGPU의 조명 단계에서 확인합니다.
줄이는 방법은 프로젝트의 라이트맵 경로나 실시간 조명 경로에 맞는 이동성을 고르고, 실시간 광원의 수를 줄이며, Attenuation Radius를 필요한 범위만큼만 작게 정하는 것입니다. 빛의 모양을 재질로 바꾸는 라이트 함수(Light Function)나, 실제 조명 기구의 빛 분포를 담은 IES 프로필(IES Profile) 같은 효과도 계산 비용이 있으므로 신중하게 씁니다.
안개
지수형 높이 안개는 기본적으로 비교적 효율적이지만, 볼류메트릭 안개는 GPU 부담이 매우 큽니다. ProfileGPU에서 볼류메트릭 안개나 높이 안개와 관련된 비용을 확인합니다. 대부분은 지수형 높이 안개로 충분하므로, 볼류메트릭 안개는 꼭 필요할 때만 켭니다.
볼류메트릭 안개를 켠다면, 그림자 스케일러빌리티 단계가 정하는 볼륨의 해상도를 비교합니다. Scattering Distribution과 Extinction Scale은 빛이 흩어지는 방향과 밀도를 정하는 값이지 품질 단계가 아니라는 점에 주의합니다. 계산하는 범위는 View Distance로 정하고, r.VolumetricFog.GridSizeZ 같은 격자 설정은 품질과 비용을 측정하며 조절합니다. 거리를 바꾸는 것과 해상도를 바꾸는 것은 서로 다른 조정입니다.
반사
화면 공간 반사(SSR)는 GPU 비용이 큰 편이고, 반사 캡처 액터는 에디터에서 미리 캡처해 두어야 하지만 실행 중의 비용은 적습니다. ProfileGPU에서 SSR이나 반사 캡처와 관련된 비용을 확인합니다.
움직이지 않는 환경의 반사에는 Box Reflection Capture나 Sphere Reflection Capture로 반사 정보를 미리 캡처해 씁니다. SSR을 쓴다면, 후처리 볼륨의 Screen Space Reflections에서 Intensity는 반사가 겉모습에 더해지는 정도를 조절하는 값이므로, 값을 낮췄다고 그 단계의 계산이 줄었다고 판단하지 않습니다. Max Roughness를 낮추면 더 매끄러운 표면에만 SSR이 적용되도록 범위를 줄일 수 있고, Quality도 함께 비교하며, 실제로 비용이 줄었는지는 같은 장면의 단계 시간으로 확인합니다.
물 표면처럼 매우 정확한 반사가 필요할 때 쓰는 평면 반사(Planar Reflections)는, 반사 방향에서 장면을 한 번 더 그리므로 비용이 큽니다. 그렇다고 전체 프레임 시간이 꼭 두 배가 되는 것은 아니지만, 쓰는 곳을 아주 제한하거나 끄는 것을 검토합니다.
목표 FPS의 예산과 품질 함께 보기
한 프레임에 쓸 수 있는 시간은 1000 ÷ 목표 FPS로 계산합니다. 60 FPS는 약 16.7 ms, 45 FPS는 약 22.2 ms, 30 FPS는 약 33.3 ms입니다. 다만 이 수치만으로 조명이나 안개의 프리셋을 정하지는 않습니다. CPU와 GPU가 겹쳐서 진행된다는 점을 생각해, 각 축이 병목인지와 얼마나 여유가 있는지를 측정합니다. 실내와 야외, 전투처럼 대표적인 장면의 캡처를 저장해 두고, 효과마다의 비용과 낮은 사양에서의 프레임 분포를 함께 기록합니다.
그리고 성능의 기준과 품질의 기준을 함께 통과해야 합니다. 예를 들어 60 FPS가 목표인 같은 장치와 맵, 카메라 구간에서, 변경 A의 대표 프레임 시간은 15.8 ms이고 변경 B는 16.4 ms라고 해 봅시다. 다른 프레임들도 모두 예산 안에 있습니다. 그런데 A에서는 상호작용 버튼의 글자가 배경에 묻혀 읽히지 않고, B에서는 읽힙니다.
이 기록에서는 B를 남깁니다. 둘 다 약 16.67 ms의 예산 안에 있지만, A는 플레이에 필요한 가독성의 기준을 통과하지 못하기 때문입니다. 즉 더 빠른 값 하나만으로는 선택의 이유가 충분하지 않습니다. 다만 B의 여유는 16.67 - 16.4 = 약 0.27 ms로 작으므로, 더 복잡한 대표 장면과 최소 사양에서도 프레임 분포를 확인해야 합니다. 한 장면의 대표값만으로 모든 장치에서 통과했다고 넓혀 말하지 않습니다.
전체 품질을 다루는 설정
게임 전체의 품질과 성능은 Edit 메뉴의 Project Settings에서 Engine의 Rendering 같은 항목으로 조정합니다. 프레임 제한, 보이는 거리의 배율, 안티에일리어싱 방식, 모션 블러 같은 설정이 여기에 있습니다.
엔진 스케일러빌리티(Scalability)는 Low, Medium, High, Epic, Cinematic 같은 미리 정해진 품질 단계를 제공합니다. 이 단계는 sg.ResolutionQuality나 sg.ViewDistanceQuality 같은 콘솔 명령으로도 조절할 수 있어서, 게임 안의 옵션 메뉴에서 플레이어가 그래픽 품질을 고르게 만들 때 씁니다. 그리고 개발하는 내내 Stat 명령과 ProfileGPU로 성능을 지켜보며, 바꾼 것이 성능에 어떤 영향을 주는지 늘 확인합니다.
나나이트, 루멘, 월드 파티션 고르기
품질을 높이는 기능일수록 GPU와 CPU의 비용이 함께 늘어날 수 있습니다. 그래서 최신 기능인지, 프로젝트가 큰지만 보고 쓸지를 정하지 않습니다. 각 기능을 도입하기 전에는 다음 조건을 확인합니다.
| 기능 | 도입하기 전에 확인할 조건 |
|---|---|
| 나나이트 | 대상 RHI와 플랫폼, 메시 기능의 지원, 재질과 픽셀, 그림자의 비용 |
| 루멘 | 동적인 간접광과 반사가 정말 필요한지, 대상 장치의 지원과 GPU 예산, 대체할 조명 경로 |
| 월드 파티션 | 월드의 크기, 스트리밍 셀과 불러오는 기준, 협업과 빌드 방식 |
| 가상 섀도 맵 | 실시간 그림자의 품질, 페이지와 캐시의 비용, 대상 플랫폼의 지원 |
고르는 순서는 다음과 같습니다. 먼저 목표 플랫폼의 최소 사양을 확정합니다. 그다음 루멘을 켠 상태와 끈 상태의 GPU 프레임 비용을 비교하고, 폴리곤이 많은 환경에서 나나이트를 적용하기 전후의 메모리와 프레임을 비교합니다. 맵이 크고 함께 작업하는 사람이 많다면 월드 파티션을 쓸지를 먼저 정합니다. 마지막으로 목표 프레임의 분포와 플레이 가독성의 기준을 함께 통과하는 설정을 고릅니다.
환경 옵션은 기능을 많이 켜는 것이 아니라, 목표 하드웨어에서 프레임이 안정적인지를 기준으로 고릅니다. 특히 루멘과 나나이트, 월드 파티션은 프로젝트의 규모와 팀의 작업 흐름에 맞춰 골라서 쓰고, GPU 시간뿐 아니라 CPU와 메모리에 올라와 있는 양, 스트리밍의 지연도 측정해 정합니다. 품질 옵션을 낮췄을 때도 플레이의 가독성과 연출 의도가 유지되는지 확인한 뒤, 최종 설정을 기술 문서에 고정해 두면, 운영하는 동안 설정이 조금씩 어긋나는 일을 줄일 수 있습니다.
정리
- 환경 설정은 그림자, 조명, 후처리처럼 서로 다른 렌더링 단계와 메모리에 영향을 주며, 품질과 성능을 맞바꾸는 관계입니다.
- 후처리와 반사의
Intensity나 블룸의Threshold처럼 겉모습을 바꾸는 값만 낮추면 그 단계의 비용은 그대로일 수 있으므로, 품질과 해상도, 샘플 수를 비교합니다. - 그림자는 방식에 따라 조절하는 설정이 다르며, 캐스케이드 수와 Dynamic Shadow Distance는 캐스케이드 섀도 맵에만 해당합니다.
- 광원은 실시간 광원의 수와
Attenuation Radius를, 안개는 볼류메트릭 안개의 해상도와View Distance를 줄이며, 산란과 밀도 값은 품질 단계가 아닙니다. - 한 프레임의 예산은
1000 ÷ 목표 FPS이며, 예산과 플레이 가독성의 기준을 함께 통과하는 설정을 고릅니다. - 나나이트, 루멘, 월드 파티션, 가상 섀도 맵은 최소 사양과 GPU, CPU, 메모리, 스트리밍의 측정을 보고 골라서 쓰며, 최종 설정은 문서로 고정합니다.
연습 문제
1. 빠른 쪽을 고르지 않는 이유
60 FPS가 목표인 같은 구간에서 변경 A의 대표 프레임은 15.8 ms, 변경 B는 16.4 ms입니다. 다른 프레임도 모두 예산 안에 있지만, A에서는 상호작용 버튼의 글자가 배경에 묻혀 읽히지 않습니다. 어느 변경을 남기고, 그다음에 무엇을 더 확인해야 할까요?
해설 보기
B를 남깁니다. 둘 다 약 16.67 ms의 예산 안에 있지만, A는 플레이에 필요한 가독성의 기준을 통과하지 못하므로, 더 빠르다는 값 하나만으로는 선택할 이유가 되지 않습니다.
B의 여유는 약 0.27 ms로 작으므로, 더 복잡한 대표 장면과 최소 사양의 장치에서도 프레임 분포를 확인해야 합니다. 한 장면의 대표값만으로 모든 장치에서 통과했다고 넓혀 말하지 않습니다.
2. 45 FPS의 예산
모바일 버전의 목표를 45 FPS로 정했습니다. 한 프레임의 예산은 약 몇 ms일까요? 측정한 프레임이 20 ms라면 예산을 통과할까요?
해설 보기
1000 ÷ 45는 약 22.2 ms입니다. 측정한 20 ms는 이보다 짧으므로 대표 프레임으로는 예산을 통과합니다.
다만 이것은 한 값의 비교일 뿐이므로, 같은 구간을 되풀이할 때 가끔 생기는 긴 프레임이 예산을 넘지 않는지, 더 복잡한 장면과 최소 사양에서도 통과하는지 함께 확인합니다.
3. 반사가 무거워서 강도를 낮췄더니
SSR의 비용이 커서 후처리 볼륨의 Screen Space Reflections Intensity를 100에서 30으로 낮췄습니다. 반사는 흐려졌는데 ProfileGPU의 SSR 단계 시간은 거의 그대로입니다. 비용을 줄이려면 무엇을 바꿔야 할까요?
해설 보기
Intensity는 반사가 겉모습에 더해지는 정도를 바꿀 뿐, SSR 단계의 계산은 거의 그대로 실행됩니다.
비용을 줄이려면 Max Roughness를 낮춰 SSR이 적용되는 표면의 범위를 줄이거나, Quality를 낮추거나, SSR을 끄고 움직이지 않는 환경에는 반사 캡처를 쓰는 방법을 검토합니다. 바꾼 뒤에는 같은 장면에서 SSR 단계의 시간을 다시 측정합니다.
엔진 스케일러빌리티의 품질 단계는 Epic의 스케일러빌리티 안내에서 확인할 수 있습니다.
다음 글 메모리 및 CPU 사용량 최적화에서는 GPU 바깥의 비용인 메모리와 CPU 사용량을 측정하고, Tick과 액터 수, 에셋 로딩을 줄이는 방법을 다룹니다.