오케스트레이션 개념과 지형도
멀티에이전트 오케스트레이션의 핵심 용어와 지형도를 정리하고, 단일 agent로 충분한 경우와 pipeline·parallelization·workflow가 필요한 시점을 판단 축 5가지로 구분합니다.
핵심 요약
- 오케스트레이션은 에이전트를 많이 붙이는 것이 아니라 불확실성이 큰 일을 역할·상태·통제로 분해하는 설계 방식입니다.
- 도구 1~2개로 끝나고 실패 비용이 낮으면 단일 agent + tool loop로 충분합니다. 멀티에이전트는 기본값이 아니라 비용과 장애 표면을 키우는 선택입니다.
- 단계 의존성·독립 실행·품질 판단·권한 분리·장기 실행이라는 판단 축 5가지로 pipeline, parallelization, evaluator-optimizer, orchestrator-workers, workflow를 고릅니다.
- Agent, Orchestrator, Worker, Tool, Handoff, State, Memory, Evaluator의 정의를 구분하고, 특히 state(복구 기록)와 memory(재사용 정보)를 분리합니다.
- 모델이 똑똑할수록 실패가 그럴듯해져 검증 루프가 더 중요해지고, 메모리는 양보다 무엇을 언제 불러올지 정하는 정책이 관건입니다.
오케스트레이션은 "에이전트를 많이 붙이는 것"이 아니라 불확실성이 큰 일을 역할, 상태, 통제로 분해하는 설계 방식입니다. 모델의 지능을 과신하지 않고 실패를 예측 가능한 단계로 쪼개는 게 핵심입니다.
언제 오케스트레이션을 고려하는가
| 상황 | 신호 | 권장 접근 |
|---|---|---|
| 단일 요청에 도구 1~2개만 필요함 | 입력과 출력이 짧고, 실패 비용이 낮음 | 단일 agent + tool loop |
| 작업이 조사, 실행, 검증으로 나뉨 | 단계별 책임과 성공 기준이 다름 | pipeline 또는 evaluator loop |
| 독립 작업을 동시에 처리할 수 있음 | 병렬 fan-out 시 지연을 줄일 수 있음 | parallelization |
| 도메인별 권한이 다름 | 회계, 배포, 고객 응대처럼 도구 접근권이 다름 | orchestrator-workers |
| 사람 승인 없이는 위험함 | 금전 이동, 프로덕션 변경, 외부 발송 | human-in-the-loop workflow |
| 실행 시간이 길고 중단/재개가 필요함 | 승인 대기, 외부 이벤트, 배치 처리 | durable workflow + checkpoint |
단일 에이전트로 충분한 경우
- 입력이 짧고 컨텍스트가 한 번에 들어간다.
- 실패해도 사람이 즉시 다시 시도할 수 있다.
- 도구 접근권을 세밀하게 나눌 필요가 없다.
- 결과물이 초안 수준이면 충분하다.
멀티에이전트가 기본값은 아닙니다
오케스트레이션은 품질, 보안, 지연 시간을 통제하려는 수단입니다. 단순한 작업에 멀티에이전트를 도입하면 토큰 비용과 장애 표면만 늘어납니다.
핵심 용어
| 용어 | 의미 | 실무 포인트 |
|---|---|---|
| Agent | 모델, 지시문, 도구, 출력 규약을 묶은 실행 단위 | "무엇을 할 수 있는가"보다 "무엇을 하면 안 되는가"를 함께 정의 |
| Orchestrator | 어떤 agent나 step를 언제 호출할지 결정하는 조정자 | 권한 분리와 state 관리의 중심 |
| Worker | 특정 역할에 최적화된 하위 agent 또는 step | 입력/출력 계약을 작게 유지 |
| Tool | 외부 시스템을 읽거나 쓰는 인터페이스 | API가 아니라 계약으로 설계 |
| Handoff | 한 agent가 다른 agent로 책임을 넘기는 행위 | 목표, 제약, 증거를 함께 넘겨야 함 |
| State | 현재 실행의 결정과 산출물 | 재실행과 복구를 위해 구조화 저장 |
| Memory | 실행 간 재사용되는 정보 | 대화 기억이 아니라 retrieval 정책 문제로 다룸 |
| Evaluator | 산출물을 판정하는 단계 | 생성과 평가를 분리해야 품질 루프가 작동 |
오케스트레이션 지형도
왼쪽으로 갈수록 단순하고 빠르지만 통제 포인트가 적고, 오른쪽으로 갈수록 강한 통제를 얻는 대신 설계 비용이 커집니다. 좋은 시스템은 처음부터 오른쪽 끝을 노리지 않습니다. 작은 루프를 검증하며 오른쪽으로 확장해 나갑니다.
판단 축 5가지
| 질문 | 의미 | 추천 패턴 |
|---|---|---|
| 단계 간 의존성이 강한가 | 이전 출력이 다음 입력을 결정하는가 | pipeline |
| 독립 실행이 가능한가 | 서로 다른 조사/분석을 동시에 수행할 수 있는가 | parallelization |
| 품질 판단이 어려운가 | 초안과 검증을 분리해야 하는가 | evaluator-optimizer |
| 권한과 책임이 분리되어야 하는가 | 서로 다른 시스템 접근권이 필요한가 | orchestrator-workers |
| 장기 실행과 재개가 필요한가 | 이벤트 대기, 승인, 재시도가 필요한가 | workflow |
패턴 선택 한 페이지 요약
| 지금 보이는 문제 | 먼저 검토할 해법 | 아직 과한 해법 |
|---|---|---|
| 단순 조회와 짧은 응답 | 단일 agent + tool loop | orchestrator-workers |
| 단계별 산출물이 중요 | pipeline | hierarchical |
| 독립 조사 작업이 많음 | parallelization | durable DAG |
| 권한이 다른 시스템을 만짐 | orchestrator-workers | 완전 자율 multi-agent |
| 승인 대기와 재개가 필요 | workflow + checkpoint | agent 간 자유 대화형 구조 |
흔한 오해
1. "모델이 똑똑하면 오케스트레이션이 필요 없다"
모델 성능이 높아질수록 오히려 실패가 더 그럴듯해지기 때문에 출력 계약, 근거 수집, 검증 루프가 중요해집니다.
2. "에이전트 수가 많을수록 품질이 올라간다"
실제로는 handoff 비용, 상태 동기화 비용, 디버깅 난이도가 함께 늘어납니다. 작업을 나누는 기준은 에이전트 개수가 아니라 책임 경계와 장애 격리입니다.
3. "메모리는 많을수록 좋다"
대부분의 문제는 기억이 부족해서가 아니라 무엇을 언제 불러와야 하는지 정하는 정책이 없어서 생깁니다. 불필요한 장기 메모리는 오답과 개인정보 노출 위험을 함께 키웁니다.
기본 설계 원칙
- 먼저 workflow를 설계하고, 그 안에 필요한 agent를 배치합니다.
- agent는 능력(capability)보다 책임(boundary)으로 나눕니다.
- tool은 모델 편의가 아니라 시스템 안전성을 기준으로 설계합니다.
- 상태는 "대화 로그"가 아니라 "복구 가능한 실행 기록"으로 저장합니다.
- 품질 평가는 생성 단계와 별도 루프로 둡니다.
ADR 스타일 결론
Decision
오케스트레이션은 단일 super-agent를 만드는 작업이 아니라, 불확실성을 작은 실행 단위와 검증 포인트로 분해하는 작업으로 정의합니다. 처음에는 단일 agent 또는 작은 workflow로 시작하고, 병렬화와 하위 agent는 명확한 필요가 생길 때만 추가합니다.
실무 체크리스트
- 이 문제를 단일 agent로 해결할 수 없는 구체적 이유가 있는가
- 단계 분해 기준이 "역할"이 아니라 "책임 경계"에 맞춰져 있는가
- 사람 승인과 자동 실행의 경계가 정의되어 있는가
- 장애가 났을 때 어디서 재시도하고 어디서 중단할지 정했는가
- 메모리와 상태를 구분해 저장 설계를 했는가