사례 — 콘텐츠 공장

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

만들 것

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

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

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번이 나란히 있는 게 중요합니다. 원고가 나오면 음성과 이미지는 서로 기다릴 이유가 없습니다 — 마이크로 스프린트의 독립성이 여기서 그대로 쓰입니다.

폴더를 둘로 나눕니다

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

단계별로

1. 수집 — terminal

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

task가 아닌 이유: 판단이 없습니다. 정해진 주소에서 받아 정해진 형식으로 저장하는 것뿐이라 명령이 싸고 결정적입니다.

2. 원고 — task

좋은 지시의 네 요소를 그대로 쓴 것입니다.

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

3. 음성 — terminal + 모델 API

원고를 문단 단위로 잘라 글 → 음성을 부릅니다.

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

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

4. 이미지 — terminal + 모델 API

원고의 [이미지: ...] 표시를 뽑아 이미지 생성을 부릅니다.

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

5. 렌더 — terminal

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

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

6. 점검 — task

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

이 설계의 판단들

왜 마지막에 사람이 있나

게시는 되돌릴 수 없는 동작입니다. 가드레일의 기준이 그대로 적용됩니다 — 되돌릴 수 있으면 자동, 없으면 사람.

왜 단계마다 파일로 남기나

왜 task가 두 개뿐인가

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

처음 2주

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

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

흔한 실패

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

다른 형태로 바꾸기

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

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

확인

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

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

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

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

막히는 것이 있으면 → 문제 해결 · 가이드 목차