개발자를 위한 Kandinsky 6.0 Pro 텍스트-투-비디오 프롬프트 레시피

프롬프트에서 길이보다 구조가 중요한 이유

긴 프롬프트는 뭔가 많이 만들어낸 듯한 기분이 듭니다. 빛, 분위기, 배경, 자동차 모델, 하늘 색을 묘사하고 나면—그 결과물은 절반을 무시하거나, 더 나쁘게는 모든 것을 뭉개버린 타협의 산물이 됩니다. kandinsky-6.0-pro/text-to-video 같은 텍스트-투-비디오 모델은 장황함에 보상을 주지 않습니다. 보상을 주는 것은 구조입니다.

구조화된 프롬프트는 자유 형식 문단이 할 수 없는 세 가지를 해냅니다:

• 관심사를 분리합니다. 샷 유형, 피사체 동작, 카메라 동작은 서로 독립된 변수입니다. 이것들이 한 문장에 얽혀 있으면 어느 부분이 나쁜 출력을 초래했는지 알 수 없습니다.
• 비교를 가능하게 합니다. 한 배치의 모든 프롬프트가 동일한 골격을 따르면, 출력의 차이는 실제로 바꾼 부분에 기인한다고 볼 수 있습니다.
• 템플릿화할 수 있습니다. 고정된 슬롯을 가진 프롬프트는 매개변수화되어 프로그래밍 방식으로 생성될 수 있습니다—수동 테스트에서 파이프라인 단계로 넘어가면 이것은 결정적입니다.

이 글에서는 세 부분 레시피를 사용합니다:

[SHOT] + [SUBJECT & ACTION] + [CAMERA]

짧고, 순서가 있으며, 반복 가능합니다. 목표는 적게 쓰기 위해 적게 쓰는 것이 아니라—예측 가능하게 쓰는 것이며, 그래야 동일한 레시피에서 슬롯 하나만 교체해도 다른 영화가 아니라 의미 있는 비교가 가능해집니다. 이후의 모든 내용은 이 골격 위에 쌓입니다: 복사해 붙여넣을 수 있는 템플릿, 카메라 무빙 표현, 반복 루프, 그리고 마지막으로 전체 흐름을 API 호출에 연결하는 부분입니다.

텍스트-투-비디오 프롬프트 레시피의 해부

레시피를 작성하기 전에 각 블록이 하는 역할을 이해하세요.

샷 (Shot)

샷 블록은 프레이밍과 길이의 의도를 설정합니다: 클로즈업, 미디엄 샷, 와이드 설정 샷, 하이 앵글, 로우 앵글. 이것은 프롬프트에서 지렛대 효과가 가장 큰 줄이며, 구도를 고정하기 때문입니다. 샷이 틀리면 다운스트림의 그 무엇도 이 클립을 구할 수 없습니다.

한 구절로 유지하세요. Wide establishing shot이 a shot that shows the whole scene from far away so you can see everything in the environment보다 낫습니다.

피사체와 동작

이 블록은 무엇이 움직이고 어떻게 움직이는지를 설명합니다. 피사체에 대해 구체적으로 쓰고, 클립당 하나의 주요 동작만 두세요. 한 프롬프트에 두 개의 경쟁하는 동작이 있으면 보통 둘 다 제대로 하지 못하는 피사체가 나옵니다.

• 좋음: a cyclist rides left to right across frame
• 위험: a cyclist rides while waving and the camera zooms and the crowd cheers

두 번째 동작이 필요하다면 그것이 별도의 클립에 속해야 하는지 자문하세요.

카메라 무빙 (Camera)

카메라 무빙 표현은 모델에게 시점이 어떻게 동작할지 알려줍니다: 정지, 팬, 틸트, 돌리인, 오빗. 이것은 개발자가 가장 자주 생략하는 블록이며—한 배치의 클립이 일관되게 느껴지는지에 가장 큰 영향을 미치는 블록이기도 합니다. 짧고 명령형인 표현이 가장 잘 작동합니다; 아래의 전용 섹션을 참고하세요.

생략해야 할 것

레시피는 긴 형용사 나열, 감정적 서술, 산문 형식의 부정 지시를 의도적으로 생략합니다. 어떤 세부 사항이 샷, 피사체, 카메라 무빙 중 어디에도 매핑되지 않는다면, 이 단계에서는 보통 노이즈입니다. 핵심 레시피가 안정적인 결과를 낼 때만 다시 추가하세요.

유용한 사고 모델: 각 블록은 같은 출력 프레임에 서로 다른 방향에서 입력을 제공합니다—구도, 움직임, 시점. 한 블록이 모호하면 모델이 자신의 사전 지식으로 빈틈을 채우며, 불일치가 바로 그곳에서 조용히 나타납니다.

흔한 샷을 위한 복사해 붙여넣을 수 있는 레시피

모든 템플릿은 [SHOT] + [SUBJECT & ACTION] + [CAMERA]를 따릅니다. 대괄호 안의 값을 바꾸고 구조는 그대로 유지하세요.

제품 히어로 샷

Close-up product shot of a [PRODUCT] rotating slowly on a seamless surface, soft studio light, camera locked off, shallow depth of field

이커머스 루프 비디오와 앱 히어로 클립에 사용합니다. 회전을 유일한 움직임으로 유지하세요.

환경 설정 샷

Wide establishing shot of [ENVIRONMENT] at [TIME OF DAY], light haze in the air, slow forward dolly

오프닝과 챕터 전환에 적합합니다. 돌리인이 깊이를 더하지만 초점을 빼앗지는 않습니다.

캐릭터 또는 인물 동작

Medium shot of [PERSON OR FIGURE] [PRIMARY ACTION], natural pace, camera static at eye level

동작은 하나만 하세요. 인물이 먼저 들어온 뒤 행동해야 한다면 두 클립으로 나누세요.

추상 또는 배경 루프

Full-frame abstract shot of [SHAPE OR PATTERN] drifting slowly, [COLOR PALETTE], gentle camera drift

이음새 없는 루프 배경을 위해 설계되었습니다. 강한 방향성 움직임을 피하면 루프 지점이 덜 눈에 띕니다.

UI 또는 화면 스타일 소재

Straight-on shot of [DEVICE OR SURFACE] displaying [CONTENT], subtle parallax, camera locked, no rotation

카메라를 고정하면 텍스트와 인터페이스 요소가 안정적으로 유지됩니다—그 위에 실제 UI를 합성할 경우 이것이 결정적입니다.

자연과 텍스처 디테일

Close-up shot of [NATURAL ELEMENT] moving gently in [CONDITION], macro framing, slow lateral drift

배치 내에서 드물게 사용하세요; 텍스처 클립은 모델 차이가 가장 뚜렷하게 드러나는 곳이므로 비교할 때는 한 그룹 내에서 카메라 무빙을 완전히 동일하게 유지하세요.

명확하고 읽기 쉬운 카메라 무빙과 움직임 표현

카메라 무빙 언어는 프롬프트가 조용히 어긋나는 지점입니다. 모델은 서술적 산문보다 짧고 관습적인 표현에 더 잘 반응하며, 한 배치 내의 일관성이 문장의 멋보다 중요합니다.

작은 어휘 목록을 사용하세요

고정된 카메라 무빙 용어 집합을 골라 모든 곳에서 반복하세요. 실행 가능한 입문 세트:

• camera static / camera locked off
• slow forward dolly / slow backward dolly
• pan left / pan right
• tilt up / tilt down
• orbit around subject
• handheld drift

모델이 이를 처리할 수 있다는 것을 이미 검증하지 않았다면 "dolly-zoom with a slight arc"처럼 복합 운동을 발명하는 것을 삼가세요. 모든 이례적인 구절은 테스트되지 않은 변수입니다.

피사체 움직임과 카메라 무빙을 분리하세요

이것은 서로 다른 지시이며 서로 다른 슬롯에 놓여야 합니다. A cyclist rides left to right는 피사체를 설명하고, pan right는 카메라를 설명합니다. the camera follows the cyclist라고 쓰면 둘을 합쳐버려 모델이 어느 쪽을 우선해야 할지 불분명해집니다.

속도를 지정하세요

한 단어—slow, steady, brisk—로 보통 충분합니다. 속도 단어는 움직임이 클립 길이 중 얼마나 소비하는지 고정해 주며, 고정 길이 클립을 이어 붙여 편집해야 할 때 중요합니다.

한 배치 내에서 표현을 일정하게 유지하세요

비교를 위해 열 가지 변형을 생성한다면 카메라 무빙 줄을 바이트 단위로 완전히 동일하게 유지하세요. 실행 간에 피사체와 카메라 무빙을 동시에 바꾸면 차이를 어느 쪽에도 귀속시킬 수 없습니다. 임시 프롬프트 테스트에서 가장 흔한 실수입니다.

긍정적이고 관찰 가능한 지시를 우선하세요

카메라가 무엇을 피하는지가 아니라 무엇을 하는지 설명하세요. Camera static은 명확한 지시이지만, camera doesn't shake는 모델에게 부정을 추론하도록 요구합니다. 긍정적 표현은 나중에 프롬프트 라이브러리를 검색하기도 더 쉽게 합니다.

레시피를 망가뜨리지 않고 조정하기

레시피는 고정 자산이 아니라 출발점입니다. 규율은 그것을 어떻게 바꾸는지에 있습니다.

실행마다 슬롯 하나만 바꾸세요

기초 레시피를 하나 고르고, 기준선을 생성한 뒤, 블록 하나—샷, 피사체, 카메라 무빙—만 수정하고 다시 생성하세요. 샷과 피사체를 동시에 바꾸면 어떤 조정이 효과가 있었는지 알 수 없습니다. 이 제약은 처음에는 느리게 느껴지지만 라이브러리가 커지면 많은 시간을 절약해 줍니다.

모든 것을 기록하세요

실행마다 기록하세요:

• 수정되지 않은 전체 프롬프트 문자열
• 어느 슬롯이 무엇으로 바뀌었는지
• 짧은 판정(보관 / 폐기 / 재검토)
• 눈에 띄는 아티팩트나 레시피로부터의 이탈

일반 텍스트 파일이나 스프레드시트 열 하나면 충분합니다. 핵심은 3주 전에 마음에 들었던 프롬프트가 기억으로 재구성되는 것이 아니라 재현 가능하다는 것입니다.

레시피에 버전을 부여하세요

프롬프트 템플릿을 코드처럼 다루세요. 식별자(product_hero_v1, establishing_city_v2)를 부여하고 버전마다 변경 로그 한 줄을 남기세요. 다운스트림 클립이 이상해 보일 때 그것을 만들어낸 정확한 레시피를 체크아웃할 수 있습니다.

레시피가 언제 완성되었는지 판단하세요

동일한 매개변수로 연속 세 번 실행한 출력이 모두 수용 가능하다면 레시피는 안정된 것입니다. 이 시점에서 그것을 동결하고 태그를 붙인 뒤 다음 샷 유형으로 넘어가세요. 작동하는 레시피를 계속 조정하는 것은 안정성을 미미한 이득과 맞바꾸는 일입니다.

적극적으로 가지치기하세요

작성한 대부분의 레시피는 결국 폐기됩니다. 안정되지 못한 것은 삭제하거나 보관하세요—관리되지 않는 미완성 템플릿 저장소는 신뢰하는 작은 저장소보다 못합니다.

레시피를 파이프라인에 통합하기

수동 반복은 탐색에 적합합니다. 프로덕션에는 안정적인 엔드포인트를 통해 전송되는 매개변수화되고 버전 관리되는 프롬프트가 필요합니다.

템플릿 매개변수화

레시피를 완성된 문자열이 아니라 명명된 슬롯을 가진 템플릿으로 저장하세요:

{
  "id": "product_hero_v1",
  "template": "Close-up product shot of a {{product}} rotating slowly on a seamless surface, soft studio light, camera locked off, shallow depth of field"
}

렌더링은 간단합니다: 호출 시점에 {{product}}를 치환하세요. 템플릿은 고정된 채로 유지되고 슬롯 값만 바뀝니다. 이는 수동 테스트에서 한 번에 변수 하나만 바꾸는 규율과 같으며, 단지 프로그래밍 방식으로 적용될 뿐입니다.

하나의 엔드포인트에 유지하세요

실험과 프로덕션 트래픽을 모두 동일한 모델 엔드포인트 kandinsky-6.0-pro/text-to-video로 라우팅하세요. 테스트 호출과 릴리스 호출이 같은 API에 도달하면 탐색에서 효과가 있던 프롬프트가 프로덕션에서도 똑같이 작동합니다. 단계 간에 인터페이스를 바꾸는 것은 "어제는 되던데" 버그의 흔한 원인입니다.

호출 지점에서 버전 관리와 기록을 하세요

생성된 모든 클립은 레시피 ID, 렌더링된 프롬프트, 타임스탬프로 추적할 수 있어야 합니다. 이것을 출력 참조와 함께 기록하세요. 클립에 문제가 표시될 때 "어느 레시피 버전과 어떤 매개변수가 이것을 만들었는가?"를 포렌식 없이 답할 수 있기를 원할 것입니다.

사려 깊게 배치 생성하세요

변형을 생성할 때는 한 배치에서 슬롯 하나만 바꾸고 카메라 무빙 줄을 포함해 나머지는 모두 일정하게 유지하세요. 이렇게 하면 배치의 비교 가능성이 유지되고 자동 검토나 수동 표본 검사가 훨씬 빨라집니다.

결과를 라이브러리에 다시 통합하세요

프로덕션에서 안정된 레시피는 태그를 붙여 재사용해야 합니다. 시간이 지나면 라이브러리는 팀의 실제 프롬프트 자산이 됩니다: 일회성 문자열 폴더가 아니라 검증되고 버전 관리되는 빌딩 블록의 집합입니다.

템플릿이 매개변수화되고 버전 관리되면 동일한 레시피가 수정 없이 수동 테스트와 프로덕션 배치를 모두 구동할 수 있습니다.

흔한 실패 패턴과 그 해석 방법

약한 출력은 대개 무작위가 아닙니다. 증상을 가장 책임질 가능성이 높은 블록에 매핑하고 그 블록만 바꾸세요.

실행 간에 구도가 흔들림

가능한 원인: 샷 블록. 모호하거나 복합적인 프레이밍 구절—a wide shot, somewhat close—은 모델에게 해석의 여지를 줍니다. 단일 표준 샷 용어로 좁히고 배치 내에서 일정하게 유지하세요.

피사체가 잘못된 행동을 하거나 너무 많이 함

가능한 원인: 피사체와 동작 블록. 한 프롬프트에 여러 동작이 있거나 모호한 동사로 묘사된 동작. 주요 동작 하나로 줄이고 관찰 가능한 언어를 사용하세요.

과도하거나 불규칙한 카메라 움직임

가능한 원인: 카메라 무빙 표현 또는 그 부재. 카메라 무빙 지시가 없으면 모델이 스스로 움직임을 발명합니다. 명시적인 camera static 또는 명명된 운동을 추가하세요; 움직임을 암시하는 산문—the scene sweeps across는 카메라 지시로 읽힙니다—은 제거하세요.

요청하지 않은 세부 사항이 나타남

가능한 원인: 지나치게 긴 프롬프트. 형용사 나열과 정서적 언어는 모델이 빈틈을 채우도록 초대합니다. 레시피를 세 블록으로 줄이고 핵심이 작동하는지 확인한 뒤 세부 사항을 하나씩 다시 도입하세요.

출력이 일관되지만 지루함

가능한 원인: 과도하게 제약된 레시피. 모든 블록이 고정되었는데 결과가 평범하다면 해결책은 보통 완전한 재작성이 아니라 통제된 변화—새로운 카메라 무빙, 새로운 동작—입니다.

결과를 재현할 수 없음

가능한 원인: 프롬프트가 아니라 프로세스 문제입니다. 기록되지 않은 편집, 실행 간에 변경된 카메라 무빙 표현, 또는 프로덕션과 다른 엔드포인트에서의 테스트. 해결책은 앞서 설명한 버전 관리 라이브러리와 단일 엔드포인트 규율입니다.

실패를 이런 식으로 해석하면 모든 나쁜 생성이 전부를 다시 작성해야 할 이유가 아니라 구체적이고 테스트 가능한 가설로 바뀝니다.