대부분의 파일명이 2주 후 무용지물이 되는 이유
나쁜 파일명은 잘못된 클립이 승인되기 전까지 위험해 보이지 않습니다. 감독은 scene04_final.mp4에 코멘트를 달고, 편집자는 scene04_final_new.mp4를 업로드하고, 아카이브에는 scene04_final_revised_real.mp4가 남습니다. 그중 두 개는 크롭 테스트이고, 하나는 올바른 연기 비트를 갖고 있지만, 어떤 프롬프트나 선택된 테이크에서 나온 것인지 이름은 말해 주지 않습니다.
AI 애니메이션 제작은 이 문제를 키웁니다. 각 샷마다 프롬프트 초안, 레퍼런스 세트, 생성 테이크, 선택된 테이크, 정리된 최종본, 보이스 패스, 플랫폼 크롭, 커버 프레임, 아카이브 사본이 생길 수 있기 때문입니다. girl_rooftop_good.mp4는 혼자 실험할 때는 괜찮을 수 있지만, 프로젝트에 에피소드, 언어, 화면비, 검토 상태, 수정 이력이 들어오면 바로 무너집니다.
명명 규칙은 파일을 찾을 수 있게 해야 하지만, 파일명이 모든 맥락을 짊어지게 만들 필요는 없습니다. 그 맥락은 이미 ArcLoop 안에 있습니다. 프로젝트, 에피소드(EP1, EP2……), 콘티 안의 shot card입니다. ArcLoop 밖에 남는 파일—로컬 익스포트, 아직 자산에 묶이지 않은 Reference image—은 파일명이 프로젝트, 에피소드, 샷, 버전을 식별할 수 있을 만큼만 구조화되면 충분합니다. 명명을 제작 흐름과 연결하려면 캐릭터 프로필 항목을 사용하고, 같은 캐릭터와 장소에 장기적인 연속성이 필요할 때는 ArcLoop 월드를 사용하세요.
편집을 견디는 파일명의 규칙
이름은 제작 순서대로 정렬되어야 합니다. 가장 넓은 단위를 먼저 둡니다. 프로젝트, 에피소드 또는 시퀀스, 샷, 자산 유형, 변형, 버전, 상태입니다. 파일이 자연스럽게 정렬되면 검토자는 모든 파일을 열지 않고도 폴더를 훑을 수 있습니다.
핵심 이름에는 장면 설명이 아니라 안정적인 번호를 사용하세요. “샷 2” 같은 번호는 “발코니 고백”보다 대본 수정에 더 잘 버팁니다. 설명어는 짧은 변형 라벨로 등장할 수 있지만, 번호가 앵커 역할을 유지해야 합니다.
상태 어휘는 작게 유지하세요. draft, select, review, approved, final, rejected, archive처럼 제한된 집합을 사용합니다. 팀원마다 상태 단어를 만들면 명명은 더 이상 규칙이 아닙니다.
긴 설명은 파일명에 욱여넣지 마세요. 프롬프트 내용, 샷 메모, 모든 캐릭터 이름은 파일명에 쓸 필요가 없습니다. 그것들은 원래 shot card 안에 있고, 정체성은 샷이 @로 참조하는 캐릭터 자산 안에 있습니다.
승인된 작업을 덮어쓰기에서 보호하세요. 변경된 파일에 같은 이름을 다시 쓰지 마세요. 버전을 올리거나 상태를 바꿉니다. 기본이지만, 유일하게 승인된 테이크가 이후 테스트로 조용히 교체되는 사고를 막습니다.
명명 패턴 만드는 법: 필드에서 첫 익스포트까지
프로젝트가 실제로 쓰는 단위부터 선택합니다. 짧은 단독 클립은 프로젝트, 샷, 자산 유형, 버전, 상태만 필요할 수 있습니다. 에피소드 시리즈는 프로젝트, 시즌, 에피소드, 시퀀스, 샷, 테이크, 변형, 버전, 상태가 필요할 수 있습니다. 아무도 검색하지 않을 필드는 추가하지 마세요.
단순한 패턴을 정의합니다. 실용적인 패턴은 PROJECT_EPISODE_SHOT_TYPE_VARIANT_v##_STATUS.ext입니다. 예를 들어 GARDEN_E01_SH012_clip_master_v03_approved.mp4입니다. 모든 글자 스타일을 통일하고 공백을 피하면 도구 사이에서 익스포트가 안정적으로 동작합니다.
type과 variant의 허용값을 만듭니다. Type은 prompt, ref, take, clip, cover, voice, caption, manifest, note가 될 수 있습니다. Variant는 master, vertical, square, clean, subbed, cropA, paletteB가 될 수 있습니다. 허용값은 폴더가 제멋대로 흘러가는 일을 막습니다.
버전 규칙을 씁니다. 초안과 수정본은 파일 내용이 바뀔 때마다 버전을 올려야 합니다. 상태 변경은 워크플로에 따라 상태 파일을 복사로 만들 수도 있고 매니페스트 상태만 업데이트할 수도 있습니다. 중요한 규칙은 내용 변경이 승인된 파일을 덮어쓰면 안 된다는 것입니다.
파일명은 프로젝트에 연결하기만 하면 되고, 그것을 대체하려 할 필요는 없습니다. 프로젝트, 에피소드, 샷이 담긴 짧은 이름이면 충분합니다. 진짜 근거는 여전히 ArcLoop 안의 shot card와, 샷이 @로 참조하는 캐릭터 또는 장면 자산입니다.
배치 익스포트 전에 명명 검토를 실행하세요. 중복 ID, 누락된 버전, 섞인 상태 단어, 소스 샷이 없는 파일, 마스터처럼 보이는 플랫폼 변형을 확인합니다. 몇 분이면 되고 몇 시간을 아낍니다.
지저분한 레거시 폴더에는 리네임 경로를 문서화하세요. 파일이 이미 편집자나 클라이언트에게 공유되었다면 새 패키지가 승인될 때까지 기존 이름을 매니페스트에 별칭으로 남깁니다. 리네임은 추적성을 높여야지, 어제 파일을 가리키던 코멘트 스레드를 깨면 안 됩니다.
무엇을 파일명에, 무엇을 ArcLoop에
파일명이 짧게 유지될 수 있는 이유는 진짜 맥락이 이미 ArcLoop 안에 있기 때문입니다. 캐릭터와 장면 자산, 스토리 개요, 그리고 각 샷이 속한 콘티 안에서의 위치입니다. 즉 NIGHT_E02_SH006_clip_vertical_v02.mp4라는 로컬 파일도 짧고 읽기 쉬운 상태를 유지할 수 있습니다. 자세한 이야기와 정체성 맥락은 이름이 아니라 연결된 프로젝트 안에 있기 때문입니다.
팀에게 실용적인 경계는 이렇습니다. 파일명은 식별을 맡고, ArcLoop는 의미를 맡습니다. 프로젝트, 에피소드, 샷, 유형, 변형, 버전을 이름에 넣으세요. 이야기 자체는 스토리 개요에 넣고, 실제 정체성 참조는 샷 설명 안의 @로 가져옵니다.
팀이 로컬 파일의 명명 규칙을 정했다면 첫 익스포트 전에 적어두기만 하면 됩니다. 그것은 ArcLoop 밖에서만 적용되는데, 프로젝트 안에서는 각 샷이 원래 그 콘티 안에 고정된 위치를 갖고 있기 때문입니다. 승인 후에 누구도 한 시즌 전체를 손으로 다시 이름 붙일 필요가 없습니다.
같은 습관은 여러 시도를 비교할 때도 도움이 됩니다. Canvas에서 하나의 샷을 분기하고, 다른 테이크를 시도하고, 이전 아이디어로 되돌아가면서도 무엇이 무엇인지 헷갈리지 않을 수 있습니다. 로컬로 내보내는 파일에 안정적인 이름을 쓰면 이 히스토리를 프로젝트 밖에서도 깔끔하게 유지할 수 있습니다.
로컬 파일 이름을 정하기 전에, ArcLoop 안에서 이 경계가 어떻게 작동하는지 살펴봅시다.
IP Project를 열고 내 자산(My Assets)으로 이동합니다. 반복 등장하는 캐릭터마다 Character asset을 만드세요——Copper Harbor라면 선장 Elian Ro입니다. 참고 이미지를 콘텐츠 라이브러리(Library)에 업로드한 뒤, 해당 asset에 Bind하여 Main image로 설정합니다. 다른 각도나 의상 이미지가 있다면 Reference image로 추가하세요.
Episode 1로 들어가 Generate Shots를 클릭합니다. ArcLoop가 Story Outline을 바탕으로 shot card 세트를 생성합니다. 각 shot card에서 @Captain Elian Ro를 입력하면 선장의 외모 정보가 불러와집니다——매번 얼굴이나 코트를 다시 설명할 필요가 없습니다. 해당 샷에서 새롭게 추가되는 정보만 작성하면 됩니다: 동작, 카메라 앵글, 조명.
먼저 Shot 1의 이미지를 생성해 구도와 캐릭터 디자인을 확인한 뒤 영상을 생성하세요. 여러 샷을 한 번에 처리하려면 AI Chat Panel을 활용하세요: "Generate videos for Shots 1, 2, and 3." 테이크가 마음에 들면 Edit에서 타임라인에 배치하고 다듬습니다.
로컬 파일 이름이 중요해지는 건 Export 단계뿐입니다. 그 시점이면 shot card——@ 참조, 설명, Storyboard 내 위치——가 이미 모든 의미 있는 정보를 담고 있습니다. 파일 이름은 짧고 정렬 가능한 식별자면 충분합니다.
예시 1: Copper Harbor 명명 규칙
Write a file naming convention for local exports from the Copper Harbor project.
Production shape: 3 short episodes, one recurring captain character asset (@Captain Elian Ro), 8 to 12 shots per episode. Export types include master clips, vertical social cuts, cover images, and caption files.
Naming pattern: COPPER_E##_SH###_TYPE_VARIANT_v##_STATUS.ext
Allowed TYPE values: clip, cover, caption, ref.
Allowed VARIANT values: master, vertical, square, subbed.
Allowed STATUS values: draft, review, final.
Version rule: increment v## whenever file content changes. Never overwrite a file already shared with the team.
Context rule: story detail, shot descriptions, and @asset references all stay inside the ArcLoop project. The filename is a short handle, not a substitute for the shot card.
이 프롬프트는 팀이 따를 수 있을 만큼 작고, 흔한 실수를 잡을 만큼 엄격한 규칙을 줍니다.
예시 2: 테이크 선택 세트 이름 붙이기
Copper Harbor 에피소드 2, 샷 7의 테이크 선택 세트 파일명을 준비하세요.
샷 배경: Captain Elian Ro가 부두에서 금이 간 나침반을 들고 있고, 구리색 등대 뒤로 안개가 걷힌다.
이름을 붙여야 할 파일: Canvas 분기에서 내보낸 테이크 세 개, 그중 하나는 나침반이 어긋나 폐기됨.
프로젝트 명명 패턴을 사용하고 설명은 파일명에 넣지 않는다.
출력 예시:
COPPER_E02_SH007_take_v01.mp4
COPPER_E02_SH007_take_v02_select.mp4
COPPER_E02_SH007_take_v03_rejected.mp4
설명: v03가 폐기된 이유는 샷 설명이나 프로젝트에 남기는 메모에 적고, 파일명에는 적지 않는다.
샷 설명은 여전히 유용하지만 shot card에 들어가야 합니다. 파일명은 운영 가능한 상태로 유지합니다.
예시 3: 지저분한 익스포트 폴더 리네임
승인된 규칙을 사용해 지저분한 Copper Harbor 익스포트 폴더를 감사하고 이름을 바꾸세요.
현재 문제: 파일명이 final.mp4, final2.mp4, good_vertical.mp4, cover_new.png, captions_real.srt이다.
알려진 매핑: final.mp4는 E01 SH010 master v02. final2.mp4는 E01 SH010 master v03. good_vertical.mp4는 E01 SH010 vertical v01. cover_new.png는 E01 cover v02. captions_real.srt는 E01 captions v01.
리네임 계획: 새 파일명을 만들고, 리네임한 사본을 확인할 때까지 원본 파일을 보존하며, 옛 이름에서 새 이름으로의 매핑을 팀 전체가 볼 수 있는 곳에 적어둔다.
창작 내용, 프롬프트, 자막, 승인 메모는 바꾸지 않는다.
매핑 정보가 충분하지 않은 파일은 추측하지 말고 표시한다.
이것이 명명 정리의 올바른 사용법입니다. 알려진 사실을 매핑하고, 창작 변경을 피하고, 부족한 출처는 추측하지 않습니다.
파일 명명이 무너지는 방식
가장 흔한 실수는 final을 너무 일찍 쓰는 것입니다. 파일은 창작 선택됨, 납품 검토 중, 플랫폼 크롭, 아카이브됨 중 하나일 수 있습니다. final은 필요한 검사를 통과한 납품물에만 남겨 두세요.
또 다른 실수는 전체 스토리를 이름에 넣는 것입니다. sad-captain-foggy-pier-compass-closeup-best-v2는 도움이 되는 것처럼 보이지만 정렬을 깨고 승인 상태도 빠뜨립니다. 스토리 단어는 shot card에 넣으세요.
팀이 명명 규칙을 섞어 쓰기도 합니다. 한 제작자는 E1S4, 다른 제작자는 ep01-shot004, 편집자는 scene4라고 씁니다. 생성이 시작되기 전에 하나의 패턴을 고르세요.
네 번째 실수는 플랫폼 변형이 마스터처럼 보이게 하는 것입니다. 세로 크롭, 정사각 크롭, 자막 버전, 클린 마스터는 서로 다른 납품물입니다. variant 필드가 그 차이를 드러내야 합니다.
자주 묻는 질문
모든 AI 애니메이션 파일명에는 어떤 필드가 들어가야 하나요?
프로젝트, 필요할 경우 에피소드나 시퀀스, 샷 ID, 자산 유형, 변형, 버전, 상태를 사용하세요. 작은 프로젝트는 쓰지 않는 필드를 뺄 수 있지만, 바뀐 파일에는 버전이 있어야 합니다.
캐릭터 이름을 파일명에 넣어야 하나요?
보통은 필요 없습니다. 캐릭터의 정체성은 이미 내 자산 안의 자산에 있고, 샷이 @로 참조하면 그대로 딸려 오므로 파일명에 다시 쓸 필요가 없습니다. 대신 에피소드와 샷 번호를 사용하세요(예: E02_SH007). 그러면 정렬도 더 잘 되고 대본이 다시 쓰여도 더 잘 버팁니다.
거절된 테이크는 어떻게 처리하나요?
유용한 실패를 설명할 때 하나의 거절 파일을 남기고 rejected로 이름 붙이며 이유는 메타데이터에 넣습니다. 모호한 이름의 반복 거절본을 수십 개 남기지 마세요.
맥락을 잃지 않으면서 파일명을 짧게 유지하려면?
샷 설명, @ 자산 참조, 그리고 캐릭터 자산 자체는 모두 프로젝트 안에서 이 샷에 연결된 채로 남습니다. 파일명에는 짧은 핸들만 있으면 됩니다. 프로젝트, 에피소드, 샷, 버전입니다.
명명 규칙은 언제 만들어야 하나요?
첫 실제 배치 전에 만들어야 합니다. 제작 후 명명은 정리이고, 제작 전 명명은 예방입니다. 패턴을 프로젝트 설정에 넣어 모든 프롬프트, 테이크, 클립, 자막, 커버가 같은 규칙을 따르게 하세요.
오래된 파일이 이미 지저분한 이름을 쓰고 있다면?
무언가를 바꾸기 전에, 옛 이름에서 새 이름으로의 매핑을 팀 전체가 볼 수 있는 기록으로 정리하세요. 소스 샷이 명확한 파일만 리네임합니다. 확실하지 않은 파일은 출처를 지어내지 말고 검토 대기로 표시합니다.
