Molayo

© 2026 Molayo

Dev.to헤드라인2026. 06. 25. 21:17

AI 시스템에는 관찰 가능성(Observability)뿐만 아니라 증거(Evidence)가 필요합니다

요약

AI 시스템 운영에서 관찰 가능성(Observability)과 증거(Evidence)의 차이를 설명합니다. 관찰 가능성은 운영자를 위한 내부 신호인 반면, 증거는 제3자가 독립적으로 검증할 수 있는 휴대 가능한 산출물이어야 함을 강조합니다.

핵심 포인트

  • 관찰 가능성은 운영 효율을 위한 내부 데이터이며, 증거는 외부 검증을 위한 독립적 산출물임
  • AI 시스템은 확률적 특성과 분산된 권한 체인으로 인해 증거 재구성이 어려움
  • 컴플라이언스 준수를 위해서는 서명된 실행 기록과 같은 의도적인 증거 구축이 필요함

AI 증거(Evidence), 관찰 가능성(Observability), 그리고 증명(Proof) 사이의 간극은 모든 AI 컴플라이언스(Compliance) 실패가 발생하는 지점입니다. 그리고 대부분의 인프라 팀은 시스템 외부의 누군가가 발생한 일을 검증해 달라고 요청하기 전까지는 이 문제를 발견하지 못합니다.

여러분의 관찰 가능성(Observability) 스택은 AI 시스템이 정확히 무엇을 했는지 알려주었습니다. 하지만 감사인(Auditor)은 그것을 증명하라고 요구했습니다. 이 둘은 서로 다른 요청입니다. 기본적으로 이 두 가지를 모두 충족하는 AI 플랫폼은 거의 없습니다.

ai evidence observability — execution plane with evidence artifact layer above observability stack

AI 증거 관찰 가능성(AI Evidence Observability): 발생한 일이 증명될 수 있는 일과 같지는 않습니다

관찰 가능성(Observability)은 시스템을 생성한 시스템에 접근 권한이 있는 운영자(Operator)가 소비하는 내부 신호입니다. 지연 시간 추적(Latency trace)은 엔지니어에게 모델이 무엇을 반환했는지, 그리고 얼마나 걸렸는지를 알려줍니다. 이것들은 운영 측면에서 유용합니다. 조직이 스스로에게 던지는 질문에 답을 해줍니다.

증거(Evidence)는 구조적으로 다른 것입니다. 그것은 런타임(Runtime) 외부에서도 생존하는 산출물(Artifact)입니다. 즉, 휴대 가능하고, 귀속 가능하며, 시스템을 한 번도 만져보지 않은 사람에 의해 독립적으로 검증될 수 있어야 합니다. 모델 호출을 누가, 어떤 정책 제약 조건 하에, 언제 승인했는지를 재구성하는 서명된 실행 기록(Signed execution record)으로서, 제3자가 라이브 인프라에 접근하지 않고도 검증할 수 있는 형태 — 이것이 바로 증거입니다.

전통적인 시스템은 종종 사후에 증거를 재구성할 수 있을 만큼 충분한 결정론적 산출물(Deterministic artifacts)을 남깁니다. HTTP 로그, 데이터베이스 감사 추적(Database audit trails), API 게이트웨이 기록 등이 그것입니다. 이러한 경우 증거는 실행 과정에 암묵적으로 포함되어 있습니다.

AI 시스템은 이러한 가정을 빈번하게 깨뜨립니다. 권한 체인(Authority chains)은 여러 실행 경계(Runtime boundaries)에 걸쳐 분산되어 있습니다. 추론 경로(Reasoning paths)는 확률적(Probabilistic)입니다. 실행 시점의 정책 상태(Policy state)는 출력값과 함께 캡처되는 경우가 거의 없습니다. 에이전트 워크플로(Agentic workflows)에서의 도구 호출 체인(Tool invocation chains)은 로깅 스택(Logging stack)이 상관관계를 분석하도록 설계되지 않은 시스템들에 걸쳐 있습니다. 증거 기록은 의도적으로 구축되어야 하지만, 오늘날 대부분의 AI 인프라에서는 그렇지 않습니다.

관찰 가능성(Observability)이 증거처럼 느껴지는 이유 (하지만 증거는 아닙니다)

관찰 가능성(Observability)은 대시보드가 상세하기 때문에 신뢰를 줍니다. 트레이스(Traces)는 세밀하고, 메트릭(Metrics)은 정확합니다. 팀이 더 많은 텔레메트리(Telemetry)를 보유할수록, 나중에 무슨 일이 일어났는지 재구성할 수 있다는 확신을 더 강하게 갖게 됩니다.

하지만 그 확신은 종종 잘못된 것입니다. 증거(Evidence)는 검증 가능한 신원(Verifiable identity)과 연결될 수 있는 귀속(Attribution), 실행 후에도 불변(Immutable)으로 유지되는 기록, 라이브 시스템에 대한 접근 권한 없이도 제3자가 수행할 수 있는 재구성, 그리고 이벤트를 생성한 실행 환경(Runtime)을 넘어선 이식성(Portability)을 요구합니다. 관찰 가능성(Observability)이 이러한 목표를 지원할 수는 있지만, 이를 보장하지는 않습니다.

가시성(Visibility)과 증명(Proof)은 시스템 외부의 누군가가 발생한 일을 검증해 달라고 요청하는 바로 그 지점에서 갈라집니다.

ai evidence observability gap — four properties that separate proof from visibility

모든 AI 사고 조사에서 나타나는 세 가지 증거 격차(Evidence Gaps)

01 — 권한 증거 격차 (Authorization Evidence Gap)

API 로그는 호출이 성공했음을 보여줍니다. 하지만 이를 허용한 권한 체인(Authority chain)은 아무것도 보여주지 않습니다. "호출이 실행되었다"와 "호출이 선언된 정책에 따라 정의된 신원에 의해 승인되었다" 사이의 차이는 대부분의 관찰 가능성 스택(Observability stacks)에서 보이지 않습니다. 로그는 실행을 기록할 뿐, 권한 부여(Authorization)를 기록하지 않습니다.

02 — 행동 증거 격차 (Behavioral Evidence Gap)

모델 출력(Model outputs)은 기록됩니다. 하지만 실행 시점에 활성화되었던 정책 범위(Policy scope)는 기록되지 않습니다. 모델이 배포된 파라미터 내에서, 즉 평가 및 승인을 받았던 행동 범위(Behavioral envelope) 내에서 작동했는지 여부는 출력 로그만으로는 답할 수 없는 거버넌스(Governance) 문제입니다.

03 — 출처 증거 격차 (Provenance Evidence Gap)

에이전트 체인(Agentic chains)의 경우, 어떤 에이전트가 어떤 다운스트림(Downstream) 동작을 트리거했는가? 체인은 실행되었습니다. 하지만 트레이스(Trace)는 이를 재구성하지 못합니다. 도구 권한 부여(Tool grants), 위임 체인(Delegation chains), 호출 시퀀스(Invocation sequences)는 여러 시스템 경계를 가로지르는 실행 아티팩트(Execution artifacts)입니다. 이 중 어느 것도 각 동작을 해당 권한 부여 소스(Authorization source)와 연결하는 인과적 기록(Causal record)을 생성하도록 설계되지 않았습니다.

격차를 드러낸 감사 (The Audit That Exposed the Gap)

현실적인 에이전트 체인을 가정해 보겠습니다: 에이전트가 변경 요청을 승인하고, 운영 티켓(Production ticket)을 생성하며, 인프라 수정을 실행하고, 클라우드 리소스 동작을 트리거합니다.

6주 후, 감사가 다음 네 가지 질문을 던집니다:

  • 초기 승인 동작을 권한 부여한 신원(Identity)은 무엇인가?
  • 어떤 정책이 인프라 수정을 허용했는가?
  • 어떤 에이전트가 클라우드 리소스 변경을 시작했는가?
  • 실행 시점에 어떤 도구 권한 부여(Tool grant)가 활성화되어 있었는가?

로그는 실행이 발생했음을 보여줍니다. 하지만 권한 부여(Authorization)를 증명하지는 못합니다. 팀은 완벽한 관찰 가능성(Observability)을 갖추고 있습니다. 하지만 증거(Evidence)를 제시할 수는 없습니다.

프레임워크 #149 — AI 증거 아티팩트 계층 (AI Evidence Artifact Layer)

AI 증거 아티팩트 계층(AI Evidence Artifact Layer)은 이를 생성한 런타임 시스템(Runtime systems) 외부에서도 유지되는, 이식 가능하고(Portable), 귀속 가능하며(Attributable), 검증 가능한(Verifiable) 실행 증거를 생성하는 역할을 담당하는 아키텍처 계층입니다.

실패 상태: 관찰 가능성(Observability)은 존재하지만, 사후에 제3자가 권한 부여(Authorization), 출처(Provenance), 정책 상태(Policy state) 또는 실행의 정당성(Execution legitimacy)을 재구성할 수 없는 상태.

AI 증거 아티팩트 계층(AI Evidence Artifact Layer)은 런타임(Runtime) 자체가 사라진 후에도 운영 메모리(Operational memory)를 보존하는 실행 시점의 메커니즘이며, 이는 #129 운영 메모리 경계(Operational Memory Boundary)와 직접적으로 연결됩니다. 교리적 체계(Doctrinal chain)는 다음과 같습니다: #129가 메모리 요구 사항을 정의하고, #134 주권 증거 체인(Sovereignty Evidence Chain)이 이를 관할권 증명(Jurisdictional proof)에 적용하며, #149가 이를 AI 실행 증명(AI execution proof)에 적용합니다. 메모리(Memory) → 증거(Evidence) → 증명(Proof).

4가지 구성 요소:

01 — 권한 경계에서의 실행 기록(Execution Records at Authorization Boundary) — 호출(Invocation) 시점에 캡처된 권한 체인. 누가 이 실행을 승인했는지, 어떤 정책 범위(Policy scope) 하에 있었는지, 호출이 이루어진 순간 어떤 제약 조건(Constraint)이 활성화되어 있었는지에 대한 기록입니다. 이 기록은 반드시 실행 시점에 생성되어야 합니다. 사후 로그 분석(Post-hoc log analysis)을 통해서는 신뢰할 수 있는 결과물을 만들어낼 수 없습니다.

02 — 정책 상태 스냅샷(Policy State Snapshots) — 실행이 발생했을 때 활성화되어 있던 제약 조건. 이는 불변(Immutable)하며 호출 기록과 결합되어 있고, 현재의 정책 설정(Policy configuration)에 접근하지 않고도 검증 가능해야 합니다. 실행 이후의 정책 변경은 과거에 허용되었던 사항을 소급하여 변경하지 않습니다.

03 — 에이전트 작업 출처(Agent Action Provenance) — 에이전트 체인(Agentic chain) 내의 각 작업을 해당 권한 부여 소스(Authorization source)와 연결하는 인과적 추적(Causal trace). 어떤 에이전트가 어떤 권한(Grant) 하에, 누구의 권한으로 어떤 도구(Tool)를 호출했는지를 나타냅니다. 이 기록이 없다면 에이전트 실행은 출력을 만들어낸 블랙박스(Black box)에 불과합니다. 이 기록이 있다면 그 체인은 방어 가능(Defensible)해집니다.

04 — 아티팩트 이식성(Artifact Portability) — 이를 생성한 시스템 외부에서도 생존하며, 내부 관찰 가능성 스택(Observability stack)에 접근 권한이 없는 제3자도 읽을 수 있는 증거. 만약 아티팩트를 해석하기 위해 라이브 시스템(Live system)이 필요하다면, 그것은 이식 가능한 것이 아닙니다. 만약 검증을 위해 생성 시스템에 대한 신뢰가 필요하다면, 그것은 증거가 아닙니다.

ai evidence artifact layer — four components: execution records, policy snapshots, agent provenance, artifact portability

설계자의 결론 (Architect's Verdict)

관찰 가능성(Observability)은 운영자(Operators)를 위한 증거입니다. 증거(Evidence)는 그 외 모든 사람을 위한 증명(Proof)입니다.

대부분의 AI 인프라 프로그램은 잘못된 계층을 최적화하고 있습니다. 시스템이 무엇을 했는지에 대한 가시성(Visibility)은 운영상 필요하지만, 시스템 외부의 누군가가 검증을 요청할 때 발생하는 책임성(Accountability) 요구 사항을 충족하지는 못합니다.

다음 단계의 AI 도입을 주도할 시스템은 가장 많은 텔레메트리(Telemetry)를 생성하는 시스템이 아닐 것입니다. 그들은 런타임(Runtime)이 종료된 후에도 무슨 일이 일어났는지 증명할 수 있는 시스템이 될 것입니다.

추가 리소스

_원문 게시처: rack2cloud.com

AI 자동 생성 콘텐츠

본 콘텐츠는 Dev.to AI tag의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.

원문 바로가기
0

댓글

0