AI 에이전트 거버넌스는 도구 호출(Tool Call) 이전에 실행되어야 합니다 | Focused Labs

도구 호출 (Tool Call) 이후의 AI 에이전트 거버넌스는 통제가 아닌 감사 서류 작업에 불과합니다.

작은 행동이라도 부작용을 초래할 수 있습니다: 이메일 전송, 고객 정보 업데이트, 환불 승인, Salesforce 기회(Opportunity) 업데이트, 또는 단순히 지갑에서 돈을 사용하는 것 등이 그러합니다. 이러한 각 행동에는 유용한 부작용과 덜 유용한 부작용이 있습니다. 만약 런타임 (Runtime)이 덜 유용한 부작용이 발생하는 것을 방지할 만큼 충분한 컨텍스트 (Context)를 가지고 있지 않다면, 발생한 일을 감사 (Auditing)하는 것이 가치가 있을 것입니다.

Gartner는 지난 5월, 서로 다른 자율성 수준과 접근 권한을 가진 AI 에이전트들에 동일한 거버넌스를 적용하면 과도한 제한 또는 제한 부족이 발생할 것이라고 예측했습니다. Gartner는 2027년 전망에서, 2027년까지 기업의 40%가 운영 환경에서 AI 에이전트를 실행하는 동안 거버넌스 관련 격차를 발견하고, 자율 AI 에이전트의 등급을 낮추거나 폐기할 것이라고 예측하고 있습니다.

읽기 전용 요약기 (Read-only summarizer)와 계정 데이터를 수정하는 에이전트가 거버넌스를 위해 동일한 검토 프로세스를 거친다는 사실만으로도 이미 충분히 나쁩니다. 하지만 초안 작성 보조 에이전트 (Drafting assistant agent)와 운영 에이전트 (Production operations agent)가 모두 동일한 승인 규칙의 적용을 받는다는 것은 그저 어리석은 일입니다. 마찬가지로, 환불을 권장하는 에이전트와 실제로 환불을 실행하는 에이전트는 서로 다른 런타임 엔벨로프 (Runtime envelopes) 내에 있어야 합니다.

행동 경계가 곧 거버넌스 경계입니다

행동 경계 (action boundary)에서 에이전트 AI 거버넌스 (agentic AI governance)를 강제하는 것은 모델이 행동을 제안할 때 가장 깔끔합니다. 그러면 런타임 (runtime)은 제안된 행동을 어떻게 처리할지 결정할 수 있습니다. 런타임은 사용자, 스레드 (thread), 실행 (run), 시도 (attempt), 제안된 도구의 이름, 해당 도구의 인자 (arguments), 런타임의 이전 상태 (즉, 런타임의 스토어 (store)), 런타임의 승인 상태 (즉, 어떤 에이전트가 무엇에 대해 승인되었는지), 그리고 런타임이 사용할 수 있는 자격 증명 (credentials)에 대해 알고 있습니다. 따라서 모델이 실행되어 부수 효과 (side effect)를 일으킬 기회를 갖기 전까지, 행동 경계는 거버넌스를 위한 깔끔한 지점이 됩니다.

에이전트 AI 거버넌스에 관하여, Focused는 이미 실행 경로에서의 AI 에이전트 거버넌스 (AI agent governance in the execution path)에 대해 작성한 바 있습니다. 더 큰 문제는 이러한 제어가 어떤 형태를 취하는가이며, 특히 신원 (identity), 정책 (policy), 평가 (evals), 트레이스 (traces), 승인 (approvals), 그리고 복구 (recovery)가 실행 시점에 어떻게 단일한 결정으로 컴파일될 수 있는가 하는 점입니다.

유용한 계약 (contract)은 에이전트에 의한 행동 실행에 관한 가장 단순한 질문들에 다음과 같이 답할 수 있습니다: 1) 이 에이전트가 이 사용자를 위해 이 도구를 호출해도 되는가? 2) 이 행동은 이 에이전트가 행동할 수 있는 권한 엔벨로프 (permission envelope)를 부여하는 워크플로 (workflow)의 일부였는가? 3) 이 행동이 계정/리전 수준의 제약 조건 (constraints)을 준수하는가? 4) 이 행동에 승인이 필요한가? 5) 소프트 제약 조건 (soft constraint)을 위반하는 이 행동에 대한 적절한 복구 (recovery) 방법은 무엇인가?

하지만 런타임의 결정이 없다면, 시스템의 거버넌스는 그저 Slack 유물 발굴과 다를 바 없습니다. 사람들은 프롬프트 (prompt), 해당 프롬프트에 대한 도구 스키마 (tool schema), 인간의 승인, 그에 상응하는 트레이스 (trace), Jira 티켓, 마지막 배포의 차이점 (diff), 그리고 애초에 이 모든 문제를 일으킨 지표 (metric)의 변화를 찾아 헤매게 됩니다. 모든 아티팩트 (artifacts)가 어딘가에 존재했기 때문에, 모두가 시스템에 제어 평면 (control plane)이 있었다고 가정합니다.

존재하는 것이 곧 강제하는 것은 아닙니다.

계약 게이트(contract gate)는 부수 효과(side effect) 이전에 위치해야 하는 반면, 런타임(runtime)은 여전히 선택권을 가집니다.

행동 계약(Behavioral contracts)은 거버넌스에 런타임 형태를 부여합니다

에이전트형 AI (agentic AI)를 거버넌스화하기 위한 학술적 연구가 증가하고 있으며, 그 중 상당수는 이러한 에이전트를 위한 계약 (contracts)에 집중하고 있습니다. 최근 Agent Behavioral Contracts에 관한 논문이 발표되었습니다. 이는 에이전트의 행동을 계약적 표현으로 나타낸 것으로, 사전 조건 (Preconditions), 엄격한 불변량 (hard Invariants), 완만한 불변량 (soft Invariants), 엄격/완만한 거버넌스 제약 (hard/soft Governance Constraints), 그리고 복구 메커니즘 (Recovery mechanisms)으로 분해됩니다. 1,980회의 세션 결과에 따르면, 엄격한 제약 준수율은 평균 88100%였으며, "표류 (drift)"는 허용 범위 내로 간주되는 0.27 미만으로 제한되었습니다 (모든 작업의 평균 액션당 처리 시간은 10ms 미만이었습니다). 이 계약을 통해 세션당 5.26.8개의 완만한 위반 (soft violations) 사항이 드러났으며, 이는 계약이 없는 베이스라인 (baselines)에서는 감지되지 않았을 사항들입니다.

행동 계약은 트레이스 (trace)를 증거로 변환합니다. 계약된 에이전트의 트레이스는 조직에서 운영 배포 시 이미 사용 중인 변경 기록 및 권한 엔벨로프 (change records and permission envelopes)와 연결되는 기록 목록이 될 수 있습니다. 읽기 전용 요약기 (read-only summarizer)는 운영 책임이 있는 자율 AI 에이전트 (production accountable autonomous AI agent)와는 다른 것입니다. 초안 작성 보조 도구 (drafting assistant)는 운영 에이전트 (production operations agent)와 다릅니다. 환불 추천자 (refund recommender)와 환불 발행자 (refund issuer)는 각각 서로 다른 런타임 엔벨로프 (runtime envelope)에 속합니다.

런타임 컨텍스트 (Runtime context)는 누락된 입력값입니다

런타임 거버넌스 (Runtime governance)는 도구 계층 (tool layer)과 가장 밀접합니다. LangChain 런타임 (runtime) 문서는 LangGraph 런타임의 create_agent 메서드를 설명하는데, 이 메서드는 컨텍스트 (context), 스토어 (store), 스트림 라이터 (stream writer), 실행 정보 (execution info) 및 서버 정보 (server info)를 도구 (tools)와 미들웨어 (middleware)에서 사용할 수 있도록 제공합니다. 문서는 ToolRuntime 인터페이스를 통해 사용자 컨텍스트 (예: 인증된 사용자 ID, 사용자 이메일), 스토어 접근 권한, 스레드 ID (thread id), 실행 ID (run id), 시도 횟수 (attempt number), 서버 정보 (예: 서버 ID, 버전) 및 관련 런타임 세부 정보를 노출합니다. 이는 거버넌스 결정에 정확히 필요한 데이터입니다.

가드 (Guards)를 에이전트 (agent) 수준에서 활성화하여 실행의 시작과 종료뿐만 아니라, 런타임 내에서의 모델 및 도구 호출을 제한할 수 있습니다. PII (개인정보) 제거뿐만 아니라, 실행 전 인간의 승인이 필요한 민감한 명령에 대한 Human-in-the-loop 승인을 포함하여, 이미 구축되어 있거나 플러그인 형태로 사용 가능한 미들웨어가 존재합니다. 문서는 실행 주변에 강제 적용 (enforcement) 기능을 배치합니다.

참고로, Open Policy Agent는 이미 정책 결정 (policy decision-making)과 강제 적용 (enforcement)을 분리하고 있으며, Kubernetes admission control, API 게이트웨이 (API gateways), 서비스 권한 부여 (service authorization), CI, 그리고 인프라 정책 (infrastructure policy) 분야에서 방대한 사용자 기반을 보유하고 있습니다.

에이전트 거버넌스(Agent governance)도 에이전트 특화 입력(agent-specific inputs)을 통해 유사한 경로를 따라가야 합니다. 즉, 정책 결정 함수(policy decision function)는 에이전트가 해당 사용자를 위해 호출하려는 도구(tool)에 대한 제안된 동작(proposed action)을 알고 있어야 합니다. 해당 호출에 대한 권한 범위(permission envelope)를 결정하기 위해 워크플로 정보(workflow info)를 알아야 합니다. 또한 해당 동작에 대한 계정 및 리전 제약 조건(account and region constraints), 그리고 해당 동작에 승인이 필요한지 여부를 알아야 합니다. 마지막으로, 결정 함수는 단순한 허용/거부(allow/deny) 이상의 것을 반환해야 합니다. 허용된 동작에 대한 영수증(receipt)을 반환하거나(예: 해당 레코드의 모든 변경 이력), 동작을 차단하거나(예: 결제 거부), 동작으로부터 복구를 시도하거나(예: 지연 후 복구(remediation) 재시도), 또는 동작을 사람에게 에스컬레이션(escalate)한 후 해당 사람의 승인이 완료되면 동일한 스레드를 재개해야 합니다.

비례적 거버넌스가 하나의 거대한 관문보다 낫습니다

균일한 거버넌스(Uniform governance)는 위원회 발표 자료(committee deck)에서는 깔끔해 보입니다. 모든 에이전트가 동일한 방식으로 검토됩니다. 동일한 체크리스트를 통과합니다. 동일한 제약 조건을 상속받습니다. 하지만 이것이 바로 저위험 AI 에이전트는 멍청해지고, 고위험 AI 에이전트는 위험해지는 방식입니다. 전자는 프로세스에 파묻히고, 후자는 챗봇을 위해 작성된 통제 수단(controls)을 적용받게 됩니다.

거버넌스를 위한 비례 모델(proportional model)은 에이전트의 자율성 수준과 잠재적 폭발 반경(blast radius, 즉 감시 없이 방치되거나 통상적인 경계를 벗어났을 때 발생할 수 있는 피해 규모)에서 시작됩니다. 관찰자(Observers)는 범위가 제한된 읽기 권한(scoped read access)을 가진 에이전트를 필요로 하며, 이는 프로그래밍 방식으로 설정되고 로그에 기록된 자격 증명(credentials) 또는 범위(scope)를 포함할 수 있습니다. 테스트 가능한 에이전트도 필요합니다. 어드바이저(Advisors)는 그 출력이 다른 에이전트와 인간에 의해 액면 그대로 받아들여지기 때문에 위험하며, 따라서 다양한 테스트 케이스를 통해 품질을 검증해야 합니다. 다른 에이전트의 작업을 승인(Approve)하는 에이전트는 선과 악 모두에 대해 가장 큰 잠재력을 가집니다. 이들은 인간 없이도 승인하도록 프로그래밍될 수 있지만, 이 경우 그들의 결정은 다시 인간의 검토와 승인을 거쳐야 하며, 결정에 대한 감사 추적(audit trails)과 문제가 발생했을 때를 대비한 사고 보고서(incident reports)가 수반되어야 합니다. 마지막으로, 완전히 자율적인(Autonomous) 에이전트가 있는데, 이들의 행동은 하드 인베리언트(hard invariants)를 통해 실시간으로 모니터링되어야 하며, 실패 시 복구 조치, 서킷 브레이커(circuit breakers), 소유자 기반의 다른 에이전트 또는 팀으로의 문제 에스컬레이션(escalation), 그리고 성능에 대한 지속적인 모니터링 규정이 마련되어 있어야 합니다.

여기에는 워크로드 ID (workload identity)라는 중요한 개념에 대한 언급도 포함되어 있습니다. 만약 도구 호출(tool call)이 프롬프트나 환경 변수에 놓인 일반적인 API 키 형태로 전달된다면, 계약(contract)은 권한에 대해 추론할 수 없습니다. 워크로드 ID, 사용자 또는 행위자 ID, 범위가 지정된 자격 증명, 그리고 왜 해당 자격 증명이 이 작업에 사용 가능한지에 대한 기록이 필요합니다. 이러한 요소들이 없다면, 사람들은 다시 블랙박스가 제대로 작동하기만을 바라는 상태로 돌아가게 됩니다.

기술(Skills), MCP 도구, 그리고 가져온 에이전트 기능(agent capabilities) 또한 실행 가능한 아티팩트(executable artifacts)입니다. 실행 가능한 에이전트 아티팩트 (Executable agent artifacts)는 출처(provenance), 버전, 권한 범위, 평가 증거(eval evidence), 그리고 롤백(rollback) 동작을 포함해야 합니다. 런타임(runtime)은 이러한 아티팩트들이 동작하도록 허용하기 전에 이를 검사할 수 있어야 합니다.

에이전트가 비감독(unsupervised) 부작용에 가까워질수록 거버넌스(Governance)는 더 무거워집니다.

영수증(Receipt)은 거버넌스의 산물입니다

거버넌스와 관련하여 영수증(receipt)은 명령 실행의 주요 부작용(side effect)이 발생하기 전에 생성되는 부작용 영수증(side-effect receipts)과 유사합니다. 타이밍이 중요합니다. 거버넌스 영수증은 변이(mutation)가 실행되기 전의 정책 결정(policy decision)을 기록합니다.

앞서 언급했듯이, 거버넌스 결정의 영수증에는 제안된 작업의 수락으로 인해 발생한 트레이스(trace)를 누군가가 재현하고 검토할 수 있게 하며, 변경된 트레이스를 어디에서 찾아야 하는지(따라서 배포로 인한 트레이스뿐만 아니라 변경 기록 및 배포를 위한 인시던트 채널까지 포함) 알 수 있도록 하는 데 필요한 정보가 포함되어야 합니다. 여기에는 다음 사항이 포함되어야 합니다: 1) 제안된 작업에 대한 설명, 2) 작업을 평가하는 데 사용된 계약(contract) 버전, 3) 계약이 결정을 내리는 데 사용한 런타임(runtime) 입력값, 4) 결정에 도달하기 위해 계약에 의해 실행된 정책 분기(policy branch) 및 승인/복구 경로(approval/recovery path), 5) 결과 트레이스로의 링크. 결과 영수증을 통해 누군가는 작업의 수락 여부를 검토하고 그로 인해 발생한 트레이스의 변화를 확인할 수 있어야 합니다.

Benchling의 LangChain 인터뷰는 여기서 좋은 실무적 상기 사례가 됩니다. 그들의 팀은 모델 제공자(provider) 제품군마다 서로 다른 실수를 하기 때문에 과학적 작업에 여러 모델 제공자를 사용하며, 순번제로 지정된 파이어 치프(fire chief, 책임자)와 함께 프로덕션 트레이스를 검토합니다. 트레이스 검토는 운영 모델(operating model)의 일부이지, 모든 것이 불타오를 때 누군가가 확인하는 대시보드가 아닙니다.