숏폼 비디오 도구들은 겉보기에는 종종 단순해 보입니다. 사용자가 이미지를 업로드하고, 문장을 작성하고, 형식을 선택하면 세련된 클립을 받게 됩니다. 하지만 그 인터페이스 뒤에는 프롬프트 엔지니어링 (Prompt Engineering), 입력 유효성 검사 (Input Validation), 모델 선택 (Model Selection), 비동기 생성 (Asynchronous Generation), 피사체 분리 (Subject Isolation), 카메라 계획 (Camera Planning), 후처리 (Post-processing), 품질 점수 산정 (Quality Scoring), 저장 (Storage), 그리고 플랫폼별 내보내기 (Platform-specific Export)를 포함하는 놀라울 정도로 복잡한 미디어 파이프라인이 자리 잡고 있습니다.

이 가이드는 엔지니어링 관점에서 이러한 시스템을 설계하는 방법을 설명합니다.

목표는 또 다른 일반적인 텍ext-to-video 인터페이스를 만드는 것이 아닙니다. 대신, 우리는 더 명확한 의도를 가진 효과에 집중할 것입니다. 즉, 피사체가 보이는 프레임 안, 위, 또는 너머로 움직이는 것처럼 보여 세로형 소셜 비디오에 적합한 3D 브레이크아웃 (3D Breakout) 환상을 만들어내는 것입니다.

여기에 설명된 아키텍처는 제품 공개, 캐릭터 애니메이션, 음식 클립, 앱 홍보, 크리에이터 콘텐츠 및 시각적 실험을 지원할 수 있습니다. 동일한 원칙은 다른 많은 AI 미디어 제품에도 적용됩니다.

1. 모델을 선택하기 전에 시각적 효과를 이해하기

3D 브레이크아웃 비디오가 반드시 진정한 3D 렌더링 (3D Render)인 것은 아닙니다.

많은 경우, 이 효과는 다음과 같은 요소들의 조합을 통해 만들어집니다:

1. 보이는 프레임 또는 화면 경계.
2. 해당 경계 내부에서 시작하는 피사체.
3. 피사체의 일부를 경계 밖으로 이동시키는 움직임.
4. 전경이 프레임과 겹치게 만드는 폐쇄 (Occlusion).
5. 카메라 움직임, 깊이 단서 (Depth Cues), 그림자, 파티클 (Particles) 또는 시차 (Parallax).
6. 몇 초 동안 환상을 유지하는 최종 합성 (Composition).

모델에 피사체의 완전한 3D 메쉬 (3D Mesh)가 필요하지는 않습니다. 모델에는 시청자가 피사체가 프레임 앞의 공간을 차지하고 있다고 믿게 만들 정도의 충분한 시각적 일관성 (Visual Consistency)이 필요합니다.

이러한 차이점은 제품 아키텍처를 변화시키기 때문에 중요합니다. 작업을 제한 없는 비디오 생성으로 취급하는 대신, 제약된 시각적 문법 (Visual Grammar)을 정의할 수 있습니다.

제약된 문법은 프롬프트를 컴파일하기 더 쉽게 만들고, 출력을 평가하기 더 쉽게 만들며, 실패 사례를 분류하기 더 쉽게 만듭니다.

예를 들어, 시스템은 모든 생성물에 다음 사항을 포함하도록 요구할 수 있습니다:

• 하나의 지배적인 피사체 (one dominant subject),
• 하나의 보이는 프레임 (one visible frame),
• 하나의 주요 움직임 방향 (one primary motion direction),
• 하나의 카메라 동작 (one camera behavior),
• 하나의 깊이 강화 효과 (one depth-enhancing effect),
• 하나의 안정적인 종료 포즈 (one stable end pose).

이는 다음과 같은 프롬프트보다 훨씬 제어하기 쉽습니다:

내 제품의 흥미진진한 시네마틱 비디오를 만들어줘.

2. 생성 계약 (Generation Contract) 정의하기

어떠한 AI 제공업체(provider)를 연결하기 전에, 애플리케이션이 원하는 바를 나타내는 내부 계약(contract)을 정의하십시오.

사용자의 원문 텍스트(raw user text)를 비디오 모델에 직접 전달하지 마십시오. 원문 입력은 너무 모호하며, 일반적으로 구도(composition), 타이밍(timing), 움직임(motion), 그리고 부정적 제약 조건(negative constraints)이 결여되어 있습니다.

유용한 TypeScript 계약은 다음과 같은 형태일 수 있습니다:

type AspectRatio = "9:16" | "1:1" | "16:9" | "4:5";
type MotionDirection = "forward" | "upward" | "diagonal" | "sideways";
type CameraMove = "locked" | "push-in" | "pull-back" | "orbit" | "handheld";
...

이 객체는 사용자 인터페이스(UI)와 사용 중인 생성 제공업체 사이의 안정적인 경계가 됩니다.

또한 지원되지 않는 조합을 검증할 수 있는 공간을 제공합니다. 예를 들어, 공격적인 궤도(orbit) 움직임과 여러 개의 움직이는 물체가 포함된 10초 길이의 매크로 샷(macro shot)은 빠른 모델(fast model)에게 너무 불안정할 수 있습니다. 백엔드(backend)에서 생성 전에 요청을 단순화할 수 있습니다.

이 계약은 제공업체의 이식성(portability)에도 도움이 됩니다. 모델이 API를 변경하더라도 애플리케이션 전체가 아닌 어댑터(adapter)만 다시 작성하면 됩니다.

3. 프롬프트 박스가 아닌 프롬프트 컴파일러(Prompt Compiler) 구축하기

강력한 AI 비디오 제품은 채팅창보다는 컴파일러(compiler)처럼 동작합니다.

사용자는 의도(intent)를 제공합니다. 애플리케이션은 그 의도를 구조화된 시각적 계획으로 번역합니다.

프롬프트 컴파일러는 6개의 레이어(layer)로 구성될 수 있습니다.

레이어 1: 피사체 정체성 (Subject identity)

구체적인 시각적 속성을 사용하여 주요 피사체를 설명합니다.

약한 예:

신발.

더 나은 예:

조각된 폼 솔(foam sole), 검은색 사이드 스트라이프, 반사되는 신발끈, 그리고 깔끔한 스튜디오 마감이 특징인 흰색 퍼포먼스 스니커즈.

레이어 2: 시작 구도 (Starting composition)

피사체가 어디에서 시작하는지 설명합니다.

스니커즈는 어두운 받침대 위에 놓인 세로형 스마트폰 화면 중앙에 위치합니다.

레이어 3: 브레이크아웃 액션 (Breakout action)

정확한 착시 효과를 설명합니다.

스니커즈가 카메라를 향해 가속하며 유리 경계면을 통과하고, 뒤꿈치는 화면 안에 일부 남아 있는 상태로 휴대폰 프레임 너머로 뻗어 나옵니다.

레이어 4: 카메라 동작 (Camera behavior)

하나의 카메라 움직임을 선택합니다.

카메라는 안정적인 프레이밍과 함께 미세한 푸시인 (push-in) 동작을 수행합니다.

레이어 5: 깊이 단서 (Depth cues)

공간적 분리를 강화하는 효과를 추가합니다.

작은 유리 입자, 접촉 그림자 (contact shadows), 얕은 피사체 심도 (shallow depth of field), 그리고 전경 모션 블러 (foreground motion blur)가 깊이감을 강조합니다.

레이어 6: 안정성 제약 사항 (Stability constraints)

변하지 말아야 할 사항을 명시적으로 기술합니다.

신발의 디자인, 로고 배치, 밑창 모양, 색상 및 재질의 외관을 유지하세요. 중복된 신발, 왜곡된 신발끈, 텍스트, 여분의 팔다리 또는 갑작스러운 장면 전환이 없어야 합니다.

컴파일러 함수가 이러한 레이어들을 조립할 수 있습니다:

function compilePrompt(input: BreakoutVideoRequest): string {
  const attributes = input.subject.keyAttributes.join(", ");
  const negatives = input.negativeConstraints.join(", ");
...

다중 장면 생성 (multi-scene generation)의 경우, LLM이 엔티티 (entities), 위치, 배경 및 일관성 그룹 (consistency groups)을 포함하는 장면 계획을 먼저 생성할 수 있습니다. LLM 가이드 비디오 계획 (LLM-guided video planning)에 관한 연구는 왜 명시적인 계획이 레이아웃을 제어하고 장면 전반에 걸쳐 엔티티를 보존하는 데 가치가 있는지를 보여줍니다.

짧은 브레이크아웃 클립의 경우, 보통 여러 장면이 필요하지는 않습니다. 하지만 동일한 계획 아이디어로부터 이득을 얻을 수 있습니다. 5초짜리 클립을 단계별 타임라인으로 취급하세요.

0.0s ~ 1.0s: 프레임 내부에 피사체 설정
1.0s ~ 2.5s: 경계면을 향해 가속
2.5s ~ 4.0s: 프레임을 통과하여 최대 깊이감 생성
...

이 타임라인은 지원되는 경우 제공자 프롬프트 (provider prompt)에 포함될 수 있으며, API가 키프레임 (keyframes)을 허용하는 경우 키프레임으로 변환될 수 있습니다.

4. 텍스트 투 비디오(Text-to-Video)와 이미지 투 비디오(Image-to-Video) 중 선택

텍스트 투 비디오 (Text-to-video)는 사용자가 아이디어만 가지고 있을 때 유용합니다.

이미지 투 비디오 (Image-to-video)는 정체성 (identity)이 중요할 때 대개 더 효과적입니다.

제품 콘텐츠의 경우, 입력 이미지에는 형태, 로고 배치, 패키징, 색상, 재질과 같은 중요한 정보가 담겨 있습니다. 순수한 텍스트 프롬프트 (text prompt)로 이러한 특징들을 근사치로 구현할 수는 있지만, 출력물이 실제 제품을 나타내야 하는 경우에는 근사치만으로는 충분하지 않습니다.

실용적인 파이프라인은 두 가지 모드를 모두 지원할 수 있습니다:

사용자가 이미지가 없는 경우
    -> 참조 이미지 (reference image) 생성
    -> 사용자가 승인하거나 재생성하도록 함
...

이미지 우선 (image-first) 접근 방식은 시스템에 결정론적인 체크포인트 (deterministic checkpoint)를 제공하기도 합니다. 만약 참조 이미지가 잘못되었다면, 비디오 생성 비용을 지불하기 전에 이를 수정할 수 있습니다.

이 패턴은 시작 프레임의 구도 (composition)가 중요한 브레이크아웃 효과 (breakout effect)에 특히 유용합니다. 피사체, 프레임, 조명, 환경을 포함하는 정지 이미지를 만든 다음, 이미지 투 비디오 모델에 특정 움직임을 애니메이션화하도록 요청할 수 있습니다.

이미지 생성 시스템을 비디오로 확장하는 기술들은 종종 문맥 (context)과 피사체의 외형을 보존하기 위해 모션 다이내믹스 (motion dynamics)와 프레임 간 메커니즘 (cross-frame mechanisms)을 추가합니다. 제품 엔지니어들이 얻을 수 있는 더 넓은 교훈은 시간적 일관성 (temporal consistency)을 위해서는 명시적인 처리가 필요하다는 점입니다. 단순히 첫 번째 프레임이 좋아 보인다고 해서 일관성이 보장될 것이라고 가정해서는 안 됩니다.

5. 모델에 도달하기 전에 입력값 정규화하기 (Normalize Inputs Before They Reach a Model)

입력값 검증 (input validation)은 보안 요구 사항일 뿐만 아니라, 출력 품질에 직접적인 영향을 미칩니다.

업로드된 이미지에 대해 다음 사항을 검사하십시오:

• MIME 타입 (MIME type),
• 파일 시그니처 (file signature),
• 크기 (dimensions),
• 종횡비 (aspect ratio),
• 파일 크기 (file size),
• 색 공간 (color space),
• 알파 채널 (alpha channel),
• 방향 메타데이터 (orientation metadata),
• 피사체 크기 (subject size),
• 배경 복잡도 (background complexity),
• 가시적 텍스트 (visible text),
• 얼굴 수 (face count),
• 가능한 정책 위반 사항 (possible policy violations).

흔히 하는 실수는 기술적으로 유효한 모든 이미지를 수락하는 것입니다. 200x200 크기의 압축된 썸네일은 검증을 통과할 수 있지만, 애니메이션 과정에서는 성능이 저하될 수 있습니다.

품질 임계값 (quality thresholds)을 생성하십시오:

interface ImageQualityReport {
  width: number;
  height: number;
...

subjectCoverage 값은 이미지의 어느 정도가 주요 객체(main object)를 포함하고 있는지를 추정합니다. 만약 제품이 프레임의 5%만을 차지한다면, 애니메이션 모델이 활용할 수 있는 유용한 디테일이 거의 없다는 것을 의미합니다.

객체 탐지기 (object detector), 세그멘테이션 모델 (segmentation model), 또는 시각-언어 모델 (vision-language model)을 사용하여 피사체 범위 (subject coverage)를 추정할 수 있습니다. 온디바이스 (on-device) 또는 브라우저 측 실험의 경우, MediaPipe는 더 큰 미디어 워크플로우의 구성 요소로 사용할 수 있는 크로스 플랫폼 API와 즉시 실행 가능한 비전 태스크 (vision tasks)를 제공합니다.

수락된 입력값은 다음과 같이 정규화 (Normalize) 합니다:

1. EXIF 방향 (orientation) 적용,
2. sRGB로 변환,
3. 불필요한 메타데이터 제거,
4. 지원되는 작업 해상도로 크기 조정 (resizing),
5. 객체 스토리지 (object storage)에 원본 보존,
6. 모델 준비용 파생물 (model-ready derivative) 생성,
7. 중복 제거를 위한 해시 (hash) 기록.

동일한 이미지를 반복해서 재압축하지 마세요. 하나의 정규화된 마스터 (normalized master)를 저장하고, 이를 기반으로 각 제공자별 버전을 파생시키세요.

6. 제공자 불가지론적 라우팅 레이어 (Provider-Agnostic Routing Layer) 생성

AI 미디어 제공자들은 지연 시간 (latency), 비용 (cost), 길이 제한 (duration limits), 종횡비 (aspect ratios), 카메라 제어 (camera control), 이미지 준수 (image adherence), 모더레이션 (moderation), 그리고 대기열 신뢰성 (queue reliability) 측면에서 서로 다릅니다.

API에 하나의 제공자를 하드코딩하는 것은 불필요한 리스크를 초래합니다.

어댑터 인터페이스 (adapter interface)를 사용하세요:

interface VideoProvider {
  name: string;
...

그 다음 제공자의 점수를 동적으로 산출합니다:

function scoreProvider(
  provider: VideoProvider,
  context: {
...

프로덕션 라우터 (production router)는 다음 사항들을 고려해야 합니다:

• 지원되는 입력 모드 (input mode),
• 원하는 길이 (duration),
• 요구되는 해상도 (resolution),
• 최근 제공자의 상태 (health),
• 대기열 깊이 (queue depth),
• 사용자 플랜 (user plan),
• 사용 가능한 크레딧 (available credits),
• 해당 콘텐츠 카테고리에 대한 과거 품질 (historical quality),
• 재시도 호환성 (retry compatibility).

라우팅은 단계별로 구성할 수도 있습니다. 빠르고 저렴한 모델이 초안 (draft)을 생성하고, 고품질 모델이 최종 렌더링 (final render)을 처리할 수 있습니다.

이러한 접근 방식은 사용자가 더 많은 리소스를 소비하기 전에 구성을 거부할 기회를 제공합니다.

이러한 가이드형 경험의 현재 브라우저 기반 구현 사례는 이 3D 브레이크아웃 비디오 워크플로(3D breakout video workflow)를 통해 확인할 수 있습니다. 이 사례는 가공되지 않은 모델 파라미터(raw model parameters)를 노출하는 대신 입력(input), 플랫폼 레이아웃(platform layout), 창의적 제어(creative control), 그리고 내보내기(export)를 중심으로 생성 과정을 구성하기 때문에 제품 인터페이스(product-interface) 참조용으로 유용합니다. 내부적인 구현 방식은 다를 수 있지만, 이 상호작용 패턴은 정형화된 워크플로(opinionated workflow)가 어떻게 인프라의 복잡성을 숨길 수 있는지를 잘 보여줍니다.

7. 생성을 비동기 상태 머신(Asynchronous State Machine)으로 모델링하기

비디오 생성은 일반적인 요청-응답(request-response) 라이프사이클 내에서 실행되어서는 안 됩니다.

제공업체(provider)가 빠르게 응답하더라도, 작업(job)은 대기열(queue)에 쌓이거나, 재시도(retry)되거나, 검토(moderate)되거나, 지연될 수 있습니다. 귀하의 API는 작업을 생성한 즉시 응답을 반환해야 합니다.

유용한 상태 머신(state machine)의 예시는 다음과 같습니다:

CREATED
  -> VALIDATING
  -> COMPILING_PROMPT
...

실패 상태(Failure states)는 구체적이어야 합니다:

REJECTED_INPUT
PROVIDER_REJECTED
PROVIDER_TIMEOUT
...

단순히 "failed"라고만 저장하지 마십시오. 고객 지원, 재시도, 환불 및 분석을 위해서는 구체적인 상태 값이 필수적입니다.

작업 스키마(job schema) 예시:

interface VideoJob {
  id: string;
  userId: string;
...

BullMQ, Cloud Tasks, SQS, RabbitMQ 또는 기타 내구성이 있는 작업 시스템(durable job system)과 같은 대기열(queue)을 사용하십시오. 정확한 선택보다는 시스템이 제공하는 보장(guarantees)이 더 중요합니다.

워커(worker)는 멱등성(idempotent)을 유지해야 합니다. 메시지가 두 번 전달되더라도 사용자에게 두 번 비용을 청구하거나 중복 작업을 생성해서는 안 됩니다.

간단한 전략은 다음과 같은 값들로부터 멱등성 키(idempotency key)를 생성하는 것입니다:

사용자 ID + 정규화된 입력 해시(normalized input hash) + 프롬프트 버전 + 출력 설정

제공업체 제출(provider submission) 단계에서는 대기열 메시지를 승인하기 전에 외부 작업 ID(external job ID)를 먼저 영속화(persist)해야 합니다.

8. 크레딧 처리를 예약 시스템(Reservation System)으로 설계하기

생성형 미디어(Generative media)는 종종 가변적인 비용이 발생합니다. 완료 후에 비용을 청구하면 제공업체 사용료를 미납받는 상황에 노출될 수 있습니다. 제출 전에 비용을 청구하면 생성 실패 시 사용자를 좌절시킬 수 있습니다.

예약 모델(reservation model)이 더 효과적입니다:

1. 최대 비용을 추정합니다.
2. 사용자의 크레딧을 예약(Reserve)합니다.
3. 생성을 제출합니다.
4. 성공 시 실제 비용을 청구하여 확정합니다.
5. 적절한 실패 상황 발생 시 예약을 해제하거나 환불합니다.
6. 제공자 비용(provider cost)을 사용자 가격과 별도로 기록합니다.

가변적인 잔액 필드(mutable balance field) 대신 원장(ledger)을 사용하세요.

type LedgerEntryType =
  | "purchase"
  | "reservation"
...

추가 전용 원장(append-only ledger)은 단일 숫자 잔액을 반복적으로 변경하는 것보다 감사(audit)하기가 더 쉽습니다.

또한 다음과 같은 중요한 질문에 답할 수 있게 해줍니다:

• 이 사용자는 왜 크레딧을 잃었는가?
• 작업이 재시도되었는가?
• 제공자가 실패한 렌더링에 대해 비용을 청구했는가?
• 환불이 자동이었는가, 아니면 수동이었는가?
• 어떤 모델이 마진(margin)을 발생시켰는가?

9. 후처리(Post-Processing)에서 브레이크아웃 환상 구축하기

생성 모델(generation model)이 모든 프레젠테이션 세부 사항을 해결해 줄 것이라고 기대하지 마세요.