게임 개발 프로젝트 폴더 구조와 에셋 네이밍 컨벤션 표준화 가이드
게임 개발 프로젝트의 폴더 구조와 에셋 네이밍 규칙을 표준화해 탐색 시간, 중복 제작, 머지 충돌을 줄이는 방법을 정리합니다. Unity·Unreal·Git 협업에 바로 적용할 수 있는 구조, 규칙, 도입 절차와 점검표를 제공합니다.
핵심 요약
프로젝트 폴더 구조와 에셋 이름은 팀원이 파일의 소유자·용도·상태·종류를 예측할 수 있게 만드는 운영 규칙이다. 최상위 폴더의 책임을 고정하고 에셋 이름을 접두사_기능_변형_번호처럼 기계적으로 해석 가능한 형식으로 통일하면 탐색 시간과 중복 제작, Git 머지 충돌을 함께 줄일 수 있다.
핵심은 완벽한 분류 체계가 아니라 새 파일을 만들 때 누구나 같은 위치와 같은 이름을 선택하도록 만드는 최소 규칙이다.
프로젝트 폴더 구조 표준화는 왜 필요한가?
게임 프로젝트에서 폴더 구조가 흔들리면 파일 탐색만 어려워지는 것이 아니다. 동일한 프리팹, 머티리얼, 사운드가 여러 위치에 생기고 참조 경로를 찾기 어려워지며 삭제 후보도 판단하기 힘들어진다. 특히 Unity의 .meta 파일과 Unreal Engine의 .uasset은 파일 이동과 이름 변경이 참조 관계에 영향을 줄 수 있으므로 에디터 밖에서 임의로 정리하는 습관은 위험하다.
폴더 표준화의 목적은 다음 네 가지다.
| 목적 | 해결하는 문제 | 확인 지표 예시 |
|---|---|---|
| 탐색성 | 파일 위치를 추측할 수 없음 | 에셋 검색·탐색 시간 |
| 중복 방지 | 같은 용도의 리소스를 다시 제작함 | 중복 프리팹·텍스처 수 |
| 소유권 명확화 | 수정 담당자를 알 수 없음 | 리뷰·수정 요청 왕복 횟수 |
| 변경 안전성 | 이동·삭제 시 참조가 깨짐 | 누락 참조, 빌드 실패 건수 |
폴더 구조는 기능 중심으로 나눠야 할까, 에셋 타입 중심으로 나눠야 할까?
정답은 프로젝트 규모와 재사용 범위에 따라 달라진다. 다만 실무에서는 최상위는 기능 또는 도메인 중심, 그 아래는 에셋 타입 중심으로 두는 혼합형이 가장 관리하기 쉽다.
| 방식 | 장점 | 단점 | 적합한 경우 |
|---|---|---|---|
| 타입 중심 | Textures, Materials, Audio를 빠르게 찾음 | 한 기능의 관련 파일이 흩어짐 | 소규모 프로토타입 |
| 기능 중심 | 특정 레벨·캐릭터의 관련 파일을 함께 관리 | 공용 리소스 위치가 모호해질 수 있음 | 기능 팀이 분리된 중대형 프로젝트 |
| 혼합형 | 기능 응집도와 공용 에셋 관리의 균형 | 초기 규칙 문서가 필요 | 대부분의 상용 게임 프로젝트 |
권장 게임 프로젝트 폴더 구조 예시
아래 구조는 Unity의 Assets 폴더나 Unreal Engine의 Content 폴더 내부에 적용할 수 있다. 엔진 기본 폴더와 팀 제작 폴더를 섞지 않는 것이 핵심이다.
Assets/
├─ _Project/
│ ├─ Art/
│ │ ├─ Characters/
│ │ ├─ Environments/
│ │ ├─ UI/
│ │ └─ VFX/
│ ├─ Audio/
│ │ ├─ BGM/
│ │ ├─ SFX/
│ │ └─ Voice/
│ ├─ Code/
│ │ ├─ Runtime/
│ │ ├─ Editor/
│ │ └─ Tests/
│ ├─ Design/
│ │ ├─ Combat/
│ │ ├─ Characters/
│ │ └─ Levels/
│ ├─ Prefabs/
│ ├─ Scenes/
│ ├─ Settings/
│ └─ UI/
├─ _ThirdParty/
│ ├─ Plugins/
│ └─ Packages/
├─ _Tests/
└─ _Archive/_Project처럼 팀 소유 리소스를 하나의 접두사 폴더로 묶으면 외부 플러그인과 제작물을 쉽게 구분할 수 있다. 언더스코어 접두사는 폴더를 정렬 상단에 고정하려는 목적일 때만 사용하고 모든 폴더에 남용하지 않는다.
최상위 폴더별 운영 원칙
| 폴더 | 포함할 항목 | 포함하지 말아야 할 항목 |
|---|---|---|
_Project | 팀이 직접 제작·수정하는 게임 리소스 | 마켓플레이스 원본 패키지 |
_ThirdParty | 외부 SDK, 에셋 스토어 패키지, 라이선스 문서 | 팀 수정본과 임시 테스트 파일 |
_Tests | 자동화 테스트 전용 씬, 더미 데이터 | 실제 배포에 필요한 게임 콘텐츠 |
_Archive | 승인된 폐기 후보, 이전 마일스톤 스냅샷 | 아직 참조 여부를 확인하지 않은 파일 |
에셋 네이밍 컨벤션은 어떻게 설계할까?
에셋 이름은 사람이 읽기 쉽고 도구가 분류하기 쉬워야 한다. 다음 형식을 기본 규칙으로 권장한다.
[TypePrefix]_[FeatureOrObject]_[Descriptor]_[VariantOrIndex]예를 들면 PF_PlayerMage_Combat_01, MAT_EnvStone_Wet, SFX_UI_ButtonClick_01처럼 작성한다. 공백, 한글, 의미 없는 final, new, copy는 피한다. 파일명은 대소문자 구분 환경에서도 안전하도록 PascalCase 또는 고정된 snake_case 중 하나만 선택해 팀 전체에서 유지한다.
권장 접두사 표준
| 에셋 종류 | 접두사 | 예시 |
|---|---|---|
| Prefab / Blueprint | PF_ / BP_ | PF_EnemyGoblin_Melee |
| Material | MAT_ | MAT_EnvWood_Oak |
| Material Instance | MI_ | MI_EnvWood_OakDark |
| Texture | T_ | T_CharKnight_Albedo |
| Static Mesh | SM_ | SM_EnvBridge_Wood |
| Skeletal Mesh | SK_ | SK_CharKnight |
| Animation | AN_ | AN_CharKnight_Attack01 |
| Audio Clip | SFX_, BGM_, VO_ | SFX_WeaponSword_Hit_01 |
| UI Sprite | SPR_ | SPR_UI_InventorySlot |
| Script | 기능명 중심 | PlayerHealth.cs, InventoryService.cs |
Unity와 Unreal Engine은 기본적으로 다른 용어를 사용한다. Unity 팀은 PF_, Unreal 팀은 BP_, SM_, MI_ 같은 엔진 생태계의 관례를 우선하면 신규 인력의 적응 비용을 낮출 수 있다.
텍스처 채널과 변형을 이름에 명시해야 하는 이유
텍스처는 이름만 보고도 사용 목적과 import 설정을 유추할 수 있어야 한다. PBR 워크플로에서 자주 쓰는 접미사는 다음처럼 정한다.
| 용도 | 권장 접미사 | 예시 |
|---|---|---|
| Base Color / Albedo | _BC 또는 _Albedo | T_Rock_Granite_Albedo |
| Normal | _N | T_Rock_Granite_N |
| Mask | _M 또는 _Mask | T_Rock_Granite_Mask |
| Roughness | _Roughness | T_Rock_Granite_Roughness |
| Metallic | _Metallic | T_Rock_Granite_Metallic |
| Ambient Occlusion | _AO | T_Rock_Granite_AO |
채널 패킹을 사용한다면 파일명에 패킹 규칙을 남긴다. 예를 들어 Unreal Engine의 ORM 텍스처라면 T_Rock_Granite_ORM처럼 명시하고 팀 문서에 R=AO, G=Roughness, B=Metallic을 고정한다. 이름만으로 임포트 설정을 완전히 대체할 수는 없지만 잘못된 맵 연결을 줄이는 데 큰 도움이 된다.
표준을 도입하는 3단계
1. 현재 파일을 분류하고 문제를 수치화한다
먼저 파일을 옮기지 말고 현재 상태를 조사한다. 중복 에셋, 의미 없는 접미사, 참조 중인 파일, 외부 패키지를 목록화한다. Unity에서는 Project 창과 Addressables 설정, Unreal에서는 Content Browser와 Reference Viewer를 이용해 참조 관계를 확인한다.
조사 결과는 다음 열을 가진 스프레드시트나 이슈 보드로 관리하면 충분하다.
| 항목 | 설명 |
|---|---|
| 기존 경로 | 현재 파일 위치 |
| 제안 경로 | 표준 구조 적용 후 위치 |
| 기존 이름 | 변경 전 이름 |
| 제안 이름 | 규칙 적용 후 이름 |
| 소유자 | 확인·수정 담당자 |
| 참조 확인 | 씬, 프리팹, 블루프린트, 데이터 테이블 영향 |
| 상태 | 대기, 검토, 완료, 보류 |
2. 최소 규칙을 문서로 합의한다
처음부터 모든 유형을 규정하면 도입이 멈춘다. 아래 네 가지를 우선 확정한다.
- 최상위 폴더의 책임과 외부 에셋 격리 방식
- 에셋 타입별 접두사 목록
- 공백·특수문자·대소문자·번호 표기 규칙
- 이동·이름 변경 시 엔진 에디터를 사용한다는 원칙
규칙은 저장소의 CONTRIBUTING.md 또는 위키에 두고 예시와 금지 사례를 같이 적는다. 규칙 변경은 구두 합의로 끝내지 말고 문서의 버전과 변경 날짜를 남긴다.
## 이름 변경 금지 사례
- Player_final.prefab
- sword new.fbx
- UI아이콘.png
## 변경 권장 사례
- PF_PlayerWarrior_Default
- SM_WeaponSword_Iron
- SPR_UI_InventoryIcon3. 새 파일부터 적용하고 기존 파일은 점진적으로 정리한다
가장 안전한 전략은 새 콘텐츠부터 규칙을 적용하는 것이다. 기존 대규모 폴더 이동은 기능 개발과 분리된 정리 작업으로 계획하고 이동 단위를 작게 나눈다. 예를 들어 한 스프린트에 UI 폴더만 정리한 뒤 참조 검사, 플레이 모드 테스트, 빌드 검증을 완료하고 다음 영역으로 넘어간다.
flowchart LR
A[규칙 초안] --> B[팀 리뷰와 합의]
B --> C[신규 에셋부터 적용]
C --> D[영역별 기존 에셋 정리]
D --> E[참조 검사와 빌드 검증]
E --> F[회고 후 규칙 개정]
F --> CGit을 사용한다면 리팩터링 커밋과 기능 변경을 분리한다. 파일 이동·이름 변경만 담긴 커밋은 chore: reorganize ui assets처럼 명확히 만들고 동일한 Pull Request에 게임 로직 변경을 섞지 않는다. 대용량 바이너리 에셋은 Git LFS 추적 정책도 함께 확인한다.
폴더와 에셋 이름 변경 시 무엇을 점검해야 하나?
파일명 변경은 단순한 정리가 아니라 참조 변경 작업이다. 다음 순서로 확인한다.
- Unity는 Unity Editor 내부에서 Unreal은 Content Browser 내부에서 파일을 이동하거나 이름을 변경한다.
- 엔진의 참조 검색 기능으로 씬, 프리팹, 블루프린트, 데이터 에셋의 연결을 확인한다.
- 대상 씬 실행과 자동화 테스트를 수행하고 개발 빌드를 만든다.
- 변경된
.meta,.uasset, 리다이렉터와 Git LFS 대상 파일이 모두 버전 관리에 포함됐는지 검토한다. - Unreal Engine에서는 이동 후 생성된 Redirector를 확인하고 팀의 검증 절차에 따라 Fix Up Redirectors를 실행한다.
에디터 밖의 파일 탐색기에서 Unity 에셋과 .meta 파일을 따로 이동하거나 삭제하면 GUID 연결이 끊길 수 있다. Unreal Engine 프로젝트에서도 .uasset을 운영체제 파일 탐색기에서 임의로 옮기면 참조와 리다이렉터 관리가 어려워진다.
운영 규칙을 지키게 만드는 현실적인 방법
컨벤션은 문서만으로 유지되지 않는다. 리뷰와 작업 흐름에 작은 확인 장치를 넣어야 한다.
- Pull Request 템플릿에
새 에셋이 컨벤션을 따르는가?항목을 추가한다. - 아트·기획·클라이언트 담당자가 함께 보는 짧은 예시 목록을 유지한다.
- 주간 또는 스프린트 종료 시 이름 위반 목록을 한 번만 정리한다.
- 예외가 반복되면 개인에게 지적하기보다 접두사 표준이나 폴더 책임이 부족한지 검토한다.
- 자동 검사가 가능하다면 CI에서 공백, 금지 문자, 미승인 최상위 폴더만 우선 검사한다.
처음부터 모든 파일명 규칙을 CI 실패 조건으로 만들면 마이그레이션 기간에 개발이 막힐 수 있다. 기존 파일은 경고로 기록하고 신규 파일부터 차단 규칙을 적용하는 점진적 정책이 안전하다.
자주 묻는 질문 (FAQ)
기존 에셋을 한 번에 전부 바꿔도 될까?
권장하지 않는다. 기능 개발과 분리된 작업 브랜치에서 도메인별로 나누고 각 단위마다 참조 검사와 빌드를 통과시킨 뒤 병합하는 편이 안전하다.
에셋 이름에 버전 번호를 넣어야 할까?
일반적으로 v2, final, final_final은 넣지 않는다. Git, Perforce 같은 버전 관리 시스템이 이력을 담당한다. 게임 안에서 동시에 쓰이는 의도적 변형만 _01, _Damaged, _Winter처럼 의미 있게 구분한다.
외부 에셋을 팀 규칙에 맞게 바로 이름 바꿔도 될까?
원본 패키지는 _ThirdParty에 보존하고 수정이 필요하면 팀 소유 복사본 또는 래퍼 에셋을 별도 위치에 만든다. 그래야 패키지 업데이트와 라이선스 확인이 쉬워진다.
마무리
좋은 폴더 구조와 네이밍 컨벤션은 예쁜 정리법이 아니라 협업 비용을 줄이는 팀 운영 장치다. 최상위 폴더 책임, 타입 접두사, 변경 안전 절차라는 세 가지부터 합의하고 신규 에셋에 먼저 적용하자. 이후 실제로 자주 발생하는 예외를 근거로 규칙을 갱신하면 문서가 개발 흐름을 방해하지 않으면서도 오래 유지된다.
