# 09. 목적 중심 파이프라인 재분석 및 개선 아이디어

> 원본 코드/프롬프트/기존 문서를 수정하지 않고 생성한 read-only 기반 제안 문서입니다. 이 문서는 기존 `08_structural_pipeline_improvement_ideas.md`를 대체하기보다는, 그 문서가 놓친 "제품 목적과 제작 플로우" 관점으로 다시 정리한 보완안입니다.

## 0. 이전 아이디어의 한계

이전 아이디어는 실행 경로, 상태 truth, DB, prompt/model source 같은 인프라 문제를 중심으로 봤다. 그 자체는 필요하지만, 제품의 본질을 충분히 반영하지 못했다.

이 제품의 목적은 단순히 "step들을 안정적으로 실행"하는 것이 아니다.

정확한 목적은 다음에 가깝다.

> 영화/드라마 시나리오 PDF를 입력받아, 사람이 검수 가능한 제작용 shot card와 asset library를 만들고, 그 위에서 참조 이미지/배경/씬 이미지를 생성해 최종 웹북/PDF로 완성하는 제작 시스템.

즉, 핵심 산출물은 `step result JSON`이 아니라 다음 네 가지다.

| 핵심 산출물 | 의미 |
|---|---|
| `Production Bible` | 작품 전체의 세계관, 시각 규칙, 인물/장소/소품 canon |
| `Shot Cards` | 웹북에 들어갈 선택된 순간들, 각 컷의 연출/등장요소/참조/프롬프트 |
| `Asset Library` | 인물 얼굴, 의상 조합, 상태 변형, 소품, 도면/배경, 씬 이미지 |
| `Review/Export Package` | 사람이 승인한 이미지와 텍스트를 엮은 웹북/PDF |

따라서 개선 방향도 `step 안정화`가 아니라 `제작 산출물 중심 구조`로 잡아야 한다.

## 1. 제품 플로우를 다시 정의

현재 문서와 코드가 설명하는 실제 제품 플로우는 다음이다.

```mermaid
flowchart TB
    PDF[시나리오 PDF] --> Ingest[텍스트 추출/정리/씬 분할]
    Ingest --> Story[스토리 구조화: scene / beat / shot]
    Story --> Selection[웹북용 핵심 shot 선택]
    Ingest --> Canon[인물/장소/소품/의상 canon]
    Canon --> Bible[Production Bible]
    Story --> Direction[연출: visible entities / camera / staging / consistency]
    Bible --> Direction
    Direction --> ShotCards[Selected Shot Cards]
    ShotCards --> RefPlan[참조 asset 계획]
    RefPlan --> AssetLib[Asset Library]
    ShotCards --> SceneGen[씬 이미지 생성]
    AssetLib --> SceneGen
    SceneGen --> Review[사람 검수/수정/승인]
    Review --> Export[웹북/PDF 출력]
```

여기서 중요한 점은 `ShotCards`가 최종 이미지 생성의 중심 계약이어야 한다는 것이다.

현재는 scene image 단계가 `scene_detail`, `shot_dependency_t2i`, `shot_staging`, `scene_consistency`, `background_render`, `composite_image_gen`, `world_guide` 등 여러 checkpoint와 DB를 직접 읽으며 조립한다. 이 방식은 유연하지만, 참조 누락/경로 누락/상태 불일치가 너무 늦게 발견된다.

## 2. 현재 step들을 "제작 의미"로 재분류

### 2.1 Ingest Lane

목적: PDF를 AI가 다룰 수 있는 장면 단위 원천 데이터로 바꾼다.

| 현재 step | 제작 의미 |
|---|---|
| `planning_doc_analysis` | 기획서에서 작품 의도/톤/제약 추출 |
| `text_cleanup` | 원문을 보존하면서 불필요한 PDF noise 제거 |
| `scene_segmentation` | 시나리오를 scene 단위로 분리 |
| `scene_save` | scene 원문을 이후 모든 단계의 안정 기준으로 저장 |
| `episode_summary` | 전체 episode context |
| `visual_world_rules` | 시대/지역/장르/금지 요소 등 visual rule seed |

이 lane의 품질 기준은 "내용을 창작하지 않고 원문 구조를 정확히 보존했는가"다.

### 2.2 Story/Shot Lane

목적: 웹북에 들어갈 "무슨 순간을 보여줄지" 결정한다.

| 현재 step | 제작 의미 |
|---|---|
| `beat_extract` | scene 안의 상태 변화/감정 변화 단위 추출 |
| `shot_extract` | beat를 한 컷으로 담을 수 있는 shot 후보로 분해 |
| `shot_validator` | 한 shot = 한 찰나 원칙, 시점 혼합/시간 점프 제거 |
| `shot_selection` | 웹북 예산에 맞춰 핵심 shot만 선택 |

이 lane의 산출물은 단순한 "shot list"가 아니라 웹북의 편집 리듬이다. 여기서 잘못 선택하면 뒤의 이미지가 아무리 좋아도 웹북이 산만하거나 핵심 장면이 빠진다.

### 2.3 Canon Lane

목적: 같은 인물/장소/소품/의상이 전체 episode에서 같은 대상으로 유지되게 한다.

| 현재 step | 제작 의미 |
|---|---|
| `entity_character_list` | 중요 인물 후보 seed |
| `entity_all_*` | 인물/장소/소품 후보 listing |
| `entity_extract_*` | 후보별 등장/설명 추출 |
| `entity_merge` | 중복 요소 병합 |
| `entity_relation` | 변형/동일성/visual similarity 관계 |
| `entity_filter` | 웹북 asset으로 만들 가치가 낮은 저빈도 요소 제거 |
| `entity_detail` | 안정 traits와 상세 description 확정 |
| `entity_t2i` | asset 생성 가능한 영어 T2I seed |
| `outlook_phase1/2/3` | 인물 의상 catalog와 scene별 outfit mapping |

이 lane의 산출물은 `EntityCanon`이 아니라 "Asset Library를 만들 수 있는 canon"이다.

### 2.4 Direction/Continuity Lane

목적: 선택된 shot을 실제 촬영 컷처럼 연출하고, 같은 scene/장소/시간의 일관성을 지킨다.

| 현재 step | 제작 의미 |
|---|---|
| `scene_director` | scene 안에 물리적으로 존재하는 entity 결정 |
| `shot_director` | shot별 visible entity와 변형 전환 시점 확정 |
| `scene_camera_flow` | scene 안의 카메라 흐름/리듬 |
| `shot_dependency` | 이전 shot/같은 장소/zoom-in relation |
| `shot_staging` | 인물 배치, 표정, 자세, 조명, 소품 위치 |
| `scene_consistency` | 같은 scene 안에서 변하지 않아야 할 요소 고정 |
| `background_*` | 장소/배경을 shot 간 공유 가능한 asset으로 설계 |
| `scene_detail` | 최종 shot별 T2I prompt와 visible entities compile |
| `shot_dependency_t2i` | T2I 기반 참조/zoom/detail 관계 보정 |
| `t2i_review` | prompt/canon/detail 검수 및 수정 |

이 lane은 "이미지를 만들기 직전의 감독 노트"다.

### 2.5 Asset Lane

목적: 실제 이미지 asset을 만들고, 이후 shot에서 참조할 수 있게 한다.

| 현재 step | 제작 의미 |
|---|---|
| `world_guide` | 모든 이미지에 들어갈 style bible |
| `ref_image_gen` | 인물 얼굴/소품 등 기본 reference |
| `composite_image_gen` | 인물 + 의상 조합 reference |
| `character_state_variant` | dead/injured/unconscious 등 특수 상태 reference |
| `floor_plan_render` | 실내/장소 구조를 고정하는 도면 reference |
| `background_render` | shot들이 공유할 배경 reference |
| `scene_image_pipeline` | 최종 selected shot 이미지 생성/검증/선택 |

이 lane의 성공 기준은 "이미지가 생성됐다"가 아니라 "해당 shot card에서 참조 가능한 asset으로 등록됐다"다.

## 3. 핵심 구조 제안: Shot Card를 중심에 둔다

### 3.1 왜 Shot Card인가

웹북/PDF에 실제로 들어가는 단위는 "scene"도 아니고 "raw step output"도 아니다. 최종 사용자가 검수하는 단위는 선택된 shot이다.

따라서 selected shot마다 하나의 `Shot Card`를 compile해야 한다.

```mermaid
flowchart TB
    Story[beat/shot/selection] --> Card[Shot Card]
    Canon[entity/outlook/canon] --> Card
    Direction[director/staging/consistency] --> Card
    Background[background/floor plan] --> Card
    Prompt[scene_detail/t2i_review] --> Card
    Assets[reference/composite/state/background assets] --> Card
    Card --> SceneImage[scene image generation]
    Card --> Review[human review]
    Card --> Export[webbook/PDF]
```

### 3.2 Shot Card에 들어가야 할 정보

| 영역 | 필드 예 |
|---|---|
| 정체성 | `project_id`, `episode_id`, `scene_index`, `shot_index`, `shot_id` |
| 스토리 | scene heading, beat summary, shot description, representative moment |
| 선택 이유 | selected 여부, selection reason, narrative importance |
| 등장 요소 | visible characters/locations/props, C##/L##/P## |
| 의상/상태 | C##O##, O00, dead/injured/unconscious variant |
| 연출 | shot type, camera direction, framing, lens, subject, composition |
| 배치 | left/right/depth, pose, gaze, prop position |
| 일관성 | fixed scene elements, keep/remove elements, previous shot relation |
| 배경 | background group id, floor plan id, background image id/path |
| 참조 | character refs, composite refs, prop refs, state refs, background refs |
| 프롬프트 | source-language description, translated T2I, final prompt |
| 검증 | prompt validation result, asset readiness, image validation |
| 이미지 | generated variants, primary image, review status |
| provenance | upstream checkpoint hashes, prompt versions, model versions |

### 3.3 Shot Card compile step

새로운 LLM step을 늘리자는 의미가 아니다. 핵심은 이미지 생성 전 deterministic compile 단계를 두자는 것이다.

```mermaid
flowchart LR
    Checkpoints[existing checkpoints] --> Compile[Shot Card Compiler deterministic]
    DB[(DB projection)] --> Compile
    Compile --> Cards[shot_cards.json / DB projection]
    Cards --> Readiness{ready?}
    Readiness -->|yes| SceneGen[scene_image_pipeline]
    Readiness -->|no| Report[missing refs / invalid card report]
```

이 compile은 다음을 미리 잡는다.

| 사전 발견 문제 | 예 |
|---|---|
| selected shot인데 `scene_detail` 없음 | 이미지 생성 시작 전 중단 |
| C01O03이 있는데 composite/ref 없음 | ref_image/composite 단계로 돌려보냄 |
| background id는 있는데 PNG/DB row 없음 | background_render repair 요구 |
| path가 cwd 의존/resolve 실패 | asset readiness fail |
| shot card에 visible entity와 prompt entity가 다름 | prompt review fail |
| close-up인데 wide background ref 주입 예정 | card-level policy로 정리 |

## 4. Pipeline을 "긴 체인"이 아니라 "제작 보드"로 봐야 함

현재 체감은 50개 이상 step의 긴 chain이다. 그러나 사용자 관점은 다음 네 보드가 더 자연스럽다.

```mermaid
flowchart LR
    Board1[Scene Board] --> Board2[Shot Board]
    Board2 --> Board3[Asset Board]
    Board3 --> Board4[Review Board]
    Board4 --> Export[Webbook Export]
```

| Board | 사용자가 보는 것 | 내부 step |
|---|---|---|
| Scene Board | 씬 분할, 씬 요약, 원문 | ingest/summary |
| Shot Board | selected shots, shot 설명, 선택/해제 | beat/shot/validator/selection |
| Asset Board | 인물/의상/소품/배경 reference | canon/outlook/ref/background |
| Review Board | 생성된 scene images, 승인/수정/재생성 | scene_image/review/export |

이렇게 보면 개선 우선순위도 달라진다. "step이 completed인가"보다 "사용자가 다음 board로 넘어갈 수 있는가"가 더 중요하다.

## 5. Approval Gate를 명시한다

완전 자동화를 목표로 하면 작은 오류가 뒤에서 큰 비용으로 증폭된다. 이 제품은 이미 HiTL을 지향하므로, gate를 명확히 두는 편이 품질과 비용에 유리하다.

```mermaid
flowchart TB
    G1[Gate 1: Scene split approved] --> G2[Gate 2: Shot selection approved]
    G2 --> G3[Gate 3: Canon/outlook approved]
    G3 --> G4[Gate 4: Background plan approved]
    G4 --> G5[Gate 5: Reference assets approved]
    G5 --> G6[Gate 6: Scene images approved]
    G6 --> Export[Export]
```

| Gate | 사람이 확인할 내용 | 통과 후 lock |
|---|---|---|
| Scene split | scene 누락/분할 오류 | scene ids, offsets |
| Shot selection | 핵심 순간 누락/과다 | selected shot list |
| Canon/outlook | 인물/장소/소품/의상 누락/중복 | C/L/P/O ids |
| Background plan | 같은 장소/세트 일관성 | background groups/floor plans |
| Reference assets | 얼굴/의상/소품/배경 reference 품질 | asset ids |
| Scene images | 최종 이미지와 대표 선택 | primary images |

중요한 점은 lock이 있어야 한다는 것이다. 예를 들어 shot selection을 사람이 승인한 뒤에는 upstream 재분석이 이 선택을 덮어쓰면 안 된다. 대신 "stale이지만 user locked" 상태로 보여야 한다.

## 6. 이미지 생성은 Shot Card build plan으로 실행한다

현재 `category=image` 실행은 사용자가 "이미지만" 의도해도 dependency를 넓게 따라가거나, 반대로 direct image endpoint는 step 상태를 우회할 수 있다.

목적 중심으로 보면 사용자는 다음 중 하나를 원한다.

| 사용자 의도 | 실제 명령 의미 |
|---|---|
| 참조 이미지 만들기 | selected shot cards에서 필요한 reference asset만 생성 |
| 배경 만들기 | selected shot cards에서 필요한 background/floor plan만 생성 |
| 씬 이미지 만들기 | ready 상태의 selected shot cards만 생성 |
| 누락 복구 | failed/missing target만 재시도 |
| 전체 다시 | locked edit을 보존하면서 build plan 재계산 |

따라서 image command는 step category가 아니라 asset target plan으로 바꿔야 한다.

```mermaid
flowchart TB
    Cards[Shot Cards] --> NeedRefs[compute needed references]
    Cards --> NeedBG[compute needed backgrounds]
    Cards --> NeedScenes[compute needed scene images]
    NeedRefs --> RefQueue[reference asset queue]
    NeedBG --> BGQueue[background asset queue]
    NeedScenes --> SceneQueue[scene image queue]
    RefQueue --> AssetLib[Asset Library]
    BGQueue --> AssetLib
    AssetLib --> SceneQueue
```

## 7. 배경 생성은 "장소 entity"가 아니라 "shot에서 재사용할 set asset"으로 봐야 함

배경 문제의 목적은 장소 entity 이미지를 만드는 것이 아니다. 목적은 같은 장소/같은 상태/같은 시간의 shot들이 같은 set을 공유하게 하는 것이다.

### 현재 흐름의 의미

| 현재 단계 | 실제 제작 의미 |
|---|---|
| `background_classify` | location들을 set reuse group으로 묶음 |
| `background_master_plan` | group 안에서 floor plan과 background variant를 계획 |
| `floor_plan_prompt/render` | 공간 구조를 고정 |
| `background_prompt/render` | shot들이 참조할 set/background image 생성 |
| `scene_detail` chain_bg guide | shot prompt가 배경 이미지와 충돌하지 않게 guide 주입 |
| `scene_image_pipeline` ref 주입 | 최종 씬 이미지가 배경을 참조 |

### 개선 아이디어

`Location`과 `SetAsset`을 분리해서 생각한다.

| 개념 | 예 |
|---|---|
| Location entity | `L01 옥탑방` |
| Set asset | `L01_rooftop_night_base` |
| Set state variant | `night_body_blood_curtain_red_circle` |
| Camera-local shot use | close-up이면 background ref skip, wide이면 사용 |

```mermaid
flowchart LR
    Location[L01 옥탑방] --> SetAsset[SetAsset: 옥탑방 기본 밤]
    SetAsset --> Variant1[Variant: 깨진 창문]
    SetAsset --> Variant2[Variant: 피웅덩이/커튼]
    Variant1 --> ShotA[S12 Shot1 wide]
    Variant2 --> ShotB[S12 Shot2 medium]
    ShotC[S12 Shot3 close-up] -. may skip bg ref .-> SetPolicy[framing policy]
```

이 관점에서는 `variant_label`도 사람이 읽는 긴 설명이 아니라, `set_state_id + human_label` 구조가 적합하다.

## 8. 효율화는 "step 단위"가 아니라 "target 단위"로 해야 함

### 잘못된 효율화

| 방식 | 문제 |
|---|---|
| image category 전체 재실행 | 너무 넓음 |
| scene_image_pipeline 전체 재실행 | 실패한 shot 외에도 모두 재생성 |
| reference 전체 재생성 | 바뀌지 않은 얼굴/의상까지 비용 소모 |
| background 전체 재생성 | 같은 set asset을 계속 다시 만듦 |

### 목적에 맞는 효율화

| target | 재실행 조건 |
|---|---|
| `character_ref:C01` | C01 canon/t2i 변경, 파일/DB 없음, 사용자가 reject |
| `outfit_ref:C01O03` | C01 or O03 변경, composite 누락 |
| `state_ref:C02:dead` | 상태 variant prompt 변경, 관련 shot 등장 |
| `set_asset:L01:night:v02` | background state 변경, file/DB 누락 |
| `scene_image:S12_Shot3` | shot card hash 변경, reference asset 변경, user request |

```mermaid
flowchart TB
    Change[Change event] --> Hash[recompute target hashes]
    Hash --> Dirty[dirty target list]
    Dirty --> Queue[queue only dirty targets]
    Queue --> Generate[generate]
    Generate --> Verify[target verify]
    Verify --> Ready[ready for review]
```

## 9. "Low-fi storyboard first, high-fi final later" 전략

현재 최종 이미지 생성을 너무 빨리 시작하면, 앞단의 scene/shot/canon 오류가 이미지 비용으로 증폭된다.

권장 플로우:

| 단계 | 산출물 | 모델/비용 |
|---|---|---|
| Low-fi storyboard | selected shot cards + rough thumbnails or text boards | 저비용 |
| Human approval | shot selection/canon/background plan 수정 | 사람 |
| Reference build | 얼굴/의상/소품/배경 고정 asset | 중비용 |
| Hi-fi scene image | 최종 2K/고품질 image | 고비용 |
| Review/export | 승인된 primary만 웹북 반영 | 사람 |

이 방식은 영화 제작의 콘티 프로세스와 더 맞다. 먼저 컷 구성을 확정하고, 이후 고비용 이미지를 만든다.

## 10. Prompt는 "작성"보다 "컴파일"로 봐야 함

현재 scene_detail, prompt_translation, prompt_sanitize, final scene prompt 조립이 단계별로 흩어져 있다.

목적 중심으로는 prompt는 Shot Card를 image provider에 맞춰 compile한 결과다.

```mermaid
flowchart LR
    Card[Shot Card] --> Compiler[Prompt Compiler]
    Compiler --> GeminiPrompt[Gemini image prompt]
    Compiler --> OpenAIPrompt[GPT image prompt]
    Compiler --> FallbackPrompt[moderation-safe prompt]
    Compiler --> Debug[why/provenance block]
```

Prompt compiler가 가져야 할 출력:

| 출력 | 설명 |
|---|---|
| source prompt | 사람이 읽는 한국어/원문 기반 설명 |
| provider prompt | Gemini/OpenAI/fal에 맞춘 영어 prompt |
| reference map | Image 1, Image 2가 무엇인지 |
| negative/avoid | world guide + shot-specific avoid |
| safety variant | moderation 대응용 순화 prompt |
| provenance | 어떤 card 필드에서 나온 문장인지 |

이렇게 하면 "왜 이 프롬프트가 나왔는가"를 UI에서 설명할 수 있다.

## 11. Human-in-the-loop를 pipeline의 일부로 넣는다

현재 문서상 제품은 AI 85%, 사람 15% 보정을 목표로 한다. 그런데 pipeline 구조는 아직 자동 step chain에 가깝다.

### 제안하는 user edit model

| 사용자 편집 | 저장 위치 | 영향 |
|---|---|---|
| scene split 수정 | Scene Board override | downstream scene ids 유지/재계산 |
| shot 선택/해제 | Shot Card lock | image target list 변경 |
| entity 설명 수정 | Canon override | ref/scene dirty target 계산 |
| outfit 수정 | Outlook override | composite/scene dirty |
| background 수정 | SetAsset override | background/scene dirty |
| prompt 자연어 수정 | Shot Card override | scene image dirty |
| image reject/approve | Review state | retry/export 대상 결정 |

핵심 원칙:

> AI 재분석은 사람이 lock한 결정을 덮어쓰지 않고, conflict/diff로 제안해야 한다.

## 12. Cross-episode 관점

제품 문서에는 시리즈 10~30화 확장 필요가 명시되어 있다. 현재 episode 독립 분석 구조는 장기적으로 한계가 있다.

### 제안 계층

```mermaid
flowchart TB
    ProjectBible[Project Production Bible] --> EpisodeBible[Episode Bible]
    ProjectCanon[Project Canon: characters/locations/props] --> EpisodeCanon[Episode-specific state]
    ProjectAssets[Project Asset Library] --> EpisodeAssets[Episode variants]
    EpisodeBible --> ShotCards[Episode Shot Cards]
    EpisodeAssets --> ShotCards
```

| 계층 | 예 |
|---|---|
| Project-level | 주인공 얼굴, 주요 장소 기본 set, 작품 톤 |
| Episode-level | 이번 화 의상, 부상/사망 상태, 특정 배경 상태 |
| Shot-level | 이 컷의 자세/구도/프롬프트 |

이 구조가 있어야 EP1의 민숙 얼굴/옥탑방 set이 EP2에서 자연스럽게 재사용된다.

## 13. 사용자에게 보여줄 화면도 재정의

현재 UI가 step 실행/이미지 검수 중심이면, 비전문가에게는 어렵다. 제작 목적에 맞춰 화면을 재구성한다.

| 화면 | 목적 |
|---|---|
| Project Bible | 작품 톤, 세계관, 주요 canon |
| Scene Board | scene 분할과 원문 검수 |
| Shot Board | 웹북에 들어갈 shot 선택/순서/이유 |
| Canon Board | 인물/장소/소품/의상 카드 |
| Set Board | 장소별 floor/background/set state |
| Asset Board | reference/composite/background asset 상태 |
| Review Board | 최종 scene image 승인/수정 |
| Export Studio | 웹북 분할/PDF 출력 |

Step 상태는 숨기지 말되, 개발자용 diagnostic layer로 내려야 한다.

## 14. 새 아이디어 요약

### A. Shot Card Compiler 도입

가장 중요한 제안이다.

기존 step output을 없애자는 뜻이 아니다. 이미지 생성 전에 deterministic compiler가 selected shot별로 모든 정보를 합쳐 `Shot Card`를 만들고, 이 카드가 ready일 때만 scene image를 생성한다.

효과:

| 효과 | 설명 |
|---|---|
| 참조 누락 조기 발견 | scene image 시작 전 실패 |
| 프롬프트/참조/provenance 일원화 | 디버깅 쉬움 |
| target-level retry 가능 | shot 단위 재생성 |
| UI 설명 가능 | 왜 이 인물/배경/프롬프트인지 표시 |

### B. Asset Library를 독립 domain으로 격상

`ImageAsset` row가 아니라 제작용 asset library로 본다.

| asset class | 예 |
|---|---|
| character base | C01 face |
| outfit standalone | O03 funeral clothes |
| composite | C01O03 full body |
| state variant | C02 dead |
| prop | P05 wristwatch |
| set/floor | L01 rooftop layout |
| set/background | L01 night damaged room |
| scene image | S12_Shot3 primary |

### C. Build Plan 기반 실행

사용자가 "이미지 생성"을 누르면 step category를 실행하는 것이 아니라, 현재 Shot Cards에서 필요한 asset target list를 계산한다.

### D. Approval Gate와 Lock

사람이 승인한 scene split, shot selection, canon, background, reference는 AI 재분석이 덮어쓰지 않는다.

### E. Low-fi to Hi-fi

처음부터 고비용 2K 최종 이미지를 만들지 말고, shot card/storyboard를 먼저 승인받고 고품질 이미지를 만든다.

## 15. 적용 우선순위

### 1순위: Shot Card Contract 정의

코드부터 고치기 전에 문서/스키마로 selected shot card의 필드를 정의해야 한다. 현재 여러 checkpoint에 흩어진 정보를 한 장의 제작 카드로 표현할 수 있어야 한다.

### 2순위: Shot Card Readiness Check

이미지 생성 전 다음을 검사한다.

| 검사 | 설명 |
|---|---|
| selected shot 존재 | shot_selection 기준 |
| scene_detail 존재 | t2i prompt와 visible entities |
| canon/outlook resolve | C##/O##/P##/L##가 실제 entity와 연결 |
| reference readiness | 필요한 ref/composite/state asset 존재 |
| background readiness | 필요한 background/floor asset 존재 또는 skip policy |
| path readiness | 모든 file path resolve 가능 |
| prompt readiness | provider prompt compile 가능 |

### 3순위: Image Build Plan

Shot Cards에서 필요한 asset target을 계산한다.

| build command | 대상 |
|---|---|
| `build_refs` | 누락된 character/prop/outfit/composite/state refs |
| `build_backgrounds` | 누락된 floor/set/background refs |
| `build_scene_images` | ready card 중 missing/rejected/stale scene images |
| `repair_assets` | DB/file/checkpoint mismatch 복구 |

### 4순위: UI Board 재구성

기존 step UI는 diagnostic으로 두고, 사용자 기본 화면은 board 중심으로 바꾼다.

### 5순위: Cross-episode Project Bible

EP1 품질이 안정된 후 project-level canon/asset reuse로 확장한다.

## 16. 최종 제안

이 시스템을 `LLM step chain`으로 계속 보면 수정 방향이 계속 hotfix/runner/DB 상태로 흐른다.

더 적합한 관점은 다음이다.

> 시나리오를 Production Bible과 Shot Cards로 컴파일하고, Asset Library를 만들어, 사람이 승인한 카드만 고품질 이미지와 웹북으로 출력하는 제작 파이프라인.

따라서 앞으로의 개선은 다음 문장으로 정렬하는 것이 좋다.

1. 모든 selected shot은 하나의 Shot Card로 설명 가능해야 한다.
2. 모든 scene image는 하나의 Shot Card와 Asset Library에서 재현 가능해야 한다.
3. 모든 사용자 수정은 Shot Card, Canon, Asset 중 어디를 바꾸는지 명확해야 한다.
4. 모든 재실행은 step 단위가 아니라 dirty target 단위여야 한다.
5. 모든 완료 상태는 "다음 제작 단계로 넘어갈 수 있음"을 의미해야 한다.