Unity 프로젝트를 구성하기 위한 모범 사례

Unity 프로젝트를 구성하는 단일 방법은 없지만, 다음은 몇 가지 주요 권장 사항입니다:

• 명명 규칙 및 폴더 구조를 문서화하세요. 스타일 가이드 및/또는 프로젝트 템플릿은 파일을 더 쉽게 찾고 구성할 수 있게 합니다. 팀에 맞는 것을 선택하고 모든 사람이 이에 동의하도록 하세요.
• 이름 규칙을 일관되게 유지하세요. 선택한 스타일 가이드나 템플릿에서 벗어나지 마세요. 이름 규칙을 수정해야 하는 경우, 영향을 받는 자산을 한 번에 파싱하고 이름을 변경하세요. 변경 사항이 많은 파일에 영향을 미치는 경우, 스크립트를 사용하여 업데이트를 자동화하는 것을 고려하세요.
• 파일 및 폴더 이름에 공백을 사용하지 마세요. Unity의 명령줄 도구는 공백이 포함된 경로 이름에 문제가 있습니다. 공백 대신 CamelCase를 사용하세요.
• 테스트 또는 샌드박스 영역을 분리하세요. 비생산 장면 및 실험을 위한 별도의 폴더를 만드세요. 사용자 이름이 포함된 하위 폴더는 팀원별로 작업 영역을 나눌 수 있습니다.
• 루트 수준에서 추가 폴더를 피하세요. 일반적으로, 콘텐츠 파일은 Assets 폴더 내에 저장하세요. 절대적으로 필요하지 않는 한 프로젝트의 루트 수준에서 추가 폴더를 만들지 마세요.
• 내부 자산을 서드파티 자산과 분리하세요. Asset Store 또는 다른 플러그인에서 자산을 사용하는 경우, 그들은 자체 프로젝트 구조를 가지고 있을 가능성이 높습니다. 자신의 자산을 분리하세요.

참고: 프로젝트를 위해 서드파티 자산이나 플러그인을 수정해야 하는 경우, 버전 관리를 통해 플러그인의 최신 업데이트를 받을 수 있습니다. 업데이트가 가져와지면, 수정 사항이 덮어쓰여졌을 수 있는 부분을 확인하고 다시 구현할 수 있습니다.

정해진 폴더 구조는 없지만, 다음 두 섹션은 Unity 프로젝트를 설정하는 방법의 예를 보여줍니다. 이 구조는 자산 유형별로 프로젝트를 나누는 데 기반하고 있습니다.

자산 유형 매뉴얼 페이지는 가장 일반적인 자산에 대해 더 자세히 설명합니다. 폴더 구조를 구성할 때 템플릿 또는 학습 프로젝트를 사용하여 추가 영감을 얻을 수 있습니다. 이 폴더 이름에 제한되지 않지만, 좋은 출발점을 제공할 수 있습니다.

Unity Hub에서 템플릿 또는 스타터 프로젝트 중 하나를 다운로드하면, 하위 폴더가 자산 유형별로 나누어져 있는 것을 알 수 있습니다. 선택한 템플릿에 따라 여러 일반 자산을 나타내는 하위 폴더가 표시되어야 합니다.

처음부터 강력한 프로젝트 구조를 정의하면 나중에 버전 관리 문제를 피하는 데 도움이 될 수 있습니다. 자산을 한 폴더에서 다른 폴더로 이동하면, 많은 VCS는 이를 파일을 삭제하고 다른 파일을 추가하는 것으로 인식합니다. 이로 인해 원본 파일의 기록이 손실됩니다.

Plastic SCM은 Unity 내에서 파일 이동을 처리하고 이동된 파일의 기록을 보존할 수 있습니다. 그러나 .meta 파일이 자산 파일과 함께 이동하도록 에디터 내에서 파일을 이동하는 것이 필수적입니다.

프로젝트에 대한 폴더 구조를 결정한 후, 에디터 스크립트를 사용하여 템플릿을 재사용하고 모든 프로젝트에 대해 동일한 폴더 구조를 생성하십시오. 에디터 폴더에 배치되면, 아래 스크립트는 "PROJECT_NAME" 변수와 일치하는 자산의 루트 폴더를 생성합니다. 이렇게 하면 자신의 작업을 서드파티 패키지와 분리할 수 있습니다.

빈 폴더는 버전 관리에서 문제를 일으킬 위험이 있으므로, 정말 필요한 것만 폴더를 생성하도록 하십시오. Git과 Perforce에서는 빈 폴더가 기본적으로 무시됩니다. 이러한 프로젝트 폴더가 설정되어 있고 누군가가 이를 커밋하려고 하면, 폴더에 무언가가 배치될 때까지 실제로 작동하지 않습니다.

참고: 일반적인 우회 방법은 빈 폴더 안에 “.keep” 파일을 배치하는 것입니다. 이것은 폴더가 리포지토리에 커밋되도록 충분합니다.

Plastic SCM은 빈 폴더를 처리할 수 있습니다. Plastic SCM은 각기 다른 버전 기록이 첨부된 엔티티로 디렉토리를 처리합니다.

Unity에서 작업할 때 염두에 두어야 할 사항입니다. Unity는 프로젝트의 모든 파일에 대해 .meta 파일을 생성하며, 여기에는 폴더도 포함됩니다. Git과 Perforce를 사용하면 유저가 빈 폴더에 대한 .meta 파일을 쉽게 커밋할 수 있지만, 폴더 자체는 버전 관리에 포함되지 않습니다. 다른 유저가 최신 변경 사항을 가져오면, 그들의 컴퓨터에 존재하지 않는 폴더에 대한 .meta 파일이 생기고, Unity는 그 .meta 파일을 삭제합니다. Plastic SCM은 빈 폴더를 버전 관리에 포함시켜 이 문제를 완전히 피합니다.

Unity는 프로젝트 내의 다른 모든 파일에 대해 .meta 파일을 생성하며, 일반적으로 자동 생성된 파일을 버전 관리에 포함하는 것은 바람직하지 않지만, .meta 파일은 조금 다릅니다. 버전 관리 창에서 Visible Meta Files 모드를 켜야 합니다(내장된 Plastic SCM 또는 Perforce 모드를 사용하지 않는 경우).

.meta 파일은 자동 생성되지만, 그것이 연관된 파일에 대한 많은 정보를 담고 있습니다. 이는 텍스처, 메시, 오디오 클립 등과 같은 가져오기 설정이 있는 자산에 일반적입니다. 이 파일들의 가져오기 설정을 변경하면, 변경 사항이 .meta 파일에 기록됩니다(자산 파일이 아닌). 그래서 .meta 파일을 리포지토리에 커밋하는 것입니다 – 모든 사람이 동일한 파일 설정으로 작업할 수 있도록 하기 위해서입니다.

기준에 대한 합의는 프로젝트 폴더 구조에서 멈추지 않습니다. 모든 게임 자산에 대해 특정 명명 기준을 설정하면 팀이 서로의 파일에서 작업할 때 더 쉽게 만들 수 있습니다.

GameObjects에 대한 확정적인 명명 기준은 없지만, 위의 표를 고려해 보세요.

단일 대형 Unity 씬은 협업에 잘 맞지 않습니다. 레벨을 여러 개의 작은 씬으로 나누어 아티스트와 디자이너가 단일 레벨에서 원활하게 협업할 수 있도록 하여 충돌의 위험을 최소화하세요.

런타임에서 프로젝트는 LoadSceneMode.Additive 매개변수를 전달하여 SceneManager를 사용하여 장면을 추가적으로 로드할 수 있습니다.

가능한 경우 작업을 Prefab으로 나누고 중첩 Prefab의 힘을 활용하는 것이 모범 사례입니다. 나중에 변경이 필요하면 장면에서가 아니라 Prefab을 변경하여 다른 사람이 작업 중인 장면과의 충돌을 피할 수 있습니다. Prefab 변경 사항은 버전 제어에서 차이를 비교할 때 읽기 쉬운 경우가 많습니다.

장면 충돌이 발생하는 경우 Unity는 장면과 Prefab을 병합하는 데 사용되는 내장 YAML(사람이 읽을 수 있는 데이터 직렬화 언어) 도구도 제공합니다. 자세한 내용은 Unity 문서의 스마트 병합을 참조하십시오.

프리셋을 사용하면 검사기에서 거의 모든 항목의 기본 상태를 사용자 정의할 수 있습니다. 프리셋을 생성하면 선택한 구성 요소 또는 자산의 설정을 복사하고 이를 자체 자산으로 저장한 다음 나중에 다른 항목에 동일한 설정을 적용할 수 있습니다.

프리셋을 사용하여 표준을 강제하거나 새로운 자산에 합리적인 기본값을 적용하십시오. 이들은 팀 전반에 걸쳐 일관된 표준을 보장하는 데 도움이 될 수 있으므로 일반적으로 간과되는 설정이 프로젝트 성능에 영향을 미치지 않도록 합니다.

구성 요소의 오른쪽 상단에 있는 프리셋 아이콘을 클릭하십시오. 프리셋을 자산으로 저장하려면 현재 저장…를 클릭한 다음 사용할 수 있는 프리셋 중 하나를 선택하여 값 세트를 로드하십시오.

프리셋을 사용하는 다른 유용한 방법은 다음과 같습니다:

• 기본값으로 게임 오브젝트 만들기: 프리셋 자산을 계층으로 드래그 앤 드롭하여 프리셋 값이 포함된 해당 구성 요소가 있는 새로운 게임 오브젝트를 만듭니다.
• 프리셋과 특정 유형 연결: 프리셋 관리자(프로젝트 설정 > 프리셋 관리자)에서 유형당 하나 이상의 프리셋을 지정하십시오. 새 구성 요소를 만들면 지정된 프리셋 값이 기본값으로 설정됩니다.
• 전문가 팁: 유형당 여러 프리셋을 만들고 필터를 사용하여 이름으로 올바른 프리셋을 연결하십시오.
• 관리자 설정 저장 및 로드: 프리셋을 매니저 창에 사용하여 설정을 재사용할 수 있습니다. 예를 들어, 동일한 태그와 레이어 또는 물리 설정을 다시 적용할 계획이라면, 프리셋을 사용하면 다음 프로젝트의 설정 시간을 줄일 수 있습니다.

코딩 표준은 팀의 작업을 일관되게 유지하여 개발자가 프로젝트의 다양한 영역 간에 쉽게 전환할 수 있도록 합니다. 다시 말해, 여기에는 확고한 규칙이 없습니다. 팀에 가장 적합한 것을 결정해야 합니다. 그러나 일단 결정을 내리면 그것을 고수해야 합니다.

예를 들어, 네임스페이스는 코드를 더 정확하게 구성할 수 있습니다. 네임스페이스를 사용하면 프로젝트 내에서 모듈을 분리하고 클래스 이름이 반복될 수 있는 서드파티 자산과의 충돌을 피할 수 있습니다.

참고: 코드에서 네임스페이스를 사용할 때는 더 나은 조직을 위해 네임스페이스별로 폴더 구조를 나누십시오.

표준 헤더도 권장됩니다. 코드 템플릿에 표준 헤더를 포함하면 클래스의 목적, 생성 날짜 및 생성자를 문서화하는 데 도움이 됩니다. 본질적으로 버전 관리를 사용하더라도 프로젝트의 긴 역사에서 쉽게 잃어버릴 수 있는 모든 정보입니다.

Unity는 프로젝트에서 새 MonoBehaviour를 만들 때 읽기 위해 스크립트 템플릿을 사용합니다. 새 스크립트나 셰이더를 만들 때마다 Unity는 %EDITOR_PATH%\Data\Resources\ScriptTemplates에 저장된 템플릿을 사용합니다:

• Windows: C:\Program Files\Unity\Editor\Data\Resources\ScriptTemplates
• Mac: /Applications/Hub/Editor/[version]/Unity/Unity.app/Contents/ Resources/ScriptTemplates

기본 MonoBehaviour 템플릿은 다음과 같습니다: 81-C# Script-NewBehaviourScript.cs.txt

셰이더, 기타 행동 스크립트 및 어셈블리 정의에 대한 템플릿도 있습니다.

프로젝트별 스크립트 템플릿을 위해 Assets/ScriptTemplates 폴더를 만들고 이 폴더에 스크립트 템플릿을 복사하여 기본값을 덮어씌우십시오.

모든 프로젝트에 대해 기본 스크립트 템플릿을 직접 수정할 수도 있지만, 변경하기 전에 원본을 백업하는 것을 잊지 마십시오. 각 Unity 버전은 고유한 템플릿 폴더를 가지고 있으므로, 새 버전으로 업데이트할 때 템플릿을 다시 교체해야 합니다. 아래의 코드 예제는 원래의 81-C# Script-NewBehaviourScript.cs.txt 파일이 어떻게 생겼는지를 보여줍니다.

아래 예제에는 도움이 될 수 있는 두 개의 키워드가 있습니다:

• #SCRIPTNAME#은 입력된 파일 이름 또는 기본 파일 이름(예: NewBehaviourScript)을 나타냅니다.
• #NOTRIM#은 괄호 안에 공백 줄이 포함되도록 보장합니다.

자신의 키워드를 사용하고 이를 편집기 스크립트로 교체하여 OnWillCreateAsset 메서드를 구현할 수 있습니다.

다음 스크립트 예제의 헤더를 스크립트 템플릿 내에서 사용하세요. 이렇게 하면 모든 새로운 스크립트가 날짜, 생성한 사용자 및 원래 속했던 프로젝트를 보여주는 헤더와 함께 생성됩니다. 이는 향후 프로젝트에서 코드를 재사용하는 데 유용합니다.