영어를 쓰는 시청자를 대상으로, 성경 말씀을 애니메이션 쇼츠(1분 이내 짧은 세로 영상)로 만드는 유튜브 채널을 운영하고 있습니다.
처음 시작할 때는 꽤 단순하게 생각했습니다.
성경 구절 하나를 고르고 거기에 이미지와 목소리만 붙이면 되는 줄 알았습니다. 그런데 막상 채널을 운영해 보니 기획, 자동화, 오류 잡기(디버깅)까지 생각보다 훨씬 많은 부분을 건드리게 됐습니다.
이 글은 잘 끝난 성공담이 아닙니다. 지금까지 겪은 시행착오를 영상 만드는 순서대로 정리한 기록입니다.
평소 회사에서 오라클 ETL(데이터를 모아 옮기고 정리하는 작업)이나 시스템끼리 데이터를 주고받는 파이프라인을 다뤘던 경험이, 뜻밖에도 영상 자동화 파이프라인을 짤 때 그대로 도움이 됐습니다.
여러 도구를 순서대로 이어서 데이터(여기서는 영상)를 차례로 흘려보낸다는 점에서, 회사에서 하던 일과 근본적으로 크게 다르지 않았습니다.
① 기획 단계에서 만난 첫 번째 벽: 사람들이 끝까지 안 본다
채널을 어느 정도 운영한 뒤, 전문가에게 채널 분석(컨설팅) 보고서를 받아 본 적이 있습니다.
기대와 달리 지적받은 내용이 꽤 아팠고, 열심히 만든 영상들을 처음부터 다시 보게 되는 계기가 됐습니다.
첫 번째 지적: "찍어 낸 AI 템플릿 느낌이 난다"
AI로 자동으로 만든 영상에서 흔히 보이는 틀에 박힌 패턴이, 보는 사람에게도 그대로 느껴진다는 뜻이었습니다.
두 번째 지적: 처음 3초 안에 붙잡는 장치(후킹)가 없다
쇼츠는 처음 몇 초 안에 계속 볼지 넘길지가 정해집니다. 그런데 제 영상들은 설명부터 차분하게 시작하는 구조라서, 초반에 넘겨 버리는 비율이 높았습니다.
실제로 시청 지속률(시청자가 영상의 어디까지 보는지 보여 주는 그래프)을 확인해 보니, 시작하고 몇 초 안에 상당수가 빠져나가는 모양이 뚜렷했습니다. 그 그래프를 보는 순간, 막연하게만 느끼던 문제가 눈앞의 숫자로 확인되는 기분이었습니다.
세 번째 지적: 누구에게 무슨 이야기를 하려는지 흐릿하다
누구를 위한 영상인지, 어떤 감정이나 메시지를 전하려는 건지가 영상 안에서 분명하게 드러나지 않는다는 의견이었습니다.
돌이켜 보면 자동화에만 집중하다 보니, 정작 영상의 핵심인 이야기 흐름과 볼 사람을 정하는 일에는 소홀했던 것 같습니다.
그래서 방향을 크게 바꿨습니다
컨설팅에서 받은 조언은 "AI 에이전트(스스로 여러 작업을 이어서 처리하는 AI 도구)를 직접 만들어서, 여러 종류의 영상을 조금씩 빠르게 만들어 시험해 보고, 반응이 오는 주제로 바로 옮겨 가라"는 것이었습니다.
이 이야기를 듣고 나서야 비로소 목표가 분명해졌습니다.
영상을 하나하나 손으로 만드는 대신, 직접 만든 파이프라인으로 여러 버전을 빠르게 만들어 보고, 반응이 좋은 형태를 찾아가는 방식으로 바꾸기로 했습니다.
외주 제작을 맡기거나 이미 만들어진 온라인 서비스(SaaS)를 그대로 쓰는 방법도 고민했습니다. 하지만 채널 운영에 맞게 세세하게 조정하려면, 결국 파이프라인을 직접 만드는 게 낫다는 결론을 내렸습니다.
그래서 이른바 "바이브 코딩" 방식, 그러니까 AI에게 도움을 받아 가며 대화하듯 코드를 짜는 방식으로 자동화 도구를 직접 조립해 나가기로 했습니다.
② 자동화 파이프라인을 만든 과정
파이프라인은 n8n이라는 도구를 바탕으로 만들었습니다. n8n은 여러 서비스를 블록(노드)처럼 이어 붙여서 작업을 자동으로 흘러가게 해 주는 자동화 도구입니다.
목표는 여러 도구를 순서대로 이어서, 성경 구절 영상을 자동으로 만들어 내는 흐름을 완성하는 것이었습니다.
대본과 내레이션 글: 구글 제미나이(Gemini)
성경 구절을 넣으면, 영상에 쓸 대본과 장면 구성을 자동으로 뽑아 주는 단계입니다.
목소리: 일레븐랩스(ElevenLabs)
글을 자연스러운 내레이션 목소리로 바꿔 주는 역할을 합니다. 목소리 톤이나 말하는 속도만 조절해도 영상 분위기가 꽤 달라진다는 걸 여러 번 확인했습니다.
영상 만들기: 여러 번 바뀐 도구
영상을 만드는 도구는 몇 번이나 바뀌었습니다.
처음에는 Kling AI와 구글 Veo를 함께 검토했습니다. 그 뒤 비용과 품질을 따져서, fal.ai에서 제공하는 Veo 3.1 Lite(쓴 만큼만 돈을 내는 방식)로 옮겼습니다.
영상 도구를 바꾸면서 AI에게 주는 지시문(프롬프트) 구조 전체를 다시 손봐야 했는데, 이 작업이 생각보다 훨씬 큰 일이었습니다.
결과물과 진행 상황 관리: 구글 드라이브와 노션
만들어진 영상 파일은 구글 드라이브에 정리하고, 에피소드별로 어디까지 진행됐는지는 노션 데이터베이스로 관리합니다.
이렇게 여러 도구를 하나의 흐름으로 이어 두면, 성경 구절 하나를 넣었을 때 대본 만들기부터 목소리, 영상, 파일 정리까지 차례로 자동 처리되는 구조가 완성됩니다.
도구를 고를 때 가장 중요했던 건 비용과 품질의 균형
처음에 구글 Veo를 검토했을 때는 품질은 만족스러웠지만, 요금 구조가 지금 채널 규모에 비해 부담스러웠습니다.
여러 대안을 비교해 본 끝에, 쓴 만큼만 돈을 내는 fal.ai의 Veo 3.1 Lite로 옮겼습니다. 덕분에 여러 버전을 시험 삼아 만들어 보는 데 필요한 여유를 얻을 수 있었습니다.
도구끼리 데이터 모양을 맞추는 일
파이프라인을 하나로 잇는 과정에서는 도구마다 주고받는 데이터 모양이 달라서 신경 쓸 게 많았습니다.
한 도구가 내놓은 결과가 다음 도구가 원하는 입력 모양과 딱 맞지 않는 경우가 많아서, 중간중간 모양을 바꿔 주는 작업이 은근히 많이 필요했습니다.
이런 일은 눈에 띄지는 않지만, 파이프라인 전체가 안정적으로 돌아가는지를 좌우하는 핵심 작업이었습니다.
③ 파이프라인을 안정시키면서 만난 버그와 해결 과정
파이프라인이 어느 정도 돌아가기 시작한 뒤에도, 실제로 운영하다 보니 생각지 못한 문제들이 계속 튀어나왔습니다.
첫째, AI 도구의 콘텐츠 검열 문제
성경 내용 가운데 일부 표현이 AI 영상 도구의 콘텐츠 정책에 걸려서, 영상 만들기가 거부되는 경우가 있었습니다.
이 문제는 지시문(프롬프트) 안에서 민감할 수 있는 표현을 상징적인 표현으로 바꿔 주는 방식(symbolic substitution)으로 돌아가서 해결했습니다.
직접적인 표현 대신, 같은 뜻을 전하면서도 검열 정책에 걸리지 않는 표현을 찾는 과정이 은근히 까다로웠습니다. 여러 번 시도하고 실패하면서, 잘 통하는 지시문 패턴을 하나씩 모아 나갔습니다.
둘째, 구절별 파일이 중복으로 만들어지는 문제
파이프라인을 여러 번 다시 돌리다 보니, 이미 만든 구절의 영상을 또 만들어 버리는 낭비가 있었습니다.
그 뒤로는 작업을 시작하기 전에 해당 구절의 파일이 이미 있는지 먼저 확인하는 코드를 넣어서, 중복 없이 이어서 작업할 수 있게 고쳤습니다.
이 확인 코드 하나만으로도 쓸데없이 반복되던 API 호출 비용(외부 AI 서비스를 쓸 때마다 나가는 돈)을 꽤 줄일 수 있었습니다. 또 파이프라인을 중간에 멈췄다가 다시 돌려도 안전하게 이어 갈 수 있게 됐습니다.
셋째, 한글 노드 이름 때문에 생긴 파일 이름 버그
n8n 작업 흐름 안에서 일부 블록(노드) 이름을 한글로 지어 뒀는데, 이 이름이 파일 이름을 만드는 코드에 그대로 쓰였습니다. 그러면서 글자 인코딩 문제로 파일 이름이 깨지는 버그가 생겼습니다.
원인을 찾는 데 꽤 오래 걸렸는데, 결국 노드 이름을 모두 영어로 바꾸고 나서야 이 문제가 완전히 사라졌습니다.
평소 회사에서 시스템을 만들 때는 당연하게 지키던 원칙인데, 자동화 도구를 급하게 조립하다 보니 이런 기본적인 부분을 놓쳤던 셈입니다.
작은 습관 하나가 나중에 얼마나 긴 디버깅 시간으로 돌아오는지 다시 한번 몸으로 느낀 경험이었습니다.
넷째, 에피소드 기록(로그)이 자꾸 꼬이는 문제
여러 단계를 거치면서 진행 상태를 적는 기록이, 동시에 여러 번 덮어써지면서 정보가 사라지는 문제가 있었습니다.
이 문제는 기존 기록을 먼저 읽고, 새 정보를 합친 다음, 다시 저장하는 "읽기 → 합치기 → 쓰기(read → merge → write)" 순서로 바꾸면서 안정됐습니다.
평소 회사에서 데이터 파이프라인을 다룰 때 자주 쓰던 방식인데, 영상 자동화 파이프라인에도 그대로 들어맞을 줄은 몰랐습니다.
결국 분야가 달라도, 여러 단계를 거치면서 상태를 안전하게 쌓아 가야 하는 문제의 본질은 크게 다르지 않다는 걸 새삼 느꼈습니다.
다섯째, 초반에 붙잡는 장치가 없던 문제는 인트로 클립으로 대응
컨설팅에서 지적받은 초반 이탈 문제를 해결하려고, 영상 시작 부분에 눈길을 끄는 짧은 인트로 클립(썸네일 같은 장면)을 자동으로 넣는 단계를 파이프라인에 추가했습니다.
이야기 흐름 전체를 처음부터 다시 짜는 대신, 시작 부분에 짧고 강한 장면 하나를 끼워 넣는 비교적 가벼운 수정으로 접근했다는 점이 특징입니다.
이 다섯 가지 문제를 하나씩 해결하고 나서야, 비로소 "입력만 하면 알아서 완성된 영상이 나오는" 구조에 가까워졌다는 느낌을 받았습니다.
④ 지금까지 해 보고 느낀 점, 그리고 다음 단계
돌아보면 영상 기획보다, 파이프라인이 멈추지 않고 잘 돌아가게 만드는 데 훨씬 많은 시간을 썼습니다.
여러 종류의 영상을 조금씩 만들어 시험하고 반응을 분석하는 작업은 아직 진행 중이고, 앞으로도 이 파이프라인은 계속 조금씩 손보게 될 것 같습니다.
다음 단계로는 어떤 종류의 인트로가 실제로 초반 이탈을 줄이는지, 여러 버전을 만들어 비교해 보는 작업을 계획하고 있습니다.
영상 하나하나를 얼마나 완벽하게 만드느냐보다, 빨리 만들고 빨리 반응을 확인하는 흐름 자체를 얼마나 잘 돌리느냐가 결국 이 채널의 성패를 가를 것 같다는 생각이 듭니다.