기존 실무에 있을때에는 Uipath라는 툴을 사용하여 개발을 진행했었습니다. (보안 이슈로 블로그에는 게시하지 못했지만..)
Ai Agent로 넘어가는 추세여서 UiPath Maestro를 사용해보았지만 가볍게 접해봤었던 코파일럿과 유사한 부분이 많았고, Copilot를 더 깊이 공부해보고 싶다는 생각이 들어 글을 작성하게 되었습니다.
먼저 Copilot으로 불리는것에는 2가지 종류가 있습니다.
- Microsoft Copilot Studio
- Microsoft 365 Copilot
처음 Copilot이라는 말을 접하면 위 2개가 동일한것이 아닌가 라는 생각이 들수도 있는데
간략하게 365 Copilot의 경우 "업무를 도와주는 AI"이고,
Coilot Studio의 경우 "그 AI를 직접 만드는 도구"입니다.
| 구분 | Microsoft 365 Copilot | Copilot Studio |
| 역할 | AI 비서 (사용) | AI 제작 도구 (개발/구축) |
| 대상 | 일반 직원 | 개발자 / IT / 자동화 담당 |
| 목적 | 업무 생산성 향상 | 업무 프로세스 자동화 |
| 사용 범위 | 개인/팀 | 조직 전체 / 고객까지 확장 |
| 난이도 | 쉬움 (그냥 사용) | 중~고급 (설계 필요) |
위 내용으로 확인할 수 있듯 M365 Copilot의 경우 "현업이 쓰는 도구"로 사용자가 메일을 쓰고, 보고서를 요약하고, 회의를 정리하는데에 사용될 수 있습니다.
업무 자동화 개발자의 경우 Copilot Studio를 이용해서 자동화와 AI를 결합시켜 개발을 진행하게 됩니다.
그렇다면 M365 Copilot은 개발자의 입장에서 필요하지 않은것이 아니냐? 라고 할 수 있는데,
각각 계층구조로 이루어져 있어 "개발자"의 입장에서 Copilot Studio로 작업을 할 경우 M365 Copilot으로 보조역할을 할 수 있기 때문에 두개 다 알고있는것이 좋다고 생각합니다. 생산성의 보조 역할이 될수 있기 때문입니다. 사용자의 입장에서 생각해볼 수 있기도 하구요. (필수는 아님)
현재까지는 AI가 포함되지 않은 업무 자동화의 영역이 보편적이었지만 점차 AI 시대로 나아가게 되며 자동화 업무를 진행하고 있는 사람들에게 Agent 툴은 필수가 되어가는것 같습니다.
사실 업무자동화 툴을 사용하며 느꼈던 점은, 단순히 업무자동화 툴을 잘 사용하는게 아닌 구조(아키텍처)를 잘 아는게 가장 중요하다는 생각을 했습니다.
Agent 구조에 대해서는 따로 포스팅을 진행하겠지만 간략히 살펴보자면,
Agent의 기본 흐름은
사용자가 입력한다 → LLM이 의도를 파악한다 → 필요한 액션을 결정한다 → API / 시스템을 실행한다 → 결과를 반환한다
LLM의 동작 방식의 경우
- 프롬프트로 행동을 제어한다 (추후 굉장히 중요함)
- 컨텍스트 기반으로 답변
- 완벽하지 않아서 검증이 필요하다.
API / 시스템 연동의 경우
- REST API 호출
- 인증 (토큰, 키)
- 데이터 주고받기 (JSON)
결국 말로 명령한 후 API를 실행시키고 결과를 반환하게 됩니다.
추가적으로 순차실행이 아닌 Event 기반으로 흐름이 진행될 상황이 많은데,
상황에따라 분기처리가 잘 진행되어야 합니다.
Copliot은 결국 "AI를 통한 대화 기반의 워크플로우 설계"이기 때문에
비버가 A를 말하면 프로세스 1을 실행시켜라.
비버가 B를 말하면 프로세스 2를 실행시켜라.
위와 같은 분기 설계가 중요합니다.
여기서 가장 중요한 부분은 AI는 모든 일을 해주지 않는다는것입니다.
따라서 실질적으로 모든 일을 AI에게 맡긴다는건 불가능하고 결국 사람의 판단이 필요합니다.
- 어디까지 AI에게 맡길 것인가?
- 어디서 사람이 개입할것인가?
예시로, 승인이 필요한 프로세스는 AI에게 완전 자동화를 맡기게 된다면 승인이 되지 않아야할것도 승인이 되어버릴 수 있습니다.
이러한 경우에는 "사람의 개입"이 필요합니다.
만약 단순 "데이터 수집"의 경우에는 사람의 개입이 필요하지 않아 완전 자동화가 가능합니다.
결국 Copilot은 "기존의 자동화와 LLM을 통합해 End-to-End 자동화를 구현하는 플랫폼"이라고 이해하면 될것 같습니다.