# 01. External Research Synthesis

이 문서는 외부 자료를 "그럴듯한 연구 소개"가 아니라 현재 파이프라인에 적용할 수 있는 prompt engineering/contract 관점으로 정리한다.

## 핵심 요약

외부 자료들의 공통점은 명확하다. 영화/스토리 시각화는 단일 LLM 호출로 해결하는 문제가 아니라, 긴 서사를 구조화하고, 인물/관계/상태/공간/레이아웃/참조 이미지를 분리하여 누적하는 문제다.

현재 레포의 방향은 이 흐름과 맞다. 특히 `beat_extract -> shot_extract -> shot_selection -> scene_director/shot_director -> scene_consistency -> background_* -> scene_detail -> ref/scene image` 구조는 "직접 샷을 물어보지 않고, 여러 중간 해석을 쌓는다"는 점에서 타당하다.

보완해야 할 점은 단계가 많다는 사실이 아니라, 각 단계가 어떤 종류의 결정을 소유하는지 더 엄격하게 분리하는 것이다.

## 자료별 시사점

| 자료 | 확인한 내용 | 이 프로젝트에 적용할 점 |
|---|---|---|
| Fountain syntax | 시나리오는 scene heading, action, character, dialogue, parenthetical 등 구조가 분리된 문서다. | `text_cleanup/scene_segmentation` 이후 action/dialogue/heading별로 evidence ref를 유지해야 한다. |
| Storyboarder | storyboard는 board 단위 메타데이터, shot type, action/dialogue, onion-skin 같은 이전/다음 board 참조를 갖는다. | `ShotCard`는 이미지 한 장의 메타데이터이며, previous/next shot linkage를 데이터로 가져야 한다. |
| MovieNet | 영화 이해 데이터는 캐릭터 ID, scene boundaries, place/action tag, cinematic style tag를 따로 주석한다. | 캐릭터/장소/행동/스타일을 한 prompt에 섞지 말고 별도 단계로 축적해야 한다. |
| MovieGraphs | 인물, 물리/감정 속성, 관계, 상호작용, 이유를 graph로 표현하고 시간에 grounding한다. | 죽은 시신, 부상, 관계 변화 같은 continuity는 `ContinuityCard`로 graph화해야 한다. |
| VidSitu | event를 verbs, semantic roles, entity coreference, event relations로 분해한다. | shot 추출 전 beat/event의 role 구조를 유지하면 "누가 무엇을 하는지" 누락이 줄어든다. |
| SummScreen | plot detail은 대사에 간접적으로 흩어져 있고, faithful plot event 생성이 어렵다. | 시나리오 요약과 visual inference는 evidence ref를 붙여야 한다. |
| MovieSum | 긴 영화 시나리오 요약은 long context와 구조 요소 때문에 어렵다. | 전체 원문을 매번 넣는 대신 scene packet과 project canon을 분리해야 한다. |
| TaleCrafter | story visualization은 identity consistency, text-visual alignment, reasonable layout이 필요하고 S2P/T2L/C-T2I로 분리한다. | prompt 생성, layout/background, image generation을 분리한 현재 방향이 맞다. |
| StoryDiffusion | 긴 이미지/비디오 생성에서 캐릭터 스타일과 attire consistency가 핵심 문제다. | `C##`, `O##`, `C##O##`, ref image binding은 최종 prompt compile 단계에서만 엄격히 다뤄야 한다. |
| OpenAI/Gemini Structured Outputs | JSON schema는 문법적 구조를 보장하지만 값의 의미 정확성은 별도 검증해야 한다. | strict schema + semantic validator가 둘 다 필요하다. |
| OpenAI/Gemini image docs | 이미지 생성은 텍스트만이 아니라 참조 이미지, multi-turn/edit flow, image inputs를 사용할 수 있다. | 이미지 단계 전 `AssetReadinessCard`로 참조 이미지 존재/경로/역할을 검증해야 한다. |

## 일반 문서 분석과 다른 점

일반 업무 문서 분석은 대체로 "명시된 사실 추출"이 중심이다. 시나리오는 다르다.

- 중요한 정보가 action line보다 dialogue에 숨어 있다.
- 인물의 감정 변화가 직접 쓰이지 않고 행동/침묵/반응으로 표현된다.
- 같은 장소가 시간, 사건, 조명, 훼손 상태에 따라 다른 background state가 된다.
- 한 장면은 1장의 이미지가 아니라 여러 still moment 후보로 분해되어야 한다.
- 이미지 모델은 추상적인 서사 의미를 직접 그릴 수 없으므로, 연출 가능한 시각 요소로 번역해야 한다.
- 일관성은 "같은 프롬프트 문장 반복"이 아니라, 참조 이미지와 고정 상태 카드의 반복 주입으로 유지된다.

따라서 prompt는 다음 형태가 되어야 한다.

```text
You are not summarizing a document.
You are producing one bounded visual decision from a screenplay packet.
Separate:
1. explicit source facts
2. reasonable visual inference
3. creative rendering decision
4. uncertainty
5. downstream validation constraints
```

## 연구에서 얻은 실용 원칙

### 1. Evidence 없이는 결정하지 않는다

시나리오 해석에는 상상력이 필요하지만, 근거 없는 상상은 continuity drift로 이어진다. 모든 중요한 결정은 `evidence_refs`를 가져야 한다.

예시:

```json
{
  "decision": "dead_body_left_side_pose",
  "decision_type": "continuity_anchor",
  "source_facts": [
    {"scene_index": 12, "source_type": "action", "span": "S12:A14-A18"}
  ],
  "visual_inference": "The body should stay motionless across shots.",
  "confidence": "high"
}
```

### 2. 인물/공간/상태/카메라는 별도 계약이다

한 LLM 호출에서 "이 장면을 이해하고, 캐릭터도 고르고, 배경도 만들고, 카메라도 정하고, 영어 이미지 프롬프트도 써라"라고 하면 실패한다. 각 결정은 소유자가 달라야 한다.

| 결정 | 소유 단계 |
|---|---|
| 등장/비등장 | `scene_director`, `shot_director` |
| 한 찰나 분해 | `shot_extract`, `shot_validator` |
| 선택 여부 | `shot_selection` |
| 인물 상태 고정 | `scene_consistency` |
| 배경 구조/상태 | `background_classify`, `background_master_plan` |
| floor plan prompt | `floor_plan_prompt` |
| empty background prompt | `background_prompt` |
| 최종 scene prompt | `scene_detail` |
| reference path/DB readiness | deterministic validator |

### 3. "카드"는 창작 의사결정의 최소 저장 단위다

Card는 단순히 예쁜 이름이 아니라 다음 역할을 한다.

- LLM이 만든 해석을 다음 단계가 재사용할 수 있게 한다.
- 사람이 어디서 drift가 생겼는지 볼 수 있게 한다.
- 재실행 시 "무엇을 보존하고 무엇을 다시 계산할지"를 구분한다.
- DB에 저장하기 전에 checkpoint에서 검증할 수 있다.

Card가 없으면 prompt는 매번 이전 단계 출력의 raw JSON을 ad hoc으로 읽게 되고, schema가 맞아도 의미가 틀린 상황을 잡기 어렵다.

### 4. Layout은 prompt의 일부가 아니라 별도 중간 산출물이다

TaleCrafter가 story-to-prompt와 text-to-layout을 분리한 것처럼, 이 프로젝트도 background/floor plan 분리가 맞다. 다만 scene prompt가 background를 다시 쓰면 중복 렌더링이 생긴다. 따라서 scene prompt는 background를 "새로 설명"하는 것이 아니라 `background_binding`과 frame 안에 보이는 부분만 선언해야 한다.

### 5. Structured Output은 충분조건이 아니다

OpenAI/Gemini structured output은 schema adherence를 제공한다. 하지만 semantic correctness는 별도다. 예를 들어 schema가 맞아도 다음은 틀린 값이다.

- `visible_entities`에 실제 보이지 않는 인물 포함
- `shot_ids`가 선택되지 않은 shot을 가리킴
- `variant_label`이 DB 컬럼 길이를 초과
- `t2i_prompt`는 JSON string이지만 `C##`/`C##O##` 규칙을 위반
- close framing인데 background reference 사용 지시 포함

따라서 prompt contract는 항상 `schema validation + semantic validation + asset readiness validation`으로 닫혀야 한다.

## 외부 자료 기반 권장 구조

```mermaid
flowchart LR
    subgraph ScriptUnderstanding[Script Understanding]
        A[Scene Structure] --> B[Events and Beats]
        B --> C[Characters and Relations]
    end

    subgraph VisualPlanning[Visual Planning]
        D[Shot Candidates] --> E[Shot Selection]
        E --> F[Continuity Anchors]
        E --> G[Layout and Background]
    end

    subgraph Generation[Image Generation]
        H[Prompt Compile] --> I[Reference Binding]
        I --> J[Image Generation]
        J --> K[Visual Validation]
    end

    C --> D
    F --> H
    G --> H
```

이 구조는 새 제안이 아니라 현재 레포의 의도를 설명하는 모델이다. 현재 구현은 이미 이 방향으로 가고 있고, 다음 개선은 이름과 저장 계약을 명확히 하는 것이다.