2026년 10월 ZView Space H3 워커의 파이프라인 문서와 코드를 바탕으로 합니다. 이 글은 우리 자체 워크플로를 설명하는 것이며 MiniMax 의 공식 방법이 아닙니다.
ComfyUI 출시 글에 따르면 MiniMax H3 는 클립당 최대 15초를 만듭니다. 그보다 긴 영상은 여러 클립으로 만들어야 하고, 어려운 점은 서로 관계없는 네 개의 영상이 아니라 하나의 영상처럼 보이게 하는 것입니다. 우리가 운영하며 정착한 방법은 한 클립의 마지막 프레임을 다음 클립에 실제 첫 프레임으로 넘기고 결과를 이어 붙이는 것입니다.
왜 60초를 한 번에 요청하지 않나
우리 첫 장편 프로필 문서에는 이렇게 적혀 있습니다. 현재 워커에서 60초를 한 번에 렌더링하는 것은 실용적이지 않아서, 60초 프로필은 15초 렌더링 네 번으로 만듭니다. 짧게 나눠 렌더링하면 실패해도 부담이 작습니다. 세 번째 장면이 잘못 나오면 1분 전체가 아니라 세 번째 장면만 다시 만들면 됩니다.
참조 조건과 하드 첫 프레임
H3 는 이미지를 상당히 다른 두 가지 방식으로 받으며, 그 차이가 이어 붙이기의 성패를 가릅니다.
- 참조→영상(Reference-to-video) 은 이미지를 느슨한 안내로 다룹니다. 모델은 피사체의 외형을 유지하되 첫 장면의 구도는 스스로 정할 수 있습니다.
- 첫 프레임(이미지→영상) 은 이미지를 실제 시작 프레임으로 다룹니다. ComfyUI 에서는 `MiniMaxH3ImageToVideo` 노드와 그 `first_frame` 입력입니다.
이어 붙이기에는 두 번째 방식이 필요합니다. 다음 장면이 이전 프레임을 느슨한 참조로만 받으면 컷에서 자세, 구도, 조명이 튈 수 있습니다. 그래서 우리의 다중 장면 프로필에서는 첫 장면 이후의 각 장면이 느슨한 조건이 아니라 첫 프레임 입력으로, 이전 클립을 디코딩한 마지막 프레임에서 시작합니다. 일반적인 한 장짜리 이미지 작업에서도 업로드한 이미지를 참조 전용 조건이 아니라 하드 첫 프레임으로 고정해 씁니다.
연결 과정 단계별
우리의 60초 스토리 프로필은 이렇게 동작합니다.
1. 참조 이미지 한 장이 1번 장면을 시작합니다. 2. 장면이 끝나면 서버가 마지막 프레임을 추출합니다. 3. 그 프레임이 다음 장면 렌더링의 첫 프레임이 됩니다. 4. 15초 장면 네 개가 모두 끝나면 FFmpeg 가 하나의 60초 파일로 이어 붙입니다. 5. 마지막 전달 단계에서 모델이 렌더링한 크기와 관계없이 결과를 1080 x 1920(9:16) 또는 1920 x 1080(16:9)로 맞춥니다. Lanczos 업스케일, 가운데 크롭, H.264/AAC 인코딩을 사용합니다.
다른 프로필은 10초 장면 여섯 개를 씁니다. 정지 이미지로 시작해서, 비전 모델이 그림에 실제로 무엇이 있는지 설명하고, 텍스트 모델이 그 설명에 근거한 여섯 장면짜리 각본을 씁니다. 각본에는 각 장면의 마지막 프레임이 어떤 상태로 끝나야 하는지가 명시됩니다. 대체 각본은 없습니다. 이미지 분석이나 각본 단계가 실패하면 H3 렌더링이 시작되기 전에 작업이 실패합니다. 범용 대체 스토리는 이미지와 맞지 않기 때문입니다.
카메라와 물리를 일관되게
이어 붙이기는 양쪽 내용이 일치할 때만 이음새를 가려 줍니다. 세 가지 규칙이 대부분의 일을 했습니다.
- 마지막 프레임의 상태를 프롬프트에 적습니다. 각 장면의 프롬프트에 클립이 어떤 자세, 시선, 손 위치, 조명으로 끝나야 하는지를 적어서, 다음 장면이 이어받을 일관된 출발점을 줍니다.
- 워크플로마다 카메라를 고정합니다. 고정 카메라 시퀀스에서는 경계에서 핸드헬드 움직임을 쓰지 않으며, 워크플로마다 자체 카메라 규칙을 유지합니다.
- 움직임을 원인과 결과로 설명합니다. 모든 H3 프롬프트에 같은 지시를 넣습니다. 움직임은 물리적 인과를 따라야 하고, 손·발·소품은 닿는 대상과 접촉을 유지해야 하며, 일반적인 군더더기 제스처는 제거합니다. 구체적인 사건(피사체 하나, 물체 하나, 당면한 문제 하나, 짧은 비트 순서)이 있는 프롬프트가 "자연스럽게 움직여"만 요청하는 프롬프트보다 낫게 동작합니다.
하나의 연속된 샷처럼 느껴져야 하는 시퀀스에서는 한 걸음 더 나아갑니다. 들어오는 클립의 마지막 17프레임을 다음 렌더링에 움직임 맥락으로 전달하고, 새 클립의 첫 1초는 이야기를 진행하지 않고 그 움직임을 재현하며, 요청 하나에 속한 모든 구간이 하나의 난수 시드를 공유해서 경계마다 관계없는 노이즈 패턴이 생기지 않게 합니다. 우리 문서는 이것을 픽셀 고정이 아니라 모델이 따르도록 유도하는 약속이라고 분명히 적습니다. 모델은 여전히 흐트러질 수 있습니다.
여전히 잘 안 되는 것
- 천천히 번지는 정체성 변화. 인계마다 다시 렌더링하므로 얼굴이나 옷의 작은 변화가 네 장면, 여섯 장면에 걸쳐 쌓일 수 있습니다. 원칙적으로는 장면이 적고 길수록 변화가 쌓일 기회가 적지만, 우리는 이를 측정하지 않았습니다.
- 오디오는 클립마다 생성됩니다. H3 는 클립마다 같은 패스에서 오디오를 만들기 때문에, 다시 믹싱하지 않으면 컷마다 오디오 이음새가 생길 것으로 예상해야 합니다. 우리는 음악을 별도 단계로 처리합니다.
- 비용은 선형으로 쌓입니다. 연결 자체의 추가 비용은 거의 없고, 렌더링 시간은 장면 시간의 합입니다([우리가 잰 H3 렌더링 시간](/articles/minimax-h3-render-time-comfyui-worker/ko) 참조).
- 잘못된 장면은 다음 장면을 오염시킵니다. 실패한 장면의 마지막 프레임이 다음 장면의 첫 프레임이므로, 가능하면 계속하기 전에 장면마다 확인하세요.
체크리스트
1. 각 장면은 이전 마지막 프레임을 느슨한 참조가 아니라 진짜 첫 프레임으로 받아 렌더링합니다. 2. 모든 장면의 끝 상태를 프롬프트에 적습니다. 3. 연결 전체에서 카메라, 렌즈, 조명을 일정하게 유지합니다. 4. FFmpeg 로 이어 붙이고, 파일 전체에 한 번만 전달용 인코딩을 합니다. 5. 오디오는 따로 계획합니다. 6. 시간을 예산으로 잡습니다. 장면 시간의 합입니다.
위 기술 내용은 2026년 10월 19일 기준 우리 내부 H3 문서와 워커 코드에서 가져왔습니다. H3 자체는 MiniMax H3 Community License 로 배포되며, MiniMax 의 로컬 배포 가이드에 지역 조건이 설명되어 있으니 상업적 사용 전에 라이선스 원문을 확인하세요.