AI 툴 카니 2026.06.03 AI 보조 작성·편집자 검수

카니 · AI 보조 작성, 편집자 검수

AI 에이전트가 사고 치기 직전, Microsoft가 꺼낸 통제 표준

AI 에이전트가 사고 치기 직전, Microsoft가 꺼낸 통제 표준

핵심 요약

AI 에이전트가 사고 치는 순간은 답변을 쓸 때가 아닙니다. 진짜 위험한 순간은 도구를 실행하기 직전입니다.

메일을 보낼지, DB를 조회할지, 파일을 삭제할지, 고객 환불 API를 호출할지 결정하는 그 짧은 지점에서 에이전트는 단순 챗봇이 아니라 업무 시스템의 행위자가 됩니다. 그래서 기업이 지금 물어야 할 질문은 “어떤 모델이 더 똑똑한가”가 아니라 “이 에이전트가 무엇을 하기 전에 누가, 어떤 규칙으로, 어떻게 멈출 수 있는가”입니다.

Microsoft는 2026년 6월 2일 Build 2026 흐름에서 Agent Control Specification, 줄여서 ACS와 ASSERT를 공개했습니다. ACS는 에이전트 실행 루프 안의 개입점을 표준화해 정책을 적용하는 런타임 통제 레이어입니다. ASSERT는 자연어로 적힌 제품 요구사항과 정책을 실행 가능한 평가 세트로 바꾸는 오픈소스 평가 프레임워크입니다.

둘을 같이 봐야 의미가 분명해집니다. ASSERT는 “우리 에이전트가 어디서 정책을 어기는지” 찾아내고, ACS는 “그 지점에서 실제로 막거나 승인 요청을 걸 수 있는 방법”을 제공합니다. 즉 평가와 통제를 한 바퀴로 묶는 시도입니다.

Microsoft Command Line 공식 ACS 글의 가드레일 이미지. 프롬프트, 커스텀 코드, 분산된 검사를 하나의 통제 표준으로 묶어야 한다는 문제를 보여준다

이미지 출처: Microsoft Command Line, “Introducing Agent Control Specification: Portable runtime governance for AI Agents”. 본문 첫 이미지이며 카드 썸네일로도 사용 가능하다.

무슨 일이 있었나

Microsoft Foundry 블로그는 Build 2026에서 신뢰 가능한 에이전트를 위한 오픈 스택으로 ASSERT와 Agent Control Specification을 소개했습니다. ASSERT의 정식 이름은 Adaptive Spec-driven Scoring for Evaluation and Regression Testing입니다. 요구사항 중심 평가와 회귀 테스트를 에이전트에 적용하겠다는 이름입니다.

ACS는 Microsoft의 Agent Governance Toolkit 안에 들어간 새 모듈입니다. 공식 글은 ACS를 특정 프레임워크나 런타임, 정책 엔진에 묶이지 않는 런타임 거버넌스 표준이라고 설명합니다. LangChain, AutoGen, CrewAI, Microsoft Agent Framework 같은 하네스와 프레임워크가 제각각 다른 훅을 쓰더라도, 정책을 쓰고 검증하는 표면을 공통화하겠다는 방향입니다.

핵심은 “프롬프트로 부탁하기”에서 “실행 코드로 강제하기”로 옮기는 것입니다. 시스템 프롬프트에 “외부 이메일을 보내지 마라”라고 쓰는 것과, 실제 send_email 도구 호출 직전에 수신자 도메인을 검사하고 차단하는 것은 다릅니다. 전자는 모델이 지켜주길 기대하는 방식이고, 후자는 하네스가 실행 전에 막는 방식입니다.

사람들이 실제로 겪는 문제

에이전트 도입 현장에서 가장 흔한 실패는 모델 답변 품질보다 권한 경계에서 나옵니다. 고객지원 에이전트가 환불 정책을 잘 설명하는 것과 실제 환불 처리를 실행하는 것은 다른 문제입니다. 코딩 에이전트가 패치를 제안하는 것과 CI, 배포, 시크릿이 있는 터미널을 만지는 것도 다른 문제입니다.

기존 방식은 대개 세 갈래로 흩어져 있었습니다. 하나는 시스템 프롬프트입니다. “민감 정보를 유출하지 말라”, “삭제 작업은 하지 말라” 같은 규칙을 모델에게 적어주는 방식입니다. 둘째는 애플리케이션 코드 안에 박힌 커스텀 검사입니다. 셋째는 입력·출력 분류기나 DLP 필터입니다.

이 방식들은 각각 쓸모가 있지만 운영 규모가 커지면 문제가 생깁니다. 정책이 프롬프트, 코드, 콜백, 보안 도구, 로그 시스템에 흩어집니다. 보안팀은 “어떤 규칙이 실제로 적용되고 있는가”를 한 곳에서 감사하기 어렵습니다. 개발팀은 프레임워크를 바꿀 때 같은 정책을 다시 구현해야 합니다. 운영팀은 사고가 난 뒤에야 도구 호출 로그를 뒤집니다.

최근 우리가 다룬 AI 에이전트 용어 정리 글에서도 핵심은 같았습니다. 모델은 두뇌에 가깝고, 하네스는 모델을 실제 업무 시스템에 연결해 움직이는 실행 장치입니다. 위험한 행동은 모델 단독이 아니라 하네스와 도구 권한이 만나는 곳에서 발생합니다.

ACS는 어디서 멈추게 하나

Microsoft의 Foundry 정리 글은 ACS가 입력, LLM, 상태, 도구 실행, 출력이라는 5개 범주에서 통제를 배치한다고 설명합니다. 더 상세한 Command Line 글은 이를 8개 개입점으로 풀어 씁니다. agent_startup, input, pre_model_call, post_model_call, pre_tool_call, post_tool_call, output, agent_shutdown입니다.

이 중 실무에서 가장 먼저 봐야 할 지점은 pre_tool_call입니다. 모델이 “이 도구를 이 인자로 호출하겠다”고 낸 순간, 아직 실제 시스템에는 손대지 않았습니다. 이때 정책 엔진은 도구 이름, 인자, 사용자 권한, 이전 대화에서 본 데이터 민감도, 승인 상태, 도구의 보안 라벨을 함께 보고 allow, warn, deny, escalate 같은 결정을 내릴 수 있습니다.

Microsoft Command Line 공식 ACS 런타임 플로우 이미지. 에이전트 실행 중 개입점에서 정책과 증거 수집을 거쳐 verdict가 반환되는 흐름을 보여준다

이미지 출처: Microsoft Command Line, Agent Control Specification 공식 글.

예를 들어 사내 이메일 에이전트를 생각해 보겠습니다. 사용자가 “방금 정리한 회의록을 고객사에도 보내줘”라고 요청했습니다. 모델은 send_email 도구를 호출하려고 합니다. 이때 ACS가 붙은 하네스는 수신자가 외부 도메인인지, 본문에 내부 전용 라벨이 붙은 문서 내용이 포함됐는지, 이 사용자가 외부 발송 승인을 받았는지 확인할 수 있습니다. 정책에 걸리면 발송을 막거나, 보안팀 승인으로 넘기거나, 민감 문구를 제거한 뒤 다시 시도하게 만들 수 있습니다.

간단히 표현하면 이런 정책 흐름입니다.

agent_control_specification_version: "0.3.1-beta"
metadata:
  name: "customer-email-agent"
policies:
  external_email_policy:
    type: rego
    bundle: ./policy
    query: data.email_agent.verdict
intervention_points:
  pre_tool_call:
    policy_target: "$.tool_call.args"
    policy_target_kind: tool_args
    tool_name_from: "$.tool_call.name"
tools:
  send_email:
    id: send_email
    clearance: internal

중요한 것은 YAML 문법 자체가 아닙니다. 정책이 하네스 바깥의 문서나 프롬프트에만 있는 것이 아니라, 실행 직전에 검사되는 계약으로 이동한다는 점입니다.

ASSERT는 왜 필요한가

ACS가 “어디서 막을 것인가”라면 ASSERT는 “무엇을 테스트할 것인가”에 가깝습니다. Microsoft의 ASSERT 글은 제품 요구사항, 정책 문서, 시스템 프롬프트, 출시 체크리스트처럼 이미 팀 안에 존재하는 자연어 의도를 실행 가능한 평가 파이프라인으로 바꾸는 것을 목표로 합니다.

ASSERT 파이프라인은 크게 네 단계입니다. 먼저 넓은 행동 요구사항을 구체적 개념 명세로 바꿉니다. 다음으로 허용되는 행동과 허용되지 않는 행동의 택소노미를 만듭니다. 그다음 단일 턴 또는 멀티 턴 테스트 케이스를 생성합니다. 마지막으로 모델, 애플리케이션, 에이전트에 실행해 보고 툴 호출과 중간 판단을 포함한 trace를 근거로 점수를 매깁니다.

Microsoft Command Line 공식 ASSERT 평가 프레임워크 이미지. 자연어 스펙에서 평가 케이스와 스코어링으로 이어지는 흐름을 보여준다

이미지 출처: Microsoft Command Line, “Turn specs into evals for any agent with ASSERT”.

이 접근은 일반 벤치마크와 다릅니다. “우리 모델이 일반적으로 친절한가”보다 “우리 환불 에이전트가 10만 원 이하 환불은 처리하되, 사기 의심 건은 escalate 하는가”를 보는 방식입니다. “우리 코딩 에이전트가 코드를 잘 쓰는가”보다 “운영 DB 삭제, 배포 파일 수정, 시크릿 노출 같은 금지 행동을 회귀 테스트에서 반복적으로 막는가”를 보는 방식입니다.

이전의 AI 모델 평가 플레이북 글에서 정리했듯, 에이전트 평가는 모델 점수 하나로 끝나지 않습니다. 하네스, 도구, 예산, 재시도, trace, 평가 기준이 함께 공개되어야 합니다. ASSERT는 그 평가 기준을 제품 요구사항과 더 가깝게 붙이려는 도구입니다.

왜 중요한가

첫 번째 의미는 보안입니다. 에이전트는 일반 앱보다 권한 문맥이 빠르게 바뀝니다. 같은 Slack 토큰이라도 회의 요약만 할 때는 괜찮지만, 대화 중 비공개 계약서를 읽은 뒤 외부 채널에 메시지를 보내려는 순간 위험해질 수 있습니다. 전통적인 IAM은 “이 토큰이 Slack API를 호출할 수 있는가”를 잘 판단하지만, “이 세션에서 이 데이터를 본 뒤 이 메시지를 보내도 되는가”는 별도의 문맥이 필요합니다.

두 번째 의미는 개발자 워크플로우입니다. 코딩 에이전트가 강해질수록 문제는 코드 생성이 아니라 검증 루프가 됩니다. 도구 호출 전 정책 검사, 테스트 실패 시 rollback, 위험 명령 승인, 변경 범위 제한, 비용 예산이 하네스에 들어가야 합니다. Claude Code 병렬 subagent 비용 글에서 다룬 것처럼 긴 작업형 에이전트는 한 프롬프트 안에서 여러 하위 작업을 돌릴 수 있습니다. 이때 권한과 예산이 없으면 생산성보다 사고 반경이 먼저 커집니다.

세 번째 의미는 기업 조달입니다. 앞으로 “에이전트 기능이 있다”는 말은 부족합니다. 기업은 해당 제품이 어떤 개입점에서 정책을 검사하는지, 정책 파일을 버전 관리할 수 있는지, trace와 판정 근거를 감사할 수 있는지, 평가 회귀를 CI에 넣을 수 있는지 물어야 합니다. 모델명보다 운영 증거가 중요해집니다.

어떻게 써야 하나

실무팀은 ACS와 ASSERT를 대형 거버넌스 프로젝트로만 보면 도입이 늦어집니다. 처음에는 가장 위험한 도구 하나부터 잡는 것이 낫습니다. 이메일 발송, 결제·환불, DB 쓰기, 코드 배포, 외부 웹훅 호출처럼 되돌리기 어려운 행동을 고릅니다.

그 다음 아래 순서로 시작할 수 있습니다.

  1. 도구 목록을 읽기, 쓰기, 삭제, 외부 전송으로 나눈다.
  2. pre_tool_call에서 반드시 검사할 도구 3개를 고른다.
  3. 허용, 차단, 사람 승인, 민감 정보 제거 기준을 문장으로 쓴다.
  4. 그 문장을 ASSERT용 평가 요구사항으로 바꾼다.
  5. 실패 케이스를 만든 뒤 ACS 정책으로 막는다.
  6. 같은 케이스를 다시 돌려 회귀 테스트로 남긴다.

팀 회의에서 바로 쓸 수 있는 기준은 더 단순합니다.

질문 확인할 것
이 에이전트가 실제로 행동하는가 읽기 전용 답변인지, 도구 호출과 쓰기 작업이 있는지 구분
어떤 지점에서 멈출 수 있는가 입력, 모델 호출 전후, 도구 호출 전후, 출력 중 최소 어디를 검사하는지 확인
정책은 어디에 있는가 프롬프트, 코드, YAML, OPA/Rego, 보안 도구 중 감사 가능한 위치 확인
실패는 어떻게 재현하는가 ASSERT 같은 평가 세트와 trace 저장 여부 확인
사람 승인은 언제 필요한가 금액, 외부 전송, 삭제, 배포, 개인정보 접근 기준을 수치화

프롬프트도 이렇게 바꿔야 합니다. “안전하게 처리해줘”는 통제 기준이 아닙니다. 대신 하네스와 평가 기준을 같이 적어야 합니다.

이 고객지원 에이전트의 환불 정책 평가 세트를 만들어라.
조건:
- 10만 원 이하 정상 환불 요청은 처리 가능으로 분류한다.
- 사기 의심, 반복 환불, 계정 공유 정황은 사람 승인으로 넘긴다.
- 외부 이메일 발송과 결제 취소 도구 호출은 pre_tool_call에서 검사해야 한다.
- 각 테스트 케이스는 user message, expected policy stance, 위험 근거, 필요한 trace evidence를 포함한다.

이런 프롬프트는 모델을 더 착하게 만드는 주문이 아닙니다. 제품 요구사항을 평가와 통제 루프로 옮기기 위한 작업 지시입니다.

리스크와 한계

첫 번째 한계는 표준의 성숙도입니다. Microsoft 글 기준 ACS는 공개 초기 단계이고, Agent Governance Toolkit README도 Public Preview라고 표시합니다. 실제 운영에 넣으려면 SDK 버전, 정책 언어, 프레임워크 어댑터, conformance 테스트가 얼마나 안정적인지 확인해야 합니다.

두 번째 한계는 평가 품질입니다. ASSERT가 자연어 요구사항에서 테스트 케이스를 만들어도, 요구사항 자체가 흐리면 평가도 흐립니다. “고객에게 적절히 응답하라”보다 “외부 수신자에게 내부 전용 문서를 보내지 말라”가 더 좋은 스펙입니다. 모델 기반 judge도 틀릴 수 있으므로 중요한 영역에서는 정책 담당자와 도메인 전문가 검토가 필요합니다.

세 번째 한계는 비용입니다. trace 기반 평가와 회귀 테스트는 모델 호출, 도구 실행, 로그 저장을 동반합니다. 모든 대화를 무한히 평가할 수는 없습니다. 대표 시나리오, 고위험 도구, 최근 실패 유형부터 회귀 세트를 좁혀야 합니다.

네 번째 한계는 과신입니다. ACS가 있다고 모든 사고가 사라지는 것은 아닙니다. 정책이 빠진 도구, 잘못 분류된 데이터, 로그 누락, 승인 피로, 우회 가능한 플러그인이 남을 수 있습니다. 통제 표준은 사고를 줄이는 운영 장치이지, 에이전트 안전 인증서가 아닙니다.

Microsoft Command Line 공식 ASSERT 예시 이미지. 사용자 입력, 시스템 출력, 평가 판단을 연결해 실패 근거를 볼 수 있는 구조를 보여준다

이미지 출처: Microsoft Command Line, ASSERT 공식 글.

관전 포인트

앞으로 볼 지표는 세 가지입니다.

첫째, ACS가 Microsoft 생태계 밖에서 얼마나 채택되는가입니다. CrewAI, Arize AI, LiteLLM, Pydantic 같은 파트너 언급은 출발점입니다. 실제로 LangChain, OpenAI Agents SDK, Anthropic 도구 호출, MCP 서버, 사내 하네스까지 같은 정책 표면을 공유할 수 있는지가 중요합니다.

둘째, 평가와 통제가 CI/CD에 들어가는가입니다. 에이전트 릴리스 전에 ASSERT로 정책 회귀 테스트를 돌리고, 실패한 케이스를 ACS 정책으로 막고, 다시 평가하는 루프가 자동화되면 에이전트 운영은 지금보다 훨씬 소프트웨어 엔지니어링에 가까워집니다.

셋째, 보안팀과 개발팀의 소유권이 어떻게 나뉘는가입니다. 개발팀은 하네스를 만들고, 보안팀은 정책과 감사 기준을 관리하고, 현업팀은 업무 요구사항과 승인 임계값을 제공합니다. 이 세 역할이 분리되지 않으면 에이전트 통제는 또다시 프롬프트와 임시 코드에 흩어질 가능성이 큽니다.

결론은 분명합니다. 에이전트 경쟁은 더 긴 컨텍스트, 더 높은 벤치마크, 더 빠른 코딩에서 끝나지 않습니다. 실제 업무에 들어가는 순간 핵심은 실행 루프입니다. 무엇을 보기 전에, 무엇을 호출하기 전에, 무엇을 외부로 내보내기 전에 멈출 수 있는가. Microsoft의 ACS와 ASSERT는 그 질문을 제품 기능이 아니라 표준과 평가 루프로 만들려는 시도입니다.

출처와 더 읽을 거리

Agent Control Specification Agent Governance Toolkit AI 보안 AI 에이전트 AI 평가 ASSERT Microsoft 개발자 도구 하네스

공유

Threads X