세로로 만들어 두면 가로는 잘라 쓰면 된다고 믿었다 — 화면비 한 줄이 완성본 22컷을 죽인 날

화면비는 마지막에 정하면 되는 값이라고 믿고 있었다

이 믿음은 명시적으로 결정된 적이 없다. 어디에도 안 적혀 있고 그냥 오래 깔려 있었다.

세로로 만들어 두면 나중에 가로가 필요할 때 양옆을 잘라 쓰면 된다 — 편집 단계의 상식이고 실제로 촬영물에서는 대체로 맞는다. 그래서 화면비를 편집에서 되돌릴 수 있는 값으로 분류해 뒀다. 되돌릴 수 있는 값이라고 믿으면 그건 나중으로 미뤄도 되는 것이 되고 나중으로 미뤄도 되는 것은 확정하지 않은 채로 그 위에 계속 쌓게 된다.

명시적으로 결정된 적이 없다는 게 이 믿음의 가장 나쁜 점이다. 결정으로 적혀 있었으면 개정판이 들어왔을 때 그 줄을 찾아가 뒤집으면 됐다. 적혀 있지 않은 전제는 뒤집을 자리가 없고 뒤집히는 순간에야 존재가 드러난다. 그리고 그때는 이미 그 위에 뭔가가 쌓여 있다.

그렇게 쌓은 것이 채택 완성본 12컷, 반려를 세 판까지 반영해 겨우 통과시킨 완성본 10컷, 그리고 이틀 동안 만든 편성 11편 100컷이었다. 마지막 것은 9분 17초짜리다. 세 번째 반려를 반영할 때까지도 그 컷들이 세로라는 사실은 아무도 안 봤다. 반려는 전부 화면 안의 내용에 관한 것이었고 프레임 자체는 검토 대상이 아니었다.

개정판 두 줄이 들어온 뒤 이 셋은 전부 재사용 불가가 됐다.

판정은 취향이 아니라 곱셈 한 줄이었다

두 줄 중 대사 쪽은 얼핏 가벼워 보인다. 영어를 한글로 갈아 끼우면 되는 것 같다. 그런데 우리 파이프라인에서 대사는 자막이 아니라 생성 프롬프트 안에 박혀 있다. 말이 바뀌면 프롬프트가 바뀌고 프롬프트가 바뀌면 그 컷은 다시 굽는 것 말고 방법이 없다. 언어 교체가 「고치기」가 아니라 「재생성」인 이유가 여기 있다.

그래도 대사는 재생성으로 끝난다. 화면비는 재생성조차 선택지가 아닌지부터 따져야 했다. 「잘라 쓰면 된다」가 왜 여기서 안 되는지는 숫자로 끝난다.

기존 컷은 768×1376 세로다. 이걸 16:9 로 만들려면 위아래를 버리고 가로폭을 그대로 쓴다. 그러면 768×432 가 나온다. 새 규격은 1376×768 이다.

768 은 1376 보다 작다. 잘라낸 결과가 목표보다 작다. 가로세로 어느 쪽으로 봐도 모자라기 때문에 업스케일 없이는 타임라인에 못 올린다. 그리고 업스케일한 컷과 원본 해상도로 새로 구운 컷을 한 편에 섞으면 같은 편 안에서 선예도가 갈린다 — 그건 편집으로 못 감춘다.

여기서 알게 됐다. 화면비가 되돌릴 수 있는 값인지 아닌지는 애초에 어느 방향으로 만들었는지에 달려 있다. 가로로 크게 만들어 두고 세로로 자르는 건 대체로 된다. 남는 픽셀에서 빼 쓰는 거니까. 세로에서 가로로 자르는 건 없는 픽셀을 요구한다. 같은 「자르기」인데 방향에 따라 한쪽만 성립한다.

「나중에 바꿀 수 있다」고 분류할 때 우리가 확인했어야 할 건 「자를 수 있는가」가 아니라 「자른 뒤에도 목표 규격보다 큰가」였다. 이 질문을 한 번도 안 던졌다.

그리고 이 질문은 던지는 데 5분도 안 걸린다. 곱셈 한 번이고 컷을 굽기 전에도 답이 나온다. 비용이 컸던 건 계산이 아니라 계산할 생각을 안 한 기간이다. 100컷을 편성하는 동안 이 곱셈을 한 번만 했으면 그 100컷은 안 만들었을 것이다. 값싼 검산을 미루면 그 검산이 비싸지는 게 아니라 검산 뒤에 버려야 할 것이 비싸진다.

죽은 것과 살아남은 것을 가른 기준은 픽셀이 아니라 서술이었다

전량 폐기라고 적으면 사실이 아니다. 무엇이 살아남았는지 나누고 보니 경계가 선명했다.

공간 서술은 다른 씬으로 그대로 이식했다. 레터박스 스크립트 2종은 가로 파이프라인에서 그대로 쓴다. 레퍼런스 2장은 애초에 인물 동일성을 잡으려고 확정해 둔 것이라 화면비와 무관하다.

정리하면 화면비에 묶인 산출물은 전부 죽었고, 안 묶인 것은 전부 살았다. 그리고 살아남은 쪽은 공통적으로 픽셀이 아니라 설명이다. razor wire 와 work light 를 어떻게 배치할지 적어 둔 문장은 세로든 가로든 상관이 없다. 그 문장으로 구운 결과물만 화면비를 갖는다.

이걸 알고 나면 작업물을 만들 때 어느 쪽에 시간을 쌓고 있는지가 다르게 보인다. 설명에 쌓은 시간은 규격이 바뀌어도 남고 픽셀에 쌓은 시간은 규격과 같이 죽는다. 이번에 이틀치가 날아간 이유는 그 이틀이 대부분 픽셀 쪽 편성에 들어갔기 때문이다.

한 챕터는 이유가 하나 더 있었다. 그 장면의 대면 자체가 개정 정본에 없다. 화면비가 맞았어도 못 썼을 컷이라는 뜻이다. 같은 「폐기」라도 규격이 안 맞아서 죽은 것과 이야기에서 사라져서 죽은 것은 성격이 다른데 집계할 때는 한 줄로 합쳐진다. 이 구분을 안 해 두면 나중에 「화면비 때문에 몇 컷을 잃었나」를 물었을 때 실제보다 큰 수가 나온다.

다시 만든 것 — 규격을 먼저 못 박고 그 위에 전부 얹었다

같은 실수를 반복하지 않는 방법은 하나뿐이었다. 규격을 먼저 확정하고 전 구간을 한 번에 쓰는 것. 구간별로 나눠 쓰면서 규격을 미루면 나중에 바뀔 때 또 앞부분부터 죽는다.

그날 새 편성 프롬프트 1차 55컷을 썼고 자정을 넘겨 나머지 104컷이 닫혔다. 합쳐서 전 구간 159컷 / 859.66초 = 14분 20초다.

• 전 컷 1376×768 — 예외 없음. 「이 컷만 세로가 어울린다」를 애초에 못 만들게 했다
• 길이는 5.17초 격자로 통일하고, 3단계로 전개되는 사건만 5.88초를 줬다
• seed 는 7 + YYYYMMDD + 씬 + 컷 규칙으로 기계 생성했다 — 중복 0
• 대사는 개정 정본 원문을 한 글자도 바꾸지 않고 그대로 넣었다

길이를 격자로 묶은 것도 같은 이유다. 컷마다 길이가 제각각이면 편성이 바뀔 때 앞뒤가 전부 밀려서 사실상 다시 짜야 한다. 격자에 맞춰 두면 컷을 빼고 넣는 일이 자리 이동으로 끝난다. 이번처럼 위쪽에서 한 줄이 바뀌었을 때 아래쪽이 얼마나 버티는지가 결국 그 아래쪽을 얼마나 규칙적으로 만들어 뒀는지에 달려 있다.

seed 를 규칙으로 만든 것도 마찬가지다. 손으로 넣으면 중복이 생기고 중복이 생기면 다른 컷인데 같은 그림이 나온다. 규칙으로 만들면 중복 여부를 세어서 확인할 수 있다. 159컷을 세어 봤고 중복은 0 이었다.

대사를 그대로 옮긴 줄은 규칙이 아니라 방어다. 대사를 옮기면서 다듬으면 그 다듬은 판본이 사실상 새 정본이 되고 다음에 정본이 또 개정될 때 무엇이 원문이고 무엇이 우리 손이 간 것인지 구분이 안 된다. 이번에 영어 대사를 전부 버리게 된 것도 원본과 산출물이 갈라져 있었기 때문이다. 한 글자도 안 바꾸면 다음 개정 때 차이만 보면 된다.

같은 날 옛 프롬프트 6폴더 182파일을 별도 폴더로 격리하고 참조 90건을 고쳤다. 이름변경은 170건 전량 인식됐고 그중 161건은 100% 유사도로 붙었다. 백업 파일도 짝 그대로 같이 옮겼다. 정리하려고 옮긴 게 아니다. 폴더만 보고 옛것과 새것이 갈리게 하려고 옮겼다. 같은 저장소에 세로용과 가로용 프롬프트가 섞여 있으면 몇 주 뒤에 누군가 세로용을 열어 가로 편성에 쓴다. 판정을 문서에 적어 두는 것보다 경로를 갈라 두는 쪽이 오래 간다. 문서는 안 읽히면 없는 것과 같지만 폴더 이름은 파일을 열 때마다 눈에 들어온다.

옮기는 김에 참조 90건을 같이 고쳤다. 이게 이관에서 제일 실수가 나기 쉬운 부분이다. 파일만 옮기고 참조를 안 고치면 문서와 스크립트가 없는 경로를 가리키게 되고 그러면 이관이 정리가 아니라 고장이 된다. 백업 파일을 짝 그대로 같이 옮긴 것도 같은 이유다 — 본체만 옮기면 백업이 원래 자리에 남아서 나중에 그 백업이 새것처럼 보인다.

판정이 맞다는 것과 지워도 된다는 것은 다른 문제다

여기까지는 기술 판단이고 마지막 하나가 남았다.

죽은 22컷 중 12컷은 대표가 채택한 완성본이고, 10컷은 반려를 세 판까지 반영해서 통과시킨 것이다. 해상도 계산은 우리가 했고 그 계산은 맞다. 그렇다고 지울 수 있는 건 아니다.

파일은 하나도 지우지 않았다. 재사용 불가라는 판정만 올리고 실물은 그대로 뒀다.

만든 쪽이 「이건 이제 못 씁니다」와 「그래서 지웠습니다」를 한 호흡에 처리하면 받는 쪽에는 결정할 기회 자체가 안 간다. 폐기는 기술 판정에서 자동으로 따라 나오지 않는다. 별도의 결정이고 그 결정은 그 작업을 채택한 쪽의 몫이다. 우리가 할 일은 판정과 근거를 정확히 올리는 것까지다. 곱셈 한 줄을 그대로 보고에 적은 것도 그래서다 — 결론만 주면 뒤집을 근거가 없다.

계산이 맞다는 확신이 셀수록 이 선을 넘기 쉽다. 768×432 가 1376×768 보다 작다는 건 반박의 여지가 없고 그러면 「어차피 답이 정해졌는데」가 된다. 그런데 우리가 확신한 건 그 컷을 이 편성에 쓸 수 없다는 것뿐이다. 다른 데 쓸 수 있는지, 참고용으로 남길지, 나중에 다시 볼지는 우리가 아는 범위 밖이다. 판정의 범위를 넘어서 처분까지 하는 것이 위험한 건 판정이 틀려서가 아니다. 판정이 답하지 않은 질문까지 답한 것처럼 굴기 때문이다.

그날 실제로 수행한 두 건, 정본을 프롬프트로 옮긴 것과 옛 프롬프트를 격리한 것이 지시 대장에 한 줄도 없다. 지시를 받았고 수행까지 했는데 기록만 없는 상태다. 폐기 판정을 파일이 아니라 문서로 올려 둔 것이 의미가 있으려면 그 문서가 읽히는 자리에 있어야 하는데 같은 날 그 자리에 아무것도 안 올라갔다는 게 걸린다. 지워도 되는지를 남이 정하게 하려면 그 남이 정할 것이 있다는 사실부터 도착해야 한다. 파일을 안 지운 것만으로는 절반이다.

남은 갈래도 하나씩만 적어 둔다. 그날 영상 산출물은 텍스트뿐이고 mp4 · png 신규가 0건이다. 그리고 가로 전환이 실제로 되는지는 한 컷도 안 구워 봤는데 이제 전 편성 159컷이 그 전제 위에 서 있다. 어제까지 이건 한 챕터짜리 미확인이었다. 하루 만에 전 구간의 전제가 됐다. 미확인 항목은 그 자리에 가만히 있어도 무게가 커진다 — 그 위에 쌓이는 것이 늘어나기 때문이다. 9:16 로 100컷을 쌓는 동안 아무도 그 무게를 재지 않았던 것과 정확히 같은 모양이다. 이번에는 적어도 그 미확인이 무엇인지 이름이 붙어 있다는 게 다르다. 가로 전환 실측 한 컷, 그게 지금 159컷 전부를 떠받치고 있는 유일한 미검증 전제다.