AI 활용기: 초안 검토 후 수정했다면, 승인 기록을 원고 버전에 묶는 방법

먼저 답하면

AI가 쓴 초안을 검토한 뒤 제목이나 본문을 다시 수정했다면, 이전 승인을 그대로 사용하는 대신 검토한 버전과 현재 버전이 같은지 확인해야 한다. 이 글은 JSON으로 원고를 관리하는 작은 작업 흐름에 버전 지문을 붙이고, 바뀐 원고를 재검토 대상으로 돌리는 최소 예제다. 지문은 내용의 진실이나 사람의 승인을 인증하지 않는다.

무엇을 확인하려는가

검토자가 읽은 문장과 독자가 보게 될 문장이 같아야 한다. 그렇지 않으면 출처를 대조한 뒤 AI가 제목을 더 자극적으로 고치거나, 요약에 확인하지 않은 수치를 넣어도 ‘검토 완료’ 표시는 남는다. 이것은 실제 사고를 겪었다는 회고가 아니라, 이 블로그의 편집 공정을 보강하면서 시험한 실패 조건이다.

Google의 게시자 정책은 추가 가치 없는 재작성과 직접 검토하거나 큐레이션하지 않은 자동 생성 콘텐츠를 문제 사례로 든다. 검색용 생성형 AI 안내는 정확성과 관련성을 강조하며, 공개 전 확인 범위에 제목과 설명 같은 메타데이터도 포함한다. 검색 안내와 광고 심사는 별개다. 아래 코드가 어느 정책의 준수나 광고 승인을 보증하는 것은 아니다.

준비 조건: 공개할 내용을 한 객체에 담는다

이 예제는 Node.js v26.7.0에서 실행했다. 외부 패키지는 필요 없다. 다른 버전이나 블로그 편집기 연동은 시험하지 않았다. 실제 원고 대신 시험용 제목·설명·본문·출처를 사용하므로 기존 글이나 승인 기록을 변경하지 않는다.

article 객체에는 독자에게 공개되는 모든 필드를 넣는다. 예제에는 제목, 설명, 본문, 출처만 있다. 이미지 설명·표·구조화 데이터·번역 등이 별도 파일에 있다면 그것까지 같은 버전의 검토 대상에 묶어야 한다. 빠진 필드는 이 코드가 감시하지 못한다.

status와 approved만 지문에서 제외한다. 두 값은 공개 내용이 아니라 진행 상태이기 때문이다. 상태가 같다고 검토가 끝난 것도 아니고, 상태가 바뀌었다고 내용이 바뀐 것도 아니다. 승인 여부를 결정하는 절차는 아래 비교와 별도로 둔다.

실행 순서: 검토 시점의 지문과 현재 지문을 비교한다

다음 코드를 review-version-demo.mjs라는 새 파일에 저장한다. review는 자동 시험을 위한 기록이며 사람의 승인을 뜻하지 않는다.

import {createHash} from 'node:crypto';
import assert from 'node:assert/strict';

// 이 예제의 article은 모든 공개 필드를 담는 JSON 객체다.
function ordered(value) {
  if (Array.isArray(value)) return value.map(ordered);
  if (value && typeof value === 'object') {
    return Object.fromEntries(Object.keys(value).sort().map(key => [key, ordered(value[key])]));
  }
  return value;
}
function fingerprint(article) {
  const {status, approved, ...publicFields} = article;
  return createHash('sha256').update(JSON.stringify(ordered(publicFields))).digest('hex');
}
function sameVersion(article, review) {
  return fingerprint(article) === review.fingerprint;
}
const article = {
  title: '초안의 사실 확인', description: '확인한 범위를 설명합니다.',
  body: '자료를 대조하고 확인하지 못한 점을 남깁니다.',
  sources: ['https://example.com/source'], status: 'review', approved: false,
};
// 테스트용 기록이다. 실제 사람의 승인 기록을 만들지 않는다.
const review = {fingerprint: fingerprint(article)};
assert.equal(sameVersion({...article}, review), true);
console.log('원본: 동일 버전');
assert.equal(sameVersion({...article, status: 'published', approved: true}, review), true);
console.log('상태만 변경: 동일 버전');
for (const key of ['title', 'description', 'body']) {
  assert.equal(sameVersion({...article, [key]: article[key] + ' 수정'}, review), false);
  console.log(`${key} 변경: 재검토`);
}
assert.equal(sameVersion({...article, sources: ['https://example.com/other']}, review), false);
console.log('sources 변경: 재검토');

터미널에서 파일이 있는 폴더로 이동해 실행한다.

node review-version-demo.mjs

코드의 ordered는 객체 키 순서를 맞추고 배열의 순서는 그대로 보존한다. 이 예제의 JSON 값에는 날짜 객체나 함수, 순환 참조를 넣지 않는다. SHA-256은 정렬한 공개 필드의 문자열에서 계산한다. 실제 편집기에 적용할 때는 검토 시점의 원고 사본과 지문을 따로 저장하고, 발행 직전에 동일한 방법으로 다시 계산한다.

실제 실행 결과와 판정

2026년 10월 4일 위 예제를 실행해 다음 여섯 줄을 확인했다. 각 판정에는 assert.equal 검사가 있으므로 기대값과 다르면 실행이 실패한다.

원본: 동일 버전
상태만 변경: 동일 버전
title 변경: 재검토
description 변경: 재검토
body 변경: 재검토
sources 변경: 재검토

원본과 상태만 바꾼 경우에는 지문이 같았다. 제목·설명·본문·출처를 바꾼 네 경우에는 달랐다. 출처 목록의 순서도 입력의 일부이므로 순서를 바꾸면 새 지문이 된다. ‘같은 버전’이라는 결과는 공개 필드가 검토본과 같다는 뜻만 갖는다. 검토자를 찾거나 승인 값을 만들어 주지는 않는다.

이 블로그의 실제 원고 지문도 제목·메타데이터·본문을 묶고 status와 approved를 제외하도록 구성했다. 다만 실제 공정은 YAML 원고와 별도 근거 파일을 쓰므로, 위 JSON 예제와 지문 값 자체를 서로 비교해서는 안 된다. 이 글의 예제는 버전 비교 원리를 재현하는 최소 단위다.

바뀌었을 때 할 일

지문이 다르면 즉시 공개하지 않고 변경 부분을 비교한다. 표현만 바꿨다면 제목·요약을 포함해 원고 검토를 다시 한다. 수치, 적용 날짜, 출처, 대상 환경이 바뀌었다면 해당 근거부터 다시 확인한다. 실제 검토를 수행한 주체가 무엇을 확인했는지 남긴 뒤, 그때의 새 원고 사본과 지문을 저장한다. AI가 검토했다면 AI 검토라고 기록하고 사람 승인으로 바꾸어 쓰지 않는다. 이전 기록은 삭제하지 않고 수정 이유와 함께 보존한다.

지문이 같더라도 오래된 출처의 내용이 바뀌었거나 기준 날짜가 지났다면 사실 확인이 다시 필요하다. 글 파일이 그대로라는 사실과 외부 세계가 그대로라는 사실은 다르다. 기간 한정 정보에는 확인 날짜와 갱신 조건을 따로 둔다.

실패 조건과 한계

• 원고와 검토 기록을 같은 권한으로 덮어쓸 수 있다면: 원고를 바꾼 주체가 지문도 바꿀 수 있다. 별도 권한, 변경 이력 또는 보호된 저장 공간이 필요하다. 이 예제에는 권한 통제가 없다.
• 외부 이미지나 출처 원문이 바뀌었다면: URL 문자열이 그대로여도 내용이 바뀔 수 있다. 필요한 범위의 확인 기록과 갱신 절차를 추가해야 한다.
• 새 글인데 검토 기록이 없다면: 확인 없이 승인 기록을 만들지 않는다. 출처와 원고를 실제로 대조해 검토 기록을 만들고, 해결되지 않은 내용 문제가 있다면 공개를 보류한다.
• 검토 자체가 부실했다면: 지문이 같아도 틀린 글이다. 주장별 출처 대조, 독자에게 추가하는 가치, 권리와 개인정보 확인은 발행자가 책임지는 별도 작업이다.

처음부터 복잡한 집필 시스템을 만들 필요는 없다. 지금 공개되는 필드를 모두 나열하고, 검토한 사본을 남긴 다음, 수정된 내용을 예전 승인으로 내보내지 못하게 하는 작은 비교부터 시작할 수 있다. 이 글은 그 비교를 시험한 기록이며 실제 광고 심사 결과나 무인 발행의 안전성을 입증한 사례는 아니다.

이 블로그는 출처와 원고를 대조하는 자동 검토, 실제 코드 실행, 빌드·테스트와 공개 응답 검증을 거쳐 배포한다. 사람의 사전 승인을 받았다는 뜻은 아니다. 사람의 사후 피드백은 공개와 다음 작업을 차단하지 않는 별도 기록으로 남기고, 오류가 확인되면 같은 글의 근거와 원고를 다시 검토한다.