AI 자동화

 

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 이미지 자동화, 아직 갈 길이 멉니다.

클로드 코드 사용량 이야기다.

개발을 하다 보면 예상치 못한 곳에서 리소스가 펑펑 터져 나가곤 합니다.

특히 AI API나 툴을 연동할 때는 더욱 그렇습니다.

오늘은 Claude Code를 활용해 심리테스트 자동화 시스템을 구축하다가,

단 한번의 사용으로 5시간 사용 한도의 51%를 날려 먹은 웃픈 이야기와 함께 이를 해결한 과정을 공유해 드립니다.

이 글은 클로드 코드 사용량 폭발 사건과 그 해결기를 담은 기록입니다.

 

 

 

현재 준비 중인 콘텐츠는 심리테스트, 홈페이지 주식 관련 글 정리, 그리고 일상적인 경험담들입니다. 오늘은 그중에서도 오늘 딱 겪었던 따끈따끈한 심리테스트 개발 연동 이야기를 해보려고 합니다.

심리테스트 자동화, 4단계 구조부터

 

클로드 코드로 심리테스트를 만드는 과정은 크게 4단계로 나뉩니다.

첫째는 전체적인 배경 설정,

둘째는 글자가 나오는 레이어 위치 맞춰주기,

셋째는 가장 중요한 글(콘텐츠) 생성 도구 만들기입니다. 매번 같은 내용이 나오면 안 되니까요.

마지막 넷째는 이 모든 요소를 자연스럽게 투입하고 완성하는 단계입니다.

 

 

이 과정을 시작 버튼 딱 하나로 한 방에 해결하려고 하니 모든 게 막혀버렸습니다. 배경이야 대충 만든다 쳐도, 레이어 위치나 글 생성은 눈으로 직접 보고 테스트하고 수정하는 반복 작업의 연속이었습니다. 이쯤 되니 내가 비개발자인지 개발자인지 헷갈리기 시작하더군요.

로컬호스트로 작업 환경을 옮겼습니다

 

사이트를 열어 확인하고, 실패한 부분을 다시 클로드 코드에게 던져주는 짓을 반복하다가 문득 좋은 아이디어가 떠올랐습니다. “클로드야, 이거 그냥 내 컴퓨터에서도 돌아가게 만들어서 여기서 완전히 고치고 실행하자!”라고 했더니 바로 알겠다고 하더군요. 그렇게 로컬호스트(Localhost) 환경을 구축했습니다.

 

로컬호스트(Localhost)란?
외부 인터넷 서버를 거치지 않고, 본인의 개인 컴퓨터(PC) 내부를 가상의 서버로 만들어 웹사이트나 프로그램을 구동하는 환경을 뜻합니다. 쉽게 말해 ‘내 컴퓨터 주소’를 의미하며, 개발 중인 화면을 실시간으로 띄워놓고 안전하게 수정 및 테스트를 반복할 수 있는 나만의 비밀 작업실 공간입니다.

 

로컬호스트를 띄워놓고 클로드 코드에게 “이건 틀렸어”, “이건 잘했어”, “이 부분은 빼줘”라고 요청하니 순식간에 딱딱 맞춰서 문제들이 풀려나갔습니다.

배경은 아주 천천히 움직이게 만들었습니다

 

그다음은 이미지와 음악 생성 과정이었습니다.

가장 처음에 만든 심리테스트는 이미지만 떵그러니 넣었더니 너무 밋밋하고 보기 싫었습니다. 그래서 두 번째로는 움직이는 영상을 배경으로 넣어봤는데, 이번에는 배경이 휙휙 지나가니까 글자가 눈에 전혀 안 들어왔습니다. 배경이 너무 신경 쓰였던 거죠.

결국 최종 조율한 방법은 아주 아주 천천히 움직이는 영상을 만드는 것이었습니다. 사용자가 보면서 ‘아, 뒷배경이 은은하게 움직이고 있구나’ 정도만 파악할 수 있는 수준으로요. 이 부분은 제미나이로 이미지를 먼저 생성한 뒤, 그록(Grok)을 통해 영상으로 변환하여 넣도록 조율했습니다.

이미지는 특별한 기교 없이 상황에 맞는 프롬프트를 넣었습니다. 배경 움직임을 최소화해야 했기에 프롬프트 구조는 생각보다 단순했습니다.

배경 영상 생성 프롬프트 예시
“심리테스트 질문에 어울리는 차분하고 몽환적인 그래픽 일러스트, 아주 미세하고 느린 구름의 움직임(Minimal animation, cinematic, super slow motion, 0.1x speed)”과 같이 시각적 자극을 줄이고 움직임을 극도로 제한하는 키워드를 조합하여 적용했습니다.

클로드 코드 사용량, 51%가 사라진 순간

그렇게 세팅을 끝내고 신나게 실행을 시켜봤는데, 모니터를 보고 눈을 의심했습니다. 100달러짜리 플랜인데 클로드 사용량이 벌써 51%를 먹고 있었던 것입니다.

클로드는 보통 5시간 주기로 사용량이 갱신됩니다. 만약 20달러짜리 일반 플랜으로 이 작업을 돌렸다면 중간에 사용 제한이 걸려 아예 실행조차 되지 않았거나 멈췄을 게 뻔합니다.

이렇게 어마어마한 리소스 소비가 일어난 까닭을 분석해 보니, 클로드의 가장 무겁고 똑똑한 고성능 AI 모델을 단순한 퀴즈 텍스트 생성에 전부 때려 박고 있었기 때문이었습니다.

고성능 모델만 쓰던 게 문제였습니다

현재 클로드의 AI 모델 종류는 Sonnet 4.6, Haiku 4.5, Opus 4.6, Sonnet 4.5, Opus 4.7 등이 존재하며, 모델마다 비용과 사용량 차이가 크게 납니다. 보통은 전체적인 구조나 마스터플랜을 짤 때 최고 사양인 Opus 4.7을 쓰고, 실제 반복적인 코딩 생산이나 단순 텍스트 생성은 가성비와 속도가 좋은 Sonnet 4.6이나 Haiku를 씁니다.

하지만 저는 비개발자라 아무것도 모르는 상태였으니, 모든 파이프라인을 Opus 4.7로 전부 실행되게 만들어 두었던 것입니다. 이 사단이 난 원인을 파악하자마자 클로드 코드에게 곧바로 명령했습니다. “이 낭비되는 상황을 파악하고, 비용을 줄이기 위한 최소한의 행동 계획을 짜서 나한테 줘.”

 

여기서 AI를 활용할 때 유용한 팁을 하나 드리자면, 무작정 “너 이거 해줘”, “이건 이렇게 고쳐줘”라고 단편적인 지시를 내리는 것보다 “먼저 계획을 짜라”고 우선순위를 넘겨주는 것이 훨씬 좋습니다. AI들이 계획을 먼저 수립하게 만들면, 스스로 무엇을 해야 할지 논리적인 단계를 거치기 때문에 이후 행동에서 실수가 급격하게 줄어듭니다.

 

 

확인해 보니 역시나 제가 만든 심리테스트 자동화 스크립트가 돌아갈 때 모든 텍스트 생성 API 요청이 전부 무거운 모델로 처리되고 있었습니다.

 

모델 분산으로 사용량이 15%까지

 

클로드 코드의 안내에 따라 무거운 작업은 상위 모델로, 단순 퀴즈 생성이나 폼 양식 맞추기는 하위 모델로 분산하는 수정을 거쳤습니다. 그리고 다시 실행을 시켜보니 놀랍게도 사용량이 기존의 3분의 1 수준인 15%까지 뚝 떨어졌습니다.

 

프로그램이나 자동화 시스템을 구축할 때 리소스 낭비가 심하다면, 어떤 모델이 불필요하게 고스펙으로 돌아가고 있는지 반드시 체크해 보셔야 합니다.

비개발자가 꼭 기억할 두 가지

 

더 중요한 것은 진짜로 성능이 필요한 핵심 부분과 가볍게 처리해도 되는 부분을 구별하지 못하면 나중에 더 큰 문제가 생긴다는 점입니다. 비개발자 입장에서 복잡한 자동화를 구현할 때는 이 두 가지만 꼭 기억하시길 바랍니다.

무조건 계획(Plan)부터 AI에게 짜 달라고 요청할 것

계획된 단계 중 딱 한 가지를 정확하게 마무리 짓고 다음 단계로 넘어갈 것

이 원칙만 지켜도 저처럼 하루 만에 아까운 사용 한도를 절반 넘게 날려 먹는 실수는 피할 수 있을 것입니다. 결국 클로드 코드 사용량 관리의 핵심은 무거운 모델과 가벼운 모델을 제대로 나누는 것이었습니다.

AI 자동화 실패담 이야기다. AI 영상&블로그 자동화, 돈 날리고 깨달은 솔직한 후기
처음에는 AI로 영상이랑 블로그 글을 뚝딱 만들어내는 '자동화 공장'만 구축하면 모든 게 끝날 줄 알았습니다. 하지만 직접 부딪혀보니 현실은 상상과 많이 달랐습니다. 이건 제가 직접 겪은 AI 자동화 실패담입니다.

할루시네이션, AI들의 뻔뻔한 거짓말

가장 먼저 발목을 잡은 건 AI들의 뻔뻔한 거짓말, 바로 할루시네이션(환각 현상)이었습니다. 제미나이든, 지피티든, 클로드든 가리지 않고 모르는 걸 마치 진짜인 것처럼 너무 당당하게 지어내서 써주더군요. 그대로 올렸다가는 큰일 나겠다 싶어서 결국 사람이 하나하나 검수해야 하는 번거로움이 생겼습니다.

API 연동의 함정

그다음 찾아온 난관은 바로 API 연동이었습니다. 텍스트 생성은 물론이고 이미지, 사진, 목소리 생성까지 이것저것 욕심내서 파이프라인에 다 연결해 두었죠. 이때까지만 해도 자동으로 굴러가는 시스템을 보며 뿌듯함이 앞섰습니다.

하지만 여기서 정말 뼈아픈 실수를 하나 하게 됩니다. 이번에 제미나이 이미지 생성 API를 연결하면서 당연히 일정 구간은 무료이거나 비용이 거의 안 들 줄 알았거든요. 나중에 알고 보니 무료가 아니라는 사실을 깨닫고 금액을 확인했을 때 그 당혹감이란 이루 말할 수 없었습니다. 지갑이 제대로 털리고 나니 정신이 번쩍 들더군요.

복붙 노가다에서 벗어나기까지

이뿐만이 아니었습니다. 초기에는 코딩을 잘 모르니 AI가 짜준 코드를 그저 복사해서 내 코드 마크다운에 붙여넣고, 또 에러 나면 다시 복사해서 붙여넣는 무한 루프를 반복했습니다. 파일 하나 수정하는 데도 시간이 엄청나게 걸렸죠.

그러다 최근에 클로드 코드를 활용해 내 PC 안의 소스 코드를 직접 읽고 알아서 내용을 수정해 주는 방식으로 워크플로우를 바꿨습니다. 일일이 복붙하지 않아도 터미널에서 알아서 척척 고쳐주니 개발 속도와 편의성이 완전히 신세계로 바뀌더군요. 노가다 아르바이트를 하다가 자동화 장비를 들여놓은 기분이었습니다.

AI 자동화 실패담이 남긴 진짜 자산

지나고 보면 API 비용으로 생돈도 날리고, 코드 에러 잡느라 밤새며 시간 낭비를 참 많이 한 것 같습니다. '내가 지금 뭘 하고 있나' 싶어 현타가 올 때도 많았습니다. 돈 낭비, 시간 낭비처럼 보였던 그 수많은 삽질의 순간들이 사실은 절대 쓸모없는 짓이 아니었습니다.

그 과정에서 에러를 해결하는 눈이 생겼고, 어떤 AI 모델이 어느 작업에 효율적인지 몸으로 깨달았습니다. 결국 그 비싼 수업료들이 고스란히 제 안의 '경험'과 '데이터'로 누적되어 가고 있었던 겁니다. 실패해 보지 않았다면 절대 만들지 못했을 나만의 단단한 무기가 생긴 셈이죠. 자동화는 단순한 기술이 아니라, 수많은 시행착오를 견뎌낸 경험의 결과물입니다. 결국 이 AI 자동화 실패담이 제 가장 큰 자산이 됐습니다.

AI 영상 자동화 유튜브 커썰 채널 악플 속에서 깨달은 성공 비결

AI 영상 자동화 시스템으로 유튜브 커썰 채널을 운영하며 겪은 조회수 상승 과정과 악플 진흙탕 속의 혼돈을 공유합니다. 그 속에서 뼈저리게 깨달은 롱런하는 유튜브 콘텐츠의 진짜 비밀과 방향성을 단문 위주로 솔직하게 정리했습니다.

이 글은 결국 AI 영상 자동화 커썰 채널 실패담이자 회복기입니다. 자동화 공장을 굴려 본 입장에서, 기술보다 사람의 마음이 더 어렵다는 사실을 뒤늦게 알게 된 기록이기도 합니다.

AI 영상 자동화 커썰 채널, 그 시작은 조회수 3회였습니다

조회수 3회라는 처참한 성적표를 받았습니다. 한 사흘은 넋이 나간 채 지냈습니다. 코딩을 못 한 것도 아닙니다. 그림 퀄리티가 떨어지는 것도 아니었습니다. 대체 왜 안 볼까 고민했습니다. 밤새워 가며 빌드업한 내 완벽한 비디오 팩토리가 순식간에 고철 쓰레기가 된 기분이었습니다.

결국 다시 원점으로 돌아갔습니다. 유튜브를 뒤지며 대박 났다는 채널들을 분석하기 시작했습니다. 그리고 뼈저리게 깨달았습니다. 사람들이 유튜브에서 원하는 건 대단한 기술이나 고결한 정보가 아니었습니다. 그저 뇌를 빼고 볼 수 있는 재미가 필요했던 겁니다. 한 번 보고 슥 날릴 수 있는 휘발성 재료였습니다.

사람들이 좋아하는 재료로 다시 판을 짜기로 결심했습니다. 그렇게 제가 선택한 건 바로 인터넷 커뮤니티의 썰들이었습니다. 이른바 커썰 채널을 기획한 것입니다.

두 번째 공장 가동

다양한 커뮤니티에서 조회수가 폭발한 화제의 글들을 스크래핑 로봇으로 긁어왔습니다. 그리고 AI를 시켜서 유튜브 쇼츠나 롱폼에 맞게 대본을 재구성했습니다. 자극적이고 몰입감 넘치는 대본으로 만들었습니다. 제미나이로 감정선이 살아있는 이미지를 뽑아냈습니다. 노드 프로그램으로 TTS와 자막을 칼싱크로 얹었습니다. 두 번째 공장이 가동된 것입니다.

확실히 커뮤니티 썰은 치트키였습니다. 영상을 올리기 시작하자마자 반응이 왔습니다. 조회수 3회에서 기어가던 그래프가 치고 올라갔습니다. 수백, 수천, 심지어 몇만 회까지 쭈욱 상승했습니다. 역시 대중들이 원하는 건 이거였습니다.

댓글 창은 곧 아수라장

드디어 성공 가도에 올랐다고 생각했습니다. 매일 신나게 댓글 창을 확인했습니다. 그런데 조회수가 나오는 만큼 또 다른 진흙탕이 저를 기다리고 있었습니다. 생각지도 못한 혼돈이었습니다. 커뮤니티 썰이라는 게 워낙 자극적이었습니다. 댓글 창이 순식간에 아수라장이 되더군요. 온갖 거친 표현과 비난이 쏟아졌습니다.

가장 황당했던 건 주인공의 성별을 두고 싸우는 것이었습니다. 대본을 각색하는 과정에서 시점이 조금 묘해졌던 모양입니다. 댓글에선 여잔데 남자인 척 소설을 쓴다며 싸웠습니다. 남잔데 여자인 척 거짓말을 한다며 지들끼리 편을 갈랐습니다. 단순히 재미있으라고 만든 영상이었습니다. 왜 남녀 갈등을 조장하냐는 비난을 받았습니다. 황당한 주작 글을 작작 올리라는 날 선 댓글을 실시간으로 두들겨 맞았습니다. 정신이 피폐해지더군요.

매일 악플의 세례를 받다 보니 회의감이 들었습니다. 인간 혐오가 생길 것 같았습니다. 인터넷 공간은 생각보다 차가웠습니다. 사람들은 뒤에서 남 욕하고 헐뜯는 자극적인 이야기에 미친 듯이 반응합니다. 그러니까 커뮤니티가 맨날 싸움터가 되는 것입니다. 저 역시 그 자극성에 편승해서 조회수를 빨아먹어 보려고 했던 것입니다.

기묘한 역설을 발견하다

하지만 악플을 차단하고 댓글 창을 관리했습니다. 그 과정에서 아주 기묘한 역설을 하나 발견하게 되었습니다. 사람들은 뒤에서 남 흉보고 자극적인 소설에 열광하는 것 같았습니다. 정작 유튜브라는 오픈된 공간에서 오랫동안 사랑받는 영상들은 결이 달랐습니다. 끝까지 살아남는 영상들은 따로 있었습니다.

누군가를 비난하고 편 가르는 영상은 순간적으로 조회수가 폭발합니다. 하지만 결국 채널을 망가뜨리고 사람을 지치게 만들더군요. 반면에 다른 사람들의 힘들었던 이야기나 그걸 이겨내는 감동적인 이야기들이 있었습니다. 따뜻한 이야기들에는 사람들이 진심 어린 응원의 댓글을 남기고 있었습니다. 사람들은 결국 위로받고 싶어 하는 것이었습니다.

자극적인 불량식품 같은 영상으로 조회수 몇 번 땡기는 건 쉽습니다. 하지만 진짜 사람의 마음을 움직여야 합니다. 오래가는 채널을 만들려면 알맹이에 따뜻함이 있어야 한다는 걸 비로소 깨달았습니다. AI와의 치열한 코딩 지옥을 지나왔습니다. 새로운 기술의 신세계를 맛보았습니다. 조회수 제로의 사막을 거쳤습니다. 악플 가득한 진흙탕까지 겪어보고 나서야 진짜 유튜브가 뭔지 조금 알 것 같더군요.

이제 기술은 완벽하게 손에 익었습니다. 세팅은 끝났습니다. 이제 제가 해야 할 일은 명확합니다. 이 강력한 AI 무기들을 가지고 사람들에게 해가 아니라 위로와 감동을 주는 진짜 이야기를 생산하는 것이었습니다.

결국 제가 도달한 결론은 단순합니다. AI 영상 자동화 커썰 채널. 그 안에 사람을 살게 하는 따뜻한 한 줄이 들어 있어야 오래 갑니다. 기술은 도구일 뿐, 결국 시청자의 마음에 남는 건 위로와 공감이라는 사실을 잊지 않으려 합니다.

AI 영상 자동화 실패담 이야기다. 살다 살다 기계 쪼가리한테
쌍욕을 박을 줄은 몰랐습니다.

지금 생각하면 코미디인데,
그땐 눈 뒤집히기 직전이었거든요.

모니터 부숴버리려다 참은,
제 눈물겨운 삽질 스토리입니다.

AI 영상 자동화 실패담, 이렇게 시작됐습니다

그때가 아마 올해 초였을 겁니다.
남들 다 하니까 나도 해보자!

영상 자동화에 겁 없이 덤볐죠.
노드(Node.js) 코딩을 붙잡고

밤마다 방구석에서 두드렸습니다.
'딸깍 딸깍' 키보드 소리만 났죠.

목표는 단 하나였습니다.
자막과 TTS 목소리가 딱 맞는,
완벽한 영상 팩토리 만들기.

처음엔 지피티가 코드를
참 기가 막히게 짜주더라구요?

코드는 완벽한데 싱크가 어긋난다

"형님, 나만 믿으십쇼."
"코딩 그까이꺼 대충 하면 끝납니다."

속으로 야르~ 소리를 질렀죠.
그런데 드디어 일이 터졌습니다.

분명 코드는 완벽해 보였거든요?
근데 싱크가 자꾸 어긋납니다.

말은 이미 끝났는데,
자막은 한참 뒤에 나오더라구요.

어떨 땐 자막이 스포를 해버립니다.

"지피티야, 이거 싱크 왜 이래?"
"코드 다시 짜줘."

"지피티: 죄송합니다. 비동기 처리 로직을 수정했습니다."

철석같이 믿고 돌렸습니다.
결과는 똑같더라구요.

오히려 더 꼬여버렸습니다.
이 짓을 한 스무 번 반복하니까,

속에서 천불이 났습니다.

"야, 너 장난하냐? 방금 준 코드랑 똑같잖아!"

"지피티: 아, 제가 착각했네요. 이번엔 진짜 고쳤습니다."

말대꾸하는 꼬라지를 보는데,
순간 이성을 잃어버렸습니다.

모니터에 대고 소리를 질렀죠.

"이 쓸모없는 기계 자식아! 똑바로 안 해?!"

진짜 화면 너머 멱살이라도
잡고 싶은 심정이었습니다.

제미나이는 눈치가 없었습니다

머리나 식히자 싶었습니다.
영상에 들어갈 이미지를 뽑으려고

제미나이를 켰습니다.

"야, 주인공이 억울해하는 느낌. 그런 그림 하나 뽑아봐."

근데 이 제미나이 녀석은
눈치가 더럽게 없더라구요.

맑고 고운 일러스트를 대령합니다.

"아니, 억울한 느낌 몰라? 내가 지금 화가 난다고!"

"제미나이: 요청을 이해했습니다. 하지만 안전 정책상…"

거기서 퓨즈가 팍 끊겼습니다.
돈 내고 쓰는데 훈계질이라니요.

구원자 클로드의 등장

"에라, 때려치워라. 내가 무슨 부귀영화를 누리겠다고."

노트북을 덮으려는데,
억울해서 잠이 안 오더라구요.

담배 한 대 피우고 유튜브를 켰죠.
'AI 자막 싱크 오류 해결'

'자동화 프로그램 에러'
이것저것 미친 듯이 뒤졌습니다.

그러다 어떤 영상 댓글에서
낯선 이름을 발견했습니다.

'코딩은 무조건 클로드 쓰세요. 지피티 뺨 때립니다.'

클로드? 그게 뭔데?
속는 셈 치고 가입했습니다.

그리고 망한 노드 코드를 던졌죠.

"야, 지피티도 못 고친 거다. 네가 볼 수 있겠냐? 왜 밀려?"

잠시 뒤 답변이 올라오는데,
소름이 쫙 돋았습니다.

"클로드: 타임스탬프 파싱 과정에서 밀리초 오차가 누적되고 있네요. 이 부분을 ffmpeg 필터로 강제 고정하세요."

밤새도록 지피티랑 싸우면서
듣지 못한 원인 분석이었습니다.

클로드가 새로 짜 준 코드를
그대로 복사했습니다.

그리고 제 프로그램에 붙였죠.
떨리는 마음으로 엔터를

'딸깍' 쳤습니다.

…어라? 맞아떨어집니다.
목소리 나오는 타이밍에

자막이 칼같이 박히더라구요.
1초 만에 해결된 순간이었습니다.

"우와! 됐다! 진짜 되네?!"

새벽 3시에 소리를 질렀습니다.
혈이 뻥 뚫리는 기분이었죠.

싱크가 해결되니까
세상 다 가진 기분이었습니다.

클로드+제미나이 콜라보의 마법

이제 그림만 잘 나오면 끝인데,
아까 그 제미나이가 걸렸습니다.

화질 자체는 나쁘지 않았거든요.
명령어를 못 알아먹는 게 문제였죠.

문득 머리에 스치는 생각이
하나 있었습니다.

'코딩 잘하는 클로드한테 프롬프트를 짜달라고 해볼까?'

곧바로 클로드 창을 켰습니다.

"야 클로드, 제미나이 쓸 건데. 주인공이 억울해 미치는 상황이야. 찰떡같이 알아먹게 영어로 짜줘."

"클로드: 제미나이는 얼굴 근육과 배경 색조를 지정하는 게 좋습니다. 이렇게 입력해 보세요."

아주 길고 정교한
영어 프롬프트를 뱉어내더군요.

그걸 복사해서 제미나이한테
슥 던져줬습니다.

'또 헛소리하면 탈퇴한다.'
속으로 칼을 갈았죠.

그런데 결과물이 뜨자마자
입이 떡 벌어졌습니다.

진짜 억울해 죽겠다는 표정이
화면에 딱 나타난 겁니다.

영화 포스터급 퀄리티였습니다.

"와… 이거구나!"
무릎을 탁 쳤습니다.

AI는 죄가 없었습니다.
멍청한 건 AI가 아니라,

사용법을 모르는 저였던 거죠.
이 조합을 알아낸 뒤로

제작 속도에 날개가 달렸습니다.
클로드한테 대본 검수받고,

코드 고치고, 프롬프트 따오고.
그걸로 제미나이 그림 뽑고.

노드 프로그램 돌려서
TTS랑 자막 합치고!

완벽한 무한 동력 팩토리가
방구석에서 돌아갔습니다.

하루 한 개 만들던 영상을
눈 깜짝할 사이에 찍어냈습니다.

컴맹이나 다름없던 제가
AI 툴들을 다루고 있더라구요.

점점 실력이 늘어가는 게 느껴졌죠.
스스로 대견하기도 하고,

어깨 뽕이 잔뜩 들어갔습니다.
친구들 만나서 은근히 자랑도 했죠.

"나 요즘 툴 여러 개 엮어서 영상 자동 생성하잖아."

조회수 3회, 진짜 문제는 따로 있었습니다

신나게 영상을 올렸습니다.
썸네일 예쁘고, 싱크 칼 같고,

화질까지 완벽한 영상들.
한 개, 두 개, 열 개, 스무 개…

채널에 차곡차곡 쌓였습니다.
이제 돈 벌 일만 남았다 싶었죠.

조회수 대박 터지는 상상을 했습니다.
매일 아침 눈뜨자마자

유튜브 스튜디오 앱을 켰습니다.

그런데 숫자가 이상하더라구요.
조회수: 3회.

그나마 2회는 제가 검수하느라
클릭한 거였습니다.

'초반이라 알고리즘 안 탔나 보지.'
말도 안 되는 합리화를 했습니다.

더 열심히 찍어냈습니다.
퀄리티는 점점 더 완벽해졌죠.

하지만 한 달이 지나도
조회수는 바닥을 기었습니다.

기술적으로는 완벽한데,
사람들이 전혀 보질 않더군요.

사막 한가운데서 나 혼자
축제를 열고 있는 기분이었습니다.

밤새워 가며 기술을 마스터했는데,
정작 제일 중요한 반응이 없었습니다.

그때 멍하니 깨달았습니다.
기술이 전부가 아니구나.

AI 쓰는 법은 마스터했을지 몰라도,
'사람 마음' 끄는 법을 놓쳤던 겁니다.

껍데기는 번지르르한데,
알맹이에 매력이 없었던 거죠.

그렇게 제 비디오 팩토리는
거대한 벽에 부딪히고 말았습니다.

기술은 완벽한데 조회수는 제로.
진짜 문제는 코딩이 아니었습니다.

여기까지가 제 AI 영상 자동화 실패담입니다.

여기서 다 때려치워야 할까요?
아니면 또 다른 길을 찾아야 할까요?