최종, 최종수정, 진짜최종이라는 이름이 늘면 최근 수정본을 찾는 데도 시간이 들어요. 파일의 수정 시각이 가장 늦다고 마지막 전달본인 것도 아니에요. 다른 폴더로 복사하거나 예전 작업을 다시 저장했을 수 있거든요. 저는 파일명에 버전과 용도를 나누고, 전달 여부는 기록으로 남기는 쪽을 택하겠어요.
버전과 용도 두 축 정하기
버전은 편집 내용이 달라진 순서예요. 용도는 그 파일을 왜 만들었는지예요. 같은 편집 버전에서 검토용 저용량 파일과 전달용 파일을 각각 내보냈다면, 용도는 달라도 편집 내용의 기준은 같을 수 있어요. 이 둘을 같은 번호 증가로 처리하면 무엇이 바뀌었는지 흐려져요.
예를 들어 P011_cut_v007.prproj를 작업 기록으로, P011_v007_review.mp4를 검토용 출력으로 정할 수 있어요. P011_v007_delivery.mp4는 같은 버전의 전달용이라는 뜻이에요. 설명을 위한 이름이며 프로그램의 자동 규칙은 아니에요.
영상 내용을 수정했다면 새 버전으로 저장하고 대응하는 출력물도 만들어 연결해요. 반대로 출력 설정만 바꿨다면 버전 자체를 바꿀지 별도 출력 구분을 붙일지 운영 기준을 정해요. 중요한 것은 파일명을 보고 변경 이유를 일관되게 해석할 수 있는지예요.
날짜는 촬영일인지 편집 저장일인지 전달일인지 뜻을 하나로 정해요. 여러 날짜를 섞어 앞에 붙이면 같은 프로젝트의 순서가 뒤엉킬 수 있어요. 저는 파일명에 모든 이력을 넣기보다 버전과 용도만 남기고, 정확한 전달 날짜는 짧은 기록으로 관리하는 편이 읽기 좋다고 봐요.
숫자 자리와 분기 표시
버전 숫자는 v001, v002처럼 자릿수를 맞추면 이름순으로 볼 때 찾기 편해요. v1, v10, v2처럼 문자순 정렬에서 다르게 보이는 혼란을 줄이려는 규칙이에요. 실제 정렬 방식은 탐색기 설정에 따라 다를 수 있으니 숫자 표기와 관계없이 목록도 확인해요.
A안과 B안처럼 동시에 갈라진 편집은 날짜 순서만으로 설명하기 어려워요. 같은 기준에서 출발했다면 v007_A와 v007_B처럼 분기임을 표시할 수 있어요. 어느 안이 선택됐는지 확인한 뒤 다음 버전으로 이어지는 관계를 기록해요.
분기 이름을 장면의 평가처럼 만들지는 않아요. 좋은안, 별로인안은 나중에 선택이 바뀌면 뜻이 어긋나요. 전달받은 사람이 이름만 봐도 중립적으로 구분할 수 있는 짧은 코드를 쓰는 편이 좋아요.
버전을 정할 때 원본 파일명까지 같은 방식으로 다시 바꾸지는 않아요. 카메라 원본의 출처 관리와 편집 프로젝트의 수정 이력은 다른 문제예요. 작업본을 구분하려던 규칙이 원본 재연결의 단서까지 바꾸지 않도록 범위를 정해요.
승인된 출력물과 대응 기록
누군가 확인한 파일이 있다면 그 정확한 이름을 남겨요. ‘7번 버전 확인받음’이라고만 적으면 같은 버전의 가로·세로 출력이나 다른 길이의 영상 중 무엇을 봤는지 모를 수 있어요. 프로젝트와 실제 보낸 출력물을 구분해서 적는 이유예요.
| 기록 | 예시 |
|---|---|
| 편집 기준 | cut_v007.prproj |
| 확인받은 파일 | v007_review_vertical.mp4 |
| 변경 내용 | 첫 장면 교체·자막 오탈자 수정 |
| 다음 작업 | 확인된 세로본으로 전달 출력 |
출력 파일만 이름을 새 버전으로 바꾼다고 편집 내용이 바뀌는 것은 아니에요. 잘못 출력한 파일에 새 이름을 붙여 전달하면 규칙이 있어도 혼동이 남아요. 파일명과 해당 프로젝트, 실제 영상 내용을 함께 맞춰야 해요.
수정 요청을 받으면 어느 버전에 대한 요청인지 먼저 확인해요. 예전 파일을 보고 보낸 의견을 최신 편집에 바로 적용하면 이미 고친 내용을 다시 바꿀 수 있어요. 검토 파일명과 필요한 경우 화면 위치를 함께 받는 것이 도움이 돼요.
같은 버전을 다시 출력했는데 인코딩 조건만 바뀌었다면 이름의 출력 구분을 활용할 수 있어요. 예시로 v007_review_small과 v007_review_full은 편집 기준은 같고 확인 목적이 다른 파일이라는 약속이에요. 반면 자막 문구까지 고쳤다면 단순 화질 차이로 표시하지 않아요. 파일명 길이를 줄이려고 서로 다른 변경을 같은 코드에 몰아넣지 않는 게 좋아요. 여러 사람이 쓰는 경우에는 대표 파일 세 개로 규칙을 읽어 보게 해 뜻이 같게 해석되는지도 확인해요.
이전 버전 보관과 교체
작업 중인 프로젝트를 NAS에 옮길 때는 저장을 마치고 사본을 만들어요. 같은 이름을 계속 덮어쓰는 것보다 구분되는 버전을 남기면 이전 선택을 확인하기 쉬워요. 다만 수동 버전 파일이 있다는 사실을 별도 장비 백업과 동일하게 보지는 않아요.
오래된 출력물을 정리할 때도 확인받은 파일은 따로 표시해요. 마지막으로 만든 파일만 남기면 왜 그 결과로 결정됐는지 사라질 수 있어요. 모두 영구 보관할 필요는 없지만, 변경 관계를 확인할 자료까지 이름순으로 일괄 삭제하지는 않겠어요.
새로운 작업자가 들어오면 현재 기준 파일과 보관 버전을 구분해 알려 줘요. current 같은 별도 안내를 둔다면 그 파일이 실제 어느 버전을 가리키는지도 적어요. 자동 동기화가 최신본을 판단해 줄 것이라 기대하지 않고, 사람이 결정한 편집 기준을 남기는 거예요.
규칙을 바꿀 때는 진행 중인 프로젝트 전체의 이름을 한 번에 정리하기보다 다음 버전부터 적용해요. 이미 전달된 파일의 이름은 기록과 함께 보존하는 편이 대조하기 좋아요. 새로운 이름을 예쁘게 맞추는 일보다 이전 요청과 현재 작업을 연결하는 일이 먼저예요.