생성형 오케스트레이션은 또한 한 에이전트가 다른 에이전트를 호출하는 멀티 에이전트 시스템을 지원합니다. 문제를 여러 전문 에이전트로 나누면 애플리케이션을 더 모듈화하고, 확장 가능하며, 관리하기 쉽게 만듭니다.
인라인 에이전트
인라인 에이전트(자식 에이전트라고도 함)는 동일한 에이전트 내에 있는 작고 재사용 가능한 워크플로입니다. 이들은 주로 메인 에이전트가 서브루틴으로 사용하는 토픽일 뿐입니다. 예를 들어, 메인 에이전트는 더 큰 계획의 한 단계로 "텍스트 번역" 토픽을 호출할 수 있습니다. 인라인 에이전트는 메인 에이전트와 컨텍스트를 공유하므로 데이터 주고받기가 간단합니다.
모범 사례: 인라인 에이전트는 단일 책임에 집중하고 철저히 테스트하세요.
연결된 에이전트
연결된 에이전트는 자체적인 오케스트레이션, 도구, 지식을 가진 독립적인 에이전트입니다. 주 에이전트는 요청의 일부를 자식 에이전트에게 위임합니다. 예를 들어, IT 에이전트가 가격 정보를 얻기 위해 영업 에이전트에게 요청을 보냅니다. 연결된 에이전트는 모듈화와 도메인 분리를 지원하며, 계획 제한을 우회할 수 있습니다. 이들 에이전트는 서로 다른 권한이나 지식을 가질 수 있으므로, 거버넌스와 감사 통제를 적용하세요.
하지만 연결된 에이전트를 사용할 때는 신중한 거버넌스가 필요합니다.
오케스트레이션:: 상위 오케스트레이터는 연결된 에이전트에게 언제 인계할지에 대한 명확한 기준을 가지고 있어야 합니다. 오케스트레이터는 사용자의 의도가 연결된 에이전트의 도메인과 일치할 때 보통 핸드오프를 합니다. 이 과정을 돕기 위해, 부모 에이전트의 설정에서 연결된 에이전트의 목적을 명확히 설명하세요. 부모 에이전트의 관점에서 전체 연결 에이전트를 설명이 포함된 에이전트형 "도구"로 간주하세요.
데이터 핸드오프: 데이터 핸드오프를 관리해야 합니다. 상위에서 연결된 에이전트로 전달할 컨텍스트를 결정합니다. Copilot Studio는 한 에이전트가 다른 에이전트를 호출할 때 기본적으로 대화 기록을 전달하므로, 연결된 에이전트가 이전 대화의 맥락을 이해할 수 있습니다. 하지만 특정 매개 변수를 전달해야 할 수도 있습니다. 예를 들어, 메인 에이전트가 이미 사용자 이름을 알고 있다면, 다시 물어보지 않기 위해 그 이름을 연결된 에이전트에게 보낼 수 있습니다.
보안: 연결된 에이전트는 부모 에이전트가 가지지 않은 권한을 가질 수 있습니다. 연결된 에이전트를 호출하는 과정에서 의도치 않게 제한을 우회하지 않도록 하세요. 예를 들어, 부모 에이전트에게 기록 삭제 권한이 없지만 연결된 에이전트에게는 있다면, 적절한 승인 없이 삭제가 이루어질 수 있는 경우에는 부모 에이전트가 연결된 에이전트를 호출해서는 안 됩니다. 연결된 에이전트 호출을 다른 중요한 작업과 마찬가지로 신중하게 처리하세요. 민감한 작업을 한다면, 필수적인 검토 절차나 사용자 동의를 반드시 거치세요.
감사 및 모니터링: 연결된 에이전트가 호출된 시점과 수행한 작업을 기록하세요. 별도의 에이전트이므로, 해당 에이전트의 대화록도 별도로 보관됩니다. 디버깅을 위해 부모 세션과 연결된 세션을 서로 연관시키는 것이 중요합니다. 일반적으로 원격 분석 내 식별자는 두 장치를 연결합니다.
에이전트 분리 시기
모든 하위 작업마다 별도의 에이전트를 생성하지 마십시오. 작업이 다음 조건에 해당하는 경우에는 별도의 에이전트를 사용하십시오.
- 자체적인 도구나 지식(별도의 전문 분야)이 필요할 만큼 복잡한지 여부
- 메인 에이전트와는 다른 거버넌스 규칙 또는 액세스 제어가 필요합니다
- 다양한 메인 에이전트에서 재사용할 수 있습니다(따라서 서비스 에이전트와 유사합니다)
이 조건들이 모두 해당되지 않는다면, 단순한 인라인 에이전트가 작업을 효과적으로 처리할 수 있으며, 완전한 연결된 에이전트보다 더 간단할 수 있습니다. 별도의 에이전트는 시스템에 오버헤드를 초래합니다. 컨텍스트 전환과 여러 에이전트 관리의 복잡성으로 인해 실행 시간이 다소 길어집니다. 따라서 신중하게 사용하는 것이 좋습니다. 실용적인 접근을 위해 하나의 에이전트부터 시작하세요. 그렇기 때문에 모듈화가 필요하거나 하나의 에이전트가 넘지 말아야 할 경계가 분명할 때에만 여러 에이전트로 분리하세요.
멀티 에이전트 오케스트레이션의 모범 사례
멀티 에이전트 환경에서 부모 에이전트와 하위 에이전트의 지침을 작성할 때 다음 모범 사례가 적용됩니다.
1. 단일 응답 원칙
매 턴마다 한 에이전트만 사용자에게 응답하도록 하세요. 멀티 에이전트 환경에서는 오직 부모 에이전트만이 사용자에게 최종 응답을 전달해야 합니다. 서브에이전트는 응답자가 아니라 연구자입니다.
- 해야 할 일: 부모 에이전트 지침에 다음을 추가: "사용자와 소통하는 유일한 에이전트는 당신입니다. 모든 하위 에이전트의 결과를 하나의 응답으로 통합하세요."
- 하지 말아야 할 일: 지침을 모호하게 남겨두지 마세요. 명시적인 지침이 없으면 서브에이전트가 사용자에게 직접 응답하여 중복 또는 부분적인 메시지가 발생합니다.
2. 서브에이전트 지침은 자신의 역할을 선언해야 합니다
항상 서브에이전트에게 자신이 서브에이전트라고 말하세요. 서브에이전트는 자신들이 오케스트레이션의 일부라는 사실을 본질적으로 알지 못합니다. 명시적인 지침 없이는 독립적인 에이전트처럼 행동하며 사용자에게 직접 메시지를 보냅니다.
- 해야 할 일: 모든 서브에이전트의 지침에 다음을 추가하세요: "당신은 서브에이전트입니다. 사용자에게 직접 응답하지 마세요. 당신의 임무는 정보를 검색하여 그 결과를 부모 에이전트에게 전달하는 것입니다. 부모 에이전트가 사용자와의 모든 통신을 처리하세요."
- 하지 말아야 할 일: 하위 에이전트가 오케스트레이션 패턴을 스스로 파악한다고 가정하지 마세요.
3. 지침 작성 시 명확하고 직접적인 언어 사용
항상 지시형 언어를 사용하세요 완곡하거나 정중한 표현은 피합니다. 플랫폼은 강력한 언어(MUST, DO NOT, NEVER)를 사용하여 시스템 수준 지침을 삽입합니다. 완곡하거나 정중한 표현("해주세요", "해야만 합니다", "하는 것이 좋습니다")으로 작성된 지침은 충돌할 경우 우선순위에서 밀립니다.
- 해야 할 일: "절대 사용자에게 직접 응답하지 마세요. 조사 결과만 반환하십시오."
- 해야 할 일: "사용자 질문마다 반드시 하나의 최종 응답만 있어야 합니다."
- 하지 말아야 할 일: "사용자에게 메시지를 보내는 것을 피하고 대신 발견한 내용을 반환해 주세요."
- 하지 말아야 할 일: "이상적으로는 단일 통합 답변을 원합니다."
4. 각 하위 에이전트마다 하나의 참조 자료 원본을 사용하세요(중복되지 않도록)
각 하위 에이전트에 겹치지 않는 고유한 참조 자료 원본을 할당하세요. 두 하위 에이전트가 동일한 지식 베이스를 검색하면, 한 하위 에이전트가 먼저 답을 찾습니다. 두 번째 하위 에이전트는 중복 결과를 반환하거나 아예 검색을 건너뛰어 아무런 가치를 더하지 않습니다.
- 해야 할 일: CA-1은 참조 자료 원본 A(예: HR 정책)를 검색합니다. CA-2는 참조 자료 원본 B(예: IT 자료)를 검색합니다.
- 하지 말아야 할 일: 두 하위 에이전트에게 동일한 문서, Dataverse 테이블 또는 SharePoint 사이트에 대한 접근 권한을 부여하지 마세요.
- 참고: 참조 자료 원본이 하나뿐이라면, 두 개의 하위 에이전트로 나누지 말고 지식이 있는 단일 에이전트를 사용하세요. 멀티 에이전트 방식은 정보원들이 진정으로 서로 다를 때에만 가치를 더합니다.
5. 하위 에이전트에 대해 정확하고 구체적인 설명 사용
부모 에이전트가 볼 수 있는 각 하위 에이전트에 대해 명확하고 구분된 설명을 작성하세요. 부모 에이전트는 하위 에이전트 설명을 바탕으로 경로를 결정합니다. 설명이 모호하거나 동일하거나 부정확하면 부모가 올바른 라우팅 결정을 내릴 수 없습니다.
- 해야 할 일: CA-1: "직원 관련 질문을 위해 인사 정책 문서를 검색하세요." CA-2: "기술 지원 질문을 찾기 위해 IT 참조 자료를 검색하세요."
- 하지 말아야 할 일: 두 에이전트가 서로 다른 도메인을 담당할 때 같은 설명을 제공하지 마세요.
- 하지 말아야 할 일: "이 에이전트는 문의 사항에 도움을 드릴 수 있습니다"와 같은 일반적인 설명을 사용하세요.
6. 부모 지침은 오케스트레이션 패턴을 정의해야 합니다
부모 에이전트에게 오케스트레이션 방법을 지시하세요. 단순히 '자식 에이전트를 사용하라'고만 말하지 마세요. 부모 에이전트에는 명확한 패턴에 대한 지시가 필요합니다: 에이전트를 호출하고, 결과를 기다린 후, 결합하여 응답하세요.
- 해야 할 일: "사용자가 질문을 할 때: 1. 정보를 수집하기 위해 두 자식 에이전트를 모두 호출합니다. 2. 두 하위 에이전트가 결과를 반환할 때까지 기다립니다. 3. 결과를 하나로 통합하여 단일 응답을 만드세요. 4. 사용자에게 단 하나의 응답만 전달하세요. 하위 에이전트는 사용자에게 직접 회신해서는 안 됩니다."
- 하지 말아야 할 일: "사용자가 질문을 하면 하위 에이전트를 호출하여 두 출처로부터 응답을 받아낸 뒤, 이를 하나로 통합된 답변으로 제공하십시오." (너무 모호함. 지시가 하위 에이전트에게 응답하지 말라고 명시하지 않음.)
7. 업무 위임 시 '직접 회신 금지' 지침을 포함하십시오
명확한 하위 에이전트 지침이 있더라도, 위임된 작업에 지시를 강화하여 추가로 명확히 하면 안전망 역할을 합니다.
- 해야 할 일: 부모 지침에 다음을 추가하세요: "자식 에이전트에 작업을 위임할 때는 항상 '결과만 반환하라'는 내용을 포함하세요. 사용자에게 응답하지 마세요.”
- 하지 말아야 할 일: 전적으로 하위 에이전트의 지시에만 의존하십시오. 작업 맥락은 하위 에이전트가 패턴을 강화할 수 있도록 더 많은 신호를 제공합니다.
8. 도메인-불일치 쿼리로 테스트하기
모든 하위 에이전트의 도메인에 해당하지 않는 질문으로 항상 테스트하세요. 이 테스트를 통해 서브에이전트가 "정보 없음"을 제대로 응답하는지, 아니면 잘못된 정보를 반환하거나, 멈추거나, 혼란스러운 메시지를 보내는지 확인할 수 있습니다.
- 해야 할 일: 모든 하위 에이전트 도메인 외부의 쿼리로 테스트하세요(예: 에이전트가 HR과 IT 업무를 담당할 때 날씨를 물어보기).
- 할 일: 상위가 "두 에이전트 모두 아무것도 찾을 수 없음"을 정상적으로 처리하는지 확인합니다.
- 하지 말아야 할 일: 한 하위 에이전트의 도메인과 완벽하게 일치하는 가장 단순한 사례 쿼리로만 테스트하지 마세요.
9. 후속 조치가 예상될 때는 정보를 전달하기보다 질문하는 방식을 선호하십시오
응답이 예상되는 경우에는 질문/요청 스타일의 상호작용을 사용하세요. 알림/전송 방식은 최종적인 단방향 메시지에만 사용하십시오. 에이전트가 일방향 메시지(알림)를 사용해 사용자에게 질문하면, 사용자의 답변은 새로운 쿼리로 부모 플래너로 돌아갑니다. 이 경우에는 하위 에이전트와 동일한 대화를 계속 이어가는 것이 더 좋습니다.
- 해야 할 일: "명확한 설명이 필요하면 사용자에게 질문을 하고 응답을 기다리세요."와 같은 지침을 작성하세요.
- 하지 말아야 할 일: "사용자에게 옵션을 안내하고 선택하게 하세요"와 같이 지침을 작성하세요. '알림'은 일방향 메시지를 의미하는 반면, '요청'은 쌍방향 소통을 의미합니다.
빠른 참고 체크리스트
| # | 수표 |
|---|---|
| 1 | 부모 지침에는 "나만 사용자에게 응답합니다"라고 명시되어 있습니다 |
| 2 | 모든 하위 에이전트 지침에는 "사용자에게 직접 회신하지 마세요"라고 적혀 있습니다 |
| 3 | 강한 지시 언어(MUST, NEVER, ONLY)를 사용합니다 |
| 4 | 각 하위 에이전트는 고유하고 겹치지 않는 참조 자료 원본을 가지고 있습니다 |
| 5 | 하위 에이전트 설명은 정확하고 명확하며 구체적입니다 |
| 6 | 부모 지침은 전체 오케스트레이션 패턴을 정의합니다(호출 → 대기 → 결합 → 응답) |
| 7 | 위임된 작업 컨텍스트에서 상위가 "직접 회신 없음"을 전달합니다 |
| 8 | 도메인-불일치 쿼리로 테스트함 |
| 9 | 하위 에이전트 지침에서 요청과 알림의 구분이 정확하게 이루어져 있습니다 |