에셋 레퍼런싱의 기초
하드 참조와 소프트 참조의 로딩 시점·메모리 영향을 비교하고 상황에 맞는 에셋 참조 방식을 선택합니다.
상점 액터 하나에 판매할 무기 서른 개의 메시를 변수로 지정해 두었다고 생각해 봅니다. 플레이어가 상점 창을 한 번도 열지 않아도, 이 액터가 레벨에 있는 것만으로 무기 메시 서른 개와 그 텍스처가 모두 메모리에 올라올 수 있습니다. 반대로 꼭 필요한 순간에만 불러오도록 바꾸면, 이번에는 "아직 준비되지 않은 에셋"을 쓰려다 빈 화면을 보는 문제가 생깁니다.
3D 모델, 텍스처, 사운드, 애니메이션, 블루프린트처럼 프로젝트에 파일로 저장된 리소스를 에셋(asset)이라고 부릅니다. 블루프린트가 에셋을 어떻게 가리키느냐에 따라 그 에셋이 언제 메모리에 올라오는지가 달라집니다. 이 글에서는 에셋 레퍼런싱(asset referencing)의 두 방식인 하드 참조와 소프트 참조를 비교하고, 소프트 참조를 비동기로 불러와 완료된 뒤에만 쓰는 방법을 익힙니다.
에셋을 가리키는 두 방법
에셋 레퍼런싱은 블루프린트나 코드에서 Static Mesh, Texture, Sound Wave, Blueprint Class 같은 특정 에셋을 가리키는 방식입니다. 파일 시스템에서 경로로 파일을 찾아가는 것과 비슷하지만, 언리얼 엔진에서는 그 참조가 로딩에 영향을 준다는 점이 다릅니다. 참조 방식은 크게 하드 참조(hard reference)와 소프트 참조(soft reference)로 나뉩니다.
하드 참조는 특정 에셋을 직접 가리키는 참조입니다. 블루프린트에 저장된 하드 참조에 값이 지정되어 있으면 로딩 의존성이 생겨, 그 블루프린트를 로드할 때 참조 대상 에셋도 함께 로드됩니다. 공식 문서도 객체가 로드되고 인스턴스로 만들어질 때 하드 참조한 에셋도 함께 로드된다고 설명합니다. 다만 변수 타입만 만들고 값을 지정하지 않았다면 가리키는 에셋이 없으므로 이런 의존성도 생기지 않습니다.
소프트 참조는 에셋 자체가 아니라 에셋의 경로를 담는 참조입니다. 소프트 참조를 가진 블루프린트가 로드되어도 경로가 가리키는 에셋은 자동으로 로드되지 않으며, 필요한 순간에 로드를 요청하거나 이미 다른 경로로 로드되어 있는 객체를 씁니다. 소프트 참조 자체는 대상의 로딩을 강제하지 않습니다.
| 하드 참조 | 소프트 참조 | |
|---|---|---|
| 변수 타입 | Object Reference(예: Static Mesh Object Reference) | Soft Object Reference, Soft Class Reference |
| 담는 것 | 에셋 객체 | 에셋의 경로 |
| 로드 시점 | 참조를 가진 블루프린트와 함께 | 로드를 요청했을 때 |
| 장점 | 로드된 뒤 바로 쓸 수 있어 연결이 단순함 | 필요한 에셋만 필요할 때 불러와 메모리와 초기 로딩 시간을 아낌 |
| 단점 | 당장 필요 없는 에셋까지 메모리에 올라옴 | 쓰기 전에 로드를 요청하고 완료를 기다려야 함 |
하드 참조가 "바로 쓸 수 있다"는 말은 에셋 객체가 로드되어 있다는 뜻일 뿐, 그 뒤의 텍스처나 메시 스트리밍처럼 리소스를 준비하는 비용까지 없다는 뜻은 아닙니다. 또 하드 참조는 사슬처럼 이어질 수 있습니다. 하드 참조한 에셋이 다시 다른 에셋을 하드 참조하면 그것까지 함께 로드되므로, 큰 프로젝트에서는 참조 하나가 예상보다 많은 메모리를 끌어들일 수 있습니다.
하드 참조로 메시 지정하기
하드 참조는 변수 타입을 Object Reference 계열로 정해 만듭니다. 블루프린트 에디터의 마이 블루프린트(My Blueprint) 패널에서 새 변수를 추가하고, 타입을 Static Mesh Object Reference로, 이름을 MyMesh로 정합니다. 컴파일한 뒤 디테일 패널의 기본값 드롭다운에서 사용할 Static Mesh 에셋(예: Shape_Cube)을 지정합니다.
이제 Event BeginPlay에서 액터의 Static Mesh 컴포넌트를 Target으로 하는 Set Static Mesh 노드를 실행하고, New Mesh 핀에 MyMesh의 Get 노드를 연결합니다. 컴파일하고 플레이하면 액터에 큐브 메시가 적용됩니다. MyMesh에 큐브가 지정되어 있으므로, 이 블루프린트가 로드될 때 큐브 메시도 이미 함께 로드되어 있고 BeginPlay에서 곧바로 쓸 수 있습니다.
소프트 참조를 비동기로 불러오기
소프트 참조는 변수 타입을 Soft Object Reference 계열로 정해 만듭니다. 새 변수를 추가해 타입을 Static Mesh Soft Object Reference로, 이름을 MySoftMesh로 정하고, 기본값 드롭다운에서 사용할 메시(예: Shape_Cylinder)를 지정합니다. 에디터에서 에셋을 고르는 방법은 하드 참조와 같지만, 변수에 저장되는 것은 실린더 메시의 경로입니다.
경로를 실제 에셋으로 바꾸려면 로드를 요청해야 합니다. Event BeginPlay에서 MySoftMesh의 Get 노드를 Async Load Asset 노드의 Asset 핀에 연결하고, BeginPlay의 실행 선을 이 노드에 잇습니다. Async Load Asset에는 실행 출력이 두 개 있습니다. 하나는 로드를 요청한 직후 곧바로 이어지는 실행 출력이고(이 글과 그림에서는 Out이라고 부릅니다), 다른 하나는 로드가 끝났을 때 실행되는 Completed입니다. Out으로 이어지는 실행은 로드가 끝나기를 기다리지 않으므로, 에셋을 쓰는 처리는 반드시 Completed 뒤에 연결합니다.
Completed는 로드한 에셋을 Object 타입으로 돌려줍니다. 이 값을 Cast To StaticMesh로 캐스트하고, 성공한 경로에서만 유효한 메시 컴포넌트를 Target으로 Set Static Mesh를 실행해 캐스트 결과를 New Mesh에 연결합니다. 로드나 캐스트에 실패하면 기존 메시를 그대로 두거나 실패를 안내하는 처리를 연결합니다.
비동기 대신 Load Asset Blocking 노드를 쓸 수도 있습니다. 이 노드는 동기 로드라서 에셋을 쓸 수 있을 때까지 기다린 뒤 다음 노드로 넘어가므로 연결은 단순하지만, 그동안 게임 스레드가 멈춰 프레임이 끊길 수 있습니다. 공식 문서도 동기 로드가 프레임 속도의 급격한 저하를 일으킬 수 있으니 게임플레이에 영향이 없을 때만 쓰라고 권합니다. 또 비동기로 불러온 객체를 계속 쓸 생각이라면, 필요한 동안 하드 참조 변수나 컴포넌트 속성에 보관해 두어야 합니다. 아무도 붙잡지 않은 객체는 메모리에서 정리될 수 있기 때문입니다.
소프트 참조를 다룰 때는 변수에 경로가 들어 있는 상태와 실제 에셋이 메모리에 준비된 상태를 나누어 생각해야 합니다. 경로가 있다고 에셋이 준비된 것은 아닙니다.
하드 의존성과 비동기 완료를 나란히 보기
소프트 경로를 가진 것과 에셋이 준비된 것은 다릅니다
소프트 경로의 요청과 Out 후속 실행은 준비 완료가 아니며 Completed 뒤 반환 타입/컴포넌트 검사를 통과할 때만 메시를 변경한다. 하드 참조 비교를 앞선 실행 단계로 이어 붙이지 않는다.
LOADING DEPENDENCY · PATH · COMPLETION
소프트 경로를 가진 것과 에셋이 준비된 것은 다릅니다
하드 참조가 로딩 의존성을 만든 경우와 MySoftMesh를 Async Load Asset으로 읽는 경우를 비교합니다. 변수 타입만 정한 상태와 실제 대상 에셋을 지정한 상태도 구분합니다.
하드 참조 뒤의 메시·텍스처 스트리밍이나 리소스 준비 비용까지 없어지지는 않습니다. 완료 후 필요한 객체는 하드 참조나 컴포넌트 속성으로 보관하며, 패키지에 대상 경로가 포함되는지 확인합니다. 실패하면 기존 메시 유지 또는 정한 실패 안내를 수행합니다.
이 예의 조건
- 본문과 원 도표에 제시된 사례의 입력·조건을 사용합니다. 설명용 수치나 독립 비교 경로는 각 단계에 표시합니다.
- 현재 상태·값과 전환 근거의 위치는 모든 단계에서 같습니다. 조건이 맞지 않거나 실행되지 않은 경로를 성공한 동작으로 해석하지 않습니다.
관계도의 보충 설명
| 범위 | 원문 |
|---|---|
| 관계·조건 설명 | 하드 참조가 로딩 의존성을 만들면 소유 에셋 로드에서 대상 준비와 SetStaticMesh로 진행한다. 소프트 참조는 경로만 보관하며 필요할 때 Async Load Asset을 요청한다. Out은 다음 실행 흐름이고 준비 완료를 보장하지 않는다. Completed에서 반환 객체의 Static Mesh 캐스트와 적용 컴포넌트를 확인해 성공할 때만 메시를 바꾼다. 실패하면 기존 메시를 유지하는 예다. 두 영역은 비교이며 이어지는 자동 실행이 아니다. |
| 노드·연결선 라벨 | 아니요 |
| 관찰·상황 | 값·보충 정보 | 변화·이유 |
|---|---|---|
| 소프트 요청 Soft 경로의 비동기 로드를 시작한다. |
|
|
| Completed 검사 완료 이벤트의 반환 타입과 컴포넌트를 확인한다. |
|
|
| 메시 변경 성공 조건이 맞을 때만 메시를 적용한다. |
|
|
소프트 경로를 가진 것과 에셋이 준비된 것은 다릅니다
소프트 경로의 요청과 Out 후속 실행은 준비 완료가 아니며 Completed 뒤 반환 타입/컴포넌트 검사를 통과할 때만 메시를 변경한다. 하드 참조 비교를 앞선 실행 단계로 이어 붙이지 않는다.
LOADING DEPENDENCY · PATH · COMPLETION
소프트 경로를 가진 것과 에셋이 준비된 것은 다릅니다
하드 참조가 로딩 의존성을 만든 경우와 MySoftMesh를 Async Load Asset으로 읽는 경우를 비교합니다. 변수 타입만 정한 상태와 실제 대상 에셋을 지정한 상태도 구분합니다.
하드 참조 뒤의 메시·텍스처 스트리밍이나 리소스 준비 비용까지 없어지지는 않습니다. 완료 후 필요한 객체는 하드 참조나 컴포넌트 속성으로 보관하며, 패키지에 대상 경로가 포함되는지 확인합니다. 실패하면 기존 메시 유지 또는 정한 실패 안내를 수행합니다.
이 예의 조건
- 본문과 원 도표에 제시된 사례의 입력·조건을 사용합니다. 설명용 수치나 독립 비교 경로는 각 단계에 표시합니다.
- 현재 상태·값과 전환 근거의 위치는 모든 단계에서 같습니다. 조건이 맞지 않거나 실행되지 않은 경로를 성공한 동작으로 해석하지 않습니다.
관계도의 보충 설명
| 범위 | 원문 |
|---|---|
| 관계·조건 설명 | 하드 참조가 로딩 의존성을 만들면 소유 에셋 로드에서 대상 준비와 SetStaticMesh로 진행한다. 소프트 참조는 경로만 보관하며 필요할 때 Async Load Asset을 요청한다. Out은 다음 실행 흐름이고 준비 완료를 보장하지 않는다. Completed에서 반환 객체의 Static Mesh 캐스트와 적용 컴포넌트를 확인해 성공할 때만 메시를 바꾼다. 실패하면 기존 메시를 유지하는 예다. 두 영역은 비교이며 이어지는 자동 실행이 아니다. |
| 노드·연결선 라벨 | 아니요 |
| 관찰·상황 | 값·보충 정보 | 변화·이유 |
|---|---|---|
| 소프트 요청 Soft 경로의 비동기 로드를 시작한다. |
|
|
| Completed 검사 완료 이벤트의 반환 타입과 컴포넌트를 확인한다. |
|
|
| 메시 변경 성공 조건이 맞을 때만 메시를 적용한다. |
|
|
위 그림은 앞에서 만든 두 경우를 나란히 놓고 비교합니다. 왼쪽의 하드 참조 영역에서는 값이 지정된 하드 참조(MyMesh = Shape_Cube)가 로딩 의존성을 만들어, 소유 에셋을 로드할 때 대상 에셋도 준비되고 유효한 컴포넌트의 Set Static Mesh로 이어집니다. 오른쪽의 소프트 참조 영역에서는 MySoftMesh의 경로만 들고 있다가 필요할 때 Async Load Asset을 요청합니다. Out은 "요청함"을 출력하는 다음 실행 경로일 뿐 완료를 보장하지 않고, Completed에서 반환된 메시가 준비되었는지와 타입, 컴포넌트를 검사해 성공이면 실린더로 바꾸고 실패면 기존 메시를 유지하거나 실패를 안내합니다. 두 영역은 비교를 위한 것이지 하나로 이어져 자동으로 실행되는 흐름이 아닙니다.
단계 그림은 소프트 참조 쪽을 세 단계로 따라갑니다. 먼저 소프트 경로의 비동기 로드를 시작하고, 다음으로 Completed가 실행되면 반환된 객체의 타입과 적용할 컴포넌트를 확인한 뒤, 마지막으로 성공 조건이 맞을 때만 메시를 바꿉니다. 그림 아래의 설명처럼, 완료 뒤 계속 쓸 객체는 하드 참조나 컴포넌트 속성으로 보관하고, 패키징한 게임에 대상 경로의 에셋이 포함되는지도 확인합니다.
따라 할 때 준비할 것
따라 할 액터에는 유효한 Static Mesh 컴포넌트가 먼저 있어야 합니다. 결과를 비교하기 쉽도록 컴포넌트에는 처음에 큐브를 표시하고, MySoftMesh에는 실린더의 경로를 지정합니다. 로드를 요청한 직후가 아니라 Completed의 캐스트 성공 경로에서 그 컴포넌트를 Target으로 Set Static Mesh를 실행하고, 실패 경로에서는 큐브를 그대로 두도록 정합니다. 이렇게 하면 화면에 실린더가 보이는지 큐브가 남는지로 성공과 실패를 구분할 수 있습니다.
에디터에서 잘 동작해도 패키징한 게임에서는 다를 수 있습니다. 패키징할 때는 실린더 메시가 실제로 쿡(Cook) 대상에 포함되었는지도 따로 확인합니다.
어떤 참조를 고를까
소프트 참조는 메모리 사용량을 줄이는 대표적인 방법입니다. 특히 넓은 오픈 월드나 에셋이 많은 게임에서는 특정 구역에 들어갔을 때만 그 구역의 에셋을 불러오는 식으로 메모리를 관리해야 합니다. 또 게임을 시작할 때 모든 에셋을 한꺼번에 불러오는 대신 필요한 에셋을 조금씩 불러오면 초기 로딩 시간도 줄일 수 있습니다.
그렇다고 모든 참조를 소프트 참조로 바꿀 필요는 없습니다. 다음 기준으로 고릅니다.
- 하드 참조가 알맞은 경우: 플레이어 캐릭터의 기본 모델이나 기본 UI처럼 게임 내내 항상 필요한 에셋, 작은 게임이나 액터가 늘 같은 소수의 에셋만 쓰는 경우, 로딩 지연을 허용할 수 없어 바로 접근해야 하는 경우.
- 소프트 참조가 알맞은 경우: 특정 상호작용 때만 나타나는 아이템 모델이나 효과음, 스킬 이펙트처럼 레벨을 불러올 때는 필요 없고 플레이 도중에 불러와도 되는 에셋, 캐릭터 커스터마이징 의상처럼 플레이어의 선택에 따라 달라지는 에셋, 큰 에셋이 많아 메모리 관리가 중요한 경우.
에셋 레퍼런싱은 변수 타입 하나를 고르는 일처럼 보이지만, 게임의 메모리 사용량과 로딩 시간에 직접 영향을 줍니다. 어떤 에셋을 언제 메모리에 올릴지를 미리 계획해 두면, 게임이 커진 뒤에 참조를 하나씩 찾아 바꾸는 수고를 줄일 수 있습니다.
정리
- 하드 참조는 에셋을 직접 가리키며, 값이 지정되어 있으면 참조를 가진 블루프린트와 함께 대상 에셋이 로드됩니다.
- 소프트 참조는 에셋의 경로만 담으며, 로드를 요청하기 전에는 대상 에셋을 메모리에 올리지 않습니다.
Async Load Asset의 요청 직후 실행 출력은 완료를 기다리지 않으므로, 에셋을 쓰는 처리는Completed에서 타입과 대상을 확인한 뒤에 연결합니다.Load Asset Blocking은 동기 로드라서 게임 스레드를 멈출 수 있고, 비동기로 불러온 객체는 쓰는 동안 하드 참조나 컴포넌트 속성에 보관합니다.- 항상 필요한 에셋은 하드 참조로, 가끔 쓰거나 선택에 따라 달라지는 에셋은 소프트 참조로 고릅니다.
연습 문제
1. 요청 직후의 실행
Async Load Asset의 Out 경로에서 "요청함"을 출력했고, Completed는 아직 실행되지 않았습니다. 이 출력만 보고 실린더를 Set Static Mesh에 적용할 수 있는 반환 객체가 준비되었다고 판단해도 될까요?
해설 보기
판단할 수 없습니다. Out으로 이어지는 실행은 로드를 요청한 직후의 흐름이고, 에셋이 준비되었다는 것은 Completed가 실행되어야 알 수 있습니다. 두 출력은 서로 다른 시점에 실행됩니다.
Completed가 실행된 뒤에도 반환된 객체가 유효한지, Static Mesh로 캐스트되는지, 적용할 컴포넌트가 유효한지를 확인하고 나서 씁니다. 대상 에셋이 이미 다른 경로로 로드되어 있어 완료가 빨리 오는 경우도 있지만, 요청했다는 메시지만으로 성공을 가정하지는 않습니다.
2. 타입만 만든 하드 참조 변수
BP_Shop에 Static Mesh Object Reference 타입의 변수 PreviewMesh를 만들었지만, 기본값은 지정하지 않고 비워 두었습니다. 이 변수 때문에 BP_Shop을 로드할 때 어떤 메시가 함께 로드될까요? 기본값에 무기 메시를 지정하면 무엇이 달라질까요?
해설 보기
변수에 지정된 에셋이 없으므로, 이 변수 때문에 함께 로드되는 메시는 없습니다. 하드 참조의 로딩 의존성은 변수 타입이 아니라 실제로 지정된 값에서 생깁니다.
기본값에 무기 메시를 지정하면 BP_Shop이 그 메시를 하드 참조하게 되어, BP_Shop을 로드할 때 무기 메시와 그 메시가 다시 하드 참조하는 머티리얼과 텍스처까지 함께 로드됩니다. 상점 창을 열 때만 필요한 메시라면 소프트 참조로 바꾸는 것을 검토합니다.
3. 참조 방식 고르기
다음 세 에셋을 하드 참조와 소프트 참조 가운데 무엇으로 두는 것이 알맞을지 이유와 함께 골라 보세요. (가) 플레이어 캐릭터의 기본 메시, (나) 커스터마이징 화면에서 고를 수 있는 의상 40벌, (다) 보스를 처치했을 때 한 번 재생되는 연출용 사운드.
해설 보기
(가)는 게임 내내 항상 필요하고, 첫 화면부터 바로 보여야 하므로 하드 참조가 알맞습니다. 불러오기를 미룰 이유가 없습니다.
(나)는 플레이어가 고른 한 벌만 필요하므로 소프트 참조로 두고, 선택한 의상만 불러옵니다. 40벌을 모두 하드 참조하면 화면을 열지 않아도 모두 메모리에 올라옵니다. (다)는 보스 전투 중에만 필요하므로 소프트 참조로 두고, 보스전이 시작될 때 미리 비동기로 불러와 두면 재생 순간의 지연을 피할 수 있습니다.
하드 참조와 소프트 참조의 로딩 방식은 언리얼 엔진 공식 문서의 에셋 참조에서 확인할 수 있습니다.
다음 글 함수 라이브러리 생성 및 활용에서는 여러 블루프린트에서 함께 쓰는 함수를 블루프린트 함수 라이브러리로 모아 어디서든 호출하는 방법을 다룹니다.