컨텍스트 엔지니어링 실패모드 위키

provenance 운영표준 — C2PA·검증가능자격증명(VC)·데이터 lineage

23 min read

상위: 07_00_MOC

provenance 운영표준 — 출처 메타데이터를 산업 표준으로 붙이는 “진짜 기초”

07_06-provenance와-신뢰등급-프로베넌스-역설은 provenance가 왜 필요한지를 보였다. 자기보고는 랜덤보다 나쁘고, 검증된 출처(attestation)만이 거의 최적에 도달한다. 그렇다면 출처·신뢰등급 메타데이터를 토큰과 아티팩트에 어떻게 붙일 것인가? 이 노트는 그 진짜 기초를, 이미 성숙한 세 산업 표준으로 정리한다. C2PA(콘텐츠 출처·진위), W3C Verifiable Credentials / DID(검증가능 자격증명·탈중앙 식별자), OpenLineage(데이터 lineage)다. 그리고 이를 에이전트 컨텍스트 provenance 설계에 어떻게 이식하는지를 07_08-처방-컨텍스트는-슬롯계약-4계층-모델과 맞물려 살펴본다.

한 줄 정의

provenance 운영표준이란, 콘텐츠·자격·데이터 흐름에 “누가 만들었고(authorship), 무엇에서 파생됐고(lineage), 변조되지 않았음(tamper-evidence)“을 암호학적으로 검증 가능한 메타데이터로 부착하는 산업 표준군(C2PA, W3C VC/DID, OpenLineage), 그리고 이를 에이전트 컨텍스트 슬롯의 출처·신뢰등급 부여에 적용하는 설계 패턴을 가리킨다.

왜 중요한가

07_02-근본원인-권위와-출처-메타데이터-부재에서 본 핵심 결함은 “컨텍스트 슬롯에 출처가 없어 LLM이 모든 토큰을 동등하게 취급한다”였다. 많은 팀은 프롬프트에 [출처: 도구] 같은 태그를 붙이는 임시방편으로 이 문제를 넘기려 한다. 그러나 그런 태그는 위조 가능한 자기보고에 불과하다. 도구 반환값이 스스로 “나는 검증된 사실”이라 주장하면 막을 길이 없다. 프로베넌스 역설과 똑같은 함정이다.

세 표준이 중요한 이유는 이렇다. 콘텐츠·신원·데이터 흐름의 위조 불가능한 출처 추적이라는 문제를 업계는 이미 10년 넘게 풀어왔고, 그 결과 에이전트 provenance가 새로 발명할 필요 없는 기성 부품이 쌓여 있다.

  • C2PA → 컨텍스트에 들어오는 외부 미디어·생성물의 출처 증명(특히 AI 생성물 표기). trust 0 슬롯의 입력 검역.
  • W3C VC/DID → 에이전트와 도구의 신원·역량을 발급자-보유자-검증자 삼자 구조로 증명. 프로베넌스 역설이 말한 “attested identity”를 표준으로 구현한다.
  • OpenLineage → 컨텍스트에 들어온 사실이 어떤 작업·데이터셋에서 파생됐는지의 계보 추적. 검증된 사실층(L2)의 출처 링크.

이 세 가지가 4계층 슬롯 계약의 신뢰등급(07_06-provenance와-신뢰등급-프로베넌스-역설 2절)을 “선언”에서 “검증”으로 끌어올린다.

1. C2PA — 콘텐츠 출처·진위의 암호학적 봉인

1.1 무엇인가

C2PA(Coalition for Content Provenance and Authenticity)는 사양 문서에서 자신을 이렇게 정의한다.

“The Coalition for Content Provenance and Authenticity (C2PA) addresses the prevalence of misleading information online through the development of technical standards for certifying the source and history (or provenance) of media content.” — C2PA Specifications 2.2

미디어 콘텐츠의 출처와 이력(provenance)을 인증하는 기술 표준이다. 소비자가 보는 형태는 Content Credentials(콘텐츠 자격증명)라는 라벨이다. Adobe·Microsoft·BBC·Sony·OpenAI 등이 참여하며, 2026년 현재 카메라와 생성형 AI, 편집 도구에 점차 탑재되고 있다.

1.2 메커니즘 — manifest, claim, hard binding

C2PA의 핵심 데이터 구조는 Manifest(매니페스트)다.

구성요소역할
Assertion(어서션)자산의 출처·수정·AI 사용에 대한 개별 진술. created_assertions(서명자 귀속) vs gathered_assertions(비귀속)로 구분
Claim(클레임)어서션들을 묶어 서명되는 provenance 데이터 단위
Claim Signature(클레임 서명)작업을 수행한 소프트/하드웨어의 개인키로 서명, 공개키로 검증
Hard Binding(하드 바인딩)실제 콘텐츠의 암호학적 해시(통상 SHA-256). 자산이나 provenance가 한 비트라도 바뀌면 해시 불일치로 변조가 드러남
Ingredients(인그리디언트)여러 소스로 합성된 경우, 원소스를 인그리디언트로 기록해 원본까지의 계보 트리를 구성
Active Manifest / Manifest Store현재 유효 매니페스트 / 자산에 결합된 전체 매니페스트 집합

핵심은 하드 바인딩이다. 변조 탐지(tamper-evidence)가 주장이 아니라 수학으로 보장된다. 콘텐츠나 매니페스트를 수정하면 해시가 깨져 검증이 실패하기 때문이다.

1.3 신뢰 모델과 결정적 한계

C2PA의 신뢰는 Trust List(신뢰 목록)로 매개된다. 브라우저의 인증기관(CA)처럼, 자격을 갖춘 구현체가 트러스트 리스트에 등재된다. 다만 사양은 신뢰의 본질을 분명히 짚는다.

“trust in the contents of a Content Credential is based on the trust relationship between the creator…and the consumer” — C2PA Explainer 2.2

그리고 가장 중요한 한계가 있다. 에이전트 provenance 설계에 그대로 적용되는 교훈이기도 하다.

“provenance information alone cannot tell you whether the digital content is true, accurate or factual.” — C2PA Explainer 2.2

출처 증명은 진실 증명이 아니다. C2PA는 이 이미지를 누가 어떻게 만들었는지는 증명하지만, 이미지가 묘사하는 내용이 사실인지는 증명하지 않는다. 이 구분이 6절 처방의 토대다.

2. W3C Verifiable Credentials / DID — 신원·역량의 삼자 검증

2.1 검증가능 자격증명(VC)

W3C Verifiable Credentials Data Model 2.0(2025년 5월 15일 W3C Recommendation)은 VC를 이렇게 정의한다.

“a tamper-evident credential whose authorship can be cryptographically verified.” — W3C VC Data Model 2.0

변조 탐지가 가능하고, 작성자(authorship)를 암호학적으로 검증할 수 있는 자격증명이다. 생태계는 네 주체로 구성된다.

graph LR
    I["Issuer 발급자<br/>(claim을 주장·서명)"] -->|"VC 발급"| H["Holder 보유자<br/>(VC 보관·VP 생성)"]
    H -->|"Verifiable Presentation"| V["Verifier 검증자<br/>(진위·정책 검사)"]
    I -.->|"식별자·검증재료 등록"| R["Verifiable Data Registry<br/>(DID·신뢰레지스트리)"]
    V -.->|"공개키 조회"| R
    style I fill:#4488FF,color:#fff
    style H fill:#44AA44,color:#fff
    style V fill:#FF8800,color:#fff
    style R fill:#888888,color:#fff
주체역할(사양 인용)
Issuer 발급자”asserts claims about one or more subjects, creating a verifiable credential…and transmitting the credential to a holder”
Holder 보유자”possesses one or more verifiable credentials and generates verifiable presentations from them”
Verifier 검증자VC/VP를 받아 진위를 검증하고 claim이 자기 요구를 충족하는지 평가
Verifiable Data Registry”mediates the creation and verification of identifiers, verification material, and other relevant data”

2.2 검증 ≠ 진실 (C2PA와 동일한 경계)

VC 사양도 C2PA와 정확히 같은 경계를 긋는다.

“verification of a credential does not imply evaluation of the truth of claims encoded in the credential” — W3C VC Data Model 2.0

자격증명의 검증은 claim의 진실성을 보장하지 않는다. 검증자가 확인하는 것은 사양 구조 적합성, 보안 메커니즘의 암호 검증, 상태(폐기 여부)뿐이고, claim이 사실인지는 자신의 정책으로 독립 판단해야 한다. 이것이 attested identity의 정확한 의미다. “이 에이전트가 X 역량을 가졌다고 신뢰된 발급자가 서명했다”는 검증이지, “그 에이전트가 실제로 일을 잘한다”는 보증이 아니다.

2.3 DID — 중앙 등록기관 없는 식별자

VC의 신원 기반은 DID(Decentralized Identifier)다. W3C DID Core는 DID를 “a globally unique persistent identifier that does not require a centralized registration authority”로 정의한다. 구조는 did:method:method-specific-id 형식이다(예: did:example:123...).

  • DID Document — DID 주체를 기술하는 데이터(공개키·서비스 엔드포인트 포함)
  • Verification Method — “a set of parameters that can be used together with a process to independently verify a proof”(공개키 등)
  • DID Controller — DID 문서를 변경할 권한을 가진 주체(주체 자신일 수도, 아닐 수도)

핵심은 통제자가 다른 어떤 주체의 허가 없이도 DID 통제권을 증명할 수 있다는 점이다. 에이전트 맥락에서 DID는 각 에이전트와 도구에 위조 불가능한 자기주권 신원을 부여하는 기반이 된다.

3. OpenLineage — 사실의 계보(data lineage)

provenance의 세 번째 축은 “이 데이터·사실이 어떤 작업에서 어떤 입력으로 만들어졌는가”의 계보다. OpenLineage(LF AI & Data Foundation 졸업 프로젝트)는 “an open framework for data lineage collection and analysis”로, lineage 메타데이터 교환의 공통 사양이다.

데이터 lineage는 데이터의 기원·이동·변환을 추적해 의존성 파악, 영향 분석(impact analysis), 컴플라이언스를 가능케 한다. OpenLineage의 코어 모델은 다음과 같다.

엔티티의미
Job데이터를 변환하는 처리 단위
Run특정 시점의 Job 실행 인스턴스
Dataset처리에 관여하는 입력·출력 데이터
Facet”user-defined metadata” — 코어를 건드리지 않고 엔티티를 확장하는 메타데이터

OpenLineage 이전에는 각 데이터 플랫폼(Airflow·Spark·Flink·dbt 등)이 lineage 통합을 중복 구현했다. OpenLineage는 이를 스케줄러·처리 프레임워크 레이어에서 표준화해 벤더 종속을 줄이고, 거버넌스와 영향 분석을 표준 provenance 추적으로 지원한다. 에이전트 맥락에서는 Facet 확장성이 특히 중요하다. 컨텍스트 사실 단위에 trust score, attestation 링크, 만료 시각 같은 provenance facet을 코어 스키마 수정 없이 부착할 수 있기 때문이다.

4. 에이전트 메모리에의 직접 적용 — TierMem(provenance-aware tiered memory)

위 표준의 발상을 LLM 에이전트 메모리에 직접 적용한 연구가 TierMem(Zhu et al., 2026, “From Lossy to Verified”)이다. 문제의식은 05 부패와 압축 위험에 곧장 맞닿는다.

장기 에이전트는 미래 질의를 알기 전에 상호작용 이력을 요약으로 압축하므로 “unverifiable omissions — decisive constraints (e.g., allergies) may be dropped.” — Zhu et al.(2026)

쓰기 시점 요약(write-time summary)은 무엇이 중요한지 모르는 채로 정보를 버리고, 그 누락은 검증할 길이 없다(알레르기 같은 결정적 제약이 사라져도 알아챌 수 없다). 반대로 원시 로그를 모두 보존하면 반복 처리 비용이 크다.

TierMem의 방법은 provenance로 연결된 2계층 메모리다.

  1. 기본적으로 빠른 요약 인덱스에서 답하되,
  2. 증거가 불충분하면 불변 원시 로그(immutable raw-log) 저장소로 에스컬레이션하고,
  3. 검증된 발견은 원출처에 링크된 새 요약 단위로 다시 기록한다(write-back).

LoCoMo 벤치마크 수치는 이렇다. 정확도 0.851(원시 로그만 사용한 0.873 대비), 입력 토큰 54.1% 감소, 지연 60.7% 감소.

“TierMem achieved 0.851 accuracy (vs. 0.873 raw-only) while reducing input tokens by 54.1% and latency by 60.7%.” — Zhu et al.(2026)

이 노트의 핵심 메시지가 여기서 실증된다. 요약(lossy)에 provenance 링크를 붙여 필요할 때 검증된 원출처로 되돌아갈 수 있게 하면, 효율은 거의 유지한 채 검증 가능성(verified)을 회복한다. C2PA의 ingredient 트리, OpenLineage의 dataset 계보, VC의 attested 링크와 정확히 같은 발상이다.

수치 신뢰도 주의 — TierMem 정량치(0.851 등)는 프리프린트(arXiv:2602.17913) 출처이며 독립 재현은 아직 확인되지 않았다. 절대치보다 방향성(provenance 링크를 붙이면 비용↓·검증성↑)으로 읽는 편이 안전하다.

5. 세 표준의 공통 골격 — 그리고 프로베넌스 역설과의 연결

세 표준은 도메인이 다르지만 하나의 공통 골격을 공유한다. 이 골격이 곧 에이전트 provenance의 설계 원리다.

graph TD
    A["① 식별가능 출처<br/>누가 만들었나<br/>(DID·서명자·Job)"] --> D["④ 검증자 독립판단<br/>출처 검증 ≠ 진실 보증"]
    B["② 변조 탐지 봉인<br/>해시·서명<br/>(hard binding·proof)"] --> D
    C["③ 파생 계보<br/>무엇에서 왔나<br/>(ingredient·dataset·lineage)"] --> D
    style A fill:#4488FF,color:#fff
    style B fill:#FF4444,color:#fff
    style C fill:#44AA44,color:#fff
    style D fill:#FF8800,color:#fff
  1. 식별 가능한 출처(authorship) — C2PA 서명자, VC 발급자, OpenLineage Job. 모두 “누가”를 위조 불가능하게 고정한다.
  2. 변조 탐지 봉인(tamper-evidence) — C2PA 하드 바인딩, VC 암호 proof. “그 사이 바뀌지 않았음”을 수학으로 보장한다.
  3. 파생 계보(lineage) — C2PA ingredient 트리, OpenLineage dataset 그래프, VC 체인. “무엇에서 파생됐나”를 추적한다.
  4. 검증 ≠ 진실 — C2PA와 VC가 똑같은 문구로 못박는 경계. 검증자는 출처가 진짜인지만 확인하고, 내용이 사실인지는 독립 정책으로 판단한다.

네 번째가 07_06-provenance와-신뢰등급-프로베넌스-역설과 곧장 이어진다. 프로베넌스 역설은 에이전트가 스스로 품질을 주장하게 하면 최악을 고른다는 것이었다. 세 표준의 답도 같다. 자기주장(self-claim)을 믿지 말고, 신뢰된 제3자가 서명한 attestation을 믿으라는 것이다. C2PA의 트러스트 리스트, VC의 발급자, DID의 통제권 증명은 모두 self-claim에서 attested로의 전환을 표준화한 장치다.

6. 처방 — 슬롯 계약에 provenance 표준을 매핑한다

07_08-처방-컨텍스트는-슬롯계약-4계층-모델의 4계층에 위 표준을 매핑하면, 신뢰등급이 “선언”에서 “검증”으로 승급된다.

슬롯(계층)provenance 표준 매핑검증 게이트
L1 불변 헌법층 (trust 5)배포자 서명 + DID 통제권 증명서명 검증 실패 시 로드 거부
L2 검증된 사실층 (trust 3)VC attested 링크 + OpenLineage lineage facet + (외부 미디어면) C2PA 매니페스트발급자 신뢰 + 해시 무결성 + 계보 추적 가능 시에만 승격
L3 작업 가설층 (trust 1)워커 DID 서명(자기생성 표기)spec 대비 검증 후 사용, attestation 없음 명시
L4 휘발 스크래치층 (trust 0)C2PA 매니페스트 유무 검사·서명 검증 실패 = 검역IPI 검역, 하드 바인딩 깨지면 격리·폐기

운영 원칙은 세 가지다.

  1. self-claim을 트러스트 메타데이터로 받지 않는다. 슬롯의 trust는 슬롯이 주장하는 값이 아니라, 신뢰된 발급자·서명자가 attest한 값이어야 한다. 프로베넌스 역설에 대한 직접 처방이다.
  2. 요약은 반드시 원출처에 링크한다(TierMem 원칙). L2로 승격하는 모든 압축·요약 사실은 OpenLineage식 lineage 링크나 C2PA식 ingredient 참조를 보존해, 검증이 필요할 때 불변 원시 로그로 에스컬레이션할 수 있어야 한다. 링크 없는 요약은 05 부패가 말한 검증 불가능한 누락을 낳는다.
  3. “검증됨 ≠ 사실임”을 모델과 운영자 모두에게 각인한다. C2PA와 VC가 같은 문구로 경고하듯, provenance는 출처가 진짜이고 변조되지 않았다는 데까지만 보장한다. 사실 여부는 07_07-충돌해소와-합의-안전성-비합성성의 검증·합의 단계가 따로 판단한다. provenance를 진실 판정으로 오용하면 그 자체가 새로운 오염원이 된다.

요약·체크리스트

  • C2PA = 콘텐츠 출처·진위 표준. manifest(assertion+claim+claim signature)에 hard binding(콘텐츠 해시)을 더해 변조를 수학적으로 탐지. trust list로 신뢰를 매개하고 “provenance ≠ 진실”을 명시.
  • W3C VC/DID = 신원·역량의 삼자(발급자-보유자-검증자) 검증. DID로 중앙 등록기관 없는 자기주권 식별자를 부여. “검증 ≠ claim의 진실”을 명시해 attested identity를 표준으로 구현.
  • OpenLineage = 데이터 lineage 표준. Job/Run/Dataset/Facet로 사실의 파생 계보를 추적하고, Facet 확장성으로 trust·attestation 메타데이터를 부착.
  • TierMem(2026) = 이 발상을 에이전트 메모리에서 실증. provenance 링크된 2계층 메모리로 토큰 54.1%·지연 60.7%를 절감하면서 정확도 0.851 유지(원시 0.873). “lossy → verified”.
  • 공통 골격 = ① 식별 가능 출처 ② 변조 탐지 봉인 ③ 파생 계보 ④ 검증 ≠ 진실. ④가 프로베넌스 역설의 답으로, self-claim 대신 attestation을 믿는다.
  • 체크리스트:
    • 모든 컨텍스트 슬롯의 trust는 self-claim이 아니라 attest된 값인가?
    • L2로 승격하는 모든 요약/사실에 원출처 lineage 링크가 보존되는가?(TierMem)
    • 외부 미디어/AI 생성물은 C2PA 매니페스트·서명 검증을 거치는가?(L4 검역)
    • 에이전트/도구에 검증 가능한 신원(DID/VC)이 부여돼 있는가?
    • 운영 문서에 “provenance 검증 ≠ 내용 사실”이 명시돼, 진실 판정과 혼동되지 않는가?

참고문헌

그래프 뷰

백링크