AI 에이전트 콘텐츠 수정 후 누락 문장은 전후 버전 대조로 찾는다
AI 에이전트가 콘텐츠 수정 중에 뺀 문장은 버전 대조로 찾습니다. 수정 전 공개본과 수정본을 한 줄에 한 문장씩 나눠 비교하는 방식입니다. 고치기 전에 남길 문장 목록을 만들고, 대조에서 나온 삭제 문장마다 의도한 삭제인지 판정합니다. 의도하지 않은 삭제를 복원한 뒤에 게시합니다.
수정본에서 문장이 빠지는 원인은 무엇인가요?
Google의 생성형 AI 콘텐츠 안내는 생성형 모델이 사실을 찾아오지 않는다고 설명합니다. 모델은 가능성이 높은 단어 순서를 예측하므로 결과에 부정확한 내용이 섞일 수 있다는 것입니다. 같은 안내는 게시 전 검토도 강조합니다. AI가 만든 모든 콘텐츠의 정확성과 신뢰성을 사람이 직접 사실 확인하고 검토해야 한다는 것입니다.
실무에서 보면 에이전트가 글 전체를 다시 생성하는 방식으로 고칠 때 이 위험이 수정 범위 밖으로 번집니다. 예를 들어 가상의 ○○ 기업 담당자가 한 문단만 고쳐 달라고 지시했다고 가정합니다. 에이전트가 전체를 다시 쓰면 지시하지 않은 문단의 문장도 줄어들 수 있습니다. 특정 문단만 바꾸는 편집 도구를 쓰는 에이전트도 있습니다. 다만 실제로 어느 방식으로 고쳤는지는 결과를 대조해야 확인할 수 있습니다.
실무에서는 예외 조건 한 줄, 주의 문장, 기준일, 숫자의 단위처럼 짧은 문장이 빠졌는지부터 점검합니다. 수정본만 다시 읽어서는 빠진 문장을 알아보기 어렵습니다. 그래서 실무에서는 다시 읽기보다 두 버전을 도구로 비교하는 방법을 권합니다.
수정 전에 원문과 지시 범위는 어떻게 고정하나요?
1단계: 공개본을 한 줄에 한 문장씩 저장하기
먼저 지금 공개된 본문을 저장합니다. 관리 화면의 편집 원고가 아니라 실제 공개 화면의 본문을 저장합니다. 편집 원고와 공개본이 다를 수 있기 때문입니다.
저장한 본문은 한 줄에 한 문장씩 나눕니다. 비즈니스 문체 글이라면 문서 편집기의 찾아 바꾸기에서 「다. 」를 「다.」와 줄바꿈으로 바꾸면 됩니다. 줄바꿈을 입력하는 방법은 편집기마다 다르므로 편집기 도움말을 확인합니다. 물음표로 끝나는 문장, 표의 칸, 목록 항목은 따로 한 줄씩 나눕니다.
에이전트에 나누게 한다면 글자는 바꾸지 말고 줄만 나누라고 지시합니다. 그다음 몇 문장을 골라 원문에서 찾기로 검색해 글자가 그대로인지 확인합니다.
나눈 결과는 파일 두 개로 저장합니다. 번호 없는 원문_본문.txt는 도구 대조용입니다. 같은 줄 앞에 S01, S02처럼 번호를 붙인 원문_번호.txt는 판정과 기록용입니다. 대조용 파일에 번호를 붙이면 문장 하나만 빠져도 뒤 번호가 밀립니다. 그러면 거의 모든 줄이 바뀐 것으로 표시됩니다.
완료 기준: 두 파일의 줄 수가 같아야 합니다. 저장 일시, 글 주소, 전체 문장 수는 파일 안이 아니라 기록 양식에 적습니다.
2단계: 남길 문장 목록 만들기
원문_번호.txt에서 수정 뒤에도 남아야 하는 문장을 고릅니다. 이 목록이 대조 기준이 됩니다.
Anthropic의 환각 줄이기 안내는 2만 토큰(모델이 글을 나누어 처리하는 단위)이 넘는 긴 문서용 방법을 소개합니다. 작업 전에 원문 문장을 글자 그대로 먼저 뽑게 하면 응답이 실제 본문에 근거하게 된다는 설명입니다. 블로그 글은 대부분 이보다 짧아 원래 적용 조건과는 다릅니다. 실무에서는 짧은 글에도 이 방식을 응용합니다. 고치기 전에 남길 문장을 원문 그대로 뽑게 하는 방법을 권합니다.
| 문장 유형 | 예 | 빠졌을 때 생기는 문제 |
|---|---|---|
| 조건·예외 | 「단, ○○인 경우는 제외합니다」 | 예외에 해당하는 독자가 잘못 판단합니다 |
| 주의·경고 | 「설정을 바꾸기 전에 기존 값을 저장합니다」 | 독자가 되돌릴 수 없는 작업을 합니다 |
| 수치·기준일 | 「○○년 ○월 기준」, 단위가 붙은 숫자 | 시점이 다른 독자가 자기 상황에 그대로 적용합니다 |
| 출처를 밝힌 문장 | 「○○ 문서는 …라고 설명합니다」 | 근거 없는 주장처럼 읽힙니다 |
| 독자가 할 행동 | 실행 순서, 따라 쓸 문안 | 글을 읽고 할 일이 사라집니다 |
완료 기준: 남길 문장이 S 번호와 함께 목록으로 저장되어 있어야 합니다. 문장마다 원문_본문.txt에서 문장 전체를 찾기로 검색해 그대로 검색되는지 확인합니다. 검색되지 않는 문장은 요약되거나 바뀐 것이므로 원문에서 다시 옮깁니다.
3단계: 고칠 곳과 고치지 않을 곳을 함께 지시하기
지시에는 고칠 곳과 함께 고치지 않을 곳도 적습니다. 고칠 곳만 적으면 나머지를 어떻게 처리할지 에이전트가 판단하게 됩니다.
Anthropic 안내는 제공한 문서의 정보만 쓰고 일반 지식은 쓰지 않도록 분명히 지시하는 방법도 소개합니다. 수정 지시에도 근거 범위와 수정 범위를 직접 적습니다. 원문_번호.txt와 남길 문장 목록을 첨부한 뒤 쓸 지시 문안은 다음과 같습니다.
- 고칠 곳: S12~S18 문단을 최신 기준에 맞게 바꿉니다. 근거는 첨부 자료만 사용합니다.
- 고치지 않을 곳: 위 범위 밖의 문장은 글자 하나도 바꾸지 않습니다.
- 남길 문장: 첨부한 목록의 문장은 위치를 옮기더라도 내용을 빼지 않습니다.
- 삭제 보고: 문장을 지웠다면 결과 끝에 지운 문장 번호와 이유를 적습니다.
- 충돌 처리: 남길 문장이 새 자료와 맞지 않으면 그 문장은 그대로 두고, 맞지 않는 내용을 보고합니다.
지시를 보내기 전에 확인할 항목은 다음과 같습니다.
- 수정 범위가 S 번호로 적혀 있는가
- 범위 밖 문장의 처리 원칙이 적혀 있는가
- 남길 문장 목록이 첨부되어 있는가
- 삭제 보고 방식이 정해져 있는가
수정 전후 버전은 어떤 도구로 대조하나요?
4단계: 번호 없는 본문 파일끼리 비교하기
수정본도 1단계와 같은 방법으로 나눕니다. 번호 없는 수정본_본문.txt와 R01, R02처럼 번호를 붙인 수정본_번호.txt를 저장합니다. 대조는 에이전트의 자기 보고에 맡기지 않고 도구로 합니다. 에이전트가 빠진 문장이 없다고 답해도 그 답 역시 모델이 생성한 문장이기 때문입니다.
Git(파일 변경 이력을 관리하는 도구)이 설치되어 있다면 저장소 밖의 파일 두 개도 비교할 수 있습니다. Git 공식 문서는 --no-index 형식이 파일 시스템의 두 경로를 비교한다고 설명합니다. 대조는 두 번에 나누어 실행합니다.
- 줄 단위 확인: git diff --no-index 원문_본문.txt 수정본_본문.txt 를 실행합니다. 「-」로 시작하는 줄은 원문에만 있는 줄이고, 「+」로 시작하는 줄은 수정본에만 있는 줄입니다. 맨 위의 「---」「+++」 두 줄은 파일 이름 표시이므로 제외합니다.
- 단어 단위 확인: 같은 명령에 --word-diff를 붙여 다시 실행합니다. 1번에서 「-」 줄 옆에 비슷한 「+」 줄이 있던 곳은 어떤 단어가 바뀌었는지 여기서 확인합니다.
Git 문서에 따르면 --word-diff는 바뀐 단어를 표시합니다. 기본값인 plain 모드는 지운 단어를 [-…-]로, 추가한 단어를 {+…+}로 보여 줍니다. 단어는 기본적으로 공백으로 구분합니다.
1번 결과에서 짝이 되는 「+」 줄이 없는 「-」 줄은 삭제 후보입니다. 비슷한 「+」 줄이 짝으로 있는 「-」 줄은 변경 후보입니다. 후보 줄마다 원문_번호.txt에서 같은 문장을 찾아 S 번호를 적습니다. Git을 쓰지 않는다면 문서 편집기의 버전 비교 기능이나 텍스트 비교 도구로 같은 줄 단위 비교를 합니다.
완료 기준: 「-」로 시작한 줄 모두에 S 번호가 붙어 있어야 합니다. 각 줄은 삭제 후보 또는 변경 후보로 나뉘어 있어야 합니다.
빠진 문장은 어떻게 판정하고 기록하나요?
5단계: 후보마다 판정하고 회차 기록 남기기
판정은 삭제, 변경, 남길 문장 대조의 세 갈래로 합니다. 변경은 문장은 남았지만 조건·숫자·주어가 바뀐 경우입니다. 남길 문장 대조는 2단계 목록의 문장마다 수정본_번호.txt의 대응 R 번호를 적는 작업입니다.
남길 문장 대조는 Anthropic 안내의 인용 검증 방식을 응용한 것입니다. 이 안내는 응답을 만든 뒤 주장마다 뒷받침하는 인용문을 찾게 하고, 찾지 못하면 그 주장을 빼게 하는 방법을 소개합니다. 수정본 대조에서는 방향을 바꿉니다. 대응 문장을 찾지 못한 남길 문장을 누락으로 표시합니다.
| 판정 | 기준 | 처리 |
|---|---|---|
| 의도한 삭제 | 수정 범위 안이고 삭제 이유가 보고됨 | 기록만 남김 |
| 대체된 삭제 | 다른 문장이 같은 내용을 더 정확히 담음 | 대응하는 R 번호를 적음 |
| 의도하지 않은 삭제 | 수정 범위 밖이거나 삭제 이유가 없음 | 원문 문장을 그대로 복원 |
| 판단 보류 | 새 자료와 원문 문장이 서로 맞지 않음 | 담당자가 근거를 확인한 뒤 결정 |
수정 회차마다 결과를 한 장에 기록합니다. 다음은 가상의 한 회차를 채운 예입니다.
| 항목 | 기록 예 |
|---|---|
| 글과 회차 | 가상의 ○○ 기업 안내 글, 3회차 수정 |
| 원문 저장 | 저장 일시, 글 주소 |
| 문장 수 | 원문 42문장, 수정본 40문장(복원 후 41문장) |
| 수정 지시 범위 | S12~S18 |
| 삭제 판정 | 3건: 의도 1(S15), 대체 1(S17→R16), 의도하지 않음 1(S27) |
| 남길 문장 대조 | 18문장 중 17문장 대응, S27 대응 없음 |
| 복원 | S27 원문 그대로 복원 |
| 바뀐 메타데이터 | 메타 설명 |
| 수정일 | 변경함 — 이유: S12~S18 내용을 최신 기준으로 실질 수정, 화면 표시와 dateModified 함께 수정 |
| 확인 | 담당자 이름, 확인 일시 |
완료 기준: 삭제·변경 후보 모두에 판정이 붙어 있어야 합니다. 남길 문장 목록 전체에 R 번호 또는 누락 표시가 적혀 있어야 합니다. 복원한 문장이 있으면 4단계 대조를 한 번 더 실행해 결과를 갱신합니다.
이 기록이 쌓이면 어떤 유형의 문장이 자주 빠지는지 드러납니다. 조건·예외 문장이 반복해서 빠진다면 다음 수정부터 그 유형을 남길 문장 목록에 처음부터 넣습니다.
본문 밖의 제목·날짜·메타데이터는 무엇을 비교하나요?
6단계: 메타데이터·날짜 비교와 게시 후 확인
본문만 대조하면 검색 결과에 보이는 정보가 빠질 수 있습니다. Google의 생성형 AI 콘텐츠 안내는 검토가 메타데이터에도 적용된다고 설명합니다. 그 예로 제목 요소, 메타 설명(검색 결과에 보이는 요약 문구), 구조화 데이터(검색엔진에 페이지 정보를 알리는 표준 형식 코드), 이미지 대체 텍스트를 듭니다. 수정 전후의 이 값들도 나란히 적어 비교합니다.
날짜는 따로 확인합니다. Google의 유용한 콘텐츠 안내는 내용이 실질적으로 바뀌지 않았는데 새로워 보이려고 날짜를 바꾸는지 묻습니다. 게시 날짜 안내는 날짜와 시간을 일관되게 하라고 설명합니다. 화면에 보이는 날짜와 마크업의 날짜가 서로 맞아야 한다는 것입니다.
실무에서는 실질적인 변경이 있을 때만 수정일을 바꾸는 방법을 권합니다. 이때 화면 표시와 dateModified(구조화 데이터의 수정일 항목) 값을 함께 고칩니다.
게시한 뒤에는 Search Console의 URL 검사 도구로 실시간 테스트를 실행합니다. 도움말은 이 테스트가 Google이 색인을 위해 페이지에 접근할 수 있는지를 알려 준다고 설명합니다. 다만 모든 색인 문제를 검사하지는 않으므로, 통과해도 색인 포함이 확정되지는 않습니다. 색인 생성을 요청할 수도 있지만, 도움말은 요청이 색인 포함을 보장하지 않는다고 밝힙니다.
완료 기준: 메타데이터의 수정 전후 값이 나란히 기록되어 있어야 합니다. 수정일 변경 여부와 이유, 실시간 테스트 결과도 함께 적혀 있어야 합니다.
정리
빠진 문장은 수정본을 다시 읽어서가 아니라 원문과 대조해서 찾습니다. 다음 순서로 바로 시작할 수 있습니다.
- 지금 공개된 본문을 한 줄에 한 문장씩 나눠 번호 없는 대조용 파일과 S 번호 기록용 파일로 저장합니다.
- 조건·주의·수치·출처·행동 문장을 원문 그대로 뽑아 남길 문장 목록을 만들고, 찾기로 일치 여부를 확인합니다.
- 수정 지시에 고칠 범위, 범위 밖 처리 원칙, 삭제 보고 방식을 적습니다.
- 번호 없는 두 본문 파일을 줄 단위와 단어 단위로 비교하고, 후보마다 판정해 의도하지 않은 삭제를 복원합니다.
- 메타데이터와 날짜를 비교한 뒤 게시하고, URL 검사 도구로 실시간 테스트를 실행합니다.
참고 자료
- Google Search's guidance on using generative AI content (Google Search Central, 확인일 2026-10-22)
- Creating helpful, reliable, people-first content (Google Search Central, 확인일 2026-10-22)
- Help Google Search know the best date for your web page (Google Search Central, 확인일 2026-10-22)
- URL Inspection tool (Search Console 고객센터, 확인일 2026-10-22)
- Reduce hallucinations (Anthropic Claude 문서, 확인일 2026-10-22)
- git-diff Documentation (Git 공식 문서, 확인일 2026-10-22)