Copilot Studio 다중 에이전트와 Power Automate, SharePoint/Teams를 연동해 “요청→검토→승인→집행” 결재 흐름을 자동화하는 실전 설계·보안·운영 체크포인트를 한 번에 정리했다.
- 오늘의 AI 기술 인사이트 핵심 포인트 3가지: “결재 자동화”는 챗봇이 아니라 다중 에이전트 분업(접수/검증/정책/감사)으로 안정성이 올라간다
- Copilot Studio는 커넥터(Connector)·Power Automate·Graph 조합으로 M365 승인/결재를 끝단까지 연결하되, 권한 위임(Delegated)과 감사 로그 설계가 성패를 가른다
- 현업 확산을 막는 요인은 모델 성능이 아니라 정책(금액 한도/예외)·데이터(증빙)·운영(재시도/에러 핸들링)이며, 이를 표준 템플릿으로 해결할 수 있다
매일 엑셀과 메일함을 오가며 승인 요청을 취합하던 실무자 A씨의 하루는 대개 비슷하다. 팀원들이 Teams로 “이거 결재 좀요”라고 던진 메시지, 메일로 날아온 PDF 견적서, SharePoint 폴더에 올라온 증빙, 그리고 결재권자의 “지금 회의 중” 한 마디가 겹치면서 요청은 누락되고 마감은 다가온다. 결국 A씨는 퇴근 직전 다시 한 번 결재 현황을 수기로 업데이트하고, 누락된 항목을 찾아 재촉 메시지를 보낸다.
AI 서비스 도입을 고민하는 기획자 B씨는 여기서 한 단계 더 복잡한 문제를 본다. “승인 속도”만이 아니라, 누가 어떤 기준으로 승인했는지, 예외는 어떻게 처리되는지, 감사 시점에 어떤 근거를 남길 수 있는지가 핵심이다. 단순히 챗봇이 신청서를 받아주는 정도로는 결재 프로세스가 바뀌지 않는다. 2026년의 Copilot Studio가 주목받는 이유는, 단일 봇이 만능으로 처리하는 방식이 아니라 다중 에이전트가 역할을 나눠 승인·결재를 ‘업무 시스템’ 수준으로 연결할 수 있기 때문이다.
왜 “다중 에이전트”가 결재 자동화에 유리한가
인공지능 인사이트 에디토리얼 팀의 분석 결과, 승인·결재는 대화형 인터페이스보다 “정책과 기록”의 비중이 훨씬 크다. 단일 에이전트에게 접수, 증빙 검증, 결재 규정 판단, 결재권자 라우팅, 사후 감사 로그까지 맡기면 다음 문제가 반복된다.
- 정책 변경(금액 한도, 예외 규정) 때마다 프롬프트/흐름이 뒤엉켜 유지보수 비용이 증가
- 에러 발생 시 원인(데이터 누락인지, 권한 문제인지, 규정 위반인지) 추적이 어려움
- 감사 대응에 필요한 “근거”를 대화 로그로만 남겨 재현성이 떨어짐
다중 에이전트 접근은 이를 기능적으로 쪼개 해결한다. 예를 들어 아래처럼 분업한다.
- 접수 에이전트: Teams/Outlook/Forms에서 신청을 표준 스키마로 수집
- 검증 에이전트: 증빙(견적서, 계약서, 발주서) 존재 여부/필수 필드/중복 신청 검사
- 정책(Policy) 에이전트: 금액, 비용 항목, 프로젝트 코드에 따라 결재 라인 결정
- 승인 오케스트레이터: Power Automate 승인 커넥터 및 Approvals/Teams로 결재 실행
- 감사(Audit) 에이전트: SharePoint/Dataverse에 근거와 타임라인을 구조화 저장
💡 인공지능 인사이드 팁: 결재 자동화의 “정확도”는 LLM 추론보다 입력 스키마 표준화에서 크게 좌우된다. 먼저 신청 데이터를 JSON 스키마(예: 금액, 비용항목, 프로젝트, 첨부, 긴급도, 요청 사유)로 고정하고, 에이전트는 스키마를 채우는 역할로 제한하면 운영 난이도가 급감한다.
전체 구성도: Copilot Studio + Power Automate + M365(Teams/SharePoint/Outlook) + 감사 저장소
가장 구현이 쉬우면서도 확장성이 높은 표준 패턴은 “Copilot Studio가 대화/오케스트레이션, Power Automate가 워크플로 실행, SharePoint/Dataverse가 기록과 상태 저장”이다.
- 프론트: Teams 내 Copilot(또는 Copilot Studio로 배포한 에이전트)
- 워크플로: Power Automate(Approvals, Outlook, SharePoint, Excel, Dataverse, HTTP)
- 데이터: SharePoint List(경량) 또는 Dataverse(거버넌스/관계형/권한 세분화)
- 승인: Approvals(Teams) + 메일 알림 + 대체 승인(Delegate) 정책
- 감사: 승인 이벤트 타임라인, 원문 첨부 링크, 정책 판정 결과(버전 포함)
최신 공식 문서에 따르면 Copilot Studio는 커넥터와 액션(Action)을 통해 외부 시스템 호출을 표준화할 수 있고, Power Platform 전반(특히 Power Automate, Dataverse)과 자연스럽게 통합된다.
🔗 Microsoft Copilot Studio 공식 문서 바로가기
구축 시나리오: “지출 품의” 승인·결재를 예로 든 E2E 흐름
현장에서 가장 수요가 많은 시나리오는 “지출 품의/구매 요청”이다. 프로세스를 단계로 쪼개면, 다중 에이전트가 어디에 붙어야 하는지 명확해진다.
1) 접수: Teams에서 자연어로 요청 → 표준 신청서로 변환
A씨는 Teams에서 “노트북 3대 구매 결재 올릴게요. 총 540만원, 견적서 첨부했고 프로젝트는 MKT-2026입니다”라고 입력한다. 접수 에이전트는 다음을 수행한다.
- 필수 필드 누락 여부 확인(금액, 항목, 프로젝트, 첨부)
- 증빙 파일을 SharePoint 문서 라이브러리에 저장하고 링크 생성
- 요청을 SharePoint List/Dataverse에 상태=Submitted로 기록
이 단계에서 중요한 건 “대화 로그”가 아니라, 이후 워크플로가 읽을 수 있는 “정형 데이터”다.
2) 검증: 중복 신청/예산 코드/증빙 적정성 체크
검증 에이전트는 규칙 기반 검사를 우선 적용한다. 예를 들어 지난 30일 내 동일 공급사+동일 품목+유사 금액 요청이 있는지, 첨부가 PDF/이미지인지, 프로젝트 코드가 사전에 등록된 값인지 확인한다. 모호한 항목만 LLM 판독(예: 견적서에서 공급사/금액/유효기간 추출)로 보강한다.
3) 정책 판정: 금액/항목/부서 기준으로 결재 라인 자동 생성
정책 에이전트는 “규정 테이블”을 기준으로 결재 라인을 만든다. 예시는 다음과 같다.
- 100만원 이하: 팀장
- 100~500만원: 팀장 → 본부장
- 500만원 초과 또는 IT자산: 팀장 → 본부장 → 재무 → IT구매
이 규정은 프롬프트에 박아넣기보다 SharePoint/Dataverse의 정책 테이블로 관리하는 편이 변경 대응에 유리하다.
4) 승인 실행: Power Automate Approvals로 결재 요청/리마인더/대체 승인
승인 오케스트레이터는 Power Automate의 승인 액션을 사용해 결재를 생성하고, Teams Approvals 또는 Outlook으로 승인 요청을 보낸다. 여기에 운영 필수 기능을 더한다.
- 리마인더: 24시간 미응답 시 자동 리마인드
- SLA 에스컬레이션: 48시간 초과 시 상위 결재권자 또는 대체자에게 라우팅
- 조건부 분기: 반려 시 사유 수집 후 요청자에게 재제출 링크 제공
5) 집행/후속: 승인 완료 후 구매/발주 시스템 연계(선택)
승인 완료로 끝내지 않고, 실제 발주/구매 요청(ERP, 구매 포털)까지 자동화하려면 커넥터 또는 HTTP 호출이 필요하다. 이 구간은 조직 보안 정책 영향이 커서 단계적으로 도입하는 것이 일반적이다.
6) 감사 로그: “누가/언제/무엇을 근거로”를 구조화해 저장
감사 에이전트는 아래를 한 번에 저장한다.
- 요청 원문(정형 데이터)과 첨부 링크
- 정책 판정 결과(규정 버전, 적용 규칙, 예외 여부)
- 승인 이벤트 타임라인(요청/열람/승인/반려/에스컬레이션)
💡 인공지능 인사이드 팁: 감사 대응을 위해 “대화 로그”만 저장하면 재현이 어렵다. 정책 판정 결과를 ‘규정 버전’과 함께 저장해두면, 추후 규정이 바뀌어도 당시 승인 근거를 정확히 설명할 수 있다.
Copilot Studio 다중 에이전트 연동: 구현 패턴 3가지
Copilot Studio에서 “다중 에이전트”를 구성하는 실무 패턴은 크게 3가지로 정리된다. 조직의 라이선스/보안/운영 성숙도에 따라 선택이 갈린다.
패턴 A: 에이전트(대화) + Power Automate(액션) 중심(가장 일반적)
- Copilot Studio: 대화, 슬롯 채우기, 사용자 확인, 예외 처리
- Power Automate: 승인 생성, SharePoint/Dataverse CRUD, 알림, 스케줄 리마인드
장점은 구현 속도와 유지보수성이다. 단점은 복잡한 정책 엔진을 순수 플로우로 만들면 난이도가 올라간다는 점이다.
패턴 B: 정책 에이전트를 별도 서비스(함수/컨테이너)로 분리
- 정책 판정(결재 라인/예외)은 Azure Functions/Container Apps 등으로 분리
- Copilot Studio/Power Automate는 API 호출로 정책 결과만 사용
규정이 복잡하거나 여러 프로세스(지출/휴가/채용)에서 정책을 재사용해야 한다면 유리하다.
패턴 C: Graph 중심으로 M365 리소스(메일/캘린더/파일)까지 깊게 연동
Teams/Outlook/SharePoint 권한과 사용자 컨텍스트를 정교하게 다루려면 Microsoft Graph 설계가 중요해진다. 다만 Graph 연동은 보안 검토(권한 범위, 관리자 동의)가 필수다.
업무 효율 비교: 기존 방식 vs 다중 에이전트 결재 자동화
| 항목 | 기존 수기/메일 기반 | Copilot Studio 다중 에이전트 + M365 | 현업 체감 포인트 |
|---|---|---|---|
| 요청 접수 | 양식 제각각(메일/메신저/엑셀) | 대화 입력 → 표준 스키마 자동 변환 | 누락/재요청 감소 |
| 증빙 확인 | 담당자 눈으로 수동 체크 | 필수 첨부/필드 검증 + 문서에서 핵심값 추출 | 초기 반려율 감소 |
| 결재 라인 결정 | 규정 문서 찾아 수동 지정 | 정책 테이블 기반 자동 라우팅 | 규정 준수 일관성 |
| 리마인드/에스컬레이션 | 담당자가 수동 재촉 | SLA 타이머 기반 자동 리마인드/대체 승인 | 병목 제거 |
| 감사 로그 | 메일/캡처/파일 흩어짐 | 결재 타임라인 + 근거 구조화 저장 | 감사 대응 시간 단축 |
보안·권한 설계: “에이전트가 할 수 있는 일”을 엄격히 제한해야 한다
승인·결재 자동화는 곧 “권한” 자동화다. 최신 공식 권고와 현업 사고 사례를 종합하면, 아래 4가지를 놓치면 운영 단계에서 제동이 걸린다.
1) 사용자 컨텍스트(Delegated) vs 서비스 계정(Application) 구분
요청자의 파일 접근, 팀/채널 접근, 메일 발송 등은 사용자 컨텍스트가 자연스럽지만, 야간 리마인드나 상태 집계처럼 배치성 작업은 서비스 계정이 편할 수 있다. 다만 서비스 계정은 과권한이 되기 쉬우므로 범위를 최소화해야 한다.
2) SharePoint/Dataverse 권한 모델
- 요청자는 본인 요청만 조회 가능
- 결재자는 자신에게 할당된 건만 조회 가능
- 감사/재무는 전체 조회 가능(읽기 전용)
특히 SharePoint List를 사용할 때 항목 수준 권한(item-level permissions)을 무리하게 쓰면 성능/운영 이슈가 생길 수 있어, 규모가 커지면 Dataverse로 옮기는 전략이 자주 선택된다.
3) 프롬프트/툴 호출 감사 가능성
승인·결재는 “왜 그 결론이 나왔는지”가 중요하다. 정책 에이전트가 사용한 규칙/버전/입력값을 저장하고, 누가 어떤 요청을 어떤 권한으로 실행했는지(런 컨텍스트)를 함께 남겨야 한다.
4) 데이터 유출 방지(DLP)와 커넥터 통제
Power Platform DLP 정책으로 “업무 데이터가 개인용 커넥터로 새는 경로”를 원천 차단해야 한다. 이는 기술 난이도보다 거버넌스 합의가 관건이다.
🔗 Power Platform DLP 정책 공식 문서 바로가기
실전 연동 절차: “다중 에이전트 + 승인 플로우”를 가장 빠르게 만드는 순서
현업에서 실패를 줄이는 구축 순서는 기능 나열이 아니라 “운영 가능한 최소 단위”부터 만드는 것이다.
Step 1. 결재 스키마(표준 필드)부터 확정
- 요청 유형(지출/구매/계약/휴가 등)
- 금액, 비용 항목, 프로젝트/코스트센터
- 증빙(필수/선택), 공급사, 납기
- 긴급도, 사유, 비고
이 스키마가 확정되면, 접수 에이전트는 “질문을 잘하는 봇”이 아니라 “필드를 채우는 인터페이스”로 안정화된다.
Step 2. 정책 테이블(결재 라우팅 규정)을 데이터로 분리
SharePoint List 또는 Dataverse에 규정을 테이블로 만든다. 최소 필드는 다음이 권장된다.
- 조건: 금액 구간, 항목, 부서, 프로젝트 유형
- 결재 라인: 순서/역할/사용자(또는 그룹)
- 예외: 특정 공급사/특정 항목 가중 규정
- 버전/적용일: 감사 재현성 확보
Step 3. Power Automate로 “승인 1건”이 끝까지 도는 골격을 먼저 완성
대부분의 프로젝트는 여기서 성패가 갈린다. Copilot Studio가 아무리 잘 대화해도, 승인 생성/상태 업데이트/리마인드/반려 재제출이 한 번에 닫히지 않으면 현업은 다시 메일로 돌아간다.
Step 4. Copilot Studio에서 다중 에이전트 분업을 적용
골격 플로우가 완성되면, 그다음이 다중 에이전트의 시간이다.
- 접수 에이전트: 스키마 채우기 + 첨부 수집
- 검증 에이전트: 규칙 검사 + 누락 시 재질문
- 정책 에이전트: 정책 테이블 조회 + 결재 라인 산출
- 승인 오케스트레이터: 플로우 호출 + 상태 질의
- 감사 에이전트: 결과 요약 + 타임라인 저장
Step 5. 운영 기능(재시도, 장애 알림, 수동 처리 백도어)을 넣고 나서 확산
자동화는 “실패했을 때”가 더 중요하다. 다음을 체크리스트로 고정하는 편이 좋다.
- 외부 커넥터 실패 시 재시도 정책(지수 백오프)
- 승인자가 퇴사/휴직/조직 변경 시 대체자 자동 매핑
- 첨부 파일 권한 문제 발생 시 자동 복구(재공유/재업로드 유도)
- 운영자용 수동 처리 화면(예: Dataverse 앱/SharePoint 뷰)
라이선스·비용 관점: “결재 자동화”에 숨은 과금 포인트
승인·결재 자동화는 대개 Teams 안에서 돌아가므로 “추가 비용이 없을 것”이라 기대하지만, 실제로는 다음 요소에서 비용이 갈린다.
- Copilot Studio 사용량/기능(에이전트 배포, 커넥터 사용 범위)
- Power Automate의 프리미엄 커넥터/실행량
- Dataverse 사용 여부(환경, 용량, 보안 모델)
- 외부 시스템(ERP/구매포털) 연동을 위한 API 게이트웨이/함수 비용
| 옵션 | 권장 대상 | 장점 | 주의할 비용/제약 |
|---|---|---|---|
| SharePoint List + 표준 커넥터 중심 | 부서 단위, 프로세스 단순 | 도입 빠름, M365 친화적 | 권한 세분화/감사 고도화에 한계 |
| Dataverse + 거버넌스 강화 | 전사 확산, 감사/권한 중요 | 관계형 모델, 역할 기반 보안 용이 | 운영/라이선스 구조 검토 필요 |
| 정책 엔진 외부화(Azure Functions 등) | 규정 복잡, 다프로세스 재사용 | 정책 변경 배포/테스트 체계화 | 개발/DevOps 비용 증가 |
아웃바운드 링크: 공식 자료로 검증 가능한 레퍼런스
🔗 Microsoft Copilot Studio 공식 문서
현업 적용에서 자주 터지는 실패 패턴 7가지(그리고 회피법)
- 정책이 문서에만 있고 데이터화되지 않음: 규정 테이블을 먼저 만들고, 예외는 “예외 테이블”로 분리
- 첨부 파일 권한 문제: 업로드 위치를 단일 문서 라이브러리로 통일하고, 링크는 “항목 기반”으로 관리
- 결재권자 부재: 대체자(Delegate) 매핑과 SLA 에스컬레이션을 필수 기능으로 포함
- 승인 완료 후 후속 작업이 수동: 최소한 회계/구매 담당자에게 자동 태스크 생성까지 연결
- 감사 로그가 대화 텍스트뿐: 구조화 로그(정책 버전/입력/결정/타임라인)를 별도로 저장
- 과도한 ‘AI 추론’ 의존: 검증은 규칙 우선, LLM은 문서 추출/요약 보조에 한정
- 운영자 화면 부재: 예외 처리용 운영 뷰(필터, 재시도 버튼, 상태 수정 권한)를 제공
내부 링크(연관 글)
결재 자동화 고도화 로드맵: 2주 MVP → 6주 전사 확산
인공지능 인사이트 에디토리얼 팀이 실제 조직 확산 패턴을 분석하면, 가장 현실적인 일정은 다음처럼 “작게 닫고, 그다음 표준화”다.
2주 MVP(부서 단위)
- 요청 스키마 확정
- SharePoint List 기반 상태 관리
- Power Automate 승인 플로우(반려/재제출 포함)
- Teams에서 요청/상태 조회
6주 확산(전사/감사 대응)
- 정책 테이블 버전 관리 + 예외 테이블
- Dataverse 전환 또는 감사 저장소 강화
- 대체 승인/조직도 연동(그룹 기반 라우팅)
- 운영 대시보드(병목, SLA 위반, 반려 사유 Top)
- 외부 시스템(ERP/구매포털) 단계적 연동
이 로드맵을 따르면 “AI를 붙였는데도 일이 줄지 않는다”는 흔한 실패를 피할 수 있다. 결재 자동화의 목표는 대화를 더 자연스럽게 만드는 것이 아니라, 누락을 줄이고, 규정을 일관되게 적용하며, 감사 가능한 기록을 남기는 것이기 때문이다.
