AI x Crypto Systems 고지: 이 기사는 편집 보조 도구로서 AI의 도움을 받아 작성되었습니다. 아이디어, 사실, 코드, 출처 및 결론은 사람이 검토했습니다.

AI x Crypto Systems 고지: 이 기사는 기술적 설명이며 투자 조언이 아닙니다. AI x Crypto Systems는 어떠한 암호 자산의 매수, 매도 또는 보유를 권장하지 않습니다.

학습 데이터 출처 (Training Data Provenance)

학습 데이터 출처 (Training Data Provenance)는 데이터셋의 이야기가 잘못되었음에도 불구하고 건강해 보일 수 있습니다. 아래의 사후 분석 (postmortem)에서, 모델 카드 (model card)는 sha256:9f22...를 가리키고 있고, 학습 파일은 변경되지 않았으며, 팀은 여전히 왜 거부 (opt-out) 기록이 학습에 도달했는지 답변할 수 없습니다. 이 사건은 암호학 (cryptography) 문제가 아닙니다. 이 사건은 누락된 매니페스트 차이 (manifest diff) 문제입니다.

사건 (incident): support-classifier-v7
증상 (symptom): 학습 설명 샘플에 거부 (opt-out) 기록이 나타남
데이터셋 해시 (dataset_hash): sha256:9f22...
...

증상 (Symptom)

학습 데이터 출처 (Training Data Provenance)는 표준 (standard)이 아닌 증상 (symptom)에서 시작됩니다. 이 사례의 증상은 사용자가 자신이 거부 (opt-out)한 지원 메시지가 왜 모델 검토 샘플에 나타나는지 묻는 것입니다. 팀은 모델 카드 (model card)를 확인하고, 데이터셋 해시 (dataset hash)를 찾아내며, 다이제스트 (digest)를 재계산하고, 최종 아카이브가 기록된 값과 일치함을 확인합니다. 학습 데이터 출처 (Training Data Provenance)는 바이트 동일성 (byte identity)을 갖추고 있지만, 검토 과정에서는 여전히 해당 기록을 설명할 수 없습니다.

증상이 중요한 이유는 팀이 흔히 혼동하는 두 가지 질문을 분리해주기 때문입니다. 해시는 "우리가 어떤 바이트로 학습했는가?"에 답하지만, 사건은 "왜 이 바이트들이 학습 세트에 존재하도록 허용되었는가?"를 묻습니다. Croissant 1.1은 파일 객체가 sha256 체크섬 (checksum)을 가질 수 있도록 허용하며, 이는 바이트 동일성 (byte identity)을 확인하는 데 유용합니다. 학습 데이터 출처 (Training Data Provenance)는 그러한 기준점 (anchor)이 필요하지만, 그 기준점은 수집 권한, 제외 이력 또는 검토자의 의도를 제공하지 않습니다.

그것이 바로 버그 (bug)입니다.

분류 메모 (Triage Note)

학습 데이터 출처 (Training Data Provenance) 분류 (triage)는 설명을 지어내기 시작하기 전에 이미 알려진 사실을 먼저 기록해야 합니다. 알려진 사실: 최종 파일 해시 (hash)는 안정적입니다. 알 수 없는 사실: 소스 내보내기 (source export)에 제외 목록 (opt-out list)이 포함되었는지, 비식별화 변환 (redaction transform)이 제외 목록 병합 (opt-out merge) 이후에 실행되었는지, 검토자 (reviewer)가 제한 사항을 수락했는지, 그리고 모델 카드 (model card)에 올바른 매니페스트 (manifest)가 복사되었는지 여부입니다. 학습 데이터 출처 (Training Data Provenance)는 이러한 미지의 사실들이 확신에 찬 다이제스트 (digest) 뒤에 숨겨질 때 실패합니다.

따라서 첫 번째 분류 메모 (triage note)는 다음과 같이 작성되어야 합니다:

질문	현재 답변	리스크
최종 파일이 변경되었는가?	아니요; 해시가 일치함	바이트 동일성 (Byte identity)이 문제는 아님
...

이전 매니페스트 (Manifest Before)

문제가 있는 매니페스트 (manifest)를 보여줄 때 학습 데이터 출처 (Training Data Provenance)는 구체화됩니다. 아래의 잘못된 매니페스트는 데이터셋 이름, 최종 다이제스트 (final digest), 그리고 변환 목록 (transform list)을 갖추고 있어 그럴싸해 보입니다. 하지만 여전히 충분하지 않습니다. 소스 정책 (source policy), 제외 증거 (exclusion evidence), 그리고 검토자 상태 (reviewer status)를 설명할 수 있는 필드들이 누락되었거나 모호합니다.

dataset: support-classifier-training
created_at: 2026-05-22T18:10:00Z
source: support-chat-export
...

학습 데이터 출처 (Training Data Provenance)가 이 매니페스트를 거부하는 이유는 YAML 형식이 나쁘기 때문이 아닙니다. 학습 데이터 출처 (Training Data Provenance)가 이 매니페스트를 거부하는 이유는 이 매니페스트가 사고 (incident)에 대해 답할 수 없기 때문입니다. "내부용 (Internal)"은 권리 근거 (rights basis)가 아닙니다. support-chat-export는 소스 기록 (source record)이 아닙니다. dedupe-v1은 제외 목록 (opt-outs)이 제거되었는지 여부를 말해주지 않습니다. 다이제스트 (digest)는 파일이 안정적이라는 것을 말해줄 뿐, 프로세스가 검토 가능했다 (reviewable)는 것을 말해주지 않습니다.

[

]

차이 증거 (Diff Evidence)

학습 데이터 출처 (Training Data Provenance)는 수정 사항이 긴 설명(essay)이 아닌 차이점(diff)일 때 개선됩니다. 아래의 차이점(diff)은 검토 내용을 변경하는 가장 작은 산출물(artifact)입니다. 이는 단순히 더 많은 메타데이터(metadata)를 추가하는 것이 아니라, 누락된 인과 관계(causal links)인 소스 버전(source version), 거부 목록(opt-out list), 권리 정책(rights policy), 편집 변환(redaction transform), 제외 보고서(exclusion report), 검토자 상태(reviewer status), 그리고 해결되지 않은 리스크(unresolved risks)를 추가합니다.

 dataset: support-classifier-training
 created_at: 2026-05-22T18:10:00Z
-source: support-chat-export
...

출처 모델 (Provenance Model)

학습 데이터 출처 (Training Data Provenance)에는 "소스(source)", "변환(transform)", "검토자(reviewer)"라는 단어에 대한 모델이 필요합니다. W3C PROV는 엔티티(entities), 활동(activities), 에이전트(agents)를 통해 출처를 설명하며, 이는 이번 사건에 대한 좋은 사고 모델(mental model)이 됩니다. 지원 내보내기(support export)와 거부 목록(opt-out list)은 엔티티(entities)입니다. 편집(Redaction)과 거부 제거(opt-out removal)는 활동(activities)입니다. 파이프라인(pipeline)과 검토자(reviewer)는 에이전트(agents)입니다. 매니페스트(manifest)가 이러한 역할들을 하나의 source 문자열로 압축하는 대신 명시할 때 학습 데이터 출처 (Training Data Provenance)는 더욱 개선됩니다.

이 모델은 첫날부터 거대한 플랫폼을 필요로 하지 않습니다. 작은 매니페스트(manifest)만으로도 소스 파일(source files), 변환 로그(transform logs), 제외 보고서(exclusion reports), 검토자 결정(reviewer decisions), 그리고 모델 빌드(model builds)를 가리킬 수 있습니다. 중요한 속성은 추적 가능성(traceability)입니다. 검토자는 모델 산출물(model artifact)에서 데이터셋 다이제스트(dataset digest)로, 다시 매니페스트 차이점(manifest diff)을 거쳐 소스 기록(source record)까지 추적할 수 있어야 합니다. 학습 데이터 출처 (Training Data Provenance)는 누군가에게 파이프라인 회의 내용을 기억해달라고 요청하지 않고도 이러한 추적이 가능할 때 유용합니다.

권리 계층 (Rights Layer)

학습 데이터 출처 (Training Data Provenance)에는 권리 계층(rights layer)이 필요합니다. 왜냐하면 다이제스트(digest)는 허용되지 않은 데이터를 완벽하게 보존할 수도 있기 때문입니다. MLCommons는 Croissant 1.1이 기계 실행 가능한 출처(machine-actionable provenance), 어휘 상호 운용성(vocabulary interoperability), 그리고 거버넌스 메타데이터(governance metadata)를 추가한다고 밝히고 있습니다. AI 데이터셋 메타데이터는 단순히 파일을 로드하는 것에 관한 것이 아니기에 이러한 방향성은 중요합니다. 메타데이터는 자동화 시스템이 검사할 수 있는 사용 제한(usage restrictions), 동의 신호(consent signals), 그리고 정책 컨텍스트(policy context)를 반드시 포함해야 합니다.

권리 계층(rights layer)은 과도한 약속을 해서는 안 됩니다. rights_basis: internal-use-policy-2026-04라고 명시된 매니페스트 필드가 모든 출처 주장(source claim)이 사실임을 증명하는 것은 아닙니다. 이는 해당 빌드(build)가 검토자가 이의를 제기할 수 있는 선언된 권리 근거(rights basis)를 가졌음을 증명할 뿐입니다. 학습 데이터 출처(Training Data Provenance)는 기록된 데이터 스토리(data story)를 증명하는 것이지, 그 스토리의 모든 문장이 도덕적 또는 법적으로 진실임을 증명하는 것이 아닙니다. 이러한 겸손함이 암호화된 약속(crypto commitments)이 단순한 컴플라이언스 연극(compliance theater)으로 전락하는 것을 방지합니다.

변환 계층 (Transform Layer)

학습 데이터 출처(Training Data Provenance)는 보통 변환 계층(transform layer)에서 실패합니다. 거부 목록(opt-out list)이 존재할 수는 있지만, 변환(transform) 과정이 해당 목록이 결합(join)되기 전에 실행될 수 있습니다. 비식별화(redaction) 단계가 존재할 수 있지만, 영어에 대해서만 적용될 수 있습니다. 중복 제거(deduplication)가 존재할 수 있지만, 유사 중복(near-duplicate)을 통해 기록을 보존할 수도 있습니다. Datasheets for Datasets는 제작자에게 동기(motivation), 구성(composition), 수집(collection), 전처리(preprocessing), 용도(uses), 배포(distribution) 및 유지 관리(maintenance)를 문서화하도록 요구하기 때문에 여전히 유효합니다. 학습 데이터 출처(Training Data Provenance)는 이러한 질문들을 빌드 아티팩트(build artifacts)로 전환합니다.

변환 계층(transform layer)에는 정확한 명칭이 필요합니다. clean-data만으로는 부족합니다. pii-redaction-v3나 opt-out-removal-v2와 같이 검토 가능한 명칭이어야 합니다. dedupe만으로는 부족합니다. dedupe-v2 threshold=0.84와 같이 검토 가능한 명칭이어야 합니다. 학습 데이터 출처(Training Data Provenance) 매니페스트는 "거부 목록(opt-out list)이 로드된 후에 제외 단계(exclusion step)가 실행되었는가?"라는 질문을 재현할 수 있도록 만들어야 합니다.

빌드 링크 (Build Link)

학습 데이터 출처(Training Data Provenance)는 모델 빌드(model build)가 수정된 매니페스트(repaired manifest)와 다시 연결될 때에만 사고(incident)를 종결합니다. 빌드 기록(build record)에는 코드 버전(code version), 데이터셋 매니페스트 해시(dataset manifest hash), 학습 구성(training configuration), 평가 세트(evaluation set), 모델 아티팩트 해시(model artifact hash) 및 검토자 상태(reviewer status)가 포함되어야 합니다. 이러한 연결이 없다면, 수정된 매니페스트는 모델 근처에 있는 단순한 문서일 뿐, 모델의 증거 체인(evidence chain)의 일부가 아닙니다.

Data Provenance Initiative 논문은 왜 이 지루해 보이는 연결이 중요한지를 보여줍니다. 대중적인 AI 데이터셋들은 누락되거나, 일관성이 없거나, 불분명한 라이선스(licensing) 및 출처 표기(attribution) 메타데이터를 가질 수 있기 때문입니다. 학습 데이터 출처(Training Data Provenance)는 메타데이터가 불완전할 수 있음을 가정하고 불확실성을 명시적으로 보존해야 합니다. unresolved_risks라고 불리는 필드는 약점이 아닙니다. 이는 다음 검토자에게 어디까지를 과도하게 주장해서는 안 되는지 알려주는 영수증의 일부입니다.

검토자 상태 (Reviewer Status)

자동화가 모든 판단을 대신할 수 없기 때문에, 학습 데이터 출처(Training Data Provenance)에는 검토자 상태(reviewer status)가 필요합니다. 검토자는 소스를 수락(accepted), 거부(rejected), 격리(quarantined), 또는 제한적 수락(accepted with limits)으로 표시할 수 있어야 합니다. 이 차이는 매우 중요합니다. 수락(Accepted)은 해당 소스가 선언된 용도에 적합함을 의미합니다. 제한적 수락(Accepted with limits)은 모델 소유자가 모델 카드(model card)에 주의 사항(caveat)을 포함해야 함을 의미합니다. 격리(Quarantined)는 특정 조건이 해결될 때까지 해당 데이터가 학습에 사용되어서는 안 됨을 의미합니다.

검토자 상태는 향후 사고 대응자(incident responder)가 읽어야 할 첫 번째 방어선이기도 합니다. 만약 분쟁이 발생한 기록이 '제한적 수락'으로 표시된 소스에서 유래했다면, 대응자는 해당 리스크가 이미 인지되었음을 알 수 있습니다. 만약 소스가 검토된 적이 없다면, 대응자는 프로세스가 실패했음을 알 수 있습니다. 학습 데이터 출처(Training Data Provenance)는 누락된 검토 상태를 최종 아카이브 요약(archive digest) 뒤에 숨기는 것이 아니라, 가시화해야 합니다.

격리 단계 (Quarantine Step)

매니페스트(manifest)가 사용자 대상 사고에 대해 답을 줄 수 없는 경우, 학습 데이터 출처(Training Data Provenance)는 격리 단계(quarantine step)를 포함해야 합니다. 격리가 모델 전체를 즉시 삭제해야 한다는 의미는 아닙니다. 이는 누락된 소스, 권리, 변환(transform), 그리고 검토자 필드가 해결될 때까지 분쟁이 있는 소스를 새로운 학습에 사용할 수 없음을 의미합니다. 이 단계는 운영 태세를 "우리는 해시(hash)를 가지고 있다"에서 "우리는 어떤 증거가 누락되었는지 알고 있다"로 변화시킵니다.

격리 기록(quarantine record)은 작을 수 있지만, 수정된 매니페스트(manifest)와는 반드시 분리되어야 합니다:

quarantine:
  source_record: support-chat-export@2026-05-22
  trigger: opt-out record found in model-review sample
...

학습 데이터 출처(Training Data Provenance)는 진실이 아닌 절제(restraint)를 증명하기 위해 격리(quarantine)를 사용합니다. 이 기록은 팀이 설명이 부족한 데이터셋을 '깨끗한 데이터'로 취급하는 것을 중단했음을 증명합니다. 이것이 논란이 된 기록이 악의적으로 포함되었음을 증명하는 것도 아니며, 수정된 파이프라인(pipeline)이 완벽하다는 것을 증명하는 것도 아닙니다. 그 가치는 더 좁지만 더 유용합니다. 즉, 다음 모델 빌드(model build) 시 동일한 취약한 매니페스트를 조용히 재사용할 수 없게 만든다는 점입니다.

이 짧은 격리 단계는 팀 내부의 인센티브(incentives)를 변화시킵니다. 격리가 없다면 가장 쉬운 길은 학습을 계속 진행하면서 데이터셋은 나중에 문서화하겠다고 약속하는 것이며, 이것이 바로 출처 부채(provenance debt)가 영구적으로 남게 되는 방식입니다. 격리가 도입되면 누락된 매니페스트 필드(manifest fields)는 단순한 정리 작업(housekeeping tasks)이 아닌 릴리스 차단 요소(release blockers)가 됩니다. 학습 데이터 출처(Training Data Provenance)는 부분적으로는 기술적 산물(technical artifact)이며, 부분적으로는 강제 함수(forcing function)입니다. 모델 소유자는 증거를 첨부하거나, 해당 데이터셋이 다음 빌드를 지원할 수 없음을 인정해야만 합니다.

모델 카드 패치 (Model Card Patch)

학습 데이터 출처(Training Data Provenance)는 매니페스트가 수정된 후 모델 카드(model card)를 패치(patch)해야 합니다. 단순히 dataset_hash=sha256:9f22...만을 나열하는 모델 카드는 나중에 동일한 실패를 초래할 수 있습니다. 패치된 모델 카드에는 매니페스트 해시(manifest hash), 소스 세트(source set), 변환 세트(transform set), 검토자 상태(reviewer status), 미결 위험(unresolved risks), 그리고 격리 이력(quarantine history)이 있다면 이를 포함해야 합니다. 모델 카드가 문서에 전체 매니페스트를 쏟아부을 필요는 없습니다. 해시를 설명할 수 있는 증거를 가리키기만 하면 됩니다.

유용한 모델 카드 라인은 구체적입니다: training_manifest=sha256:4d81c0ee; reviewer_status=accepted_with_limits; unresolved_risks=legacy tickets before consent-policy migration. 이 라인은 보기 좋지는 않지만, 검색 가능하고 검토 가능합니다. 모델 아티팩트(model artifact)가 미래의 사고 대응자(incident responder)가 Slack 고고학(Slack archaeology) 없이도 데이터의 맥락을 재구성할 수 있도록 충분한 포인터(pointers)를 제공할 때, 학습 데이터 출처(Training Data Provenance)는 더욱 개선됩니다.

사후 분석 마무리 (Postmortem Close)

학습 데이터 출처(Training Data Provenance)는 단순히 "해시(hash)가 있었다"라는 말보다 훨씬 더 유용한 문장으로 이번 사고를 종결짓습니다. 더 나은 문장은 다음과 같습니다: pii-redaction-v3, opt-out-removal-v2, dedupe-v2 과정을 거친 후, 2026-05-22 날짜의 소스 내보내기(source export) 및 거부 목록(opt-out list)을 기반으로 생성된 매니페스트(manifest) 4d81c0ee로 학습된 모델 support-classifier-v7. 리뷰어 상태는 accepted_with_limits이며, 두 개의 미해결 리스크(unresolved risks)가 존재함. 이 문장이 긴 이유는 실제 데이터의 이야기가 길기 때문입니다.

마지막 교훈은 명확합니다. 학습 데이터 출처(Training Data Provenance)는 해시(hash)를 유지해야 하지만, 해시는 영수증의 마지막 줄일 뿐 영수증 그 자체는 아닙니다. 다이제스트(digest)는 바이트 드리프트(byte drift)를 포착합니다. 매니페스트 차이(manifest diff)는 프로세스 드리프트(process drift)를 포착합니다. 모델 소유자는 다음 사용자가 왜 자신의 기록이 학습 세트에 포함되었는지 묻기 전에 이 두 가지가 모두 필요합니다.