02_Orchestration
오케스트레이션 (Orchestration)
에이전트 설계의 기본 요소(모델, 도구, 지침)가 갖추어지면, 에이전트가 워크플로우를 효과적으로 실행할 수 있도록 하는 오케스트레이션 패턴을 고려할 수 있습니다.
점진적 접근 방식
복잡한 아키텍처를 가진 완전히 자율적인 에이전트를 즉시 구축하고 싶은 유혹이 있을 수 있지만, 고객들은 일반적으로 점진적인 접근 방식(incremental approach)을 통해 더 큰 성공을 거두었습니다.
오케스트레이션 패턴의 두 가지 범주
일반적으로 오케스트레이션 패턴은 크게 두 가지 범주로 나뉩니다:
- 단일 에이전트 시스템 (Single-agent systems):
- 하나의 모델이 적절한 도구(tools)와 지침(instructions)을 갖추고 루프(loop) 내에서 워크플로우를 실행합니다.
- 다중 에이전트 시스템 (Multi-agent systems):
- 워크플로우 실행이 여러 개의 조정된 에이전트에 걸쳐 분산됩니다.
1. 단일 에이전트 시스템 (Single-agent systems)
단일 에이전트는 도구를 점진적으로 추가함으로써 많은 작업을 처리할 수 있어, 복잡성을 관리하고 평가 및 유지보수를 단순화할 수 있습니다. 새로운 도구를 추가할 때마다 에이전트의 역량이 확장되며, 이는 여러 에이전트를 조기에 오케스트레이션할 필요를 없애줍니다.
루프 기반 실행
모든 오케스트레이션 접근 방식에는 '실행(run)'의 개념이 필요하며, 이는 일반적으로 종료 조건(exit condition)에 도달할 때까지 에이전트가 작동하도록 하는 루프(loop)로 구현됩니다.
- 일반적인 종료 조건: 도구 호출(tool calls), 특정 구조화된 출력(structured output), 오류 발생, 또는 최대 턴(turn) 수 도달 등이 있습니다.
- 예를 들어, Agents SDK에서는
Runner.run()메서드를 사용하여 에이전트를 시작하며, 다음 중 하나가 발생할 때까지 LLM을 반복합니다:- 특정 출력 유형으로 정의된 최종 출력 도구(final-output tool)가 호출될 때.
- 모델이 도구 호출 없이 응답(예: 사용자에게 직접 메시지)을 반환할 때.
복잡성 관리 전략: 프롬프트 템플릿
다중 에이전트 프레임워크로 전환하지 않고 복잡성을 관리하기 위한 효과적인 전략은 프롬프트 템플릿(prompt templates)을 사용하는 것입니다.
- 사용 방식: 여러 개별 프롬프트를 유지하는 대신, 정책 변수(policy variables)를 수용하는 단일하고 유연한 기본 프롬프트(single flexible base prompt)를 사용합니다.
- 이점: 이 템플릿 접근 방식은 다양한 컨텍스트에 쉽게 적응할 수 있어 유지보수 및 평가를 크게 단순화합니다. 새로운 사용 사례가 발생하면 전체 워크플로우를 다시 작성하는 대신 변수를 업데이트할 수 있습니다.
2. 다중 에이전트 시스템 (Multi-agent systems)
일반적인 권장 사항은 단일 에이전트의 역량을 먼저 최대화하는 것입니다. 에이전트 수가 많아지면 개념 분리가 직관적일 수 있지만, 추가적인 복잡성과 오버헤드가 발생할 수 있으므로, 도구를 가진 단일 에이전트만으로도 충분한 경우가 많습니다.
하지만 복잡한 워크플로우의 경우, 프롬프트와 도구를 여러 에이전트에 분할하는 것이 성능과 확장성 향상에 도움이 될 수 있습니다. 특히 에이전트가 복잡한 지침을 따르는 데 실패하거나 일관되게 잘못된 도구를 선택할 때, 시스템을 더 세분화하고 구별되는 에이전트를 도입해야 할 수 있습니다.
다중 에이전트 분할을 고려해야 할 때
- 복잡한 로직: 프롬프트가 많은 조건문(다중 if-then-else 분기)을 포함하고, 프롬프트 템플릿의 확장이 어려워질 때, 각 논리적 세그먼트를 개별 에이전트로 분할하는 것을 고려해야 합니다.
- 도구 과부하 (Tool overload): 단순히 도구의 수가 많은 것만이 아니라, 도구들의 유사성 또는 중복(similarity or overlap)이 문제일 수 있습니다. 도구에 설명적인 이름, 명확한 매개변수, 상세한 설명을 제공하여 명확성을 높였음에도 성능이 향상되지 않는다면, 여러 에이전트를 사용해야 합니다.
다중 에이전트 오케스트레이션 패턴
다중 에이전트 시스템은 요구 사항에 따라 다양하게 설계될 수 있지만, 소스에서는 광범위하게 적용 가능한 두 가지 범주를 강조합니다:
- 관리자 패턴 (Manager pattern, agents as tools):
- 중앙의 "관리자(manager)" 에이전트가 도구 호출을 통해 여러 전문화된 에이전트를 조정합니다.
- 각 전문화된 에이전트는 특정 작업이나 도메인을 처리합니다.
- 관리자는 컨텍스트나 제어를 잃지 않고 적절한 시점에 올바른 에이전트에게 작업을 지능적으로 위임하며, 그 결과를 응집력 있는 상호 작용으로 종합합니다.
- 이 패턴은 하나의 에이전트만 워크플로우 실행을 제어하고 사용자에게 접근하기를 원할 때 이상적입니다.
- 분산 패턴 (Decentralized pattern, agents handing off to agents):
- 여러 에이전트가 동등한 위치(peers)에서 작동하며, 자신의 전문 분야에 따라 서로에게 작업 실행을 핸드오프(handoff)합니다.
- 핸드오프(Handoff)는 에이전트가 다른 에이전트에게 위임하는 단방향 전송입니다.
- 이 패턴은 단일 에이전트가 중앙 통제나 종합을 유지할 필요가 없을 때 최적이며, 대신 각 에이전트가 실행을 인계받아 필요에 따라 사용자와 상호 작용할 수 있도록 허용합니다.
- 이는 대화 분류(conversation triage)와 같은 시나리오나, 원래 에이전트가 계속 관여할 필요 없이 전문 에이전트가 특정 작업을 완전히 인계받기를 원할 때 특히 효과적입니다.
참고: 오케스트레이션 패턴에 관계없이, 구성 요소는 유연하고 조합 가능해야 하며, 명확하고 잘 구조화된 프롬프트에 의해 구동되어야 합니다. 다중 에이전트 시스템은 그래프로 모델링될 수 있으며, 에이전트는 노드로, 관리자 패턴에서의 에지는 도구 호출을, 분산 패턴에서의 에지는 에이전트 간의 실행 전송(handoff)을 나타냅니다.
