해시가 맞아도 검수는 낡을 수 있다: AI 산출물과 근거의 연결
산출물 해시·검사 대상·승인 범위를 함께 연결한다. 검수 뒤 파일이 바뀌는 사례를 통해 서명된 기록과 내용 품질의 차이를 설명한다.
컴파일이 잘 되는 코드나 깔끔한 문서만 봐서는 어떤 입력과 도구를 사용했는지, 사람이 무엇을 확인했는지 알 수 없다. 이 과정을 추적하려면 산출물에 입력·실행·검증·승인 기록을 연결해야 한다.
DOCX 초안을 HWP 양식에 채우는 자동화 작업이라면 원문에 없던 저자 정보가 생기지 않았는지, 참고문헌이 바뀌지 않았는지, 모든 페이지를 검수했는지 기록해야 한다.
“AI가 만들었다”는 라벨 대신 그 결과를 만들어낸 경로를 확인할 수 있어야 한다.
| 기록 | 포함할 근거 |
|---|---|
| 입력 | 원본 해시·지시 식별자 |
| 실행 | 도구 호출·재시도·버전 |
| 검증·승인 | 실제 검사 결과·승인 주체 |
| 산출물 연결 | 산출물 해시·manifest·감사 로그 |
해시는 파일의 상태만 알려준다
산출물의 SHA-256 해시를 남기면 파일이 나중에 바뀌었는지 확인할 수 있다. 하지만 해시는 생성 과정을 설명하지 않는다. 잘못된 입력으로 만든 결과에도 정상적인 해시는 붙는다.
소프트웨어 공급망의 SLSA provenance는 산출물이 어디서, 언제, 어떤 빌드 과정을 거쳤는지 검증 가능한 정보로 남긴다. GitHub의 artifact attestation도 빌드 결과를 저장소와 워크플로에서 생성된 서명된 주장에 연결한다. 산출물과 생성 과정을 분리하지 않는 방식이다.
문서에도 같은 모델을 적용할 수 있다. 결과물인 HWP의 해시와 원본 DOCX·HWP의 해시, 사용한 kordoc 버전, 실행한 작업, 검증 결과, 승인자를 함께 기록한다. 이 정보를 문서 본문에 모두 넣을 필요는 없다. 별도의 manifest나 감사 로그로 연결하면 된다.
에이전트 작업에 남길 네 종류의 기록
입력 provenance에는 사용한 파일과 지시를 적는다. 민감한 원문을 로그에 복제하기보다 파일 해시와 안전한 식별자를 남긴다.
실행 provenance는 모델 이름보다 구체적이어야 한다. 호출한 도구와 순서, 각 단계의 성공 여부, 재시도나 우회 내역을 기록한다. 에이전트 추적 시스템의 trace가 이 역할을 맡아 모델 호출, 도구 호출, handoff, guardrail 결과를 하나의 실행 경로로 연결한다.
검증 provenance에는 실제로 수행한 검사 내역을 담는다. 코드는 테스트와 정적 분석·빌드 결과를, 문서는 구조 검증·필수 내용 대조·페이지 수·렌더링 경고·시각 검수 결과를 포함한다. 단순히 “검수 완료”라고 남기기보다 통과한 검사를 기계가 읽을 수 있는 형태로 기록한다.
승인 provenance는 에이전트가 제안한 변경과 사람이 승인한 변경을 구분한다. 문서의 저자 정보나 코드의 배포 권한처럼 책임이 따르는 항목에서는 자동 생성과 최종 승인을 같은 사건으로 처리하면 안 된다.
문서 자동화에서 참고할 C2PA의 관점
C2PA는 이미지, 영상, 오디오뿐 아니라 문서를 포함한 디지털 콘텐츠의 출처와 편집 이력을 안전하게 결합하는 기술 표준을 다룬다. 모든 HWP 문서에 C2PA를 바로 적용할 수 있다는 뜻은 아니다. 다만 누가 만들었고 어떤 편집을 거쳤는지, 그 주장을 콘텐츠와 어떻게 묶을지에 관한 관점은 문서 자동화에도 유용하다.
문서용 manifest는 다음과 같은 예시 구조로 시작할 수 있다. 실제 결과가 없는 필드는 null로 두고 검증·승인 뒤에만 값을 기록한다.
이 기록이 문서의 사실성을 보증하지는 않는다. 어떤 근거와 절차를 거쳤는지 확인하게 해주는 장치에 가깝다. provenance는 품질 검사를 대신하지 않으며, 품질 검사가 실제로 수행됐다는 주장을 검증 가능한 형태로 남긴다.
{
"artifact": {
"name": "완성본.hwp",
"sha256": "..."
},
"inputs": [
{ "role": "content", "name": "초안.docx", "sha256": "..." },
{ "role": "template", "name": "양식.hwp", "sha256": "..." }
],
"tool": { "name": "kordoc", "version": "..." },
"checks": {
"pageCount": null,
"twoColumnLayout": null,
"renderedAllPages": null,
"inventedAuthorMetadata": null
},
"approvedByHuman": null
}검증 기록을 실제 산출물에 연결하기
같은 모델도 입력 파일·도구 권한·검증 절차에 따라 다른 결과를 만든다. 모델 이름은 실행 조건 중 하나로 기록하고, 결과의 신뢰 여부는 실제 검사와 승인 근거로 판단한다.
원본 파일, 에이전트가 수정한 파일, 위험 작업 차단 방식, 통과한 테스트와 렌더링, 최종 승인 주체를 구체적으로 확인해야 한다.
우선 산출물과 입력의 해시, 실제 검사 결과, 승인 주체를 같은 실행 ID로 연결한다. 수행하지 않은 검사는 빈 상태로 남기고, 파일이 바뀌면 무효가 된 검증 기록을 확인해야 한다.
가상의 보고서 A를 모든 페이지에 걸쳐 검수한 뒤 마지막 표의 숫자를 수정해 보고서 B를 만들었다고 하자. B의 해시를 새로 계산했다고 해서 A의 검수 결과가 B에도 적용되지는 않는다. 검수 기록이 가리키는 해시와 최종 배포 파일의 해시를 대조해야 한다. 두 해시가 다르면 어떤 검사가 무효가 됐는지 확인하고 영향받는 검사를 다시 수행한다. 단순히 manifest의 파일 해시만 교체하면 낡은 PASS 기록을 새 파일에 붙이는 오류가 생긴다.
서명에도 같은 한계가 있다. 신뢰하는 실행 주체가 ‘검사 X를 수행했다’는 기록에 서명하면 그 주체와 기록의 연결을 확인할 수 있다. 그러나 검사 X가 잘못 설계됐거나 입력 사실이 틀렸다면 서명이 내용까지 참으로 바꾸지는 못한다. 파일 무결성, 기록의 발행 주체, 검사의 적합성을 나누어 판단해야 한다.
최소 기록은 입력 식별자, 산출물 해시, 검사 이름·버전·대상 해시·결과, 승인 대상 해시를 같은 실행에 연결하는 것이다. 수행하지 않은 검사와 실패한 검사를 모두 false 하나로 합치지 않고 미실행·실패·통과를 구분한다. 재시도할 때는 이전 실패 기록을 지우지 않고 새 시도로 연결하면 최종 성공에 이르기까지의 경로를 추적할 수 있다.
참고 자료
SLSA Provenance (https://slsa.dev/provenance (새 창))
GitHub Artifact Attestations (https://docs.github.com/actions/security-for-github-actions/using-artifact-attestations/using-artifact-attestations-to-establish-provenance-for-builds (새 창))
C2PA Technical Specification (https://spec.c2pa.org/specifications/specifications/2.4/specs/C2PA_Specification.html (새 창))
OpenAI Agent Evals (https://developers.openai.com/api/docs/guides/agent-evals (새 창))
kordoc GitHub 저장소 (https://github.com/chrisryugj/kordoc (새 창))
