에디터의 성능 최적화
하드웨어·에디터·프로젝트·뷰포트·콘텐츠 설정과 캐시를 점검해 대형 프로젝트에서도 편집 반응성을 유지합니다.
언리얼 엔진은 고품질 그래픽을 실시간으로 그리는 만큼 시스템 자원을 많이 씁니다. 그래서 프로젝트가 커지거나 그래픽 옵션을 높이면, 뷰포트가 끊기거나 액터를 옮길 때 반응이 늦어지는 일이 생깁니다. 이럴 때 무작정 품질을 모두 낮추면 지금 작업에 필요한 화면까지 잃게 됩니다.
이 글에서는 에디터가 느려지는 원인을 하드웨어, 에디터 설정, 프로젝트 설정, 뷰포트, 콘텐츠, 캐시로 나눠 살펴보고, 각각에서 무엇을 조정할 수 있는지 정리합니다. 마지막으로 설정을 바꾼 효과를 프레임 시간으로 비교하는 방법을 계산 예와 함께 익힙니다. 성능 최적화는 품질을 낮추는 일이 아니라, 병목을 찾아 필요한 옵션부터 조정하는 일이라는 점을 기억하며 읽어 주세요.
하드웨어 요구사항부터 확인하기
가장 기본이 되는 것은 컴퓨터의 하드웨어입니다. 언리얼 엔진은 그래픽 카드(GPU), CPU, 메모리(RAM), 저장 장치의 성능에 크게 의존하며, 각 부품이 영향을 주는 작업이 다릅니다.
| 부품 | 영향을 주는 작업과 확인할 점 |
|---|---|
| GPU | 렌더링 성능에 가장 큰 영향을 줍니다. 사용하는 엔진 버전과 렌더링 기능의 GPU와 그래픽 API 요구사항을 확인합니다. 루멘(Lumen)이나 나나이트(Nanite) 같은 기능은 DirectX 12와 셰이더 모델 6(SM6) 같은 별도 조건이 있어, 에디터를 실행하는 최소 조건과 다릅니다. |
| 드라이버 | GPU 제조사의 최신 안정 드라이버를 쓰고, 그 엔진 버전이 요구하는 드라이버 조건을 확인합니다. |
| CPU | 복잡한 계산과 블루프린트 컴파일, 셰이더 컴파일에 영향을 줍니다. 셰이더 컴파일은 여러 코어를 함께 쓰므로 코어가 많을수록 유리합니다. |
| RAM | 에디터와 프로젝트가 쓰는 메모리가 상당합니다. Epic이 권장하는 Windows 개발 사양은 32 GB이며, 실제 필요량은 에셋 규모와 함께 띄워 두는 도구에 따라 달라집니다. |
| 저장 장치 | 프로젝트를 열고 저장하는 속도에 영향을 줍니다. 프로젝트와 캐시를 빠른 SSD에 두면 대기 시간을 줄이는 데 유리하지만, NVMe SSD가 모든 구성에서 실행의 필수 조건이라는 뜻은 아닙니다. |
부품을 바꾸기 전에는 먼저 무엇이 병목인지 확인합니다. GPU가 느린데 메모리를 늘려도 뷰포트는 빨라지지 않기 때문입니다. 요구사항은 하드웨어 공식 안내에서 사용하는 엔진 버전과 운영체제를 골라 비교합니다.
에디터 설정으로 줄일 수 있는 부담
개인화된 개발 환경 설정에서 본 에디터 환경설정에도 체감 성능을 바꾸는 항목이 있습니다. Edit 메뉴의 Editor Preferences를 열고 General의 Performance에서 Use Less CPU when in Background를 켜면, 에디터가 활성 창이 아닐 때 CPU 사용량을 줄입니다. 에디터를 띄워 둔 채 다른 프로그램으로 작업할 때 컴퓨터가 덜 무거워집니다.
뷰포트의 실시간(Realtime) 갱신도 끌 수 있습니다. 뷰포트 메뉴의 Realtime 옵션을 끄면 뷰포트가 매 프레임 다시 그리지 않고, 카메라를 움직이는 등 필요할 때만 그리므로 계속 갱신하는 부담이 줄어듭니다. 대신 시간에 따라 바뀌는 효과나 애니메이션의 미리 보기가 멈춘 것처럼 보이므로, 작업을 마치면 필요한 상태로 되돌립니다. 메뉴의 위치는 버전에 따라 다릅니다.
프로젝트 설정으로 렌더링 비용 조절하기
프로젝트 설정은 렌더링 품질과 직접 연결되어 있어 성능에 큰 영향을 줍니다. 다만 무엇이든 바꾸기 전에 기준이 되는 측정부터 합니다. 같은 장면과 같은 창 크기에서 프레임 시간과 메모리 사용량, 텍스처 스트리밍 풀(Texture Streaming Pool) 경고 같은 메시지를 먼저 보고, 한 항목씩 바꿔 비교합니다. 셰이더를 컴파일하는 동안의 대기와, 컴파일이 끝난 뒤 평소의 렌더링 비용도 따로 봐야 합니다. 둘을 섞으면 설정의 효과를 잘못 읽게 됩니다.
Edit 메뉴의 Project Settings를 열고 Engine의 Rendering으로 가면 다음 항목을 조정할 수 있습니다.
| 항목 | 조정 방법과 주의점 |
|---|---|
| Anti-Aliasing Method | 기본 방식은 버전과 템플릿에 따라 다르며, TSR, TAA, FXAA 같은 방식의 지원도 렌더링 경로에 따라 다릅니다. 지금 방식을 확인하고, 바꾸기 전후의 프레임 시간과 화질을 비교합니다. 가벼운 방식으로 바꾸면 화질이 떨어질 수 있습니다. |
| Dynamic Global Illumination Method | 루멘은 최신 실시간 간접 조명을 제공하지만 그만큼 높은 사양을 요구합니다. 학습 초기이거나 사양이 낮다면 Screen Space나 None으로 바꿔 부담을 줄일 수 있습니다. |
| Reflection Method | 루멘 반사 대신 Screen Space 반사를 쓰거나 None으로 두어 반사 계산 비용을 줄일 수 있습니다. |
| Shadow Map Method | 가상 섀도 맵(Virtual Shadow Maps)과 기존 섀도 맵(Shadow Maps) 가운데 지금 방식을 확인하고, 스케일러빌리티의 그림자 품질도 함께 봅니다. 두 방식의 비용은 장면과 하드웨어에 따라 달라서, 한쪽이 항상 빠르다고 가정하지 않습니다. |
| Occlusion Culling | 다른 물체에 가려 보이지 않는 오브젝트를 그리지 않는 기능입니다. 기본으로 켜져 있으며, 특정 문제가 생겼을 때 확인해 볼 항목입니다. |
간접 조명과 반사 방식은 글로벌 일루미네이션과 반사 설정에서, 그림자 방식은 그림자 옵션과 성능 최적화에서 자세히 다룹니다.
프레임을 일정하게 맞추는 Smooth Frame Rate는 에디터 환경설정이 아니라 Project Settings의 Engine, General Settings, Framerate에 있는 애플리케이션 프레임 설정입니다. 프레임 제한을 없애는 것만으로 느린 프레임의 병목이 해결되지는 않습니다. 한 프레임이 오래 걸리는 원인은 그대로 남아 있기 때문입니다.
뷰포트에서 보는 것 줄이기
뷰포트의 설정만으로도 편집할 때의 부담을 줄일 수 있습니다. 먼저 뷰 모드입니다. 뷰포트 툴바의 뷰 모드 메뉴에서 릿(Lit) 대신 언릿(Unlit)을 고르면 조명의 영향을 뺀 재질만 보이고, 와이어프레임(Wireframe)을 고르면 폴리곤 구조가 선으로 보입니다. 재질이나 모델의 형태를 확인할 때 쓸모가 있지만, 실제 비용은 장면과 렌더링 경로에 따라 다르므로 이 모드들이 복잡한 장면에서 항상 가장 가볍다고 가정하지는 않습니다.
다음은 표시(Show) 메뉴입니다. 조명 아이콘이나 오디오 아이콘, 내비게이션 표시처럼 작업에 필요 없는 요소를 끄면 뷰포트가 그릴 것이 줄어듭니다. 무거운 이펙트나 파티클, 후처리를 잠시 숨기고 배치 작업에 집중할 수도 있습니다. 표시 메뉴로 숨긴 것은 뷰포트에서만 숨겨지므로, 게임 결과에는 영향을 주지 않습니다.
마지막으로 렌더링 해상도입니다. 뷰포트 메뉴의 화면 백분율(Screen Percentage)을 낮추면 뷰포트를 더 작은 해상도로 그린 뒤 화면 크기로 늘려 보여 주므로, 화질은 떨어지지만 GPU 부담이 줄어듭니다. 툴바의 Settings에 있는 엔진 스케일러빌리티 설정(Engine Scalability Settings)에서도 해상도와 그림자, 효과 같은 품질 단계를 한꺼번에 낮출 수 있습니다. 메뉴의 위치는 버전에 따라 다르므로 이름으로 찾습니다.
콘텐츠와 레벨에서 줄이기
에디터의 설정 말고도, 만드는 콘텐츠 자체가 성능을 크게 좌우합니다. 설정은 보는 방식을 바꿀 뿐이지만, 콘텐츠는 그려야 할 양 자체를 정하기 때문입니다.
레벨 오브 디테일(Level of Detail, LOD)은 메시가 화면에서 차지하는 크기 같은 기준에 따라 상세 수준을 바꾸는 기능입니다. 멀리 있어 작게 보이는 오브젝트는 폴리곤이 적은 모델로 그려 비용을 줄입니다. 텍스처도 필요한 곳에만 고해상도를 쓰고, 화면에서 작게 보이는 물체에는 불필요하게 큰 텍스처를 쓰지 않습니다. 모델의 폴리곤 수가 너무 많으면 성능에 큰 영향을 주므로, 눈에 잘 띄지 않는 오브젝트는 폴리곤 수를 줄입니다.
오클루전 컬링(occlusion culling)은 가려서 보이지 않는 오브젝트를 그리지 않는 기능입니다. 효과는 가림 관계와 렌더링 경로에 따라 달라지며, 보이지 않는다고 모든 처리 비용이 없어지는 것은 아닙니다. 그리지는 않아도 그 오브젝트가 가려졌는지 판단하는 비용과, 화면과 상관없이 실행되는 로직이나 물리는 남기 때문입니다.
조명도 비용이 큰 요소입니다. 실시간으로 움직이는 조명과 실시간 그림자는 비용이 높으므로, 조명의 영향 범위와 그림자를 드리울지 여부를 신중하게 정합니다. 미리 계산해 굽는(bake) 정적 조명을 쓰려면, 프로젝트가 정적 조명을 지원하도록 되어 있는지와 루멘처럼 고른 조명 방식과 함께 쓸 수 있는지를 먼저 확인합니다. 이 내용은 실시간 조명 및 사전 계산 조명에서 다룹니다.
캐시와 작업 데이터 구분하기
파생 데이터 캐시(Derived Data Cache, DDC)는 에셋에서 계산해 낸 데이터를 저장해 두고 다시 쓰는 캐시입니다. 텍스처를 압축하거나 셰이더를 컴파일한 결과를 저장해 두므로, 다음에 같은 에셋을 열 때 다시 계산하지 않아도 됩니다. 그래서 캐시가 크다는 이유만으로 주기적으로 지우면, 다음에 열 때 그만큼을 다시 만드느라 오히려 오래 기다리게 됩니다.
프로젝트 폴더에는 캐시와 비슷해 보이지만 성격이 다른 폴더들이 있으므로, 지우기 전에 무엇인지 구분합니다.
| 대상 | 확인할 내용 |
|---|---|
| DDC | 다시 만들 수 있는 파생 데이터입니다. 지우기 전에 실제 캐시 경로와 오류나 용량 문제가 있는지부터 확인합니다. UE 5.4부터 기본 로컬 캐시는 Zen 저장소(Zen Store)를 쓰므로, 예전처럼 고정된 버전별 폴더 경로가 있다고 일반화하지 않습니다. |
Intermediate | 빌드하는 동안 생기는 중간 파일이 들어 있습니다. 빌드 문제를 진단할 때 다시 만드는 비용과 대상을 확인하고 다룹니다. |
Saved | 자동 저장 사본과 설정, 로그 같은 작업 기록이 들어 있습니다. 캐시와 함께 지우면 복구용 사본과 문제를 진단할 로그를 잃을 수 있습니다. |
캐시를 정리해야 할 때는 DDC 공식 안내에서 지금의 저장 방식에 맞는 관리 절차를 확인합니다. 에셋 원본과 필요한 복구 자료는 지키고, 프로젝트의 Saved 폴더 전체를 성능을 위해 지워도 되는 캐시로 취급하지 않습니다.
오래 작업한 뒤 에디터의 반응이 느려졌다면, 작업을 저장하고 다시 시작하기 전후의 메모리 사용량과 동작을 비교해 볼 수 있습니다. 다만 다시 시작했더니 나아졌다는 사실만으로 메모리 누수가 있다고 단정할 수는 없습니다. 다시 시작하면 캐시와 열린 창, 백그라운드 작업도 함께 초기화되기 때문입니다.
바꾼 효과를 프레임 시간으로 비교하기
설정을 바꾼 효과는 초당 프레임 수(FPS)보다 한 프레임을 그리는 데 걸린 시간, 즉 프레임 시간(frame time)으로 비교하는 편이 정확합니다. 둘의 관계는 FPS = 1000 / 프레임 시간(ms)입니다.
가상의 같은 장면으로 계산해 봅니다. 셰이더 컴파일이 끝난 뒤 같은 카메라와 같은 창 크기에서 한 프레임이 24 ms 걸렸고, 옵션 하나를 바꾼 뒤 20 ms가 되었다고 합시다. 1000 / 24는 약 41.7이고 1000 / 20은 50이므로, 약 41.7 FPS에서 50 FPS로 바뀐 것입니다. 60 FPS를 목표로 한다면 한 프레임의 예산은 1000 / 60, 약 16.67 ms이므로, 20 ms는 아직 목표에 못 미칩니다. 이때 프로젝트를 처음 열 때의 로딩 시간과, 장면이 안정된 뒤의 프레임 시간을 섞지 않도록 주의합니다.
화면 백분율도 계산해 봅니다. 화면 백분율이 가로와 세로의 렌더링 크기에 각각 적용되는 조건에서, 1920×1080을 50%로 낮추면 960×540이 됩니다. 가로와 세로가 모두 절반이 되므로 픽셀 수는 원래의 25%입니다. 하지만 이것만으로 프레임 전체의 비용이 75% 줄어든다거나 FPS가 네 배가 된다고 단정할 수는 없습니다. CPU가 하는 일과 해상도와 상관없는 고정 비용, 고른 렌더링 경로의 비용은 그대로 남기 때문입니다.
품질을 낮춘 설정은 지금 하는 편집에 정말 필요한지 확인하고 씁니다. 편집을 편하게 하려고 낮춘 설정과 최종 결과물의 설정은 다를 수 있으므로, 최종 화면과 성능은 목표 기기에서 따로 점검합니다. 측정 도구를 쓰는 방법은 환경 요소의 성능 분석에서 다룹니다.
정리
- 성능 최적화는 품질을 모두 낮추는 일이 아니라, 병목을 찾아 필요한 옵션부터 한 항목씩 바꿔 비교하는 일입니다.
- 하드웨어는 GPU, 드라이버, CPU, RAM, 저장 장치가 각각 다른 작업에 영향을 주며, Epic이 권장하는 Windows 개발 사양의 메모리는 32 GB입니다.
- 에디터에서는 Use Less CPU when in Background와 뷰포트의 Realtime으로, 프로젝트에서는 안티에일리어싱, 간접 조명, 반사, 그림자 방식으로 부담을 조절합니다.
- 뷰 모드, 표시 메뉴, 화면 백분율, 엔진 스케일러빌리티 설정은 편집할 때의 부담을 줄이며, 표시 메뉴로 숨긴 것은 게임 결과에 영향을 주지 않습니다.
- LOD, 텍스처 해상도, 폴리곤 수, 오클루전 컬링, 조명 설정처럼 콘텐츠가 그려야 할 양 자체를 줄이는 것이 근본적인 개선입니다.
- DDC는 다시 만들 수 있는 캐시지만 지우면 재생성 비용이 들고,
Saved는 복구 자료와 로그가 있는 작업 기록이라 캐시로 취급하지 않습니다. - 효과는
FPS = 1000 / 프레임 시간(ms)으로 계산해 같은 조건에서 비교하며, 60 FPS의 예산은 약 16.67 ms입니다.
연습 문제
1. 개선한 결과가 목표를 만족할까
같은 조건에서 옵션을 바꾼 뒤 프레임 시간이 25 ms가 되었습니다. 몇 FPS이며, 30 FPS 목표와 60 FPS 목표 가운데 어느 쪽을 만족할까요?
해설 보기
1000 / 25 = 40이므로 40 FPS입니다. 30 FPS 목표의 예산은 약 33.3 ms이고 25 ms는 그보다 짧으므로 30 FPS 목표는 만족합니다. 60 FPS 목표의 예산은 약 16.67 ms이므로 25 ms로는 부족합니다.
이 계산은 프레임 시간만 본 것이므로, 화면 품질과 순간적인 끊김은 따로 확인해야 합니다.
2. 화면 백분율을 낮췄는데 기대만큼 빨라지지 않았다
1920×1080 뷰포트에서 화면 백분율을 50%로 낮췄더니, 픽셀 수가 25%가 되었는데도 프레임 시간은 30 ms에서 24 ms로만 줄었습니다. 왜 네 배 빨라지지 않았을까요?
해설 보기
화면 백분율은 픽셀 수에 비례하는 비용만 줄입니다. CPU가 하는 일, 해상도와 상관없는 고정 비용, 렌더링 경로의 다른 단계 비용은 그대로 남기 때문에 프레임 시간이 픽셀 수에 비례해 줄지는 않습니다.
30 ms에서 24 ms로 줄었다면 약 33.3 FPS에서 약 41.7 FPS가 된 것입니다. 더 줄이려면 남은 비용이 CPU 쪽인지 GPU의 다른 단계인지 측정 도구로 확인해야 합니다.
3. 용량을 비우려고 폴더를 지우기 전에
디스크가 부족해서 프로젝트 폴더의 캐시처럼 보이는 폴더를 지우려 합니다. DDC, Intermediate, Saved 가운데 무엇을 어떻게 다뤄야 할까요?
해설 보기
DDC는 다시 만들 수 있는 파생 데이터이므로 지울 수는 있지만, 다음에 열 때 텍스처 압축과 셰이더 컴파일을 다시 하느라 오래 기다리게 됩니다. 지우기 전에 실제 캐시 경로와 공식 관리 절차를 확인합니다.
Intermediate는 빌드 중에 생기는 중간 파일이라 다시 만들 수 있지만, 다시 빌드하는 비용이 듭니다. Saved에는 자동 저장 사본과 설정, 로그가 있으므로 캐시처럼 통째로 지우면 복구 자료와 진단 기록을 잃을 수 있습니다. 용량이 문제라면 Saved 안에서도 무엇이 큰지 먼저 확인하고, 필요한 자료를 남긴 채 정리합니다.
이것으로 2장을 마칩니다. 2장에서는 에디터의 레이아웃을 작업에 맞게 바꾸고 저장하는 방법, 뷰포트 이동과 액터의 선택과 변형, 에디터 환경설정과 단축키, 플러그인, 프로젝트 전체에 적용되는 프로젝트 설정, 그리고 에디터의 성능을 측정하며 조정하는 방법까지 에디터 환경을 갖추는 법을 익혔습니다. 다음 장의 에셋 임포트 및 관리부터는 외부 파일을 에셋으로 가져오는 방법에서 시작해, 폴더 구조와 버전 관리, 에셋 최적화, 에셋을 쓰는 레벨 디자인, Fab에서 외부 에셋을 들여오는 일까지 에셋을 다루는 방법을 살펴봅니다.