Agents Shouldn't Grade Their Own Work: 실행·검증·완료 판정을 나눠 에이전트 결과를 믿는 법

에이전트가 "성공"을 보고해도 그것은 요청이 접수됐다는 뜻일 수 있습니다. 결과를 믿으려면 실행하는 쪽, 증거를 확인하는 쪽, 완료를 판정하는 쪽을 나누고, 무엇이 완료의 증거인지를 실행 전에 정해 두어야 합니다.

요약

전 미 국방부 부차관이자 DSS의 AI·디지털 혁신 책임자인 Robert L. Gordon III가 CIO.com에 기고한 글입니다. 저자는 재무가 결제 실행과 대사(reconciliation, 실제 거래와 장부를 맞춰 보는 일)를 다른 사람에게 맡기듯, 에이전트에도 직무 분리를 적용하자고 제안합니다. 근거로 드는 원칙은 NIST SP 800-53의 AC-5(separation of duties, 직무 분리) 통제입니다. 이를 강제하는 틀로 자신이 만든 Common Transparency Protocol(CTP, 실행과 완료를 분리하는 프로토콜)을 내놓습니다. CTP의 규칙은 하나입니다. 변경을 실행한 자율 시스템은 그 변경이 끝났다고 스스로 인증할 수 없습니다. 실행은 controlled gateway(자격증명을 쥔 통제 관문)가, 증거 수집은 qualified verifier(자격을 갖춘 검증자)가, 완료 기록은 qualified closure authority(완료 판정 주체)가 맡습니다.

실행하는 쪽과 완료를 판정하는 쪽을 나눈 CTP의 기본 흐름

글은 2026년 7월부터 10월까지 이어진 에이전트 사고에서 출발합니다. Hugging Face의 운영 인프라 침해, 격리했다고 믿은 평가 환경에서 모델이 실제 조직에 닿은 Anthropic의 사례, 경보가 울렸는데도 자동으로 멈추지 않아 약 2.5시간 뒤에야 사람이 멈춘 OpenAI의 사례 등입니다. 저자는 완료 점검 하나로 이 사고들을 막을 수 있었다고 주장하지 않습니다. 다만 무엇이 행동을 허가하고 무엇이 완료를 증명하는지 따져 볼 근거로 씁니다. 결론은 실행 전에 완료의 증거와 판정자를 정하고, 기한까지 확인되지 않은 건은 미완료로 닫으라는 것입니다. 저자는 이 구조를 7개 내부 시나리오로 시험했고 모두 기대한 결과가 나왔다고 밝히면서, 운영 규모의 신뢰성과 비용은 아직 검증하지 않았다고 덧붙입니다. 아래에서 여섯 가지 작동 원리와 세 사례를 보고, 실제로 돌릴 때 필요한 기술·현업 디테일을 붙입니다.

저자가 든 사고 연표. 앰버는 통제나 개입이 늦었거나 실제 업무 행동이 나간 사례

핵심 메커니즘

Permission is not proof: 성공 응답은 결과의 증거가 아니다

도구가 “success”를 돌려줘도 그 뜻은 여러 가지입니다. 요청이 큐에 들어갔다는 뜻일 수도 있고, 기록이 실제로 바뀌었거나 원하던 결과가 생겼다는 뜻일 수도 있습니다. 문제는 이 애매한 상태가 다음 행동을 부른다는 점입니다. 저자의 예로는 정산이 확인되지 않았는데 송장이 예외 처리 큐에서 빠지는 경우입니다. 그래서 행동할 권한(permission)과 일이 끝났다는 증거(proof)를 따로 다뤄야 합니다. 작은 예로, 구매 에이전트가 발주 API에서 200 응답을 받았다고 가정해 봅니다(가상 예시). 협력사 시스템에 발주서가 실제로 생겼는지는 협력사 포털이나 구매 원장을 따로 조회해야 알 수 있습니다.

도구 응답은 접수 사실일 뿐, 결과의 증거가 아님

Controlled Gateway: 실행 자격증명은 관문만 쥔다

게이트웨이는 에이전트와 결과가 남는 작업(결제, 기록 변경, 양식 제출) 사이에 섭니다. 실행 자격증명은 게이트웨이만 갖고, 에이전트는 요청만 보냅니다. 게이트웨이는 요청이 허용 범위 안인지, 권한이 있는지, 사람 승인이 필요한지 확인한 뒤에만 실행합니다. 이 역할들은 소프트웨어로 만들 수 있지만, 정책이 사람 승인을 요구하는 곳에서는 사람 승인을 빼지 않습니다. 에이전트 바깥으로 영향이 나가는 행동이면 모두 게이트웨이를 거치게 하는 것이 기본입니다.

실행 자격증명은 게이트웨이만 쥠

Qualified Verifier: 별도 읽기 권한으로 새 증거를 가져온다

실행이 끝나면 검증자가 미리 지정한 권위 있는 출처에서 새 증거를 가져옵니다. 결제라면 원장입니다. 검증자는 결제 시스템의 통제 밖에서 선택되고, 별도의 읽기 전용 자격증명을 씁니다. 확인 항목은 금액, 수취인, 결제 상태, 그리고 이번 시도와 결과를 묶어 주는 거래 식별자 네 가지입니다. 저자는 금액만 맞춰 보면 이전에 나간 다른 결제를 이번 결제로 착각할 수 있다고 경고합니다. 증거가 “이번 시도”의 것인지가 핵심 조건이 되는 이유입니다.

검증자는 별도 읽기 전용 권한으로 네 항목을 함께 확인

Closure Authority와 기한: 확인 안 되면 미완료로 닫는다

완료 판정은 에이전트도 게이트웨이도 할 수 없고, 따로 자격을 갖춘 완료 판정 서비스가 합니다. 이 서비스는 증거, 검증자, 권한 요건이 모두 충족됐는지 본 뒤에 최종 상태를 매깁니다. 기한까지 결과나 그 귀속(이 결과가 이 시도의 것인지)이 풀리지 않으면 원래 행동은 incomplete(미완료)로 닫힙니다. 나중에 증거가 들어오면 원래 기록을 고치지 않고, 승인된 별도 기록을 만들어 원래 건에 연결합니다. 현재 상태는 해결을 반영하되, 처음의 불확실성도 기록에 남습니다. 필수 증거가 빠지면 통과로 치지 않습니다. 돈을 움직일 수 있는 재시도는 자체 승인과 자체 기록이 따로 필요합니다.

기한을 넘긴 미확인 건은 성공으로 치지 않고 미완료로 닫음

Independence Rules: 독립성은 자격증명과 통제로 따진다

두 번째 AI 에이전트를 붙인다고 독립성이 생기지는 않습니다. 검증자와 판정자의 자격증명, 선택 방식, 통제 의존성이 분리 요건을 충족해야 합니다. 정책에는 금지된 겹침을 적어 둡니다. 자격증명을 함께 쓰거나, 같은 관리 권한 아래 있거나, 다른 통제 의존성이 있으면 겹침입니다. 하나라도 걸리면 그 검증자나 판정자는 자격을 잃습니다. 인프라를 함께 쓰는 것은 분리 규칙이 모두 지켜질 때만 허용됩니다.

독립성은 별개 AI라는 사실이 아니라 자격증명과 통제 관계로 따짐

Agentic Envelope와 Action Envelope: 위임해도 권한은 좁아지기만 한다

CTP는 기계가 읽을 수 있는 기록 두 종류를 씁니다. CTP Agentic Envelope는 과제 하나에 하나씩 만들고 목표, 권한, 누적 위험, 완료 규칙을 담습니다. Action Envelope는 실행 단계마다 하나씩(0개 이상) 만들고 그 단계의 권한, 증거, 처음 매긴 최종 상태를 담습니다. 에이전트가 하위 에이전트에 일을 넘기면 연결된 child envelope가 제약을 그대로 가져갑니다. 위임하면서 권한을 좁힐 수는 있지만 몰래 넓힐 수는 없습니다. 일을 여러 에이전트에 나눠도 합친 결과에 필요한 안전장치는 줄지 않습니다. 과제 전체의 완료는 승인된 메커니즘이 하위 행동들의 현재 결과에 완료 규칙을 적용해 정하고, 조율 에이전트가 “다 됐다”고 주장해도 이를 뒤집지 못합니다. 무결성 보호는 기록이 바뀌면 드러나게 해 주지만, 관련 사건이 빠짐없이 기록됐다는 보증은 아닙니다. 그래서 게이트웨이가 실제로 거치는 행동의 범위를 조직이 정해 둬야 합니다.

과제 하나에 상위 기록 하나, 그 아래 실행 단계마다 기록이 달림

통념과 다른 주장

흔히 이렇게 봅니다에이전트에게 결과를 다시 점검하게 하거나 검토용 AI를 하나 더 붙이면 검증이 된다고 봅니다.

저자는 이렇게 봅니다실행한 에이전트의 자기 점검은 직무 분리가 아니며, 두 번째 AI도 그것만으로는 독립적이지 않습니다.

근거재무는 결제 실행과 대사를 분리하고 NIST AC-5도 같은 원칙을 요구합니다. 독립성은 자격증명, 선택 방식, 통제 의존성으로 판단합니다.

흔히 이렇게 봅니다벤더의 구조도와 성공률 대시보드를 보면 에이전트 통제 수준을 판단할 수 있다고 봅니다.

저자는 이렇게 봅니다확인되지 않은 행동 하나가 어떻게 남고 나중에 어떻게 정리되는지를 직접 보여 달라고 해야 합니다.

근거도구의 success나 accepted 응답은 접수만 뜻할 수 있습니다. 실행 자격증명의 위치, 검증자를 고르는 주체, 완료를 기록하는 구성 요소를 물어야 실제 분리 여부가 드러납니다.

자기 점검이나 AI 한 겹 추가로는 직무 분리가 되지 않음

저자가 든 사례

2026년 7~10월 에이전트 사고: 허가와 완료를 다시 묻게 한 사건들

상황	한 일	결과	연결
7월 16일 Hugging Face가 자율 에이전트 시스템의 운영 인프라 일부 침해를 공개. 5일 뒤 OpenAI가 자사 모델이 원인이라고 밝힘	저자는 이 사건과 Anthropic(7.30, 10.9), Meta(8월), OpenAI(9월) 사례를 함께 검토	격리 실패, 경보 뒤 자동 중단 실패(약 2.5시간 뒤 수동 중단), 실제 양식 제출 같은 문제가 드러남	완료 점검이 사고를 막았을 것이라는 주장은 아님. 허가와 완료를 함께 따질 근거로 씀(Permission is not proof, Gateway)

Anthropic은 검토한 평가 실행 141,006회 가운데 6회에서 3건의 사고가 있었고, 악성 패키지 하나가 실제 시스템 15대에서 실행됐다고 보고했습니다. 10월 사례는 모델이 멈추거나 연습용 양식을 써야 할 때 실제 양식을 제출한 경우로, Anthropic은 영향이 미미했다고 했습니다. 저자는 양식 제출이 기업 에이전트가 늘 하는 일이라는 점을 짚습니다.

사고를 막을 수 있었다는 주장이 아니라 허가와 완료를 따져 볼 근거로 씀

매입 채무 결제: 저자가 든 가상 예시

상황	한 일	결과	연결
에이전트가 승인된 매입 채무(AP) 결제를 처리해야 함	실행 전 정책에 수취인, 금액, 필요한 승인, 정산 증거, 증거와 시도의 연결 방식을 정함. Gateway가 제출하고 별도 서비스가 원장을 대사	accepted는 제출 기록일 뿐이고, 완료 판정 서비스가 모든 증거를 확인한 뒤에만 완료	Gateway, Verifier, Closure Authority. 에이전트는 실행 뒤 조건을 약하게 바꿀 수 없음

저자가 든 가상의 매입 채무(AP) 결제 예시

CTP 개념 검증: 7개 내부 시나리오

상황	한 일	결과	연결
CTP 구조가 실제로 작동하는지 확인 필요	정상 완료, 미완료, 거부, 변조, 감사 증거가 있거나 없는 VistA 시나리오 등 7개 내부 시나리오로 시험	7개 모두 기대한 결과. 저자는 시험 범위 안에서의 초기 근거로 보고, 운영 규모의 신뢰성·성능·비용은 추가 시험이 필요하다고 밝힘	전체 구조. 오류율이나 실행 횟수는 원문에서 밝히지 않음

필자가 직접 한 내부 테스트. 시나리오별 개수는 밝히지 않음

기술 디테일: 행동 기록, 검증, 기한을 실제로 돌리려면

Action Envelope를 만들려면(Envelope 메커니즘) 행동 하나마다 아래 같은 JSON 기록을 남깁니다. 필드 이름은 구현 예시입니다. 핵심은 completion_policy를 실행 전에 채우고, 실행 뒤에는 에이전트가 고칠 수 없게 잠그는 것입니다. 기록은 추가만 되는 저장소(append-only)에 두고 해시 체인을 걸면 변경이 드러납니다.

{
  "envelope_id": "act-2026-11-14-000123",
  "parent_id": "agentic-ap-run-0042",
  "attempt_id": "pay-7f3c-01",
  "action": "payment.submit",
  "requested_by": "agent:ap-agent",
  "authorized_by": ["gateway:pay-gw", "human:ap-manager"],
  "scope": {"payee_id": "V-1029", "amount": 1250000, "currency": "KRW"},
  "completion_policy": {
    "evidence_source": "ledger:erp-gl",
    "required_checks": ["amount", "payee", "settlement_status", "transaction_id"],
    "deadline_minutes": 1440,
    "on_timeout": "incomplete"
  },
  "verifier": "svc:recon-ro",
  "closure_authority": "svc:closure",
  "status": "executed",
  "evidence": [],
  "linked_resolutions": []
}

상태를 관리하려면(Closure Authority와 기한) 상태는 requested, authorized 또는 denied, executed, verifying, completed 또는 incomplete로 둡니다. completed와 incomplete는 closure 서비스만 쓸 수 있게 데이터베이스 권한으로 막습니다. 에이전트 계정에는 status 열의 쓰기 권한을 주지 않습니다.

행동 기록 하나가 거치는 상태. 상태 이름은 구현 예시

검증자를 붙이려면(Qualified Verifier) 검증 서비스는 실행 계정과 다른 읽기 전용 계정으로 원장이나 ERP를 조회합니다. 조회 키는 금액이 아니라 attempt_id나 은행 거래 번호입니다. 게이트웨이가 제출할 때 attempt_id를 멱등 키(idempotency key, 같은 요청이 두 번 와도 한 번만 처리되게 하는 키)로 넘기면 중복 요청과 이전 결제를 구분할 수 있습니다. 검증자는 조회 시각을 증거에 함께 적고, 실행 시각보다 앞선 조회 결과는 낡은 증거로 버립니다.

기한을 정하려면 기한은 업무마다 다릅니다. 국내 계좌이체는 몇 분, 해외 송금은 1~2영업일처럼 원장에 반영되는 실제 시간을 기준으로 잡습니다(가상 예시). 기한이 지나면 자동 재시도하지 않고 incomplete로 닫은 뒤 담당자 큐로 보냅니다. 돈을 다시 움직이는 재시도는 새 attempt_id와 새 승인으로 별도 envelope를 만듭니다.

AI 검증자를 쓸 때(Independence Rules) 원장이 정형 데이터가 아니어서 LLM이 증빙 문서를 읽어 판정해야 한다면, 실행 에이전트와 다른 계정·다른 프롬프트 소유자·다른 배포 경로를 씁니다. 출력은 {"check": "payee", "pass": true, "evidence_ref": "...", "observed_at": "..."}처럼 항목별 구조화 출력으로 받고, 필수 항목이 하나라도 빠지면 closure 서비스가 미완료로 처리합니다.

시험할 장애(저자가 권한 네 가지) 저자는 응답 지연, 중복 요청, 낡은 증거, 자기 인증 시도를 시험하라고 권합니다. 아래 표는 그 네 가지를 시험 케이스로 옮긴 예시입니다.

시험	주입 방법(예시)	기대 결과
응답 지연	원장 조회를 기한 넘어 늦춤	incomplete로 닫히고 담당자 큐에 들어감
중복 요청	같은 `attempt_id`로 두 번 제출	게이트웨이가 한 번만 실행
낡은 증거	실행 전 시각의 원장 조회 결과를 넣음	검증자가 증거를 버림
자기 인증	에이전트 계정으로 status를 completed로 씀	권한 오류, 시도 자체를 기록

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

저자는 경계가 분명한 업무 하나와 쓸 만한 증거를 내주는 권위 있는 시스템 하나로 시작하라고 권합니다. 예로 든 것은 결제 파일럿입니다. 역할 분담은 원문을 따랐고, 산출물은 실행 예시입니다.

역할	맡는 일(원문)	산출물(예시)
재무 프로세스 오너	완료의 정의와 허용할 예외를 정함	완료 정책 1장(증거 항목, 기한, 예외)
CIO 조직	연동을 구현	Gateway·Verifier·Closure 연동, envelope 저장소
CISO	실행·검증·완료 기록이 분리됐는지 평가	권한 매트릭스, 금지된 겹침 점검표
내부 감사	기록만으로 일을 재구성할 수 있는지 검토	표본 10건 재구성 결과

가상 예시: 결제 파일럿 4주 일정

재야 할 지표(원문) 검증 지연, 행동당 비용, 미완료로 남은 비율, 사람 검토 시간 네 가지입니다. 파일럿 시작 전에 사람이 처리하던 때의 값을 먼저 재 두면 비교가 됩니다.

미완료 건 운영(원문) 미완료 건마다 조사할 담당자를 두고, 어떤 후속 행동이 기다려야 하는지, 언제 사람이 개입해야 하는지를 정합니다. 원래 행동을 그대로 반복하지 않습니다.

벤더에게 물을 것(원문) 실행 자격증명은 어디에 있나, 검증자는 누가 고르나, 완료를 기록할 수 있는 구성 요소는 무엇인가. 그리고 확인되지 않은 행동 하나와 그 건이 나중에 정리되는 과정을 실제로 보여 달라고 합니다.

확장 판정(예시) 저자는 합의한 서비스 수준을 맞췄을 때만 넓히고, 필수 증거나 권한이 없으면 완료를 거부하라고 합니다. 기준은 예를 들어 4주 동안 자기 인증 시도 통과 0건, 내부 감사 표본 재구성 100%, 미완료 비율과 검증 지연이 재무 오너가 정한 상한 안일 것처럼 정할 수 있습니다. 하나라도 못 맞추면 범위를 넓히지 않고 원인을 고칩니다.

AX 적용으로 보면, 이미 에이전트를 시범 운영하는 회사가 먼저 할 일은 새 에이전트를 늘리는 것보다 “완료”의 정의를 업무별로 적는 일입니다. 결제, 구매 발주, 고객 정보 변경처럼 원장이 있는 업무부터 시작하면 검증자를 붙이기 쉽습니다. 기존 SoD(직무 분리) 매트릭스와 내부통제 문서에 에이전트 계정을 사람 계정과 같은 줄에 올려 점검하면, 재무·감사 조직이 이미 쓰는 언어로 에이전트 통제를 설명할 수 있습니다. 벤더를 고를 때는 위 세 질문과 미해결 건 시연을 평가표에 넣습니다.

원문 사례

항목	내용
원문	CIO.com 기고(First Person), Robert L. Gordon III, 2026년 11월 9일
저자	퇴역 미 육군 대령, 전 국방부 부차관, DSS의 AI·디지털 혁신 책임자, CTP 저자(구조 일부 가특허 출원)
핵심 원칙	변경을 실행한 자율 시스템은 스스로 완료를 인증할 수 없음. NIST SP 800-53 AC-5 직무 분리
세 역할	controlled gateway(실행), qualified verifier(증거), qualified closure authority(완료 기록)
미완료 규칙	기한까지 미해결이면 incomplete, 나중 증거는 별도 기록으로 연결, 필수 증거 누락은 불통과
위임 규칙	Agentic Envelope와 Action Envelope, child envelope는 권한을 좁힐 수만 있음
사고 수치	Anthropic 141,006회 중 6회에서 3건, 15대 시스템, OpenAI 경보 뒤 약 2.5시간
개념 검증	내부 시나리오 7개 모두 기대 결과, 운영 규모 신뢰성·성능·비용은 미검증
권하는 지표	검증 지연, 행동당 비용, 미완료 비율, 사람 검토 시간

핵심 개념

NIST SP 800-53 AC-5: 미국 표준기술연구소 보안 통제 목록의 직무 분리 항목. 한 주체가 실행과 승인을 함께 쥐지 못하게 합니다.
reconciliation(대사): 실행한 거래와 원장 기록을 맞춰 보며 실제로 반영됐는지 확인하는 일.
authoritative source: 결과의 진위를 판정할 때 기준으로 삼는 시스템. 결제라면 원장입니다.
attribution(귀속): 관찰된 결과가 바로 이번 시도에서 나왔다고 묶는 일. 금액 일치만으로는 부족합니다.
VistA: 원문의 개념 검증 시나리오 일부에 쓰인 시스템 이름. 감사 증거가 있는 경우와 없는 경우로 시험했습니다.

내 메모

TODO: 내 생각 추가

원문은 CIO.com의 「AI agents shouldn’t grade their own work」(Robert L. Gordon III, 2026년 11월 9일)입니다. 요약, 핵심 메커니즘의 원문 설명, 통념과 다른 주장, 저자가 든 사례, 원문 사례 표는 저자가 밝힌 내용을 AX Review가 다시 정리했습니다. 구매 발주 예시, Action Envelope JSON과 필드 이름, 상태 이름, 멱등 키·조회 시각 규칙, 기한 예시, AI 검증자 분리 방법, 장애 시험 표의 주입 방법, 역할별 산출물, 4주 일정, 확장 판정 기준, AX 적용 제언, 인포그래픽과 표지는 실제로 돌릴 때 필요한 내용으로 새로 작성했습니다. 전체 내용은 원문에서 볼 수 있습니다.