# 사례 — 콘텐츠 공장

> **이 장에서 배우는 것**
> 지금까지 본 것들을 하나로 이어 **매일 자동으로 도는 제작 파이프라인**을
> 만드는 법. 구조를 그대로 따라 하면 됩니다.

## 만들 것

> **매일 아침, 정해둔 주제의 짧은 영상 한 편이 완성돼 있습니다.**

사람이 하는 일은 **마지막에 확인하고 올리는 것**뿐입니다.

```mermaid
graph TD
  A["1 수집<br/>terminal"] --> B["2 원고<br/>task"]
  B --> C["3 음성<br/>terminal + 모델 API"]
  B --> D["4 이미지<br/>terminal + 모델 API"]
  C --> E["5 렌더<br/>terminal"]
  D --> E
  E --> F["6 점검<br/>task"]
  F --> G["사람이 확인하고 게시"]
```

3번과 4번이 나란히 있는 게 중요합니다. **원고가 나오면 음성과 이미지는 서로
기다릴 이유가 없습니다** — [마이크로 스프린트의
독립성](/guide/ha-micro-sprint)이 여기서 그대로 쓰입니다.

## 폴더를 둘로 나눕니다

```
콘텐츠-소스/          ← 수집·원고·소재
  out/
    01-collected.json
    02-script.md
    03-audio/
    04-images/

콘텐츠-렌더/          ← 영상 조립 프로젝트
  src/
  out/
    final.mp4
```

**왜 나누나**: [작업 폴더가 곧 활동 범위](/guide/ht-working-directory)이기
때문입니다. 렌더 프로젝트는 코드가 있고 빌드가 돌므로 성격이 다릅니다. 나눠두면
자율성도 다르게 줄 수 있습니다.

| 폴더 | 자율성 |
|---|---|
| 소스 | 파일 편집 자동 승인 |
| 렌더 | 계획만 → 검증 후 올림 |

## 단계별로

### 1. 수집 — `terminal`

```
매일 05:30  ·  kind: terminal
```

정해진 곳에서 자료를 받아 `out/01-collected.json`으로 저장합니다.

**`task`가 아닌 이유**: 판단이 없습니다. 정해진 주소에서 받아 정해진 형식으로
저장하는 것뿐이라 [명령이 싸고 결정적](/guide/ht-pipelines)입니다.

### 2. 원고 — `task`

```
매일 06:00  ·  kind: task
```

```
[목표]
out/01-collected.json 을 읽고 60초 분량 영상 원고를 작성해 out/02-script.md 로
저장해주세요.

[범위]
- out/ 밖의 파일은 건드리지 말 것
- 01-collected.json 이 없거나 비어 있으면 아무것도 하지 말고 알릴 것

[완료 조건]
- 문단마다 한 장면. 문단 사이에 빈 줄
- 각 문단 끝에 [이미지: ...] 형태로 그 장면의 이미지 설명
- 전체 400~500자

[맥락]
- 이 원고는 그대로 음성으로 읽힙니다. 읽었을 때 자연스러워야 합니다
- 숫자는 소리 내 읽는 형태로 (2026년 → 이천이십육 년)
```

[좋은 지시의 네 요소](/guide/ai-intent-context)를 그대로 쓴 것입니다.

**"없으면 아무것도 하지 말고 알릴 것"이 핵심입니다.** 수집이 실패했는데 원고가
돌면 **빈손으로 그럴듯한 원고를 지어냅니다.**

### 3. 음성 — `terminal` + 모델 API

```
매일 06:20  ·  kind: terminal
```

원고를 **문단 단위로 잘라** [글 → 음성](/guide/ht-voice-image)을 부릅니다.

```
out/03-audio/
  001.wav
  002.wav
  ...
```

두 가지를 반드시 넣으세요.

```
□ 이미 있는 번호는 건너뛴다
□ 실패한 문단 번호를 남긴다
```

**문단으로 나누는 이유**는 실패했을 때 그 문단만 다시 만들기 위해서입니다.

### 4. 이미지 — `terminal` + 모델 API

```
매일 06:20  ·  kind: terminal
```

원고의 `[이미지: ...]` 표시를 뽑아 [이미지 생성](/guide/ht-voice-image)을
부릅니다.

```
out/04-images/
  001.png
  002.png
```

**프롬프트를 파일로 남기세요.** 스타일 항목(색감, 구도 규칙)은 공통으로 얹어
편마다 톤이 흔들리지 않게 합니다.

### 5. 렌더 — `terminal`

```
매일 06:50  ·  kind: terminal
```

음성과 이미지를 받아 영상으로 조립합니다. 렌더 프로젝트에서 명령 한 줄입니다.

**여기가 `terminal`인 이유가 분명합니다** — 빌드 명령은 판단이 없고, 매번 같은
결과가 나와야 합니다.

### 6. 점검 — `task`

```
매일 07:20  ·  kind: task
```

```
[목표]
오늘 만들어진 결과물을 점검하고 요약해주세요.

[확인할 것]
- out/03-audio/ 의 파일 수가 원고 문단 수와 같은가
- out/04-images/ 의 파일 수가 [이미지:] 표시 수와 같은가
- final.mp4 가 있고 길이가 50~70초인가
- 각 단계 로그에 실패가 있었나

[완료 조건]
- 문제가 없으면 "정상" 과 영상 길이만 보고
- 문제가 있으면 어느 단계 무엇이 문제인지 구체적으로

[하지 말 것]
- 문제를 발견해도 스스로 고치지 마세요. 보고까지입니다
```

**마지막 줄이 중요합니다.** 점검 단계가 고치기 시작하면 무엇이 원래 결과였는지
알 수 없게 됩니다.

## 이 설계의 판단들

### 왜 마지막에 사람이 있나

게시는 **되돌릴 수 없는 동작**입니다.
[가드레일](/guide/ha-guardrails)의 기준이 그대로 적용됩니다 — 되돌릴 수 있으면
자동, 없으면 사람.

```
수집 · 원고 · 음성 · 이미지 · 렌더  → 되돌릴 수 있음 → 자동
게시                              → 되돌릴 수 없음 → 사람
```

### 왜 단계마다 파일로 남기나

```
□ 실패한 단계부터 다시 돌릴 수 있음
□ 어제 것과 비교할 수 있음
□ 마음에 안 드는 부분만 골라 다시 만들 수 있음
```

### 왜 `task`가 두 개뿐인가

여섯 단계 중 **판단이 필요한 것은 원고와 점검 둘뿐**입니다. 나머지는 정해진
명령입니다. [비용의 대부분이 `task`에서 나오므로](/guide/ht-pipelines) 이 구분이
곧 운영비입니다.

## 처음 2주

**한 번에 자동화하지 마세요.**

| 시기 | 하는 일 |
|---|---|
| 1~3일 | 각 단계를 손으로 한 번씩 실행. 어디서 막히는지 확인 |
| 4~7일 | 예약으로 걸되 **매일 결과를 눈으로 확인** |
| 2주차 | 자율성 올리고 점검 단계의 보고만 확인 |
| 이후 | 실패 알림이 올 때만 개입 |

**1~3일을 건너뛰면** 여섯 단계가 동시에 처음 도는 걸 보게 되고, 어느 단계가
문제인지 알기 어렵습니다.

## 흔한 실패

| 증상 | 원인 | 대처 |
|---|---|---|
| 빈 원고가 매일 나옴 | 수집이 실패했는데 원고가 계속 돎 | 전제 확인을 지시문에 |
| 음성·이미지 수가 안 맞음 | 실패한 항목을 건너뛰고 진행 | 점검 단계에서 수를 대조 |
| 톤이 편마다 다름 | 이미지 스타일이 공통이 아님 | 프롬프트에 공통 항목 |
| 비용이 예상보다 큼 | 판단 없는 단계를 `task`로 | `terminal`로 옮기기 |
| 며칠째 아무것도 안 나옴 | 컴퓨터가 꺼져 있었음 | [백그라운드 실행·시작 항목](/guide/ht-first-run) |

**마지막이 의외로 흔합니다.** 노트북이 닫혀 있으면 예약도 안 돕니다.

## 다른 형태로 바꾸기

같은 구조를 갈아끼우면 다른 파이프라인이 됩니다.

| 바꾸는 것 | 되는 것 |
|---|---|
| 수집 → 사내 로그, 렌더 → 문서 | 일일 운영 리포트 |
| 수집 → 문의 내역, 렌더 → 표 | 주간 고객 이슈 요약 |
| 수집 → 경쟁사 페이지, 렌더 → 비교표 | 가격 모니터링 |
| 수집 → 회의 녹음, 음성→글 사용 | 회의록 자동화 |

**구조는 같습니다** — 수집 → 판단 → 가공 → 조립 → 점검 → 사람.

---

## 확인

**1. 여섯 단계 중 `task`가 두 개뿐인 이유는?**

<details>
<summary>답</summary>

**판단이 필요한 단계가 원고와 점검 둘뿐**이기 때문입니다. 나머지는 정해진
명령이라 `terminal`이 싸고 결정적입니다. 비용의 대부분이 `task`에서 나오므로 이
구분이 곧 운영비입니다.
</details>

**2. 원고 단계에 "자료가 없으면 아무것도 하지 말라"를 넣는 이유는?**

<details>
<summary>답</summary>

**수집이 실패했는데 원고가 돌면 빈손으로 그럴듯한 원고를 지어내기** 때문입니다.
아무도 안 보는 시간에 도는 파이프라인에서는 틀린 결과가 그대로 굳습니다.
</details>

**3. 왜 게시만 사람이 합니까?**

<details>
<summary>답</summary>

**되돌릴 수 없는 동작**이기 때문입니다. 수집·원고·음성·이미지·렌더는 다시 만들면
되지만 게시는 취소가 어렵습니다. 가드레일의 기준이 그대로 적용됩니다.
</details>

---

**확장하기 파트가 끝났습니다.** 여기까지 오시면 하이퍼팀즈(HyperTeams)를 화면에서 쓰는 것을
넘어 **다른 프로그램과 잇고 자동으로 돌게** 만들 수 있습니다.

막히는 것이 있으면 → [문제 해결](/guide/ht-troubleshooting) ·
[가이드 목차](/guide)