간단한 버전 관리 방법
언리얼 소스 컨트롤에서 나이아가라 에셋을 체크아웃·커밋·되돌리고 바이너리 충돌을 줄이는 팀 작업 순서를 익힙니다.
나이아가라 효과 하나에는 여러 이미터와 모듈, 스크립트, 머티리얼, 텍스처가 얽혀 있습니다. 그래서 공용 이미터를 잘못 고치면 그것을 쓰는 여러 시스템이 한꺼번에 바뀌고, 실수로 저장한 변경 때문에 어제까지 잘 보이던 효과가 깨지기도 합니다. 버전 관리(version control)를 쓰면 이런 실수에서 이전 상태로 돌아갈 수 있고, 여러 사람이 동시에 작업할 때의 충돌을 줄이며, 과거의 변경 기록을 따라가 문제의 원인을 찾을 수 있습니다. 팀 프로젝트는 물론 혼자 하는 작업에서도 꼭 필요한 이유입니다. 이 글에서는 언리얼 에디터를 버전 관리 시스템에 연결하는 방법과 나이아가라 에셋을 다루는 기본 작업, 바이너리 에셋의 주의점, 그리고 팀의 작업 순서를 정리합니다.
버전 관리가 주는 것
버전 관리는 네 가지를 줍니다. 첫째, 잘못된 변경을 되돌리거나 실수로 지운 파일을 이전 버전으로 되살릴 수 있습니다. 둘째, 누가 언제 무엇을 바꿨는지 기록해 문제가 생겼을 때 원인을 찾게 도와줍니다. 셋째, 여러 팀원이 같은 프로젝트에서 동시에 작업할 때 파일 충돌을 관리하고 변경을 합칠 수 있습니다. 넷째, 시험용과 개발용, 출시용처럼 효과의 여러 버전을 나누어 관리할 수 있습니다.
에디터를 버전 관리에 연결하기
언리얼 엔진은 Perforce와 Git, SVN 같은 여러 외부 버전 관리 시스템과의 연결을 지원하며, 에디터 안에서 기본적인 버전 관리 작업을 할 수 있는 인터페이스를 제공합니다. 예전에는 이 기능을 소스 컨트롤(Source Control)이라고 불렀지만, UE 5.3부터 에디터에서는 리비전 컨트롤(Revision Control)이라는 이름을 씁니다. 그래서 2026년 11월 기준의 UE 5.8에서는 메뉴를 Revision Control이라는 이름으로 찾습니다.
먼저 쓸 공급자의 플러그인을 확인합니다. Edit > Plugins를 열어 쓸 버전 관리 공급자의 플러그인이 설치되어 켜져 있는지 확인합니다. Perforce와 SVN, 따로 설치한 Git 공급자는 지원하는 기능과 설정 화면이 서로 다를 수 있습니다.
다음으로 연결합니다. 에디터 오른쪽 아래의 Revision Control 상태 버튼에서 Connect to Revision Control을 고르고, 쓸 버전 관리 시스템을 선택한 뒤 그 공급자가 요구하는 정보를 입력합니다. Perforce라면 서버와 사용자, 워크스페이스를 넣고, Git이라면 로컬 저장소와 원격 저장소의 설정을 쓰므로 같은 항목을 요구하지 않습니다. 연결에 성공하면 오른쪽 아래에 버전 관리의 상태 아이콘이 나타납니다.
나이아가라 에셋을 다루는 기본 작업
연결한 뒤에는 콘텐츠 브라우저에서 NS_, NE_ 같은 나이아가라 에셋을 오른쪽 클릭해 버전 관리 작업을 합니다.
체크아웃(Check Out)은 고치기 전에 하는 일입니다. Perforce처럼 체크아웃을 쓰는 공급자에서는 에셋을 고치기 전에 체크아웃합니다. 다만 체크아웃이 언제나 다른 사람의 수정을 막는 독점 잠금이 되는 것은 아니므로, 바이너리 파일에 대한 Perforce의 독점 파일 형식 설정이나 Git LFS의 잠금 정책을 따로 확인합니다. 상태 아이콘과 툴팁에서 내가 고친 상태와 다른 사람의 잠금을 확인하며, 아이콘의 모양은 엔진과 공급자에 따라 다릅니다.
체크인(Check In)이나 제출(Submit)은 고친 내용을 버전 관리에 올려 다른 팀원이 새 버전을 받을 수 있게 하는 일입니다. 이때 바뀐 내용을 요약한 커밋 메시지를 자세히 씁니다. NS_Explosion_Fire: Added more secondary sparks and adjusted lifetime. 같은 메시지가 그 예입니다. Git의 commit은 로컬에만 남는 기록이므로, 다른 팀원과 나누려면 push를 해야 합니다. 디스크에 저장만 한 상태와 제출한 상태도 구분합니다.
동기화(Sync)는 다른 팀원이 올린 변경을 받아 내 작업 공간을 최신으로 맞추는 일입니다. 콘텐츠 브라우저에서 최상위 폴더를 오른쪽 클릭하고 버전 관리 메뉴의 Sync를 고릅니다.
되돌리기(Revert)는 체크아웃해 고친 변경을 취소하고, 체크아웃하기 전의 상태로 돌아가는 일입니다. 디스크에 저장했지만 아직 제출하지 않은 변경도 함께 버려질 수 있으므로, 대상 리비전과 파일 목록을 확인한 뒤 실행합니다. 에디터에 열려 있는 에셋도 새 디스크 상태로 다시 불러와야 합니다.
기록 보기(History)는 에셋의 변경 이력을 보는 일입니다. 버전마다 누가 언제 바꿨고 어떤 커밋 메시지를 남겼는지 확인할 수 있습니다.
나이아가라 에셋의 주의점
나이아가라 에셋은 대부분 바이너리 파일(.uasset)이어서, 텍스트로 된 코드처럼 줄 단위로 변경을 합칠 수 없습니다.
그래서 두 명 이상이 같은 나이아가라 .uasset을 동시에 고쳐 올리려 하면 충돌(conflict)이 생기고, 버전 관리 시스템은 보통 둘 가운데 하나를 고르거나 손으로 해결하라고 합니다. 가장 좋은 방법은 같은 에셋을 동시에 고치지 않는 것입니다. 고치기 전에 그 에셋의 담당자와 실제 잠금 상태를 확인하고, 작고 완결된 변경을 올립니다. 충돌이 이미 났다면 두 변경의 의도를 비교해, 기준 버전에 필요한 수정을 다시 적용하고 결과를 확인합니다.
시스템(NS_)과 이미터(NE_)를 따로 에셋으로 관리하는 것도 버전 관리에 도움이 될 수 있습니다. 다만 독립된 이미터는 여러 시스템이 함께 쓸 수 있으므로, 부모와의 상속과 고른 버전에 따라 연결된 시스템들이 변경의 영향을 받습니다. 이미터의 버전을 올리면 쓰는 곳마다 업그레이드가 필요할 수 있고, 독립된 복사본은 저절로 갱신되지 않습니다. 또 시스템 자체를 고칠 때는 여전히 시스템 에셋에서 충돌이 날 수 있습니다.
에셋의 이름이나 경로를 바꾸면 리디렉터(redirector)가 생깁니다. 리디렉터는 예전 참조를 새 위치로 이어 주는 역할을 합니다. 버전 관리에 올리기 전에는 에디터에서 리디렉터를 정리해 참조하는 패키지를 다시 저장합니다. 리디렉터를 오른쪽 클릭해 Fixup을 실행하거나, 바뀐 폴더의 오른쪽 클릭 메뉴에서 리디렉터를 정리하는 항목을 씁니다. 쓰기 권한이나 체크아웃 문제로 참조를 갱신하지 못했다면 리디렉터를 억지로 지우지 않고, 갱신된 참조 패키지와 옮긴 에셋을 같은 변경에 함께 넣습니다.
고친 파일과 참조만 하는 파일
한 번의 변경에 무엇을 넣을지 따져 봅니다. NS_Explosion_Fire의 배치와 공용 NE_FireBlast의 수명, M_Explosion_Fire_SubUV의 색을 고쳤다고 합시다. 이번 변경의 기록에는 실제로 저장한 이 세 패키지와 각각을 바꾼 이유를 넣습니다. 참조만 하는 T_Explosion_Fire_D는 내용이 바뀌지 않았다면, 의존한다는 이유만으로 고쳤다고 적지 않습니다. 대신 그 텍스처를 쓰는 대표 효과가 같은 리비전의 조합에서 열리고 제대로 재생되는지 확인합니다. 공용 이미터라면 고른 버전과 로컬에서 덮어쓴 값도 함께 기록합니다.
| 파일 | 이번에 한 일 | 변경에 넣을지 |
|---|---|---|
NS_Explosion_Fire | 배치를 고쳐 저장 | 넣음 |
NE_FireBlast | 수명을 고쳐 저장 | 넣음, 고른 버전과 덮어쓴 값도 기록 |
M_Explosion_Fire_SubUV | 색을 고쳐 저장 | 넣음 |
T_Explosion_Fire_D | 참조만 함 | 넣지 않음, 함께 동작하는지 확인 |
결국 제출할 때는 실제로 고친 시스템과 이미터, 모듈, 머티리얼 같은 패키지를 빠짐없이 넣습니다. 참조된다는 이유로 모든 파일을 고칠 필요는 없지만, 대표 레벨과 사용자 파라미터를 부르는 곳, 고른 이미터의 버전이 함께 제대로 동작하는지는 확인합니다.
팀의 작업 순서
팀으로 일할 때는 몇 가지 규칙을 정해 두면 좋습니다. 먼저 어떤 팀원이 어떤 나이아가라 시스템이나 이미터를 맡는지 분명히 해서 동시 수정을 줄입니다. 작은 변경이라도 자주 커밋해 충돌의 가능성을 줄이고, 문제가 생겼을 때 돌아갈 지점을 늘립니다. 커밋 메시지는 다른 팀원이 쉽게 알아볼 수 있도록 분명하고 자세하게 씁니다. 큰 변경이라면 풀 리퀘스트(Pull Request)나 리뷰로 다른 팀원의 검토를 거친 뒤 합치는 방식도 검토할 수 있으며, 이는 주로 Git을 쓰는 프로젝트에서 씁니다.
나이아가라 효과를 만드는 일은 끝없이 되풀이하며 다듬는 과정이고, 버전 관리는 그 과정을 안전하게 지켜 줍니다. 에디터의 버전 관리 기능을 익히고 나이아가라 에셋의 특성을 이해해 팀에 맞는 작업 순서를 세우면, 프로젝트 전체가 더 안정적으로 굴러갑니다.
정리
- 버전 관리는 실수에서 되돌아가고, 변경 기록을 따라가며, 여러 사람의 작업을 관리하고, 효과의 여러 버전을 나누는 데 씁니다.
- UE 5.3부터 에디터에서는 소스 컨트롤을 리비전 컨트롤이라고 부르며, 오른쪽 아래의 상태 버튼에서 공급자에 연결합니다.
- 체크아웃이 언제나 독점 잠금은 아니므로 Perforce의 독점 파일 형식이나 Git LFS의 잠금을 따로 확인하고, Git의 commit은 push해야 공유됩니다.
- 바이너리인 나이아가라 에셋은 줄 단위로 합칠 수 없으므로 동시 수정을 피하고, 작고 완결된 변경을 자주 올립니다.
- 이름을 바꾸거나 옮긴 뒤에는 에디터에서 리디렉터를 정리하고, 실제로 고친 패키지와 갱신된 참조 패키지를 한 변경에 함께 넣습니다.
연습 문제
1. 옮긴 시스템과 읽기 전용 블루프린트
시스템을 다른 폴더로 옮겼고, 그것을 참조하던 블루프린트 하나도 리디렉터를 정리하는 과정에서 다시 저장되어야 합니다. 그 블루프린트가 읽기 전용이라면 무엇을 먼저 해결해야 할까요? 옮긴 시스템만 공유하고 블루프린트의 변경을 빠뜨리면 무엇을 확인하지 못한 채 남을까요? 디스크 저장과 로컬 Git commit, 팀 공유의 상태도 구분해 보세요.
해설 보기
먼저 참조하는 블루프린트를 쓸 수 있게 열거나, 담당자와 이야기해 필요한 체크아웃과 수정 권한을 해결한 뒤 리디렉터 정리 결과를 확인합니다. 정리에 실패한 리디렉터를 파일 탐색기에서 지워 참조를 끊지 않습니다.
옮긴 시스템과 실제로 다시 저장한 참조 패키지는 하나의 완결된 변경으로 다룹니다. 블루프린트를 빠뜨리면 다른 사람의 프로젝트에서는 블루프린트가 여전히 예전 경로를 참조해, 그 효과가 제대로 열리는지 확인하지 못한 상태가 됩니다. 디스크에 저장한 것은 기록을 제출한 것이 아니고, Git commit은 로컬의 이력일 뿐입니다. 팀이 공유하려면 원격에 반영하고 동료가 업데이트를 받는 것까지 확인해야 합니다. 이 문제는 실제 버전 관리 작업을 해 본 결과를 말하는 것이 아닙니다.
2. 같은 시스템을 고친 두 사람
두 사람이 같은 NS_Explosion_Fire를 동시에 고쳐 한 사람은 스파크를 늘리고, 다른 사람은 연기의 색을 바꿨습니다. 나중에 올린 사람에게 충돌이 났습니다. 어떻게 해결해야 할까요?
해설 보기
바이너리 에셋은 두 변경을 줄 단위로 합칠 수 없으므로, 둘 가운데 하나를 기준으로 삼아야 합니다. 먼저 올라간 버전을 기준으로 받은 뒤, 나중에 올리려던 사람의 변경인 연기 색을 그 위에 다시 적용하고 결과를 확인해 올립니다.
다음부터는 고치기 전에 그 에셋의 담당자와 잠금 상태를 확인하고, 바이너리 파일에는 독점 잠금을 써서 같은 에셋을 동시에 고치는 일을 막습니다.
3. 되돌린 뒤에도 남아 있는 변경
체크아웃한 이미터를 Revert했는데, 에디터에 열려 있는 이미터 화면에는 고친 값이 그대로 보입니다. 되돌리기가 실패한 걸까요?
해설 보기
꼭 실패한 것은 아닙니다. Revert는 디스크의 파일을 체크아웃하기 전 상태로 되돌리지만, 에디터에 이미 열려 있던 에셋은 메모리에 예전 값을 가지고 있을 수 있습니다.
열린 에셋을 닫고 다시 열거나 새 디스크 상태로 다시 불러와 확인합니다. 그 상태에서 다시 저장하면 되돌린 내용을 덮어쓸 수 있으므로, 다시 불러오기 전에 저장하지 않도록 주의합니다.
나이아가라의 이미터와 모듈에 버전을 매기는 기능은 Epic의 모듈과 이미터 버전 관리 문서에서, 리디렉터의 정리는 에셋 리디렉터 문서에서 확인할 수 있습니다.
다음 글 나이아가라 이펙트 디버깅 기초에서는 효과가 보이지 않거나 이상하게 움직일 때 나이아가라 디버거와 속성 스프레드시트로 원인을 좁히는 방법을 살펴봅니다.