2026년 말입니다. 유럽의 한 대출 기관에 있는 AI 시스템이 지난 4월 한 소비자의 대출 신청을 거절했습니다. 신청자는 불만을 제기했고, 감독관은 이제 다음과 같은 간단한 질문을 던집니다.

시스템이 무엇을 결정했는지, 어떤 근거로 결정했는지 보여주세요. 그리고 이 기록이 생성된 이후로 변경되지 않았음을 증명하세요.

당신은 로그(logs)를 확인합니다. 그리고 불편한 진실을 마주하게 됩니다. 로그는 아주 많지만, 그 중 어느 것도 그 질문에 답하지 못한다는 사실입니다.

당신이 가진 로그는 잘못된 로그입니다

대부분의 AI 배포(deployments)는 두 종류의 로그를 생성합니다. 애플리케이션 로그(Application logs)는 API 호출과 지연 시간(latency)을 기록합니다. 추론 로그(Inference logs)는 모델의 입력 및 출력 토큰을 기록합니다. 둘 다 디버깅(debugging)에는 유용합니다. 하지만 규제 기관, 감사인, 또는 법원이 실제로 묻는 것, 즉 결정(the decision) — 누가, 어떤 권한으로, 어떤 근거로 결정했으며, 그 후에 어떤 일이 일어났는지에 대해서는 어느 것도 포착하지 못합니다.

EU AI Act 제12조는 고위험(high-risk) AI 시스템이 시스템의 수명 주기 동안 이벤트를 자동으로 기록할 것을 요구합니다. 신용 점수 산정, 채용, 보험 가격 책정 및 혜택 결정은 부속서 III(Annex III)에 해당하며, 고위험 의무 사항들은 2026년과 2027년에 걸쳐 적용됩니다. 배포자(Deployers)는 해당 로그를 최소 6개월 동안 보관해야 하며, 기존 기록 보관법이 적용되는 금융 분야에서는 더 오래 보관해야 합니다.

여기에 공백이 있습니다. 제12조는 '목적'에 대해서는 명확하지만, '메커니즘(mechanics)'에 대해서는 거의 침묵하고 있습니다. 제12조는 형식을 지정하지 않습니다. 무결성(integrity)에 대한 책임이 누구에게 있는지도 명시하지 않습니다. 그리고 **변조 방지(tamper-evident)**라는 단어도 사용하지 않습니다. 하지만 사후에 조용히 편집될 수 있는 로그가 증거로서 어떤 가치가 있을지 생각해 보십시오. 결정을 내린 동일한 시스템이 그 기록을 작성하고, 심지어 다시 쓸 수도 있다면, 그 기록은 시스템이 자신에 대해 들려주는 이야기에 불과합니다. 그 증거적 가치는 거의 제로에 가깝습니다.

로그는 _"나를 믿으세요, 이것이 일어난 일입니다"_라고 말합니다. 증거는 _"나를 믿을 필요 없습니다. 여기 증거가 있습니다"_라고 말합니다. 그 차이가 문제의 핵심이며, 현재 제대로 다뤄지지 않고 있습니다.

증명을 위해 설계된 결정 기록(decision record)의 모습

이 간극을 메우는 방법은 이미 잘 알려져 있습니다. 웹이 스스로를 보호하는 방식(Certificate Transparency, RFC 6962)과 투명성 로그(transparency logs)가 무결성(integrity)을 증명하는 방식에서 빌려온 것입니다. 즉, 기록을 추가만 가능한(append-only) 상태로 유지하고, 각 완성된 기록을 머클 트리(Merkle tree)로 해싱하는 것입니다. 이때 로그 내 기록의 위치를 해싱된 리프(leaf) 노드 _내부_에 결합함으로써, 그 어떤 것도 몰래 순서를 바꾸거나 다시 쓸 수 없게 만듭니다. 그러면 생성 주체를 신뢰하지 않고도, 누구나 공개된 작은 루트(root)를 통해 개별 기록을 검증할 수 있습니다. 기록 중 단 1바이트만 변경되어도 수학적 계산이 맞지 않게 됩니다. 조작은 자동으로 드러나게 됩니다.

**Open Decision Standard (ODS)**는 이를 _결정(decisions)_에 정확히 적용합니다. 아래는 의존성 없는 약 250줄 분량의 참조 데모(reference demo)에서 실제로 출력된 결과물입니다. 이 데모는 신용 점수 산정 거절 사례를 기록하고, 이를 앵커링(anchoring)하며, 증명한 다음, 이를 조작해 봅니다.

[1] DECISION recorded
    record_id : loan-2026-04-19-0098
    authority : policy_hash 58f7a207e5617d78… (어떤 규칙이 적용되었는지)
...

(해시 값은 실행할 때마다 달라집니다. 기록에 타임스탬프가 찍히기 때문입니다. 따라서 재현되는 것은 정확한 숫자가 아니라 동작 방식이며, 증명은 유효합니다.)

추론 로그(inference log)에는 절대 포함되지 않는 결정 기록(decision record)만의 요소를 주목하십시오. 결정이 실행된 근거인 권한(authority) (적용된 정책의 해시), 근거(rationale), 조치(action), 그리고 그 바로 뒤에 parent_id로 연결되어 추가된 **결과(outcome)**가 있습니다. 각 기록에 저장소로부터 할당된 일련번호는 해싱된 리프 노드 내부에 존재하므로, 로그 내에서의 위치 자체가 증명 대상의 일부가 됩니다. 이것이 바로 사후에 파편들을 모아 재구성하는 것이 아니라, 기록으로서 포착된 책임성(accountability) 계층입니다.

이제 중요한 부분입니다. 누군가 저장된 결정을 수정합니다. 거절(rejection)을 승인(approval)으로 조용히 뒤바꿉니다:

[5] 이제 누군가 저장된 결정을 조용히 수정합니다: REJECT -> APPROVE
    편집된 저장 기록을 바탕으로 리프(leaf) 재계산됨
    무결성 검사 (integrity check)       : FAIL — 편집으로 인해 리프가 변경됨; 증명(proof)이 더 이상 루트(root)와 일치하지 않음
...

위조할 별도의 무결성 필드는 존재하지 않습니다. 정전(canonical) 저장 기록 자체가 리프의 사전 이미지(pre-image)이기 때문입니다. 수정 사항은 수학적으로 가시적입니다. 체크포인트 루트(checkpoint root)를 보유한 사람이라면 누구라도 — 규제 기관, 감사인, 신청인의 변호사 등 — 운영자를 신뢰할 필요도 없고 나머지 기록에 접근할 필요도 없이 이를 탐지할 수 있습니다. 기록이 증거가 된 것입니다.

이것이 위치하는 지점

기술 환경은 빠르게 변화하고 있으며, ODS는 의도적으로 그 모든 것을 독점하려 하지 않습니다. IETF와 Linux Foundation는 에이전트 정체성(agent-identity) 및 위임 출처(delegation-provenance) 계층, 즉 어떤 에이전트가 누구의 권한으로 행동했는지를 구축하고 있습니다. ODS는 그 상위 계층입니다. 즉, 무엇이, 어떤 근거로, 어떤 결과로 결정되었는지에 대한 검증 가능한 기록입니다. ODS는 이 새롭게 부상하는 스택을 대체하기 위해서가 아니라, 상호 운용하기 위해 설계되었습니다. 제12조는 모든 이에게 기록을 보관하라고 말했지만, 마침내 누군가 질문을 던졌을 때 그 기록들을 가치 있게 만드는 방법까지 알려주지는 않았습니다. 그것이 바로 ODS가 채우기 위해 구축된 공백입니다.

직접 실행해보고 잘못된 점을 알려주세요

ODS는 오픈 표준(Apache 2.0)입니다. 레퍼런스 데모는 의도적으로 매우 작게 만들어졌으며 의존성이 전혀 없습니다(Python 3.9+ 이상, 표준 라이브러리만 사용). 따라서 모든 코드를 읽고 마법 같은 요소가 없음을 확인할 수 있습니다. 오직 정전 기록(canonical records), 도메인 분리된 머클 리프(domain-separated Merkle leaves, RFC 6962), 그리고 책임성(accountability)을 담고 있는 이벤트에 적용된 포함 증명(inclusion proofs)만이 존재합니다.

git clone https://github.com/ODS-Foundation/ods-specification
cd ods-specification/examples/quickstart
python orpi_demo.py

전체 스키마 (schema), 참조 검증기 (reference validator), 그리고 표준에 따른 구현을 인증하는 적합성 스위트 (conformance suite)가 동일한 저장소(repository)에 포함되어 있습니다. 이 스위트는 정직하고 범위가 제한된 (scope-qualified) 판정을 내리며, 자신이 증명할 수 있는 것 이상의 것을 증명한다고 주장하지 않습니다.

만약 귀하가 AI 거버넌스 (AI governance), 컴플라이언스 (compliance), 레그테크 (RegTech) 분야에서 종사하거나, EU 내에서 고위험 (high-risk) AI를 구축 또는 구매한다면, 귀하의 솔직한 피드백을 부탁드립니다. 데모를 실행해 보고 모델이 어디에서 깨지는지, 제가 놓치고 있는 선행 기술 (prior art)이 무엇인지, 혹은 위협 모델 (threat model)이 어디서 틀렸는지 알려주십시오. 그러한 비판은 현재 이 표준에 있어 동의보다 훨씬 더 유용합니다.