(5/7) Copilot Studio 규정 봇에 액션 붙이기 — ‘안내’에서 ‘휴가 신청’까지
🤖 Microsoft Copilot 활용·제작 시리즈 (전체 7편)
- MS Copilot 으로 할 수 있는 일 총정리 — 365 · 소비자 · GitHub · Studio
- Microsoft 365 Copilot 앱별 실전 활용 — Word·Excel·PowerPoint·Outlook·Teams
- Microsoft 365 Copilot 으로 대화 말고 '자동화' 하기 — 트리거·액션·에이전트
- Copilot Studio 로 사내 규정 Q&A 봇 직접 만들기 — 지식 연결부터 게시까지
- Copilot Studio 규정 봇에 액션 붙이기 — '안내'에서 '휴가 신청'까지 ← 지금 글
- Copilot Studio 자율 에이전트 만들기 — 사람이 안 불러도 도는 메일 분류봇
- Agents Toolkit 으로 프로코드 에이전트 만들기 — VS Code 에서 코드로 정의하기
Summary
지난 규정 Q&A 봇 글에서 우리는 읽고 답하는 봇을 만들었어요. “육아휴직 며칠?” 에 출처를 달아 답하는 데까지 갔죠. 이번 글은 그 봇을 한 칸 더 밀어요. 읽기에서 쓰기로 — 즉 “휴가 5일 신청해줘” 라고 하면 실제로 신청을 등록하고 결재까지 올리는 액션을 붙입니다.
여기서부터가 자동화의 진짜 경계예요. 안내는 틀려도 사람이 다시 물어보면 그만이지만, 신청·차감·발송 같은 쓰기 액션은 잘못 돌면 되돌리기가 어려워요. 그래서 이번 글의 절반은 “어떻게 신청을 처리하나” 이고, 나머지 절반은 “어떻게 사고를 막나” 예요. 잔여 확인·사람 승인 게이트·권한·로그를 같은 비중으로 다뤄요.
💡 이 글에서 만드는 것
- 읽기 vs 쓰기 — 액션이 더하는 위험
- 액션의 두 갈래 — 커넥터 액션 vs Power Automate 플로우
- 플로우 만들기 — 입력 → 잔여 확인 → 승인 → 기록 → 응답
- 에이전트에 액션 연결 — 설명이 곧 트리거
- 입력 슬롯 채우기 — 빠진 값 되묻기 · Adaptive Card
- 사람 승인 게이트 — 되돌리기 어려운 한 칸
- 테스트 — 정상 신청 / 잔여 부족 거절 / 모호한 입력 되묻기
- 권한·되돌리기·감사 로그
⚠️ 2026년 상반기 기준이에요. 따라오려면 직장·학교 구독 + Copilot Studio + Power Automate 권한 이 필요하고, 일부는 관리자가 환경/커넥터를 열어줘야 보여요. 본문의 사번·이름·시스템은 전부 예시값(마스킹)이에요. 실제 인사·근태 시스템 연동은 회사 환경에 맞춰 커넥터를 바꿔야 해요.
1. 읽기 봇에 쓰기를 더한다는 것
같은 봇이지만 “안내” 와 “신청” 은 무게가 완전히 달라요. 한 표로 먼저 잡고 갈게요.
| 읽기(지식 Q&A) | 쓰기(액션) | |
|---|---|---|
| 하는 일 | 규정을 찾아 답함 | 신청·차감을 시스템에 씀 |
| 틀렸을 때 | 다시 물으면 됨 | 잘못된 신청이 남음 |
| 되돌리기 | 필요 없음 | 어렵거나 불가 |
| 꼭 필요한 것 | 출처 | 확인 + 사람 승인 |
핵심은 마지막 줄이에요. 읽기 봇의 안전장치가 “출처” 였다면, 쓰기 봇의 안전장치는 “실행 전 확인” 과 “사람 승인 게이트” 예요. 이게 빠지면 봇이 아니라 사고기예요.
🚨 첫 액션을 붙일 때 원칙 하나만 가져가세요. “되돌리기 어려운 액션은 자동 실행하지 않는다.” 휴가 신청은 결재 취소가 가능하니 그나마 낫지만, 그래도 제출 전 사용자 확인 과 상급자 승인 두 칸을 끼워요.
2. 액션의 두 갈래 — 커넥터 vs 플로우
Copilot Studio 에서 에이전트에 액션을 붙이는 길은 크게 둘이에요.
| 방식 | 무엇 | 언제 |
|---|---|---|
| 커넥터 액션 | 미리 만들어진 단일 동작(메일 보내기, 행 추가 등) | 한 방에 끝나는 단순 동작 |
| Power Automate 플로우 | 여러 단계를 엮은 내 워크플로우 | 조건·승인·여러 시스템이 얽힐 때 |
휴가 신청은 단순한 한 동작이 아니에요. 잔여를 확인하고 → 규정에 맞는지 보고 → 상급자 승인을 받고 → 기록을 남기는 여러 단계가 묶여요. 그래서 우리는 Power Automate 플로우 쪽을 써요. 플로우를 하나 만들어 두고, 에이전트가 그 플로우를 호출 하게 하는 구조예요.
[에이전트] "휴가 신청을 처리하려면 이 플로우를 부른다"
│ 입력: 사번 · 시작일 · 종료일 · 휴가유형
▼
[Power Automate 플로우] 잔여 확인 → 승인 → 기록
│ 출력: 처리 상태 · 신청번호
▼
[에이전트] 사용자에게 결과를 말로 전달
이 “에이전트가 판단/대화, 플로우가 실제 일 처리” 라는 분업이 핵심이에요. 대화의 유연함은 에이전트가, 결정적이고 안전해야 하는 실행 은 플로우가 가져가요.
💡 자동화 개념 글에서 “되도록 결정적으로, AI 는 꼭 필요한 지점에서만” 이라고 했던 그 원칙이 여기서 손에 잡혀요. 신청 처리 로직은 플로우(결정적)에, “무슨 휴가를 며칠 원하는지 알아듣기” 만 에이전트(AI)에 둬요.
3. 만들 흐름 한눈에
만들기 전에 전체 그림을 박아둘게요. 사용자의 한 마디에서 신청 완료까지 이렇게 흘러요.
사용자: "다음 주 월~금 연차 쓸게"
↓
에이전트: 입력 슬롯 채우기
├─ 휴가유형 = 연차 (알아들음)
├─ 시작일 = 다음 주 월 (알아들음)
└─ 종료일 = ? (모호 → 되물음)
↓
Adaptive Card 로 신청 내용 확인 ("이렇게 제출할까요?")
↓
[Power Automate 플로우 호출]
├─ 1) 잔여 휴가 조회
├─ 2) 잔여 < 신청일수? → 거절 응답
├─ 3) 상급자 승인 요청 ← 사람 게이트
└─ 4) 승인되면 기록 + 잔여 차감
↓
에이전트: "신청번호 LV-0000, 승인 대기 중입니다"
이 그림에서 AI 가 일하는 칸은 맨 위 두 칸(알아듣고 되묻기)뿐 이에요. 나머지는 전부 플로우의 결정적 단계예요. 그래서 신청 처리가 매번 같은 방식으로, 예측 가능하게 돌아가요.
4. Power Automate 플로우 만들기
먼저 일을 실제로 처리할 플로우부터 만들어요. Copilot Studio 의 에이전트 화면에서 액션 추가(Add action) → 새 플로우 만들기(Create a flow) 로 들어가면 Power Automate 캔버스가 열려요. 트리거는 “Copilot 에서 호출됨(When an agent calls the flow)” 으로 시작해요.
4-1. 입력 파라미터 정의
플로우가 에이전트한테서 받을 값을 정해요.
| 입력 | 타입 | 예시값 |
|---|---|---|
employeeId |
텍스트 | EMP-0000 |
leaveType |
텍스트 | 연차 |
startDate |
날짜 | 2026-06-29 |
endDate |
날짜 | 2026-07-03 |
4-2. 잔여 휴가 조회
실제 환경에선 인사·근태 시스템 커넥터(또는 사내 API)를 호출하는 자리예요. 이 글에선 예시로 SharePoint 리스트나 Dataverse 테이블에서 사번으로 잔여를 읽어온다고 할게요.
액션: (인사 시스템) 사번 = employeeId 로 잔여 휴가 조회
출력: remainingDays = 8
4-3. 조건 분기 — 잔여가 모자라면 거절
신청 일수를 계산해서 잔여와 비교해요.
requestedDays = 영업일(startDate ~ endDate) = 5
조건: requestedDays > remainingDays ?
├─ 예 → status = "거절: 잔여 부족" 으로 응답 반환하고 종료
└─ 아니오 → 다음 단계(승인)로
4-4. 상급자 승인 — 사람 게이트
여기가 가장 중요한 칸이에요. Power Automate 의 승인(Approvals) 액션을 끼워서, 신청을 바로 확정하지 않고 상급자에게 승인 요청 을 보내요.
액션: 승인 시작 및 대기 (Start and wait for an approval)
유형: 승인/거부
받는 사람: (상급자 메일)
제목: [휴가 신청] EMP-0000 연차 5일 (06/29~07/03)
출력: outcome = Approve | Reject
상급자가 Teams/메일에서 버튼 한 번으로 처리하면 그 결과가 outcome 으로 돌아와요.
4-5. 기록 + 잔여 차감, 그리고 응답
승인 결과에 따라 마지막을 처리해요.
outcome = Approve ?
├─ 예 → 신청 레코드 생성(신청번호 LV-0000 발급)
│ + 잔여 휴가 차감(8 → 3)
│ → status = "승인 완료", leaveId = "LV-0000"
└─ 아니오 → status = "반려됨"
마지막: 에이전트에 반환 (응답 파라미터)
status, leaveId, remainingAfter
플로우의 반환값(status·신청번호·차감 후 잔여) 이 에이전트가 사용자에게 말해줄 재료예요.
⚠️ 4-2~4-5 의 시스템 연결(인사 조회·레코드 생성)은 회사마다 달라요. SharePoint/Dataverse/사내 API 중 무엇을 쓰든 “읽기(잔여) → 판단 → 승인 → 쓰기(기록)” 순서만 지키면 구조는 똑같아요.
5. 에이전트에 액션 연결하기
플로우를 저장하면 에이전트의 액션 목록에 잡혀요. 여기서 가장 중요한 건 액션의 이름과 설명(description) 이에요. Copilot Studio 는 이 설명을 읽고 “사용자가 이런 말을 하면 이 액션을 부르면 되겠다” 를 판단하거든요. 설명이 곧 트리거 역할이에요.
| 필드 | 적은 값 |
|---|---|
| 액션 이름 | 휴가 신청 처리 |
| 설명 | 사용자가 휴가(연차·반차·경조 등)를 신청하려 할 때 호출. 휴가 유형과 시작·종료일을 받아 잔여를 확인하고 상급자 승인을 거쳐 신청을 등록한다. |
| 입력 | employeeId, leaveType, startDate, endDate |
| 출력 | status, leaveId, remainingAfter |
💡 설명을 모호하게 적으면(“휴가 관련 처리”) 엉뚱한 질문에도 액션이 튀어나와요. 반대로 너무 좁게 적으면(“연차 5일 신청”) 반차·경조는 못 잡아요. “무엇을 할 때 부르는지 + 무엇을 받아 무엇을 하는지” 를 한 문장에 담는 게 좋아요.
6. 입력 슬롯 채우기 — 빠진 값은 되묻기
액션에는 입력 4개가 필요해요. 사용자가 한 번에 다 말해주지 않으니, 에이전트가 빠진 값을 되묻는 게 자연스러워야 해요. 이걸 슬롯 필링(slot filling)이라고 해요. 입력마다 “이게 비어 있으면 이렇게 물어봐” 를 지정해 둬요.
| 슬롯 | 비었을 때 되묻는 말 |
|---|---|
leaveType |
“어떤 휴가인가요? (연차·반차·경조 등)” |
startDate |
“언제부터 시작하나요?” |
endDate |
“언제까지인가요?” |
employeeId 는 보통 로그인한 사용자 정보에서 자동으로 채워요(사용자가 직접 사번을 칠 필요 없음). 실제 대화에선 이렇게 흘러요.
나: 휴가 신청할게
봇: 어떤 휴가인가요? (연차·반차·경조 등)
나: 연차
봇: 언제부터 언제까지인가요?
나: 다음 주 월요일부터 금요일까지
봇: 확인했어요. 아래 내용으로 신청할게요. 맞으면 '제출' 을 눌러주세요.
Adaptive Card 로 마지막 확인
값이 다 모이면, 바로 제출하지 말고 Adaptive Card 로 신청 내용을 한 번 더 보여줘요. 쓰기 액션 직전의 “정말 이대로?” 게이트예요.
{
"type": "AdaptiveCard",
"body": [
{ "type": "TextBlock", "text": "휴가 신청 확인", "weight": "Bolder", "size": "Medium" },
{ "type": "FactSet", "facts": [
{ "title": "유형", "value": "연차" },
{ "title": "기간", "value": "2026-06-29 ~ 2026-07-03 (5일)" },
{ "title": "신청자", "value": "EMP-0000" }
]}
],
"actions": [
{ "type": "Action.Submit", "title": "제출", "data": { "confirm": true } },
{ "type": "Action.Submit", "title": "취소", "data": { "confirm": false } }
]
}
사용자가 제출 을 눌러야 비로소 플로우가 호출돼요. 이 한 칸이 “말실수로 신청이 나가는” 사고를 막아줘요.
✅ 슬롯 필링 + 확인 카드는 쓰기 액션의 기본 예절이에요. 읽기 봇엔 없던 단계지만, 쓰기 봇엔 반드시 넣으세요. 사람이 “예” 라고 누르는 명시적 순간을 만드는 게 핵심이에요.
7. 사람 승인 게이트 다시 보기
플로우 4-4 에서 넣은 승인(Approvals) 단계를 한 번 더 짚을게요. 확인 카드(사용자 본인 확인)와 승인 게이트(상급자 결재)는 다른 게이트 예요.
| 게이트 | 누가 | 무엇을 막나 |
|---|---|---|
| 확인 카드 | 신청자 본인 | 말실수·오타로 잘못 제출 |
| 승인 | 상급자 | 권한·규정에 안 맞는 신청 |
두 개를 다 통과해야 기록이 남아요. 상급자에겐 이런 승인 요청이 가요.
[휴가 신청 승인 요청]
신청자: EMP-0000
유형: 연차 5일
기간: 2026-06-29 ~ 07-03
잔여: 8일 → 승인 시 3일
[ 승인 ] [ 반려 ]
🚨 “AI 가 알아서 승인까지” 는 편해 보여도 사내에선 위험해요. 결재·금액·되돌리기 어려운 액션의 마지막 확정 버튼은 항상 사람 이 눌러야 해요. 에이전트는 모아서 올려주는 것 까지, 누르는 건 사람.
8. 테스트 — 세 가지 길
읽기 봇 때처럼 정상 / 막아야 할 / 모호한 세 종류를 다 던져봐야 해요. 쓰기 봇은 특히 “막아야 할” 케이스가 잘 도는지가 품질이에요.
케이스 1 — 정상 신청
나: 다음 주 월~금 연차 신청
봇: 연차 5일(06/29~07/03) 맞으실까요? [확인 카드]
나: (제출)
봇: 신청이 접수됐어요. 신청번호 LV-0000, 현재 상급자 승인 대기 중입니다.
승인되면 잔여 휴가가 8일에서 3일로 조정돼요.
확인 카드 → 플로우 → 승인 대기까지 정상. ✅
케이스 2 — 잔여 부족(막아야 할)
나: 다음 달에 연차 10일 신청할게
봇: 신청하신 10일이 현재 잔여(8일)를 초과해서 접수할 수 없어요.
기간을 조정하시거나, 잔여 관련 문의는 인사팀으로 확인해 주세요.
플로우의 조건 분기(4-3)가 승인 단계로 가기 전에 잘라냈어요. ✅ 쓰기가 일어나기 전에 막는 게 핵심이에요.
케이스 3 — 모호한 입력(되묻기)
나: 휴가 좀 쓸게
봇: 어떤 휴가인가요? (연차·반차·경조 등)
나: 반차
봇: 언제 쓰실 건가요? 오전/오후도 알려주세요.
슬롯이 빌 때 추측하지 않고 되물어요. ✅ 모호한데 멋대로 채워 신청하는 게 제일 위험해요.
✅ 한 가지 더 테스트하세요 — 상급자가 ‘반려’ 를 눌렀을 때. 봇이 “반려되었습니다” 를 사용자에게 제대로 전하고, 잔여가 차감되지 않았는지 확인해야 해요. 승인 실패 경로가 깨끗해야 안심하고 풀어요.
9. 권한·되돌리기·로그
쓰기 액션을 운영에 올리기 전에 이 셋은 꼭 보세요. 읽기 봇보다 훨씬 깐깐하게 봐야 해요.
- 커넥션은 누구 권한으로 도나. 플로우의 인사 시스템 커넥션이 만든 사람 계정 으로 연결돼 있으면, 봇은 그 계정 권한으로 써요. 신청 등록처럼 광범위한 쓰기는 전용 서비스 계정 + 최소 권한 으로 두는 게 안전해요.
- 되돌리기 경로를 미리 만들기. “잘못 승인된 신청을 어떻게 취소하나” 를 봇 만들 때 같이 설계하세요. 차감된 잔여를 복구하는 보상 단계(또는 취소 액션)가 없으면, 사고가 났을 때 손으로 고쳐야 해요.
- 모든 실행에 로그. 누가·언제·무엇을 신청했고 결과가 뭔지(신청번호·승인자·차감 내역) 남기세요. Power Automate 실행 기록 + 신청 레코드 자체가 감사 추적이 돼요.
- 실패 처리. 승인 중간에 시스템이 죽으면? 잔여는 차감됐는데 기록이 안 남으면? 차감과 기록을 한 묶음(가능하면 마지막에 한 번에) 으로 처리해서 어중간한 상태를 줄이세요.
- 그림자 봇 금지. 휴가 신청처럼 민감한 쓰기 봇은 부서마다 따로 만들지 말고 공식 하나 로. 누가 인사 시스템에 쓰는지 통제 불가가 되면 그게 최악이에요.
💡 운영 원칙 한 줄: “읽기는 틀려도 다시 묻지만, 쓰기는 틀리면 치워야 한다.” 그래서 쓰기 봇은 덜 자동화 하는 게 오히려 잘 만든 거예요. 확인·승인·로그를 귀찮을 만큼 깔아두세요.
10. 한 장 요약
| 단계 | 무엇을 | 핵심 한 줄 |
|---|---|---|
| 설계 | 읽기 vs 쓰기 구분 | 되돌리기 어려운 액션은 자동 실행 금지 |
| 방식 | Power Automate 플로우 | 대화는 AI, 실행은 결정적 플로우 |
| 플로우 | 잔여→조건→승인→기록 | 쓰기 전에 잔여로 먼저 자름 |
| 연결 | 액션 설명 다듬기 | 설명이 곧 트리거 |
| 입력 | 슬롯 필링 + 확인 카드 | 빈 값은 되묻고, 제출은 사람이 |
| 승인 | 본인 확인 + 상급자 결재 | 마지막 버튼은 항상 사람 |
| 테스트 | 정상/부족/모호 + 반려 | 막는 경로가 품질 |
| 운영 | 권한·되돌리기·로그 | 덜 자동화한 게 잘 만든 것 |
정리하면, 에이전트에 액션을 붙이는 건 “AI 가 알아듣고, 플로우가 안전하게 실행하고, 사람이 마지막을 확정하는” 분업을 짜는 일이에요. 읽기 봇이 “출처” 로 신뢰를 샀다면, 쓰기 봇은 “확인·승인·로그” 로 신뢰를 사요. 이 세 칸만 제대로 깔면, 봇이 안내를 넘어 진짜 업무를 처리하면서도 사고가 아니라 자산으로 남아요.
이제 노코드 지식 봇(4편) → 액션을 붙인 쓰기 봇(이번 글)까지 왔어요. 다음은 트리거로 스스로 깨어나는 자율 에이전트 — 사람이 부르지 않아도 이벤트·스케줄로 도는 영역이에요.
일단 오늘은 여기까지…..
다음 글에서는 사람이 부르지 않아도 트리거로 스스로 도는 자율 에이전트를 직접 만들어볼게요.
← 이전 글: (4/7) 사내 규정 Q&A 봇 만들기 ｜ 다음 글 →: (6/7) 자율 에이전트 — 메일 분류봇
