수년간 복잡한 3D 파이프라인을 관리하면서, 저는 체계적인 명명 규칙이 원활하고 확장 가능한 워크플로우를 위한 가장 중요한 요소라는 것을 알게 되었습니다. 이는 고지식함을 뜻하는 것이 아니라, 치명적인 오류를 방지하고, 검색 시간을 절약하며, 원활한 협업을 가능하게 하는 시스템을 만드는 것입니다. 저는 게임, 영화, XR 프로젝트 전반에 걸쳐 검증된 메시, 머티리얼, 텍스처에 대한 정확한 프레임워크를 공유할 것입니다. 이 가이드는 혼란스러운 애셋 관리에서 벗어나 전문적이고 미래 지향적인 파이프라인으로 나아가고자 하는 모든 3D 아티스트, 기술 감독, 스튜디오 리더를 위한 것입니다.
핵심 요약:
저는 final_model_v23_newFIX.obj와 같이 애셋 이름이 지정된 프로젝트를 맡은 적이 있습니다. 그 결과는 항상 동일합니다. 머티리얼 링크가 깨지고, 파일이 덮어쓰여지며, 아티스트들은 올바른 버전을 찾는 데 30% 이상의 시간을 낭비합니다. 팀 환경에서는 이러한 혼란이 가중되어 모든 것이 제대로 가져오거나 조립되지 않는 통합 지옥으로 이어집니다. 재정적 비용은 실제적입니다. 마감 기한을 놓치고 혼란을 풀기 위한 값비싼 초과 근무로 직접 연결됩니다.
논리적이고 예측 가능한 명명 시스템은 조용한 파트너 역할을 합니다. 애셋 이름을 chr_hero_sword_high로 지정하면, 파일을 열어보지 않고도 해당 애셋의 카테고리, 목적, 디테일 수준을 즉시 알 수 있습니다. 이를 통해 효율적인 스크립팅, 배치 처리 및 자동화된 도구 체인이 가능합니다. 저의 정신 에너지는 관리적인 고고학 대신 창의적인 문제 해결에 집중할 수 있습니다. 이는 마찰이 적고 속도가 빠른 창의적인 환경의 기반이 됩니다.
경력 초기에 저는 악몽과 같은 경험을 했습니다. 마지막 순간에 클라이언트의 변경 요청으로 200개 장면에 걸쳐 캐릭터의 변형을 교체해야 했습니다. 애셋 이름이 일관성 없게 지정되어 수동적이고 오류가 발생하기 쉬운 프로세스였고, 결국 마감 기한을 놓쳤습니다. 이 교훈은 뇌리에 깊이 박혔습니다. 규칙은 범위 변경(scope creep)과 프로덕션 변동성에 대한 첫 번째 방어선입니다. 잘 명명된 애셋 라이브러리는 빠르고 자신감 있게 방향을 전환할 수 있도록 해줍니다.
저의 시스템은 애셋 유형을 나타내는 표준화된 접두사에 따라 달라집니다. 이는 모든 도구나 팀원이 가장 먼저 보는 것입니다. 또한 기술적 상태를 나타내는 접미사를 사용합니다.
chr_ (캐릭터), prop_ (소품), env_ (환경), veh_ (차량), fx_ (효과)._high (스컬프팅된 원본), _low (게임용 메시), _coll (충돌 메시), _rig (리깅된 버전).이 간단한 구조는 어떤 소프트웨어의 애셋 브라우저에서도 필터링을 즉시 가능하게 하며, 수백만 폴리곤 스컬프트를 실수로 게임 엔진으로 가져오는 것을 방지합니다.
판타지 전사 캐릭터의 이름을 만들어 봅시다. 저는 이 순서를 따릅니다.
chr_chr_warriorchr_warrior_axechr_warrior_axe_high (ZBrush 스컬프팅)chr_warrior_axe_low이는 애셋 간에 명확한 계층 관계를 만듭니다. Tripo AI와 같은 도구를 사용하여 컨셉에서 기본 메시를 생성할 때, 저는 AI가 생성한 모델을 첫 순간부터 _high 또는 원본 애셋으로 취급하여 이 규칙을 즉시 적용합니다.
red_shiny_sword는 설명적이지만 취약합니다. 아트 디렉션이 바뀌어 이제 파란색이 되면 어떻게 될까요? prop_sword_hero_01은 기능적이고 영구적입니다. 역할(prop), 객체 유형(sword), 사용자(hero)를 설명하고 변형(01)을 위한 공간을 남겨둡니다. 기능적 명명은 아트 디렉션 변경에도 살아남으며, 리깅 또는 인벤토리 시스템 훅과 같은 기술적 프로세스에서 참조하기 훨씬 쉽습니다.
머티리얼의 이름은 부모 메시로 직접 연결되어야 합니다. 제 메시가 prop_wooden_barrel_low라면, 기본 머티리얼은 m_prop_wooden_barrel입니다. m_ 접두사는 제 파이프라인에서 머티리얼에 대한 보편적인 접두사입니다. 서브 머티리얼 또는 머티리얼 인스턴스(예: 다른 목재 스테인)의 경우, m_prop_wooden_barrel_01, m_prop_wooden_barrel_02를 추가합니다. 이는 메시가 참조될 때 머티리얼 연결이 그대로 유지되거나 다시 연결하기가 아주 쉽다는 것을 보장합니다.
텍스처 이름은 머티리얼 이름의 확장입니다. m_prop_wooden_barrel 머티리얼의 모든 맵은 다음 패턴을 따릅니다.
m_prop_wooden_barrel_D (Diffuse/Albedo)m_prop_wooden_barrel_N (Normal)m_prop_wooden_barrel_RMA (Roughness, Metallic, Ambient Occlusion - 패킹됨)일관된 맵 접미사(_D, _N, _RMA, Emissive용 _E)를 사용하는 것이 중요합니다. 이를 통해 텍스처 합성 도구 및 게임 엔진 임포터가 머티리얼을 자동으로 인식하고 올바르게 설정하여 설정 시간을 대폭 단축할 수 있습니다.
저의 폴더 구조는 명명 계층을 반영하여 모든 애셋에 대한 예측 가능한 경로를 만듭니다.
Project_Assets/
├── 01_Characters/
│ ├── chr_warrior/
│ │ ├── Meshes/
│ │ │ ├── chr_warrior_high.fbx
│ │ │ └── chr_warrior_low.fbx
│ │ ├── Textures/
│ │ │ ├── m_chr_warrior_D.tga
│ │ │ └── m_chr_warrior_N.tga
│ │ └── Materials/
│ │ └── m_chr_warrior.mi
└── 02_Props/
└── prop_sword_hero/
├── Meshes/
└── Textures/
이 구조는 확장 가능합니다. 애셋이 10개든 10,000개든 논리는 동일하게 유지됩니다.
팀의 경우 규칙은 문서화되고 강제되어야 합니다. 저는 모든 프로젝트에 대해 한 페이지짜리 "명명 규칙서"를 만듭니다. 버전 관리 시스템(Perforce 또는 Git LFS와 같은)에서 자동 유효성 검사 스크립트를 사용하여 규칙을 따르지 않는 애셋 체크인을 표시합니다. 핵심은 규칙을 따르는 것이 어기는 것보다 쉽게 만드는 것입니다. 간단하고 명확한 규칙이 복잡하고 완벽한 규칙보다 항상 낫습니다.
최신 AI 생성 도구는 명명 규칙의 예외가 아닙니다. 오히려 규칙을 더 일찍 적용해야 하는 이유입니다. "화려한 고딕 양식의 촛대"와 같은 텍스트 프롬프트로 Tripo에서 3D 모델을 생성할 때, 제가 가장 먼저 하는 일은 출력 파일의 이름을 prop_candelabra_gothic_high로 바꾸는 것입니다. 그런 다음 즉시 올바른 /02_Props/ 폴더 구조에 배치합니다. 이는 AI가 생성한 애셋을 처음부터 일류 프로덕션 요소로 취급하여, 리토폴로지, 텍스처링, LOD 생성을 위한 나머지 파이프라인에 원활하게 통합되도록 보장합니다.
좋은 명명 시스템은 어떤 단일 프로젝트나 소프트웨어보다 오래 지속됩니다. 저는 몇 년 후에 애셋 라이브러리로 돌아가도 여전히 이해할 수 있습니다. 미래에 대비하기 위해 핵심 이름에 소프트웨어별 코드(예: ZBrush용 _zb)를 사용하지 않습니다. 이러한 코드는 폴더나 주석 필드에 들어갑니다. 저는 독립적이고 기능적인 용어를 고수합니다. 이는 제 애셋이 항상 새로운 엔진으로 포팅되거나, 아카이벌 프로젝트에 사용되거나, 다음 세대의 AI 도구에 공급되어 리믹싱 또는 반복 작업을 할 수 있도록 준비되어 있으며, 그 의도와 구조가 완벽하게 보존된다는 것을 의미합니다.
moving at the speed of creativity, achieving the depths of imagination.
텍스트·이미지를 3D 모델로 변환
매월 무료 크레딧 제공
압도적인 디테일 복원력