테마
15. 에이전트 오케스트레이션과 고급 시스템 설계
한 번의 프롬프트로 해결되지 않는 문제를 다루기 시작하면, 이제 질문 설계가 아니라 시스템 설계가 시작된다.
1. 언제 단일 프롬프트로는 부족할까?
단일 프롬프트는 여전히 강력하다.
하지만 아래 조건이 겹치면 한 번의 호출만으로는 버거워진다.
- 해야 할 단계가 여러 개다
- 외부 도구를 호출해야 한다
- 중간 결과를 검증해야 한다
- 여러 관점을 병렬로 비교해야 한다
- 실패했을 때 부분 재시도가 필요하다
즉, 오케스트레이션은 "멋있어 보여서"가 아니라 문제 구조가 복잡해졌기 때문에 등장한다.
핵심은 항상 단순한 해법부터 시작하는 것이다.
오케스트레이션은 필요할 때만 들어가야 한다.
2. 에이전트 오케스트레이션이란 무엇인가?
쉽게 말하면 하나의 모델이 모든 걸 다 하게 두지 않고, 역할을 나눠 협력하게 만드는 구조다.
예:
- 라우터: 요청 종류를 분류
- 플래너: 해야 할 단계를 쪼갬
- 워커: 각 단계 실행
- 검증기: 결과를 검사
- 요약기: 최종 사용자 응답으로 정리
이 구조의 목적은 "더 똑똑해 보이게"가 아니라 작업 분리와 실패 통제다.
3. 자주 쓰는 구성요소
| 구성요소 | 역할 |
|---|---|
| Router | 어떤 경로로 처리할지 결정 |
| Planner | 작업을 단계로 분해 |
| Worker | 실제 작업 수행 |
| Retriever | 필요한 문서나 근거 수집 |
| Tool Executor | 검색, 계산, DB 조회 등 외부 도구 호출 |
| Verifier | 결과의 형식, 근거, 정책 위반 여부 점검 |
| Memory / State | 중간 상태와 결정 사항 보관 |
| Human Gate | 고위험 단계에서 사람 승인 받기 |
이 중 모든 요소가 항상 필요한 것은 아니다.
필요한 만큼만 조합해야 한다.
4. 전체 구조를 크게 보면 이렇게 된다
이 그림에서 중요한 것은 하나다.
에이전트는 마법이 아니라, 입력 계층, 조정 계층, 도구 계층을 나눈 시스템이다.
5. 대표적인 오케스트레이션 패턴
5.1 선형 체인
A가 끝나면 B, B가 끝나면 C를 수행한다.
구조가 단순하고 디버깅이 쉽다.
5.2 Planner-Worker
플래너가 일을 쪼개고 여러 워커가 맡는다.
복잡한 작업에 강하지만 상태 관리가 필요하다.
5.3 Fan-out / Fan-in
여러 관점을 병렬로 실행한 뒤 하나로 모은다.
비교 분석, 리뷰, 후보안 생성에 좋다.
5.4 Reviewer Loop
생성기와 검토기를 반복시켜 품질을 끌어올린다.
앞에서 본 Generator/Discriminator의 시스템 버전이라고 볼 수 있다.
즉, 오케스트레이션은 새로운 개념이라기보다, 우리가 앞에서 배운 기법들을 시스템 수준으로 올린 것에 가깝다.
6. 실제 실행 흐름은 이런 식으로 흘러간다
여기서 중요한 포인트는 Verifier다.
오케스트레이션이 복잡해질수록 중간 검증 없이 진행하면 오답이 누적되기 쉽다.
7. 고급 시스템 설계에서는 무엇이 중요할까?
7.1 상태 관리
누가 어떤 결정을 내렸는지, 어떤 도구 결과를 썼는지 남겨야 한다.
상태가 없으면 디버깅도 재현도 어렵다.
7.2 중단 조건
루프가 언제 끝나야 하는지 명확해야 한다.
- 재시도 횟수 제한
- 시간 제한
- 비용 제한
- 품질 기준 도달 시 종료
7.3 권한 경계
모든 워커가 모든 도구를 쓰게 두면 위험하다.
역할마다 접근 가능한 도구와 데이터 범위를 제한해야 한다.
7.4 관측 가능성
어디서 실패했는지 보여야 한다.
- 라우팅 실패
- 도구 오류
- 검증 실패
- 시간 초과
7.5 사람 개입 지점
고위험 작업에서는 자동 진행보다 중간 승인 지점이 더 중요하다.
8. 언제 오케스트레이션을 쓰지 말아야 할까?
복잡한 설계는 항상 비용이 든다.
아래 상황이라면 단일 프롬프트나 단순 체인이 더 낫다.
- 답변이 짧고 구조가 단순하다
- 외부 도구 호출이 거의 없다
- 실패 시 사람이 바로 다시 시도해도 된다
- 지연 시간과 비용이 매우 중요하다
즉, 오케스트레이션은 성능 향상 도구이기도 하지만 동시에 복잡도 증가 장치이기도 하다.
9. 자주 하는 실수
9.1 처음부터 멀티에이전트로 시작한다
단일 프롬프트로 충분한 문제도 괜히 복잡해진다.
9.2 라우터와 검증기가 약하다
분배가 잘못되거나 검증이 빠지면 여러 에이전트가 있어도 오히려 더 나빠질 수 있다.
9.3 상태를 남기지 않는다
중간 결정이 남지 않으면 실패 원인을 찾기 어렵다.
9.4 중단 조건이 없다
리뷰 루프가 끝없이 돌거나, 비용이 예상보다 크게 늘어난다.
9.5 도구 권한을 과하게 열어둔다
편해서 좋을 것 같지만 보안과 안정성이 급격히 나빠진다.
10. 공부할 때 이렇게 이어서 보면 좋다
07 경쟁과 피드백 루프: 생성기-검토기 구조의 기초09 프롬프트 보안과 방어 관점: 입력 신뢰 구간과 권한 분리13 개발과 서비스 구현 관점: 프롬프트를 코드와 운영으로 보는 관점14 조직 적용과 운영 정책, 평가 자동화: 운영과 평가 루프
즉, 에이전트 오케스트레이션은 독립된 마법 기술이 아니라, 앞선 문서들의 개념을 분산 시스템처럼 엮은 결과다.
핵심 정리
- 에이전트 오케스트레이션은 한 번의 프롬프트로 처리하기 어려운 문제를 역할 분리로 다루는 방식이다
- Router, Planner, Worker, Verifier, Tool Executor, State 관리가 기본 구성요소다
- 고급 시스템 설계에서는 상태 관리, 중단 조건, 권한 경계, 관측 가능성이 핵심이다
- 멀티에이전트는 강력하지만 복잡도와 비용을 함께 올리므로, 단순한 해법이 충분한지 먼저 확인해야 한다