AI 에이전트의 핵심 질문은 이제 “답을 잘하느냐”만이 아닙니다. 도구를 호출하고, 데이터를 읽고, 업무 시스템을 실행하는 순간부터 더 중요한 질문이 생깁니다.
이 에이전트가 지금 이 행동을 해도 되는가?
Microsoft가 공개한 Agent Control Specification, ACS는 이 질문을 다루기 위한 오픈소스 표준입니다. 프롬프트에 “하지 마”라고 적어두는 방식이 아니라, 에이전트 실행 과정에서 정책을 평가하고 집행하는 런타임 거버넌스 규격입니다.1
ACS는 에이전트 행동을 정책으로 통제한다
ACS의 핵심은 정책을 에이전트 코드나 프롬프트 안에 묻어두지 않는 데 있습니다. 개발자, 컴플라이언스, 보안 팀이 별도의 정책으로 에이전트의 행동 기준을 정의하고, 실행 중 필요한 지점에서 이를 검사할 수 있게 합니다.
정책이 할 수 있는 일은 명확합니다.
특정 행동을 허용한다
특정 행동을 차단한다
사람의 승인을 요구한다
판단 근거와 실행 증거를 로그로 남긴다
Microsoft에 따르면 ACS는 입력 수신 전, 도구 호출 전, 도구 결과 반환 후, 최종 응답 전 같은 단계에서 정책을 확인할 수 있습니다.1 즉, 에이전트가 “생각한 뒤 실행하는” 전체 흐름 중간에 통제 지점을 넣는 방식입니다.
이 구조의 장점은 실무적으로 큽니다. 보안 규칙이 LangChain 코드, 시스템 프롬프트, 개별 콜백, 내부 문서에 흩어지지 않습니다. 정책 파일로 남고, 리뷰할 수 있으며, 다른 에이전트나 런타임으로 옮기기도 쉬워집니다.
중요한 변화는 “프롬프트 안전장치”에서 “런타임 거버넌스”로의 이동이다
많은 팀이 에이전트 통제를 프롬프트 차원에서 시작합니다. 예를 들어 “개인정보를 출력하지 마라”, “승인 없이 결제하지 마라” 같은 지시를 시스템 프롬프트에 넣습니다. 하지만 프롬프트는 운영 통제의 기준선이 되기 어렵습니다.
프로덕션 환경에서는 더 구체적인 질문이 필요합니다.
어떤 도구 호출은 항상 차단해야 하는가?
어떤 작업은 사람 승인을 받아야 하는가?
어떤 데이터 접근은 감사 로그를 남겨야 하는가?
정책 변경 후 기존 에이전트 동작이 깨지지 않았는가?
여러 프레임워크에서 같은 정책을 적용할 수 있는가?
ACS가 의미 있는 이유는 이 질문들을 프롬프트가 아니라 정책과 런타임의 문제로 다루기 때문입니다. 에이전트를 더 똑똑하게 만드는 기술이라기보다, 에이전트가 실제 시스템에서 행동할 때 필요한 통제 언어에 가깝습니다.
Agent Governance Toolkit은 운영 체계로 확장되고 있다
ACS는 Microsoft Agent Governance Toolkit 흐름 안에 있습니다. Agent Governance Toolkit v4.0.0에서는 45개의 Python 패키지가 5개 배포판으로 통합됐습니다.2 이는 에이전트 거버넌스가 개별 실험 도구를 넘어 운영 패키지 형태로 정리되고 있음을 보여줍니다.
구성도 에이전트 운영에 필요한 영역을 폭넓게 포함합니다.
agent-governance-toolkit-core에는 정책 엔진, capability 모델, 감사, MCP 게이트웨이, ID, 신뢰 점수가 포함됩니다.2 이는 “무엇을 할 수 있는가”, “누가 실행했는가”, “어떤 근거로 허용했는가”를 다루는 기반입니다.
agent-governance-toolkit-runtime에는 권한 링, saga 오케스트레이션, 종료 제어가 포함됩니다.2 단순히 입력과 출력을 필터링하는 수준이 아니라, 실행 권한과 작업 흐름 자체를 통제하려는 방향입니다.
agent-governance-toolkit-sre에는 SLO, 오류 예산, 카오스 엔지니어링, 서킷 브레이커가 포함됩니다.2 이는 에이전트를 일반 소프트웨어 서비스처럼 관찰하고, 장애를 가정하고, 운영 기준을 세우겠다는 접근입니다.
agent-governance-toolkit-cli에는 agt CLI, OWASP 검증, 무결성 검사, 정책 린팅이 포함됩니다.2 정책을 문서로만 두지 않고 개발·검증·배포 과정에 포함시키려는 의도가 보입니다.
적용할 때 봐야 할 기준
ACS를 지금 모든 팀이 즉시 도입해야 한다고 말할 수는 없습니다. 중요한 것은 ACS가 제시하는 운영 패턴입니다. 특히 프로덕션 에이전트를 준비하는 팀이라면 다음 기준으로 현재 구조를 점검할 수 있습니다.
첫째, 정책이 코드와 분리되어 있는가입니다. 도구 호출 제한, 승인 조건, 감사 로그 기준이 코드 곳곳에 흩어져 있다면 변경과 검토가 어려워집니다. ACS의 방향은 이런 규칙을 별도 정책으로 관리하는 것입니다.
둘째, 도구 호출 전후에 통제 지점이 있는가입니다. 에이전트의 위험은 대부분 외부 시스템을 호출할 때 발생합니다. 따라서 모델 응답 자체보다 도구 실행 전, 결과 반환 후, 최종 응답 전의 검사가 중요합니다.
셋째, 승인과 증거 로그를 남길 수 있는가입니다. 차단만으로는 충분하지 않습니다. 어떤 행동은 사람 승인이 필요하고, 어떤 행동은 나중에 검토할 수 있는 근거가 필요합니다.
넷째, 정책을 테스트할 수 있는가입니다. Agent Governance Toolkit v4.0.0에는 정책 회귀 테스트를 위한 AGT test replay engine이 추가됐습니다.2 정책이 운영 규칙이라면, 애플리케이션 코드처럼 테스트되고 회귀 검증되어야 합니다.
정책은 점점 더 시스템 가까이 내려간다
Agent Governance Toolkit v4.0.0에서 눈에 띄는 부분은 wire-protocol 인식 정책 평가입니다. SQL과 Kubernetes에 대해 TypeScript, Rust, Go, .NET에서 제공됩니다.2 이는 정책 평가가 추상적인 “도구 이름” 수준을 넘어, 실제 시스템과 주고받는 프로토콜에 가까워지고 있음을 뜻합니다.
Credential redaction도 C#, Python, TypeScript, Rust 전반에서 확장됐습니다.2 에이전트가 여러 언어와 런타임에서 동작하는 현실을 고려하면, 민감 정보 보호 역시 특정 프레임워크 안에만 머물기 어렵습니다.
이 흐름은 명확합니다. 에이전트 거버넌스는 문서나 권고사항이 아니라, 런타임·테스트·배포 파이프라인의 일부가 되어야 합니다.
결론: ACS는 에이전트 운영의 공통 언어다
ACS의 가치는 에이전트를 더 똑똑하게 만드는 데 있지 않습니다. 에이전트가 실제 업무 시스템에서 행동할 때, 무엇을 허용하고 무엇을 막고 언제 사람에게 넘길지를 일관되게 정의하는 데 있습니다.
따라서 ACS를 볼 때 핵심 질문은 “이 표준을 당장 쓸 것인가”보다 “우리 에이전트의 행동 통제 지점이 명확한가”입니다.
프로덕션 에이전트를 준비하고 있다면 먼저 다음부터 점검하는 것이 현실적입니다.
도구 호출 정책을 코드와 분리할 수 있는가
권한과 승인 조건을 명확히 정의할 수 있는가
실행 증거와 감사 로그를 남길 수 있는가
정책 변경을 테스트하고 회귀 검증할 수 있는가
여러 에이전트 프레임워크에 같은 통제 방식을 적용할 수 있는가
ACS는 이 질문들에 대한 하나의 기준선을 제시합니다. 에이전트가 단순한 챗봇을 넘어 실제 시스템을 움직이기 시작했다면, 이제 필요한 것은 더 긴 프롬프트가 아니라 실행 중 통제 가능한 정책 체계입니다.
참고
1Introducing Agent Control Specification: Portable runtime governance for AI Agents
이 노트는 보도·비평·교육·연구 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.