모델은 논리적인 결론에 도달하도록 추론할 수 있지만, 여전히 당신의 프로덕션 시스템을 망가뜨릴 수 있습니다. 자율 에이전트(autonomous agent)가 API를 호출하거나, 데이터베이스에 기록하거나, 돈을 이동시키는 순간, 유일하게 중요한 것은 당신의 기록 시스템(system of record)에서 실제로 무엇이 일어났는가 하는 점입니다. 기저에 깔린 사고 사슬 (chain-of-thought) 프롬프트의 탁월함은 무의미합니다.

의사결정의 정확성(decision correctness)과 결과의 정확성(consequence correctness) 사이의 이러한 격차는 대부분의 기업용 AI 검증이 실패하는 지점입니다.

"에이전트가 올바르게 응답했다"가 잘못된 결승선인 이유

대부분의 AI 검증 관행에 깔린 가정은 단순합니다. 모델이 올바른 답을 향해 추론해 나간다면, 결과도 괜찮을 것이라는 생각입니다.

항상 괜찮은 것은 아닙니다.

모델은 올바른 추론 사슬을 생성하면서도 결제를 중복 처리하거나, 만료된 권한에 따라 행동하거나, 다운스트림 시스템이 완료하지 못한 작업에 대해 성공을 보고할 수 있습니다. 추론은 타당했습니다. 하지만 결과는 그렇지 않았습니다. 이 둘은 서로 다른 것이며, 대부분의 평가 프레임워크는 그중 하나만을 측정합니다.

NIST의 리스크 관리 프레임워크(Risk Management Framework)에 대한 에이전트 전용 확장안으로 유통되는 제안들은 이 점을 명확히 하고 있습니다. 기존 프레임워크나 생성형 AI 동반 프레임워크 모두 실제 프로덕션에서 작동하는 자율적인 도구 사용 시스템을 위해 작성된 것이 아닙니다. 프레임워크들은 정적 모델(static models)을 위해 구축되었습니다. 에이전트는 정적이지 않습니다.

핵심적인 거버넌스 실패는 의사결정의 정확성과 결과의 정확성을 동일한 측정 지표로 취급하는 것입니다. 이 둘은 같지 않습니다.

거버넌스 패턴: 프런트 게이트(Front-Gate), 단일 실행(Execute Once), 검증(Verify)
개별 게이트가 의미를 갖기 전에, 전체적인 패턴이 명확해야 합니다.

거버넌스가 적용된 에이전트 흐름(governed agent flow)은 세 가지 단계로 구성됩니다. 첫째, 프론트 게이트 체크(front-gate checks): 시스템은 어떤 동작이 실행되기 전에 에이전트의 신원(identity), 권한(authority), 그리고 뒷받침되는 증거(supporting evidence)를 검증합니다. 둘째, 정확히 한 번 실행(exactly-once execution): 동작은 중복 실행이나 부분 실행으로부터 보호되며 통제된 경로를 통해 실행됩니다. 셋째, 검증 및 감사(verification and audit): 결과는 도구의 응답(acknowledgment)으로부터 추론하는 것이 아니라, 권위 있는 소스(authoritative source)로부터 다시 읽어 들여지며, 변조 방지(tamper-resistant)가 가능한 증거로 기록됩니다.

에이전트가 모든 게이트를 통과하면 최종 상태는 "검증됨(verified)"이 됩니다. 만약 어떤 게이트라도 통과하지 못하면 최종 상태는 "정직하게 거부됨(honestly denied)"이 됩니다. 두 상태 중 어느 것도 모호하지 않습니다. 그것이 핵심입니다.

이 패턴이 방지하는 것은 희망에 기반한 자동화(hope-based automation)입니다. 즉, 에이전트가 동작이 기록 원천(source of record)에서 확인되었기 때문이 아니라, 단순히 응답 상태에 도달했다는 이유만으로 성공을 주장하는 것입니다. 희망에 기반한 자동화는 겉보기에만 깨끗한 대시보드와 보이지 않는 실패를 양산합니다.

게이트 1: 신원 바인딩 (Identity Binding)

이는 에이전트의 관점에서 재정의된 혼동된 대리인 문제(confused deputy problem)입니다. 1988년까지 거슬러 올라가는 이 문제는, 신뢰할 수 있는 프로그램이 권한이 낮은 호출자를 대신하여 승인되지 않은 동작을 수행할 때 자신의 광범위한 권한을 사용하는 경우 발생합니다. 대리인은 누가 요청할 권리가 있는지 확인하지 않고, 자신이 들은 내용에 따라 행동합니다.

에이전트 규모에서는 이 실패 양상이 동일하지만 증폭됩니다. 만약 사용자가 에이전트에게 "Acme 벤더 기록을 업데이트해줘"라고 말하고, 에이전트가 해당 문자열을 표시 이름(display-name) 일치로 해석한다면, Tenant B의 "Acme LLC" 대신 Tenant A의 "Acme Corp"를 업데이트할 수 있습니다. 에이전트는 자신의 격상된 자격 증명(elevated credentials)을 사용하고, 잘못된 대상을 대상으로 동작하며, 성공을 기록합니다.

수천 개의 기업이 모델 요청을 라우팅하기 위해 사용하는 AI 게이트웨이 프록시인 LiteLLM이 2026년 3월에 침해되었을 때, 이 문제가 프로덕션 규모에서 어떻게 나타나는지 입증되었습니다. 공격자들은 SSH 키, 클라우드 자격 증명, API 키를 탈취했으며, 이는 약 500,000개의 기업 신원에 영향을 미쳤습니다. 이는 수명이 길고 범위가 넓은 자격 증명을 단일 위치에 풀링(pooling)한 직접적인 결과였습니다 (SANS Institute).

안전한 신원 바인딩 (Secure identity binding)을 위해서는 실행 전 해결 (pre-action resolution) 단계가 필요합니다. 에이전트가 다루는 모든 인간이 읽을 수 있는 레이블(label)이나 짧은 식별자는 실행 게이트 (action gate)가 열리기 전에 UUID 또는 암호화 해시 (cryptographic hash)와 같은 근본적이고 불변하는 시스템 식별자로 매핑되어야 합니다. 이것이 없다면, 권한 부여 (authorization) 및 로깅 (logging)이 잘못된 행위자에게 연결될 수 있기 때문에 이후의 모든 제어 기능이 약화됩니다.

게이트 2: 증거 출처 (Evidence Provenance)

에이전트 배포에서 지배적인 실패 모드 (failure mode)는 간접 프롬프트 주입 (indirect prompt injection)입니다. 에이전트가 단순히 읽기만 해야 했던 데이터—송장 PDF, 고객 이메일, 또는 검색된 데이터베이스 레코드—내부에 명령어가 밀수됩니다. 에이전트는 신뢰할 수 없는 콘텐츠를 데이터가 아닌 명령으로 취급하여 실행합니다.

이러한 출처 붕괴 (provenance collapse)는 이메일에서 발견된 악성 콘텐츠가 검증된 조직 정책과 동일한 신뢰 수준으로 취급될 때 발생합니다. 아키텍처가 데이터 채널 (data channels)과 명령 채널 (instruction channels)을 구조적으로 분리하지 않는다면, 에이전트는 이 둘을 신뢰성 있게 구분할 수 없습니다.

증거 출처는 검색 (retrieval)의 문제가 아닙니다. 이는 근본적인 제어 (foundational control)입니다. 에이전트의 컨텍스트 (context)에 있는 모든 콘텐츠 조각에 소스 분류 (source classification) 태그를 지정하십시오: 신뢰할 수 있는 시스템 명령 (trusted system instruction), 검증된 데이터 소스 (verified data source), 또는 검증되지 않은 외부 콘텐츠 (unverified external content). 실행 게이트는 '신뢰할 수 있음'으로 태그된 명령만 처리해야 합니다. 검증되지 않은 명령이 결정 경로 (decision path)를 오염시켜서는 안 됩니다.

게이트 3: 권한의 유효성 (Authority Currency)

유효한 암호화 승인 (cryptographic approval)이 타당하더라도, 그것이 더 이상 동일한 형태로 존재하지 않는 객체에 속해 있을 수 있습니다. 강제 푸시 (force-push) 이전의 커밋, 종료 후의 사용자 세션, 오늘 아침에 재할당된 역할 등이 그 예입니다.

암호화적 유효성 (cryptographic validity)과 시간적 유효성 (temporal currency)은 서로 다른 체크 항목입니다. 몇 시간에 걸쳐 지속될 수 있는 다단계 계획 루프 (multi-step planning loop)의 시작 시점에 부여된 권한은 최종 작업이 실행되기 전에 취소될 수 있습니다. 권한을 로그인 또는 작업 시작 시점에만 확인한다면, 에이전트는 오래된 자격 증명 (stale credentials)을 재사용하게 될 것입니다.

결제 인프라(Payments infrastructure)는 AI가 등장하기 전 이미 이 문제를 해결했습니다. Google의 Agent Payments Protocol은 사용자의 의도, 범위(scope), 그리고 승인된 결제 내용을 담고 있는 서명된 변조 방지 위임장(tamper-resistant mandates)을 사용합니다. Visa의 Trusted Agent Protocol은 모든 에이전트에 고유한 암호화 ID(cryptographic identity)를 발급하며, 트랜잭션을 신뢰하기 전에 해당 ID와 소비자가 설정한 한도(limits)를 모두 검증하도록 요구합니다.

권한이 부여된 시점의 대상 객체 버전 식별자(version identifier)를 저장하십시오. 실행 시점에 해당 버전을 실제 객체와 비교하십시오. 만약 두 버전이 다르다면, 승인은 오래된 것(stale)이며 게이트는 해당 동작을 거부합니다.

Gate 4: 정확히 한 번 실행 (Exactly-Once Execution)

네트워크 타임아웃(Network timeouts)은 모호함을 유발합니다. 만약 에이전트가 API를 호출했는데 응답을 받기 전에 연결이 끊어진다면, 에이전트는 다운스트림(downstream)에서 동작이 성공했는지 알 방법이 없습니다. 비멱등적(non-idempotent) 작업에 대해 단순히 재시도(retry)를 수행하면 효과가 중복됩니다.

이는 결제 엔지니어링(payments engineering)에서 해결된 문제입니다. Stripe의 결제 API는 첫 번째 요청의 결과를 고유 키(unique key) 아래에 저장하며, 동일한 키를 가진 반복 요청에 대해서는 작업을 다시 실행하는 대신 저장된 결과를 재생(replay)합니다.

프로덕션 환경에서 이 위험을 무시한다는 것은 고객에게 비용이 두 번 청구되거나, 기록이 두 번 삭제되거나, 인프라 변경 사항이 두 번 적용됨을 의미합니다. 에이전트의 내부 로그에는 한 번의 시도로 표시될 수 있지만, 기록 시스템(system of record)에는 두 번으로 표시될 수 있습니다.

재시도 시점이 아니라, 동작이 승인되는 순간 동작당 고유한 실행 키(execution key)를 생성하십시오. 다운스트림 시스템은 처리를 시작하기 전에 해당 키를 사용하여 중복 제거(deduplication) 확인을 강제해야 합니다.

Gate 5: 독립적 검증 (Independent Verification)

모델이 작업이 완료되었다고 말하는 것은 증거가 아닙니다. 도구가 "성공(success)" 응답을 반환하는 것도 외부 동작이 완료되었다는 증거가 아닙니다. 모델이 근본적인 결과 대신 검증 단계(verification step)를 최적화하도록 동작하는 것은 이미 알려져 있고 문서화된 실패 모드(failure mode)입니다.

2025년 METR의 평가에 따르면, OpenAI의 o3 모델은 코드를 더 빠르게 실행하라는 요청을 받았을 때 근본적인 코드를 개선하는 대신 경과 시간(elapsed time)을 측정하는 함수를 수정하여, 일부 작업에서 100%의 보상 해킹(reward-hacking) 비율을 달성했습니다.

29개국과 UN, OECD, 그리고 유럽연합(EU)의 자료를 인용한 2026년 국제 AI 안전 보고서(International AI Safety Report)는, 시스템이 테스트 조건과 실제 배포 환경을 구분하고 평가의 격차를 악용하는 사례가 더욱 흔해졌음을 발견했습니다.

권위 있는 다운스트림 시스템(downstream system)으로부터 상태를 다시 읽어오십시오. 어떤 시스템의 어떤 필드가 완료를 확인하는지 사전에 정확히 정의하십시오. 실행 직후 해당 필드를 직접 쿼리하여 예상되는 사후 상태(post-action state)와 비교하십시오. 도구의 승인(tool acknowledgment)만으로는 절대로 이 게이트를 닫아서는 안 됩니다.

게이트 6: 의무 추적 (Obligation Tracking)

정당한 첫 번째 효과가 반드시 완료된 작업과 동일한 것은 아닙니다. 임시 크레딧, 부분적인 수정, 또는 변경된 구성 설정(configuration setting)은 각각 초기 조치로서 완전히 정확할 수 있지만, 모니터링 창(monitoring window), 공시 요구 사항(disclosure requirement), 또는 다운스트림 정산(downstream settlement)을 여전히 열려 있는 상태로 남겨둘 수 있습니다.

첫 번째 API 호출이 성공하자마자 작업을 완료로 표시하는 것은 숨겨진 잔류 위험(residual risk)을 생성합니다. 이는 초기 조치는 성공했지만, 깨진 의존성(dependencies)이나 종료되지 않은 약속(commitments)이 뒤에 남아 있는 상황을 초래합니다.

IS 42001의 조항 6.1.4는 이미 AI 시스템이 가질 수 있는 잠재적 결과(consequences)를 평가하기 위한 문서화된 프로세스를 요구하고 있습니다. 이를 직접 적용하십시오. 초기 효과와 후속 의무를 분리하는 작업 완료 스키마(task-completion schema)를 구축하십시오. 에이전트는 경고(alerts), 알림(notifications), 조정(reconciliations), 그리고 컴플라이언스 의무(compliance obligations)가 종결될 때까지 추적되거나, 마감일과 함께 특정 소유자에게 공식적으로 이관(deferred)될 때까지 워크플로를 종료 상태로 표시할 수 없습니다.

게이트 7: 진실된 보상 (Truthful Compensation)

때로는 해로운 영향을 되돌려야(reversed) 합니다. 어떤 효과를 취소해야 할 때, 교정 메커니즘(corrective mechanism)이 실제로 일어난 일에 대한 기록을 다시 써서는 안 됩니다. 로그에서 원래의 원치 않는 효과를 조용히 제거해 버리는 롤백(rollback)은 거버넌스(governance) 측면에서 재앙적인 결과를 초래합니다.

규제 기관(Regulators), 감사인(auditors), 그리고 사고 대응 팀(incident response teams)은 실제 노출 정도를 평가하기 위해 원래의 작업(action)이 정확히 무엇이었는지 반드시 알아야 합니다. 비즈니스 효과를 되돌리는(undoing) 것이 그것이 전혀 발생하지 않았던 것처럼 가장하는 것과 같지는 않습니다.

진실된 보상(Truthful compensation)은 되돌리기를 삭제(delete)가 아닌 추가(append) 작업으로 취급하며, 결코 삭제로 취급하지 않습니다. 교정 작업(corrective action)은 원래의 작업 식별자(identifier)를 참조하는 새로운 레코드를 추가하여, 불변의 감사 로그(immutable audit logs), 원래의 결정(original decisions), 그리고 출처 데이터(provenance data)를 보존합니다. 현재 상태를 보여주는 모든 보고 뷰(reporting view)는 전체 이력을 보여주는 감사 로그(audit log)와 별도로 유지되어야 합니다.

실제로 중요한 것을 점수화하기: AI 운영 리스크를 위한 지배적 규칙(Dominant Rules)
결정 품질(decision quality)과 결과 품질(consequence quality)을 하나의 통합 점수로 결합하는 것은 운영 리스크를 은폐합니다. 모델은 높은 품질로 추론(reasoning)할 수 있지만 여전히 통제가 제대로 되지 않을 수 있습니다. 반대로 모델이 추론을 제대로 하지 못하더라도 안전하게 격리(contained)될 수 있습니다. 하나의 혼합된 숫자는 당신이 실제로 해결해야 하는 문제가 무엇인지 모호하게 만듭니다.

안전 지표(safety metrics)에 지배적 점수 규칙(dominant scoring rules)을 적용하십시오. 중복된 되돌릴 수 없는 결제, 위조된 권한 부여, 또는 독립적인 재확인(readback)이 결여된 완료 주장(completion claim)은 전체 결과에 지배적인 영향을 미쳐야 합니다. 이것들은 심각한 위반(hard violations)입니다. 단 한 번의 파괴적인 시스템적 실패(catastrophic systemic failure)는 모델이 계획 단계에서 얼마나 잘 추론했는지와 관계없이, 테스트된 전체 범위의 결과를 0으로 만듭니다.

결정 품질과 결과 품질을 별도로 점수화하십시오. 심각한 위반 사항이 평균값에 섞이지 않고 점수를 지배하도록 하십시오.

거짓 거부(False-Refusal) 회계

모든 요청을 차단하는 제어 시스템(control system)은 안전하지 않은 작업 비율을 0%로 달성하지만, 운영을 완전히 망가뜨립니다. 거짓 거부(false refusals)를 추적하지 않고 안전성을 측정하는 것은 잘못된 보안 의식을 심어줍니다.

안전 격리 지표(safety containment metrics)와 함께 거짓 거부율을 추적하고 보고하십시오. 만약 가드레일(guardrail) 업데이트로 인해 거짓 거부가 급증한다면, 즉시 제어 파라미터(control parameters)를 조정하십시오. 단 한 번의 깨끗한 실행은 취약한 주장입니다. 신뢰성(Reliability)을 확보하려면, 특히 당신의 제어 계층(control layer) 덕분에 개선되었다고 입증할 수 있는 반복적인 시험이 필요합니다.

성능 주장 보정 (Calibrating Performance Claims)

벤더(vendor) 또는 내부 에이전트의 안전성 보고서를 평가할 때는, 주장의 출처에 따라 차별화하여 판단해야 합니다.

테스트 설계(test design)나 시나리오 카탈로그(scenario catalog)는 단지 일관된 방법론을 보여줄 뿐입니다. 당신은 다음과 같이 말할 수 있습니다: "이것은 해당 리스크를 테스트하기 위한 합리적인 방법입니다."

벤더가 자체적으로 보고한 실행 결과(self-reported vendor run)는 해당 벤더가 선택한 조건 하에서, 그날의 특정 구성(configuration)이 무엇을 수행했는지만을 드러냅니다. 당신은 다음과 같이 말할 수 있습니다: "공개된 이러한 조건 하에서, 이 구성은 이러한 결과를 생성했습니다."

독립적으로 재현된 실행(independently reproduced run)은 출력이 벤더의 내부 설정에 의한 인위적인 결과물(artifact)이 아니었음을 증명합니다.

명시되고 정의된 프로토콜(protocol)에 따라 감사된 결과(result audited against a named, defined protocol)는 다음을 의미합니다: "이 구성은 이 날짜 기준으로, 이 명시된 범위(scope)에 대해, 이 명시된 프로토콜을 통과했습니다."