숏폼 콘텐츠가 넘쳐나는 시대, 우리는 단순 기계식 생성을 넘어 "내러티브가 있고 세계관이 일률적으로 맞물려 돌아가는" 영상을 만들어내는 Kkulim Video 파이프라인을 운영하고 있습니다. 초기에는 빠른 결과 위주의 모델을 주로 사용했지만, 프로젝트 고도화에 따라 시각적 품질과 각 에피소드 속 인물들의 일관성이 가장 큰 화두로 떠올랐습니다.
그리고 오늘 우리는, 파이프라인의 핵심인 비디오 생성 엔진(Video Generation Model)을 구글의 Gemini Veo 3.1 Lite (`veo-3.1-generate-preview`) 로 전면 교체하는 핵심적인 돌파구를 마련했습니다. 이 마이그레이션 도입 사례가 자동화 비디오 프로젝트를 구상중인 많은 개발자와 창작자들에게 의미 있는 인사이트가 되길 바랍니다.
## 1. 마이그레이션, 왜 필요했을까? (The Challenge)
기존 LTX 기반의 엔진들도 훌륭하지만, 시리즈물 영상 매체에서 가장 크게 직면한 문제는 주인공의 외모나 소품이 씬(Scene)이 바뀔 때마다 미세하게 튀거나 왜곡되는 문제였습니다. 이는 프롬프트 엔지니어링이나 프리픽스(prefix)를 길게 늘려 쓰는 텍스트 기반 보일러플레이트만으로는 근본적 해결이 불가능했습니다.
본질적으로 "이미지를 보고 그대로 학습해서 움직이게 해주는" (Reference Image) 시스템만이 답이었습니다. 구글에서 공개한 Veo 3.1 Lite는 바로 이 점을 SDK 단에서 매끄럽게 처리해준다는 강력한 강점이 존재했습니다.
## 2. 모듈식 구조가 빛을 발하다 (The Process)
마이그레이션이 단 몇 시간 만에 물 흐르듯 자연스럽게 적용될 수 있었던 배경엔 Agentic Pipeline의 모듈화(Decoupling) 설계가 있었습니다.
* 동적 의존성 바인딩: produce.py가 영상 생성 스킬의 하드코딩된 호출부에 의존하지 않고, config.yaml의 프로바이더 값(`providers.video: "gemini-video"`) 방향타 한 번 조작하는 것만으로 구동되도록 리팩토링 되어 있었습니다.
* 유연한 스킬 교체: 기존 아키텍처를 뒤엎지 않고 skills/gemini-video라는 하나의 작은 레고 블록을 신설한 후, API 규격(google-genai SDK 사용)에 맞춰 --ref 라는 참조 이미지 전달 통로만 새로 뚫었습니다. 이전 모델에서 쓰던 무의미한 길이 파라미터(`duration`)들도 파이프라인 호환성을 위해 조용히 흡수 시켜버렸습니다.
## 3. Veo의 시각적 일관성: --ref 기능을 말하다 (Key Feature)
이번 구현의 핵심은 types.VideoGenerationReferenceImage(..., reference_type="asset")의 활용입니다.
이제 시나리오 프롬프트 엔지니어가 산출한 텍스트 덩어리뿐 아니라, 이전 에피소드로부터 내려오는 주인공의 원본 시트, 무대 배경, 키 소품 등의 시각적 "매니페스트" 파일들이 에셋 파이프라인을 거쳐 Veo에게 참조 이미지 배열 형태로 그대로 찔러 들어갑니다.
결론적으로 AI가 헷갈려 생성해 내던 회색 지대(Hallucination)가 사라지고, 정교하게 통제된 스타일의 숏폼 결과물이 렌더링 됩니다.
## 4. 남겨진 생각들 / 시사점 (Takeaways)
파이프라인을 유지 및 발전시키는 프로젝트는 "돌아갈 수 있는 다리"를 항상 남겨두어야 합니다.
이번 과정에서도 우리는 기존 fal-video 플랫폼 설정과 모듈을 완전히 지우지 않았습니다. API Rate Limit 문제 발생 시거나 혹은 다른 특수 효과가 필요할 때 언제든 fallback 엔진으로 롤백하여 작동할 수 있게 설계 하였음을 자부합니다.
AI 트렌드는 1주 단위로 바뀝니다. 새로운 모델(Veo 3.1)이 나오면 내 파이프라인의 '해당 톱니바퀴'만 갈아 끼우면 되는 구조. 이것이 Kkulim Video 파이프라인이 보여준 에이전트 기반 구조의 가장 위대한 성공사례일 것입니다. 이번 Gemini Veo 3.1 적용은 이런 확장성의 증명이자, 콘텐츠 일관성의 새로운 기준점이 되었습니다.
