현장 기록 / W1 · 마감 전달

한 씬을 다 찍은 뒤, 스크립터는 마감 전에 무엇을 넘기는가

한 씬을 다 찍은 뒤에 스크립터가 남겨야 할 것은 「표 하나」가 아니고, 하류가 현장의 사실을 다시 알아볼 수 있게 만드는 한 묶음의 기록입니다. 테이크별 기록은 이것이 어느 씬의 어느 컷의 몇 번째 테이크인지, 현장에서 어떤 등급과 메모를 주었지에 답해야 하고, 콘티뉴이티 증거는 구체적인 항목으로 돌아가 확인하게 만들어야 하며, 타임코드 대조는 시간 위치가 어디서 왔는지를 설명해야 하고, 전달 목록은 수신자가 무엇을 손에 넣었는지 스스로 알 수 있게 해야 합니다. SlateX는 현재 같은 한 묶음의 기록을 여러 교환 형태로 비출 수 있지만, 수신자가 이 문자값들을 확인하는 일까지 대신하지는 못합니다.

마감 전달의 핵심은 「파일 하나 생성한다」가 아니라, 다음에 읽는 사람이 기록을 다시 그 씬과 그 컷과 그 테이크로 되돌릴 수 있게 하는 것입니다.

먼저 업계의 임무와 소프트웨어 결과물을 나눕니다

스크립터의 업계 임무는 촬영 과정에서 생긴 신원, 판단, 연속성 단서를 하류에게 남기는 것입니다. 테이크별 기록은 보통 소재와 촬영 상태를 다시 위치해야 하는 사람에게 쓰이고, 콘티뉴이티 증거는 뒤에서 의상·분장·소품이나 동작, 화면의 연속 관계를 확인해야 하는 사람에게 쓰이며, 타임코드 대조는 기록과 실제 미디어의 시간 위치를 한 자리에 놓고 점검해야 하는 사람에게 쓰이고, 전달 목록은 이번 전달에 어떤 파일이 들고 어떤 정보는 출처로 돌아가야 하는지를 수신자에게 알려 줍니다.

SlateX의 현재 출력은 소프트웨어 결과물이지 이 업계 임무 그 자체와 같지 않습니다. 구조화 목록과 표 형태 파일, 사람이 읽는 데일리 리포트, 대본 프로젝트 파일을 생성할 수 있습니다. 이 결과물들은 이미 기록된 데이터를 서로 다른 형태로 쓰므로 「한 번 더 베껴 적는」 단계는 줄여 주지만, 「사람이 이 기록과 소재가 맞는지 확인한다」는 일까지 절차에서 빼 내지는 않습니다.

그러므로 전달을 말할 때는 두 층을 나눠야 합니다. 스크립터는 추적에 충분한 정보를 남기는 쪽을 담당하고, 소프트웨어는 이미 있는 기록을 파일로 비출 뿐입니다. 앞의 것은 판단과 책임을 요구하지만, 뒤의 것은 데이터 표현일 뿐입니다.

테이크 기록은 다시 알아볼 수 있는 신원을 남겨야 합니다

기록 한 개는 최소한 씬·컷·테이크라는 열쇠로 되돌아갈 수 있어야 합니다. 등급과 메모가 답하는 것은 현장이 그때 어떤 판단과 보충 정보를 남겼는가이고, 신원이어야 서로 다른 전달물 사이에서 다시 맞춰지는 기초가 됩니다.

이 점이 특히 중요한 이유는, 같은 한 묶음의 테이크 기록이 서로 다른 결과물에서 행 수도 행 순서도 다르게 나타나기 때문입니다. 표 형태와 구조화 목록은 멀티 카메라 기록에서 카메라별로 전개해 여러 행을 만들고, 사람이 읽는 데일리 리포트는 테이크 하나에 행 하나입니다. 정렬도 각자의 규격을 거칩니다. 따라서 「몇 번째 행」을 파일 간 신원으로 쓸 수 없고, 받을 때 계속 씬·컷·테이크로 대조해야 합니다.

콘티뉴이티 증거는 구체적인 기록으로 돌아가야 하고 미디어 덩어리만 남기면 안 됩니다

콘티뉴이티 사진이나 그 밖의 증거가치는, 그것이 구체적인 촬영 기록과의 관계를 아직 붙이고 있다는 데 있습니다. 뒤에서 돌아볼 때는 이 증거가 어느 촬영, 어느 컷, 어느 연속성 대상과 관련되는지 알아야 하고, 문맥 없는 앨범 뭉치만 보면 안 됩니다.

그것은 소프트웨어가 사람을 대신해 콘티뉴이티 판단까지 마쳤다는 뜻이 아닙니다. 사진을 기록에 걸고 함께 돌려볼 수 있게 하는 일과 「화면이 정말로 연속되는가」는 서로 다른 두 일입니다. 전달할 때는 추적 관계를 보존해 다음을이어받는 사람이 스스로 판단하게 해야 하고, 도구의 연결 메커니즘을 결론처럼 써서는 안 됩니다.

타임코드 대조는 어디를 다시 봐야 하는지 수신자에게 알려야 합니다

시간 위치의 역할은 텍스트 기록이 미디어와 같은 시간축에서 점검될 기회를 주는 것입니다. 그러나 수신자는 필드가 합법적인 타임코드처럼 보인다는 이유만으로 그대로 믿어서는 안 됩니다. 어떤 전달 필드는 현장 기록에서 오고, 어떤 것은 소프트웨어가 파생시키며, 어떤 결손치는 자리채움 내용까지 얻습니다.

그래서 스크립터가 넘기는 것은 타임코드 문자열 하나가 아니고, 「이 기록은 누구이며 이 값은 어디서 확인해야 하는가」라는 문맥까지입니다. 하류가 바로 쓸 수 있는지와 관련해서는, 수신자가 자기 절차에 맞춰 열마다 확인해야 합니다.

같은 한 묶음의 기록은 서로 다른 전달 형태로 변합니다

SlateX의 현재 네 가지 교환 형태가 감당하는 일이 서로 다릅니다. 구조화 목록과 표 형태 파일은 필드 단위로 읽는 데 알맞고, 사람이 읽는 데일리 리포트는 사람이 넘기는 판에 가까우며, 대본 프로젝트 파일은 대본 구조 자체로 돌아갑니다. 네 개의 행 단위 사본이 아닙니다.

핵심 경계 하나는 멀티 카메라입니다. 한 테이크에 카메라가 여러 대 걸리면 구조화 목록과 표 형태 파일은 여러 행에 전개되지만, 데일리 리포트는 여전히 테이크 하나에 행 하나이고 그 행의 카메라 파라미터는 한 대만 취합니다. 말하자면, 멀티 카메라 씬의 모든 기기 파라미터가 데일리 리포트의 같은 행에 동시에 나타나지는 않습니다.

전달물은 서로를 참조하는 한 묶음의 파일이지, 행 번호로 행마다 이어 붙일 수 있는 사본 묶음이 아닙니다.

사람을 바꿀 때 「인수인계」를 제품 능력으로 써서는 안 됩니다

SlateX에는 현재 「인수인계」나 「교대」, 여러 사람이 동시에 수정하는 일의 구현이 없습니다. 사람을 바꿀 때는 새 기기에서도 작업 위치를 다시 골라야 하고, 소프트웨어에는 「인수인계 완료」로 홍보할 수 있는 상태가 없습니다.

그러므로 이 글에서 말할 수 있는 것은 어떤 정보를 기록에 남겨 두어야 하는가입니다. 씬·컷·테이크 신원, 현장 판단과 메모, 콘티뉴이티 증거의 연결 관계, 시간 위치, 전달에 무엇이 들었는가. 이 기록들이 존재한다는 것을 더 진행해 「연속 인수인계를 지원한다」거나 「여러 사람 협업」으로 쓰지는 못합니다.

테이크 기록은 「정확히 무엇을 적는가」를 따로 답해야 합니다

마감 전달의 상위 질문까지는 여기에서 「어떤 정보 무리를 남겨야 하고, 하류는 왜 그것이 필요한가」에서 멈춥니다. 테이크 기록 한 개 안쪽에 실제로 무엇이 들어 있어야 하는지는 이미 독립 페이지 『테이크 기록 한 개는 어떤 인수 가능 정보를 남기는가』가 이어 펼쳐 말하고 있습니다. 그 주제는 한 기록의 필드와 경계를 다루므로, 이 글에서 전달 형태를 다시 설명하지 않습니다.

FAQ

마감 전달은 표 하나 내보내면 끝납니까?

끝나지 않습니다. 테이크별 기록과 콘티뉴이티 증거, 타임코드 대조, 전달 목록은 서로 다른 책임을 지고, 소프트웨어 출력에도 여러 형태가 있으므로 그중 파일 하나를 전체 전달물로 취급할 수 없습니다.

몇 장의 전달 파일을 행 번호로 서로 대조하면 안 되는 이유는 무엇입니까?

같은 한 묶음의 기록이 서로 다른 결과물에서 서로 다른 전개 방식과 정렬 방식을 쓰고, 멀티 카메라 기록은 일부 결과물에서 여러 행에 나뉘기 때문입니다. 파일 간에는 씬·컷·테이크 신원으로 다시 맞춰야 합니다.

데일리 리포트에서 한 테이크의 모든 카메라 파라미터를 함께 볼 수 있습니까?

볼 수 없습니다. 현재 데일리 리포트는 테이크 하나에 행 하나이고 그 행의 카메라 파라미터는 한 대에서 오므로, 멀티 카메라 정보가 한 행에 모두 모이지 않습니다.

SlateX는 교대 인수인계나 여러 사람의 동시 수정을 지원합니까?

현재 그런 구현이 없습니다. 이 글은 핵심 정보를 기록에 남겨 두어야 한다고만 요구할 수 있고, 기록 그 자체를 「인수인계」나 「여러 사람 협업」 능력으로 쓸 수는 없습니다.


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