https://www.youtube.com/watch?v=ZykXZYIctDM
1. Copilot Studio 엔진 발전사 개요
이 타임라인 노트는
1.1. 초기 대화형 AI 엔진의 시작과 LUIS 활용
초기 대화형 AI 엔진은 사용자의 메시지를 받아 무엇을 해야 할지 결정하는 단계에서 시작되었다.
초기 키워드 매칭 방식:
가장 초기에 개발된 봇에서는 사용자가 입력한 텍스트에서 특정 키워드를 찾기 위해
index of나string in string함수를 사용하였다.이 방식은 한계가 명확하여, 이후 정규 표현식(Regex)을 시도했으나 이 역시 효과적이지 못했다.
LUIS (Language Understanding Intelligent Service) 도입:
키워드 매칭의 한계를 극복하기 위해 실제 AI를 도입했으며, 당시
Azure Cognitive Services 의 일부였던 LUIS를 사용했다.LUIS는 커스텀 훈련 모델로, 개발자가 인텐트(Intents) (예: 매장 영업시간, 길 안내, 메뉴 항목)와 해당 인텐트에 대한 여러 예시 문장을 제공하여 모델을 훈련시켰다.
LUIS는 사용자의 발화가 어떤 인텐트에 가장 가깝게 일치하는지(예: 98% 확률로 영업시간 문의)를 판단하여 다음 동작을 결정했다.
초기 개발 환경과 대화 관리:
초기에는 Pro-code 솔루션으로 SDK를 사용하여 개발했으며, 개발자는 코드 내에서 원하는 모든 것을 구현할 수 있었다.
Azure Bot Service 내에서 대화(Dialogues)를 관리하는 기능이 있었는데, 이는
Copilot Studio 의 토픽(Topic)과 유사한 개념으로, 순차적인 이벤트 체인을 코드로 직접 구축해야 했다.당시 Regex는 특정 단어를 포함하는지 등을 확인하는 매우 기초적인 표현 언어였다.
LUIS 모델 훈련 시에는 모든 인텐트와 사용자가 말할 수 있는 다양한 방식을 정의해야 했으며, 개체 추출(Entity Extraction)을 위해 엔티티를 정의하는 작업이 필요했다.
이러한 방식은 모델을 튜닝하는 데 많은 시간이 소요되었으나, 현재는 대규모 언어 모델(LLM) 덕분에 언어 모델 자체를 훈련할 필요가 없어졌다.
1.2. Waterfall 대화 방식과 Adaptive Dialogue의 등장
엔진의 발전 과정에서 대화 흐름 관리 방식에 큰 변화가 있었다.
Waterfall 대화 방식:
초기에는 Waterfall 대화 개념이 존재했으며, 이는 매우 엄격한 순차로 구성된 대화 방식이었다.
에이전트의 처리는 상태 머신(State Machine)과 유사하여, 한 단계(Step)에서 처리 후 다음 단계로 이동하는 구조였다.
Waterfall 방식은 물이 위에서 아래로 흐르듯 한 순서에 갇혀 진행되었으며, 중간에 맥락을 전환하는 인터럽션(Interruption) 처리가 불가능했다.
예시로, 비행기 출발 시간 질문 도중 사용자가 갑자기 목적지를 변경하려 하면, Waterfall 방식은 해당 질문 단계에 갇혀 다음 단계로 넘어가지 못하는 문제가 있었다.
Adaptive Dialogue의 도입:
Adaptive Dialogue는 Waterfall 방식의 한계를 극복하기 위해 도입되었으며, 더 자연스러운 인터럽션 감지를 가능하게 했다.
이를 통해 사용자가 대화 맥락을 전환할 때, 이전 순서를 관리하고 새로운 시퀀스를 시작하는 방법을 지원했다.
Adaptive Dialogue는 Power Virtual Agents (PVA)의 초기 기반이 되었으며, C#이나 JavaScript 코드를 작성하지 않으려는 사용자층을 목표로 했다.
Adaptive Dialogue 구현의 복잡성:
Adaptive Dialogue를 코드로 작성하는 것은 매우 복잡하여, PVA 출시 이전에도
Bot Framework Composer 가 개발되었다.개념적으로는 이해하기 쉬웠으나, 당시의 JSON 기반 코드로 이를 표현하는 것은 참조 관리 등이 어려워 수동 작성이 매우 힘들었다.
이러한 복잡성 때문에 시각적 편집기(Visual Editor)가 훨씬 효율적이었으며, 이는 대화 흐름의 그래프를 시각적으로 관리하고 이해하는 데 용이했다.
당시 시장에서는 대화 트리 디자이너(Conversation Tree Designers)가 있었고, 개발자가 아닌 비즈니스 사용자와 개발자의 경계에 있는 대화 디자이너 역할이 필요했다.
시각적 캔버스는 개발자와 디자이너가 코드를 통해 교차할 수 있는 방법을 모색한 결과였으며, Bot Framework에서는 잘 구현되었으나 여전히 개발자 중심적이었다.
1.3. Power Virtual Agents (PVA) 1.0과 2.0의 진화
Bot Framework와 PVA의 합병 이후, PVA 플랫폼의 발전 과정이 설명되었다.
PVA 1.0의 특징:
PVA 1.0은 개별 LUIS 언어 이해 모델의 필요성을 대체했다.
개별 모델을 직접 훈련할 필요 없이, 하나의 대규모 공유 언어 모델을 사용했다.
이 모델은 DTE라는 알고리즘을 사용했는데, 이는 현재의 OpenAI나 Anthropic 모델보다는 작지만 LLM의 일종이었다.
사용자는 최상위 인텐트만 정의하면 되었고, 모델 관리가 필요 없었다.
이 기술은 BERT 기반 기술에서 파생된 것으로 추정된다.
한계점:
모델 자체의 한계에 부딪혔다.
영어 전용이었으며, 다른 언어를 사용하려면 번역이 필요했다.
모델 외적으로는 Waterfall 스타일의 대화 방식을 사용했으며, 질문/응답, 메시지 전송 등 기본적인 기능만 제공했다.
고급 기능 부재: 흐름 간 분기, 변수 관리(
API 호출 및 데이터 조작을 위한 정보 수집 불가), 인터럽션 처리가 어려웠다.
PVA 2.0의 발전:
PVA 2.0에서는 Adaptive Dialogue 스타일을 도입하고 이를 더욱 발전시켰다.
봇의 불변 정의(Immutable Definition), 즉 봇의 소스 코드가 존재하며, 실행 단계에서 중요한 값(변수)을 캡처하여 상태를 관리했다.
인터럽션 발생 시, 새로운 컨텍스트 창을 생성하여 처리할 수 있었는데, 이는 Adaptive Dialogue 스택을 기반으로 했다.
Bot Framework의 장점 통합: 변수, 조건문(If 문), 루프, 다른 대화로의 점프 등 고급 기능이 추가되었다.
확장성 추가: HTTP 엔드포인트 호출,
Power Platform 커넥터 및 플로우 호출 기능이 추가되었다.
1.4. PVA 1.0과 Bot Framework의 통합 및 LLM 시대의 도래
PVA 2.0은 PVA 1.0의 인프라 용이성과 Bot Framework의 유연성을 결합한 지점이었다.
인프라 및 유연성 비교:
PVA 1.0은 Azure에 15~16개의 서비스를 설정할 필요 없이 인프라 온디맨드(Infrastructure on Demand)를 제공하는 SaaS 형태였다.
Bot Framework는 무한한 구축 능력을 제공했지만, Azure 리소스 프로비저닝 및 권한 설정이 복잡했다.
PVA 2.0은 두 방식이 합쳐져 Bot Framework의 유연성과 SaaS의 용이성을 모두 갖추게 되었다.
LLM 시대의 급격한 전환:
PVA 2.0은 2021년 6월경에 출시되었다.
2021년 11월 Chat
GPT 출시 이후, 모든 계획이 변경되었으며, 팀은 3개월 내에 새로운 방향으로 전환해야 했다.발표자는 12월 1일에 복귀하여 이 변화를 인지했으며, 과거
Tay 나 Chia와 같은 AI 실패 사례 때문에 초기에는 불안감을 느꼈다.PVA 2.0 인프라가 구축되어 있었기에, 이 급격한 변화에 신속하게 대응할 수 있었다.
Generative Answers (RAG의 전신)의 등장:LLM 시대에 가장 먼저 도입된 기능은
Generative Answers 였으며, 이는 현재의Knowledge (SaaS 기반 RAG 패턴)의 전신이다.작동 방식은, 만약 사용자의 질문에 대해 정의된 인텐트(Intent)를 찾지 못하면, 검색(Search)으로 폴백(Fallback)하여 접지된(Grounded) RAG 패턴으로 답변을 시도하는 것이었다.
이 기능은 2022년 초에 시연되었으며, 발표자는 이 기능이 매우 커질 것이라고 예상했다.
당시 발표자는 고객 대면 업무를 담당하는 유일한 사람이었으며, 이 기술을 고객에게 시연하고 피드백을 받아 엔진 개선에 기여했다.
1.5. 초기 RAG 시연과 검색의 한계 노출
초기 RAG 패턴을 활용한 시연 과정에서 흥미로운 사례와 함께 검색의 근본적인 한계가 드러났다.
초기 RAG 시연 사례:
초기에는 Bing 공개 웹을 기반으로 시연을 진행했다.
고객사 웹사이트에서 양식(Form)을 작성하는 토픽을 만들고, 웹사이트를 스크립트로 질문하며 양식 작성을 유도하는 시연을 했다.
시연 후, 고객들은 봇이 공개되지 않아야 할 정보까지 찾아내는 것에 대해 문의했다.
이는 고객들이 자신의 정보가 Bing이나 Google에 인덱싱되어 있다는 사실을 인지하지 못했기 때문에 발생한 문제였다.
LLM 도입 전후의 차이:
LLM이 없던 시절에는 고정된 토픽이나 인텐트만 처리할 수 있었으며, 범위를 벗어난 질문에는 "모르겠다"고 답했다.
접지된 RAG 패턴과 폴백 데이터를 사용하면서, 에이전트가 맥락화된 답변을 제공할 수 있게 되었다.
이전에는
Q&A Maker 를 사용하여 Q&A 쌍을 로드하여 성격을 부여하려 했으나, 이제는 에이전트가 농담도 할 수 있게 되었다.RAG (Retrieval Augmented Generation)는 데이터 기반의 Chat
GPT 와 같으며, 검색 증강 생성이라고 할 수 있다.
1.6. RAG의 발전: 단순 검색에서 Agentic RAG로
RAG 패턴은 단순 검색 방식에서 벗어나 복잡한 추론이 가능한 Agentic RAG로 진화했다.
기존 RAG 파이프라인 (2022년 이후 약 2~3년간 지속):
사용자가 질문을 하면, 질문 내용을 기반으로 검색을 수행했다.
검색은
벡터 인덱스 나시맨틱 검색 을 사용하여 자연어를 인덱스와 의미적으로 일치시켰다.검색 결과로 문서 조각(Snippet)들이 반환되었다.
이 스니펫들과 사용자 질문을 생성 AI 모델에 제시하여 답변을 생성하고 출처를 인용하도록 했다.
기존 RAG의 실패 지점 및 관찰:
검색 쿼리 자체가 올바른 검색 대상인지에 대한 의문이 발생했다.
SharePoint, 공개 웹, 업로드 문서, Dataverse 등 다양한 검색 제공자에서 결과를 가져올 때, 어떤 데이터 소스가 가장 적절한지에 대한 관련성 판단이 어려웠다.
검색 결과 자체가 정확한지에 대한 신뢰 문제가 있었다.
인간의 검색 방식 관찰과 Agentic RAG의 탄생:
인간은 검색 시 반복적인 과정을 거친다: 검색 → 스니펫 스캔 → 문서 클릭 → 내용 확인(Ctrl+F, 목차 확인, 이미지/표 확인) → 잘못 검색했음을 인지하고 다시 검색을 반복한다.
기존 에이전트는 검색 후 첫 두 단계(검색 및 스니펫 확인)만 수행하도록 제한되어 있었다.
Agentic RAG는 에이전트에게 반복(Iterate) 능력을 부여하여, 필요한 정보를 스스로 결정하고 검색하며 정보를 탐색하도록 허용한다.
Agentic RAG의 작동 방식 (
Copilot Studio 및 Researcher 도구 반영):SharePoint 등에서 검색뿐만 아니라 문서 내 찾기, 목차 확인, 테이블/이미지 추출 등 다양한 API 도구를 LLM에 제공한다.
에이전트는 다음 단계를 결정하기 위해 루프를 돌며 도구를 사용한다.
사용자의 질문을 분석하고 검색할 대상을 식별한다.
검색 결과를 확인하고, 메타데이터가 짧은 문서는 전체 콘텐츠를 가져온다.
긴 문서는 목차를 요청하여 필요한 세 섹션만 추출한다.
추출된 데이터를 언어 모델에 제시하고, 다음 단계(정보가 충분한지, 반복/피벗이 필요한지)를 결정한다.
이러한 반복(2~3회 루프)을 통해 포괄적인 답변을 생성하며, 기존 검색보다 더 많은 세부 정보를 추출하고 교차 참조한다.
1.7. Agentic RAG의 적용 및 품질 향상
Agentic RAG는 단순 쿼리부터 복잡한 쿼리까지 대응하며 답변 품질을 혁신적으로 개선한다.
Copilot Studio 에서의 적용:단순 쿼리 최적화: 일부 특정 사례를 위해 검색 후 문서 검색/추출을 수행하는 하드 코딩된 파이프라인 형태의 덜 Agentic한 RAG 형태도 제공된다.
복잡한 쿼리: 더 복잡한 쿼리에는 Agentic RAG 시스템을 활용하여 고품질 답변을 제공한다.
사용자 경험 변화:
응답 대기 시, 단순 타이핑 표시 대신 에이전트가 생각하고 연구하는 상태 업데이트를 표시하게 된다.
이는 답변 품질을 높이기 위해 연구 시간을 갖는 것이며, 지연 시간(Latency)이 발생하지만 그 가치가 매우 중요하다.
Agentic RAG의 답변 품질 향상 사례:
이전에는 답변을 시도했으나 실패하거나, 두 개의 인용만 제공했다.
새로운 기술로는 동일한 두 개의 인용을 사용하더라도, 정확한 답변을 추출하고 좋은 응답을 구성한다.
이전에는 일반적인 답변만 나왔다면, 이제는 보험의 공제액(Co-pay)처럼 특정 보험 플랜에 따른 구체적인 정보를 추출하여 제공한다.
출시 계획 및 지능형 오케스트레이션:
이 기능은 2025년 11월과 12월에 걸쳐 출시될 예정이며, 이후에도 지속적으로 개선될 것이다.
Agentic RAG는 지연 시간을 추가하므로, 항상 사용되는 것은 아니다.
오케스트레이터 내의 로직이 사용자의 쿼리 복잡도를 평가하여, Agentic RAG가 필요한지 판단한다.
복잡하지 않은 경우, 더 빠른 응답을 위해 고정된 파이프라인을 사용하여 도구들을 조합할 수 있다.
1.8. 지식 관리 및 설명/지침의 중요성
RAG 구성 요소와 더불어, 지식의 초점 맞추기 및 설명/지침의 적절한 사용이 중요해졌다.
지식 초점 맞추기:
Child Agents나 특정 지식 세트에 집중하는 토픽을 사용하여 지식을 세분화할 수 있다.
예를 들어, HR 정책 정보나 IT 정책 정보와 같이 지식 컨테이너로 오케스트레이션하여 지식 간의 중복을 피할 수 있다.
설명(Description)과 지침(Instructions)의 핵심 역할:
이러한 기능이 도입되면서,
Copilot Studio 내의 설명(Description)과 지침(Instructions)의 강력함을 이해하는 것이 핵심 과제가 되었다.발표자는 SAP Ariba 조달(Procurement) 프로토타입을 만들 때 단 하나의 토픽도 만들지 않고 도구와 Child Agents만을 사용하여 구현한 사례를 언급했다.
Connected Agents보다 Child Agents가 중요하며, 이는 지침의 힘과 도구 및 지식을 결합하여 토픽에서 하던 작업을 수행할 수 있게 한다.
개발자들은 종종 지침(Instructions)에 모든 작업을 하려 하지만, 이는 설명(Description)에 해야 할 작업을 포함하는 경우가 많다.
각 요소를 적절하게 사용하는 것이 중요하다.
1.9. 설명(Description)의 힘과 MCP (Model Context Protocol)
설명과 지침은 조화롭게 사용되어야 하며, 특히 도구(API)에 대한 설명이 중요하다.
모델 컨텍스트 프로토콜 (MCP):
MCP는 REST API 또는 HTTP 엔드포인트와 그 위에 있는 설명을 쌍으로 묶는 업계 표준 프로토콜이다.
에이전트가 별도의 지침 없이도 포괄적인 MCP 서버에 연결되면, 매우 광범위한 작업을 수행할 수 있다.
도구(Tool) 정의 방식의 변화:
MCP 및 에이전트 이전: 이슈 생성, 이슈 읽기 등 각 도구 호출을 수동으로 명시해야 했다.
생성형 오케스트레이션: 도구를 수동으로 추가하는 것이 여전히 번거로웠으며, 각 도구에 대한 설명을 수동으로 입력해야 했다.
이로 인해 에이전트는 제한된 도구만 사용 가능했고 창의성이 부족했다.
MCP의 장점: GitHub의 MCP 서버처럼 방대한 기능을 포함하는 경우, 에이전트는 사용자가 요청하는 창의적인 작업(예: 이슈 열기)을 수행할 수 있다.
MCP를 활용한 복합 작업 수행:
사용자가 "이슈를 열어달라"고 요청하면, 에이전트는 지침에 따라 다음과 같은 작업을 수행한다.
이슈를 열기 전에 중복 이슈가 있는지 확인한다.
사용 가능한 태그 목록을 확인하고 적절히 태그를 지정한다.
책임자를 파악하여 적절한 사람에게 할당한다.
에이전트는 MCP 서버의 모든 기능을 활용하여, 사용자가 입력한 내용을 기반으로 여러 쿼리를 생성하여 기존 이슈를 확인한다.
지침에 제공된 정보(예: 영역별 담당자 테이블)를 바탕으로 Joe에게 할당하고 그의 GitHub 별칭을 찾아 할당한다.
결론: API 소유자가 설명을 큐레이션하면, 에이전트는 예상치 못한 요청에도 도구의 흥미로운 조합을 활용하여 강력한 경험을 제공한다.
도구 설명 작성 가이드:
MCP 서버를 활용하거나 자체 도구를 작성할 때, 도구가 유용한 이유와 기능에 대한 설명만 제공하면 충분하다.
입력과 출력을 명시하고, 에이전트가 문맥에 따라 언제 사용할지 결정하도록 맡겨야 한다.
1.10. 지침(Instructions)의 적절한 사용과 반복적 개선
도구 설명이 잘 되어 있으면, 지침에 모든 워크플로우를 명시할 필요가 줄어든다.
지침의 역할과 오용:
지침에서는 도구들을 함께 사용하라는 힌트를 줄 수 있지만, 명시적인 지침은 덜 필요하다.
개발자들은 종종 "if/then" 방식을 고수하며 모든 복잡한 워크플로우를 지침에 넣으려 한다.
지침에 쓸 공간이 부족하다는 것은 지침에 너무 많은 내용을 작성했거나, Child Agents를 사용하여 오케스트레이션을 제대로 하지 않았음을 의미한다.
혁신적인 접근 방식:
개발자는 LLM이 스스로 일하게 하고, 테스트 후 "왜 이렇게 동작했는지"를 분석하여 원하는 대로 동작하도록 영어(자연어)로 넛지(Nudge)해야 한다.
이는 과학보다는 예술에 가깝다고 비유되며, 변호사처럼 명확하게 지침을 작성하는 것이 중요하다.
설명(Description)을 통한 사전 제어:
설명에 "이 도구는 이것을 수행하지만, 절대 이것을 하지 말라"는 내용을 포함하면, 지침에서 넛지할 필요성이 줄어든다.
1.11. 미래 전망 및 코드 인터프리터의 역할
향후 대화형 AI의 발전 방향과 현재 미리보기(Preview) 기능에 대한 논의가 이어졌다.
미래에 대한 기대:
모델과 오케스트레이션의 힘이 계속 증가할 것으로 기대된다.
반복 작업 처리의 한계와 Code Interpreter:
현재 모델은 반복(Looping) 처리에 약점이 있다. 예를 들어, 문서에서 15명의 사람을 추출한 후, 각 사람에 대해 개별적으로 연구 조사를 수행하는 작업은 어렵다.
Code Interpreter는 테이블 형태의 데이터(CSV, Excel)에 대한 질문을 처리하는 데 사용되며, Python 코드를 작성하고 샌드박스 환경에서 실행하여 결과를 반환한다.
코드는 루프 처리에 강점을 가지므로, 모델이 코드를 생성하도록 하여 반복 작업을 처리할 수 있다.
Agentic RAG와 코드 생성의 결합:
미래에는 모델이 실행할 코드를 생성하고, 이 코드가 런타임 대신 도구를 직접 실행하게 될 것이다.
예를 들어, Word 문서를 업로드하면, 모델이 사람 목록을 만들고, 그 목록을 루프하며
지식 검색 을 수행하도록 코드를 생성한다.이로 인해 에이전트는 현재 메모리 한계로 인해 어려웠던 복잡하고 광범위한 작업을 수행할 수 있게 된다.
Code Interpreter 및 관련 기능:
Code Interpreter는 현재 미리보기(Preview) 기능으로 제공된다.
코드 생성(Code Generation) 기능도 프롬프트에서 시작할 수 있다.
엑셀 스프레드시트 내 계산 및 비교 기능은 M365 Copilot에서 시작되어
Copilot Studio 로 포팅되었다.발표자는 Code Interpreter에 대한 교육 콘텐츠를 추가로 제공할 예정이다.
1.12. 마무리 및 향후 계획
감사 인사 및 섭외:
발표자는 Jeff Durstat에게 시간을 내준 것에 대해 감사를 표했다.
앞으로도 대화형 AI 분야에서 영향력 있는 인물들을 섭외하여 팟캐스트를 계속 진행할 예정이다.
채널 구독 및 배포:
채널 구독을 요청했다.
팟캐스트는 Spotify, Apple Podcast, Pocketcast, YouTube에서 청취 가능하며, 다른 채널을 원하는 경우 제안을 받는다.
첫 번째 에피소드는 중복되어 있으나, 향후 모든 오디오 및 비디오 복사본은 하나의 피드 채널을 통해 일괄적으로 업데이트될 것이다.
종료:
Jeff Durstat에게 다시 한번 감사 인사를 전하며 방송을 마쳤다.
댓글
댓글 쓰기