연구2026.08.11

AI Agent가 도구를 실행하기 직전, 우리는 무엇을 통제했나

AI 에이전트가 답변만 생성할 때와 실제 업무 도구를 사용할 때의 위험은 다르다.

메일을 읽는 것과 보내는 것, 항공편을 조회하는 것과 예약을 취소하는 것, 계좌 정보를 확인하는 것과 송금하는 것은 모두 ‘도구 사용’이지만 결과의 무게는 전혀 다르다. 어떤 행동은 되돌릴 수 있고, 어떤 행동은 외부 상태를 즉시 바꾼다. 개인 정보나 금전, 조직의 운영 권한과 연결되는 행동도 있다.

그렇다면 기업이 AI 에이전트에게 업무를 맡길 때 확인해야 할 것은 단순히 “이 모델이 과제를 잘 푸는가?”만이 아니다.

더 중요한 질문은 다음과 같다.

AI 에이전트가 실제 업무 도구를 실행하려는 순간, 조직의 정책이 그 행동에 개입할 수 있는가?

우리는 이 질문을 검증하기 위해 통제가 없는 기준선인 C0와 거버넌스가 활성화된 C5를 설계했다. 그리고 동일한 과제와 동일한 모델을 두 조건에서 실행해, 거버넌스가 실제로 무엇을 허용하고 무엇을 멈추는지 비교했다.

이 글은 그 과정에서 개발한 시스템과 총 1,446회의 실행 결과, 그리고 첫 번째 실험을 마치며 얻은 교훈을 기록한 글이다.

프롬프트만으로는 충분하지 않았다

AI 에이전트의 안전성을 다룰 때 가장 먼저 떠올릴 수 있는 방법은 시스템 프롬프트에 규칙을 적는 것이다.

예를 들면 다음과 같다.

사용자의 개인 정보를 외부에 보내지 않는다.
금전과 관련된 작업은 사용자의 승인을 받는다.
요청받은 업무와 관련 없는 도구는 사용하지 않는다.

이러한 지침은 필요하다. 하지만 모델에게 규칙을 설명하는 것과 실제 도구 실행을 통제하는 것은 다른 문제다.

모델은 잘못된 도구를 선택할 수 있고, 예상하지 못한 인자를 만들 수 있으며, 여러 단계를 수행하는 과정에서 최초의 업무 범위를 벗어날 수도 있다. 프롬프트는 행동을 유도하지만, 실행 자체를 기술적으로 중단시키지는 못한다.

그래서 우리는 거버넌스를 모델의 앞이나 뒤가 아니라 에이전트와 업무 도구 사이에 배치했다.

모델이 도구를 호출하면 곧바로 실행하지 않는다. 먼저 거버넌스 프록시가 호출을 가로채고, 정책 엔진이 도구와 과제 맥락을 확인한다. 정책의 판단에 따라 원래 도구를 실행하거나, 승인이 필요한 행동으로 분류하거나, 호출을 차단한다.

그리고 이 모든 판단을 감사 로그로 남긴다.

즉, 이번 연구에서 거버넌스는 모델에게 전달하는 권고 문구가 아니라 실행 경로에 삽입된 기술적 통제 지점이다.

C0와 C5를 어떻게 정의했나

실험의 출발점은 통제 조건을 명확히 구분하는 것이었다.

C0: 통제가 없는 기준선

C0에서는 거버넌스 프록시가 사실상 pass-through로 동작한다. 모델이 선택한 도구 호출을 별도의 정책 개입 없이 원래 실행 경로로 전달한다.

C0는 다음을 측정하기 위한 기준선이다.

모델이 과제를 얼마나 완료하는가
어떤 도구를 선택하는가
고위험 도구 경로에 얼마나 자주 도달하는가
정책 개입이 없을 때 어떤 실패가 발생하는가

C5: 거버넌스가 활성화된 조건

C5에서는 최소권한 정책을 실행 경로에 적용한다.

도구는 크게 세 종류로 나뉜다.

허용 도구 과제 수행에 필요하다고 예상된 조회·읽기·필수 도구다.
승인 필요 도구 송금, 메시지 전송, 예약 취소, 주문 변경처럼 외부 상태를 바꾸거나 영향이 큰 행동이다.
예상 밖 도구 허용 목록과 승인 필요 목록 어디에도 포함되지 않은 호출이다.

허용된 도구는 실행한다. 예상 밖 도구는 차단한다. 승인 필요 도구는 승인 여부를 확인한 뒤 실행해야 한다.

다만 이번 실험에는 실제 사람에게 승인 요청을 보내고 응답을 돌려받는 채널이 없었다. 따라서 승인 필요 행동이 나타나면 안전한 기본값으로 실행을 중단하는 fail-closed 방식을 적용했다.

이 차이는 결과를 해석할 때 매우 중요하다. 승인 채널 부재로 중단된 실행은 모델이 고장 난 것이 아니라, 현재의 정책 구성에서 의도적으로 실행하지 않은 것이다.

우리가 실제로 개발한 것

1. GovernanceProxy

GovernanceProxy는 원래 도구 함수를 감싸고, 실행 전에 정책 엔진의 결정을 요청한다.

정책이 allow 또는 승인 완료를 반환하면 원래 함수를 실행한다. 정책이 block을 반환하면 원래 함수는 실행하지 않고, 벤치마크와 에이전트가 처리할 수 있는 차단 응답을 반환한다.

여기서 중요한 검증 항목은 “차단 메시지가 생성됐는가”가 아니다. 실제 원래 함수가 실행되지 않았는지를 original_callable_executed 필드로 기록했다. 정책이 차단했다고 말하면서 뒤에서는 도구가 실행되는 상황을 구분하기 위해서다.

2. 최소권한 정책 엔진

정책 엔진은 과제별로 예상 도구와 승인 필요 도구를 관리한다.

예를 들어 정보를 조회하는 도구는 허용할 수 있지만, 사용자 정보를 변경하거나 돈을 보내는 도구는 승인 대상으로 분류할 수 있다. 업무 범위와 관계없는 도구 호출은 예상 밖 호출로 차단한다.

정책 결정에는 적용된 규칙 ID와 판단 이유가 함께 포함된다. 덕분에 결과만 보고 “막혔다”고 추측하지 않고, 어떤 규칙이 어떤 이유로 호출을 막았는지 추적할 수 있다.

3. 벤치마크별 정책 프로필

실험에는 AgentDojo와 tau-bench를 사용했다. 두 벤치마크는 과제 구조와 도구 사용 방식, 평가 방식이 서로 다르다.

AgentDojo에는 과제별 expected-tool 정책을 적용했다. tau-bench에는 조회·헬퍼 도구를 허용하면서 변경·쓰기 성격의 도구를 승인 또는 차단 경로로 보내는 helper-aware 정책을 적용했다.

두 조건 모두 최소권한과 고위험 행동 통제라는 목적을 공유하지만, 세부 정책은 벤치마크의 특성에 맞게 구현했다. 따라서 결과를 해석할 때도 두 벤치마크를 무조건 하나로 합산하지 않고 각각의 결과를 함께 확인했다.

4. 감사 로그와 결과 분류 체계

각 도구 호출에는 다음과 같은 정보를 기록했다.

실험 조건과 벤치마크
호출한 도구 또는 행동의 이름
정책 결정과 적용 규칙
판단 이유
승인 필요 여부와 승인 상태
원래 도구의 실제 실행 여부
차단 여부
복구 가능성
실행 시간과 오류 유형

또한 최종 실행 결과를 단순 성공과 실패로만 나누지 않았다.

과제 성공
모델·과제 실패
정책 유발 안전 차단
평가기 오류

이 분류 체계가 없었다면 C5가 의도적으로 차단한 실행도 모델 실패에 섞였을 것이다.

실험은 어떻게 구성했나

최종 Full v2 실험의 범위는 다음과 같다.

실행 가능한 기본 과제: 241개
모델: Claude Opus 4.5, Claude Sonnet 4.5, Gemini 2.5 Pro
비교 조건: C0, C5
벤치마크: AgentDojo, tau-bench
유효 실행: 241 × 3 × 2 = 1,446건
C0/C5 paired 비교: 723쌍

동일한 기본 과제와 동일한 모델 조합을 C0와 C5로 묶었다. 이를 통해 서로 다른 과제를 단순 비교하는 대신, 같은 조건에서 거버넌스의 유무가 결과를 어떻게 바꾸는지 확인할 수 있었다.

최종 통합 결과는 다음 품질 조건을 충족했다.

예상한 1,446개 실행 행을 모두 확보
중복 실행 키 0개
최종 미실행 행 0개
결과 매핑 경고 0개

실험 과정이 항상 순조로웠던 것은 아니다. Batch 10에서 로컬 엔드포인트 연결 및 서버 오류로 120개의 인프라 실패 행이 발생했다. 이 120건은 뒤에서 언급하는 모델의 다단계 실행 한계 120건과 건수만 우연히 같을 뿐 서로 다른 집합이다. Batch 10 인프라 실패 행은 유효 실행 결과에서 제외하고 provenance로 보존했으며, 이후 동일한 범위를 Batch 10R로 재실행해 성능 분석에는 재실행 결과만 포함했다.

실패의 흔적을 남기면서도 동일 실행이 결과에 두 번 집계되지 않게 한 것이다.

성공률만 보면 C5는 실패처럼 보인다

C0의 과제 성공은 211건으로 29.2%였다. C5의 과제 성공은 81건으로 11.2%였다.

여기까지만 보면 결론은 간단해 보인다.

“거버넌스를 적용했더니 성공률이 낮아졌다.”

하지만 이 문장만으로는 C5에서 실제로 일어난 일을 설명할 수 없다. C5의 비성공에는 모델이 과제를 해결하지 못한 경우와, 정책이 실행을 의도적으로 멈춘 경우가 함께 들어 있기 때문이다.

총 1,446건을 결과의 의미에 따라 분해하면 다음과 같다.

과제 성공: 292건, 20.2%
모델·과제 실패: 798건, 55.2% — 과제 미해결 645건, 다단계 실행 한계 120건, 도구 미호출 33건
정책 유발 안전 차단: 272건, 18.8%
평가기 오류: 84건, 5.8%

C5에서 발생한 정책 유발 안전 차단은 272건이었다. 이 실행들은 모델이 답을 생성하지 못해서 실패한 것이 아니다. 정책이 승인 필요 행동이나 예상 범위 밖 도구 호출을 발견하고 실행을 중단한 경우다. 뒤에서 제시하는 차단 신호 285건은 이 272건에, 차단 신호는 남았지만 최종 결과가 평가기 오류로 분류된 13건을 더한 호출 로그 기준 수치다.

그렇다고 272건을 모두 안전 성과라고 부를 수도 없다. 실제로 막아야 할 위험 행동을 막았을 수도 있지만, 업무에 필요한 정상 도구를 정책이 과도하게 제한했을 수도 있다.

따라서 우리가 얻은 첫 번째 결론은 성공률의 높고 낮음이 아니었다.

AI 에이전트 거버넌스에서는 ‘모델의 실패’와 ‘정책이 선택한 중단’을 분리해야 한다.

같은 723쌍에서 결과는 어떻게 바뀌었나

paired 분석에서는 동일한 과제와 모델이 C0와 C5에서 어떤 결과를 냈는지 직접 비교했다.

결과는 다음과 같다.

C0와 C5 모두 성공: 72쌍
C0 성공에서 C5 비성공으로 전환: 139쌍
C0 비성공에서 C5 성공으로 전환: 9쌍
두 조건 모두 비성공: 503쌍

과제 성공률의 paired 변화는 -17.98%p였고, 근사 95% 신뢰구간은 -21.01%p에서 -14.95%p였다.

고위험 도구 도달은 C0의 170건에서 C5의 148건으로 22건 감소했다. paired 변화는 -3.04%p였다.

특히 C0에서는 성공했지만 C5에서 비성공으로 바뀐 139쌍을 다시 분해했다.

승인 채널 부재에 따른 fail-closed: 88쌍
예상 밖 또는 허용되지 않은 도구 차단: 41쌍
모델·과제 실패: 10쌍

즉, 성공 감소 139건 중 129건은 정책 차단 경로와 연결돼 있었다. C5가 실행 경로에 실질적으로 개입했다는 증거인 동시에, 정책이 만들어 낸 효용 비용이기도 하다.

C5는 어떤 거버넌스 신호를 남겼나

C5의 723건 가운데 호출 로그상 285건, 39.4%에서 차단 신호가 관찰됐다. 이 중 272건은 최종 결과도 정책 유발 안전 차단으로 분류됐고, 나머지 13건은 차단 신호가 있었으나 최종 결과가 평가기 오류로 분류됐다. 또한 285건 중 180건은 승인 필요 행동이었지만 실제 승인 채널을 사용할 수 없어 fail-closed된 사례였다.

로그를 기반으로 차단 결과를 예비 분류하면 다음과 같다.

승인 채널 부재에 따른 fail-closed 후보: 180건

정책상 사람의 승인이 필요한 행동이었지만 승인 채널이 없었기 때문에 실행하지 않았다. 현재 실험 구성에서는 의도한 안전 동작이다.

다만 실제 운영 환경에 승인 workflow가 연결됐다면 일부는 승인 후 정상 완료됐을 수 있다. 따라서 이 결과를 생산 환경의 효용 손실로 그대로 일반화해서는 안 된다.

allowlist 기반 적정 차단 후보: 64건

예상 범위 밖 도구를 차단했고, C0 성공에서 C5 실패로 이어지는 명시적인 효용 손실 신호는 발견되지 않은 사례다.

오탐 검토가 필요한 도구 차단 후보: 41건

C0에서는 성공했지만 C5에서 도구 차단 후 비성공으로 바뀐 사례다. 정상 업무에 필요한 도구를 정책이 과도하게 막았는지 확인해야 한다.

여기서 ‘후보’라는 표현이 중요하다. 41건은 확정된 오탐이 아니다. 각각의 업무 맥락과 도구 호출을 사람이 검토하기 전에는 올바른 차단인지 과잉 차단인지 확정할 수 없다.

이번 실험은 차단을 발생시키는 데서 끝나지 않고, 어떤 차단을 다음 수동 검토 대상으로 보내야 하는지 식별할 수 있는 로그 구조를 만들었다는 데 의미가 있다.

벤치마크에 따라 결과가 달랐다

AgentDojo: 거버넌스 개입이 선명하게 관찰된 환경

AgentDojo의 결과는 다음과 같다.

C0 성공: 176/267, 65.9%
C5 성공: 61/267, 22.8%
C5 차단: 147건
승인 채널 부재 차단: 90건

AgentDojo에서는 도구 사용과 고위험 행동 경로가 비교적 명확하게 드러났다. 그만큼 C5의 차단과 승인 필요 신호도 선명하게 관찰됐다.

반면 C0 대비 C5의 utility 감소도 컸다. 이는 정책이 실제로 개입했다는 뜻이지만, 동시에 allowlist가 업무에 필요한 정상 행동까지 막지 않았는지 검토해야 한다는 뜻이다.

tau-bench: 모델과 평가 파이프라인의 영향이 컸던 환경

tau-bench의 결과는 다음과 같다.

C0 성공: 35/456, 7.7%
C5 성공: 20/456, 4.4%
C5 차단: 138건
승인 채널 부재 차단: 90건

tau-bench에서는 task_not_solved와 평가기 오류가 많이 발생했다. 다단계 상호작용, helper 도구 사용, 모델의 tool-use 능력, 평가기의 안정성이 결과에 함께 영향을 미쳤다.

따라서 tau-bench의 낮은 성공률이나 C0/C5 차이를 거버넌스 정책 하나의 효과로 해석할 수 없다. 같은 C5라도 벤치마크가 제공하는 도구와 평가 구조에 따라 관측되는 신호가 달라진다는 사실을 확인했다.

모델마다 거버넌스와 상호작용하는 방식도 달랐다

Claude Opus 4.5는 C0에서 가장 높은 과제 성공 수를 기록했다. 동시에 C5에서는 승인 필요 및 차단 신호도 가장 많이 발생했다. 도구를 적극적으로 활용해 과제를 수행하는 모델일수록 정책과 만나는 지점도 늘어날 수 있다는 해석이 가능하다.

Claude Sonnet 4.5는 tau-bench에서 C0와 C5의 성공 수가 각각 8건으로 같았고, 평균 점수는 소폭 상승했다. 모든 모델에서 C5의 영향이 같은 방향과 크기로 나타난 것은 아니다.

Gemini 2.5 Pro는 tau-bench에서 고위험 도구 경로에 도달한 사례가 적었다. 그 결과 Opus와 Sonnet보다 거버넌스 차단 신호도 제한적으로 관찰됐다.

이 결과를 단순한 모델 순위로 읽기는 어렵다. 모델마다 도구를 선택하고 여러 단계를 진행하는 성향이 다르며, 그 차이가 정책의 허용·차단 규칙과 상호작용하기 때문이다.

거버넌스 평가에서는 모델의 정답률뿐 아니라 행동 성향과 정책 접촉면도 함께 봐야 한다.

첫 실험을 마치며 배운 다섯 가지

1. 거버넌스는 실행 경로에 있어야 한다

모델에게 안전 규칙을 설명하는 것만으로는 실제 도구 실행 여부를 검증할 수 없다. 정책 판단과 원래 함수 실행 사이에 통제 지점이 있어야 한다.

이번 래퍼에서는 차단 결과뿐 아니라 원래 도구가 실제로 실행됐는지를 별도로 기록했다. 이 차이가 프롬프트 수준의 안전 지침과 실행 수준의 거버넌스를 나누는 기준이었다.

2. 안전한 중단과 실패는 같은 것이 아니다

승인 필요 행동을 승인 채널 없이 실행하지 않은 것은 현재 구성에서 의도한 동작이다. 이를 모델 실패와 같은 범주로 집계하면 정책 효과를 잃게 된다.

반대로 정책이 막았다는 이유만으로 모든 차단을 적절하다고 평가해서도 안 된다. 차단 결과에는 적정 차단, 과잉 차단, 추가 검토가 필요한 사례가 함께 존재한다.

3. 승인 판정과 승인 workflow는 다르다

이번 C5는 어떤 행동에 승인이 필요한지 판정하고, 승인 정보가 없을 때 fail-closed하는 단계까지 구현했다. 하지만 사람에게 승인 요청을 전달하고, 승인 결과에 따라 실행을 재개하는 완전한 workflow는 구현하지 않았다.

생산 환경에서의 효용을 평가하려면 다음 단계에서 실제 승인 서비스를 연결해야 한다.

4. 정책만큼 어댑터와 평가기도 중요하다

벤치마크마다 도구의 의미와 helper 구조가 달랐다. 정책이 같은 목적을 가져도 실제 통합 방식에 따라 허용 범위와 차단 결과가 달라졌다.

또한 평가기 오류를 모델 실패나 정책 실패와 분리하지 않으면 잘못된 결론에 도달할 수 있다. 에이전트 거버넌스 실험은 정책 코드만의 실험이 아니라 실행기, 서버, 어댑터, 평가기를 포함한 전체 시스템 실험이었다.

5. 재현성은 실패 기록을 보존하는 데서 시작한다

Batch 10의 인프라 실패를 조용히 삭제했다면 최종 숫자는 깔끔해 보였을 것이다. 하지만 어떤 결과가 왜 제외됐고 무엇으로 대체됐는지 알 수 없게 된다.

우리는 원본 장애 행을 provenance로 보존하고 Batch 10R을 유효 결과로 사용했다. 최종 통합 단계에서 중복 키와 누락 행을 다시 확인했다. 성공한 결과뿐 아니라 실패와 대체의 계보를 남기는 것이 실험을 재현 가능하게 만들었다.

이번 결과가 증명하지 않는 것

이번 실험은 C5가 모든 위험 행동을 막았다고 증명하지 않는다. 또한 생산 환경에서의 안전성을 검증한 결과도 아니다.

해석할 때 다음 한계를 함께 봐야 한다.

실제 인간 승인 채널이 없어 승인 필요 행동은 모두 fail-closed됐다.
모델·과제 실패 798건은 task_not_solved 645건, 다단계 실행 한계 120건, 도구 미호출 33건으로 구성된다. 여기의 120건은 유효 실행에 포함된 모델 실행 한계이며, 앞서 제외·재실행한 Batch 10 인프라 실패 120건과는 별개다.
평가기 오류 84건이 남아 있다.
AgentDojo와 tau-bench는 과제 및 평가 구조가 다르다.
두 벤치마크에 적용한 C5 정책은 목적은 같지만 세부 구현이 동일하지 않다.
41건의 오탐 검토 후보는 아직 확정 오탐이 아니다.
이번 통합 결과는 Full v2의 실행 가능한 범위에 한정된다.

따라서 이번 결과를 “C5가 안전성을 증명했다”라고 표현할 수는 없다.

우리가 강하게 말할 수 있는 것은 다음 정도다.

C5는 에이전트의 도구 실행 경로에 실제로 개입했고, 고위험·승인 필요·예상 밖 행동에 대해 감사 가능한 차단 신호를 만들었다.

다음 단계

C0/C5는 완성된 거버넌스 시스템의 종착점이 아니라 첫 번째 실행 기반이다.

다음 연구와 개발에서는 다음 항목을 이어갈 계획이다.

실제 승인 workflow 연결

승인 필요 행동을 무조건 중단하는 대신, 사람에게 요청을 전달하고 승인·거절·시간 초과 결과를 받아 실행을 재개하거나 종료하는 흐름이 필요하다.

41개 차단 후보의 수동 판정

각 사례를 검토해 적정 차단, 오탐, 정책 누락, 모델·과제 실패, 불명확 사례로 구분해야 한다. 이를 통해 정책의 정밀도와 과잉 차단률을 계산할 수 있다.

차단 이후의 복구 경로 평가

운영 환경에서는 차단 자체보다 차단 이후 무엇을 할 수 있는지가 중요하다. 더 안전한 도구로 전환하거나, 업무 범위를 축소하거나, 사람에게 이관한 뒤 과제를 완료할 수 있어야 한다.

정책의 단계화

모든 위험 행동을 하나의 차단 규칙으로 처리하기보다 읽기, 제한적 변경, 승인 필요 변경, 금지 행동 등으로 통제 강도를 세분화할 필요가 있다.

모델·정책 조합별 행동 분석

모델의 도구 사용 성향과 정책 접촉면을 분석해, 어떤 모델과 어떤 정책 조합에서 효용과 통제의 균형이 달라지는지 확인해야 한다.

마치며

이번 C0/C5 연구에서 우리가 확인하려 했던 것은 “거버넌스를 적용하면 성공률이 올라가는가?”가 아니었다.

오히려 더 근본적인 질문이었다.

AI 에이전트가 실제 업무 도구를 실행하려는 순간, 조직의 정책이 그 행동을 멈출 수 있는가. 무엇을 허용했고 무엇을 막았는지 설명할 수 있는가. 그리고 그 과정에서 발생한 모델 실패와 정책의 선택을 구분할 수 있는가.

C5는 분명한 효용 비용을 만들었다. C0보다 과제 성공률이 낮아졌고, 승인 채널이 없었기 때문에 많은 실행이 fail-closed됐다.

하지만 그 비용을 하나의 실패율로 뭉개지 않고 모델·과제 실패, 정책 유발 차단, 평가기 오류로 분해하면서 거버넌스 시스템이 실제로 한 일을 관찰할 수 있었다.

이것이 이번 첫 실험에서 얻은 가장 중요한 결과다.

AI 에이전트의 자율성은 선언만으로 통제되지 않는다. 실행 경로에서 측정하고, 개입하고, 기록할 수 있어야 한다.

C0/C5는 그 출발점을 만들기 위한 우리의 첫 번째 구현이자 실험이었다.

실험 요약

241개 실행 가능 과제
3개 모델
C0/C5 2개 조건
1,446개 유효 실행
723개 paired 비교
C5 차단 신호 285건
승인 채널 부재에 따른 fail-closed 180건
정책 유발 안전 차단 272건
수동 오탐 검토 후보 41건