같은 테이크 기록이 몇 장의 전달물에서 행 수도 순서도 맞지 않는가

같은 한 묶음의 테이크 기록이 몇 장의 전달물에서 행 수와 순서가 다른 것은, 서로 다른 프로젝트에서 데이터를 가져오서가 아닙니다. 생성 시간 순으로 뜬 같은 한 장의 스냅샷에서 출발한 뒤, 각자 서로 다른 정렬 키와 전개 규격을 썼기 때문입니다. 표 형태 결과물은 생성 시간순을 보존하고, 구조화 목록은 씬·컷·테이크로 다시 정렬하며, 사람이 읽는 데일리 리포트는 또 다른 컷 키를 씁니다. 그러면서 앞의 둘은 카메라별로 전개되고, 데일리 리포트는 여전히 테이크 하나에 행 하나입니다.

파일 간 대조에서 일관된 공통 키는 씬·컷·테이크 신원이지 「몇 번째 행」이 아닙니다.

시작점은 같지만 뒤의 정렬 규격이 다릅니다

스냅샷은 처음에 기록 생성 시간 오름차순으로 가져옵니다. 표 형태 결과물은 그 뒤로 다시 정렬하지 않으므로, 이 생성 시간 순을 기본적으로 보존합니다. 구조화 목록은 씬 번호와 컷 번호, 테이크 번호로 다시 정렬하는데, 이때 씬과 컷은 자연순 비교를 씁니다. 그래서 데이터 출처는 같아도 행의 위치는 이미 표 형태 결과물과 갈라집니다.

사람이 읽는 데일리 리포트는 정렬을 한 겹 더 밉니다. 씬 다음에 컷의 한정자 이름을 두 번째 키로 쓰고, 그다음 테이크 번호로 배열합니다. 이 한정자 이름은 구조화 목록이 쓰는 원시 컷 번호와 같지 않아, 두 파일이 같은 한 묶음의 테이크를 담고 있어도 「두 번째 행은 두 번째 행과 맞아야 한다」는 관계가 성립하지 않습니다.

화면 로그에는 또 다른 순서가 있습니다. 이것은 컷 번호 문자열 오름차순으로 먼저 서고, 그다음 테이크 번호 오름차순으로 섭니다. 문자열 정렬에서는 10이 2 앞에 옵니다. 이것은 화면 층 자신의 표시 순서이므로, 내보내기 파일 속 위치를 거꾸로 끌어내는 데 쓸 수도 없습니다.

행 수가 다른 핵심은 카메라별로 전개하는가에 있습니다

구조화 목록과 표 형태 결과물은 둘 다 카메라별로 전개됩니다. 테이크 하나가 여러 카메라를 포함하면 행도 여러 개가 되고, 카메라가 없어도 행 하나는 보존합니다. 사람이 읽는 데일리 리포트는 다릅니다. 테이크 수만큼 행을 내므로, 멀티 카메라 테이크 하나도 여전히 행 하나만 차지합니다.

이것은 같은 현장 기록 묶음이 서로 다른 총 행 수를 낳는 이유도 설명합니다. 멀티 카메라 테이크 하나는 목록과 표에서는 갈라지지만, 데일리 리포트에서는 테이크 하나 그대로입니다. 데일리 리포트에서 순서번호처럼 보이는 No.도 문서 전체의 행 번호일 뿐이고, 테이크 번호가 아닙니다. 그러니 그것을 파일 간 대조 키로 쓸수록 아닙니다.

행 수가 다른 것은 결과물의 규격이 서로 다르기 때문이고, 어느 파일이 「촬영 하나를 더했다」거나 「하나 빼먹었다」는 말이 아닙니다.

컷 표식은 서로 다른 결과물에서 같은 문자열이 아닐 수도 있습니다

사람이 읽는 데일리 리포트는 컷의 한정자 이름을 쓰지만, 표 형태 결과물의 컷 열은 원시 컷 번호를 씁니다. 한 컷은 화면이나 어느 파일에서 씬 접두어나 한정된 형태를 달고 나타나고, 다른 파일에서는 더 짧은 번호만 남을 수 있습니다. 수신자는 그것들을 씬·컷·테이크 관계에 되돌려 이해해야 하고, 어느 한 열의 문자열이 완전히 일치하는지만으로 같은 테이크인지 판단하지 않아야 합니다.

여기서 설명하는 것은 저희 결과물 쪽의 생성 방식입니다. 현재 증거로 특정한 하류 소프트웨어가 이것 때문에 어떻게 잘못 대응되거나 누락되거나 가져오기가 거절된다고 더 단정할 수 없습니다. 구체적인 수신 동작은 여전히 수신자가 자신의 가져오기 템플릿에 맞춰 열마다 확인해야 합니다.

대조할 때는 무엇을 써야 하는가

파일 간에 대조할 때는 먼저 씬 번호를 고정하고, 다음에 컷을 고정하고, 그다음 테이크 번호를 봅니다. 멀티 카메라 기록에서는 카메라까지 계속 봐야 합니다. 그렇게 하는 목적은 신원 관계를 공통 언어로 삼기 위한 것이고, 어느 파일에 우연히 나타난 행 위치를 기본키로 쓰기 위한 것이 아닙니다.

두 파일의 총 행 수가 다르다면, 서로 다른 전개 규격을 썼는지를 먼저 물어야 합니다. 순서가 다르다면, 서로 다른 컷 정렬 키를 썼는지를 봐야 합니다. 신원 관계 자체가 맞지 않을 때만 원본 기록으로 돌아가 점검해야 하고, 먼저 몇 결과물의 행이 줄마다 맞출 것을 요구하면 안 됩니다.

이런 차이는 생성 방식의 결과지만, 「방식이 그렇다」는 것이 확인을 생략해도 된다는 말과도 같지 않습니다. 각 결과물은 서로 다른 책임을 지고, 수신자는 자기가 쓰는 필드가 정말로 같은 현장 기록 하나로 되돌아갈 수 있는지 확인해야 합니다.

FAQ

표 형태 결과물과 구조화 목록의 순서가 왜 다릅니까?

표 형태 결과물은 생성 시간순을 보존하고, 구조화 목록은 씬·컷·테이크로 다시 정렬하기 때문입니다. 둘은 같은 한 묶음의 스냅샷에서 출발하지만 뒤의 정렬 규격이 다릅니다.

멀티 카메라일 때 몇 파일의 총 행 수가 왜 다릅니까?

구조화 목록과 표 형태 결과물은 카메라별로 전개되어 멀티 카메라 테이크 하나가 여러 행을 차지하고, 사람이 읽는 데일리 리포트는 테이크 단위로 행을 내므로 같은 테이크가 여전히 행 하나만 차지합니다.

데일리 리포트의 No.를 다른 파일의 행 번호와 대조할 수 있습니까?

대조하지 않아야 합니다. 데일리 리포트의 No.는 문서 전체의 행 번호이고 테이크 번호와 같은 개념이 아니므로, 파일 간 신원 키로 쓸 수 없습니다.

몇 파일은 어떤 공통 키로 대조해야 합니까?

씬·컷·테이크 신원을 우선 쓰고, 멀티 카메라 기록에서는 카메라까지 계속 확인해야 합니다. 행 번호나 어느 파일의 정렬 위치를 공통 키로 취급하지 마십시오.

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