증거 검증(Evidence verification)은 대부분의 AI 플랫폼이 한 번도 통과해 보라고 요구받지 못한 테스트입니다. 즉, 해당 플랫폼을 신뢰하지 않는 사람이 플랫폼이 생성한 결과물을 신뢰할 수 있는가 하는 문제입니다. 두 개의 AI 플랫폼은 동일한 로그(logs), 동일한 대시보드(dashboards), 그리고 동일한 감사 내보내기(audit exports)를 생성할 수 있습니다. 그중 하나는 증거를 생성한 것이고, 다른 하나는 자신에 대한 매우 설득력 있는 이야기를 만들어낸 것입니다. 이 차이는 벤더 데모(vendor demo)에서는 보이지 않습니다. 플랫폼의 협조 없이 누군가가 특정 결정 사항을 검증하려고 시도하는 날, 그리고 그 기록이 스스로 존재할 수 없다는 사실을 발견하는 날에야 비로소 드러납니다.

evidence verification — authority capture and independent verification versus a runtime-dependent evidence claim

You Bought an Observability Layer. You Needed an Evidence Layer는 범주 오류(category mistake)를 확립했습니다. 조직들은 텔레메트리(telemetry)를 구매하고 그것이 증거라고 가정했습니다. 이 글은 그보다 더 심각한 문제에 관한 것입니다. 그 간극을 메웠다고 믿는 조직들 — 즉, 서명된 기록과 불변의 로그(immutable logs)를 가리킬 수 있는 "증거 계층 (evidence layer)"을 구매한 조직들조차 — 애초에 권위 있는 증거를 포착하지 못한 경우가 빈번합니다. 범주 오류가 조달(procurement)의 실패라면, 이것은 진본성(authenticity)의 실패입니다. 이는 아티팩트(artifacts)가 실제로 존재하기 때문에 파악하기가 더 어렵습니다. 단지 그것들을 만든 시스템을 신뢰하지 않고서는 그 아티팩트들을 신뢰할 수 없을 뿐입니다.

무결성(Integrity)은 진본성(Authenticity)이 아니다

대부분의 엔지니어링 팀은 해싱(hashing) 단계에서 멈춥니다. 기록이 서명되고, 서명이 저장되면, 암호학적 무결성(cryptographic integrity)이 증거 문제를 해결한다고 가정합니다. 그것은 문제의 절반만을 해결할 뿐입니다.

무결성(Integrity)은 기록이 작성된 이후에 변경되었는지 여부에 답합니다. 해시 체인(hash chain), 서명(signature), 불변 로그 항목(immutable log entry) — 이 모든 것들은 당신이 지금 보고 있는 바이트가 과거 어느 시점에 저장되었던 바로 그 바이트와 동일하다는 것을 증명합니다. 그것은 실제적인 속성(property)이며 중요합니다. 하지만 이는 해당 기록이 애초에 권위(authoritative)가 있었는지에 대한 문제와는 완전히 다른 문제입니다.

인증(Authenticity)은 기록이 정확하고 완전했는지, 그리고 우연히 무언가를 기록하고 있었던 인접 시스템들로부터 사후에 재구성된 것이 아니라 실제 결정이 발생한 순간에 포착되었는지에 대해 답합니다. 해시 체인으로 재구성된 기록과 해시 체인으로 구성된 충실한 기록은 무결성 검사(integrity check)만으로는 구별할 수 없습니다. 둘 다 통과합니다. 하지만 그중 하나만이 증거 검증 등급(evidence-verification-grade)에 해당합니다.

인증은 축적되지 않는다

대부분의 AI 인프라 프로그램이 가진 본능은 기록이 다운스트림(downstream)으로 이동함에 따라 증거 품질이 향상된다는 것입니다. 로그를 수집하고, 집계하고, 서명하고, 보관하고, SIEM을 통해 실행하는 식입니다. 각 단계가 보증(assurance)을 더해주는 것처럼 느껴집니다.

진본성 (Authenticity)은 그런 방식으로 작동하지 않습니다. 그것은 이벤트가 생성되는 순간에 존재하거나, 아니면 아예 존재하지 않는 것입니다. 프레임워크 #151 인프라 증거 격차 (Infrastructure Evidence Gap)는 인프라 변경 사항에 대해 이미 이 순간을 명명했습니다: 인증 이벤트 (Authorization Event) — 즉, 정체성 (identity), 권한 (authority), 정책 상태 (policy state)가 행위 그 자체와 함께 캡처되는 개별적이고 타임스탬프가 찍힌 지점입니다. #151의 6단계 체인은 승인된 의도 (Approved Intent) → 인증 이벤트 (Authorization Event) → 서명된 계획 아티팩트 (Signed Plan Artifact) → 정책 상태 스냅샷 (Policy State Snapshot) → 실행 기록 (Execution Record) → 증거 아티팩트 (Evidence Artifact)로 이어집니다. 인증 이벤트 이후의 모든 단계는 하류 프로세싱 (downstream processing)입니다. 그 어떤 것도 발생하지 않은 인증 이벤트를 만들어낼 수 없습니다.

이 글은 #151이 인프라 변경 사항에 대해 던지는 것과 동일한 질문을 AI 실행에 적용하여 묻습니다: 만약 모델이나 에이전트가 행동한 순간에 정체성, 권한, 정책 상태, 그리고 행위가 함께 캡처되지 않았다면, 사후에 수행되는 그 어떤 보관 (retention), 서명 (signing), 또는 집계 (aggregation)도 그 순간을 재현할 수 없습니다. 실행 경로 (execution path)는 이 네 가지 조건이 공존할 수 있는 유일한 장소입니다. 그 하류에 있는 모든 시스템은 이미 이벤트 자체가 아니라 이벤트의 재현된 표현 (representation)을 바탕으로 작동하고 있습니다.

동일한 요구 사항이 AI 실행 경로에서도 나타납니다. 인증 추적 (An authorization trail)은 결정이 행사되는 순간에 권한이 캡처될 때만 존재하며, 인접한 텔레메트리 (telemetry)로부터 사후에 재구성되는 것이 아닙니다.

재구성이 증거가 될 수 없는 이유

이 차이점은 나란히 놓고 볼 때 가장 쉽게 확인할 수 있습니다.

감사 추적 (audit trail) 항목은 다음과 같이 보입니다: "사용자 X가 변경을 승인함, 기록 시점에 캡처됨, 승인 시점에 서명됨." 이것이 바로 증거입니다. 즉, 인증 이벤트 (Authorization Event)가 중요했던 순간에 권한 컨텍스트 (authority context)를 가졌던 시스템에 의해 생성된 개별적인 아티팩트 (artifact)로서 존재하는 것입니다.

재구성(reconstruction)은 다음과 같은 형태를 띱니다: "우리는 티켓이 존재했고, 역할(role)이 존재했으며, 승인 워크플로우(approval workflow)가 완료되었고, 로그상 승인이 발생한 것으로 보이므로 사용자 X가 변경 사항을 승인했다고 믿습니다." 이 문장의 모든 절은 사실입니다. 하지만 그 중 어느 것도 증거(evidence)는 아닙니다. 그것은 단일 권한 부여 이벤트(authorization event)를 공동으로 증명하도록 설계된 적이 없는 인접 시스템들로부터 구축된 추론(inference)입니다. 이는 정확히 권한 체인 불투명성 (Authority Chain Opacity), 즉 에이전트 도구 체인(agentic tool chains)에 대한 Framework #141의 실패 상태의 형태입니다. 즉, 실행 시점에 생성된 적이 없기 때문에 실행 후 권한 이동(authority movement)을 재구성할 수 있게 해주는 증거 아티팩트(evidence artifact)가 존재하지 않는 것입니다.

이는 권한 경계가 붕괴될 때 (authorization boundaries collapse) 나타나는 것과 동일한 실패 패턴입니다. 조직은 결정 경로(decision path)를 설명할 수는 있지만, 해당 결정이 일어난 순간 실제로 누가 권한을 보유했는지는 증명할 수 없다는 사실을 깨닫게 됩니다.

audit trail evidence versus reconstructed evidence — one path solid, one path dashed

이것은 대부분의 AI 플랫폼이 인지하지 못한 채 빠지는 함정입니다. 재구성된 내용은 철저해 보입니다. 네 개의 별도 시스템을 인용합니다. 마치 실사(due diligence)를 수행한 것처럼 들립니다. 하지만 그것은 증거가 아니며, "증거처럼 들리는 것"과 "증거인 것" 사이의 간극이야말로 감사(audit), 규제 조사(regulatory inquiry), 또는 사고 조사(incident investigation)가 답변 수용을 거부하는 바로 그 지점입니다. 증거 검증(evidence verification)은 외부인이 발견하기 전에 바로 이 간극을 잡아내기 위해 존재합니다.

2부 구성의 증거 검증 테스트

Framework #149의 네 번째 구성 요소인 아티팩트 휴대성 (Artifact Portability)은 이러한 개념이 설계자가 실제로 테스트할 수 있는 구체적인 대상으로 전환되는 지점입니다. 만약 어떤 아티팩트 (artifact)를 해석하거나 검증하기 위해 라이브 시스템 (live system)이 계속 가용 상태여야 하거나, 해당 아티팩트를 생성한 시스템을 믿어야만 한다면, 그것은 증거가 아닙니다. 이 기준은 두 가지의 별개이며 순차적인 테스트로 나뉩니다.

테스트 1 — 권한 캡처 (Authority Capture) — 플랫폼이 권한이 행사되는 바로 그 순간에 권한 있는 아티팩트를 발행했는가? 즉, 신원 (identity), 권한 (authority), 정책 상태 (policy state)가 사후에 인접 로그로부터 조립된 것이 아니라, 동작과 함께 동시에 캡처되었는가?

테스트 2 — 독립적 검증 (Independent Verification) — 제3자가 해당 아티팩트를 생성한 런타임 (runtime)을 신뢰하지 않고도 검증할 수 있는가? 즉, 라이브 시스템에 대한 접근 권한도, 벤더가 주장하는 무결성도 필요 없으며, 플랫폼이 운영 상태를 유지하거나 정직할 것이라는 의존성도 없는가?

두 테스트 중 하나라도 통과하지 못하면 해당 아티팩트는 운영 기록 (operational record)일 뿐, 증거가 아닙니다. 두 가지를 모두 통과해야만 자격이 주어집니다. 대부분의 현재 AI 플랫폼은 테스트 1을 느슨한 형태로 통과합니다. 즉, 실행 시간 근처 어딘가에서 일부 권한 컨텍스트 (authority context)가 캡처되기는 합니다. 하지만 테스트 2는 조용히 실패합니다. 감사인 (auditor)이 나타나기 전까지는 아무도 두 번째 질문을 던지지 않기 때문입니다. 촬영 후 미디어가 조작되지 않았음을 증명한다는 완전히 다른 문제를 위해 구축된 C2PA 콘텐츠 출처 (content provenance) 표준도 동일한 아키텍처적 베팅을 합니다. 검증 과정에서 필요할 때마다 데이터를 가져오는(on-demand) 방식은 데이터를 가져오는 주체가 무엇이든 간에 그 주체를 신뢰해야 한다는 점에 의존하기 때문에, 출처 데이터는 검증 시점에 요청되는 것이 아니라 서명되는 순간에 결합됩니다. AI 증거 아키텍처 역시 다른 방향에서 동일한 제약 조건에 부딪히고 있습니다.

the two-part evidence verification test — authority capture and independent verification

테스트 1은 통과하지만 테스트 2에서 실패하는 아티팩트 (Artifact)는 여전히 런타임 의존적 (runtime-dependent)입니다. 조직은 권한이 캡처되었다는 사실을 증명할 수 있습니다. 하지만 그 증거가 플랫폼이 사라진 후에도 생존한다는 것은 증명할 수 없습니다. 이것이 바로 증거 (evidence)가 존재하는 근본적인 이유입니다.

이것이 로깅 공백 (Logging Gap)이 아닌 조달 실패 (Procurement Failure)인 이유

대부분의 플랫폼 평가는 하위 단계의 질문들을 던집니다: 보존 기간 (retention windows), 내보내기 형식 (export formats), 검색 기능 (search capability), 감사 로그 (audit log)에 대한 RBAC (역할 기반 액세스 제어) 범위 등입니다. 플랫폼은 실행 시점에 권위 있는 아티팩트 (authoritative artifacts)를 전혀 생성하지 않으면서도 이러한 모든 질문에 '예'라고 답할 수 있습니다. 왜냐하면 제안 요청서 (RFP)가 그 문제를 드러낼 질문을 던지지 않았기 때문입니다.

조달 과정에서 거의 아무도 묻지 않는 질문은 다음과 같습니다: 권한이 행사되는 순간 어떤 권위 있는 아티팩트 (authoritative artifact)가 생성되는가, 그리고 그 아티팩트를 우리 플랫폼을 신뢰할 필요가 없는 누군가가 검증할 수 있는가? 이 두 가지 질문이 바로 '2단계 증거 검증 테스트 (Two-Part Evidence Verification Test)'의 전부이며, 이는 아키텍처 검토 대신 구매자 실사 (buyer diligence)로 재정의된 것입니다. NIST AI Risk Management Framework는 조직의 AI 책임성을 정확히 이러한 관점에서 정의합니다. 즉, 벤더가 스스로에 대해 주장하는 내용을 뒷받침하는 증거가 아니라, 독립적인 조사 (independent scrutiny)를 뒷받침하는 증거를 의미합니다.

이 상황을 위험하게 만드는 비대칭성 (asymmetry)은 다음과 같습니다: 증거 생성 플랫폼 (evidence-originating platforms)과 텔레메트리 전용 플랫폼 (telemetry-only platforms)은 아직 감사 이벤트 (audit event)가 발생하지 않은 배포 환경에서는 동일해 보입니다. 이 격차는 수정 비용이 가장 저렴한 바로 그 순간에는 보이지 않다가, 수정 비용이 가장 비싼 순간, 즉 조사 중이거나 규제 조사 (regulatory inquiry)가 진행 중이며, 런타임 (runtime)이 이미 기본적으로 신뢰하지 않는 누군가에게 답변해야 하는 상황에서 표면 위로 드러납니다. 증거 검증 질문을 결코 던지지 않는 조달 기준 (Procurement rubrics)은 기본적으로 그러한 격차를 계속해서 구매하게 될 것입니다.

아키텍트의 판결 (Architect's Verdict)

검증을 위해 그 근원 플랫폼이 살아있고, 사용 가능하며, 신뢰받는 상태로 유지되어야만 하는 증거는 결코 증거가 아니었습니다. 그것은 증거의 옷을 입은 '주장 (claim)'일 뿐이며, 누군가가 플랫폼의 도움 없이 그 주장을 확인하려고 시도하는 바로 그 순간까지 두 가지는 동일해 보일 뿐입니다.

증거 문제를 해결했다고 믿는 대부분의 조직은 사실 무결성 (integrity) 문제를 해결한 것에 불과합니다. 즉, 기록이 작성된 이후로 변경되지 않았음은 증명할 수 있지만, 그 기록을 작성할 당시 해당 시스템이 권위 있는 시스템이었는지를 별도로 확인하지 않은 상태입니다. 이러한 격차는 데모 (demo), 보존 정책 (retention policy), 또는 저장 여부만을 묻는 컴플라이언스 체크리스트 (compliance checklist)에서는 나타나지 않습니다. 이 격차는 그 어떤 산출물도 견뎌낼 수 있도록 설계되지 않은 단 하나의 대화 상황에서 드러납니다. 바로 런타임 (runtime)에 대한 접근 권한이 없는 독립적인 제3자가, 자신들이 보고 있는 것이 사실인지 묻는 상황입니다.

그러한 대화 속에서 살아남는 시스템은 가장 완벽한 로그 (logs)를 가진 시스템이 아닙니다. 신뢰를 얻기 위해 런타임의 허락을 받을 필요가 없었던 시스템입니다. 그것이 바로 증거 검증 (evidence verification)이 실제로 테스트하고자 하는 핵심입니다.

원문은 rack2cloud.com에서 처음 게시되었습니다.