1부 · 왜 다시 만들었나
클래식의 구조적 한계와 코어 재건축의 이유.
0. Copilot Studio, 왜 다시 만들었나
▶ 포인트 — 클래식은 “대화를 설계”하는 도구였고, 그 패러다임 자체가 다단계·장기 작업에서 천장에 부딪혔다. 그래서 Microsoft는 UI가 아니라 AI 코어 자체를 코딩 하네스 위에 다시 지었다.
0.1 클래식의 구조적 한계
클래식 Copilot Studio(구 Power Virtual Agents)는 본질적으로 대화 흐름 설계 도구였습니다. 메이커가 직접 그려야 했던 것:
- Topics — “사용자가 X라고 말하면 → 노드 A → 노드 B”의 트리거-응답 트리
- Prompts — 특정 입력→특정 출력의 단발성 AI 호출
- 분기·조건·변수 — 모든 경우의 수를 노드로 연결
이 방식의 결정적 약점은 모든 경로를 사람이 미리 상상해서 그려야 한다는 것입니다. 시나리오가 조금만 복잡해져도 분기가 폭발하고, 사용자가 예상 밖의 말을 하면 흐름이 끊깁니다.
이 모델은 FAQ 챗봇·정형 시나리오에는 잘 맞았지만, 한계가 분명했습니다.
| 한계 | 증상 |
|---|---|
| 흐름이 깨짐 | 다단계 작업 중간에 예상 못한 입력이 오면 토픽이 끊김 |
| 분기 폭발 | 시나리오가 복잡해질수록 노드·조건이 기하급수적으로 증가 |
| 도구 호출이 경직 | 어떤 도구를 언제 부를지 메이커가 미리 다 설계해야 함 |
| 긴 작업 불가 | “문서를 읽고 분석해서 보고서를 써줘” 같은 long-horizon 작업이 어려움 |
그리고 이 한계들이 복잡한 작업에서 구체적으로 어떻게 터지는지를, Anthropic은 Effective harnesses for long-running agents에서 두 가지 실패 모드로 정리했습니다 — 클래식 봇이 무너지던 양상과 정확히 같습니다.
| Anthropic이 진단한 실패 모드 | 클래식 봇에서의 증상 |
|---|---|
| 한 방에 다 하려다(one-shot) 컨텍스트 중간에 소진 | 다단계 작업이 중간에 끊기고 미완성 상태로 종료 |
| 진척을 보고 다 됐다고 조기 선언(declares the job done) | 핵심 기능이 안 되는데 대화가 끝나버림 |
0.2 무엇을 바꿨나 — 코어 재건축
고객 피드백의 핵심은 세 가지였습니다(블로그·로드맵 슬라이드 4 기준):
- 에이전트가 업무의 자연스러운 일부가 되길 원한다
- 신뢰할 수 있고 확장 가능한(reliable & scalable) 에이전트 플랫폼이 필요하다
- 에이전트·앱·결정론적 워크플로우가 함께 잘 동작하길 원한다
그래서 Microsoft의 선택은 UI 손보기가 아니라 AI 코어(오케스트레이터)를 새로운 coding harness · CLI 레이어 위에 재건축하는 것이었습니다. 결과적으로 얻은 능력:
- 지시 준수(instruction adherence) 강화 — 특히 긴 대화에서도 원래 지침을 안 놓침
- 장기·다단계(long-horizon) 작업 — 중간에 무너지지 않고 끝까지
- 재귀적 실행(recursive task execution) — 복잡한 문제를 스스로 단계로 쪼개 반복
- 대용량 콘텐츠 + 리치 파일 생성 — 전용 컨테이너에서 Word/PPT/Excel/CSV/PDF 산출
빌드 경험도 단순화: 구성 탭 9개 → 4개(Build·Test·Preview·Monitor), 지침·스킬·도구·지식이 한 화면, 풀페이지 테스트에서 추론 과정(inline chain-of-thought)과 도구 호출(tool calling)을 실시간 관찰.
반론 대응(FAQ): “이거 그냥 UI 리스킨 아니냐?” → 신뢰성·다단계 처리 향상은 UI가 아니라 새로운 AI 코어의 기능입니다. 재설계된 UI는 그 코어를 뒷바침 해주는 메이커의 제작 경험을 개선할 뿐입니다.