녹음 하나로 롱폼과 숏폼을 만드는 편집 하네스

문제 정의

병목은 말하는 데 있지 않고, 말한 것을 자르는 데 있었다

개인 팟캐스트를 직접 편집해서 올리고 있었다. 녹음 자체는 두 시간이면 끝난다. 그런데 그 녹음 하나를 롱폼 한 편과 숏폼 몇 편으로 만드는 데는 하루가 꼬박 들어갔다. 그중 판단이라고 부를 만한 시간은 길지 않았다.

어느 대목이 쓸 만한지 고르는 일은 듣는 동안 거의 끝나고, 나머지는 그 판단을 타임라인 위로 옮기는 손작업이었다. 자막을 몇 글자에서 끊을지, 컷을 어느 프레임에서 자를지 같은 결정을 회차마다 처음부터 다시 내리는 일이다. 한 회차의 롱폼 자막만 700줄이 넘는데, 그 줄을 하나씩 끊고 화면에 맞추는 데 시간이 가장 많이 들어갔다.

이 구조에서는 회차를 규칙적으로 낼 수 없다. 하루를 비울 수 있는 주에만 영상이 나가고, 그렇지 못한 주에는 녹음 파일만 쌓인다. 게다가 손이 많이 가는 만큼 한 회차에서 뽑는 숏폼 편수도 자연히 줄어든다. 만들 수 있는 만큼만 기획하게 되기 때문이다. 제약도 분명했다.

혼자 하는 일이라 본업 외 시간에만 붙을 수 있었고, 전사부터 렌더링까지 맥 한 대에서 돌려야 했으며, 편집 도구가 프로그램에게 열어주는 범위 밖으로는 나갈 수 없었다. 무엇보다 품질을 깎을 수 없었다. 자동화한 결과가 손으로 편집한 것보다 못하다면 자동화할 이유가 없기 때문이다.

가설 수립

편집툴은 손이지 두뇌가 아니다

먼저 두 갈래를 실제로 밀어봤다. 하나는 편집 도구 없이 ffmpeg로 영상을 통째로 찍어내는 방식인데, 자막 한 줄을 고치려 해도 전체를 다시 렌더링해야 해서 접었다. 다른 하나는 기존 편집 도구를 프로그램으로 조종하는 방식이었고, 이쪽은 실제로 붙여서 돌려봤다. 결과는 무겁고 원활하지 않았다. 도구가 켜져 있어야 했고, 응답이 느렸고, 조종이 걸린 지점에서 무엇이 잘못됐는지 알아내기 어려웠다.

설계를 한 번 통째로 버리기도 했다. 참고하던 이전 하네스가 다른 편집기를 전제로 만들어져 있어서 그쪽 구조를 그대로 옮기려다가, 이 맥에 실제로 무엇이 설치돼 있고 그 도구가 프로그램에게 무엇을 열어주는지 확인하고 나서 앞서 그린 그림을 버렸다. 두 번의 실패와 한 번의 폐기에서 읽은 것은 AI가 편집을 못 한다는 결론이 아니었다.

편집 도구에 판단까지 맡기려 한 것이 문제였다. 그래서 방향을 뒤집었다. 어느 말을 쓸지, 어디서 끊을지, 자막을 몇 글자로 나눌지 같은 판단은 전부 내 파이프라인이 갖고, 도구에는 이미 확정된 결과를 타임라인에 늘어놓는 조립만 시킨다. 이 가설이 맞다면 사람이 하는 일은 편집이 아니라 승인 몇 번으로 바뀌어야 했다.

솔루션 도출

도구의 AI 기능을 전부 끄는 것에서 시작했다

조립을 맡을 도구로는 프로그램 인터페이스를 열어둔 편집 앱을 골랐다. 다만 그 앱이 제공하는 자동 자막과 자동 컷 기능은 코드 수준에서 호출을 막았다. 진실의 출처가 둘이 되면 반드시 어긋나기 때문이다. 컷 목록은 내 파이프라인이 만든 것 하나만 존재하고, 도구는 그것을 그리기만 한다.

같은 이유로 기획 단계의 LLM에게는 초 단위 시간을 쓰지 못하게 했다. 구간은 문장 번호로만 지정하게 하고, 그 번호가 몇 초 몇 프레임인지는 스크립트가 계산한다. 코드를 짜기 전에 실제 앱을 상대로 스무 단계를 한 바퀴 돌려 응답 형태부터 확인한 것도 같은 이유였는데, 문서에 적힌 자막 입력 방식이 정작 설치된 판본에는 없다는 것이 그 자리에서 드러났다.

정작 가장 오래 붙잡은 것은 자막도 화자 구분도 아니었다. 잘 됐다는 보고를 믿을 수 없다는 문제였다. 화자 명패 점유율은 33%에서 34%로 멀쩡한데, 그 안에서 21자짜리 발화가 통째로 다른 화자의 것으로 흡수돼 있었다. 도구가 응답에서 서른 개까지만 돌려준다는 것을 모르고 보낸 탓에 127개 컷이 97개로 들어간 적도 있는데, 그때도 검사는 전부 통과였다. 총량 지표는 개별 오류를 덮고, 검수용 정지 화면은 시간축에서 생긴 결함을 보지 못한다.

그래서 일하는 방식을 세 가지로 바꿨다. 통과 보고 대신 결과물 프레임을 직접 열어 보고, 만든 쪽이 자기 일을 검증하지 못하게 맥락 없는 검증자에게 체크리스트를 들려 보내고, 한 번 덴 것은 회차가 끝날 때마다 규칙 문서에 박아둔다.

파이프라인이 만든 결과가 편집 앱에 들어간 모습. 왼쪽 라이브러리의 롱폼 한 편과 숏폼 열네 편, 아래 트랙의 명패 클립까지 사람이 손으로 놓은 것은 하나도 없다. 이름과 경로는 가렸다.

실행 도중에 전제가 뒤집힌 적도 있다. 36분짜리 롱폼을 1080p로 뽑는 마지막 단계에서 여섯 번 연속 실패했다. 코덱을 바꿔도, 트랙을 줄여도 비슷한 지점에서 같은 메모리 오류로 죽었다. 세로 숏폼은 같은 픽셀 수인데도 열네 편이 전부 성공했으므로 해상도 자체의 문제도 아니었다.

원인 후보를 하나씩 배제하고 남은 설명은 길이와 해상도의 누적이었고, 한 번에 뽑는다는 전제를 버렸다. 타임라인을 여섯 구간으로 나눠 따로 뽑은 뒤 무손실로 이어붙이자 65,601프레임이 정확히 일치했고, 이음매 열 곳의 픽셀 차이는 0이었다. 화질도 디자인도 깎지 않았다.

결과 & 배운 점

하루가 한 시간이 되었고, 남은 자산은 영상이 아니었다

이 파이프라인으로 만든 회차를 실제로 게시했다. 하루 꼬박이던 한 회차가 사람이 붙어 있는 시간 기준으로 한 시간 안팎까지 줄었고, 그 한 회차에서 36분짜리 롱폼 한 편과 숏폼 열네 편이 나왔다. 처음 기획은 숏폼 세 편이었다. 그런데 그 세 편이 전부 후반부에 몰려 있어서 정작 롱폼 제목이 걸고 있던 주장이 숏폼에는 없었고, 편수를 미리 정하지 않기로 하고 후보를 다시 뽑자 열네 편이 됐다.

전사와 렌더링, 익스포트는 여전히 오래 걸리지만 그건 기계가 혼자 도는 시간이라 그동안 다른 일을 할 수 있다. 물론 아직 못 하는 것도 분명하다. 입력은 오디오만 받고, 한 마이크에 두 사람이 섞여 녹음된 경우에는 화자를 나누지 못하며, 배경 음악과 엔딩 카드는 아직 없다.

실제로 게시한 회차의 완성본 프레임. 왼쪽이 롱폼, 오른쪽이 숏폼이며 자막과 명패는 전부 파이프라인이 배치했다. 채널명과 출연자 정보는 가렸다.

돌아보면 이 작업에서 남은 자산은 영상 파일이 아니라 규칙이었다. 파이프라인 코드는 약 7,400줄인데 그것을 검사하는 테스트가 거의 같은 분량이고, 어떤 판단을 왜 그렇게 내렸는지 적어둔 규칙 문서는 그보다 많다. 한 회차를 닫으면서 그 회차에서 배운 것을 백 건 넘게 추려 하네스에 되먹인 적도 있다. 나는 코드를 직접 쓰지 않았다.

대신 어떤 판단을 기계에 넘기고 어떤 판단은 넘기지 않을지 정했고, 나온 결과를 승인하거나 거부했다. 그 과정에서 가장 크게 배운 것은 한 회차를 잘 뽑는 일보다 이번에 덴 것을 다음 회차가 다시 밟지 않게 만드는 쪽이 훨씬 오래 남는다는 점이다. 지금은 새 회차를 열면 지난 회차에서 배운 규칙들이 이미 켜져 있다.