버전 관리에 중점을 두고 씬 및 프리팹을 제작하는 방법
관련주제
- #프리팹
- #파일잠금
- #씬
- #서브그래프
- #FBX
- #퍼포스
2024.10.07
Unity에서 콘텐츠를 제작하는 모범 사례(버전 관리 중심)
이 가이드의 목표는 버전 관리와 함께 작동하는 Unity에서 콘텐츠를 제작하는 모범 사례를 제공하는 것입니다. 버전 관리 사용에 대한 자세한 내용은 Unity의 버전 관리로 협업 강화 블로그 또는 버전 관리에 대한 심층적인 모범 사례 전자책에서 확인할 수 있습니다. 이 두 리소스 모두 버전 관리 작업에 대한 일반적인 정보를 담고 있지만, 이 블로그에서는 콘텐츠가 버전 관리와 통합되는 방법과 많은 크리에이터가 동시에 동일하거나 인접한 콘텐츠를 작업할 때 병합 충돌을 피하는 방법에 초점을 맞추고 있습니다.
.meta 파일
.meta 파일과 버전 관리에 대해 온라인에서 많은 혼란이 있습니다. .meta 파일은 항상 버전 관리에서 확인해야 합니다. 여기에는 에셋 간의 모든 참조를 연결하는 파일 GUID와 같은 중요한 정보가 포함되어 있습니다. 소스 파일과 동기화 상태를 유지해야 합니다(이름과 위치는 항상 연결된 소스 파일과 일치해야 합니다). 이러한 용도로 제작된 특정 툴이 없거나 .meta 파일의 기능을 완전히 이해하지 않는 한 에셋 파일을 Unity 에디터 외부로 이동하거나 이름을 변경하지 마세요.
기본 버전 관리 .meta 파일 모드는 운영 체제의 디스크에 있는 .meta 파일을 숨기지 않고 표시하는 파일 보기입니다. 퍼포스를 사용하는 경우 퍼포스 모드를 선택합니다.
스마트 병합
Unity와 버전 관리로 작업할 때 모든 팀이 가장 먼저 해야 할 일은 스마트 병합을 설정하는 것입니다. 기본적으로 Unity는 YAML 파일을 텍스트로 저장하므로 버전 관리에서 병합할 수 있습니다. 에셋 직렬화 모드를 바이너리로 변경하면 버전 관리에서 이러한 파일을 병합할 수 있는 기능이 제거됩니다.
Unity의 YAML 파일은 텍스트 기반이므로 많은 버전 관리 병합 소프트웨어가 텍스트 또는 코딩 규칙을 사용하여 병합을 시도합니다. 스마트 병합은 유니티에서 YAML 구조를 염두에 두고 병합하도록 설계되었습니다. 모든 YAML 파일에 대해 스마트 병합을 기본 병합 도구로 사용하는 것이 좋습니다.
스마트 병합을 사용하면 병합 충돌로 인한 작업 손실이 크게 줄어들지만, 팀에서 잠재적인 작업 손실에 대해 무관용 원칙을 적용하고 있다면 파일 잠금을 사용하고 모든 YAML 파일에 대해 수동 병합 충돌 해결을 시행하는 것이 좋습니다.
파일 잠금
파일 잠금은 여러 콘텐츠 제작자가 동시에 동일한 바이너리 파일(또는 YAML 파일)을 작업하는 대형 스튜디오에서 흔히 사용하는 방법입니다. Unity 버전 제어를 사용하면 잠긴 파일을 다른 사람이 체크아웃할 수 없습니다. Perforce는 누구도 잠긴 파일을 제출할 수 없도록 합니다.
Git을 사용하려면 파일 잠금을 지원하려면 Git LFS를 초기화해야 합니다. 대용량 콘텐츠 파일이 있고 버전 관리를 위해 Git을 사용하는 모든 프로젝트에 Git LFS를 사용하는 것이 좋습니다.
좋은 가이드라인과 도구
성공적인 팀은 종종 이름 지정 규칙, 폴더 구조, 에셋의 위치, 에셋 편집 방법에 관한 엄격한 가이드라인을 가지고 있습니다. 팀마다 상황이 다르기 때문에 하나의 보편적인 가이드라인은 존재하지 않습니다. 팀에 적합한 시스템을 선택하고 그 시스템이 작동하는 한 오랫동안 사용하는 것이 가장 중요합니다.
구체적이고 엄격한 가이드라인을 통해 콘텐츠를 검증하는 도구를 더 간단하게 개발할 수 있습니다. 이렇게 하면 버그가 게임에 유입되기도 전에 이를 방지할 수 있습니다. 에셋 위치와 이름이 명확해지면 코드와 도구로 콘텐츠를 검증하는 것이 훨씬 쉬워집니다. 그런 다음 에셋 포스트 프로세싱 및 프리셋을 통해 Unity 임포트 표준을 보다 쉽게 적용할 수 있습니다.
우려 사항 분리
콘텐츠를 제작할 때는 관심사 분리 원칙을 활용하는 것이 중요합니다. 콘텐츠를 어떻게 나누고 어디에 배치해야 하는지 생각하면 프로젝트가 깔끔하게 유지되고 대부분의 콘텐츠 제작자가 병합 충돌을 방지할 수 있습니다. 또한 특정 하위 장면이나 프리팹에 개별 기능이 있는 경우 검색 가능성 및 기능 전문가 온보딩에도 도움이 될 수 있습니다. 콘텐츠를 파일로 분리하는 데 사용할 수 있는 주요 빌딩 블록은 씬, 프리팹 및 서브그래프입니다.
장면
씬은 모든 Unity 애플리케이션의 매크로 빌딩 블록입니다. 각 장면은 파일에 직렬화(저장)되므로 소스 제어 및 동시 편집에 적합한 방식으로 콘텐츠를 구성하는 데 사용할 수 있습니다. 애디티브 씬 로딩은 종종 매우 큰 씬, 스트리밍 콘텐츠 또는 별도의 컴포넌트가 여러 개 있는 매우 단순한 씬을 제작하는 데 효과적으로 사용됩니다.
일반적으로 씬 종속 데이터는 씬에 저장하는 것이 좋습니다. 예를 들어 베이크된 조명, 조명, 라이트맵, 환경 설정의 경우 모두 어떤 씬에 있는지에 따라 달라집니다. 거의 모든 것을 프리팹에 저장할 수 있습니다. 씬이 작고 해당 씬 내에서만 편집되는 특정 콘텐츠가 있는 경우 해당 데이터를 모두 단일 씬에 저장하는 것이 좋습니다. 그러나 한 씬에 게임 오브젝트가 두 개 있는 경우, 그 중 하나를 변경하면 씬 파일이 변경된다는 점에 유의해야 합니다.
스마트 병합은 두 명의 콘텐츠 제작자가 씬에서 서로 다른 두 개의 오브젝트를 동시에 변경하는 시나리오를 처리해야 하지만, 더 정교한 변경은 해결할 수 없는 충돌을 초래할 수 있습니다. 이 문제를 완화하기 위해 프리팹을 활용하는 것이 좋습니다.
명시적인 씬 구조 측면에서 Unity 넷코드 데모에는 여러 시나리오에서 보았던 것과 유사한 간단한 프로젝트의 표준 씬 레이아웃에 대한 유용한 흐름도가 포함되어 있습니다.
프리팹
프리팹을 사용하여 모듈식 개별 콘텐츠를 제작할 수 있습니다. 자세한 내용은 프리팹 및 중첩된 프리팹에 대한 튜토리얼을 확인하세요. 이 튜토리얼에서 가장 중요한 섹션은 모범 사례 섹션입니다. 프리팹으로 콘텐츠를 제작하는 것에 대한 명시적인 규칙은 없습니다. 각 팀은 프로젝트에 따라 가장 적합한 방법을 결정해야 합니다. 하지만 따라야 할 몇 가지 좋은 가이드라인이 있습니다:
· 프리팹을 집 또는 프로젝트의 빌딩 블록으로 생각하세요. 일반적으로 집의 기초를 나타내는 루트 프리팹이 있습니다. 그 안에는 집의 나머지 부분을 구성하는 재사용 가능한 각 구성 요소에 대한 프리팹이 있습니다. 창턱처럼 세분화할 수도 있고 창문이 있는 벽처럼 넓게 만들 수도 있습니다. 필요한 세부 수준은 콘텐츠 제작자가 프리팹을 편집하려는 방식에 따라 달라집니다.
· 프리팹은 중첩할 수 있습니다. 즉, 위의 예시에서는 집을 구성하는 벽, 지붕, 창문, 문 프리팹이 있는 집 프리팹이 있을 수 있습니다. 프리팹을 중첩할 때 주의해야 할 한 가지 중요한 점은 계층 구조가 깊어질수록 프로젝트에 성능 문제가 발생할 가능성이 높아진다는 점입니다. 일반적으로 프리팹 계층 구조의 깊이를 5~7레벨 미만으로 유지하는 것이 좋습니다.
· 프리팹을 중첩할 때는 일반적으로 프리팹 모드에서 프리팹을 편집하는 것이 좋습니다. 이렇게 하면 프리팹 속성 또는 오버라이드가 적절한 위치에 설정됩니다. 씬 뷰에서 프리팹 프로퍼티를 편집하면 잘못된 프리팹이나 씬 자체에 오버라이드가 발생할 수 있습니다. 이로 인해 의도하지 않은 결과가 발생하고 병합 충돌이 발생할 수 있습니다. 때로는 부모 프리팹에서 자식 프리팹 프로퍼티를 재정의해야 하는 경우가 있습니다(이 방법으로 특정 프리팹에 대한 모든 참조에 영향을 주지 않고 변형을 수행할 수 있습니다). 이것은 표준 워크플로이지만 적절한 프리팹 또는 씬에서 변경하고 오버라이드를 적용하는 데 주의해야 합니다.
· 프리팹이 로드되고 인스턴스화될 때 런타임에 프리팹의 모든 항목이 메모리에 로드되고 인스턴스화됩니다. 즉, 시각 효과 또는 항상 존재하지 않는 첨부 오브젝트가 프리팹 내부에 있는 경우 해당 오브젝트가 메모리에 인스턴스화됩니다. 이렇게 하면 모든 프리팹이 인스턴스화될 때마다 그 안에 있는 모든 것을 인스턴스화하므로 메모리가 부풀어 오를 수 있습니다. 오브젝트에 가끔 시각 효과나 모델이 첨부되는 경우 런타임에 이러한 구성 요소를 추가하는 풀링 시스템과 첨부 관리자를 사용하는 것이 좋습니다. 풀링 시스템의 어떤 것도 일반적으로 프리팹 안에 배치해서는 안 됩니다.
· 모든 것이 프리팹일 필요는 없습니다. 더 작은 빌딩 블록은 프리팹 또는 씬 내부의 게임 오브젝트가 될 수 있습니다. 오브젝트가 씬이나 프리팹에 고유한 경우 해당 프리팹을 만들 필요가 없습니다.
· 프리팹 변형은 신중하게 사용해야 합니다. 일반적으로 프리팹 변형은 개체의 핵심 구성 요소가 단순한 차이점만 있을 뿐 동일할 때 가장 잘 활용됩니다. 예를 들어 기능은 동일하지만 비주얼이 다른 게임 컴포넌트에 프리팹 변형을 사용하는 것이 도움이 될 수 있습니다. 이 시나리오에서 핵심 기능을 변경하면 프리팹과 그 변형의 기능에 모두 영향을 주지만 비주얼은 재정의된 상태로 유지됩니다. 루트 프리팹을 변경하면 재정의된 프리팹에 의도하지 않은 결과가 발생할 수 있으므로 지나치게 복잡한 프리팹 변형을 만들 때는 주의해야 합니다. 일반적으로 캐릭터 변형 시스템이나 기타 복잡한 시각적 스킨 시스템과 같은 것은 시스템이 매우 단순하지 않는 한 프리팹 변형에 기반해서는 안 됩니다.
프리팹 또는 씬 내에서 무엇이 프리팹이고 무엇이 게임 오브젝트인지 결정하기 위한 일관된 전략을 세우는 것이 좋습니다.
FBX 및 프리팹
프리팹을 FBX 파일에서 직접 생성하는 경우 모델 프리팹이라는 특수한 종류의 프리팹이 생성됩니다. 그 결과 프리팹 변형 FBX 파일이 생성됩니다. 추가 또는 변경 사항은 프리팹 파일에 오버라이드로 저장됩니다. 그러나 대부분의 데이터는 FBX 파일에 저장되므로 프리팹을 변경하거나 추가해도 모델 프리팹에 적용할 수 없습니다. 모델 프리팹 변형 워크플로우를 사용하는 경우 구조 변경을 최소화하는 것이 중요합니다.
FBX 모델과 프리팹 사이에 덜 긴밀하게 결합된 구조를 허용하는 두 가지 대체 워크플로가 있습니다:
FBX 파일을 씬에 직접 추가한 다음 씬의 게임 오브젝트에 컴포넌트나 구조적 수정을 추가합니다. 이 시나리오에서는 이제 모든 변경 사항이 씬 파일에 저장됩니다. 많은 사람이 같은 장면에서 이 워크플로를 사용하는 경우 병합 충돌이 발생할 수 있습니다. 변경 사항이 씬에 적용되어야 하고 충돌이 문제가 되지 않는 경우에만 이 워크플로우를 권장합니다.
분해된 모델에서 표준 Unity 프리팹을 생성합니다. 이 방법에서는 FBX 모델을 씬으로 드래그한 다음 완전히 언패킹합니다. 그런 다음 프리팹을 만드는 데 사용됩니다. 이 방법론은 프리팹에서 FBX 파일을 완전히 분리합니다. FBX 파일과 프리팹 사이에 매우 느슨한 결합이 필요한 경우에 유용합니다. 더 이상 원본 FBX 파일에 적용된 구조적 변경 사항을 상속하지 않습니다. 결합은 메시, 머티리얼 및 애니메이션의 이름 사이에서만 이루어집니다. 그 외의 모든 것은 프리팹 파일 자체에 저장됩니다. 이는 완전히 고유한 FBX 모델의 배리언트를 만드는 데 유용할 수 있습니다. 예를 들어 두 캐릭터가 동일한 모델을 사용하지만 완전히 다른 메시, 머티리얼 또는 다른 계층구조가 필요한 경우 이 방법론이 메모리와 디스크 공간을 추가로 차지하는 여러 개의 FBX 파일을 만드는 것보다 나을 수 있습니다.이 방법에서 한 가지 주의할 점은 원본 FBX 파일에서 메시 또는 머티리얼 이름이 변경되면 오브젝트가 사라지지 않고 대신 누락된 메시 또는 머티리얼이 참조된다는 점입니다. 매우 복잡한 컴포넌트 설정이 필요할 때 유용하게 사용할 수 있습니다. 게임 오브젝트가 사라지고 모든 컴포넌트가 손실되는 대신 오브젝트는 그대로 유지되고 컴포넌트는 새 오브젝트로 전송되거나 이름이 변경된 메시 또는 머티리얼을 이제 사라진 메시 또는 머티리얼을 참조하는 게임 오브젝트에 다시 슬롯에 넣을 수 있습니다.
아래 두 이미지에서는 FBX 파일을 변경한 다음 다시 임포트합니다. 공의 유니티 로고 주변의 원이 삭제됩니다. 메인 서포트 스탠드의 이름이 변경됩니다. 메인 볼의 소재가 검은색에서 녹색으로 변경되고 스탠드 로고 위에 새로운 모체가 도입되어 모델 위로 올라가는 변형이 생겼습니다.
이 모든 것은 FBX 파일과 모델 프리팹 모두에서 밀접하게 일치합니다. 모델이 아닌 프리팹에서는 원래 계층 구조, 이름 및 머티리얼이 유지됩니다. 삭제된 메시는 이제 누락된 메시이지만 게임 오브젝트는 여전히 존재합니다. 이름이 변경된 메시도 모델에 더 이상 존재하지 않는 메시 이름을 참조하기 때문에 표시되지 않습니다. 게임 오브젝트가 여전히 원본 머티리얼을 참조하고 있기 때문에 변경된 머티리얼은 업데이트되지 않습니다. 또한 계층 구조 변경이 존중되지 않고 부모가 변경되지 않았기 때문에 메시가 같은 위치에 유지됩니다.
셰이더 그래프 또는 시각 효과 그래프와 같은 그래프 툴의 경우, 셰이더 그래프 서브그래프와 시각 효과 그래프 서브그래프를 사용하여 별도의 파일에 있는 재사용 가능한 함수 노드를 만들 수 있으며 모든 셰이더 그래프 또는 시각 효과 그래프에서 충돌을 일으키지 않고 편집할 수 있습니다. 이를 통해 사용자는 프리팹 및 씬과 유사한 방식으로 관심사를 분리할 수 있습니다. 가장 적합한 하위 그래프를 활용하여 재사용성을 위한 전략을 세우는 것이 좋습니다.
깊은 계층구조를 피하는 것은 씬, 프리팹, 게임 오브젝트, 애니메이션, UI 등 모든 콘텐츠에 적용되는 보편적인 원칙입니다. 일반적으로 모든 종류의 깊은 계층 구조는 성능 문제를 일으키는 경향이 있습니다. 캐릭터의 애니메이션 계층 구조가 깊어지면 CPU 성능 문제로 인해 화면에 그릴 수 있는 캐릭터 수가 줄어듭니다. 따라서 모든 애니메이션 계층구조를 씬의 루트 노드에 배치하는 것이 성능에 도움이 됩니다. UI 및 캔버스를 사용할 때 플랫 계층 구조를 선택하면 계단식 레이아웃 업데이트가 줄어들어 성능이 향상됩니다. 깊이 중첩된 프리팹은 성능 문제를 일으킬 수 있으며 오버라이드를 주의 깊게 관리하지 않으면 혼란을 초래할 수도 있습니다.
팀에서 네트워크 드라이브부터 로컬 컴퓨터에 이르기까지 다양한 위치에 소스 콘텐츠를 저장하는 경우가 많습니다. 모든 중요한 소스 콘텐츠를 어떤 식으로든 버전 관리에 넣을 것을 권장합니다.
이 모든 것은 FBX 파일과 모델 프리팹 모두에서 밀접하게 일치합니다. 모델이 아닌 프리팹에서는 원래 계층 구조, 이름 및 머티리얼이 유지됩니다. 삭제된 메시는 이제 누락된 메시이지만 게임 오브젝트는 여전히 존재합니다. 이름이 변경된 메시도 모델에 더 이상 존재하지 않는 메시 이름을 참조하기 때문에 표시되지 않습니다. 게임 오브젝트가 여전히 원본 머티리얼을 참조하고 있기 때문에 변경된 머티리얼은 업데이트되지 않습니다. 또한 계층 구조 변경이 존중되지 않고 부모가 변경되지 않았기 때문에 메시가 같은 위치에 유지됩니다.
아래 이미지의 전후 이미지에는 위에서 변경한 결과가 씬 계층 구조에 표시됩니다. 씬에서 직접 참조되는 FBX 파일과 표준 모델 프리팹은 원본 FBX 파일에 대한 변경 사항에 반응합니다. 압축이 풀린 프리팹은 원래 계층 구조를 유지하며 삭제나 이름 변경에 반응하지 않습니다.
주어진 시나리오에서 어떤 방법론을 사용할지 신중하게 결정하는 것이 중요합니다. 에디터와 FBX 파일 간에 긴밀한 결합이 필요한 경우 표준 모델인 프리팹이 가장 적합합니다. 매우 느슨한 결합이 필요한 경우(예: 메시나 머티리얼을 자주 교체할 수 있는 매우 유연한 캐릭터 시스템) FBX 파일의 컴포넌트에 대한 소프트 레퍼런스를 사용하여 모델이 아닌 프리팹을 만드는 것이 더 효과적입니다.
하위 그래프
셰이더 그래프 또는 시각 효과 그래프와 같은 그래프 툴의 경우, 셰이더 그래프 서브그래프와 시각 효과 그래프 서브그래프를 사용하여 별도의 파일에 있는 재사용 가능한 함수 노드를 만들 수 있으며 모든 셰이더 그래프 또는 시각 효과 그래프에서 충돌을 일으키지 않고 편집할 수 있습니다. 이를 통해 사용자는 프리팹 및 씬과 유사한 방식으로 관심사를 분리할 수 있습니다. 가장 적합한 하위 그래프를 활용하여 재사용성을 위한 전략을 세우는 것이 좋습니다.
깊은 계층 구조 피하기
깊은 계층구조를 피하는 것은 씬, 프리팹, 게임 오브젝트, 애니메이션, UI 등 모든 콘텐츠에 적용되는 보편적인 원칙입니다. 일반적으로 모든 종류의 깊은 계층 구조는 성능 문제를 일으키는 경향이 있습니다. 캐릭터의 애니메이션 계층 구조가 깊어지면 CPU 성능 문제로 인해 화면에 그릴 수 있는 캐릭터 수가 줄어듭니다. 따라서 모든 애니메이션 계층구조를 씬의 루트 노드에 배치하는 것이 성능에 도움이 됩니다. UI 및 캔버스를 사용할 때 플랫 계층 구조를 선택하면 계단식 레이아웃 업데이트가 줄어들어 성능이 향상됩니다. 깊이 중첩된 프리팹은 성능 문제를 일으킬 수 있으며 오버라이드를 주의 깊게 관리하지 않으면 혼란을 초래할 수도 있습니다.
소스 콘텐츠
팀에서 네트워크 드라이브부터 로컬 컴퓨터에 이르기까지 다양한 위치에 소스 콘텐츠를 저장하는 경우가 많습니다. 모든 중요한 소스 콘텐츠를 어떤 식으로든 버전 관리에 넣을 것을 권장합니다.
가장 일반적인 방법은 Assets 폴더 밖에 있는 버전 관리의 폴더에 소스 콘텐츠를 넣는 것입니다. 이렇게 하면 Unity가 소스 파일에서 콘텐츠를 직접 임포트하려고 시도하지 않습니다. Maya, 3ds Max, Blender, Photoshop 파일은 에셋 폴더의 아무 곳에나 배치하면 모델과 텍스처로 자동 임포트됩니다. 유니티는 이를 지원하지만, 이 방법을 권장하지는 않습니다. 또한 자산을 비교적 쉽게 추적할 수 있도록 소스 디렉터리를 Assets 디렉터리의 콘텐츠에 미러링하는 것이 좋습니다.
대부분의 사용자는 소스 콘텐츠를 모두 필요로 하지 않으며 소스 콘텐츠는 디스크 용량이 매우 클 수 있으므로(테라바이트 단위) 사용자가 마스킹할 수 있어야 합니다. 일부 버전 관리 소프트웨어에서는 콘텐츠 마스크를 만드는 것이 매우 간단합니다. Unity 버전 관리에서는 클로킹된 파일을 사용하여 이 작업을 수행합니다. 퍼포스에서 뷰는 클라이언트에서 콘텐츠를 마스킹하는 데 사용됩니다. 하지만 Git은 이런 방식으로 작동하도록 설계되지 않았습니다. 따라서 소스 콘텐츠에 대해 별도의 Git 리포지토리를 만들거나 콘텐츠 유형별로 별도의 리포지토리를 만드는 것이 좋습니다(예: 3D 아티스트는 전체 오디오 소스를 동기화할 필요가 없을 수 있고 그 반대의 경우도 마찬가지입니다).
버전 관리와 함께 작동하고 같은 영역에서 작업하는 여러 사용자를 지원하는 콘텐츠를 만드는 것은 어려운 작업입니다. 하지만 유니티는 신중한 고민과 계획을 통해 해결할 수 없는 병합 충돌이나 작업 손실이 발생하지 않는 대규모 콘텐츠를 제작할 수 있는 빌딩 블록을 제공합니다.
