Microsoft 365 Copilot 으로 대화 말고 ‘자동화’ 하기 — 트리거·액션·에이전트
Summary
지난 두 글에서는 Copilot 을 채팅창에 대고 시키는 쪽으로 봤어요. 제품군 지도를 그렸고(총정리), 앱마다 어떤 프롬프트를 던지면 뭐가 나오는지도 정리했죠(앱별 활용). 그런데 그건 전부 내가 묻고 → Copilot 이 답하는 구조였어요. 매번 사람이 앉아서 프롬프트를 쳐야 한다는 뜻이에요.
이번 글은 그 반대편이에요. 프롬프트를 매번 안 쳐도 알아서 도는 영역 — 즉 자동화에 집중합니다. 메일이 도착하면, 정해진 시각이 되면, 어떤 이벤트가 발생하면 Copilot 이 스스로 판단하고 외부 시스템에 결과를 써넣는 흐름이죠. 핵심 키워드는 세 개예요. 트리거(언제 시작하나), 액션(무엇을 바꾸나), 그리고 그 둘을 묶는 에이전트/플로우.
💡 이 글에서 다루는 것
- 대화 vs 자동화 — 무엇이 근본적으로 다른가
- 자동화의 3요소 — 트리거 · 액션 · 근거(지식)
- 만드는 사다리 — Agent Builder(노코드) → Copilot Studio(로우코드) → Agents Toolkit(프로코드)
- 트리거 — 수동·스케줄·이벤트로 시작점 잡기
- 액션 — 메일 발송·티켓 생성·CRM 갱신·Power Automate 호출
- 에이전트 플로우 / 워크플로우 — 결정적 자동화 + 필요할 때만 AI 호출
- 자율 에이전트 — 사람 없이 도는 것과 그 과금·거버넌스 함정
- 실전 시나리오 3개와 “넘기기 전에 챙길 점”
⚠️ 자동화 기능은 마이크로소프트가 가장 빠르게 갈아엎는 영역이에요. 이 글은 2026년 상반기 기준이고, 메뉴 이름·과금 단위·트리거 종류는 자주 바뀝니다. 또 자동화를 만들려면 보통 직장·학교 구독 + Copilot Studio 권한이 필요하고, 일부는 관리자가 열어줘야 보여요.
1. 대화와 자동화는 무엇이 다른가
같은 Copilot 인데 “대화” 와 “자동화” 는 작동 방식이 근본적으로 달라요. 한 표로 먼저 잡고 갈게요.
| 대화형 | 자동화형 | |
|---|---|---|
| 시작 | 사람이 프롬프트를 침 | 트리거가 켜짐(시각·이벤트·메일) |
| 사람 자리 | 매번 루프 안에 있음 | 만들 때만, 실행은 무인 |
| 결과 | 화면에 답이 뜸 | 외부 시스템에 써짐(메일·티켓·레코드) |
| 반복 | 매번 다시 쳐야 함 | 한 번 만들면 계속 돎 |
| 대표 도구 | Word·Excel·Teams 안의 Copilot | Agent Builder · Copilot Studio |
핵심 차이는 두 가지예요. 하나는 시작을 사람이 안 한다는 것(트리거), 다른 하나는 결과가 화면이 아니라 시스템에 남는다는 것(액션)이에요. 이 두 개가 빠지면 그냥 빠른 비서고, 이 두 개가 들어가면 비로소 “자동화” 가 됩니다.
💡 그래서 자동화를 설계할 때 던질 질문은 “이걸 잘 설명하면 답을 잘 해줄까?” 가 아니라 “무엇이 이걸 켜고(트리거), 끝나면 어디에 무엇을 남기나(액션)?” 예요.
2. 자동화의 3요소 — 트리거 · 액션 · 근거
대화형 Copilot 이 근거(지식) 하나로 돌았다면, 자동화는 거기에 트리거와 액션이 더 붙어요. 이 세 개가 자동화의 뼈대예요.
| 요소 | 질문 | 예 |
|---|---|---|
| 트리거 | 언제 시작하나? | 메일 도착 · 매일 오전 8시 · 폼 제출됨 |
| 근거(지식) | 무엇을 보고 판단하나? | 사내 위키 · SharePoint 문서 · 메일 스레드 |
| 액션 | 무엇을 바꾸나? | 답장 발송 · Jira 티켓 생성 · 시트 한 줄 추가 |
대화형에서 익숙한 “내 권한 안의 데이터만 본다” 는 원칙은 자동화에서도 그대로예요. 다만 자동화는 쓰기까지 한다는 게 무서운 부분이에요. 잘못 만든 트리거가 잘못된 액션을 무한히 반복하면, 화면에 오답이 뜨는 것과는 차원이 다른 사고가 나요. 그래서 뒤에서 거버넌스를 따로 짚을게요.
3. 만드는 사다리 — 노코드에서 프로코드까지
“자동화를 만든다” 고 하면 거창하게 들리는데, 실제로는 난이도가 다른 세 단계가 있어요. 필요한 만큼만 올라가면 돼요.
| 단계 | 도구 | 누가 | 무엇을 |
|---|---|---|---|
| 노코드 | Agent Builder(M365 Copilot 안) | 일반 사용자 | 자연어로 지식+액션 붙인 declarative 에이전트 |
| 로우코드 | Copilot Studio | 파워유저·시민개발자 | 트리거·플로우·자율 에이전트, 1000+ 커넥터 |
| 프로코드 | Agents Toolkit(VS Code) | 개발자 | 코드로 정밀 제어, HTTP 트리거·커스텀 API |
노코드 — Agent Builder
가장 가벼운 입구예요. Microsoft 365 Copilot 화면 안에서 자연어로 “이런 일을 하는 에이전트를 만들어줘” 라고 말하면, 지식(특정 SharePoint 사이트·문서)과 간단한 액션을 붙인 declarative 에이전트가 만들어져요. 거창한 자율 실행보다는 “특정 주제에 특화된 Copilot” 을 빠르게 찍어내는 용도예요.
💡 declarative 에이전트는 별도 모델을 띄우는 게 아니라, 365 Copilot 과 똑같은 오케스트레이터·모델 위에서 지식과 액션만 내가 끼워넣는 구조예요. 그래서 만들기 쉽고, 보안·권한도 본체 Copilot 을 그대로 따라가요.
로우코드 — Copilot Studio
진짜 자동화는 여기서 시작해요. 트리거를 붙이고, 여러 단계를 잇고, 외부 시스템에 액션을 날리는 걸 화면에서 블록으로 조립해요. 자율 에이전트와 에이전트 플로우(뒤에서 설명)가 다 여기 있어요. Power Platform 의 1000+ 커넥터를 그대로 끌어 쓸 수 있는 게 강점이에요.
프로코드 — Agents Toolkit
VS Code 에서 코드로 만드는 방식이에요. 예를 들어 declarative 에이전트의 액션을 Power Automate 의 HTTP 트리거에 연결해 두면, 에이전트가 그 엔드포인트를 때려서 임의의 업무 프로세스를 굴리게 할 수 있어요. 정밀 제어·CI 연동·복잡한 API 호출이 필요할 때 내려가는 단계예요.
✅ 처음부터 프로코드로 갈 필요는 없어요. “노코드로 안 되면 로우코드, 그래도 안 되면 프로코드” 순서로 올라가는 게 비용·유지보수 면에서 합리적이에요.
4. 트리거 — 자동화의 시작점
자동화를 대화와 가르는 첫 번째 선이 트리거예요. 사람이 프롬프트를 치는 대신 무엇이 이 흐름을 켜느냐죠. 크게 세 종류예요.
| 트리거 | 언제 | 예시 |
|---|---|---|
| 수동 | 사람이 버튼/명령으로 시작 | “주간 보고 만들기” 버튼 |
| 스케줄 | 정해진 시각·주기 | 매주 금요일 오후 4시 |
| 이벤트 | 다른 시스템에서 무슨 일이 생김 | 메일 도착 · 폼 제출 · 레코드 변경 |
에이전트 플로우와 워크플로우는 이 셋 중 무엇으로든 켤 수 있고, 다른 자동화나 에이전트가 또 다른 자동화를 트리거할 수도 있어요. 자동화가 자동화를 부르는 사슬이 되는 거예요.
⚠️ 이벤트 트리거는 편한 만큼 위험해요. “메일 도착 → 답장 발송” 을 잘못 짜면, 자동 답장이 또 상대의 자동 답장을 트리거하는 무한 루프가 날 수 있어요. 트리거 조건(보낸 사람·제목 필터)을 좁히고, 실행 횟수 상한을 거는 습관이 필요해요.
5. 액션 — 화면이 아니라 시스템에 쓰기
두 번째 선은 액션이에요. 대화형 Copilot 은 결과를 화면에 보여주고 끝이지만, 자동화 에이전트는 결과를 실제 시스템에 써넣어요. 이게 declarative 에이전트에 “액션” 을 붙이는 이유예요.
| 액션 | 하는 일 |
|---|---|
| 메일 발송 | 요약·답장을 사람 손 안 거치고 보냄 |
| 티켓 생성 | ITSM(서비스나우 등)에 인시던트 등록 |
| 레코드 갱신 | Dynamics·CRM 의 고객 정보 업데이트 |
| Power Automate 호출 | 정해둔 플로우를 실행해 임의 시스템 연동 |
| 알림 전송 | Teams 채널·담당자에게 푸시 |
특히 Power Automate 호출이 만능 열쇠예요. 액션 목록에 없는 동작이라도, Power Automate 플로우 하나 만들어서 거기에 연결해 두면 사실상 무엇이든 트리거할 수 있어요. “에이전트가 판단 → 플로우가 실행” 의 분업이죠.
💡 액션을 붙이는 순간 에이전트는 “읽고 답하는” 존재에서 “세상을 바꾸는” 존재가 돼요. 그래서 액션마다 “이게 잘못 실행되면 무슨 일이 나나?” 를 한 번씩 적어보는 걸 추천해요. 메일 발송·결제·삭제 같은 되돌리기 어려운 액션은 사람 승인 단계를 끼우는 게 안전합니다.
6. 에이전트 플로우 / 워크플로우 — 결정적 자동화 + 필요할 때만 AI
여기가 2026년 들어 가장 많이 바뀐 부분이에요. 예전엔 “AI 에이전트” 와 “정해진 절차 자동화(Power Automate 식)” 가 따로 놀았는데, 지금은 한 캔버스에서 섞어 짜요.
핵심 아이디어는 이거예요. 자동화의 대부분은 결정적(deterministic) 으로 흘러야 해요 — “폼이 들어오면 → 이 표에 한 줄 추가 → 담당자에게 알림” 같은 건 AI 의 창의력이 필요 없고, 매번 똑같이 도는 게 맞아요. 그러다 딱 한 군데, 판단이 필요한 지점에서만 AI(에이전트)를 부르는 거예요.
[폼 제출] ← 트리거
↓
분류가 애매한가?
├─(명확) → 규칙대로 라우팅 ← 결정적 플로우
└─(애매) → 에이전트에게 "어느 팀?" ← 여기서만 AI 호출
↓
팀 배정 결과로 라우팅 계속
이렇게 agent node(플로우 중간에서 에이전트를 부르는 블록)를 끼우면, “안정적이고 예측 가능한 자동화” 와 “유연한 AI 판단” 의 장점을 같이 가져가요. 전부 AI 에게 맡기면 매번 결과가 흔들리고, 전부 규칙으로만 짜면 예외 처리가 지옥이 되거든요. 그 사이 균형점이에요.
✅ 설계 원칙 한 줄: “되도록 결정적으로, AI 는 꼭 필요한 한 지점에서만.” 자동화는 재현성이 생명이라, AI 호출 지점을 적게 둘수록 디버깅이 쉬워져요.
7. 자율 에이전트 — 사람이 빠진 파이프라인
가장 끝단이 자율 에이전트(autonomous agent) 예요. 트리거로 스스로 깨어나서, 계획을 세우고, 여러 단계를 실행하고, 막히면 사람에게 에스컬레이션까지 해요. 사람이 매 단계 확인하지 않는다는 점에서 진짜 “무인” 자동화예요.
- 트리거로 깨어남 — 사람의 프롬프트가 아니라 이벤트·스케줄이 시작점
- 스스로 계획·실행 — 목표를 받고 필요한 단계를 알아서 밟음
- 막히면 에스컬레이션 — 애매하거나 권한이 부족하면 사람에게 넘김
좋아 보이지만, 자율성에는 두 가지 비용이 따라와요.
첫째, 과금. 자율 실행은 보통 일반 채팅과 다른 단위로 과금돼요. 생성형 오케스트레이션으로 도는 자율 에이전트는 자율 액션(autonomous action) + 플로우 액션이 같이 카운트돼서, 무심코 자주 도는 에이전트를 풀어두면 비용이 빠르게 붙어요.
둘째, 통제. 사람이 루프에서 빠진 만큼, 잘못 돌 때 알아채기가 늦어요. 그래서 자율 에이전트일수록 실행 로그·승인 게이트·횟수 상한을 더 촘촘히 걸어야 해요.
🚨 자율 에이전트를 처음 풀 때는 읽기 전용 또는 초안만 만드는 범위로 시작하세요. “티켓을 자동 생성” 대신 “티켓 초안을 담당자에게 제안”, “메일 자동 발송” 대신 “답장 초안을 보낸 편지함에 대기” 식으로요. 신뢰가 쌓인 다음 쓰기 권한을 넓히는 게 안전해요.
8. 실전 시나리오 3개
개념만으론 손에 안 잡히니, 자주 만드는 자동화 셋을 트리거→근거→액션 골격으로 풀어볼게요.
시나리오 A — 받은 편지함 자동 분류·라우팅
| 요소 | 내용 |
|---|---|
| 트리거 | 특정 메일함에 메일 도착(이벤트) |
| 근거 | 메일 본문 + 사내 분류 기준 문서 |
| 액션 | 카테고리 태깅 → 담당 팀 채널로 알림 → 긴 건은 요약 첨부 |
문의 메일이 쏟아지는 공용 메일함에 잘 맞아요. 분류가 명확하면 규칙대로, 애매하면 agent node 가 “어느 팀?” 만 판단하게 짜면 됩니다.
시나리오 B — 주간 리포트 자동 생성·배포
| 요소 | 내용 |
|---|---|
| 트리거 | 매주 금요일 오후 4시(스케줄) |
| 근거 | 이번 주 프로젝트 문서·회의 요약·메일 |
| 액션 | 한 장 요약 생성 → Pages/문서로 저장 → 팀 채널 게시 |
매주 손으로 긁어모으던 걸 통째로 무인화해요. 사람은 금요일에 완성된 초안을 검토만 하면 돼요.
시나리오 C — 승인 라우팅
| 요소 | 내용 |
|---|---|
| 트리거 | 휴가/구매 신청 폼 제출(이벤트) |
| 근거 | 사내 규정·결재선 정보 |
| 액션 | 규정 위반 여부 판단 → 결재자에게 승인 요청 → 결과 회신 |
여기서 금액·되돌리기 어려움이 큰 액션(실제 결재 승인)은 자동 실행이 아니라 사람 승인 게이트로 두는 게 정석이에요. AI 는 “규정에 맞는지 1차 점검 + 초안 라우팅” 까지만.
💡 세 시나리오의 공통 패턴이 보이죠? 트리거로 깨어나 → 근거로 판단 → 시스템에 쓰되 → 위험한 마지막 한 칸은 사람에게. 이 골격을 그대로 다른 업무에 갈아끼우면 돼요.
9. 넘기기 전에 챙길 점
자동화는 한 번 잘못 풀면 대화형과 비교가 안 되게 시끄러워요. 발행(=운영 투입) 전에 이건 꼭 보세요.
- 권한 = 자동화의 사정거리. 에이전트는 만든 사람(또는 지정한 계정)의 권한으로 데이터를 보고 액션을 해요. 권한이 넓은 계정으로 만들면 사정거리도 넓어집니다. 최소 권한으로.
- 트리거 루프 차단. 메일·알림처럼 자기 액션이 자기 트리거를 또 켤 수 있는 흐름엔 필터와 실행 상한을 거세요.
- 결정적 우선. AI 호출 지점은 적게. 매번 결과가 흔들리면 자동화가 아니라 도박이에요.
- 되돌리기 어려운 액션엔 사람 게이트. 발송·결제·삭제·외부 공개는 자동 실행 대신 승인 단계로.
- 과금 가시성. 특히 자율 에이전트는 자주 돌수록 비용이 붙어요. 실행 빈도와 액션 수를 모니터링하세요.
- 거버넌스·로그. 누가 어떤 에이전트를 만들었고 무슨 액션을 했는지 관리자가 볼 수 있어야 해요. “그림자 자동화” 가 쌓이면 사고 원인 추적이 불가능해집니다.
10. 한 장 요약
| 축 | 대화형 Copilot | 자동화 Copilot |
|---|---|---|
| 시작 | 사람 프롬프트 | 트리거(수동·스케줄·이벤트) |
| 사람 | 매번 루프 안 | 만들 때만 |
| 결과 | 화면 표시 | 시스템에 쓰기(액션) |
| 만드는 곳 | 없음(그냥 씀) | Agent Builder → Copilot Studio → Agents Toolkit |
| AI 비중 | 전부 AI | 결정적 + 필요할 때만 AI |
| 가장 큰 함정 | 사실 오류 | 트리거 루프·과금·통제 상실 |
정리하면, Microsoft 365 Copilot 의 자동화는 “트리거로 깨어나, 근거로 판단하고, 시스템에 결과를 쓰는 파이프라인” 이에요. 대화형이 “빠른 비서” 라면 자동화는 “안 보이는 곳에서 도는 직원” 에 가까워요. 그래서 더 강력하지만, 더 조심해야 해요. 되도록 결정적으로 짜고, AI 는 꼭 필요한 지점에서만 부르고, 위험한 마지막 한 칸은 사람에게 남겨두는 것 — 이 세 원칙만 지키면 자동화가 사고가 아니라 자산이 됩니다.
일단 오늘은 여기까지…..
다음 글에서는 Copilot Studio 로 첫 자율 에이전트를 직접 만들어보는 과정을 단계별로 정리해볼게요.
← 이전 글: Microsoft 365 Copilot 앱별 실전 활용 ｜ 함께 보기: MS Copilot 제품군 총정리
