AI Agent Autonomy: 행동마다 자율의 선을 긋고 되돌릴 수 없는 일은 사람이 승인

에이전트에게 얼마나 맡길지는 에이전트 단위가 아니라 행동 단위로 정합니다. 읽고 분류하고 초안을 쓰는 일은 혼자 하게 둡니다. 계약 서명이나 송금처럼 되돌릴 수 없는 일은 사람이 승인합니다. 실제로 쓰려면 워크플로의 행동을 하나씩 적은 목록에 되돌림 가능 여부, 한도, 승인자를 붙여야 합니다. 그리고 에이전트 권한이 맡긴 사람의 권한을 넘지 않게 호출 경로에서 막습니다.

요약

CIO.com 선임 기자 Grant Gross가 2026년 11월 5일 낸 기사입니다. 에이전틱 AI의 약속은 에이전트가 스스로 판단하고 행동하는 것인데, IT 리더 대부분은 아직 봇에게 넓은 통제권을 넘길 준비가 안 됐다는 문제의식에서 출발합니다. 근거로 KPMG의 3분기 AI Pulse 조사(2026년 7~8월)를 듭니다. 에이전트를 구축·배포·개발 중이라는 IT 리더가 직전 분기 53%에서 62%로 늘었습니다. 그래도 사내 프로세스를 에이전트에 넘기는 일은 1차 IT 지원 같은 단순하고 위험이 낮은 업무에 머뭅니다. 기사는 이 간극을 네 사람의 시각으로 풉니다. AI 거버넌스 벤더 ModelOp의 CTO Jim Olsen, 보안 기업 Barracuda Networks의 CIO Siroui Mushegian, 공과금 앱 Taupia의 공동창업자 겸 CTO Joshua Rowe, 고객 상담 AI 플랫폼 Text의 CTO Maciej Walaszczyk입니다.

네 사람의 답은 한 방향으로 모입니다. 완전 자율은 당분간 오지 않지만 제한된 자율은 이미 쓰입니다. 그 경계를 정하는 기준이 에이전트의 성능이나 신뢰도가 아니라 행동 하나하나의 결과라는 점이 이 기사의 요지입니다. 실수했을 때 바로 고칠 수 있는 행동은 혼자 하게 둡니다. 권한 변경이나 운영 시스템 수정, 계약 서명, 송금처럼 결과가 무겁거나 되돌릴 수 없는 행동에는 사람을 붙입니다. 자율을 넓히는 속도는 모델이 얼마나 좋아지느냐보다 행동을 되돌릴 수 있게, 범위를 묶을 수 있게 만드는 속도에 달렸다는 것이 기사 속 진단입니다. 아래에서 다섯 가지 작동 원리와 세 사례를 본 뒤 실제로 돌릴 때 필요한 기술·현업 디테일을 붙입니다.

핵심 메커니즘

Action-level Autonomy: 같은 에이전트라도 행동마다 자율 수준이 다르다

기사의 두 번째 소제목은 “It’s about the action, not the agent”입니다. Rowe는 에이전트에게 모든 상황에서 완전한 자유를 주지 말고 선을 행동에 그으라고 말합니다. 같은 에이전트가 한 단계는 혼자 처리하고 다음 단계에서는 사람의 결재를 받는 구조입니다. 작동 방식은 단순합니다. 에이전트가 하려는 행동(입력)을 그 행동의 성격과 대조해(처리) 바로 실행할지, 승인을 기다릴지 정합니다(출력). Rowe는 오늘 거의 자율에 가깝게 맡길 수 있는 일로 읽기 위주의 작업을 듭니다. 데이터 수집, 분류(triage), 초안 작성, 선택지 비교입니다. Mushegian도 같은 워크플로 안에서 어떤 단계는 혼자, 어떤 단계는 승인을 받게 하라고 권합니다. 에이전트를 하나의 단위로 믿거나 못 믿는 이분법을 버리는 셈입니다. 워크플로가 한두 단계뿐이고 모두 읽기 작업이면 행동별 구분이 필요 없습니다. 아래 가상 예시는 IT 헬프데스크 에이전트 하나가 다섯 단계를 거치며 자율 수준이 바뀌는 모습입니다.

Consequence-based Evidence: 실수의 결과가 클수록 권한을 넓히기 전 더 많은 증거를 요구한다

Mushegian의 원칙은 실수의 결과가 권한을 늘리기 전에 필요한 증거의 양을 정한다는 것입니다. 행동마다 “틀리면 무슨 일이 생기나”를 먼저 묻습니다. 그 답이 무거울수록 자율을 주기 전에 더 긴 확인 기간과 더 많은 성공 기록을 요구합니다. 좋은 후보는 답이 문서로 잘 정리돼 있고 행동 범위가 좁으며 실수해도 쉽게 고칠 수 있는 일상적 사내 지원 요청입니다. 나쁜 후보는 접근 권한을 바꾸거나 운영 시스템을 고치는 에이전트입니다. 감사 대상 프로세스라면 사람의 책임이 하나도 남지 않는 운영은 아직 확신하지 못한다고 그는 말합니다. 자율은 한 부서 전체보다 그 안의 특정 작업을 맡은 에이전트에게 먼저 온다고 봅니다.

Reversible or Bounded: 되돌릴 수 있게 만들면 자율이 넓어진다

Rowe는 되돌릴 수 없는 행동에 언제 자율을 줄 수 있느냐는 질문에 AI 모델의 성능보다 조직이 각 행동을 얼마나 빨리 되돌릴 수 있게(reversible) 또는 범위가 묶이게(bounded) 만드느냐에 달렸다고 답합니다. 그가 든 장치는 네 가지입니다. 지출 한도(spending limit), 실행 전 취소할 수 있는 유예 기간(cooling-off period), 되돌리기(rollback), 그리고 실수를 되돌릴 만큼 자세한 감사 기록(audit trail)입니다. 행동에 이 장치가 붙으면 실수가 나도 피해가 한도 안에 머물고 원상 복구가 가능하므로 자율 범위를 넓힐 수 있습니다. 반대로 계약 서명이나 계좌에서 돈을 빼는 일처럼 되돌릴 수 없는 행동은 앞으로도 상당 기간 사람이 승인해야 한다고 봅니다. 가상 예시로, 구독 해지 에이전트에 “실행 24시간 전 고객 알림, 그 사이 취소 가능” 유예를 붙이면 해지 실행은 자율로, 위약금이 발생하는 해지는 승인으로 나눌 수 있습니다.

Delegated Authority Ceiling: 대신 일하는 에이전트는 맡긴 사람보다 큰 권한을 갖지 않는다

Walaszczyk의 핵심 원칙은 누군가를 대신해 움직이는 에이전트가 그 사람보다 큰 권한을 가지면 안 된다는 것입니다. 그는 이를 용기나 편안함의 문제가 아니라 설계의 문제로 봅니다. 설계 대상은 네 가지로 에이전트가 돌아가는 환경, 만질 수 있는 권한, 받는 지시, 그리고 감독입니다. 부서 전체를 에이전트에게 넘기지 말고 목표를 정의하고 경계를 정하고 결과를 확인할 수 있는 특정 프로세스만 위임하라고 권합니다. 고객 상담은 이미 통제를 넘기기 시작한 영역입니다. 사람이 준 지식으로 학습한 에이전트가 상시 감독 없이 문의에 답합니다. 그래도 감독은 진짜여야 합니다. 시간과 주의를 들여 결과를 확인하는 일이지 승인 버튼을 누르는 일이 아닙니다. 에이전트가 한 일이라고 사람의 책임이 사라지지도 않습니다.

Sandbox and Runtime Enforcement: 정책을 호출 경로에서 강제하고 권한이 슬며시 늘지 않게 막는다

Olsen은 자율 봇을 잘 정의된 정책이 있는 엄격한 sandbox(격리된 실행 환경)에 가두라고 권합니다. 정책을 문서로만 두지 않고 실행 순간에 강제하는 수단으로 API gateway, 운영체제(OS) 수준 차단, 자격 증명(credential) 관리를 듭니다. 정책은 특정 에이전트와 특정 용도에 묶어야 합니다. 기사는 두 가지 걱정도 전합니다. 하나는 autonomy creep(에이전트가 받은 것보다 많은 권한을 조용히 떠안는 현상)입니다. 다른 하나는 human-in-the-loop(사람이 중간에 확인하는 구조) 장치가 직원에게 에이전트의 실수를 고칠 권한이나 시간을 주지 못하는 경우가 있다는 AI·보안 전문가들의 경고입니다. Olsen은 지금 쓸 수 있는 해법이 일부 있지만 최소한의 신뢰에 닿으려면 더 일관된 전략이 필요하다고 봅니다. 민감 정보에 접근하지 않는 비핵심 업무가 가장 먼저 완전 자율을 얻고 신뢰가 쌓이면 범위가 넓어진다는 전망입니다.

통념과 다른 주장

저자가 든 사례

Barracuda Networks: 에이전트 약 2,000개, 그래도 사람이 확인한다

• 상황: 보안 기업 Barracuda Networks에는 에이전트가 약 2,000개 배포돼 있습니다. 감사 대상 프로세스도 있습니다.
• 한 일: 티켓 처리 자동화의 상당수를 trust-but-verify(믿되 확인하는) 방식으로 운영합니다. 에이전트가 다른 에이전트를 감독하는 구조입니다.
• 결과: 여전히 직원이 봇의 행동을 확인합니다. CIO Mushegian은 사람의 책임이 전혀 없는 운영에는 아직 확신이 없다고 말합니다. 자동화율이나 오류율 같은 수치는 기사에서 밝히지 않았습니다.
• 연결: Consequence-based Evidence, Action-level Autonomy.

Taupia: 요금제 전환은 에이전트가, 확정은 고객이

• 상황: 가정용 공과금 앱 Taupia가 에너지 요금제를 비교하고 공급사 전환을 돕는 일을 자동화하려 합니다.
• 한 일: 직원이 단계마다 승인하지 않아도 에이전트가 요금제를 비교하고 전환을 돕도록 시험하고 있습니다.
• 결과: 전환이 실제로 반영되기 전에 고객이 내용을 검토하고 확인합니다. 시험 규모와 성과 수치는 기사에서 밝히지 않았습니다.
• 연결: Action-level Autonomy, Reversible or Bounded.

개인용 완전 자율과 기업의 제한된 자율

• 상황: 개인 사용자 사이에서 Clawdbot, OpenClaw 같은 도구에 메일 전체 접근과 완전한 자율을 주는 일이 널리 퍼졌습니다. Olsen은 일부에게는 잘 됐지만 노출된 위험이 컸다고 봅니다.
• 한 일: 기업에서는 고객 환불이나 크레딧 처리처럼 제한된 영역에서 사람 개입 없이 처리하는 자율이 늘고 있습니다. Olsen은 이런 봇을 엄격한 sandbox 안에 두라고 권합니다.
• 결과: 제한된 자율은 이미 쓰이지만 기업이 에이전트에게 완전 자율을 주는 일은 가까운 시일 안에는 없다고 Olsen은 내다봅니다.
• 연결: Sandbox and Runtime Enforcement.

기술 디테일: 행동 단위 자율을 직접 구현한다면

아래 필드명, 설정값, 구성은 기사에 없는 실행 제안이자 가상 예시입니다. 연결된 원칙은 각 항목 첫 문장에 밝혔습니다.

행동 레지스트리부터 만듭니다(Action-level Autonomy, Reversible or Bounded). 에이전트가 아니라 행동을 레코드로 적습니다. 에이전트가 부를 수 있는 도구 호출 하나가 레코드 하나입니다. 자율 수준은 이 레코드에만 두고 프롬프트에는 두지 않습니다.

{
  "action_id": "refund.issue",
  "workflow": "고객 환불 처리",
  "effect": "write",
  "reversibility": "bounded",
  "consequence_tier": 2,
  "autonomy": "auto_within_limits",
  "limits": {"amount_krw_max": 100000, "per_customer_per_day": 1},
  "cooling_off_minutes": 0,
  "rollback_handler": "refund.reverse",
  "approver_role": "CS 팀장",
  "approval_sla_minutes": 60,
  "audit_fields": ["ticket_id", "amount", "reason", "evidence_refs"],
  "promotion_rule": {"min_runs": 300, "max_error_rate": 0.01, "zero_severe": true}
}

reversibility는 reversible(원상 복구 가능), bounded(한도 안에서만 피해), irreversible(되돌릴 수 없음) 셋으로 둡니다. irreversible이면 autonomy는 approve 또는 forbid만 허용하도록 스키마에서 막습니다. 계약 서명과 외부 송금이 여기에 들어갑니다. rollback_handler가 비어 있는 write 행동은 reversible로 등록할 수 없게 합니다.

판정은 게이트웨이의 규칙이 하고 LLM은 하지 않습니다(Sandbox and Runtime Enforcement). 에이전트는 도구를 직접 부르지 않고 API gateway를 거칩니다. 게이트웨이는 요청의 action_id로 레지스트리를 찾은 뒤 한도와 위임자 권한을 대조해 실행하거나 승인 큐로 보냅니다. 에이전트는 호출을 action_id, on_behalf_of, params, justification 네 필드의 구조화 출력(JSON)으로 냅니다. 스키마 검증에 실패하면 게이트웨이가 실행하지 않습니다. 위험 판단을 LLM에 맡기면 같은 요청에 다른 답이 나올 수 있으므로 판정 경로에는 모델을 넣지 않습니다. 실행이 끝나면 audit_fields를 채운 기록을 남기면서 rollback에 필요한 이전 상태를 함께 저장합니다.

권한은 교집합으로 계산합니다(Delegated Authority Ceiling). 에이전트가 누군가를 대신해 움직이면 요청에 on_behalf_of(위임자 ID)를 싣습니다. 게이트웨이는 에이전트 서비스 계정의 권한과 위임자의 현재 권한의 교집합만 허용합니다. 위임자가 퇴사하거나 권한이 줄면 에이전트 권한도 즉시 줄어듭니다. 자격 증명은 행동 하나 또는 세션 하나에만 유효한 짧은 토큰(예: 15분)으로 발급하고 장기 API 키를 에이전트 설정에 넣지 않습니다.

권한이 슬며시 느는 것을 감지합니다(autonomy creep). 매일 실행 로그를 레지스트리와 대조해 세 가지를 경보로 띄웁니다. 레지스트리에 없는 action_id 호출 시도, 한도 근처(예: 90% 이상) 실행의 급증, 승인 요청 없이 같은 결과를 내려는 우회(작은 금액으로 쪼갠 환불 여러 건)입니다. 거부된 호출도 기록해야 에이전트가 무엇을 시도했는지 보입니다.

자율은 단계로 올리고 올리는 기준은 결과 등급마다 다르게 둡니다(Consequence-based Evidence). 행동 하나는 shadow(추천만 하고 실행 안 함), 승인 후 실행, 한도 내 자율, 사후 표본 검토 순으로 올라갑니다. consequence_tier가 1인 행동은 예를 들어 50건 무사고면 다음 칸으로, 3인 행동은 500건과 심각 오류 0건을 요구하는 식입니다. shadow 단계에서는 에이전트 추천과 사람 결정이 일치한 비율을 행동별로 집계합니다.

승인 요청은 승인자가 실제로 판단할 수 있게 만듭니다(human-in-the-loop가 작동하려면). 승인 화면에 무엇을 하려는지, 왜 하는지, 바뀌는 값의 전후 비교, 되돌리는 방법, 승인 기한을 담습니다. 승인자가 수정하거나 거부할 권한이 있어야 합니다. 승인까지 걸린 시간을 기록합니다. 승인 시간이 몇 초에 몰리면 확인 없이 누르고 있다는 신호이므로 표본을 골라 다시 봅니다. Barracuda처럼 에이전트가 에이전트를 확인하게 할 때는 확인 에이전트를 다른 모델이나 다른 프롬프트로 두고 둘의 판단이 갈리면 사람에게 넘깁니다.

막히는 경우	증상	대응
승인 피로	승인 요청이 하루 수백 건, 몇 초 만에 승인	결과 등급 낮은 행동을 한도 내 자율로 올리고 승인은 무거운 행동에만
쪼개기 우회	한도 바로 아래 금액의 실행이 연속	고객·일자 단위 누적 한도 추가
rollback 실패	외부 시스템이 취소 API를 지원하지 않음	해당 행동을 irreversible로 재분류
위임자 권한 변경 미반영	퇴사자 명의로 에이전트가 계속 실행	호출마다 위임자 권한을 실시간 조회, 캐시 금지
레지스트리 밖 행동	새 도구를 붙인 뒤 등록 누락	미등록 action_id는 기본 거부

현업 실행 디테일: 누가, 언제, 무엇을

기사는 CIO와 CTO가 자율 범위를 정하고 직원이 봇 행동을 확인하며 고객이 최종 변경을 확인한다고 전합니다. 아래 역할, 일정, 기준은 이를 바탕으로 새로 짠 가상 예시입니다. 첫 대상은 Mushegian이 좋은 후보로 든 일상적 사내 지원 요청이나 Olsen이 든 환불·크레딧 처리처럼 답이 정리돼 있고 실수를 고치기 쉬운 워크플로가 좋습니다.

역할	맡는 일
AX 추진 리드	시범 워크플로 선정, 레지스트리 승인, 진행 판정
프로세스 오너(현업 팀장)	행동 목록 작성, 행동별 한도와 승인자 지정, shadow 결과 검토
승인자(현업 담당자 2~3명)	승인 큐 처리, 거부·수정 사유 기록
보안·IAM 담당	게이트웨이 정책, 짧은 토큰 발급, 권한 교집합, 이탈 감지 경보
감사·법무	되돌릴 수 없는 행동 목록 확인, 승인 기록이 감사에 쓸 만한지 점검
에이전트 개발자	도구 호출을 레지스트리의 action_id로 정리, rollback 핸들러 구현

준비물. 시범 워크플로의 최근 3개월 처리 기록(티켓 또는 환불 건), 단계마다 지금 누가 무엇을 승인하는지 적힌 결재 규정, 연결할 시스템별 취소·되돌리기 가능 여부, 위임자가 될 직원의 현재 권한 목록, 실수 사례와 복구에 걸린 시간이 필요합니다.

기간	할 일	산출물
1주	워크플로 하나의 행동 목록 작성, 행동마다 되돌림 가능 여부와 결과 등급 판정	행동 레지스트리 초안
2주	한도, 유예, rollback, 승인자·승인 기한 지정, 게이트웨이 정책과 토큰 설정	확정 레지스트리, 정책 설정
3주	shadow 운영(에이전트 추천과 사람 처리 병행), 승인 화면 시험	행동별 일치율, 승인 소요 시간
4주	판정 회의, 행동별로 자율 단계 올림·유지·내림 결정	행동별 자율 단계 결정서

현장에 물을 것.

1. 이 워크플로에서 실수가 나면 누가 알아채고, 되돌리는 데 얼마나 걸리나요?
2. 단계 가운데 한 번 실행하면 되돌릴 수 없는 것은 어느 단계인가요?
3. 지금 사람이 승인하는 단계에서 승인자는 실제로 무엇을 확인하나요?
4. 에이전트가 대신 일할 때 누구의 이름으로 기록돼야 하나요?
5. 감사에서 이 워크플로를 두고 물어 온 적이 있는 항목은 무엇인가요?

진행 판정 기준(예시). shadow에서 에이전트 추천과 사람 처리의 일치율이 해당 행동의 기준(예: 결과 등급 1은 95%, 2는 98%)을 넘고 레지스트리 밖 호출과 한도 초과 시도가 0건이면 그 행동만 다음 칸으로 올립니다. 일치율이 기준에 못 미치면 같은 칸에서 2주 더 봅니다. rollback이 시험에서 한 번이라도 실패한 행동은 irreversible로 다시 분류하고 사람 승인으로 내립니다.

AX 적용 제언. 에이전트 도입 결재를 “이 에이전트를 써도 되나”에서 “이 행동을 혼자 해도 되나”로 바꾸는 것이 첫걸음입니다. 지금 많은 조직이 에이전트 단위로 보안 심사를 하는데, 행동 레지스트리를 심사 단위로 삼으면 같은 에이전트의 읽기 작업은 바로 열고 쓰기 작업만 단계적으로 열 수 있습니다. 적용 순서는 IT 헬프데스크 1차 지원, 환불·크레딧, 고객 상담 답변처럼 되돌리기 쉬운 영역에서 시작해 구매 요청, 계약 갱신 같은 무거운 영역으로 갑니다. 권한 변경, 운영 시스템 변경, 계약 서명, 외부 송금은 레지스트리에서 처음부터 approve로 고정합니다. 현업 스폰서는 프로세스 오너가 맡아야 승인자가 시간을 냅니다. 승인 업무를 평가 항목에 넣지 않으면 승인은 버튼 클릭으로 끝나기 쉽습니다.

원문 사례

항목	내용
원문	CIO.com, 2026.11.5 게재, Grant Gross(선임 기자) 작성
조사 수치	KPMG Q3 AI Pulse(2026년 7~8월): 에이전트 구축·배포·개발 중인 IT 리더 62%, 직전 분기 53%
현재 자율 범위	1차 IT 지원 같은 단순·저위험 업무, 고객 환불·크레딧 처리, 고객 상담 답변
Jim Olsen (ModelOp CTO)	엄격한 sandbox와 정책, 런타임 통제(API gateway, OS 수준, 자격 증명 관리), 비핵심·비민감 업무부터 완전 자율
우려	autonomy creep, 승인자에게 권한·시간이 없는 human-in-the-loop
Siroui Mushegian (Barracuda Networks CIO)	에이전트 약 2,000개, trust-but-verify, 실수의 결과가 필요한 증거량을 정함, 권한 변경·운영 시스템 변경은 나쁜 후보
Joshua Rowe (Taupia 공동창업자·CTO)	선은 행동에, 읽기 위주 작업은 거의 자율, 요금제 비교·전환 에이전트 시험(확정은 고객), 지출 한도·cooling-off·rollback·audit trail
Maciej Walaszczyk (Text CTO)	에이전트 권한은 맡긴 사람 이하, 환경·권한·지시·감독의 설계, 부서 전체 위임 반대, 감독은 실제 확인
사람 승인으로 남길 것	계약 서명, 계좌에서 돈 이체, 결과가 크거나 되돌릴 수 없는 행동

핵심 개념

Agentic AI

사람이 단계마다 지시하지 않아도 목표를 받아 스스로 계획하고 도구를 호출해 행동하는 AI입니다.

Tier 1 IT support

비밀번호 재설정, 접속 문제처럼 정해진 절차로 처리하는 1차 IT 지원입니다. 어려운 건은 2차 이상으로 넘깁니다.

Trust-but-verify

일단 맡기되 결과를 따로 확인하는 운영 방식입니다. 기사에서는 에이전트가 다른 에이전트를 확인하는 구조로 나옵니다.

Autonomy creep

에이전트가 처음 받은 범위보다 많은 권한이나 행동을 조용히 떠안게 되는 현상입니다.

Cooling-off period

실행을 결정한 뒤 실제 반영 전까지 두는 유예 기간입니다. 그 사이 취소할 수 있습니다.

Audit trail

누가, 언제, 무엇을, 어떤 근거로 했는지 남긴 기록입니다. 실수를 되돌리고 감사에 답하는 데 씁니다.

API gateway

여러 서비스로 가는 호출을 한곳에서 받아 인증, 권한, 한도를 확인한 뒤 넘겨주는 관문입니다.

내 메모

TODO: 내 생각 추가

원문은 CIO.com의 「AI agent autonomy remains an elusive work in progress」(Grant Gross, 2026.11.5)입니다. KPMG 조사 수치와 네 사람의 발언은 기사에 실린 내용이며 사례 회사의 성과 수치는 기사에 나오지 않습니다. 요약, 핵심 메커니즘의 원문 설명, 통념과 다른 주장, 사례, 원문 사례 표는 기사 내용을 AX Review가 다시 정리했습니다. 핵심 개념의 뜻풀이는 일반적인 정의로 보탰습니다. 행동 레지스트리 JSON, 게이트웨이 판정 방식, 권한 교집합, 자율 단계 사다리, 막히는 경우 표, 역할·일정·판정 기준, 인포그래픽 속 헬프데스크·구독 해지·환불 예시는 기사에 없는 내용으로 새로 작성했고 그 안의 필드명과 숫자는 가상 예시입니다. 전체 내용은 원문 페이지에서 볼 수 있습니다.