hades83bks

도구가 첫 출력을 냈다 — 첫 영상이 나갔다

https://youtu.be/42Dfq00VF7s?si=LUj_kbaTagb6oDO1

두 달 만에 완성한 영상 자동화 파이프라인

오늘 드디어
내가 두 달간 밤낮없이 빌드해 온 영상 자동화 파이프라인의 첫 결과물이 드디어 유튜브 세상에 올라갔다.
(첫 결과물은 아니지 사실대로 말하면 이전에 커썰이 있었으니…)

영상 자동화 파이프라인. 이게 두 달 동안 나를 붙잡고 있던 전부였다.

첫 영상의 주제는 최근 국내 증시를 뒤흔든 ‘SK하이닉스 -9.92% 급락 시황과 젠슨 황 방한’ 이슈다.
길이는 약 7분 7초이며, 가로 영상으로 제작되었다.
(이건 내가 알아낸 사실이지만 쇼츠 처럼 세로 영상으로 3분이상 넘어가게되면 롱폼으로 간주된다.)

두 달간 쌓아온 도구들

여기까지 오는 데 정말 많은 도구와 인프라를 쌓아왔다.
8편에서 비용이 51%를 찍는 것을 보고 모델 분산 배치를 결정했고,
9편에서는 이미지 자동화 파이프라인을 구축했다.
10편에서는 영상에 들어갈 캐릭터 에디터를 직접 만들었으며,
다가올 11편과 12편에서는 분산 한 달 후 데이터 검증과 슬라이드 시스템 6종 확장을 준비 중이다.
돌이켜보면 이 모든 도구와 시행착오들이 오늘!
이 영상 한 편을 완벽하게 뽑아내기 위한 필수 부품들이었다.
두 달 가까이 이렇다 할 결과물 없이 밑바닥 도구만 주구장창 쌓아오던 지루한 단계가 드디어 끝난 것이다.

15분 만에 도는 빌드 흐름

이번 첫 영상을 만들어낼 때의 실제 빌드 흐름은 다음과 같았다.
원고를 작성하면 publish-from-script.js 엔진이 텍스트를 분석해 슬라이드 스펙을 자동으로 생성한다.
이어서 Typecast API를 통해 보이스(TTS) 데이터를 다운로드하는데,

이때 스피커별로 미리 지정된 색상과 폰트 매핑 플러그인이 자동으로 작동한다.
그다음 디자인 템플릿 중 주제에 맞는 것을 선택하면 PNG 레이아웃과 mp4 비디오 소스가 자동으로 출력된다.
여기에 캐릭터 스튜디오에서 미리 추출해 둔 마스코트 인드로 진행자 컷을 올리고,
마지막으로 FFmpeg 스크립트를 실행하면 슬라이드, 마스코트, 자막, BGM이 단 한 번에 연결된다.
이렇게 완성된 최종본을 유튜브에 업로드하는 구조다.
(유튜브 업로드도 자동으로 하려했는데 이건 정말로 너무나 귀찮아서 일단 빼두었다)

이 모든 파이프라인이 한 바퀴 돌아 최종 영상이 출력되기까지 걸린 전체 작업 시간은 놀랍게도
단 15분이었다.
원래 수작업으로 진행했다면 파워포인트로 슬라이드를 일일이 디자인하고,
보이스를 따로 녹음해서 타임라인에 맞추고,
프리미어나 캡컷 같은 편집 툴에서 자막을 한 땀 한 땀 박아야 했을 것이다.
최소 하루 꼬박 걸리던 중노동이 단 몇 번의 명령어로 단축된 셈이다.

출력은 15분, 수정은 2시간

물론 15분만에 생성되는건 맞긴하지만.
출력된 결과물을 수정하는데 2시간이 걸렷다.

• tts랑 자막이 싱크가 맞지않는 문제
• 이미지가 의미없는 과자사진이 들어가는 문제
• 어제 있었던 일을 오늘 해야한다고 거짓말하는 클로드
• 반복된 작업을 싫어하니 하기싫다고 말하는 클로드..
  (이건 최근에 알게된 사실이지만 AI들도 자기들이 일하기싫으면 할루시네이션이 심해진다.)

제일 큰 문제는 수정한 뒤 재생성을 해야하는데 또 똑같이 15분이 걸린다.
왜냐?
실수한 잘못된 곳을 수정하려면 0~41에 가운데 하나만 끼워넣으려면
결국 내 손이 들어가야하는데
손이 들어간다 = (캡컷으로 중간에 한두컷을 수동으로 넣고 발행하고 확인하는것이다)
내 손을 쓰기 싫으면 클로드에게 그냥 맡기는 수밖에없다.
맡긴다 = “야 이거 해”

처음 돌려본 명암

물론 첫 실행이었던 만큼 명암이 확실했다.
가장 잘 됐던 부분은 슬라이드 자동 생성과 자막 매핑이었다.
복잡한 반도체 용어나 주가 수치들이 오타 없이 한 번에 완벽한 비주얼로 표현되었고,
오디오 타이밍과 자막 씽크 부분은 인간이 손으로 다시 만질 필요가 전혀 없을 만큼 정교하게 맞아떨어졌다.

반면 아쉬운 점도 명확했다.
영상 중간에 나온 용어 설명 슬라이드는 배경 톤이 너무 어두워 전체적인 시각적 톤앤매너와 맞지 않아 수동으로 코드를 조금 손봐야 했다.(내가 아닌 클로드가)
또한, 특정 하이라이트 컷에서 마스코트 캐릭터의 위치가 자막 일부분을 살짝 가리는 레이어 오류가 발생했고,
‘HBM4′, ’10b5원’ 같은 전문 기술 및 법적 용어의 TTS 발음이 약간 어색하게 처리된 단어들이 있어 오디오 필터를 재구성하는 문제를 남겼다.

그럼에도 이번 첫 출력이 준 감회는 남다르다.
지난 두 달 동안 구체적인 영상 결과물 없이 백엔드 도구와 파이프라인만 붙잡고 있을 때는 솔직히 외롭고 불안했다.
‘이 코드가 진짜 움직여서 번듯한 영상이 되긴 할까?’라는 의심이 머릿속을 계속 맴돌았다.
하지만 오늘 내가 짠 시스템이 뱉어낸 첫 영상이 유튜브 채널 페이지에 그대로 박히고 재생되는 순간, 그 모든 의심과 피로가 눈 녹듯 사라졌다.

코드를 한 줄도 제대로 쓰지 못하는 내가 오직 AI에게 구조를 지시하고 협업하여 영상 자동 생성 시스템을 구축해 냈다.
그리고 그 시스템이 마침내 실제 대중 앞에 나갈 완성도 높은 콘텐츠를 안정적으로 출력해 냈다.
이게 2026년을 살아가는 솔로 제작자에게 정말로 가능한 일이라는 것을,
내 눈으로 직접 확인하고 나서야 온전히 실감이 났다.

다음 한 달의 목표는 명확하다.
구축된 파이프라인을 풀가동해 주 3편 이상,
총 12편의 영상을 안정적으로 양산하는 궤도에 진입할 것이다.
그리고 이번 첫 영상의 조회수, 평균 체류 시간, 이탈률 등 유튜브 스튜디오의 실제 시청자 데이터를 기반으로
파이프라인의 레이아웃과 연출 방식을 정밀하게 튜닝해 나갈 예정이다.
도구는 준비 완료되었으니,
이제는 진짜 스케일업의 시간이다.
(그냥 혼자만의 생각인데 이게 가능할까 계속 의심이 된다.)

영상 자동화 파이프라인. 두 달 만에 첫 영상이 나갔다. 이제 진짜 시작이다.

 

AI 서브에이전트 관점에서 핵심 변수를 짚어봅니다. 어느 날 여느 때처럼 유튜브 영상을 기획하고 제작하던 중이었습니다. 문득 마음 한구석에서 깊은 답답함이 밀려왔습니다. 주식 차트를 보여주며 시장 흐름을 명쾌하게 설명하고 싶었는데, 제가 직접 개발한 슬라이드 영상 시스템에는 그래프를 그릴 수 있는 슬라이드가 아예 없었던 것입니다.

 

 

결국 제가 선택할 수 있었던 유일한 방법은 텍스트로 된 글머리 기호(bullet point)를 사용해 숫자를 구질구질하게 나열하는 것뿐이었습니다. 명색이 자동화된 슬라이드 영상 제작 시스템인데, 핵심적인 시각화 도구가 빠져 있으니 매번 텍스트만 가득한 지루한 영상이 나올 수밖에 없었죠. 그날 밤, 모니터를 끄며 굳게 결심했습니다. “답답해서 안 되겠다. 당장 템플릿을 추가로 개발하자.”

한마디로 이번 작업의 주역은 AI 서브에이전트. 직접 코딩하는 대신 AI 서브에이전트 3개에게 일을 나눠주고, 저는 설계와 검수만 맡은 셈입니다.

 

 

지난 10편 글에서 “드디어 나만의 영상 자동화 도구를 만들었다”고 기쁘게 자랑했던 기억이 납니다. 그런데 신기하게도 그 글을 올린 지 채 한 달도 지나지 않아서, 저는 이 도구에 새로운 살을 붙이기 시작했습니다. 역시 도구란 한 번 만들고 끝나는 정적인 존재가 아니라, 창작자의 필요에 따라 끊임없이 성장해 나가는 생명체 같은 것인가 봅니다.

 

급하게 보완하기로 한 슬라이드 템플릿 6종

이번에 보완이 시급하다고 느낀 필수 템플릿 레이아웃은 총 6가지였습니다.

첫째, 막대그래프나 선그래프를 깔끔하게 그려주는 ‘chart’ 레이아웃. 둘째, 좌우 카드를 배치해 대조군을 명확히 보여주는 ‘compare’ 레이아웃. 셋째, 아주 굵고 선명한 서체로 한 줄을 강렬하게 때려 박는 ‘headline’ 레이아웃. 넷째, 뉴스 채널처럼 화면 하단이나 측면에 종목별 실시간 가격 흐름을 보여주는 ‘ticker’ 레이아웃. 다섯째, 역사적 사건이나 프로세스를 시간 순서대로 가로막대 위에 펼쳐놓는 ‘timeline’ 레이아웃. 마지막 여섯째, 여러 개의 통계 수치를 4분할이나 6분할 격자 형태로 깔끔하게 채워 넣는 ‘stat-grid’ 레이아웃까지. 이 모든 걸 완벽히 갖추고 싶었습니다.

 

AI 서브에이전트 병렬 시스템을 가동하다

하지만 큰 문제가 있었습니다. 이 6개의 복잡한 웹 기반 CSS/JS 슬라이드 템플릿을 하나씩 정성스레 수작업으로 만들려면 아무리 빨라도 최소 일주일은 족히 걸릴 게 뻔했습니다. 개발에 진을 다 빼고 정작 본업인 영상 기획은 뒷전이 될 것 같아 몹시 싫었습니다. 그래서 꾀를 냈습니다. 예전에 구축해 둔 ‘AI 서브에이전트 병렬 시스템’을 가동하기로 한 것입니다.

 

 

터미널을 열고, Anthropic의 Sonnet 모델 기반으로 작동하는 서브에이전트 3개를 동시에 띄웠습니다. 각 에이전트에게 쪼개진 미션을 나누어 던졌습니다.

 

 

지난 8편에서 다루었던 ‘분산 결정 아키텍처’가 실제로 어떻게 힘을 발휘하는지 증명할 수 있는 완벽한 기회였습니다. 복잡하고 무거운 전체 과업을 아주 단순하고 독립적인 단위로 잘게 쪼갠 뒤, 손넷 서브에이전트 셋에게 골고루 배분했습니다.

설계는 사람이, 구현은 에이전트가

각 에이전트는 자신에게 할당된 슬라이드의 HTML/CSS 코드, 화면을 채울 더미 데이터 세트, 그리고 깨지지 않고 완벽하게 렌더링 되는지 검증하는 자동화 테스트 스크립트까지 세트로 완성해 저에게 전달하도록 설계했습니다. 저는 그저 팔짱을 끼고 전체 설계를 감시하며, 올라오는 결과물들을 꼼꼼하게 검수하고 최종 검증을 거쳐 통합하기만 하면 되었습니다.

 

 

그렇게 진행된 프로젝트의 역할 분담은 대략 다음과 같았습니다. 서브에이전트 A는 정교한 ‘chart’ 템플릿과 시간 순대로 배치되는 ‘timeline’을 맡았고, 서브에이전트 B는 카드를 양쪽으로 대조하는 ‘compare’와 다중 격자 수치 데이터 구조인 ‘stat-grid’를 할당받았습니다. 마지막 서브에이전트 C는 심플하지만 강력한 가독성을 뿜어야 하는 ‘headline’과 무한 롤링 영역이 포함된 ‘ticker’ 구현을 완벽히 소화해 냈습니다. 이들은 각자의 영역에서 충돌 없이 훌륭한 코드를 생산해 냈습니다.

 

순수 작업 시간 14시간, 66% 단축

결과는 정말 놀라웠습니다. 6가지 템플릿을 설계부터 자동 테스트 빌드까지 완전히 완성하는 데 걸린 실제 순수 시간은 단 14시간이었습니다. 만약 제가 서브에이전트 없이 순차적으로 하나하나 맨땅에 코딩했다면 최소 42시간 이상은 꼬박 걸렸을 작업이었습니다. 결과적으로 전체 개발 시간을 무려 66%나 단축하는 데 성공한 셈입니다.

 

stat-grid는 세 번을 다시 고쳤다

물론 모든 과정이 다 순탄하지만은 않았습니다. 예를 들어 ‘stat-grid’ 슬라이드는 예상보다 개발 난이도가 꽤 높았습니다. 화면 해상도나 텍스트 길이에 따라 격자가 깨지지 않고 유연하게 배치되도록 CSS flex와 grid 비율을 잡는 부분에서 미세한 에러가 계속해서 발생했기 때문입니다. 결국 담당 에이전트에게 세 차례나 다시 고쳐 오라고 피드백을 전달하며 루프를 돌아야 했습니다. 반면, 한 줄 문구를 크게 박는 ‘headline’ 슬라이드는 정말 손쉽게 단 한 번 만에 완벽한 레이아웃이 나왔습니다. 구조 자체가 단순했기에 폰트 굵기와 정렬만 맞추면 끝나는 작업이었기 때문입니다.

 

 

가장 큰 난관은 서브에이전트들끼리 서로 소통하지 않고 제각각 작업하다 보니 발생한 ‘디자인 톤의 미묘한 어긋남’이었습니다. 미세하게 둥글기 값이 다른 border-radius나 서로 미묘하게 다른 회색조 컬러, 폰트 자간 등이 통합 단계에서 눈에 밟혔습니다. 결국 최종 검수 및 통합 단계에서 제가 직접 CSS 스타일시트를 열고 전체적인 디자인 규격을 일괄 조율하는 다듬기 작업을 거쳐야 했습니다. 이 통합 작업이 예상외로 전체 제작 시간의 30% 정도를 잡아먹었지만, 그럼에도 생산성이 어마어마하게 폭발했다는 사실은 변하지 않습니다.

 

 

이번 개발을 통해 드디어 총 10종의 고품질 슬라이드 템플릿 시스템이 완성되었습니다. 이제 웬만한 복잡한 주제의 주식 분석, 시사 정보, 트렌드 영상도 마우스 몇 번 클릭하며 슬라이드를 조합하는 것만으로 뚝딱 만들어낼 수 있는 강력한 무기를 쥐게 되었습니다.

AI 서브에이전트가 알려준 진짜 역량

두 번째로 진행된 이번 서브에이전트 병렬 실전 프로젝트를 치르며, 저는 아주 소중한 진리를 하나 깨달았습니다. AI가 대신 코딩을 해주는 시대에 인간 창작자에게 필요한 진짜 역량은 구체적인 문법을 외우는 코딩 기술이 아니라는 점입니다. 바로 전체 시스템을 쪼개어 바라볼 수 있는 ‘구조적 설계 능력’과 결과물의 퀄리티를 판단할 줄 아는 ‘안목과 검수 능력’이 진짜 무기입니다. 코드를 직접 한 줄도 짜지 못하더라도 설계의 방향성만 제대로 잡을 수 있다면, 누구나 자신만의 도구를 무한히 자라나게 만들 수 있는 메타 아키텍처의 시대가 열린 것입니다.

 

 

다음 목표는 명확합니다. 이렇게 구축된 10종의 템플릿 풀세트를 활용해 다음 한 주 동안 쉬지 않고 고화질 쇼츠와 풀영상들을 가득 뽑아내어 실전에 돌려볼 예정입니다. 실제로 제작 프로세스에서 유용하게 자주 쓰이는 슬라이드와, 멋있어 보여서 만들었지만 정작 손이 안 가고 썩어가는 슬라이드가 무엇인지 정량적 데이터로 선별해 낼 것입니다. 안 쓰는 도구는 과감하게 쳐내거나 통폐합하며, 도구의 군더더기를 걷어내는 다이어트 작업에 들어갈 계획입니다. 도구가 진정으로 자란다는 것은, 비대하게 커지기만 하는 게 아니라 사용자의 손때가 묻어 가장 가볍고 날카로운 상태로 정제되는 과정이니까요.

 

AI 모델 분산 배치 관점에서 핵심 변수를 짚어봅니다. 기대로 시작했던 ‘모델 분산 배치’ 실험이 한 달을 맞이했습니다.
과연 무지성으로 쓰던 고비용 모델을 줄이고 효율을 찾을 수 있었을까요?
5월 28일 처음 마주했던 사용량 페이지는 그야말로 충격이었습니다.

Opus 51%, Sonnet 0%, Haiku 0%.
일주일 만에 한도 절반을 단 하나의 모델이 먹고 있었죠.
전부 Opus가 디폴트로 설정되어 있던 탓이었습니다.

그날 결심했습니다.

복잡한 아키텍처 작업만 Opus에게 맡기고, 나머지는 전부 Sonnet과 Haiku로 내리기로 말이죠.

한 달 전 제가 시작한 게 바로 이 AI 모델 분산 배치.

 

AI 모델 분산 배치 한 달, 무엇이 달라졌나

오늘이 6월 3일입니다.

정확히 한 달이 지나서 다시 같은 사용량 페이지를 열어보았습니다.

결과는 놀라웠습니다.

 

(이젠 20달러짜리로도 유지가 될정도로 만들어 졌다는게 놀랍네요)

한 달간 적용한 규칙

실제 한 달간 적용했던 규칙은 아주 명확했습니다.

Opus: 새 시스템 아키텍처 설계, 복잡한 디버깅, 글 다듬기 (일주일에 5번 정도)

Sonnet: 코드 수정, 파일 정리, 일반 작업, 서브에이전트 (사실상 기본값)

Haiku: 단순 분류, 짧은 변환, 반복 작업

참고로 이 세 모델 Opus·Sonnet·Haiku는 모두 Anthropic Claude 라인업입니다.

 

 

처음에는 매번 작업을 시작할 때마다 망설였습니다.

‘이건 Opus를 써야 하나? Sonnet으로도 충분할까?’

하지만 1주일쯤 지나니 자연스럽게 감이 잡히더군요.

처음부터 새로 만드는 거대한 뼈대는 Opus,
이미 있는 코드를 수정하고 보완하는 건 Sonnet,
단순한 형식 변환은 Haiku.

이 룰을 머릿속에 박아두니 다음부터는 거의 자동으로 손이 움직였습니다.

 

의외의 수확들

이번 실험을 통해 얻은 의외의 수확들이 있었습니다.

첫째로, Sonnet으로 충분한 작업이 진짜 많았다는 점입니다.
Opus가 반드시 필요하다고 생각했던 작업의 절반 이상이 Sonnet으로도 똑같이 구현되었습니다.
차이가 있다면 처리 시간 30초 정도였을 뿐, 결과물의 퀄리티는 거의 같았습니다.
그동안 제가 얼마나 무지성으로 ‘제일 비싸고 좋은 것’만 켜두었는지 반성하게 되더군요.

 

 

둘째로, 서브에이전트 병렬 작업의 강력함입니다.

Sonnet 서브에이전트 3개를 동시에 띄워서 서로 다른 파일을 작업시키니,
혼자 일하는 하나의 Opus보다 속도가 훨씬 빨랐습니다.
특히 슬라이드 템플릿 6종을 만들 때 세 에이전트가 동시에 코드를 작성하는 모습을 보며 감탄했습니다.
비용은 훨씬 적게 드는데 속도는 몇 배나 빠른 신기한 경험이었죠.
반면 Haiku는 생각보다 쓸 일이 적었습니다.
단순 분류 작업 자체가 실제 업무에서는 그리 많지 않았고,
대부분 Sonnet의 범위 안에서 해결되었기 때문입니다.

 

순탄치만은 않았던 시행착오

물론 과정이 늘 순탄했던 것은 아닙니다.
분산 초기에는 Sonnet이 만든 결과물이 만족스럽지 않아
결국 Opus가 다시 손을 보는 이중 작업이 발생하곤 했습니다.
결과적으로 비용이 두 번 든 셈이었죠.
처음부터 적절한 모델을 지정하는 감각을 익히기까지는 꼬박 1~2주의 시행착오가 필요했습니다.

 

 

또 하나의 복병은 ‘익숙함’이었습니다.
툴의 디폴트 설정이 여전히 Opus로 되어 있다 보니,
명시적으로 모델을 지정하지 않으면 나도 모르게 다시 고비용 모델로 슬금슬금 손이 가곤 했습니다.
매 작업을 시작할 때마다 “지금 이 작업에는 어느 머리를 쓸 것인가?”라고

스스로에게 묻는 습관을 들이는 것이 가장 중요했습니다.

 

결론: 모델 선택이 곧 작업 설계다

결론적으로,
지난 글을 쓸 때만 해도 “이렇게 하면 비용이 줄겠지”라는 막연한 추측이었던 것이 한 달간의 데이터를 통해 확실한 사실로 증명되었습니다.
가장 중요한 건, 비용을 줄였음에도 결과물의 질은 전혀 떨어지지 않았다는 점입니다.
영상은 매일 차질 없이 제작되었고, 글도 매일 올라갔으며, 전체적인 작업 속도는 오히려 빨라졌습니다.

결국 한 달간 제가 데이터로 증명한 핵심은 AI 모델 분산 배치.

 

 

AI 도구를 쓸 때 디폴트로 가장 좋은 모델을 켜는 것은 인간의 직관적인 본능일지도 모릅니다.
하지만 그 직관이 비용의 99%를 만들어냅니다. 이제 모델 선택 자체가 작업 설계의 핵심적인 일부가 되어야 합니다.
어떤 작업에 어떤 머리를 쓸지 결정하는 것은 단순한 비용 절감의 문제가 아니라,
작업의 효율성과 스마트함을 결정짓는 핵심 열쇠입니다.

 

 

다음 한 달의 질문은 이것입니다. ‘이 효율적인 비율이 계속 유지될 것인가,
아니면 복잡한 작업들이 다시 쌓이면서 Opus의 비중이 올라갈 것인가.’ 한 달 뒤 실제 데이터를 들고 다시 기록을 남기겠습니다.

 

도구가 자라기 시작했다 — 슬라이드 시스템 확장기

 

슬라이드 템플릿 확장 관점에서 핵심 변수를 짚어봅니다. 지난 10편에서 “내 손으로 도구를 만들었다”고 기록했다. 그런데 한 달도 채 되지 않아 그 도구가 스스로 몸집을 불리며 자라기 시작했다. 이번 글은 그 경이로운 자람의 첫 단계에 대한 기록이다. 이번 글의 핵심은 한마디로 슬라이드 템플릿 확장이다.

슬라이드 템플릿 확장에 나선 이유

 

처음에는 title, bullet, stat, quote라는 가장 기본적인 4종의 슬라이드만으로 영상을 만들기 시작했다. 하지만 불과 며칠 만에 명확한 한계와 부족함이 눈에 들어왔다. 주식 데이터의 변화를 직관적인 그래프로 보여주고 싶었고, 두 가지 요소를 한눈에 비교하는 카드가 필요했다. 때로는 강렬한 헤드라인 한 줄을 화면 정중앙에 박아넣고 싶기도 했다. 겨우 4종의 템플릿만 돌려 쓰다 보니 완성된 영상들이 점차 단조롭고 지루해지기 시작한 것이다.

 

 

영상의 역동성을 살리기 위해 새로운 템플릿 6개를 더 추가하기로 마음먹었다. 새로 기획한 템플릿의 종류는 다음과 같다.

• chart: 막대 및 선 그래프를 보여주는 슬라이드
• compare: 좌우 구조로 대상을 비교하는 카드
• headline: 굵고 강렬한 한 줄 강조 화면
• ticker: 화면 하단에 종목별 가격 흐름을 보여주는 자막
• timeline: 시간 순서대로 사건을 펼쳐놓는 연연표
• stat-grid: 여러 개의 핵심 숫자를 격자 형태로 배치하는 화면

 

이걸 예전 방식대로 하나씩 혼자 만들면 족히 일주일은 걸릴 게 뻔했다. 나는 그 지루한 시간을 견디고 싶지 않았다. 그래서 이번에는 머리를 써서 서브에이전트 3개를 동시에 띄워 병렬로 작업을 밀어붙이기로 했다.

 

이 구조는 지난 8편에서 다루었던 ‘분산 처리’ 이야기와 맥을 같이 한다. 전체 해야 할 일을 아주 작은 단위로 쪼개어, Sonnet 서브에이전트들에게 각각 나누어 던져주는 방식이다. 한 명의 똑똑한 Opus에게 전권을 맡기는 것보다, 명확한 지시를 받은 세 명의 Sonnet을 동시에 굴리는 게 훨씬 빠르다는 것을 지난 한 달간 뼈저리게 체감했기 때문이다.

 

 

각 서브에이전트는 단순히 코드만 짜는 게 아니라, 템플릿 코드에 들어갈 더미 데이터와 화면이 깨지지 않는지 확인하는 자동 테스트 코드까지 한 번에 만들어서 결과물을 뱉어냈다. 에이전트들이 일하는 사이사이에 내가 한 일은 오직 하나, 결과물들을 하나로 합치고 눈으로 직접 확인하는 ‘통합 및 시각 검수’뿐이었다.

실제로 내가 코드를 직접 타이핑하는 시간은 거의 0에 수렴했다. 전체적인 판을 설계하고, 에이전트들의 결과물을 검수한 뒤, 수정 사항을 다시 피드백하여 보내는 것이 내 업무의 전부였다. 서브에이전트들이 각자 맡아서 진행한 템플릿 분담 현황은 아래 표와 같다.

 

• 에이전트 A — 담당 템플릿: chart, ticker / 산출물: 컴포넌트 코드, 주식 데이터 파서, 테스트 툴
• 에이전트 B — 담당 템플릿: compare, headline / 산출물: 레이아웃 CSS, 반응형 그리드, 예시 데이터
• 에이전트 C — 담당 템플릿: timeline, stat-grid / 산출물: 시간축 애니메이션, 격자 정렬 스크립트

6종 템플릿 빌드 결과 리포트

병렬 에이전트 시스템을 가동하여 얻은 실제 수치와 작업 데이터는 내 예상보다 훨씬 효율적이었다.

• 6종 제작에 걸린 실제 시간: 총 6시간
• 기존 방식(순차 제작) 예상 시간: 약 24시간
• 작업 시간 단축률: 75% 감소

 

실제 작업을 진행하면서 아주 흥미로운 점들을 발견할 수 있었다. 우선 headline과 compare 슬라이드는 에이전트 B가 구조를 워낙 깔끔하게 잡아서 단 한 번의 수정 요청 없이 한 방에 완벽한 템플릿이 뽑혀 나왔다. 텍스트 중심의 정적 레이아웃이라 에이전트가 직관적으로 해석하기 쉬웠던 덕분이다.

반면, 가장 애를 먹었던 것은 에이전트 A가 담당한 chart 슬라이드였다. 화면 크기가 변할 때마다 막대 그래프의 높낮이가 유동적으로 변해야 했는데, 처음에는 비율이 자꾸 깨져서 출력되었다. 결국 에이전트에게 캔버스 렌더링 범위를 제한하는 조건을 주어 3번의 재수정을 거친 후에야 안정적인 그래프를 얻을 수 있었다.

또한, 서로 다른 서브에이전트들이 각자 디자인을 하다 보니 처음 합쳤을 때는 폰트 크기나 여백 같은 디자인 일관성이 미묘하게 어긋났다. 다행히 공통 스타일시트(CSS)를 상위에 끼워 넣는 방식으로 내가 직접 다듬는 작업을 거치자 전체적인 톤앤매너가 빠르게 정렬되었다. 수작업 리소스를 감안하더라도 압도적인 속도였다.

 

이번 실험으로 얻은 인사이트

“코드를 쓰지 못해도, 설계하고 검수할 수 있다면 시스템은 자란다.”

1. 슬라이드 10종 풀 시스템 완성

이제 총 10종의 템플릿을 보유하게 되었다. 정보 전달, 수치 비교, 타임라인 나열 등 사실상 거의 모든 형태의 정보성 영상을 이 템플릿 조합만으로 찍어낼 수 있는 강력한 무기가 생겼다.

2. 병렬 작업 패턴의 내재화

10편의 캐릭터 스튜디오에 이어 두 번째로 서브에이전트 병렬 작업법을 실전에 적용했다. 이제 일을 어떻게 쪼개고 어떤 프롬프트로 분산시켜야 에이전트들이 헤매지 않는지 그 최적의 패턴이 내 몸에 완전히 익기 시작했다.

3. AI로 내 도구를 키우는 메타 구조

가장 짜릿한 지점은 바로 이것이다. 내가 만든 초기 시스템을, 내가 부리는 AI 에이전트들을 통해 스스로 확장시키는 구조를 완성했다는 것. 개발자가 아니더라도 구조적인 설계 능력과 명확한 기준만 있다면 거대한 시스템을 얼마든지 빌드업할 수 있다는 확신이 생겼다.

 

이번 작업의 정체는 한마디로 슬라이드 템플릿 확장이다. 다음 단계는 명확하다. 이렇게 완성된 10종의 풀 시스템을 활용해 실제로 일주일 분량의 영상을 연속으로 돌려볼 예정이다. 그 과정에서 생성되는 데이터를 기반으로, 정말 자주 쓰이는 알짜배기 슬라이드와 만들어놓고 정작 손이 안 가는 슬라이드를 냉정하게 가려낼 것이다. 쓰이지 않는 템플릿은 과감히 접거나 다른 기능으로 통합할 생각이다. 도구도 건강하게 자라기 위해서는 적절한 다이어트와 가지치기가 필수적이니까.

이번에 도입한 병렬 에이전트 시스템에 대해 더 궁금한 점이 있으시거나, 본인의 업무 플로우에 적용해보고 싶은 부분이 있으신가요?

AI 이미지 자동화 이야기다. 이미지 제작 자동화, 어디까지 오셨나요? (feat. 한계 극복기)
유튜브나 틱톡 같은 숏폼, 롱폼 영상을 매일 찍어내다시피 만드는 분들이라면 누구나 공감하실 겁니다.
영상의 퀄리티를 결정짓는 가장 핵심적인 요소가 바로 '비주얼',
즉 이미지와 영상 소스라는 것을요.

오늘은 제가 그동안 머리를 싸매고 진행해 온 이미지 생성부터 최종 영상 제작까지의 자동화 파이프라인과,
그 과정에서 겪은 생생한 시행착오를 공유해보려 합니다.
한마디로 이건 제 AI 이미지 자동화 도전기입니다.
전체적인 흐름은 이렇습니다.
'이미지 생성 및 분위기에 맞춘 프롬프트 적용 ➔ 동작 및 캐릭터 고정 ➔ 배경 합성 ➔ 최종 영상화' 단계입니다.

AI 이미지 자동화, 어디까지 왔나

첫 단계인 이미지 생성은 사실 AI를 조금이라도 다뤄보신 분들이라면 익숙하실 겁니다.
요즘은 제미나이나 그록 같은 AI 툴 성능이 워낙 좋아져서,
복잡한 영어 프롬프트가 없어도 그냥 한국어로 편하게 대화하듯 요구하면 알아서 척척 그려주니까요.

예를 들면 "이런 행동을 하는 귀여운 소를 한 마리 그려줘"라고 입력하는 식입니다.

그런데 이걸 매일, 그것도 수십 번씩 반복하다 보니 엄청난 번거로움이 발생했습니다.
채널의 정체성을 유지하려면 '고정된 마스코트 캐릭터'가 필요한데,
매번 새로 생성할 때마다 소의 모양이나 색상이 미묘하게 달라지는 문제가 있었습니다.
마스코트 이미지를 일관되게 유지하기 위해 이미지를 새로 뽑고,
마음에 안 들면 또 생성하고, 수정하는 단순 반복 작업이 계속되다 보니 피로감이 엄청났습니다.

고백하자면 올 초까지만 해도 '이미지 투 이미지(Image to Image)' 기능을 제대로 활용하지 못하는 상태였습니다.
이미 완성된 기존 이미지를 기반으로 새로운 동작을 재생성한다는 개념 자체를 생각하지 못했던 거죠.

하지만 지금은 기술이 정말 좋아졌습니다.
기존에 만들어 둔 마스코트 이미지를 베이스로 넣어두고,
"이 캐릭터가 오른쪽으로 걸어가는 동작을 만들어줘" 혹은
"이 이미지가 자연스럽게 움직이게 해줘"라고 말만 해도
기본적인 움직임이나 턴어라운드 동작을 구현해 주니까요.

마스코트 고정과 배경 합성

그래서 저는 현재 프레임 워크를 조금 바꾸어 사용하고 있습니다.
우선 채널을 대표할 중심 마스코트 캐릭터 이미지를 먼저 고정으로 생성합니다.
그 다음, 영상의 분위기에 맞는 별도의 배경 이미지를 따로 생성하죠.
최종적으로 이 두 가지 요소를 레이어 형태로 투명하게 합성하는 방식을 1차적으로 사용하고 있습니다.
이렇게 하면 캐릭터가 배경에 묻히지 않고 깔끔하게 분리되어 제어하기가 훨씬 수월해집니다.

한도 제한이라는 벽

그런데 여기서 또 다른 예상치 못한 장벽에 부딪혔습니다.
완성도를 높이려고 캐릭터와 배경을 반복해서 수정하고 재생성하다 보니,
API나 플랫폼 자체의 '하루 사용 한도 제한'이 툭하면 걸려버리는 것입니다.
한참 작업 속도가 붙어서 코드를 수정하고 테스트해야 하는 타이밍에 제한 메시지가 뜨면 정말 맥이 탁 풀립니다.
현재로서는 이 부분이 가장 큰 걸림돌입니다.

이 한도 제한 문제를 해결하기 위해 제가 찾은 방안은 무식하지만 가장 확실한 방법뿐이었습니다.
예외 처리를 꼼꼼하게 해두고, 최대한 여러 번 나눠서 실행해 보는 것이죠.
자동화 코드를 돌리다가 실패하면, 실패한 에러 로그 부분을 제외하고 다시 필터링해서 부분 테스트를 반복하는 수밖에 없습니다.
결국 이미지나 배경을 생성하는 것도 인간의 '상상력'과 '기획력'이 기준이 되어야 하는 영역이다 보니,
매번 완벽한 프롬프트를 짜내는 게 여간 힘든 일이 아닙니다.
그래서 저는 최근 이 프롬프트 엔지니어링의 상당 부분을 클로드에게 위임했습니다.
"이러한 상황과 맥락에 맞는 최적의 이미지 생성 프롬프트를 구조화해줘"라고 맡겨두고 해결하는 식으로 부담을 덜고 있습니다.

소스를 묶어 영상으로

최종 영상화 단계는 이렇게 준비된 소스들을 하나로 묶는 과정입니다.
앞서 만든 '배경 + 마스코트' 합성 이미지를 하나의 완전한 캔버스로 출력합니다.
그 이후 완성된 단일 이미지를 비디오 생성 기능을 지원하는 AI 툴에 투입합니다.
그록 같은 곳에 넣고 "이 이미지의 분위기를 살려서 카메라가 부드럽게 줌인되는 5초짜리 영상을 만들어줘"라고
요청하면 비디오 클립 생성 자체는 크게 어렵지 않게 뚝딱 완성됩니다.

문제는 이 작업을 영상 한 편당,
혹은 매일 올리는 숏폼 분량에 맞춰 수십 번씩 '반복해서' 자동화 프로세스로 매끄럽게 굴려야 한다는 점입니다.
스크립트 작성, 이미지 생성, 비디오 변환, FFmpeg을 통한 오디오 합성까지 이어지는
파이프라인을 매끄럽게 연결하는 것은 여전히 많은 튜닝이 필요하네요.

여기까지가 현재 제가 치열하게 부딪히며 구축하고 있는 AI 비주얼 생성 파이프라인의 현주소입니다.
아직 완벽하다고 볼 수는 없지만,
매달 기술이 발전하는 속도를 보면 조만간 한도 제한이나 퀄리티 편차 문제도 완전히 해결될 날이 오지 않을까 싶습니다.
혹시 여러분은 이런 이미지 일관성 문제나 영상 변환 작업을 어떤 방식으로 자동화하여 해결하고 계시나요?
저보다 먼저 앞서나가고 계신 고수분들이 있다면 댓글이나 메시지로 좋은 팁 좀 공유해 주십시오.
집단지성의 힘이 절실한 요즘입니다.
AI 이미지 자동화, 아직 갈 길이 멉니다.