Quick Reference
폴더는 찾기와 ownership을 정리하지만, folder 이름만으로 build inclusion·runtime load·assembly boundary가 자동으로 결정되지는 않습니다. 내부 제작물, 외부 package, test/sandbox, generated output의 책임을 나누고 각 build policy는 Build Profiles/Addressables/asmdef에서 별도로 확인합니다.
Assets/
Game/ # 팀이 소유하는 gameplay·art·scenes·prefabs
ThirdParty/ # 외부 asset의 원본과 update 경계
Tests/ # test assemblies와 fixtures
_Dev/ # sandbox, profiling, migration tools구조를 나누는 기준
Game/ 아래를 Art, Audio, Prefabs, Scenes, Scripts로 나누는 방식은 시작점일 뿐입니다. 규모가 커지면 feature 단위로 code·prefab·data를 가까이 둘지, asset type 단위로 유지할지를 팀이 고릅니다. 중요한 것은 한 asset의 owner, source of truth, 생성 경로를 쉽게 찾을 수 있는가입니다.
ThirdParty는 internal modifications를 섞지 않는 update boundary입니다. vendor asset을 수정해야 한다면 wrapper, extension, patch 기록 중 어떤 방식으로 upgrade를 재현할지 정합니다. copied third-party file을 Game folder에 흩뿌리면 license·upgrade·diff의 출처가 사라집니다.
folder 밖의 build 정책
_Dev, Sandbox, Tests 이름은 사람에게 의도를 보여 줄 뿐, scene이 player build에 자동 제외된다는 보장은 없습니다. build scene list/Build Profile, Addressables group, Resources 폴더, code asmdef platform filters가 실제 inclusion을 결정합니다.
| 정책 | 확인 위치 | 흔한 실수 |
|---|---|---|
| player scene 포함 | Build Profile/scene list | dev scene이 folder 밖이라서 제외된다고 가정 |
| runtime asset load | Addressables/Resources policy | asset path만 보고 build 포함을 추측 |
| test code 포함 | asmdef test assembly·platform | test helper가 player assembly에 들어감 |
| external plugin platform | Plugin Import Settings | 모든 platform build에 native plugin이 들어감 |
folder move/rename은 .meta를 포함한 version-control change set으로 다룹니다. 대규모 move와 content editing을 같은 commit에 섞으면 merge conflict와 missing reference 원인을 분리하기 어렵습니다.
자주 틀리는 부분
| 증상 | 원인 | 수정 |
|---|---|---|
| dev scene이 release에 포함 | folder 이름만 exclusion으로 생각 | Build Profile scene list 확인 |
| third-party update가 internal code를 덮음 | vendor source를 직접 수정 | wrapper/patch와 source boundary 유지 |
| asset 참조가 이동 뒤 끊김 | meta 동반 이동이 아님 | asset·meta를 함께 move하고 import 검증 |
| Scripts folder가 너무 커서 owner를 못 찾음 | feature/asset type 기준이 섞임 | 한 기준을 문서화하고 신규 asset부터 일관 적용 |
Resources에 모든 것을 넣음 | convenience와 build/load cost를 혼동 | Addressables 또는 명시적 load policy 검토 |
참고 링크
3 sources