결과물이 왜 소재를 다시 잇는 경로를 넘기지 못하는가

ALE, CSV, PDF, FDX는 모두 구조화된 기록을 넘길 수 있지만, 어느 것에서도 수신자 기계의 소재를 다시 잇는 경로는 나오지 않습니다. 기계로 읽는 두 결과물에는 Source File Name 칸과 원본 파일을 담는 칸이 실제로 있고, 그 칸에 실리는 것은 현장에서 옮겨 적어 넣은 문자입니다. 소프트웨어는 디스크를 훑어 위치를 찾지 않고, 옮겨 적지 않았으면 칸 전체가 빈칸으로 나갑니다. 프로젝트 저장소 안에 있는 그 실제 경로는 내보내기 스냅샷에 애초에 실린 적이 없습니다.

소재는 프로젝트 저장소에 디스크 위의 저장 위치를 실제로 갖습니다. 다만 결과물 속 그 칸은 옮겨 적어 넣은 문자일 뿐이라, 수신자가 그것만으로 소재에 바로 재연결할 수 없습니다.

로컬 매체에 저장 위치가 두 가지인 이유

매체를 로컬에 저장할 때는 하나의 디렉터리 규칙만 적용되지 않습니다. 새 항목 폼에서 만들어진 영상은 하위 구분 없는 평면 착지 영역으로 들어갑니다. 목록 쪽의 촬영, 사진 라이브러리 선택, 파일 가져오기는 프로젝트, 씬, 컷, 테이크로 층을 나눈 구조화된 디렉터리에 들어갑니다. 두 저장 위치 모두 프로젝트 저장소 안에서 매체를 어떻게 보관하느냐의 문제입니다.

핵심 경계는 이 경로들이 프로젝트 저장소에만 있고 내보내기 스냅샷에는 들어가지 않는다는 점입니다. ALE, CSV, PDF 또는 FDX를 내보내기로 생성할 때 손에 쥐어지는 것은 촬영 기록과 관련 필드의 스냅샷이지 매체 자산 경로 목록이 아닙니다. 그래서 수신자가 릴 번호, 씬 번호 또는 테이크 번호를 볼 수 있어도, 결과물 파일에서 로컬 파일의 물리적 위치를 바로 얻을 수는 없습니다. 컷 번호는 CSV와 PDF에서만 별도 열을 이루고, ALE에는 이 열이 없습니다.

파일 이름이 원래 경로의 대리물이 될 수 없는 이유

매체를 디스크에 놓기 전에 파일 이름을 먼저 정규화합니다. 허용되지 않는 문자는 밑줄로 바꾸고, 제어 문자는 삭제하고, 지나치게 긴 이름은 잘라냅니다. 정규화 뒤에 쓸 만한 내용이 남지 않으면 영문 상수 자리채움 이름으로 떨어집니다. 즉 디스크 위의 파일 이름 자체는 이미 외부에 있던 출처 이름과 다를 수 있습니다.

사진의 처리는 두 부류로 나뉩니다. 현장 촬영과 퀵 컷으로 얻은 사진은 재인코딩되고, 사진 라이브러리에서 고르거나 파일로 가져온 사진은 원본 바이트 그대로 보관됩니다. 두 부류 모두 원래 경로는 가져가지 않습니다. 따라서 수신자가 우연히 비슷한 파일 이름을 손에 넣어도 그것을 「원본 파일 이름 더하기 원본 바이트」의 증거로 취급할 수 없습니다. 결과물 속 그 칸의 파일 이름은 릴 번호와 클립 번호로 조립된 것이고, 디스크 위의 그 이름이 아닙니다. 경로 처리, 파일 이름 정규화, 매체 바이트 처리는 로컬 저장 계층의 사실이지, 결과물 속 매체 경로 열로 바뀌지는 않습니다.

「결과물에서 경로를 읽을 수 없다」는 내보내기 결과의 경계를 설명하는 것이고, 소재가 로컬 프로젝트 저장소에 존재하는지에 대한 판단이 아닙니다.

이것이 소재 재연결을 직접 제한하는 이유

결과물에 매체 경로가 없으면, 기록 한 행에서 특정 로컬 파일 위치로 곧바로 건너뛰게 하는 물리적 포인터가 없습니다. 릴 번호, 씬 번호, 테이크 번호 같은 필드는 여전히 신원 관계를 세우는 데 쓸 수 있지만, 그것들은 식별자이지 경로가 아닙니다. 수신자는 이 식별자들을 자신이 받은 매체 목록, 파일 명명, 디렉터리의 실제 상태와 대응시켜야 합니다.

이것이 바로 『ALE를 받으면 이 필드들부터 확인하라』가 수신자에게 소재와 현장 기록으로 돌아가 확인할 것을 요구하는 이유입니다. 파일을 열 수 있고 몇몇 열을 읽을 수 있다는 것이, 그 파일이 동시에 매체 위치까지 실었다는 뜻은 아닙니다. 어떤 작업 흐름이 결과물에서 소재를 바로 찾아내야 한다면, 그 대응 관계는 수신자가 이미 갖고 있는 매체 정보로 채워야 합니다.

네 가지 결과물이 같은 경계에 서 있는 이유

ALE과 CSV는 기계 판독 표이고, PDF는 사람이 읽는 요약이며, FDX는 대본 교환을 담당합니다. ALE과 CSV 뒤에 있는 촬영 기록 스냅샷에는 Source File Name 칸과 원본 파일을 담는 칸이 있고, 두 칸 모두 현장에서 옮겨 적어 채웁니다. 적어 넣으면 내용이 있고, 적지 않으면 빈칸입니다. PDF는 사람이 읽는 데만 쓰이고, FDX는 대본 쪽 스냅샷을 써서 테이크 기록조차 실지 않습니다. 네 결과물 어디에도 소프트웨어가 디스크에서 찾아낸 경로를 담은 칸은 없습니다. 형식이 다르다고 이 경계가 바뀌지 않습니다. 어떤 형식의 열이 더 많다는 이유만으로 프로젝트 저장소 속 매체의 저장 위치까지 덤으로 나온다고 추론할 수 없습니다.

예를 들어 『CSV 전달물은 ALE보다 무엇을 더 싣고 무엇을 빼는가』가 다루는 것은 필드 집합의 차이이고, 경로가 없다가 생긴 일이 아닙니다. 『ALE를 받으면 이 필드들부터 확인하라』는 어느 칸을 옮겨 적지 않아 빈칸으로 나가는지, 그 옮겨 적히지 않은 칸이 마감 대조표에 어떻게 드러나는지를 칸별로 다룹니다. 받을 때는 「이 칸은 옮겨 적지 않았다」, 「이 칸은 옮겨 적은 문자를 담고 있다」, 「매체를 실제로 다시 연결할 수 있는 포인터」를 나눠서 이해해야 합니다. 열에 이름이 적혀 있는 것은 위치가 적혀 있는 것이 아닙니다.

수신자가 소재 대응 관계를 세우는 방법

결과물 기록을 매체와 대응시켜야 할 때, 수신자는 릴 번호, 씬 번호, 테이크 번호처럼 보이는 식별자에서 출발해 자신의 매체 목록과 항목별로 대조해야 합니다. 매체 쪽 명명, 릴 번호 또는 디렉터리 규칙이 결과물 기록과 맞지 않으면, 경로를 짐작하는 대신 실제 소재와 현장 기록으로 돌아가 확인해야 합니다. 직접 재연결 관계는 결과물 자체가 제공하지 않습니다.

그러므로 이런 파일은 매체 목록이나 매체 백업이 아니라 기록 및 교환 데이터로 이해해야 합니다. 이들이 내놓는 것은 칸 하나에 옮겨 적힌 문자이지, 기록에서 수신자 기계의 소재 위치로 가는 해석 가능한 포인터가 아니며, 수신자 프로젝트에서 매체 링크가 자동으로 세워진다는 약속도 구성하지 않습니다. 마무리할 때 수신자는 릴 번호, 씬 번호, 테이크 번호로 자신의 매체 목록을 직접 확인해야 합니다.

FAQ

ALE과 CSV에 파일 이름이 있는데도 왜 소재 경로는 읽을 수 없습니까?

파일 이름은 기록 속 신원 단서이고, 경로는 매체가 실제로 놓인 위치로, 둘은 같은 것이 아닙니다. ALE과 CSV에는 Source File Name 칸과 원본 파일을 담는 칸이 있고, 값은 현장에서 옮겨 적었는지에 달려 있으며, ALE의 그 두 칸은 ASCII만 받아들여서 비라틴 문자가 끼면 칸 전체가 빈칸이 됩니다. PDF와 FDX에는 그 두 칸조차 없습니다. 옮겨 적힌 그 문자열이 이름 붙이는 것은 촬영 쪽 파일이고, 수신자 기계의 디렉터리로는 이어지지 않습니다. 그래서 그 값이 나타났다고 재연결할 수 있는 위치가 채워지지 않습니다.

사진을 보관한 뒤에 외부 파일의 원본 바이트가 그대로 남습니까?

반드시 그렇지는 않습니다. 현장 촬영과 퀵 컷으로 얻은 사진은 재인코딩되고, 사진 라이브러리에서 고르거나 파일로 가져온 사진은 원본 바이트 그대로 보관됩니다. 두 부류 모두 원래 경로는 가져가지 않습니다.

CSV는 필드가 더 많아서 매체 경로까지 함께 얻습니까?

열이 더 많다는 이유만으로 소프트웨어가 찾아낸 경로 열이 생기지는 않습니다. CSV의 그 두 칸은 현장에서 입력한 문자이고, ALE의 같은 이름 두 칸은 ASCII만 받으며, PDF와 FDX에는 그 두 칸이 애초에 없습니다.

소재를 재연결해야 할 때는 무엇을 근거로 해야 합니까?

수신자는 릴 번호, 씬 번호, 테이크 번호처럼 보이는 식별자를 직접 자신의 매체 목록과 실제 파일에 대조해야 합니다. 결과물 내용에서 로컬의 완전한 경로를 짐작하지 않아야 합니다.

Axiom One LLC — SlateX. 위 숫자는 2026-09-24 기준입니다.