에셋 관리의 기본 개념

나이아가라 효과를 잘 만드는 일은 효과 하나의 품질뿐 아니라, 그 효과에 얽힌 나이아가라 시스템과 이미터, 모듈 스크립트, 머티리얼, 텍스처를 얼마나 체계적으로 관리하느냐에도 달려 있습니다. 같은 스파크 텍스처가 폴더마다 복사되어 있거나, 지워도 되는지 모르는 에셋이 쌓여 가면, 프로젝트가 커질수록 찾기도 고치기도 어려워집니다. 에셋 관리는 프로젝트의 확장성과 협업의 효율, 오랜 기간의 유지보수에 직접 영향을 줍니다. 기본적인 프로젝트 설정 및 관리에서 이름과 폴더의 규칙을 간단히 정했다면, 이 글에서는 그 규칙이 왜 필요한지와 재사용의 범위, 그리고 참조를 확인해 정리하는 습관을 더 자세히 살펴봅니다.

---

이름 규칙이 하는 일

프로젝트의 모든 에셋에 일관된 이름 규칙을 적용하는 것은 혼란을 줄이고 작업을 빠르게 하는 가장 기본적인 방법입니다. 이름만 보고도 어떤 종류의 에셋이고 어디에 쓰는지 바로 알 수 있고, 예측할 수 있는 패턴으로 검색할 수 있습니다. 여러 사람이 함께 일할 때 이름에 대한 쓸데없는 질문이나 오해가 줄고, 특정 이름 패턴의 에셋을 대상으로 하는 자동화 스크립트를 쓰기도 쉬워집니다.

나이아가라 에셋에는 보통 다음 접두사를 씁니다.

• 나이아가라 시스템(Niagara System): NS_. NS_Explosion_Fire, NS_Character_HealAura가 그 예입니다.
• 나이아가라 이미터(Niagara Emitter): NE_. NE_Fire_Core, NE_Smoke_Trail이 그 예입니다.
• 나이아가라 모듈 스크립트(Niagara Module Script): NMS_. NMS_Force_AttractByDistance가 그 예입니다.
• 나이아가라 데이터 인터페이스(Niagara Data Interface): NDI_. NDI_Actor_Player가 그 예입니다. 이것은 팀에서 이름을 정한 직접 만든 타입이나 참조 변수에 쓰는 접두사이며, 모든 데이터 인터페이스가 콘텐츠 브라우저의 독립된 에셋인 것은 아닙니다.

이름은 10장 첫 글에서 정한 [효과 종류]_[하위 종류]_[설명]처럼 범주를 나누어 짓습니다. NS_Weapon_Pistol_MuzzleFlash, NE_Explosion_SecondarySpark가 그 예입니다. 줄임말은 피하고 뜻이 분명한 전체 이름을 쓰는 편이 좋아서, NS_Imp_Mtl보다 NS_Impact_Metal이 낫습니다. 또 NS_Impact_Bullet_Metal처럼 무엇에 맞은 효과인지까지 적으면 비슷한 효과와 구분하기 쉽습니다. 무엇보다 팀 전체가 합의한 규칙을 꾸준히 지키는 것이 중요합니다.

---

논리적인 폴더 구조

폴더 구조도 이름 규칙만큼 중요합니다. 잘 정리된 폴더는 에셋을 찾는 시간을 줄이고 프로젝트를 읽기 쉽게 만듭니다.

먼저 Content/FX나 Content/Effects처럼 모든 입자 효과의 에셋을 담는 최상위 폴더를 하나 만듭니다. 그 아래에는 Fire, Water, Impacts, Character, Weapon, Environment, Magic처럼 효과의 큰 범주별로 폴더를 나눕니다. 각 범주 아래에는 효과 시스템마다 하위 폴더를 만들고, 그 시스템에서만 쓰는 이미터와 머티리얼, 텍스처를 함께 둡니다. 예를 들어 Content/FX/Explosions/Explosion_Large/ 폴더에 NS_Explosion_Large.uasset, NE_Explosion_Core.uasset, M_Explosion_SubUV.uasset, T_Explosion_Smoke.uasset을 함께 두는 식입니다.

여러 시스템이 함께 쓰는 이미터와 머티리얼, 텍스처는 Content/FX/Common이나 Content/FX/Shared 같은 별도의 폴더에 모읍니다. 참고용 이미지나 영상은 Content/Docs/FX_References 같은 폴더에 따로 두어 에셋 폴더를 깨끗하게 유지합니다. 아래는 이런 규칙을 따른 폴더 구조의 예입니다.

---

에셋 다시 쓰기

나이아가라의 장점 가운데 하나는 모듈성이며, 이를 살려 에셋을 다시 쓰면 작업이 크게 빨라집니다.

흔히 쓰는 스파크나 연기 기둥, 작은 불꽃 같은 효과는 독립된 이미터 에셋(NE_)으로 만들어 저장하고, 여러 나이아가라 시스템(NS_)에 더해 효과를 빠르게 구성합니다. 부모와의 상속과 고른 버전으로 연결된 시스템은 공통의 변경을 함께 받을 수 있습니다. 다만 버전 업그레이드와 로컬에서 덮어쓴 값, 독립된 복사본을 구분하고, 쓰는 곳마다 결과를 확인해야 합니다.

자주 쓰는 복잡한 계산이나 특정 로직, 예를 들어 거리에 따른 힘이나 한 방향으로 퍼지는 계산은 모듈 스크립트(NMS_)로 저장해 다시 씁니다. 코드의 함수처럼 동작하므로 나이아가라 그래프를 깔끔하게 유지하고 실수를 줄이며, 여러 곳에서 같은 동작을 하게 합니다.

부드러운 원형 스프라이트나 노이즈 텍스처, SubUV 시트처럼 여러 효과에서 쓸 수 있는 범용 머티리얼과 텍스처는 함께 써서 VRAM 사용량을 줄이고 일관성을 지킵니다. 하나의 마스터 머티리얼에서 머티리얼 인스턴스를 만들어 색이나 세기 같은 변형을 만드는 방법도 씁니다.

---

공용 버전과 독립 복사본의 영향 범위

공용 이미터를 바꿀 때 어디까지 영향이 가는지 따져 봅니다. 공용 이미터에 버전 관리가 켜져 있고, 시스템 A와 B가 버전 1을 고른 상태라고 합시다. 버전 2를 만들었다고 해서 두 시스템이 저절로 업그레이드되었다고 기록하지 않습니다. A에서 버전 2를 고르고 결과를 확인했다면, 바뀐 것은 A가 고른 버전뿐입니다. B는 여전히 버전 1을 고르고 있는지 확인하며, 따로 복사해 둔 독립 복사본 C는 공용 부모의 업데이트를 받는 구조가 아니므로 따로 고치고 검토합니다.

나이아가라 안의 버전 기능은 Git이나 Perforce의 이력을 대신하지 않는다는 점도 기억해 둡니다.

---

에셋을 꾸준히 정리하기

에셋 관리는 한 번 정하면 끝나는 일이 아니라, 프로젝트 내내 계속 해야 하는 일입니다. 정기적으로 콘텐츠 브라우저의 레퍼런스 뷰어(Reference Viewer)로 쓰이지 않는 것 같은 에셋과 의존 관계를 찾습니다. 다만 지우기 전에 게임 코드가 문자열 경로로 불러오는지, Asset Manager나 패키징 설정에 포함되어 있는지도 확인합니다. Developers 폴더로 옮겼다는 사실만으로 모든 쿠킹(cook) 경로에서 빠진다고 보장할 수는 없습니다.

에셋을 옮긴 뒤에는 에디터에서 리디렉터를 정리해, 옮긴 에셋을 참조하는 패키지를 다시 저장합니다. 쓰기 권한이나 체크아웃 문제로 정리에 실패한 리디렉터는 억지로 지우지 말고 남겨 둔 채 원인부터 해결합니다.

복잡한 나이아가라 시스템이나 모듈에는 주석을 충분히 달아 다른 사람이 이해하기 쉽게 하고, 필요하다면 팀의 위키나 문서에 에셋의 사용법과 규칙을 적어 둡니다. 새 효과를 더할 때마다 stat Niagara나 나이아가라 디버거로 성능에 주는 영향을 확인하며, 그 방법은 파티클 효과의 기본 최적화 기법과 나이아가라 이펙트 디버깅 기초에서 다뤘습니다.

정리는 에셋을 만들 때 이름과 담당자를 정하고, 작업하는 동안 공용 에셋의 참조를 확인하며, 마감 전에 패키징 결과를 점검하는 순서로 합니다. 같은 역할로 보이는 에셋이라도 실제 설정과 쓰이는 곳이 다를 수 있으므로, 이름만 보고 합치거나 지우지 않습니다.

---

정리

• 일관된 이름 규칙은 에셋의 종류와 용도를 바로 알게 하고 검색과 협업, 자동화를 쉽게 하며, NS_, NE_, NMS_ 같은 접두사를 씁니다.
• 폴더는 최상위 FX 폴더 아래에 범주와 시스템별로 나누고, 함께 쓰는 에셋은 Common이나 Shared 폴더에 모읍니다.
• 이미터와 모듈, 머티리얼은 다시 쓰되, 상속과 고른 버전, 덮어쓴 값, 독립 복사본을 구분해 영향 범위를 확인합니다.
• 공용 이미터의 새 버전은 쓰는 곳이 직접 골라야 반영되며, 나이아가라의 버전 기능은 버전 관리 시스템의 이력을 대신하지 않습니다.
• 지우기 전에 레퍼런스 뷰어뿐 아니라 동적 경로와 패키징 설정도 확인하고, 이름만 보고 합치거나 지우지 않습니다.

---

연습 문제

1. 참조가 보이지 않는 텍스처

레퍼런스 뷰어에서 어떤 텍스처를 가리키는 참조가 보이지 않지만, 게임 코드는 문자열 경로로 그 텍스처를 불러오고 패키징 설정에도 명시적으로 들어 있습니다. 이 텍스처를 지울 후보로 곧바로 확정할 수 있을까요? 또 이름 규칙이 같은 두 머티리얼이 입력과 블렌드 모드가 다른데, 하나로 합쳐도 된다는 결론은 맞을까요?

해설 보기

확정할 수 없습니다. 동적으로 불러오는 경로와 패키징 정책을 확인해야 하므로, 레퍼런스 뷰어에 참조가 보이지 않는다는 것만으로는 지울 수 없습니다. 코드가 요청하고 쿠킹 결과에 필요한 에셋이라면 남겨 두거나, 그 사용 경로를 함께 바꾼 뒤 확인합니다.

두 머티리얼도 그대로 합치면 안 됩니다. 이름이 비슷해도 입력과 블렌드 모드가 다르면 서로 다른 표현을 맡고 있을 수 있습니다. 공용으로 만들려면 각 사용처의 값과 렌더링 결과, 예산이 유지되는지 비교합니다. 이름과 폴더 구조는 찾기 위한 규칙일 뿐, 실제 의존 관계와 설정을 대신하지 않습니다.

2. 바뀌지 않은 시스템 B

공용 이미터의 버전 2에서 스파크의 색을 바꾼 뒤, 시스템 A에서는 새 색이 보이는데 시스템 B에서는 예전 색 그대로입니다. 오류일까요?

해설 보기

오류가 아닐 가능성이 큽니다. 버전 관리가 켜진 공용 이미터에서는 쓰는 곳마다 어느 버전을 쓸지 고르므로, A만 버전 2로 바꾸고 B는 버전 1을 그대로 고르고 있다면 B의 색은 바뀌지 않습니다.

B에도 새 색이 필요하다면 B에서 버전 2를 고르고 결과를 확인합니다. B가 버전 1에 맞춰 덮어쓴 값이 있다면 업그레이드한 뒤에도 그 값이 원하는 결과를 만드는지 함께 봅니다.

3. 폴더마다 복사된 텍스처

같은 원형 스프라이트 텍스처가 효과 폴더마다 복사되어 열 개나 있습니다. 하나로 합치려면 어떻게 진행하면 좋을까요?

해설 보기

먼저 열 개의 텍스처가 정말 같은지, 즉 해상도와 압축, 알파 설정까지 같은지 확인합니다. 같은 것만 하나를 골라 Content/FX/Common 같은 공용 폴더로 옮깁니다.

그다음 나머지 복사본을 공용 텍스처로 대체해 참조를 바꾸고, 리디렉터를 정리합니다. 문자열 경로나 패키징 설정에서 복사본을 직접 가리키는 곳이 없는지도 확인한 뒤, 각 효과가 같은 결과를 내는지 보고 남은 복사본을 지웁니다.

공용 이미터와 모듈의 버전 기능은 Epic의 모듈과 이미터 버전 관리 문서에서 확인할 수 있습니다.

다음 글 크로스 플랫폼 호환성 기본 이해에서는 같은 효과를 PC와 콘솔, 모바일 같은 여러 플랫폼에서 쓰기 위해 기능의 지원과 품질 단계를 나누는 방법을 살펴봅니다.