AI 영상 자동화를 해보고 싶었습니다. 대본만 받아보는 데서 끝내지 않고, 목소리와 화면, 자막까지 붙은 영상 파일을 만드는 일이요.
이번에는 여러 도구를 연결해 83초짜리 세로 영상을 완성했습니다. 아직 유튜브에 올리지는 않았습니다. 채널 이름도 조금 더 준비한 뒤 공개하려고 합니다.
해보니 중요한 것은 모든 일을 잘하는 AI 하나를 찾는 게 아니었어요. 글을 쓰는 도구, 목소리를 만드는 도구, 화면을 만드는 도구가 각자의 일을 하도록 순서를 정하는 것이었습니다.
그중 가장 오래 붙잡은 것은 의외로 목소리였습니다.
영상 하나를 만드는 일을 나눠봤습니다
소재는 익숙한 과학 이야기로 잡았습니다. 알고 있다고 생각한 내용을 짧은 영상으로 설명할 수 있는지 확인해보고 싶었어요.
먼저 다른 영상의 도입 질문, 설명 순서, 끝맺음을 분석했습니다. 그 흐름을 참고하되 제 대본과 화면은 따로 만들었습니다.
이번 자동화는 Claude(클로드)에 Higgsfield(힉스필드)를 MCP로 연결해 구축했습니다. MCP는 AI가 외부 도구를 호출할 수 있게 연결하는 방식입니다. Claude에서 Higgsfield의 이미지·영상 생성 도구를 호출하도록 연결한 것이죠.
제작 도구의 역할도 나눴습니다.
- Claude: 기획과 대본, 화면을 만들 때 쓸 요청문을 정리합니다.
- Higgsfield: 설명에 필요한 이미지와 짧은 영상을 만듭니다.
- TTS: 글을 읽어주는 AI 목소리를 만듭니다.
- FFmpeg: 음성과 화면, 자막을 하나의 영상 파일로 합칩니다.
- 자동 검사: 합친 영상에서 긴 무음이나 검은 화면 같은 문제를 찾습니다.
TTS는 글을 음성으로 바꾸는 기능입니다. FFmpeg는 영상과 소리를 다루는 도구이고요. 처음에는 이름을 외우기보다 역할만 이해해도 됩니다.
도시락을 만든다고 생각하면 조금 쉬워요. 반찬을 만드는 일과 도시락 통에 담는 일은 다르죠. 이번에도 재료를 만드는 도구와 완성 파일로 묶는 도구를 나눴습니다.
순서는 대본 확인 → 음성 확인 → 자막 확인 → 이미지·영상 확인 → 조립 → 검사 → 썸네일 확인으로 정했습니다. 썸네일은 목록에서 먼저 보이는 작은 대표이미지입니다.
각 단계는 제가 확인해야 다음으로 넘어갑니다. 대본이 바뀌면 음성도 다시 만들 수 있고, 음성이 바뀌면 화면 길이도 달라지기 때문입니다.
목표는 반복해서 합치고 검사하는 일을 줄이는 것입니다. 무엇을 말할지, 어떤 목소리가 맞는지까지 사람 없이 결정하게 하지는 않았습니다.
목소리는 숫자로 골랐다가, 귀로 다시 골랐습니다
처음에는 Azure의 한국어 목소리 다섯 종류를 두 가지 속도로 비교했습니다. Azure는 Microsoft의 서비스이고, 여기서는 AI 음성을 만드는 기능을 썼습니다.
이름보다 소리에 집중하는 방식으로 비교한 뒤 후보 하나를 골랐습니다. 속도를 25% 높인 설정은 제 테스트에서 분당 517자 정도를 읽었습니다.
그때는 목소리가 정해졌다고 생각했어요. 그런데 Typecast를 들어보니, 제 귀에는 발음이 더 또렷했습니다. 그래서 서비스를 바꿔보기로 했습니다.
이번에는 다른 문제가 나왔습니다. 무료 등급에서 음성 생성 요청을 연달아 보내다가 두 차례 차단됐습니다. 화면에는 비정상 활동을 감지했다는 오류가 나타났어요.
월 $15인 API Lite 요금제를 결제했지만, 연속 호출 문제는 남았습니다. 제 실행에서는 세네 번 요청한 뒤 일시적으로 막히는 패턴도 관찰했습니다. 모든 계정에 적용되는 공식 기준이라는 뜻은 아닙니다.
그래서 문장마다 음성을 따로 만들던 방식 대신, 대본 전체를 한 번의 요청으로 합성하도록 바꿨습니다. API는 프로그램이 다른 서비스에 작업을 요청하는 연결 방식입니다.
음성에는 어느 말이 언제 나오는지 알려주는 시간 정보를 함께 받아 자막을 맞췄습니다. 통째로 녹음한 뒤 말이 나오는 시간을 기준으로 자막을 붙이는 셈이죠.
이렇게 요청 횟수를 줄였지만, 차단 문제가 완전히 해결됐다고 보지는 않습니다. 서비스가 막혔는데 계속 다시 요청하는 방식으로 운영할 수도 없고요.
목소리 선택도 한 번 더 바뀌었습니다. 한 후보의 tempo를 0.75로 두니 분당 440자 정도가 됐지만, “목소리가 쳐진다”는 피드백을 받았습니다.
tempo는 이 서비스에서 말하는 속도를 조절하는 설정입니다. 그런데 제 비교에서는 숫자를 올렸을 때 속도뿐 아니라 말의 힘도 다르게 느껴졌어요. 최종적으로는 웹 화면에서 직접 들어보고 마음에 드는 목소리를 골랐습니다.
목소리는 정해진 시간 안에 몇 글자를 읽는지만으로 고를 수 없었습니다. 끝까지 듣고 싶게 들리는지도 함께 봐야 했어요.
이 캡처는 목소리를 고르던 중간 비교 기록입니다. 빠른 쪽이 무엇인지 숫자로 확인한 뒤, 두 음성을 다시 들어보자는 대화였어요. 최종 목소리나 이번 완성본의 속도를 확정한 화면은 아닙니다.
AI 영상 자동화에서 화면보다 음성을 먼저 정한 이유
음성이 바뀔 때마다 화면 길이도 다시 맞춰야 했습니다. 멋진 장면을 먼저 만들어놓아도, 설명이 더 길어지면 화면이 부족해집니다. 반대로 설명이 짧아지면 남는 영상이 생기고요.
그래서 음성을 먼저 확정하고, 필요한 길이만큼 화면을 만드는 방식으로 바꿨습니다. 이걸 audio-first, 쉽게 말해 ‘음성 먼저’라고 부릅니다.
당시에는 이렇게 제작 순서를 정리했습니다. 캡처 속 비용 절감 설명은 계획 단계의 예상입니다. 실제로 얼마를 아꼈는지는 생성 내역을 대조해야 합니다.
이번 작업에서는 불필요한 영상 생성을 줄이는 데 도움이 됐습니다. 다만 누구나 같은 비율로 비용을 아낄 수 있다는 뜻은 아닙니다. 목소리와 대본을 얼마나 자주 바꾸는지에 따라 달라질 겁니다.
제가 음성에 요구한 조건은 분명했습니다.
음성에 공백이 있거나 딜레이 있으면 지루해지니까 반드시 음성은 이어져야 해. 쉼이 느껴지면 절대 안 돼Azure를 쓰던 단계에서는 쉼을 조절하는 설정이 기대대로 반영되지 않았습니다. 그래서 만들어진 음성에서 0.25초를 넘는 공백을 찾아 0.15초로 줄이는 후처리를 적용했습니다.
이건 이번 영상의 빠른 설명 흐름에 맞춘 선택입니다. 모든 영상에서 쉼을 없애야 한다는 규칙은 아니에요. 차분히 설명할 영상이라면 듣는 사람이 생각할 틈도 필요하겠죠.
자막도 음성과 똑같은 글을 길게 보여주는 대신, 휴대전화에서 바로 읽을 수 있게 줄였습니다. 한 번에 한 줄, 짧은 단어 묶음이 음성을 따라 바뀌도록 했습니다.
한 자막에는 1~3어절, 16자 이내를 기준으로 잡았습니다. 어절은 ‘영상이’, ‘완성됐습니다’처럼 띄어쓰기로 나뉘는 말의 묶음입니다. 단어가 중간에서 잘리지 않도록 했고, 화면 자막의 문장부호는 뺐습니다. 음성을 만드는 대본의 문장부호는 그대로 두었습니다.
같은 글이어도 읽어주는 용도와 화면에서 빠르게 읽는 용도는 다르다는 걸 여기서 배웠습니다.
화면을 만드는 단계에서는 여러 장면을 묶어 생성하도록 요청했습니다. 위 캡처는 생성 도구가 실행 중인 모습입니다. 최종 파일이 정상인지까지 확인한 화면은 아니에요. 그 확인은 조립 뒤에 따로 했습니다.
완성한 파일에서 무엇을 확인했을까
이번 결과물은 달을 주제로 한 83초짜리 영상입니다. 대본은 612자였고, 휴대전화에 맞춘 세로 화면으로 만들었습니다.
제작 후 별도로 검사한 기록은 다음과 같습니다.
- 화면 크기: 1080×1920, 초당 30프레임
- 파일 형식: H.264 영상과 AAC 음성이 들어간 파일
- 0.3초를 넘는 무음: 0건
- 검은 화면: 0건
- 첫 음성: 시작과 동시에 재생
- 마지막 음성 뒤 여백: 0.25초
- 측정 음량: -14.6 LUFS
프레임은 영상을 이루는 낱장 화면입니다. LUFS는 소리가 전반적으로 얼마나 크게 들리는지 살펴보는 측정값이고요. 이번 수치는 파일 검사 기록이지, 시청자가 지루해하지 않는다는 증거는 아닙니다.
자막은 뽑아낸 화면 일부를 직접 봤습니다. 한글이 깨지지 않는지, 한 줄로 나오는지, 단어가 중간에서 잘리지 않는지를 확인했어요. 모든 프레임을 사람 눈으로 검사한 것은 아닙니다.
과학 설명도 대본 단계에서 계산을 다시 확인했습니다. 화면과 소리가 잘 붙었다고 내용까지 맞는 것은 아니기 때문입니다.
마지막에는 다음 주제로 이어지는 예고를 붙였습니다. 영상 한 편을 만드는 것에서, 다음 편까지 연결해보는 단계로 넘어가고 있습니다.
비용보다 먼저 알게 된 운영의 한계
제가 선택한 Typecast API Lite는 월 $15, 매월 20만 크레딧인 요금제입니다. 크레딧은 사용할 수 있는 양을 세는 단위로, 공식 안내에서는 글자당 1크레딧으로 계산합니다. 웹 편집 서비스의 요금제와는 별개입니다. Typecast API 요금 안내
계획한 분량은 긴 영상 두 편과 짧은 영상 여덟 편입니다. 긴 영상 대본을 3,080자, 짧은 영상 대본을 660자로 잡으면, 한 번씩 음성을 만들 때 합계는 11,440자입니다. 월 제공량의 약 6%입니다.
여유는 있지만 재생성까지 무료라는 뜻은 아닙니다. 목소리를 바꾸거나 대본을 고칠 때마다 사용량이 늘 수 있고, 한도를 넘으면 추가 요금이 자동 결제됩니다. 월 구독료를 ‘영상 한 편의 추가 비용’과 혼동하지 않으려 합니다.
영상 생성 쪽은 별도 파일럿 한 편에서 Higgsfield 크레딧 196.5를 사용한 기록이 있습니다. 이 숫자를 이번 83초 영상의 비용으로 합치지는 않았습니다. 어떤 생성 방식에 얼마가 들어갔는지 세부 구분도 아직 남아 있습니다.
보안 실수도 있었습니다. 작업 중 서비스 인증키가 채팅에 노출돼 즉시 교체했습니다. 기존 키가 더 이상 작동하지 않는지도 확인했습니다. 인증키는 프로그램이 서비스를 쓰게 해주는 비밀번호 같은 것이므로, 요청문이나 공개 캡처에 넣어서는 안 됩니다.
자동화는 만드는 속도만 높이는 일이 아니었습니다. 서비스가 요청을 거절했을 때, 비용이 늘었을 때, 비밀정보가 노출됐을 때 어디서 멈출지도 정해야 했습니다.
파일 완성과 채널 운영은 아직 다른 단계입니다
“그럼 이제 알아서 영상이 올라가고 돈도 버는 건가요?”라고 물을 수 있습니다. 아직은 아닙니다.
현재는 영상 파일을 완성한 단계입니다. 업로드는 제가 직접 할 예정이고, 아직 수익도 없습니다. 시청 반응이나 수익화 가능성을 검증한 사례는 아니에요.
짧은 영상 세 편을 공개한 뒤 4주 동안 반응을 관찰하는 단계도 남았습니다. 제작 형식이 완전히 정해진 것은 아닙니다. 긴 영상도 계획하고 있지만, 실제 운영 결과는 그다음에 확인해야 합니다.
그래도 시작할 때와는 생각이 달라졌습니다. 영상 제작을 한 도구에 전부 맡기지 않아도, 여러 도구를 연결하면 대본에서 완성 파일까지 가는 흐름을 구현할 수 있었습니다.
처음 해본다면 채널 전체를 자동화하려 하지 않아도 됩니다. 먼저 짧은 대본의 목소리를 골라보세요. 그 음성 길이에 맞춰 화면을 준비하고, 자막을 붙인 뒤 소리와 화면을 함께 확인하는 작은 흐름부터 만드는 겁니다.
제가 다음에도 지키려는 순서는 이것입니다. 먼저 들을 만한 음성을 만들고, 그 길이에 맞는 화면을 붙입니다. 자동 검사를 거쳐도, 마지막에는 제가 직접 들어보고 봅니다.