당신의 에이전트가 작업을 완료했다고 말합니다. 로그 파일도 그 내용에 동의합니다. 하지만 이 중 어느 것도 증거가 될 수 없습니다. 로그는 그것이 설명하는 바로 그 프로세스에 의해 작성되었으며, 디스크 접근 권한이 있는 누구라도 나중에 다시 작성할 수 있기 때문입니다. 고객, 감사인 또는 법원에 에이전트가 무엇을 했는지 보여주어야 한다면, 변경 시 명확하게 오류를 발생시키며(fails loudly when altered), 당신을 신뢰하지 않고도 제삼자가 확인할 수 있는 기록이 필요합니다. 이 글은 오픈 검증기(open verifier)와 서명된 실행 영수증(signed execution receipt)을 사용하여 정확히 이 작업을 수행하는 실질적인 가이드입니다.

1단계: 검증기(verifier) 설치

검증기는 영수증 사양(receipt specification)이 공개된 작은 오픈 소스 Python 패키지입니다:

$ pip install traceseal-verify
$ traceseal-verify receipt.json
[OK] receipt.json — operator signature verified

검증은 **오프라인(offline)**으로 실행됩니다. 계정, API 호출, 또는 운영자(operator)의 인프라에 대한 접근이 필요하지 않습니다. 이것이 핵심입니다. 운영자의 협조가 필요한 검증은 독립적인 검증이 아닙니다.

2단계: 영수증 읽기 — 구조 분석

영수증은 세 개의 블록으로 구성된 단일 JSON 문서입니다. 다음은 축약된 실제 영수증 예시입니다:

{
  "attestation": {
    "attested_at": "2026-04-15T05:29:04Z",
...

각 블록은 서로 다른 질문에 답합니다:

• provenance (출처) — 어떤 코드가 실행되었는가. 발행자(Publisher)는 콘텐츠 주소 지정 방식의 매니페스트(manifest)에 서명합니다. 모든 아티팩트(skill definition, capability declaration, 코드 자체)는 SHA-256 해시(FIPS 180-4)로 나열됩니다. 코드의 단 1바이트만 변경되어도 매니페스트 해시는 더 이상 일치하지 않습니다.
• execution (실행) — 어떤 일이 일어났는가. 입력값(Inputs), 출력값(outputs), 그리고 샌드박스 정책(sandbox policy)은 정형 JSON(canonical JSON) 형태의 해시로 기록됩니다. 이는 데이터를 노출하지 않고도 무결성(integrity)을 증명합니다. 즉, 출력을 공개하지 않고도 출력이 변경되지 않았음을 입증할 수 있습니다.
• attestation (증명) — 누가 이를 보증하는가. 운영자(Operator)는 Ed25519 키(RFC 8032)를 사용하여 전체 기록에 서명합니다. 이 서명은 정형 JSON 인코딩(정렬된 키, 고정된 구분자)을 대상으로 하므로, 주어진 영수증(receipt)에 대해 정확히 하나의 유효한 바이트 시퀀스가 존재합니다. 어디에서든 편집이 발생하면 봉인이 깨집니다.

3단계: 검증이 무엇을 증명하는지 이해하기

traceseal-verify가 [OK]를 출력하면 다음 네 가지 사항이 확립된 것입니다:

1. 영수증은 운영자가 서명한 것과 바이트 단위로 일치합니다. 이후에 에이전트, 운영자의 도구, 또는 파일을 취급한 그 누구에 의해서도 편집되지 않았음을 의미합니다.
2. 실행된 코드는 각 파일의 해시를 포함하여 발행자가 서명한 코드와 정확히 일치합니다.
3. 기록된 입력값, 출력값 및 샌드박스 정책은 실행 시점에 존재했던 것들입니다. 나중에 제시되는 그 어떤 것이든 해시를 통해 대조 확인할 수 있습니다.
4. 서명 키는 지문(fingerprint)으로 식별되므로, 동일한 운영자의 반복된 영수증은 서로 연결될 수 있습니다. 또한 영수증은 공개 투명성 로그(public transparency log) (transparency_log_seq 필드)에 고정될 수 있으며, 이를 통해 운영자가 몰래 두 가지 버전의 이력을 유지하는 것을 방지합니다.

영수증이 증명하지 못하는 것

정직한 도구는 자신의 한계를 명시하며, 이는 분쟁 상황에서 영수증에 의존해야 할 경우 매우 중요합니다:

• 작업의 품질을 증명하지는 않습니다. 영수증은 무엇이 실행되었고 무엇이 생성되었는지는 증명하지만, 그 결과물이 올바른지는 증명하지 않습니다. 결과물을 정답(Ground Truth)과 대조하여 확인하는 것은 별도의 상호 보완적인 검증 단계입니다.
• 포함되지 않은 이벤트는 증명하지 못합니다. 영수증은 하나의 실행(Execution)을 봉인합니다. 봉인된 실행 외부에서 취해진 행동은 단순히 누락될 뿐입니다. 이것이 바로 계측(Instrumentation)이 사고 발생 후가 아니라, 사고 발생 전에 시작되어야 하는 이유입니다.
• 사람이 아닌 키(Key)를 결속합니다. 서명은 운영자 키(Operator Key)의 소유자가 해당 기록을 보증했음을 증명합니다. 해당 키를 법적 신원과 연결하는 것은 다른 서명 체계와 마찬가지로 키 관리(Key-management)의 문제입니다.

신뢰의 역전: 로그의 경우, 기록을 읽는 사람이 작성자를 신뢰해야 하는 부담을 가집니다. 서명된 영수증의 경우, 기록 자체가 검증을 통과해야 하는 부담을 가집니다. 이것이 "우리 시스템은 제대로 작동했다고 말한다"와 "직접 확인해 보라"의 차이입니다.

이것이 스크린샷과 로그 내보내기보다 나은 이유

오늘날 증거 조사 팀이 일반적으로 생성하는 결과물인 스크린샷, 로그 내보내기(Log exports), 대시보드 PDF 등은 한 가지 결함을 공유합니다. 즉, 모두 행동의 의심을 받는 당사자에 의해 생성되거나 그 당사자의 통제 하에 있다는 점입니다. 로그 관리에 관한 컴퓨터 보안 지침은 로그가 시스템을 제어하는 누구에 의해든 수정될 수 있기 때문에 반드시 보호가 필요하다고 수년 동안 경고해 왔습니다 (NIST SP 800-92). 정형화된 기록(Canonical record)에 대한 분리된 서명은 수정 가능성을 제거하며, 공개 검증기(Open verifier)는 타인의 말을 그대로 믿어야 할 필요성을 없애줍니다.

여기에 제시된 모든 것은 공개되어 있습니다: 영수증 사양(Receipt spec), PyPI의 검증기(Verifier on PyPI), 그리고 투명성 로그(Transparency log). 여러분이 직접 이 형식을 구현할 수 있으며, 사양에는 참조용 정형 JSON 인코더(Reference canonical-JSON encoder)도 포함되어 있습니다.

원문은 traceseal.io에 게시되었습니다.