개발자를 위한 Microsoft AI 에이전트 행동 제어 툴 심층 분석

---
title: "개발자를 위한 Microsoft AI 에이전트 행동 제어 툴 심층 분석: ACS·ASSERT·Agent 365 완전 가이드"
date: 2026-06-08
draft: false
tags:
  - AI 에이전트
  - 마이크로소프트
  - ACS
  - ASSERT
  - Foundry
  - AI 개발
  - 에이전트 거버넌스
categories:
  - ai-coding
description: "Microsoft Build 2026에서 공개된 AI 에이전트 행동 제어 도구 ACS·ASSERT·Agent 365를 심층 분석합니다. 8개 인터셉션 포인트, 크로스 프레임워크 지원, 실제 요금까지 개발자 관점에서 정리했습니다."
cover:
  image: "images/ai-에이전트-개발--마이크로소프트-ai-제어-cover.jpg"
  alt: "개발자를 위한 Microsoft AI 에이전트 행동 제어 툴 심층 분석 커버 이미지"
  caption: "Photo by [AS_Photography](https://pixabay.com/ko/photos/%EB%85%B8%ED%8A%B8%EB%B6%81-%EC%BB%B4%ED%93%A8%ED%84%B0-%EC%B0%BD%EB%AC%B8-%ED%99%94%EB%A9%B4-5603790/) on Pixabay"
---

> ※ 이 글에는 제휴 마케팅 링크가 포함될 수 있으며, 구매 시 수수료를 받을 수 있습니다.

---

AI 에이전트가 스스로 툴을 호출하고 코드를 실행하는 시대, 개발자의 가장 큰 공포는 "에이전트가 내가 원하지 않는 행동을 했을 때 막을 방법이 없다"는 것이다. Microsoft가 Build 2026에서 공개한 **Agent Control Specification(ACS)**과 **ASSERT** 프레임워크, 그리고 엔터프라이즈 사용자를 위한 **Agent 365**는 바로 이 문제를 정면으로 겨냥한다. 이 글에서는 세 도구의 구조·실제 활용 가능성·요금, 그리고 반드시 알아야 할 한계까지 냉정하게 분석한다.

---

## 1. 왜 지금 에이전트 행동 제어가 중요한가

LLM 기반 에이전트는 이제 단순한 챗봇이 아니다. 파일을 삭제하고, API를 호출하고, 데이터베이스에 쓰기 작업을 한다. 기존의 프롬프트 엔지니어링 방식으로는 이런 "사이드 이펙트가 있는 행동"을 런타임에서 제어하기가 사실상 불가능했다. 로그로 사후 분석은 할 수 있지만, **사전에 막는** 메커니즘이 없었다.

Microsoft가 이 공백을 채우기 위해 선택한 접근법은 세 가지다:

1. **ACS(Agent Control Specification)** — 에이전트 실행 루프의 특정 지점에 정책 평가 훅을 삽입하는 런타임 거버넌스 명세
2. **ASSERT** — 텍스트로 작성한 정책을 자동으로 테스트셋으로 변환해 CI/CD에 통합하는 평가 프레임워크
3. **Agent 365** — Microsoft 365 생태계 안에서 에이전트를 생성·배포·모니터링하는 엔터프라이즈 오케스트레이션 플랫폼

ACS와 ASSERT는 MIT 라이선스 오픈소스로 공개되었다. ([출처: Microsoft Foundry 블로그](https://devblogs.microsoft.com/foundry/build-2026-open-trust-stack-ai-agents/))

---

## 2. ACS(Agent Control Specification) 심층 분석

![ACS 8개 인터셉션 포인트의 에이전트 실행 루프 제어 흐름도](/ai-tools-blog/images/ai-에이전트-개발--마이크로소프트-ai-제어-diagram.png)
*ACS 8개 인터셉션 포인트의 에이전트 실행 루프 제어 흐름도*

### 2-1. 8개 인터셉션 포인트란 무엇인가

ACS는 에이전트 실행 루프 안에 총 8개의 인터셉션 포인트를 정의한다. ([출처: Microsoft Command Line](https://commandline.microsoft.com/agent-control-specification-runtime-governance/))

| # | 인터셉션 포인트 | 제어 가능한 내용 |
|---|---|---|
| 1 | **agent startup** | 에이전트 초기화 전 환경 검증, 권한 사전 점검 |
| 2 | **input** | 사용자 입력이 에이전트에 전달되기 전 필터링 |
| 3 | **pre-model-call** | 모델 호출 직전 컨텍스트 검토, 프롬프트 인젝션 탐지 |
| 4 | **post-model-call** | 모델 응답 수신 직후 출력 내용 정책 평가 |
| 5 | **pre-tool-call** | 툴 실행 직전 파라미터 검증, 위험 액션 차단 |
| 6 | **post-tool-call** | 툴 실행 결과를 에이전트에 전달하기 전 필터링 |
| 7 | **output** | 최종 응답이 사용자에게 전달되기 전 검토 |
| 8 | **agent shutdown** | 에이전트 종료 시 감사 로그 기록, 리소스 정리 |

이 구조의 핵심은 **각 지점에서 정책 평가가 비동기적으로 실행**된다는 것이다. 예를 들어 `pre-tool-call` 지점에서 "rm -rf 명령어를 포함한 shell 툴 호출은 모두 차단"이라는 정책을 등록하면, 에이전트가 실제로 해당 명령을 실행하기 전에 인터셉터가 이를 막는다.

### 2-2. 크로스 프레임워크 지원

ACS는 LangChain, OpenAI Agents SDK, Anthropic Agents SDK, AutoGen, CrewAI, Semantic Kernel, MCP 툴 등 주요 에이전트 프레임워크의 플러그인 SDK 형태로 제공된다. ([출처: TechCrunch](https://techcrunch.com/2026/06/02/microsoft-offers-devs-a-better-way-to-control-ai-agent-behavior/)) 이는 Azure 종속 없이 자체 인프라에서도 ACS 정책을 적용할 수 있다는 의미다.

### 2-3. ACS의 한계

ACS는 강력하지만 결정적인 약점이 있다.

**첫째, 레이턴시 오버헤드.** 8개 인터셉션 포인트 각각에서 정책 평가가 실행되므로, 정책이 복잡할수록 에이전트 응답 시간이 늘어난다. Microsoft의 자체 벤치마크에서 정책 평가 1회당 평균 12–40ms의 추가 지연이 측정되었다. 사용자 대기 시간이 중요한 실시간 챗봇 환경에서는 체감 성능 저하가 발생할 수 있다. ([출처: Microsoft Foundry 블로그](https://devblogs.microsoft.com/foundry/build-2026-open-trust-stack-ai-agents/))

**둘째, 정책 언어의 학습 곡선.** ACS 정책은 YAML 기반 DSL(Domain-Specific Language)로 작성된다. "위험한 SQL 쿼리를 막는다"는 직관적 의도를 정확한 DSL 표현으로 변환하는 작업은 생각보다 까다롭다. 잘못 작성된 정책은 정상 동작까지 차단하는 오탐(false positive)을 낳는다.

**셋째, 런타임 평가의 한계.** ACS는 실행 중인 액션을 감시하는 도구지, 에이전트의 **의도**를 사전에 이해하는 도구가 아니다. 정교하게 설계된 멀티스텝 공격(예: 여러 개의 무해해 보이는 툴 호출을 조합한 데이터 유출)은 단일 인터셉션 포인트 기반 정책으로 탐지하기 어렵다.

---

## 3. ASSERT 프레임워크: 정책을 자동 테스트로 변환

### 3-1. ASSERT란 무엇인가

ASSERT(Agent Safety Specification Evaluation and Regression Testing)는 개발자가 자연어로 작성한 에이전트 행동 정책을 **자동으로 테스트 케이스로 변환**해 CI/CD 파이프라인에 통합하는 평가 프레임워크다. ([출처: Microsoft Foundry 블로그](https://devblogs.microsoft.com/foundry/build-2026-open-trust-stack-ai-agents/))

핵심 아이디어는 단순하다. 기존에는 "이 에이전트가 개인정보를 외부로 유출하지 않는다"는 요구사항을 검증하려면 개발자가 수동으로 테스트 시나리오를 설계해야 했다. ASSERT는 이 과정을 자동화한다.

### 3-2. 실제 동작 방식: 3단계 워크플로

**Step 1 — 정책 작성 (Policy Spec)**

```yaml
# assert-policy.yaml
agent: customer-support-bot
policies:
  - id: no-pii-leak
    description: "에이전트는 사용자의 이름·이메일·전화번호를 시스템 외부 툴에 전달하지 않는다"
    severity: critical
  - id: no-competitor-mention
    description: "에이전트는 경쟁사 제품명을 직접 추천하지 않는다"
    severity: warning

# .github/workflows/agent-safety.yml
- name: Run ASSERT safety tests
  run: assert run --tests tests/ --agent-endpoint ${{ secrets.AGENT_URL }}
  env:
    ASSERT_API_KEY: ${{ secrets.ASSERT_API_KEY }}