AI 에이전트 (AI agents)를 운영하는 거의 모든 팀은 로그 (logs)를 남깁니다. 하지만 분쟁 상황에서 실제로 제기되는 질문인 **'왜 누군가가 그 로그를 믿어야 하는가?'**에 답할 수 있는 팀은 거의 없습니다.

로그는 시스템이 스스로에 대해 남기는 기록입니다. 디버깅 (debugging)에는 유용하고, 운영 (operations)에는 필수적이지만, 그 자체만으로는 증거로서 가치가 거의 없습니다. 이 글은 로그와 서명된 실행 영수증 (signed execution receipts)의 차이점, 그리고 로그가 제공할 수 없는 서명된 실행 영수증이 무엇을 더해주는지에 대한 입문서입니다.

증거가 실제로 요구하는 것

법률 용어를 걷어내고 보면, 회의적인 외부인이 기록을 신뢰하기 위해서는 다음 네 가지를 충족해야 합니다.

• 무결성 (Integrity). 기록이 생성된 이후 변경되지 않았어야 하며, 만약 변경되었다면 그 사실을 감지할 수 있어야 합니다.
• 귀속성 (Attribution). 특정 누군가가 해당 기록에 대해 책임을 져야 합니다. 아무도 보증하지 않는 기록은 누구에게도 책임을 물을 수 없습니다.
• 완전성 (Completeness). 이해관계자가 사후에 선택적으로 추출한 데이터가 아니라, 전체 집합을 보고 있어야 합니다.
• 독립성 (Independence). 의구심을 갖는 측이 의심받는 측의 협조 없이도 검증을 수행할 수 있어야 합니다.

_증거 능력 (admissibility)_은 이보다 훨씬 낮은 기준이라는 점에 유의하십시오. 영국 민사 절차에서는 증인의 진술 없이도 비즈니스 기록을 증거로 받아들입니다 (Civil Evidence Act 1995, s.9). 로그를 심판부에 제출하는 것은 쉽습니다. 하지만 심판부가 그 로그의 _가치_를 어떻게 판단하느냐가 핵심이며, 바로 이 지점에서 일반적인 로깅 (logging)은 한계에 부딪힙니다.

로그가 각 항목별로 실패하는 이유

애플리케이션 로그 (application log)는 위 네 가지 항목 모두에서 실패하며, 이는 구현의 문제라기보다 구조적인 문제입니다:

• 무결성 (Integrity): 로그는 운영자가 제어하는 인프라 상의 변경 가능한 (mutable) 파일입니다. 디스크나 데이터베이스에 접근할 수 있는 사람이라면 누구나 과거 기록을 다시 작성할 수 있으며, 아티팩트 (artefact) 자체에는 아무런 흔적도 남기지 않을 수 있습니다. 이는 새로운 관찰이 아닙니다. 컴퓨터 보안 지침에서는 로그 데이터가 시스템을 보유한 누구에 의해든 변경될 수 있기 때문에 명시적인 보호가 필요하다고 지난 20년 동안 말해왔으며 (NIST SP 800-92), 연방 통제 카탈로그 (federal control catalogue)에는 정확히 이 문제를 해결하기 위한 전용 통제 항목인 AU-9 _감사 정보 보호 (Protection of Audit Information)_가 포함되어 있습니다 (NIST SP 800-53 Rev. 5).
• 귀속성 (Attribution): 에이전트 (agent)가 자기 자신을 설명하는 로그를 작성합니다. 목격자와 피고인이 동일한 프로세스인 셈입니다. 오작동하거나 침해된 에이전트는 구조적으로 깨끗한 로그를 작성합니다.
• 완전성 (Completeness): 감사자 (auditor)에게 도달하는 것은 필터링된 내보내기 (export) 결과물입니다. 즉, 특정 날짜 범위, grep 결과, 또는 대시보드 스크린샷입니다. 특정 항목이 누락된 것이, 애초에 생성되지 않은 것인지, 부하 (load) 상황에서 누락된 것인지, 혹은 삭제된 것인지 구분할 수 없습니다.
• 독립성 (Independence): 검증 (verification)이란 운영자에게 파일을 요청하고 도착한 것을 믿는 것을 의미합니다. 그것은 검증이 아니라 예의 (courtesy)일 뿐입니다.

구조적인 문제: 로그는 독자에게 작성자를 신뢰할 것을 요구합니다. 로그의 품질을 아무리 높여도 이 문제는 해결되지 않습니다. 결함은 내용이 아니라 신뢰의 방향에 있기 때문입니다.

부분적인 해결책들, 그리고 각 해결책의 한계

업계에는 이 문제의 파편들에 대한 훌륭하고 실질적인 해답들이 존재합니다. 각 해결책이 무엇을 얻어다 주는지 정확히 파악할 가치가 있습니다. 왜냐하면 팀들은 저장 (storage) 문제를 해결했을 뿐인데 증거 (evidence) 문제를 해결했다고 흔히 믿기 때문입니다.

• 중앙 집중형 로깅 (Centralised logging) / SIEM. 로그를 생성한 머신 외부로 이동시켜, 단일 침해된 호스트가 로그를 조용히 재작성할 수 없게 만듭니다. 실질적인 개선입니다. 하지만 수집기 (collector)는 여전히 운영자 인프라이므로, 무결성 (integrity)은 이제 호스트가 아닌 수집기에 대한 운영자의 말에 의존하게 됩니다.
• 추가 전용 (Append-only) 및 WORM 스토리지. 스토리지 계층에서의 수정을 방지합니다. 이 또한 실질적인 개선이지만, 운영자가 구성하고 재구성할 수 있으며 당신에게 신뢰를 요구하는 정책에 의해 강제됩니다. 이는 운영자를 제약할 뿐, 외부인이 무엇인가를 검증할 수 있게 하지는 않습니다.
• 해시 체이닝 (Hash chaining). 각 엔트리 (entry)가 이전 엔트리의 해시 (hash)를 확정하므로, 엔트리를 삭제하거나 수정하면 체인이 깨집니다. 이는 Haber and Stornetta (1991) 이후 디지털 타임스탬핑 (digital timestamping)의 기반이 된 아이디어입니다. 이것은 진정으로 강력하며, Traceseal이 영수증 하단에 해시 체인으로 연결된 감사 로그 (audit log)를 유지하는 이유이기도 합니다. 한계점은 다음과 같습니다: 체인은 _내부적 일관성 (internal consistency)_을 증명할 뿐입니다. 체인을 보유한 사람은 체인이 자신의 통제 범위를 벗어난 무언가에 고정 (anchor)되어 있지 않는 한, 체인을 처음부터 끝까지 다시 구축하여 완벽하게 일관된 대안적 역사를 제시할 수 있습니다.
• 신뢰할 수 있는 타임스탬프 (Trusted timestamps) 및 투명성 로그 (transparency logs). 고정 (anchoring) 단계입니다. RFC 3161 타임스탬프는 제3자를 통해 데이터를 특정 시간에 결합하며, RFC 9162 스타일의 머클 트리 (Merkle-tree) 투명성 로그는 두 명의 관찰자에게 서로 다른 두 개의 역사를 보여주는 것을 암호학적으로 어렵게 만듭니다. 이것이 "체인 재구축"의 간극을 메우는 조각입니다.

이 목록을 순서대로 읽어보면 하나의 패턴이 나타납니다. 각 단계는 주장의 근거를 "운영자의 프로세스를 신뢰하라"에서 "수학을 직접 검증하라"로 이동시킵니다. 서명된 영수증은 단일 파일이 전체 논거를 담을 수 있도록 패키징된, 그 여정의 종착점일 뿐입니다.

서명이 추가하는 것

실행 영수증 (execution receipt)은 단일 실행을 기록하는 독립적인 JSON 문서입니다. 즉, 어떤 서명된 코드가 실행되었는지, 무엇을 소비하고 생성했는지 (FIPS 180-4에 따라 데이터를 노출하지 않고 기록의 무결성을 증명할 수 있도록 SHA-256 해시로 기록), 어떤 샌드박스 정책 (sandbox policy) 하에서 실행되었는지, 그리고 해당 전체 데이터에 대한 Ed25519 서명 (RFC 8032)을 포함합니다.

세 가지 설계 선택 사항이 실제로 핵심적인 역할을 수행합니다:

1. 서명은 정형 인코딩 (canonical encoding)을 대상으로 합니다. 모든 레벨에서 키가 정렬되고, 공백이 없으며, 불리언 (boolean)이나 null이 없습니다. 따라서 주어진 영수증은 정확히 하나의 유효한 바이트 시퀀스를 가집니다. 의미적으로는 동일하지만 인코딩 방식이 다른 문서가 통과할 여지는 없습니다. 어디에서든 수정이 발생하면 검증이 깨집니다.
2. 공개 키 (public key)가 영수증 내부에 포함됩니다. 검증은 오프라인 상태에서 독립적으로 이루어집니다. 키 서버, API 호출, 계정, 또는 운영자에 대한 요청이 필요하지 않습니다. 의심하는 자는 의심 대상에게 의존하지 않습니다.
3. 내용이 아닌 해시 (hashes)를 사용합니다. 입력과 출력이 해시로만 나타나기 때문에, 영수증은 설명하는 데이터를 유출하지 않고도 공개될 수 있습니다. 또한 원본 데이터를 보유한 사람이라면 누구나 해시를 다시 계산하여 일치 여부를 확인할 수 있습니다.

네 가지 속성에 비추어 보면 다음과 같습니다: 무결성 (integrity)은 정형 서명에서 오고, 귀속성 (attribution)은 서명한 운영자 키에서 오며, 독립성 (independence)은 오프라인 검증에서 오고, 완전성 (completeness)은 기록을 공개 투명성 로그 (public transparency log)에 고정함으로써 얻어집니다. 마지막 속성은 대부분의 증거 체계가 조용히 건너뛰는 부분이기 때문에 명확히 언급할 가치가 있습니다.

이 형식은 완전히 명시되어 있습니다. 영수증 사양 (receipt specification)은 개발자가 우리의 코드를 건드리지 않고도 어떤 언어로든 검증기 (verifier)를 구현할 수 있도록 작성되었으며, 참조 검증기는 PyPI에서 확인할 수 있습니다:

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

실제 영수증의 필드별 상세 설명과 [OK]가 무엇을 증명하고 무엇을 증명하지 못하는지에 대해서는 AI 에이전트가 실제로 무엇을 했는지 검증하는 방법을 참조하십시오.

이것이 컴플라이언스(Compliance) 문제가 되고 있는 이유

EU AI Act는 이미 기록을 보관하는 것과 그 기록을 뒷받침할 수 있는 능력(stand behind them)을 구분하고 있습니다. Regulation (EU) 2024/1689의 제12조는 고위험 시스템(high-risk systems)이 추적 가능성(traceability)에 적합한 표준에 따라 수명 주기 동안의 이벤트를 자동으로 기록할 수 있도록 요구합니다. 제19조는 제공자(providers)가 자동 생성된 로그를 자신들의 통제하에 보관할 것을 요구합니다. 의무 사항은 추적 가능성을 지원하는 기록을 생성하는 것이며, 기록을 생성하는 당사자가 몰래 재작성할 수 있는 기록은 해당 당사자의 신뢰도가 미치는 범위 내에서만 그 기능을 수행할 뿐입니다.

규정 어디에도 암호화된 영수증(cryptographic receipts)을 의무화하는 내용은 없습니다. 하지만 규제 기관, 기업 고객 또는 보험사에게 추적 가능성을 입증해야 하는 순간이 왔을 때, 로그 내보내기(log export)와 서명된 영수증(signed receipt)의 차이는 단순히 믿어달라고 요청하는 것과 검증을 요청하는 것의 차이와 같습니다.

자신의 스택에 무엇을 요구해야 하는가

• 내부자가 기록을 조작했다면, 우리가 어떻게 알 수 있을까요? 만약 그 답이 해당 내부자의 접근 권한이 올바르게 제한되어 있다는 사실에 의존한다면, 그것은 증거 (evidence)가 아니라 통제 (control)일 뿐입니다.
• 외부자가 우리의 도움 없이 검증할 수 있습니까? 만약 검증을 위해 당신이 파일을 건네주고 상대방이 당신을 믿어주어야 한다면, 그 기록은 당신을 의심하는 사람에게 당신의 선의 (good faith)에 대해 아무것도 증명하지 못합니다.
• 기록이 우리의 통제 범위를 벗어난 곳에 닻을 내리고(anchored) 있습니까? 내부적 일관성 (Internal consistency)은 다시 쓸 수 없는 이력 (unrewritable history)과 동일하지 않습니다.
• 당시에 봉인되었습니까? 영수증 (Receipts)은 실행될 당시에 계측 (instrumented)된 실행만을 다룹니다. 분쟁이 시작된 시점에 시작된 증거 수집은 그 이전에 일어난 일에 대해 아무것도 증명하지 못합니다.

원문은 traceseal.io/blog에 게시되었습니다. 영수증 규격 (receipt spec), 검증기 (verifier), 그리고 투명성 로그 (transparency log)는 공개되어 있습니다 — 저희를 채택하지 않고도 해당 형식을 도입하실 수 있습니다.