예약으로 파이프라인 만들기

이 장에서 배우는 것 예약의 두 종류와 각각을 언제 쓰는지, 그리고 여러 단계를 잇는 법.

두 종류입니다

예약 실행에서는 업무 예약만 다뤘습니다. 실제로는 두 가지입니다.

이 구분이 파이프라인 설계의 핵심입니다.

언제 무엇을 쓰나

graph TD
  Q["이 단계는 어느 쪽?"] --> Q1{"매번 판단이 필요한가?"}
  Q1 -->|"예"| T["task<br/>에이전트"]
  Q1 -->|"아니오"| Q2{"명령 한 줄로 되나?"}
  Q2 -->|"예"| S["terminal<br/>명령"]
  Q2 -->|"아니오"| T

판단이 없는 단계에 task를 쓰지 마세요. 에이전트를 부르면 비용이 들고 결과가 매번 조금씩 다릅니다. terminal은 싸고 결정적입니다.

이건 Phase 1의 AI 적합성 평가와 같은 판단입니다 — 규칙으로 100% 표현되면 AI를 쓸 이유가 없습니다.

예약 하나 만들기

새 예약에 넣는 것들입니다.

주기는 예약 실행 장에서 본 그대로입니다 — 분·시간·매일· 평일·매주·매월, 또는 크론 식 직접 입력.

여러 단계를 잇는 법

여기가 이 장의 본론입니다. 예약 하나는 한 단계입니다. 파이프라인은 여러 단계를 이어야 합니다.

방법 1 — 시차를 둔다 (가장 단순)

장점: 단순합니다. 각 단계가 독립적이라 하나가 실패해도 나머지가 돕니다. 단점: 앞 단계가 늦어지면 뒷 단계가 빈손으로 돕니다.

그래서 각 단계가 전제를 확인해야 합니다.

예약 실행 장에서 "전제 조건을 확인하게 하라"고 한 것이 파이프라인에서는 필수가 됩니다.

방법 2 — 한 단계가 다음을 부른다

terminal 단계의 명령 안에서 REST API로 다음 업무를 만듭니다.

장점: 앞이 끝나야 뒤가 돕니다. 빈손 실행이 없습니다. 단점: 열쇠가 스크립트에 들어갑니다. 환경변수로 빼세요.

방법 3 — 한 업무가 전부 한다

지시문 하나에 여러 단계를 담고 에이전트가 알아서 진행하게 합니다.

대개 권하지 않습니다. 컨텍스트가 차서 뒤로 갈수록 일관성이 떨어지고, 어느 단계에서 실패했는지 알기 어렵습니다. 마이크로 스프린트의 원칙이 여기도 적용됩니다 — 나누면 각자 깨끗한 컨텍스트에서 시작합니다.

파이프라인 설계 원칙

1. 단계마다 산출물을 파일로 남기세요

중간 산출물이 파일로 있으면 실패한 단계부터 다시 돌릴 수 있습니다. 메모리로만 넘기면 처음부터입니다.

번호를 붙이는 이유는 순서가 보이기 때문입니다.

2. 이미 있는 것은 건너뛰게 하세요

50개 중 3개가 실패했을 때 3개만 다시 만들 수 있습니다.

3. 실패를 알리게 하세요

가장 자주 빠뜨립니다. 조용히 실패하면 몇 주 뒤에 발견합니다.

4. 자율성은 낮게 시작하세요

파이프라인은 아무도 안 보는 시간에 돕니다. 자율성 수준을 처음부터 전부 자동으로 두지 마세요.

비용이 누적됩니다

매일 도는 파이프라인은 한 번 비용 × 30입니다.

줄이는 순서는 정해져 있습니다.

1번이 가장 효과적입니다. 형식 변환을 에이전트에게 시키고 있었다면 명령 하나로 바꾸는 것만으로 그 단계 비용이 0이 됩니다.

관리

예약이 늘어나면 관리가 필요합니다.

세 번째가 파이프라인 특유의 문제입니다. 수집이 몇 주째 실패했는데 원고 작성이 계속 돌면서 빈 결과를 만들고 있을 수 있습니다.

확인

1. task와 terminal 예약을 어떻게 구분합니까?

2. 중간 산출물을 파일로 남겨야 하는 이유는?

3. 파이프라인 비용을 줄이는 가장 효과적인 방법은?

세 단계짜리를 직접 만들고 가운데를 깨뜨려봅니다. 60분입니다 → 파이프라인 하나를 끝까지 만들어보기