flux-3-max 키프레임 기반 동영상 생성 프롬프트 레시피, 바로 복사해 붙여넣기 가능

키프레임 기반 동영상 생성 워크플로가 프롬프트에 기대하는 것

첫 프롬프트를 쓰기 전에 키프레임 기반 동영상 생성 워크플로의 역할 분담을 이해해 두면 큰 도움이 됩니다.

당신은 두 장 이상의 정적 키프레임을 제공합니다. 이들은 앵커입니다. 무엇이 존재하는지, 그것이 화면 어디에 위치하는지, 특정 시점에 장면이 어떤 모습인지를 정의합니다. 모델은 그 사이를 보간합니다. 당신의 텍스트 프롬프트는 움직임 브리핑입니다. 모델에게 한 앵커에서 다음 앵커로 어떻게 이동할지 알려줍니다 — 무엇이 움직이는지, 어느 방향으로 움직이는지, 대략 어떤 강도로 움직이는지, 그리고 카메라가 어떻게 움직이는지.

이 역할 분담에는 실질적인 결과가 따릅니다. 프롬프트가 세상을 다시 설명할 필요가 없습니다. 키프레임에서 명확히 보이는 모든 것은 이미 확립되어 있습니다. 프롬프트는 정적 이미지가 표현할 수 없는 것 — 움직임, 리듬, 카메라 의도, 그리고 앵커 사이의 모든 상태 변화(문이 열림, 피사체가 돌아섬, 빛이 변함) — 에 집중해야 합니다.

유용한 사고 모델: 두 장의 키프레임을 아무 설명 없이 인간 편집자에게 넘긴다면, 그들은 "우리가 A에서 B로 어떻게 가나요?"라고 물을 것입니다. 당신의 프롬프트는 이 질문에 대한 답입니다. 그 밖의 모든 것 — 색 보정, 의상 디테일, 세트 디자인 — 은 텍스트에 형용사를 밀어넣는 것보다 키프레임을 개선하는 편이 훨씬 낫습니다.

이 가이드의 나머지 부분에서는 이 틀을 기억하세요. 아래의 모든 레시피는 같은 사고를 중심으로 구성됩니다: 키프레임은 앵커링을, 텍스트는 움직임 안내를 담당합니다.

키프레임 설명의 해부 구조

안정적인 출력은 안정적인 입력 구조에서 시작됩니다. 각 키프레임을 고정된 순서로 설명하면, 어딘가 어긋났을 때 어느 줄을 확인해야 하는지 정확히 알 수 있습니다.

각 키프레임에 다음 네 부분 순서를 사용하세요:

1. 피사체

누가 또는 무엇이 초점이며, 어떤 상태인지. 수와 자세를 구체적으로: "혼자 탄 자전거 기수, 똑바로 앉아 두 손으로 핸들 잡음"이 "자전거 타는 사람"보다 낫습니다.

2. 장면과 환경

피사체가 어디에 있는지, 그리고 위치를 잡는 데 필요한 최소한의 맥락: "젖은 아스팔트 도로 위, 뒤로 낮은 건물들." 보통 한 절이면 충분합니다.

3. 구도와 카메라 위치

해당 키프레임의 샷 크기와 각도: "중간 샷, 눈높이, 피사체가 화면 왼쪽으로 살짝 치우침." 이것은 동영상이 보간하여 도달할 지점이므로 중요합니다.

4. 빛과 분위기

시간대, 빛의 방향, 날씨, 안개. "저녁 역광, 부드러운 안개"가 다섯 개의 감성 형용사보다 실행 가능성이 높습니다.

몇 가지 경험 법칙:

• 모든 키프레임에서 동일한 순서를 유지하세요. 키프레임 A가 피사체로 시작하는데 키프레임 B가 빛으로 시작하면, 편집은 추측이 됩니다.
• 보이는 것만 설명하세요. 추측성 배경 이야기는 모델이 활용할 수 없는 노이즈만 더합니다.
• 각 부분당 한 문장. 한 부분에 두 문장이 필요하다면, 그것은 두 개의 생각이 주도권을 다투고 있을 가능성이 큽니다.
• 키프레임 간에 어휘를 재사용하세요. A에서 "중간 샷"이라면 B에서도 "중간 샷"이라 하고, "중거리 구도"라고 하지 마세요.

이 구조는 의도적으로 지루합니다. 지루한 구조가 바로 흥미로운 부분 — 움직임 — 을 디버깅 가능하게 만드는 이유입니다.

카메라 움직임과 움직임의 표현

카메라와 움직임의 표현은 대부분의 프롬프트가 실수하는 지점이며, 보통 한 문장에서 너무 많은 일을 하려 하기 때문입니다.

규칙은 이것입니다: 짧게, 단일 의도, 독립 절.

좋은 움직임 표현은 하나의 움직임만 명명하고 그것을 완성하게 둡니다:

• "카메라가 천천히 푸시인한다."
• "카메라가 오른쪽으로 트럭하며 피사체를 중앙에 유지한다."
• "미세한 핸드헬드 드리프트, 줌 없음."
• "피사체가 카메라 쪽으로 돌아서고 멈춘다."

나쁜 움직임 표현은 의도를 쌓아 모델이 타협하게 만듭니다:

• "카메라가 천천히 푸시인하면서 동시에 왼쪽으로 팬하고 살짝 위로 틸트하며, 피사체는 앞으로 걸어가 돌아서고, 동시에 미세한 줌이 있다."

그 문장은 다섯 개의 지시를 담고 있습니다. 어떤 단일 짧은 영상도 그 모두를 깔끔하게 만족할 수 없으므로, 당신은 탁한 평균값을 얻습니다. 작업을 나누세요: 샷을 이끄는 움직임을 골라내고 나머지는 키프레임이 처리하게 하세요.

보상이 따르는 실용적 관례 몇 가지:

• 카메라와 피사체를 분리하세요. "카메라는 정지한다. 피사체는 왼쪽에서 오른쪽으로 걸어간다." 두 절, 두 움직임 주인.
• 속도어를 의식적으로 사용하세요. "천천히", "매끄럽게", "빠르게"는 유용합니다. "극적으로"와 "영화적으로"는 속도어가 아닙니다 — 소망입니다.
• 중요할 때 종료 상태를 명명하세요. "피사체가 화면을 가득 채울 때까지 푸시인"은 모델에게 목표를 줍니다.
• 부정 표현은 약합니다. "카메라 움직임 없음"보다 "정지 카메라"를 우선하세요.

하나만 기억한다면: 한 절, 한 의도. 영상이 어긋날 때 가장 먼저 확인할 것은 한 움직임 절이 암묵적으로 두 개의 움직임을 담고 있는지입니다.

복사해 붙여넣을 수 있는 레시피 템플릿

아래는 범용 골격입니다. 복사하고, 슬롯을 채우고, 라벨을 유지하세요 — 라벨은 모델이 아니라 당신을 위한 것이므로, 원한다면 전송 전에 제거해도 됩니다.

[KEYFRAME A]
Subject: {{subject_a}}
Scene: {{scene_a}}
Framing: {{framing_a}}
Light: {{light_a}}

[KEYFRAME B]
Subject: {{subject_b}}
Scene: {{scene_b}}
Framing: {{framing_b}}
Light: {{light_b}}

[MOTION]
Camera: {{camera_move}}
Subject: {{subject_move}}
Pacing: {{pacing}}

짧은 제품 스타일 영상에 사용한 채워진 예시:

[KEYFRAME A]
Subject: a single ceramic mug, handle facing right, steam rising
Scene: on a wooden desk, blurred window behind
Framing: close-up, slightly above eye level, mug centered
Light: soft morning side light from the left

[KEYFRAME B]
Subject: the same ceramic mug, steam thinner, handle facing right
Scene: same wooden desk, window still blurred
Framing: close-up, slightly above eye level, mug centered
Light: slightly warmer morning light from the left

[MOTION]
Camera: slow push in
Subject: steam drifts upward and fades
Pacing: steady, unhurried

두 슬롯은 각별히 주의해야 합니다. {{camera_move}}는 당신의 짧은 목록 중 단일 움직임이어야 합니다. {{pacing}}은 전체 짧은 영상의 에너지를 설정합니다 — 결과가 너무 빠르거나 너무 느리게 느껴질 때 가장 저렴한 조정 손잡이입니다.

이렇게 채워진 템플릿을 보관하는 작은 라이브러리를 유지하세요. 슬롯이 명확하고 충분히 검증된 몇 개의 골격은 일회성으로 손수 쓴 프롬프트를 거의 항상 능가합니다. 변수가 격리되고 가시적으로 유지되기 때문입니다.

다양한 움직임 의도를 위한 레시피 변형

템플릿은 그대로 유지되고 움직임 블록만 바뀝니다. 아래는 동일한 키프레임 블록 위에 구축된 세 가지 변형이며, 각각 다른 의도를 겨냥합니다.

변형 1: 공개(카메라가 일함)

[MOTION]
Camera: slow push in from medium to close-up
Subject: holds pose, breathing only
Pacing: slow, even

피사체 자체가 보상이고 화면을 그것으로 조여오고 싶을 때 사용하세요. 피사체 움직임을 최소로 줄여 카메라 움직임이 명확히 전달되게 합니다.

변형 2: 가로지르기(피사체가 일함)

[MOTION]
Camera: static, locked off
Subject: walks left to right across frame, steady stride
Pacing: moderate, continuous

키프레임이 경로나 위치 변화를 설명할 때 사용하세요. 카메라를 고정하면 가로지르기가 명확히 읽힙니다. 서로 경쟁하는 두 움직임은 그것을 흐리게 만듭니다.

변형 3: 분위기(환경이 일함)

[MOTION]
Camera: very slow lateral drift
Subject: mostly still, slight sway
Pacing: slow, ambient

빛, 안개, 입자가 영상을 이끄는 설정 샷과 배경에 사용하세요. 피사체는 화면을 앵커링하고 환경이 변화를 제공합니다.

무엇이 변하지 않았는지 주목하세요: 키프레임 설명. 이것이 구조의 의미입니다. 앵커가 안정되면 움직임 의도를 전환하는 것은 재작성이 아니라 두 줄 편집입니다 — 이로써 같은 장면에서 짧은 영상을 A/B 테스트하는 것이 실제로 가능해집니다.

실패 모드와 어긋난 영상을 디버깅하는 방법

영상이 어긋날 때 프롬프트를 서둘러 다시 쓰지 마세요. 어긋남은 정보입니다. 한 번에 변수 하나만 바꾸고, 다시 실행하고, 그다음에 다른 것을 건드리세요.

아래는 흔한 실패 모드와 각각의 단일 변수 수정 방법입니다.

영상이 혼란스럽거나 "평균화"된 느낌

원인: 한 절에 두 개 이상의 움직임 의도가 있음. 수정: 움직임 블록을 별도 줄로 나누고, 주도적 움직임 외의 모든 것을 삭제하세요.

피사체가 변형되거나 정체성을 잃음

원인: 텍스트가 피사체를 과도하게 설명하여 키프레임과 경쟁함. 수정: 두 키프레임의 피사체 줄을 수, 자세, 하나의 결정적 디테일로 간소화하세요. 정체성은 앵커가 담당하게 하세요.

카메라가 움직이지 말라고 했는데 움직임

원인: 다른 곳에 암묵적 움직임이 있거나, 리듬 단어가 에너지를 암시함. 수정: "카메라는 정지한다"를 독립 절로 쓰고, 리듬 단어를 부드럽게 하세요.

움직임이 너무 빠르거나 너무 느림

원인: 리듬이 명시되지 않았거나 모순됨. 수정: {{pacing}}만 바꾸세요. 다시 실행하세요. 같은 라운드에서 카메라 절을 조정하지 마세요.

영상이 두 번째 키프레임을 무시함

원인: 키프레임 B가 너무 많은 차원에서 동시에 A와 벗어남. 수정: 두 설명을 줄별로 비교하고, 가장 중요하지 않은 줄에서 차이를 줄이세요. 한 줄을 바꾸고, 다시 실행하고, 반복하세요.

규율은 간단합니다: 반복마다 변수 하나, 그리고 무엇을 바꿨는지 짧게 기록하세요. 서너 라운드 후에는 보통 문제의 그 줄을 찾아내고, 레시피 자체에 대해 재사용할 수 있는 무언가를 배우게 됩니다.

버전 관리와 팀 내 레시피 공유

레시피가 작동하면 그것은 더 이상 프롬프트가 아니라 프로젝트 자산이 됩니다. 자산처럼 다루세요.

가벼운 시스템이면 충분합니다:

• 레시피를 저장소에 보관하세요. prompts/ 디렉터리에 레시피 하나당 파일 하나, 사용하는 코드와 함께 둡니다. 레시피와 요청 코드를 함께 버전 관리하세요.
• 장면이 아니라 의도로 이름을 붙이세요. reveal-product-closeup.md는 찾을 수 있지만, prompt-final-v3-really.md는 아닙니다.
• 골격과 채우기를 분리하세요. 템플릿은 한 번만 저장하고, 채워진 예시는 그에 대한 작은 차이로 저장합니다. 이렇게 하면 검토자가 어떤 슬롯이 바뀌었는지 정확히 볼 수 있습니다.
• 무엇을 바꿨고 무엇이 일어났는지 기록하세요. 레시피마다 두 줄짜리 변경 로그 — 바뀐 변수, 관찰된 효과 — 가 긴 산문 설명보다 가치 있습니다.
• 코드를 리뷰하듯 레시피를 리뷰하세요. 동료가 차이를 읽고 영상을 예측할 수 있어야 합니다. 그들이 할 수 없다면, 움직임 절이 너무 많은 일을 하고 있는 것입니다.
• 의식적으로 퇴역시키세요. 레시피가 대체되면 삭제하지 말고 표시하고 대체품에 링크하세요. 그래야 옛 영상이 여전히 재현 가능합니다.

이것은 워크플로에서 영광스럽지 않은 부분이며, 바로 이것이 일관된 영상을 납품하는 팀과 매 티켓마다 프롬프트를 다시 논쟁하는 팀을 가르는 차이입니다. 이 레시피들을 단일 통합 인터페이스를 통해 실행할 준비가 되었다면, 요청을 엔드투엔드로 연결하고 flux-3-max 키프레임 기반 동영상 생성 모델 페이지에서 시작하세요.