에이전트 루프와 오케스트레이션 5패턴
순차·병렬·분기·반복 루프·오케스트레이터 역할 분리 — 스킬을 조합해 복잡한 업무를 자동 처리하는 다섯 가지 핵심 패턴
한 줄 요약
오케스트레이션은 "여러 스킬을 어떤 순서로 어떻게 엮는가"입니다. 5가지 패턴을 기억하세요: 순차 · 병렬 · 분기 · 반복 루프 · 오케스트레이터 역할 분리. 복잡한 스킬은 이 5개의 조합일 뿐입니다.
5 패턴 한눈에
flowchart LR P1[1 순차] --> P2[2 병렬] P2 --> P3[3 분기] P3 --> P4[4 반복 루프] P4 --> P5[5 오케스트레이터]
패턴 1 — 순차 (Sequential)
가장 단순. A 가 끝나면 B, B 가 끝나면 C.
flowchart LR A[스킬 A] --> B[스킬 B] --> C[스킬 C]
언제 쓰나: B가 A의 출력을 입력으로 요구할 때. 예: 웹 크롤링 → 요약 → 아카이브 저장.
함정: 각 단계가 직렬이라 총 시간 = 단계 합. 한 곳 실패하면 전체 실패.
패턴 2 — 병렬 (Parallel)
의존이 없는 작업들을 동시에 실행.
flowchart TD S[시작] --> A[스킬 A] S --> B[스킬 B] S --> C[스킬 C] A --> M[합치기] B --> M C --> M
언제 쓰나: 서로의 결과를 기다릴 필요가 없을 때. 예: 환율 조회 + ETF 조회 + 뉴스 수집을 동시에 → 전부 도착하면 1장 카드로 합침.
함정: "병렬로 할 수 있다"고 판단하는 건 사람의 몫입니다. A가 B의 결과를 필요로 하는데 병렬로 돌리면 B는 없는 값을 읽게 됩니다.
체크리스트:
- 이 작업들은 서로의 출력을 참조하지 않는다
- 동일한 외부 API 에 동시 호출해도 rate limit 에 안 걸린다
- 결과를 합칠 지점(merge point)이 명확하다
패턴 3 — 분기 (Branching)
조건에 따라 다른 경로로 진행.
flowchart TD
A[데이터 수집] --> Q{"조건"}
Q -->|경우 1| B[경로 B]
Q -->|경우 2| C[경로 C]
Q -->|경우 3| D[경로 D]
B --> M[결과 합치기]
C --> M
D --> M
언제 쓰나: 입력 특성에 따라 처리가 달라질 때. 예:
- 환율 변동폭 ≥ 1% → 뉴스 추가 수집 / 미만 → 기본 카드
- 파일 확장자 → PDF 스킬 / eml → 이메일 스킬 / xlsx → 엑셀 스킬
- 긴급도 '높음' → 즉시 알림 / '일반' → 배치 요약
포인트: 분기의 기준을 명확하게 수치화 해야 합니다. "중요하면" 같은 모호한 기준은 재현성이 깨집니다.
패턴 4 — 반복 루프 (Agent Loop)
목표가 달성될 때까지 도구 호출을 자동 반복. 이것이 "에이전트"라는 단어의 핵심입니다.
flowchart LR
S[시작] --> T[도구 호출]
T --> C{"목표 달성?"}
C -->|예| D[완료]
C -->|아니오 + 재시도 가능| T
C -->|아니오 + 한계 도달| F[실패 보고]
언제 쓰나:
- 외부 API 가 간헐적으로 실패 → 재시도
- 첫 검색 결과가 부족 → 다른 쿼리로 재검색
- 생성한 결과가 품질 기준에 미달 → 개선 후 재시도
반드시 있어야 할 것:
- 종료 조건 (성공 시 / 최대 시도 도달 시)
- 재시도 간격 (일반적으로 exponential backoff)
- 실패 기록 (왜 실패했는지 로그)
함정 — 무한 루프: 종료 조건이 명확하지 않으면 끝없이 돕니다. 반드시 최대 시도 횟수(예: 3회)를 두세요.
패턴 5 — 오케스트레이터 역할 분리
지금까지 4개는 한 스킬 안에서 흐름을 정의했습니다. 패턴 5는 상위 에이전트가 여러 스킬을 지휘하도록 책임을 위로 올립니다.
flowchart TD O["오케스트레이터 지휘자"] --> S1[스킬 1: 수집] O --> S2[스킬 2: 분석] O --> S3[스킬 3: 작성] O --> S4[스킬 4: 발송] S1 --> O S2 --> O S3 --> O S4 --> O O --> F[최종 보고]
차이점:
- 패턴 1~4: 작업 흐름이 스킬 안에 박혀 있음. 재사용 시 수정 필요.
- 패턴 5: 스킬들은 "무엇을 하는가"만 정의. 오케스트레이터가 "어떤 순서로, 어떤 조건에서" 부를지 결정.
장점:
- 스킬이 다른 맥락에서도 재사용 가능
- 오케스트레이션 변경이 스킬 수정을 요구하지 않음
- 거버넌스·감사가 오케스트레이터 한 곳에 집중
예 — Track D 세법 개정 체인:
- 스킬 1:
web-reader— 공지 크롤링 - 스킬 2:
notice-digest— 공지 요약 + 업종 분류 - 스킬 3:
client-matcher— 고객 DB 대조 - 스킬 4:
docx-filler— 맞춤 안내문 생성 - 스킬 5:
telegram-notify— 알림 발송
이 5개 스킬은 Track D 외에도 다른 시나리오에서 재사용됩니다. 오케스트레이터 스킬 tax-law-chain 이 순서를 정하고 분기·반복·실패 처리를 담당.
5 패턴 조합 — 실전 예시
Track B 일일 시장 브리핑
flowchart TD
T[08:50 트리거] --> P[병렬 수집 · 패턴 2]
P --> W[web-reader]
P --> X[exchange-rate]
P --> Y[etf-naver]
W --> R[수집 실패? · 패턴 4]
X --> R
Y --> R
R -->|재시도 성공| M[양식 합치기 · 패턴 1]
R -->|한계 도달| E[실패 섹션 표시 · 패턴 3]
E --> M
M --> D{"변동폭 ≥ 1% · 패턴 3"}
D -->|예| N[뉴스 추가]
D -->|아니오| S[기본 카드]
N --> S
S --> G[텔레그램 발송]
- 패턴 1 (순차) — 수집 → 합치기 → 발송
- 패턴 2 (병렬) — 3종 API 동시 호출
- 패턴 3 (분기) — 변동폭 기반 뉴스 추가 여부
- 패턴 4 (루프) — 실패 시 재시도
- 패턴 5 는 이 수준에서는 필요 없음. 하나의 스킬 안에서 흐름이 완결.
Track D 세법 개정 체인
복잡도가 더 높아 패턴 5 오케스트레이터가 등장합니다. 5개 하위 스킬이 조합되어 End-to-End 자동화를 완성. 위에서 설명한 예시 참고.
컨텍스트 관리와 출력 형식 약속
오케스트레이션 품질은 두 가지 외곽 원칙으로 결정됩니다.
컨텍스트 관리
매 단계마다 다음 단계에 필요한 최소 정보만 넘깁니다. 전체를 주면 토큰 낭비 + 품질 저하.
나쁨: 수집된 뉴스 전체(10,000자) → 요약 스킬에 통째로
좋음: 뉴스 제목 + 요약 5줄(500자) → 요약 스킬
출력 형식 약속
각 단계의 출력 포맷을 사전에 고정 합니다. 다음 단계가 이 포맷을 전제로 설계됩니다.
# 수집 단계의 출력 스키마
collection_result:
items:
- title: string
url: string
published_at: date
summary_3_lines: string
key_numbers: map<string, string>
collected_at: datetime
이런 약속이 있어야 단계 교체(예: web-reader 대신 새 크롤러)가 가능해집니다.
자주 묻는 질문
Q. 5 패턴 중 어떤 걸 먼저 배워야 하나요?
A. 순차 → 병렬 → 분기 순서. 이 3개만 알아도 실무의 80%를 커버합니다. 반복 루프와 오케스트레이터는 복잡한 체인을 만들 때 도입.
Q. 병렬 처리가 항상 빠른가요?
A. 아닙니다. 병렬의 장점은 대기 시간이 겹칠 때 발휘됩니다. 각 작업이 CPU·메모리 집약적이면 병렬이 오히려 느릴 수 있습니다. 외부 API 호출처럼 "기다리는 시간이 대부분"인 경우에 효과적입니다.
Q. 재시도 루프가 무한히 돌면 어떻게 하죠?
A. 최대 시도 횟수(3 ~ 5회)와 최대 경과 시간(예: 5분) 이중 제한을 두세요. 둘 중 하나라도 먼저 걸리면 중단하고 실패 보고.
Q. 오케스트레이터도 AI 인가요, 코드인가요?
A. Claude 의 경우 오케스트레이터도 AI(스킬로 구현)입니다. 코드 기반 오케스트레이터(예: Airflow, n8n)도 가능하지만 AI 기반이 더 유연합니다. 조건이 바뀌면 스킬 수정만으로 대응 가능.
다음 읽을거리
변경 이력
- v1 (2026-04-11): 최초 작성 — Claude@IGM Cohort 1 교재용