나는 프로젝트의 이틀째를 에피소드 제작 비용을 어떻게 더 낮출 수 있을지 고민하며 보냈다.

이 두 문장은 동시에 모두 사실이며, 이것이 이 시리즈가 다루고자 하는 이야기다. 상황은 다음과 같다.

내가 가정했던 것

7월 13일, 나는 얼굴을 공개하지 않는 (faceless) 숏폼 채널을 전업으로 구축하기로 결정했으며, 이를 단순히 끝에 송장을 발행하는 업무가 아닌 복리 자산 (compounding asset)으로 취급하기로 했다.

포맷은 "시니어 vs 주니어 (Senior vs Junior)"다. 하나의 코딩 문제를 두 번 해결한다: 순진한 방식 (naive way)과 베테랑의 방식 (veteran way). 9:16 세로 비율, 분할 화면, 왼쪽에는 빨간 조명 아래 당황한 주니어, 오른쪽에는 차가운 푸른 조명 아래 침착한 시니어. 슬로건은 "실행되는 코드와 배포되는 코드의 차이 (the difference between code that runs and code that ships)"다.

내 베팅은 기술적 정확성이었다. 나는 C, C++, C#, Java, JavaScript, TypeScript, VB로 프로덕션 코드 (production code)를 배포해 왔다. 누구나 오후 한나절이면 이와 유사해 보이는 채널을 만들어낼 수 있지만, 그들이 만들어낼 수 없는 것은 주니어 버전이 왜 실패하는지에 대한 정확한 설명이다. 개발자 관객은 CPM 표의 최상단에 위치하므로, 높은 CPM 니치 (niche) 시장에서의 정확성은 자동화된 저질 콘텐츠 (automated slop)와 경쟁하는 1인 운영자가 가질 수 있는 유일하게 방어 가능한 위치처럼 보였다.

두 번째 가정은 더 조용했으나 이후의 모든 것을 결정지었다. 나는 제약 조건 (binding constraint)이 크레딧 (credits)이 될 것이라고 가정했다.

실제로 일어난 일

파이프라인은 결정을 내린 지 하루 뒤인 7월 14일에 검증되었다. 네 단계로 구성된다.

각 블록에 대한 스틸 프레임 (still frame) 생성. 각 스틸을 8초 길이의 클립으로 애니메이션화. 비트당 하나의 보이스오버 (voiceover) 녹음. 각 블록의 오디오를 해당 블록에 동기화하고 자막을 입혀(burning in) 로컬에서 전체를 조립.

한 에피소드는 대략 10초 길이의 네 개 블록으로 구성된다: 콜드 오픈 (cold open), 주니어 코드, 시니어 코드, 핵심 포인트. 처음부터 끝까지 약 40초 분량이다.

같은 날, 퍼널 (funnel)이 라이브되었습니다. SQLite/D1 테이블을 기반으로 이메일 수집 기능이 포함된 원페이지 사이트를 구축하여, 매주 하나의 시니어 팁 (senior tip)을 제공하도록 했습니다. 그 후, 아무것도 게시하기 전에 출시 버퍼 (launch buffer)로 에피소드 1부터 5까지를 제작했습니다. 에피소드 1은 7월 17일에 공개되었으며, YouTube를 시작으로 교차 게시 (cross-posts)가 이어졌습니다.

어떻게 알아냈는가

나는 비용을 에피소드 단위가 아닌 단계별로 항목화했습니다: 스틸 프레임 (still frames), 각 비트 (beat)의 애니메이션, 보이스오버 (voiceover) 테이크.

한 단계가 모든 것을 압도합니다. 각각 8초 길이의 네 개 비트를 애니메이션화하는 것이 에피소드 크레딧 (credit) 비용의 압도적인 대부분을 차지합니다. 프레임과 보이스 테이크를 합쳐도 그 옆에서는 반올림 오차 수준에 불과하며, 이는 조절할 가치가 있는 유일한 레버 (lever)가 애니메이션화하는 비트의 개수뿐임을 의미합니다.

계정이 사용하는 플랜은 한 사이클당 약 3,000 크레딧을 제공하며, 생성되는 비트의 수에 따라 에피소드당 약 30에서 110 크레딧 사이의 비용이 발생합니다. 실제 제작 시에는 프레임이 잘못 나와서 다시 생성해야 하거나 애니메이션이 사용할 수 없는 상태로 돌아오는 경우가 있기 때문에 해당 범위의 상단에 위치하게 됩니다.

이제 내가 정확히 읽고도 무시했던 부분입니다. 구독은 사용 여부와 상관없이 갱신되며, 플랜 자체의 안내가 산술적인 계산을 대신 해줍니다. 에피소드당 비용을 기준으로 볼 때, 한 사이클당 약 3,000 크레딧은 크레딧이 소진되기 전까지 약 100개의 에피소드를 만들 수 있는 양입니다. 나는 5개를 제작하고 있었습니다. 에피소드 하나를 더 만드는 데 드는 한계 비용 (marginal cost)은, 중요한 의미를 갖는 모든 측면에서 제로 (zero)였습니다.

따라서 내가 이틀째에 최적화하려고 했던 숫자는 이미 제로였습니다. 그럼에도 불구하고 나는 최적화를 진행했습니다. 왜냐하면 이틀째에 내가 셀 수 있는 유일한 숫자가 그것뿐이었기 때문입니다. 조회수도, 시청 시간도, 가입자도 없었으며, 대신 측정할 수 있는 D1 테이블의 데이터도 아무것도 없었습니다.

무엇을 바꾸었는가

두 가지 결정 모두 이틀째에 내려졌으며, 둘 다 크레딧을 절감하기 위한 것이었습니다.

첫째, 재사용 (reuse)입니다. 블록 1 — 분할 화면 훅 클립 (split-screen hook clip) — 은 한 번 생성된 후 모든 에피소드에서 재사용됩니다. 블록 4 역시 마찬가지입니다: 그 위에 얹히는 보상 카드 (payoff card)와 보상 보이스오버 (payoff voiceover)입니다. 오직 훅 내레이션 (hook narration)과 두 개의 코드 비트 (code beats)만이 에피소드마다 변경됩니다. 명시적인 이유는 브랜드 인지도 (brand recognition)로, 카탈로그가 하나의 채널처럼 느껴지게 만드는 반복적인 오프닝과 클로징을 만드는 것이었습니다. 실제 이유는 네 개의 애니메이션 비트 중 두 개를 제거함으로써, 에피소드당 크레딧 비용을 대략 절반으로 줄일 수 있었기 때문입니다.

둘째, 하나의 목소리입니다. 단 하나의 프리셋 목소리인 "Sterling"이 모든 에피소드의 모든 대사를 읽습니다. 주니어, 시니어, 훅, 보상까지 모두 말이죠. 하나의 목소리는 제가 막 구축한 파이프라인 (pipeline)에서 변수를 하나 줄이는 것이며, 카탈로그 전반의 일관성은 단순한 클립의 더미가 아닌 하나의 채널처럼 보이게 합니다.

두 결정 모두 비용이 거의 들지 않았으며, 출시된 5개의 에피소드 모두에서 핵심적인 역할을 하고 있습니다. 이 점을 기억하세요.

제가 다르게 했을 것이라고 말하고 싶은 것

측정을 수행한 다음, 행동에 옮기기 전에 그 측정값이 실제로 무엇을 의미하는지 확인하십시오. 저는 크레딧 회계 (credit accounting)를 정확히 수행했고, 에피소드당 한계 비용 (marginal cost)이 사실상 제로라는 결론을 올바르게 내렸습니다. 하지만 그 후 하루 동안 '제로를 절반으로 줄이는' 데 시간을 허비했습니다. 왜냐하면 이틀째에는 크레딧은 셀 수 있었지만, 정작 중요한 것들은 셀 수 없었기 때문입니다. 만약 당신이 측정할 수 있는 유일한 숫자가 당신을 제약하지 않는 숫자뿐이라면, 정직한 방법은 자신의 대시보드에 놓여 있다는 이유만으로 그 숫자를 최적화하는 것이 아니라, 더 빨리 게시하여 플랫폼이 당신을 제약할 수 있는 숫자를 제공하게 만드는 것입니다.

이 글은 제로 상태에서 얼굴 없는 코딩 채널 (faceless coding channel)을 구축하는 과정에 대한 정직한 기록의 일부입니다.
채널: https://www.youtube.com/@amtocbot
매주 이메일로 전달되는 시니어 팁: https://seniorvsjunior.higgsfield.app