에이전트가 메일을 보내기 전에 사람이 승인합니다: Copilot Studio의 도구 호출 승인 게이트
에이전트에 실제 업무를 맡기려 할 때 가장 먼저 걸리는 질문이 있습니다. “잘못 실행하면 어쩌죠?”
메일을 고객에게 보내거나, 지원 티켓을 종료하거나, 결제를 처리하는 작업은 되돌리기 어렵습니다. 그래서 많은 조직이 에이전트를 조회 전용으로만 쓰고 있죠. 지시문에 “중요한 작업은 먼저 확인하라”고 써 둘 수는 있지만, 그건 지시일 뿐 보장이 아닙니다.
메시지 센터 공지 RM570434로 안내된 Enabling makers to require human approval for tool calls는 이 문제에 결정론적(deterministic) 장치를 제공합니다.
무엇이 달라지나요
Microsoft가 공지에서 밝힌 내용입니다.
Copilot Studio에서 이제 메이커가 에이전트가 특정 도구를 실행하기 전에 사람의 승인을 요구할 수 있습니다. 도구별·에이전트별 토글(per-tool, per-agent toggle) 로 설정하며, 게이트에 걸린 도구 호출은 일시 중지되고 에이전트가 무엇을 하려는지 설명하는 승인 요청을 표시합니다. 그러면 사람이 승인, 세션 동안 승인, 거부 중 하나를 선택한 뒤에야 작업이 실행됩니다.
승인 흐름
- 에이전트가 게이트가 걸린 도구를 호출하려 함
- 호출이 일시 중지됨
- 에이전트의 의도를 설명하는 승인 요청이 표시됨
- 사람이 선택:
- 승인(approve) — 이번 호출만 허용
- 세션 동안 승인(approve for the session) — 해당 세션 내 반복 승인 생략
- 거부(deny) — 실행하지 않음
- 승인된 경우에만 작업 실행
어디에 표시되나
승인 요청은 에이전트가 배포된 채널 안에 인라인으로 표시됩니다. Microsoft Teams와 Microsoft 365 Copilot을 포함합니다.
별도 관리 화면으로 가는 것이 아니라 대화가 벌어지는 그 자리에서 승인이 이뤄진다는 점이 중요합니다. 승인 절차가 업무 흐름을 끊지 않습니다.
핵심은 “지시문과 무관하게” 동작한다는 것
공지에서 가장 눈여겨볼 표현이 이 부분입니다.
…에이전트의 지시문과 독립적으로(independent of the agent’s instructions) 고위험이나 민감한 작업에 결정론적 가드레일을 제공합니다.
이 문장이 왜 중요한지 짚어 볼 필요가 있습니다.
| 방식 | 성격 | 보장 수준 |
|---|---|---|
| 지시문에 “확인하고 실행하라” 명시 | 모델이 따르기를 기대 | 확률적 |
| 도구별 승인 토글 | 시스템이 강제 | 결정론적 |
지시문 기반 제어는 모델이 그 지시를 어떻게 해석하느냐에 달려 있습니다. 프롬프트 인젝션이나 예외 상황에서 우회될 여지도 있죠. 토글은 그 층 아래에서 동작합니다. 에이전트가 무엇을 지시받았든, 게이트가 걸린 도구는 승인 없이 실행되지 않습니다.
어떤 작업에 걸어야 하나
공지가 예로 든 고위험·민감 작업입니다.
- 메일 발송(sending emails)
- 티켓 종료(closing tickets)
- 결제 처리(processing payments)
여기에 국내 업무 환경을 대입해 보면 이런 것들이 후보가 됩니다.
- 외부 발송 — 고객·거래처에 나가는 메일, 메시지
- 상태 변경 — 주문 취소, 계약 상태 변경, 승인 처리
- 금전 관련 — 환불, 정산, 지출 등록
- 삭제·종료 — 레코드 삭제, 계정 비활성화, 티켓 클로즈
- 대외 게시 — 공지 게시, SNS 발행
기준을 하나로 정리하면 이렇습니다. 되돌리기 어렵거나, 조직 밖으로 나가거나, 금전이 얽힌 작업.
활용 시나리오 예시
시나리오 1 — 고객 응대 에이전트 에이전트가 문의 내용을 분석하고 답변 초안까지 만들지만, 메일 발송 도구에는 승인 게이트를 걸어 둡니다. 담당자가 Teams에서 내용을 확인하고 승인해야 발송됩니다.
시나리오 2 — IT 지원 자동화 티켓 조회·분류는 자동으로 처리하되, 티켓 종료는 승인을 거칩니다. 잘못 닫힌 티켓으로 인한 재문의를 막습니다.
시나리오 3 — 세션 단위 승인 활용 같은 유형의 작업을 연달아 처리할 때는 “세션 동안 승인” 을 선택해 매번 확인하는 번거로움을 줄입니다.
일정
| 구분 | 시점 |
|---|---|
| 정식 출시(GA) | 2026년 9월 |
2026년 9월 정식 출시로 임박한 일정입니다.
메이커·도입 담당자를 위한 체크포인트
- 게이트 대상 도구 목록을 먼저 정하세요: 도구별·에이전트별 토글이므로 어떤 도구에 게이트를 걸지 조직 기준이 필요합니다. “되돌릴 수 없는 작업”을 기준으로 목록을 만들어 두면 에이전트마다 판단할 필요가 없습니다.
- 승인자 지정과 응답 시간: 승인 요청이 채널에 인라인으로 뜨는데, 누가 승인할 것인지와 승인이 늦어지면 어떻게 되는지를 운영 관점에서 정리해야 합니다. 승인 대기가 병목이 되면 자동화 효과가 반감됩니다.
- “세션 동안 승인”의 범위 확인: 편리하지만 한 번 선택하면 세션 내 같은 도구 호출이 통과합니다. 어떤 도구는 매번 승인을 받아야 하는지 구분해 두세요.
- 지시문 기반 통제와 병행: 승인 토글은 최후 방어선입니다. 지시문에서도 신중히 동작하도록 설계하고, 토글은 그것이 실패했을 때의 안전장치로 두는 것이 좋습니다.
- 감사 관점 활용: 승인 요청과 결과가 남는다면 누가 무엇을 승인했는지가 기록됩니다. 감사 대응이 필요한 조직이라면 이 이력을 어떻게 보존·조회할지 확인하세요.
- 채널별 동작 확인: Teams와 Microsoft 365 Copilot에서 인라인 표시가 명시되어 있습니다. 다른 채널에 배포한 에이전트의 동작은 별도 확인이 필요합니다.
- 사용자 안내: 승인 요청이 뜨는 것을 오류로 오해하지 않도록, 왜 승인이 필요한지를 사용자에게 미리 알려 두세요.
마무리
에이전트를 실무에 투입하는 데 있어 가장 큰 장벽은 성능이 아니라 신뢰였습니다. “잘 하겠지”라는 기대만으로는 결제나 대외 발송을 맡기기 어렵죠.
이번 기능은 그 신뢰 문제를 기대가 아니라 구조로 해결합니다. 지시문이 어떻든, 모델이 무엇을 판단했든, 게이트가 걸린 도구는 사람의 확인 없이 실행되지 않습니다. 그러면서도 승인은 대화 흐름 안에서 이뤄지니 자동화의 이점도 크게 훼손되지 않습니다.
조회만 하던 에이전트를 실행까지 시키는 단계로 넘어가려는 조직에게 실질적인 전환점이 될 기능입니다. 정식 출시는 2026년 9월 예정입니다.
출처
- 원문 ID: RM570434 — Microsoft Copilot Studio: Enabling makers to require human approval for tool calls
- 메시지 센터: https://mc.merill.net/message/RM570434
- Microsoft 365 로드맵: https://www.microsoft.com/microsoft-365/roadmap
실제 출시 일정·기능은 변경될 수 있습니다.