HKUDS/ViMax의 README 한 줄은 거의 그대로 아키텍처 선언이다. "Director, Screenwriter, Producer, and Video Generator All-in-One". 네 개의 역할이 한 시스템 안에 묶여 있다는 뜻인데, 중요한 건 이름의 화려함이 아니라 호출 순서다. 영상 생성 모델이 맨 앞이 아니라 맨 뒤에 위치한다. 앞의 세 단계는 전부 LLM 기반의 메타 의사결정이고, 실제 생성 콜은 모든 결정이 끝난 다음에야 발생한다.
이게 왜 의미 있냐면, 영상 에이전트를 실제로 만들어 본 사람은 안다. 진짜 어려운 건 모델 한 컷의 품질이 아니다. 컷과 컷 사이 캐릭터·조명·카메라 톤의 일관성, 길이와 음악과 자막의 정합, 그리고 비싼 generation call을 몇 번 호출하고 어디를 다시 뽑을지 결정하는 메타 판단이다. ViMax는 이 메타 판단을 "Producer"라는 역할로 분리하고, 영상 모델 호출 자체를 또 하나의 도구로 다룬다. Screenwriter가 트리트먼트를 쓰고, Director가 그것을 샷 단위로 쪼개고, Producer가 길이와 자원·연속성을 조정한 뒤에야 Video Generator가 불려 나온다.
이 구조의 부수 효과는 백엔드 종속성에서 풀려난다는 점이다. Sora든 Veo든 Kling이든, 마지막 단계의 생성 백엔드를 바꿔 끼워도 앞단의 각본·샷리스트·프로듀서 노트는 그대로 재사용된다. 하루 +504 stars로 튀어 오른 배경에는 "또 하나의 video model wrapper"가 아니라 "영상 생성을 멀티 에이전트 파이프라인의 마지막 노드로 끌어내린 레퍼런스"라는 위치 설정이 있다.
물론 트레이드오프는 분명하다. 4역할이 분리된 만큼 단계별 LLM 호출이 누적되고, 한 컷이 어색할 때 Director·Screenwriter·Producer 중 누구의 판단이 틀렸는지 추적해야 한다. 그래서 이 repo를 실제로 가져다 쓸 때 가장 먼저 손봐야 할 것은 모델 교체가 아니라, 각 단계의 중간 산출물—스크립트, 샷리스트, 프로듀서 노트, 생성 결정 로그—을 사람이 읽고 다시 고칠 수 있게 남기는 일이다. 영상 에이전트의 운영 비용은 모델 가격이 아니라, 이 중간 산출물의 가독성에서 가장 크게 결정된다.