# 예약으로 파이프라인 만들기
> **이 장에서 배우는 것**
> 예약의 두 종류와 각각을 언제 쓰는지, 그리고 여러 단계를 잇는 법.
## 두 종류입니다
[예약 실행](/guide/ht-schedule)에서는 업무 예약만 다뤘습니다. 실제로는 두
가지입니다.
| 종류 | 무엇을 | 필요한 것 |
|---|---|---|
| **`task`** | 에이전트에게 지시를 맡김 | 지시문 |
| **`terminal`** | 명령을 그대로 실행 | 명령어 |
이 구분이 파이프라인 설계의 핵심입니다.
## 언제 무엇을 쓰나
```mermaid
graph TD
Q["이 단계는 어느 쪽?"] --> Q1{"매번 판단이 필요한가?"}
Q1 -->|"예"| T["task
에이전트"]
Q1 -->|"아니오"| Q2{"명령 한 줄로 되나?"}
Q2 -->|"예"| S["terminal
명령"]
Q2 -->|"아니오"| T
```
| 단계 | 종류 | 왜 |
|---|---|---|
| 자료를 읽고 요약 | `task` | 매번 내용이 다름 |
| 파일 형식 변환 | `terminal` | 정해진 명령 |
| 원고 작성 | `task` | 판단 필요 |
| 렌더·빌드 | `terminal` | 정해진 명령 |
| 오류 로그 분석 | `task` | 매번 다름 |
| 백업·정리 | `terminal` | 정해진 명령 |
> **판단이 없는 단계에 `task`를 쓰지 마세요.** 에이전트를 부르면 비용이 들고
> 결과가 매번 조금씩 다릅니다. `terminal`은 싸고 결정적입니다.
이건 [Phase 1의 AI 적합성 평가](/guide/ax-phase1-problem)와 같은 판단입니다 —
**규칙으로 100% 표현되면 AI를 쓸 이유가 없습니다.**
## 예약 하나 만들기
새 예약에 넣는 것들입니다.
| 항목 | `task` | `terminal` |
|---|---|---|
| 작업 폴더 | 필수 | 필수 |
| 주기 | 필수 | 필수 |
| 지시문 | **필수** | — |
| 명령어 | — | **필수** |
| 자율성 | 선택 | 해당 없음 |
| 엔진·모델 | 선택 | 해당 없음 |
주기는 [예약 실행 장](/guide/ht-schedule)에서 본 그대로입니다 — 분·시간·매일·
평일·매주·매월, 또는 크론 식 직접 입력.
## 여러 단계를 잇는 법
여기가 이 장의 본론입니다. 예약 하나는 한 단계입니다. **파이프라인은 여러
단계를 이어야** 합니다.
### 방법 1 — 시차를 둔다 (가장 단순)
```
06:00 terminal 자료 수집
07:00 task 수집한 것으로 원고 작성
08:00 terminal 원고로 결과물 생성
```
**장점**: 단순합니다. 각 단계가 독립적이라 하나가 실패해도 나머지가 돕니다.
**단점**: 앞 단계가 늦어지면 뒷 단계가 **빈손으로 돕니다.**
그래서 각 단계가 **전제를 확인**해야 합니다.
```
✓ "수집 결과 파일이 없으면 아무것도 하지 말고 알릴 것"
```
[예약 실행 장](/guide/ht-schedule)에서 "전제 조건을 확인하게 하라"고 한 것이
파이프라인에서는 필수가 됩니다.
### 방법 2 — 한 단계가 다음을 부른다
`terminal` 단계의 명령 안에서 [REST API](/guide/ht-rest-api)로 다음 업무를
만듭니다.
```bash
# 수집이 끝난 뒤 결과가 있으면 다음 업무 생성
if [ -s out/collected.json ]; then
curl -X POST http://localhost:27777/api/v1/tasks \
-H "Authorization: Bearer $HT_KEY" \
-H "Content-Type: application/json" \
-d '{"workspaceId":3,"prompt":"out/collected.json 으로 원고를 작성해줘","name":"원고-'"$(date +%F)"'"}'
fi
```
**장점**: 앞이 끝나야 뒤가 돕니다. 빈손 실행이 없습니다.
**단점**: 열쇠가 스크립트에 들어갑니다. 환경변수로 빼세요.
### 방법 3 — 한 업무가 전부 한다
지시문 하나에 여러 단계를 담고 에이전트가 알아서 진행하게 합니다.
**대개 권하지 않습니다.** [컨텍스트가 차서](/guide/ai-context-overflow) 뒤로 갈수록
일관성이 떨어지고, 어느 단계에서 실패했는지 알기 어렵습니다.
[마이크로 스프린트](/guide/ha-micro-sprint)의 원칙이 여기도 적용됩니다 — **나누면
각자 깨끗한 컨텍스트에서 시작합니다.**
## 파이프라인 설계 원칙
### 1. 단계마다 산출물을 파일로 남기세요
```
out/
01-collected.json
02-script.md
03-audio/
04-final.mp4
```
**중간 산출물이 파일로 있으면** 실패한 단계부터 다시 돌릴 수 있습니다. 메모리로만
넘기면 처음부터입니다.
번호를 붙이는 이유는 **순서가 보이기 때문**입니다.
### 2. 이미 있는 것은 건너뛰게 하세요
```
✓ "out/03-audio/ 에 이미 있는 문단은 건너뛸 것"
```
50개 중 3개가 실패했을 때 3개만 다시 만들 수 있습니다.
### 3. 실패를 알리게 하세요
가장 자주 빠뜨립니다. 조용히 실패하면 **몇 주 뒤에** 발견합니다.
```
✓ "각 단계 끝에 성공/실패를 요약해 알릴 것.
실패하면 다음 단계로 넘어가지 말 것."
```
### 4. 자율성은 낮게 시작하세요
파이프라인은 **아무도 안 보는 시간에** 돕니다. [자율성
수준](/guide/ht-autonomy)을 처음부터 전부 자동으로 두지 마세요.
```
1주차: 계획만으로 돌리고 매일 계획을 확인
2주차: 파일 편집 자동 승인
이후: 안정적이면 올림
```
## 비용이 누적됩니다
매일 도는 파이프라인은 **한 번 비용 × 30**입니다.
```
task 단계 3개 × $0.30 × 30일 = 월 $27
```
줄이는 순서는 정해져 있습니다.
```
1. 판단이 필요 없는 단계를 terminal 로 옮기기 ← 가장 큼
2. 단순한 task 에 가벼운 모델
3. 실패 재시도에 상한 두기
```
**1번이 가장 효과적입니다.** 형식 변환을 에이전트에게 시키고 있었다면 명령
하나로 바꾸는 것만으로 그 단계 비용이 0이 됩니다.
## 관리
예약이 늘어나면 관리가 필요합니다.
```
□ 이 예약이 마지막으로 성공한 게 언제인가
□ 목적이 끝난 파이프라인이 계속 도는가
□ 앞 단계가 실패했는데 뒤 단계가 계속 도는가
```
**세 번째가 파이프라인 특유의 문제입니다.** 수집이 몇 주째 실패했는데 원고
작성이 계속 돌면서 빈 결과를 만들고 있을 수 있습니다.
---
## 확인
**1. `task`와 `terminal` 예약을 어떻게 구분합니까?**
답
**매번 판단이 필요하면 `task`, 정해진 명령이면 `terminal`**입니다. 판단이 없는
단계에 `task`를 쓰면 비용이 들고 결과가 매번 달라집니다.
**2. 중간 산출물을 파일로 남겨야 하는 이유는?**
답
**실패한 단계부터 다시 돌릴 수 있기** 때문입니다. 파일로 안 남기면 어느 단계에서
실패해도 처음부터 다시 해야 합니다.
**3. 파이프라인 비용을 줄이는 가장 효과적인 방법은?**
답
**판단이 필요 없는 단계를 `terminal`로 옮기는 것**입니다. 형식 변환 같은 것을
명령 하나로 바꾸면 그 단계 비용이 사라집니다.
---
세 단계짜리를 직접 만들고 가운데를 깨뜨려봅니다. 60분입니다 →
[파이프라인 하나를 끝까지 만들어보기](/guide/ht-try-pipeline)