https://m.youtube.com/watch?v=3TznIFWDlR0
📌 Copilot Studio Dudecast EP4에서 Gary Pretty는 누구이며, 어떤 이야기를 나누었는가?
1. Copilot Studio Dudecast 소개 및 배경
Copilot Studio와 대화형 AI의 최신 동향을 다루는 팟캐스트에 Gary Pretty가 출연하여 경험을 공유한다.
1.1. 출연자 소개 및 과거 이력
Gary Pretty는 Copilot Studio 팀의 Principal Product Manager이다.
진행자와 Gary Pretty는 Azure Bot Framework 시절부터 협력해 왔다.
Gary는 엔지니어로 시작하여 12개월 후 MVP 경험을 바탕으로 제품 관리(Product Management) 영역으로 이동했다.
초기에는 Bot Framework Composer의 작성 경험(authoring experience)에 중점을 두었으며, 이는 현재 Copilot Studio의 토픽(Topics) 경험과 유사하다.
당시 적응형 대화(adaptive dialogues) 개념의 인큐베이션을 통해 코드를 생성하는 방식으로 전환했으며, 이는 시각적 디자이너 인터페이스의 시초가 되었다.
1.2. Power Virtual Agents로의 전환과 생성형 AI의 충격
Gary와 진행자는 Power Virtual Agents로 합류하며 Azure Bot Framework Composer의 유연성을 SaaS 환경에 통합하는 작업을 진행했다.
ChatGPT 등장 이후, 진행 중이던 모든 작업을 중단하고 생성형 AI를 제품에 3개월 내에 통합해야 하는 급격한 방향 전환이 있었다.
이로 인해 생성형 답변(Generative Answers) 기능이 제품에 도입되었다.
2. 생성형 AI 도입을 위한 초고속 혁신 과정
ChatGPT 발표 후 3개월 만에 제품 방향을 전환하고 'Describe it to build it' 및 생성형 오케스트레이터를 신속하게 개발한 비하인드 스토리를 다룬다.
2.1. 'Describe it to build it' 기능의 탄생
ChatGPT 발표 후, Gary는 4주 뒤에 토픽이 자동으로 생성될 것이라는 질문에 최소 2년은 걸릴 것이라고 순진하게 답했다.
연휴 복귀 후, "Describe it to build it" 기능을 제품에 출시하라는 새로운 임무를 받았다.
이는 ChatGPT 기반의 첫 기능으로, 대화(dialogue)를 처음부터 빌드할 수 있게 했다.
이 기능 출시 후 2개월 만에 Semantic Kernel과 같은 기술을 활용하여 생성형 오케스트레이터를 구축하자는 아이디어가 나왔다.
비전 비디오 제작 후 24시간 이내에 Build(개발자 컨퍼런스)에서 공개할 수 있도록 6주 내에 퍼블릭 프리뷰 출시하라는 지시를 받았다.
이 과정은 새로운 기술이었기에 흥분과 동시에 두려움을 안겨주었다.
당시 '생성형 답변(Generative Answers)'이 주력 기능이었으나, 'Describe it to build it' 기능이 예상보다 빠르게 개발되어 출시되었다.
2.2. 생성형 오케스트레이터 개발과 모델 변화
초기 오케스트레이터는 GPT-3.5 기반이었으며, 도구 호출(calling tools)은 가능했으나 도구 체이닝 능력은 부족했다.
초기에는 도구 선택 후 사용자 입력을 받아 대화를 생성하는 슬롯 채우기(slot filling) 코드를 별도로 구현해야 했다.
초기 프리뷰 단계에서 지연 시간(latency)이 30초 이상으로 매우 높았는데, 이는 기능 호출(function calling)을 사용하는 기본 챗 모델을 사용했기 때문이다.
성능 개선을 위해 GPT-4로 전환했으나 지연 시간이 심해져 다시 롤백했고, 이후 두 번째 반복(4.1 기본 구현)으로 재구축했다.
현재는 더 강력한 최신 모델을 추가하고 있으며, 모델 개선에 따라 제어 로직을 모델에 넘기는 방향으로 전환 중이다.
목표는 안전하고 일관된 방식으로 모델에 제어 권한을 넘겨 신뢰성 있는 경험을 제공하는 것이다.
모델 선택 시 해당 모델의 행동 방식에 옵트인할 수 있도록 하면서도 안전장치(guard rails)는 유지해야 한다.
3. 차일드 에이전트(Child Agents)의 실질적 활용법
차일드 에이전트는 복잡한 대화 흐름을 단순화하며, 모델의 선호도에 따라 직접 응답하고 질문할 수 있게 하여 유연성을 극대화한다.
3.1. 차일드 에이전트의 개념과 이점
차일드 에이전트는 개발 초기 생성형 토픽(generative topics)으로 불렸으며, 분실/도난 신용카드 처리와 같은 복잡한 조건부 대화에 유용하다.
토픽으로 구현 시 시간이 걸리던 작업을, 차일드 에이전트로는 6줄의 지침만으로 5분 이내에 테스트할 수 있다.
차일드 에이전트는 모델의 선호도에 따라 직접 응답하고 질문할 수 있는 능력을 부여받았다.
이는 2년 전 모델이 어려워했던 부분으로, 유연성을 크게 높인다.
3.2. 차일드 에이전트를 활용한 제로 토픽(Zero Topic) 구현 사례
조달 카탈로그(procurement catalog) 정보를 활용하여 구매 요청을 추가하는 시나리오에서, 토픽이나 입력(inputs)을 전혀 사용하지 않고 구현했다.
모델에게 지침(instructions)만 제공하여 자연스러운 대화를 통해 수량 확인, 주문 확인 등의 작업을 수행하게 했다.
지침 내에 슬래시(/)를 사용하여 특정 도구(tool)를 명시적으로 호출할 수도 있다.
이 조달 솔루션은 차일드 에이전트만으로 구성되었으며, 토픽은 0개였다.
이는 차일드 에이전트가 강력해짐에 따라 토픽의 미래에 대한 질문을 제기한다.
3.3. 토픽과 차일드 에이전트의 공존과 미래
토픽은 여전히 결정론적 보장(deterministic assurance)이 매우 중요한 사용 사례에서 필요하다.
차일드 에이전트처럼 지침을 반복적으로 따르는 능력은 토픽처럼 결정론적으로 느껴지게 한다.
일부 고객은 과거 기술 경험 때문에 지침이 따르리라 신뢰하지 않아 토픽을 기본값으로 사용하고 있다.
차일드 에이전트와 에이전트 수준 모델 전환 기능을 결합하여 사용하면 효율성과 유연성이 높아진다.
장기적으로 토픽의 필요성은 줄어들 것이나 완전히 사라지지는 않을 것으로 예상된다.
차일드 에이전트는 구축 효율성을 높이고 최종 사용자 경험에 긍정적인 영향을 준다.
신용카드 분실 예시에서, 차일드 에이전트는 LLM 기반으로 사용자의 비정형적인 응답(예: "첫 번째, 세 번째, ATM 인출 건")을 맥락 속에서 완전히 이해하고 처리할 수 있어 사용자 경험이 극적으로 향상된다.
4. 에이전트 구조화 및 컨텍스트 관리
차일드 에이전트는 논리적 컨테이너 역할을 하여 오케스트레이션의 복잡성을 줄이며, 연결된 에이전트(Connected Agents)와의 관계 및 컨텍스트 전달 방식이 중요하다.
4.1. 차일드 에이전트를 통한 논리적 컨테이너화
연결된 에이전트(Connected Agents)보다 차일드 에이전트의 개념에 더 큰 잠재력이 있다.
도구와 지식을 논리적 컨테이너로 묶고, 설명(descriptions)과 지침(instructions)을 통해 사용 방법을 안내할 수 있다.
40개 이상의 도구를 선택해야 할 때 오케스트레이터가 혼란스러워지는데, 차일드 에이전트는 이를 방지한다.
지식(Knowledge)을 단순히 덤프하는 대신, 차일드 에이전트로 논리적 컨테이너 그룹을 만들고 지침을 추가하여 제어할 수 있다.
microsoft.com 지식을 차일드 에이전트에 넣고 "Surface 관련 질문에만 답변하라"는 지침을 주면, 질문이 Surface 관련이 아닐 경우 해당 차일드 에이전트로 오케스트레이션되지 않아 필터링 효과를 얻는다.
부모 에이전트의 개요 지침에 긴 텍스트를 넣는 대신, 차일드 에이전트에 기능을 분리하면 매 턴마다 오케스트레이션 실행을 방지하여 최적화할 수 있다.
4.2. 연결된 에이전트와 멀티 에이전트 아키텍처
차일드 에이전트, 연결된 에이전트, 멀티 에이전트 아키텍처는 모두 상호 보완적인 기능이다.
에이전트가 20~40개 이상의 도구를 갖게 되면 오케스트레이션 정확도가 저하될 수 있으므로, 이때 연결된 에이전트나 차일드 에이전트로 분할을 고려해야 한다.
연결된 에이전트 사용 결정 기준은 팀 분리 여부나 애플리케이션 확장성/기능 분리 여부에 따라 달라진다.
별도 팀이 구축하는 독립적인 에이전트(예: 신용카드 에이전트)는 연결된 에이전트가 적합하다.
단일 팀은 차일드 에이전트를 사용하는 것이 좋으며, 두 가지를 결합할 수도 있다 (부모 에이전트 -> 연결된 에이전트 -> 내부 차일드 에이전트).
단일 에이전트로 성능과 정확도를 유지할 수 있다면 멀티 에이전트 사용은 지양해야 하며, 멀티 에이전트 사용 시 약간의 지연 시간 증가가 발생한다.
현재 멀티 에이전트 시스템의 제약 사항으로 동일 환경 내에 존재해야 한다.
4.3. 차일드 및 연결된 에이전트의 현재 상태와 향후 계획
차일드 에이전트와 연결된 에이전트 기능은 현재 GA(일반 공급) 상태이다.
향후 몇 달 안에 A2A 프로토콜 통합, Foundry 통합, SDK 에이전트, Fabric 등 현재 퍼블릭 프리뷰 상태인 기능들을 GA로 전환할 예정이다.
차일드 에이전트 생성 수가 연결된 에이전트보다 많아, 대부분 1:다(one-to-many) 구조(부모 에이전트와 다수의 차일드 에이전트)로 사용됨을 알 수 있다.
4.4. 컨텍스트(대화 상태) 관리의 중요성
봇 초기부터 대화 상태(conversation state)를 유지하는 것이 중요하며, 이는 메모리, 변수, 대화 컨텍스트를 의미한다.
멀티 에이전트 환경에서는 부모 에이전트에서 로드된 사용자 프로필이나 숨겨진 컨텍스트 정보를 IT 지원 에이전트와 같은 다른 에이전트로 전달하는 것이 중요해진다.
4.5. 컨텍스트 전달 메커니즘 및 향후 계획
사용자 상태(User State)로 설정된 전역 변수는 세션 간에 유지되며, 연결된 에이전트 호출 시에도 계속 채워져(hydrated) 전달된다.
Copilot Studio 환경 변수 역시 올바르게 구성되면 에이전트 간에 전달될 수 있다.
기본적으로 에이전트는 자연어 작업(natural language task)을 연결된 에이전트에 보내고, 선택적으로 대화 기록을 함께 보낼 수 있으며, 완료 후 자연어 요약을 반환한다.
향후 입력/출력 스키마(Input/Output Schema) 관리 기능이 연결된 에이전트에도 도입될 예정이다.
이를 통해 항상 필요한 3가지 정보(예: 사용자 ID, 제품 ID)를 명시적으로 보낼 수 있다.
심지어 자연어 작업 없이 특정 변수만 전달하고 결과를 받을 수도 있다.
5. 입력/출력(Inputs/Outputs) 기능의 변혁적 역할
입력/출력(슬롯) 개념은 토픽, 도구, 에이전트 전반에 적용되며, LLM이 컨텍스트를 기반으로 데이터를 지능적으로 채우고 변환하는 데 핵심적인 역할을 한다.
5.1. 입력/출력(슬롯)의 정의와 LLM의 역할
입력(Inputs)은 도구가 실행되기 전에 전달되는 슬롯(slots)의 값이며, 출력(Outputs)은 도구가 반환하는 하나 이상의 슬롯이다.
이 개념은 Power Platform 커넥터와 유사하며, 토픽, 차일드 에이전트, 연결된 에이전트에 적용된다.
슬롯은 이름과 설명을 가지며 오케스트레이터(LLM 플래너)에 가시적이다.
토픽의 질문 노드도 데이터를 수집하지만, 입력/출력 방식이 훨씬 강력하다.
티켓 생성 시 필요한 정보(제목, 설명, 심각도 등)를 토픽에서 질문할 수 있지만, 입력/출력 방식을 사용하면 LLM이 사용자 발화(예: "PC가 고장 났고 BIOS 오류가 뜬다")에서 제목과 설명을 지능적으로 채울 수 있다.
LLM은 로그인된 사용자 컨텍스트를 통해 이름이나 사용자 프로필 정보를 가져와 질문 없이 슬롯을 채울 수 있다.
5.2. 출력 데이터 처리의 혁신
데이터베이스에서 가져온 비정형 데이터를, 도구의 출력 스키마로 정의된 명시적인 Power FX 레코드 형식으로 변환할 수 있다.
LLM은 추가적인 Power FX 함수 작업 없이 비정형 데이터를 가져와 정의된 출력 형식으로 변환하는 데 매우 능숙해졌다.
적응형 카드 생성 도구 예시:
JSON 형식의 입력(적응형 카드 JSON)을 받고, 사용자 응답을 출력으로 받을 수 있다.
오케스트레이터는 비행 상태를 가져온 후, LLM이 적응형 카드 스키마를 이해하여 JSON을 생성하고 사용자에게 카드를 표시할 수 있다.
5.3. 입력 기반 대화 제어의 이점
입력(Inputs)을 사용하면 구매 주문(PO) 제출 시 필요한 5~6가지 정보를 수집할 때, 질문 노드 대신 입력을 사용하면 역순으로 대화할 수 있다.
질문 노드를 사용하면 채워진 슬롯에 대해 되돌아가지 않지만, 입력을 사용하면 "배송 업체를 DHL로 변경해 줘"와 같이 이전 단계의 정보를 수정할 수 있다.
이는 구조화된 대화 경로를 따르지 않으면서도 대화 제어권을 유지하는 데 매우 유익하다.
6. AI 기반 개발(AI-Driven Development)의 미래와 우려
AI 기반 개발의 가속화는 개발 효율성을 높이지만, 그 속도에 대한 경계심도 존재하며, 이는 Copilot Studio의 지속적인 발전으로 이어지고 있다.
6.1. AI 기반 개발에 대한 기대와 우려
Gary는 현재 가장 흥분되면서도 가장 두려운 부분은 AI 주도 개발(AI-driven development)의 출현이라고 말한다.
GitHub Copilot 사용으로 개발 워크플로우가 가속화되고 배포 효율성이 높아졌다.
버그 수정 예시: 버그를 엔지니어링 팀에 넘기는 대신, Gary는 Claude 코드를 사용하여 수정 프로토타입을 만들어 진단 및 해결 시간을 단축하고 있다.
문서 사양 작성에도 Claude 코드를 활용하며, 마치 아이디어를 주고받는 동료처럼 활용하고 있다.
이러한 채택 가속화는 매우 긍정적이지만, 그 속도가 가장 두려운 부분이기도 하다.
6.2. 최신 기술 동향 및 Copilot Studio의 발전 방향
진행자는 클라우드 코드(Claude code)와 GitHub Copilot을 결합하여 부트캠프 피드백 애플리케이션을 구축하는 등 AI 도구의 발전을 직접 경험하고 있다.
진행자는 곧 '바이브 코딩(vibe coding)'이라는 새로운 개념을 다룰 예정이며, 이는 이번 주 가장 흥분되고 두려운 주제이다.
AI는 효율성을 높여 증폭(amplified)시키는 역할을 하며, 사용자들은 Copilot Studio를 사용하며 경계(edges)를 발견하고 튜닝해야 한다.
개발자가 발견한 경계는 Gary Pretty가 기능 사양을 작성하여 해결할 것이다.
6.3. 마무리 및 향후 계획
Gary Pretty는 자신의 콘텐츠 게시 빈도가 낮으므로, 진행자의 채널을 계속 시청하는 것이 최신 정보를 얻는 가장 좋은 방법이라고 추천한다.
진행자는 현재 Copilot Studio 부트캠프 시리즈를 재구축하고 있어 콘텐츠 제작에 잠시 공백이 있었다.
진행자는 Gary와 Dwayne 콤보의 발표를 볼 기회가 있다면 놓치지 말라고 권유한다.
Gary는 올랜도에서 열리는 행사에 참석할 가능성이 높다.
시청자들에게 LinkedIn에서 Gary Pretty를 팔로우할 것을 권장한다.
댓글
댓글 쓰기