MiniMax H3 Max 텍스트 투 비디오 프롬프트 레시피 (개발자 대상)

좋은 텍스트 투 비디오 프롬프트는 무엇으로 구성되는가

텍스트 투 비디오 프롬프트는 한 문장이 아니다. 자연어로 작성된 작은 설정 파일이다. 생성 결과가 잘못 나왔을 때 정말 유용한 질문은 “프롬프트가 좋은가?”가 아니라 “프롬프트의 어느 부분이 실패했는가?”이다. 이 질문에 답하려면 작성한 프롬프트에 지목 가능한 구성 요소가 있어야 한다.

모든 프롬프트를 서로 독립적인 여섯 개의 블록으로 보라:

• 주체(Subject) — 화면에 누구 또는 무엇이 있는지, 여러 번의 생성에서 일관성을 유지할 만큼 구체적으로(종, 재질, 의상, 연령대, 식별 특징).
• 동작(Action) — 주체가 무엇을 하는지, 발생 순서대로 나열한다. 이것은 비트 목록이지 분위기가 아니다.
• 장면(Scene) — 장소, 시간, 날씨, 배경 활동, 그리고 광원.
• 카메라(Camera) — 카메라가 어디에 있고, 어떻게 움직이며, 어떤 속도로 움직이는지. 이것은 장면과 다른 일이므로 별도 줄로 분리해야 한다.
• 길이(Duration) — 클립이 얼마나 지속되어야 하는지, 그리고 암묵적으로 그 안에 몇 개의 동작 비트가 들어갈 수 있는지를 결정한다.
• 해상도(Resolution) — 이번 생성에서 목표로 하는 출력 티어.

이 블록들을 물리적으로 분리하는 것—블록마다 한 줄, 또는 블록마다 라벨이 붙은 조각—이 중요한 이유는 비디오 생성이 다변수 최적화 문제이고, 한 번의 실험에서 변수를 하나만 움직일 수 있기 때문이다. 주체, 카메라, 길이가 매끄러운 한 문단 안에 얽혀 있다면 카메라를 바꾸는 동시에 주체의 표현과 문장 리듬까지 바뀌어, 어느 변경이 다른 결과를 낳았는지 더 이상 말할 수 없게 된다.

분리된 블록은 반복 편집에도 더 잘 견딘다. 주체 블록은 같은 장면의 열 개 샷에서 재사용할 수 있다. 카메라 블록은 렌즈를 바꾸듯 교체할 수 있다. 길이 블록은 동작을 다시 쓰지 않고도 늘리거나 줄일 수 있다. 산문 형태로 쓴 프롬프트는 매번 처음부터 다시 써야 하지만, 블록 형태로 쓴 프롬프트는 항목별로 비교할 수 있다.

마지막으로 기억할 점: 이 블록들의 효력은 대등하지 않다. 주체와 동작의 변경은 대개 눈에 보이고 직관적으로 이해된다. 카메라 표현과 길이의 변경이 대부분의 예상 밖 결과를 낳으며, 양방향으로 작용한다—전치사 하나가 프레이밍을 뒤집고, 길이 변경 하나가 마지막 동작 비트를 조용히 삭제할 수 있다. 그에 맞게 주의를 분배하고, 카메라와 길이에 각각 조정 가능한 자리를 마련하되 형용사 속에 묻어두지 마라.

아래의 모든 내용은 이 구조 위에 세워진다. 이른바 레시피란 잘 구조화되어 복사하고 편집할 수 있는 블록의 집합일 뿐이다.

바로 복사할 수 있는 레시피는 무엇으로 구성되는가

레시피는 라벨이 붙은 슬롯이 있는 프롬프트 템플릿이다. 복사하고, 슬롯을 채우고, 전송하면 다음 버전과 비교할 수 있는 결과를 얻게 된다. 구조가 절대 바뀌지 않기 때문이다.

다음 골격을 모든 실험의 기반으로 삼아라:

SUBJECT: <who/what, with 2–3 identifying details>
ACTION: <beat 1> -> <beat 2> -> <beat 3>
SCENE: <location>, <time of day>, <light source>, <background activity>
CAMERA: <position>, <movement>, <pace>
DURATION: <target length>
RESOLUTION: <tier for this pass>

이 템플릿을 형식적인 것이 아니라 실제로 유용하게 만드는 두 가지 규칙이 있다.

변하는 슬롯과 고정된 슬롯을 분리하라

일반적인 프로젝트에서 SUBJECT와 SCENE은 안정적인 기준선이다—여러 샷에서 같은 캐릭터, 같은 장소를 촬영한다. ACTION, CAMERA, DURATION, RESOLUTION은 샷마다의 변수다. 머릿속으로 “고정”과 “변동”으로 표시하고, 실험할 때는 변동하는 것만 건드려라. 결과가 예상 밖이었는데 그때 주체 설명까지 바꿨다면, 테스트 한 번을 낭비한 것이다.

ACTION을 형용사가 아닌 비트로 써라

비트 목록이 있으면 길이를 셀 수 있다. walks in -> sets down a box -> looks up는 세 비트다. 클립이 그중 두 개만 담고 돌아왔다면 이 샷은 너무 꽉 찼거나 길이가 너무 짧다는 것을 알 수 있다. a busy, dynamic scene은 아무것도 확인할 수 없다. 형용사는 SCENE과 CAMERA의 리듬에 속하며, 질감을 묘사하지 순서를 묘사하지 않는다.

프롬프트에 라벨을 유지하라

이 대문자 라벨은 모델을 위한 것이기도 하고 당신 자신의 기록을 위한 것이기도 하다. 변경 로그에서 차이를 읽기 쉽게 하고, 빠진 필드를 한눈에 보이게 하며, 연속된 수정 속에서 프롬프트가 산문으로 퇴화하는 것을 막는다. 모델이 라벨 붙은 조각을 잘 처리하면 유지하라. 매끄러운 문장을 더 선호하면 최종 단계에서 라벨을 제거하되, 기록에는 라벨을 남겨 구조화된 기록을 유지하라.

완전히 채운 예시:

SUBJECT: ceramicist in her 40s, clay-dusted apron, hair tied back
ACTION: lifts a wet bowl off the wheel -> turns it to inspect -> sets it on the shelf
SCENE: small studio, late afternoon, single window light from the left, dust in the air
CAMERA: medium close-up at wheel height, slow push in, unhurried pace
DURATION: short pass
RESOLUTION: draft tier

형식은 이게 전부다. 이어지는 모든 레시피는 이 골격에 특정 슬롯 하나를 테스트 대상으로 더한 것이다.

레시피: 길이 제어

길이는 장면을 늘리는 슬라이더가 아니다. 장면이 무엇을 담을 수 있는지를 바꾼다. 짧은 클립은 하나의 동작이다. 더 긴 클립은 시작, 중간, 끝이 있는 시퀀스이며, 그 시퀀스를 쓰지 않으면 모델이 스스로 채울 내용을 지어내거나 비트 하나를 잃는다.

그러므로 ACTION을 요구하는 길이에 맞추고, 길이를 기본값에 맡기지 말고 명시하라.

짧은 클립 레시피 (하나의 명확한 동작)

SUBJECT: <consistent subject block>
ACTION: single continuous gesture — <the one thing that happens>
SCENE: <stable scene block>
CAMERA: <fixed position, minimal movement>
DURATION: brief clip, one action beat
RESOLUTION: <current test tier>

짧은 클립은 절제에 보상을 준다. 동작 하나, 카메라 아이디어 하나, 배경 부수 줄거리 없음. 주체가 화면에 들어와야 한다면 그 입장 동작이 곧 동작이다. 동시에 몸 돌리기와 제스처까지 요구하지 마라.

더 긴 클립 레시피 (순서대로 나열된 비트)

SUBJECT: <consistent subject block>
ACTION: beat 1 -> beat 2 -> beat 3 (in this order)
SCENE: <stable scene block, plus any change over time>
CAMERA: <movement that supports the beats>
DURATION: extended clip, three beats
RESOLUTION: <current test tier>

더 긴 클립에는 명확한 순서와 제한된 비트 수가 필요하다. 하나의 연속 샷에서 세 비트는 합리적인 목표다. 다섯 개가 필요하다면 먼저 당신이 사실상 두 개의 샷을 묘사하고 있는 것은 아닌지 생각하라. 어느 비트가 추가 시간을 차지할 가치가 있는지도 결정하라—보통은 중간 비트인데, 첫 비트는 설정에, 마지막은 마무리에 쓰이기 때문이다.

길이 표현이 리듬을 바꾸는 방식

이 레시피들을 실행한 뒤 얻은 두 가지 실용적 관찰:

• 리듬을 서술하는 어휘는 길이 자체만큼 중요하다. unhurried, continuous, in one take, quickly는 같은 비트 목록이 클립 안에서 분포하는 방식을 바꾼다. 같은 세 비트 목록도 unhurried로 표시한 것과 quickly로 표시한 것은 다른 길이가 아니라 다른 샷이다.
• 비트 하나가 사라졌다면 먼저 길이를 늘리고, 그다음에 동작 삭제를 고려하라. 마지막 비트가 항상 잘린다면, 세 비트가 모두 필수라는 전제하에 보통의 해법은 비트를 줄이는 것이 아니라 공간을 더 주는 것이다.

다른 무엇을 테스트할 때는 길이를 고정하라

이 규율이 레시피를 쓸 만하게 만든다. 길이는 리듬을 바꾸고, 리듬은 카메라 움직임의 인상을 바꾸며, 카메라는 동작이 어떻게 펼쳐지는지에 영향을 준다. 카메라를 테스트하면서 길이를 변동시키면 귀인에서 실수하게 된다. 길이를 잠그고, 기록하고, 그다음에 다음 슬롯을 바꿔라.

같은 논리가 해상도에도 적용된다. 이는 다음 레시피의 주제다.

레시피: 해상도 티어 선택

해상도는 우선 비용과 반복 속도의 결정이고, 그다음이 화질 결정이다. 티어 사이에서 프롬프트는 크게 바뀌지 않는다. 바뀌는 것은 시도를 얼마나 감당할 수 있는지, 그리고 프롬프트 아이디어가 성립하는지를 얼마나 빨리 알아볼 수 있는지다.

두 티어로 생각하라: 탐색용 드래프트 티어와 전달용 최종 티어. 구체적인 수치는 모델의 파라미터 문서에 있다—여기서 중요한 것은 숫자가 아니라 워크플로우다.

드래프트 티어 레시피

SUBJECT: <subject block>
ACTION: <beat list>
SCENE: <scene block>
CAMERA: <camera block>
DURATION: <short test length>
RESOLUTION: draft tier

드래프트 실행은 구도 차원의 질문에 답한다: 주체를 식별할 수 있는가? 카메라 움직임을 읽을 수 있는가? 모든 비트가 있는가? 낮은 티어에서는 최종 렌더 한 번에 걸리는 시간 동안 여러 변형을 돌릴 수 있고, 프롬프트가 아직 변하는 중일 때 가장 필요한 것이 바로 그것이다.

최종 티어 레시피

SUBJECT: <locked subject block>
ACTION: <locked beat list>
SCENE: <locked scene block>
CAMERA: <locked camera block>
DURATION: <delivery length>
RESOLUTION: final tier

잠금이라는 단어에 주목하라. 최종 티어로 올리는 것은 검증된 프롬프트를 승격하는 것이지 또 한 번의 실험이 아니다. 해상도와 길이 외에는 아무것도 바꾸지 마라. 최종 렌더의 구도가 드래프트와 다르다면, 프롬프트에 해상도에 민감한 무언가가 있다는 뜻이며 기록할 가치가 있다.

용도별 티어 선택

• 탐색 및 내부 리뷰 — 드래프트 티어. 확인하는 것은 구조이지 정교함이 아니다.
• 프롬프트 회귀 검사 — 드래프트 티어. 비용이 충분히 낮아 변경마다 실행할 수 있다.
• 고객 전달 또는 임베드 전달 — 최종 티어, 그리고 드래프트가 의도에 부합해 통과한 뒤에만.
• 합성 화면의 배경 또는 심하게 크롭된 요소 — 그 요소가 화면의 작은 부분만 차지한다면 드래프트 티어로 충분할 수 있다.

낮은 티어를 먼저 테스트하는 것이 실제로 시간을 아끼는 이유

텍스트 투 비디오에서 비용이 큰 실패 모드는 잘못된 샷을 아름답고 고해상도로 렌더링하는 것이다. 곧 버려질 구도를 다듬는 데 쓴 모든 분은 낭비이며, 높은 티어에서는 시도가 더 느리기 때문에 그 낭비가 배로 늘어난다. 드래프트 티어 반복은 저렴한 결정—주체 명확성, 비트 수, 카메라 방향—을 앞으로 당기고 비싼 티어는 확인용으로 남긴다.

한 가지 주의: 세부 디테일을 판단할 수 없을 만큼 낮은 티어로 드래프트하지 마라. 샷이 작은 소품이나 얼굴 표정에 의존한다면 그 디테일은 더 높은 티어에서만 평가 가능할 수 있으며, 그런 특정 검사는 더 일찍 티어를 올려야 한다.

레시피: 실제로 샷을 바꾸는 카메라 표현

이 가이드에서 하나만 가져간다면 이것을 가져가라: 카메라 표현은 주체에 붙일 수 있는 어떤 형용사보다도 결과에 더 큰 영향을 준다. 주체, 동작, 장면이 완전히 같고 카메라 블록만 다른 두 프롬프트는 두 개의 다른 샷이다. 반면 분위기 형용사 더미만 다른 두 프롬프트는 대개 여전히 같은 샷이다.

그래서 카메라 블록은 레버리지가 가장 높은 슬롯이며, 한 번에 한 구절씩 테스트할 가치가 가장 큰 슬롯이다.

움직임 패턴

CAMERA: static, locked off
CAMERA: slow push in
CAMERA: slow pull out
CAMERA: lateral tracking left to right
CAMERA: handheld follow behind the subject
CAMERA: orbit around the subject, quarter turn

위의 각 항목은 완전하고 바로 복사할 수 있는 카메라 블록이다. 의도적으로 짧게 썼다. 장황한 카메라 문장은 종종 서로 경쟁하는 두 지시를 담고(push in while orbiting), 충돌할 때 출력은 반쯤 무작위로 그중 하나를 고른다.

앵글 패턴

CAMERA: eye level, medium shot
CAMERA: low angle, close on hands
CAMERA: high angle, wide, subject small in frame
CAMERA: over-the-shoulder from behind the subject

앵글이 바로 프레이밍 의도가 있는 곳이다. “Close on hands”와 “subject small in frame”은 분위기가 아니다—관객이 무엇을 볼 수 있는지에 대한 결정이며, cinematic보다 샷을 훨씬 크게 바꾼다.

페이스 패턴

CAMERA: unhurried, deliberate movement
CAMERA: brisk, follows the action closely
CAMERA: settles and holds on the final beat

페이스는 동작 블록이 아니라 카메라 블록에 속한다. 카메라가 어떻게 행동하는지를 서술하며, 긴 샷이 떠다니지 않고 짜임새 있게 보이도록 만드는 가장 깔끔한 수단이다.

한 번에 한 구절만 교체하라

카메라 표현을 읽을 수 있게 만드는 방법:

1. 주체, 동작, 장면, 길이를 고정한 기본 프롬프트를 쓴다.
2. CAMERA: static, locked off로 이 기본 프롬프트를 실행한다.
3. 카메라 줄만 바꾼다—실행마다 한 곳만 교체한다.
4. 각 실행의 클립을 보관하고 사용한 카메라 구절로 라벨을 붙인다.

네다섯 번 실행하면 개인용 구절 사전이 생긴다: slow push in이 당신의 주체와 당신의 장면에서 무엇을 하는지 알게 되며, 이는 어떤 일반 목록보다 가치 있다. 프로젝트마다 한 번씩 하면 이 구절 사전은 이후의 모든 샷에 이어진다.

두 가지 실패 모드

• 지시 중첩. 짧은 클립에 push in, then orbit, then pull out을 쓰는 것은 길이에 담을 수 없는 세 개의 카메라 움직임을 요구하는 것이다. 한 샷에는 움직임 하나만.
• 형용사로 대체하기. 분위기 단어(dramatic, dynamic, epic)를 카메라 움직임 대신 쓰는 것은 카메라를 지정하지 않은 것이다. 카메라 블록에 카메라가 어디에 있고 무엇을 하는지 말하는 내용이 없다면, 가장 중요한 슬롯을 비워둔 것이다.

실제 출력을 임베드하고 비교하라

레시피는 버전 B가 버전 A를 이기는지 판단할 수 있을 때만 유용하다. 이를 위해서는 테스트 하네스—출력을 만들고 나열해, 비교가 느낌이 아니라 기계적으로 이루어지게 하는 작고 지루한 루틴—가 필요하다.

도구가 필요한 것이 아니라 규율과 폴더 하나가 필요하다.

테스트 하네스, 다섯 단계

1. 테스트하지 않는 모든 것을 고정하라. 이번 실험에서 변하지 않는 주체, 동작, 장면, 길이 블록을 담은 baseline.md를 작성하라. 배치의 모든 실행은 이 블록들을 그대로 복사한다.
2. 변수를 명시하라. 실행마다 슬롯 하나만 바꿔라. 카메라 표현을 테스트한다면 파일 간에 다른 것은 카메라 줄 하나뿐이어야 한다.
3. 배치를 생성하라. 모든 변형을 같은 드래프트 티어, 같은 길이로 실행해 비교가 공정하도록 하라.
4. 나란히 배열하라. 매번 같은 순서로 클립을 연속 재생하거나 간단한 그리드로 나란히 놓아라. 순서가 중요하다—위치가 여러 번의 시청에서 안정적일 때 눈이 비교하기 쉽다.
5. 각 변형의 결론을 기록하라. 변형마다 한 문장: 무엇을 바꿨는지, 원하는 변경이었는지, 유지할 것인지.

비교할 때 볼 것

• 비트 완전성 — 동작 목록의 모든 비트가 순서대로 나타났는가?
• 카메라 가독성 — 설명 없이도 관객이 카메라 움직임을 서술할 수 있는가?
• 주체 일관성 — 실행 간에 주체가 여전히 같은 주체 블록으로 식별 가능한가?
• 비의도적 변경 — 카메라 구절을 교체했는데 장면이 조용히 바뀌었는가? 이는 블록 간 누출의 징후다.

이 마지막 점검이 테스트 하네스의 진짜 보상이다. 블록이 깨끗하면 슬롯 하나를 바꿀 때 한 가지만 바뀐다. 블록이 누출되면 단일 시청으로는 결코 알아차릴 수 없는 간섭이 생기며, 이 간섭이 프롬프트 반복을 운에 맡기는 것처럼 느끼게 만드는 원인이다.

테스트 하네스를 작게 유지하라

네다섯 개의 변형이면 결정을 내리기에 충분하다. 더 큰 배치는 주의를 희석하고 훑어보게 만든다. 첫 배치에서 결론이 나지 않았다면, 보통 답은 당신이 고른 변수가 너무 미세했기 때문이지 스무 번 더 실행해야 해서가 아니다.

마지막으로 결론을 레시피 파일에 되먹여라. 이긴 카메라 구절은 기준선 템플릿으로 승격되어야 하며, 그래야 같은 것을 반복해서 재발견하지 않는다.

반복 가능한 프롬프트 반복 워크플로우

아래는 앞선 레시피들로 조립한 전체 순환이다. 의도적으로 전혀 화려하지 않으며, 바로 이것이 프롬프트 라이브러리가 계속 발전하는지 아니면 서서히 표류하는지를 결정한다.

1단계 — 블록 초안 작성

템플릿을 한 번 채워라: 주체, 동작 비트, 장면, 카메라, 길이, 해상도. 다듬지 마라. 첫 버전의 존재 이유는 수정되기 위함이다.

2단계 — 저렴하게, 짧게 실행하라

드래프트 티어에서 짧은 길이로 생성하라. 얻는 것은 구도, 비트 수, 카메라 가독성에 대한 정보—그것뿐이다. 변동 슬롯 하나씩만 다른 두세 변형을 실행하라.

3단계 — 승자를 선택하고 잠가라

어떤 변형이 원하는 효과를 냈다면 그 정확한 텍스트를 locked/ 파일로 복사하라. 잠금은 그 파일을 더 이상 편집하지 않는다는 뜻이다. 이후 실험은 그 파일에서 분기하지, 그 위에서 제자리 수정하지 않는다. 이 작은 습관이 가장 흔한 퇴화—계속 제자리에서 미세 조정하다 좋은 버전을 잃는 것—을 막는다.

4단계 — 최종 설정으로 승격하라

길이와 해상도만 전달 값으로 바꾸고 렌더하라. 최종 결과가 드래프트와 의미 있는 차이를 보이면 그 차이를 기록하라—이 프롬프트가 해상도나 길이에 민감하다는 뜻이며, 다음 프로젝트 전에 어느 슬롯이 취약한지 알고 싶을 것이다.

5단계 — 모든 것을 기록하라

모든 실행에는 기록이 있다. 로그는 이 워크플로우에 복리 효과를 만드는 산물이다. 최소 필드는 다음과 같다:

id: shot03_v2
template: studio-ceramics
variable_tested: camera
prompt: <full prompt text, verbatim>
duration: <value used>
resolution: <tier used>
verdict: <one sentence — what changed, keep or discard>
artifact: <clip path>

로그를 신뢰할 수 있게 만드는 세 가지 규칙. 프롬프트는 축자 원문만 기록하라—의역은 재현할 수 없다. 기록마다 변수는 하나만—그렇지 않으면 로그가 “왜 이것이 효과가 있었는가?”에 답할 수 없다. 모든 기록에 클립 경로를 붙여라—산출물 없는 결론은 의견일 뿐이다.

6단계 — 구절 사전으로 정련하라

몇 프로젝트마다 로그를 읽고 반복해서 이긴 것—카메라 구절, 비트 목록의 형태, 장면 블록—을 공유 구절 사전 파일로 추출하라. 구절 사전은 재사용 가능한 지식이고, 로그는 그 뒤의 증거다.

순서가 중요한 이유

먼저 저렴하게 반복하고, 잠그고, 승격하고, 기록하라: 각 단계는 이전 단계의 규율에 의존한다. 잠금이 없으면 승격은 움직이는 과녁을 테스트한다. 기록이 없으면 잠금에는 근거가 없다. 저렴한 드래프트가 없으면 잠글 만한 가치가 있는 무언가를 만들 만큼 충분한 실행을 감당할 수 없다.

HiAPI.ai의 통합 API로 MiniMax H3 Max 텍스트 투 비디오에 이 순환을 적용하고, 프롬프트 텍스트와 파라미터 값을 자신의 저장소에 보관해 모든 성공이 재현 가능하게 유지되도록 하라.