생성 오케스트레이션은 Copilot Studio에서 대화형 에이전트 개발의 진화 과정입니다. 사용자 의도를 해석하고, 복잡한 요청을 분해하며, 적절한 도구와 지식을 선택하고, 안전과 준수를 위한 가드레일과 함께 다단계 계획을 실행하는 대형 언어 모델(LLM) 기반 계획 계층을 도입합니다. 생성적 오케스트레이션은 손으로 만든 대화 주제에만 의존하는 대신, 행동, 주제, 지식 소스, 자율 에이전트, 자율 트리거 등 재사용 가능한 구성 요소를 지능적인 워크플로우로 조합합니다.
Copilot Studio에서는 생성 오케스트레이션을 활성화하면 수작업 스크립팅을 줄이면서 더 나은 답변을 제공합니다. 이 글에서는 생성 오케스트레이션의 구조와 효과적인 명령어 작성 및 오케스트레이션 에이전트를 테스트 및 조정하는 방법에 대해 배웁니다.
생성 오케스트레이션이 왜 중요한가요?
전통적인 주제 중심 설계는 여러 개의 수작업으로 만든 주제, 엄격한 분기, 그리고 수동 슬롯 채우기 논리를 요구합니다. 이 접근법은 다음과 같은 결과를 가져올 수 있습니다:
- 논리가 겹치는 대규모 주제 목록.
- 모호하거나 다중 의도가 있는 발화를 다루기 어렵습니다.
- 사용자가 질문을 다르게 표현할 때 일관성 없는 경험이 있습니다.
- API나 비즈니스 규칙이 변경될 때 유지보수 비용이 많이 듭니다.
생성적 오케스트레이션은 다음과 같은 방식으로 이러한 문제를 해결합니다:
- 재사용 가능한 구성 요소를 작성하여 주제 확장을 줄이기.
- 입력 정의에 기반한 슬롯 채우기 자동화.
- 반응 스타일과 계획 구조를 동적으로 조정합니다.
- 의미 지식 검색을 통한 관련성 향상.
- 선제적인 다음 단계 제안을 가능하게 합니다.
아키텍처 및 구성 요소
고수준에서 생성 오케스트레이터 에이전트는 여러 핵심 구성 요소로 구성되어 함께 작동합니다:
오케스트레이터(플래너): 사용자 메시지나 이벤트와 같은 입력을 구조화된 계획으로 전환하는 에이전트의 LLM 기반 두뇌입니다. 오케스트레이터는 의도를 식별하고, 각 단계에서 호출할 도구, 주제, 에이전트를 선택하며, 단계 간 순서와 데이터 흐름을 정의합니다. 이 시스템은 런타임이 실행하는 순서화된 단계('계획') 목록을 출력하고, 각 단계가 정책 내에 있는지 확인합니다. 예를 들어, 민감한 행동에 대한 승인을 구합니다.
지식 계층: 내부 지식 기반, 문서, 데이터베이스 등과 같은 검색 소스 집합으로, 에이전트가 답변을 근거 내기 위해 쿼리할 수 있습니다. 오케스트레이터는 이 계층을 이용해 사실 정보나 지침을 가져옵니다. 결과에는 인용문과 메타데이터가 포함되며, 에이전트는 이를 투명성을 위해 응답에 반영할 수 있습니다. 지식 계층은 읽기 전용이며 증거나 맥락을 제공합니다.
도구 및 커넥터: 에이전트가 계획의 일부로 호출할 수 있는 외부 동작, API 또는 자동화 흐름. 각 도구는 정의된 인터페이스를 가지고 있습니다: 입력 매개변수(예상 타입 포함), 출력 변수, 그리고 때로는 오류 조건도 포함됩니다. 본질적으로 에이전트가 주문을 조회하거나 이메일을 보내거나 스크립트를 실행하는 등 작업을 수행하는 데 필요한 '기술'입니다. 도구를 철저히 테스트하고, 오케스트레이터가 이들을 신뢰할 수 있는 함수로 간주하기 때문에 동일한 입력을 받아도 결정론적으로 동작하는지 확인해야 합니다.
주제 및 인라인 에이전트: 특정 논리를 담은 재사용 가능한 대화 주제 또는 미니 대화. 생성적 오케스트레이션에서는 플래너가 트리거 구뿐만 아니라 사용자의 필요에 부합하는 목적에 따라 주제를 호출할 수 있습니다. 인라인 에이전트는 더 큰 계획 내에서 하위 단계로 사용되는 작고 집중된 주제나 루틴을 의미합니다. 메인 에이전트의 컨텍스트 내에서 실행되며, 개별 작업을 처리하여 메인 오케스트레이터가 그 세부 사항을 명시적으로 스크립트화할 필요가 없도록 합니다.
이벤트 트리거(자율성): 사용자 메시지 없이 오케스트레이터를 시작하는 메커니즘입니다. 이러한 메커니즘은 예약 트리거이거나 데이터베이스 레코드 업데이트와 같은 이벤트 기반 트리거일 수 있으며, 에이전트가 자율적으로 계획을 실행하도록 유도합니다. 각 트리거는 고유한 조건과 명령을 가질 수 있습니다. 자율 트리거는 에이전트가 특정 조건이 충족되면 사용자 채팅 입력에만 반응하는 대신 워크플로우를 적극적으로 시작할 수 있게 합니다.
제어 계층과 의사결정 경계
프로덕션 등급 에이전트에서는 모든 결정을 AI에게 맡기지 마세요. 일반적으로 세 가지 통제 계층이 존재합니다:
결정론적 계층: 이 계층은 전통적인 규칙 기반 논리를 사용하며, 임무 중요하거나 되돌릴 수 없는 행동에 대해서는 여전히 강제합니다. 예를 들어, 결제 처리나 기록 삭제 시 AI 해석 없이 단계별로 실행되는 엄격하게 작성된 주제나 흐름을 사용할 수 있습니다. 이 계층에는 민감한 데이터에 대한 명시적 검사나 검증도 포함될 수 있습니다. 만약 어떤 일이 정확히 명시된 대로 일어나야 한다면, 결정론적으로 처리하세요. 생성 오케스트레이터를 이 흐름들을 덮어쓰거나 변경하지 않도록 설정할 수 있습니다. 실제로는 이러한 행동을 AI 플래너에 노출하지 않거나, 항상 사용자 확인이 필요한 주제로 묶을 수도 있습니다.
하이브리드(인터셉트) 레이어: 이 레이어는 주로 결정론적 구조에 대해 AI의 유연성을 추가합니다. 조율자가 정해진 경계 내에서 작동할 수 있도록 허용하며, 인간 또는 규칙 기반 가로채기가 가능하도록 허용합니다. 예를 들어, 에이전트가 자동으로 응답을 작성하거나 행동을 수행할 수 있지만, 승인 단계를 삽입해 관리자가 검토할 수 있습니다. 또는 에이전트가 일정 가치 한도까지 작업을 처리한 후 에스컬레이션을 요구받을 수도 있습니다. 하이브리드 계층은 AI의 자율 계획이 체크포인트를 받는 지점을 미리 정의합니다. 중간 위험 프로세스에 이 방식을 적용하세요: AI가 무거운 일을 맡기되, 감독을 위해 인간을 참여시키는 것입니다.
AI 오케스트레이터 계층: 이 계층은 완전 생성형입니다. LLM 플래너는 (제한 내에서) 저위험 쿼리에 대해 계획을 작성하고 실행할 자유를 가집니다. 대부분의 Q&A 상호작용, 정보 조회, 또는 간단한 다단계 요청이 이 범주에 속합니다. 대부분의 사용자 질문에 대해 에이전트는 자율적으로 어떻게 해결할지 결정하고 조치를 취할 수 있습니다. 이 계층은 생성형 AI의 적응력과 강력함을 제공합니다. 정책에 묶여 있습니다. 예를 들어, AI가 특정 관리자 도구를 호출하거나 특정 정보를 공개하는 것이 금지되어 있다는 것을 알고 있을 수 있습니다. 상담원은 일상적인 작업에 대해 멈춰서 허락을 구할 필요가 없습니다.
이러한 계층을 앞두고 의사결정 경계를 명확히 정의하세요. 어떤 행동과 주제를 살펴보세요:
- 확인 없이도 실행할 수 있습니다(AI가 그냥 할 수 있습니다).
- 대화 중 사용자의 확인을 요구하세요(예: "모든 기록을 삭제할 것이 확실합니까?")
- 오프라인 승인을 요구하세요 (예: 관리자가 승인 워크플로우를 통해 확인해야 합니다)
이러한 경계는 확인 노드 추가, 플랫폼 승인 기능, 트리거 내 로직 등 주제 디자인을 통해 강제하세요. 통제를 계층화함으로써 에이전트가 안전하게 작동하도록 보장할 수 있습니다—AI는 잘하는 일을 처리하고, 인간이나 엄격한 규칙은 AI가 혼자 결정해서는 안 되는 것을 처리합니다.
에이전트 명령어에 대한 모범 사례
적절히 작성된 상담원 지침은 계획 생성의 품질에 영향을 미칩니다.
맥락적 관련성
- 지침은 에이전트가 사용할 수 있는 도구와 지식만을 참조하도록 하세요.
- 정확한 도구명, 변수명, Power FX 식별자를 사용하세요.
대화 지침
- 응답 형식(목록, 표, 굵은 글씨)을 지정하세요.
- 스타일 지침을 제공하세요("간결하게", "인용 포함", "다음 단계 제안").
- 특정 지식 출처를 직접적으로 언급하는 것은 피하세요. 대신 그들을 묘사해 보세요.
도구나 지식을 언제 사용할지 결정하기
- 공구 이름을 사용하는 것을 선호합니다. 이름은 묘사보다 더 큰 의미를 가집니다.
- 잘못된 정보를 피하기 위해 지식 역량을 일반적으로 설명하세요.
자율 실행 명령어
- 다단계 워크플로우에 대한 기대되는 행동 순서를 정의하세요.
- 프로세스 지침과 구체적인 안내를 결합하세요.
생성 오케스트레이션을 위한 고품질 명령어 구성 항목에서 더 알아보세요.
주제 입력과 출력 설계
주제를 작성할 때는 생성 오케스트레이션 모드에서 입력과 출력 매개변수에 특히 주의를 기울이세요:
명확한 입력 매개변수와 설명을 정의하세요: 주제나 동작이 특정 정보(예: 비밀번호 재설정 주제의 "사용자 이름")가 필요하다면, 주제 입력을 만들고 설명적인 이름과 예시를 부여하세요. 오케스트레이터는 이러한 이름과 설명을 사용해 자동으로 해당 값이 누락되었는지 사용자에게 묻습니다. 입력값에 대해 허용된 값 목록이나 Power FX 검증 공식을 사용하면 봇이 유효한 데이터를 수집하는지 확인할 수 있습니다(예: 국가 코드를 두 글자로 제한하는 것).
자동 프롬프트 사용: 생성형 모드에서는 에이전트가 누락된 정보를 찾기 위해 질문 노드를 수동으로 추가하는 대신 스스로 질문을 생성합니다. 이 접근법은 고전 봇과는 큰 차이입니다. 핵심은 입력 이름이 인간에게 친숙해야 한다는 점입니다(예: "시작일", "이메일 주소") 그래야 AI가 자연스럽게 질문을 만들 수 있습니다. AI의 자동 생성 질문이 이상적으로 표현되지 않았다면, 입력의 설명이나 이름을 다듬는 것을 고려해 보세요. 이 기능은 대화를 크게 간소화하지만, 잘 지정된 입력에 의존합니다.
적절한 주제별 출력 명시: 주제는 오케스트레이터가 최종 답변을 컴파일하는 데 사용하는 출력 변수를 생성할 수 있습니다. 예를 들어, "스토어 찾기" 주제는 .을 출력
NearestStoreLocation할 수 있습니다. 사용자에게 직접 메시지를 보내는 대신 정보를 출력함으로써 오케스트레이터가 그 정보를 다른 단계들과 자연스럽게 결합할 수 있게 됩니다. 주제의 내용이 더 큰 답변에 사용된다면, 출력 변수로 캡처하고 최종 메시지를 오케스트레이터가 처리하도록 하세요. 생성 AI를 사용하여 에이전트 동작 오케스트레이션에 대해 자세히 알아봅니다.프롬프트에서 데이터를 '이중 처리'하지 마세요: 출력 설정을 할 때, 그 출력을 LLM에 열린 형태로 입력하지 마세요. 예를 들어, 액션이 요약 텍스트를 반환한다면, 그 요약을 구조화된 출력으로 전달하고 오케스트레이터가 포함하도록 하여 "액션 결과가 {summary}라고 말한다" 와 같은 명령어를 작성하지 마세요. 이 접근법은 모델이 콘텐츠를 과도하게 생성하거나 반복하는 것을 방지합니다. 출력은 가능한 한 최종 데이터 포인트여야 합니다.
행동, 주제, 지식의 연쇄
오케스트레이터가 한 턴에 여러 기능을 사용할 수 있기 때문에, 조합 가능성을 염두에 두고 설계해야 합니다:
모든 것에 직관적인 이름과 설명을 부여하세요: 플래너는 주로 도구나 주제의 이름과 설명이 사용자의 요청과 얼마나 잘 맞는지에 따라 사용할지 결정합니다. 사용자의 의도에 부합하는 능동적인 문구를 사용하세요. 예를 들어, "TranslateText"라는 도구가 "특정 언어로 텍스트를 번역한다"라는 설명이 있는데, 사용자가 번역에 대해 질문할 때 "Flow1"이라는 일반적인 이름의 도구보다 더 자주 선택될 가능성이 높습니다. 이름이 무엇보다 중요하다. 암호 같은 이름은 피하세요. 만약 에이전트가 잘못된 주제를 선택했다면, 그 이름과 설명을 다시 검토하세요.
풍부한 '툴킷'을 제공하되 엄선하세요: 시나리오에 필요한 모든 유용한 행동(API, 플로우 등)을 연결하고, 중요한 플로우에 대한 주제를 작성하세요. 이 접근법은 AI가 쿼리를 해결할 수 있는 더 많은 선택지를 제공합니다. 하지만 담당자에게 관련 없거나 위험한 도구나 주제는 제거하거나 비활성화하여 플래너가 혼란스러워하지 않도록 하세요. 고품질의 선택지를 적게 묶는 것이 중복이 있는 포괄적 선택지보다 낫습니다. 설명이 겹치면 에이전트가 여러 가지를 동시에 시도하게 될 수 있는데, 이는 원하지 않을 수 있습니다.
플래너를 합리적인 범위 내에서 신뢰하세요: 구성 요소가 명확히 정의되면, 오케스트레이터가 자유롭게 조합할 수 있도록 허용하세요. 예를 들어, 사용자가 지식 문서나 실시간 데이터 API로 해결할 수 있는 질문을 할 경우, 플래너는 두 가지 모두를 선택해 배경 지식으로 데이터를 가져오고 현재 정보를 위해 API를 호출할 수 있습니다. 이 접근법은 더 나은 답변을 제공할 수 있습니다. 이 자율성을 받아들이되, 좋은 선택이 이루어지는지 초반에 주의하세요.
다중 의도 처리: 사용자 쿼리가 본질적으로 두 가지 별도 사항을 요청한다면(예: "새 계정 개설하고 세부 정보를 보내라"), 생성 플래너는 관련 순서를 차례로 호출하여 두 가지를 모두 충족시키려 합니다. 멀티 인텐트를 위해 분기 작업을 수동으로 스크립트할 필요는 없습니다. 개발자로서 당신의 역할은 각 하위 작업(계정 개설, 세부 정보 전송)이 어떤 도구나 주제로 처리되고, 필요하면 출력과 입력이 연결되도록 하는 것입니다.
지식이 주제와 도구를 보완하도록 하자: 오케스트레이터는 단순한 대체 수단이 아니라 능동적으로 지식 검색을 호출할 수 있습니다. 풍부한 지식 기반이 설정되어 있다면, 에이전트는 어떤 행동이 다른 부분을 다루더라도 지식 기사 조각으로 쿼리의 일부에 답할 수 있습니다. 이 동작은 의도된 것입니다. 도구로는 쉽게 얻을 수 없는 정보로 지식 기반을 최신 상태로 유지하세요.
지식 사용 범위 주의: 현재는 에이전트에게 특정 지식 에세이를 요구할 때마다 사용하도록 강요할 수 없습니다. AI는 쿼리를 바탕으로 관련 기사를 선택합니다. 또한 제한 사항도 참고하세요. 예를 들어, "여러 주제가 매쳐진다" 같은 시스템 주제는 생성 모드에서는 사용하지 않는데, 플래너가 중의성 해소를 다르게 처리하기 때문입니다. 생성 오케스트레이션의 다른 알려진 한계에 대해 더 알아보세요.
오케스트레이션 에이전트의 테스트 및 조정
생성적 오케스트레이션은 명시적 설계에서 AI의 '두뇌'로 일부 논리를 전환시킵니다. 반복 테스트는 의도한 대로 작동하는지 확인합니다. 다음은 오케스트레이션 에이전트를 테스트하고 개선하기 위한 모범 사례입니다:
활동 맵 사용: Copilot Studio는 테스트 중 오케스트레이터가 결정한 단계를 보여주는 활동 맵 을 제공합니다. 복잡한 질문을 한 후에는 계획을 점검하세요: 어떤 주제나 행동이 언급되었는가? 어떤 순서로? 적절한 후속 질문을 했나요? 만약 상담원이 잘못된 주제를 선택하거나 도구를 놓쳤다면, 부품 설명을 다듬거나 지침을 조정해야 할 수도 있습니다.
대본을 검토하세요: 요원이 출판되면 대화 기록이나 기록을 정기적으로 검토하세요. 답변에서 환각이나 부정확한 점이 있는지 찾아보세요. 사용자가 "그건 맞지 않다"고 피드백을 주면, 왜 그렇게 생각했는지 다시 확인해 보세요. 문제를 해결하기 위해 누락된 사실을 지식 기반에 추가하거나, 지침을 강화하거나, 경우에 따라 새로운 주제를 추가해 공백을 보완할 수 있습니다. 자세한 내용은 '에이전트 대화 기록 추출 및 분석(참조 아키텍처)'에서 확인하세요.
작은 변화로 반복하기: 미묘한 변화를 통해 생성 에이전트를 개선할 수 있습니다. 예를 들어, 에이전트 출력이 너무 장황하거나 원하는 형식이 아니면 스타일과 형식에 관한 지침을 조정한 후 다시 테스트하세요. 만약 매번 불필요한 도구를 호출한다면, 그 도구의 설명이 너무 광범위해서 적절한 때만 호출되도록 조정할 수 있을 수 있습니다. 한 번에 한 가지씩 변화를 주고받으며 에이전트의 결정에 미치는 영향을 관찰하세요.
예시 발화 제공(신중하게): 주제 설명에 몇 가지 예시 사용자 쿼리를 추가하면 LLM이 해당 주제를 언제 사용해야 하는지 이해하는 데 도움이 될 수 있습니다. 예를 들어: "목적: 사용자의 비밀번호를 재설정합니다. 예를 들어, 사용자가 '비밀번호를 잊었어요' 또는 'Contoso 계정 접근 권한을 재설정했습니다.'라고 말할 수 있습니다." 이 예시들은 모델에게 추가적인 힌트를 제공합니다. 과하지 말고, 설명은 간결하고 집중되도록 하세요. 모델에는 이미 많은 맥락이 포함되어 있으니, 메타데이터가 명확한지 확인하세요.
성능 지표 모니터링: 사용량이 증가함에 따라 성공률(에이전트가 실제로 사용자의 요청을 해결했는가), 대체 속도("죄송하지만 도와드릴 수 없습니다"라는 빈도), 그리고 사용자 만족도 같은 주요 지표를 주시하세요. 테스트 중에도 각 주제와 도구가 얼마나 자주 사용되는지 간단히 계산하면 필요한 조정을 암시할 수 있습니다. 예를 들어, 사소한 잡담 주제가 너무 자주 언급되어 잡음을 더한다면, 해당 주제를 비활성화하거나 설명을 좁히세요. 에이전트의 성과 테스트에 대한 지침을 검토하세요.
생성 시스템은 당신의 구성과 수정에서 내재적으로 학습합니다. 명령어나 메타데이터의 각 개선은 AI의 다음 결정을 더 나은 것으로 만듭니다. 시간이 지나면서 조정된 에이전트는 쿼리를 더 정확하고 효율적으로 처리하게 됩니다.
생성 오케스트레이션에서의 커스텀 트리거
생성 오케스트레이션을 위해 특별히 제공되는 주제 트리거가 있습니다. 이 트리거들을 사용하면 에이전트의 라이프사이클에 연결해 오케스트레이션 과정의 중요한 시점에 맞춤형 로직을 주입할 수 있습니다. 세 가지 주요 트리거가 있습니다:
| Trigger | 트리거가 될 때 | 목적 |
|---|---|---|
| 요청된 지식에 대하여 | 에이전트가 지식 기반 쿼리를 수행하기 직전에 | 이 트리거는 오케스트레이터가 지식 소스를 검색하려는 순간을 가로채게 해줍니다. 에이전트가 사용하려는 키워드에 SearchPhrase 대한 읽기 전용 접근과 사용자 지정 검색 결과를 제공하는 시스템 변수를 제공합니다. 예를 들어, 쿼리를 포착해 독점 인덱스로 라우팅하거나 결과에 더 많은 데이터를 주입할 수 있습니다.이것은 고급("비밀") 트리거로, 기본적으로 UI에 표시되지 않으며 현재는 YAML 편집(주제 이름을 정확 OnKnowledgeRequested히 지정)으로 활성화해야 합니다. 특정 결과를 필터링하거나 외부 데이터를 지식 응답에 병합하는 등 지식 검색 단계를 보완하거나 맞춤화해야 할 때 사용하세요. |
| AI 응답 생성 | AI가 초안 답변을 작성한 후, 사용자에게 전송되기 전입니다 | 에이전트는 최종 응답 텍스트(모든 도구 및 주제 출력을 바탕으로)를 작성한 후 전달 직전에 이 트리거를 발동합니다. 이 단계는 답변이나 인용을 프로그래밍적으로 수정할 기회를 제공합니다. 예를 들어, 텍스트를 후처리하여 서식을 수정하거나, 원시 URL을 친근한 추적 링크로 대체할 수 있습니다. 심지어 응답을 무시할 수도 있습니다. 트리거는 자체 맞춤 메시지를 생성할 수 있고, 원래 AI 응답을 보내야 하는지 여부를 표시하는 플래그를 사용할 ContinueResponse 수 있습니다.이 트리거는 AI의 답변에 대한 마지막 순간의 조정이나 개선, 예를 들어 설문 질문을 덧붙이거나, AI가 포함했지만 제거하고 싶은 내용을 삭제하는 데 사용할 수 있습니다. 이 트리거를 많이 사용하면 주요 명령어에 있을 수 있는 논리가 있었을 수도 있습니다. 필요할 때 세밀한 제어를 위해 사용하세요. |
| 완전 계획 완료 | 전체 계획이 실행되고 응답이 전송된 후에야 | 계획이 완료되어 모든 단계가 완료되고 사용자가 답을 보게 되면, 이 트리거가 발동됩니다. 보통은 대화 종료 후 모든 과정을 시작하는 데 사용하세요. 일반적인 용도는 대화를 특정 최종 주제나 설문조사로 전환하는 것입니다. 예를 들어, 사용자에게 감사 인사를 전하거나 다음 단계를 안내하는 종료 후 채팅 주제가 있을 수 있습니다. On Plan Complete를 사용하면 해당 주제를 자동으로 호출할 수 있습니다. 하지만 주의하세요: 특히 사용자가 후속 질문을 할 경우 모든 질문 후에 대화를 끝내고 싶지 않을 것입니다. 특정 컨텍스트 변수가 설정되었거나 계획이 특정 요청을 해결할 때만 종료되도록 로직을 추가하세요. 본질적으로, 적절할 경우 정리 작업이나 우아한 마무리 작업에 On Plan Complete를 사용하세요. |
더 많은 생성형 오케스트레이션 기능
에이전트가 계획하고 행동하며 협업하는 방식을 확장하는 고급 기능을 통해 Copilot Studio의 오케스트레이션 모델에 대한 이해를 심화하세요:
- 자율 에이전트 기능 설계: 트리거, 의사결정 경계, 가드레일을 활용해 능동적으로 행동하는 에이전트를 구축하세요.
- 다중 에이전트 오케스트레이션 패턴 탐색: 여러 에이전트가 어떻게 협력하고, 작업을 위임하며, 복잡한 워크플로우를 해결하기 위해 맥락을 교환하는지 배워보세요.