필사 모드: AI가 쓴 글이 무너지는 지점들 — 여섯 가지 실패와 각각의 가드레일

• 들어가며 — 문장은 매끄러운데 글이 틀렸습니다
• 실패 유형 한눈에 보기 — 탐지 가능성으로 나눈 지도
• 지어낸 출처와 인용 — 형식은 완벽하고 내용만 없습니다
• 낡은 정보 — 모델은 모른다고 말하는 대신 옛날을 현재형으로 말합니다
• 늘려 쓴 문단과 근거 없는 단정 — 문장 단위의 두 실패
  • 같은 말을 늘려 쓴 문단
  • 근거 없이 단정하는 문장
• 얇은 글과 반복 표현 — 독자와 검색이 실제로 벌하는 것
• 표절과 저작권 — 출력이 원문을 얼마나 닮았는가
• 마치며 — 가드레일의 목적은 통과가 아니라 어디를 볼지 정하는 것입니다
• 참고 자료

들어가며 — 문장은 매끄러운데 글이 틀렸습니다

사람이 쓴 나쁜 글과 AI가 쓴 나쁜 글은 다르게 나쁩니다. 사람이 쓴 글은 대개 문장에서 먼저 무너집니다. 비문이 있고, 흐름이 끊기고, 읽다 보면 어디가 이상한지 금방 짚힙니다. AI가 쓴 글은 반대입니다. 문장은 끝까지 매끄럽고, 단락은 균형이 잡혀 있고, 어조는 시종일관 자신 있습니다. 그런데 인용한 문장이 그 페이지에 없고, 세 문단이 같은 말이고, 근거를 대지 않은 채 단정합니다.

이 차이가 실무에서 위험한 이유는 우리가 글을 검증할 때 문장의 매끄러움을 단서로 쓰기 때문입니다. 읽어서 걸리는 데가 없으면 통과시키는 습관이 있는데, AI 출력에는 그 신호가 처음부터 없습니다. 그래서 "읽어 봤다"는 검증이 되지 못하고, 무엇을 볼지 미리 정해 놓은 목록만이 검증이 됩니다.

이 글은 그 목록입니다. 여섯 가지 실패 유형을 각각 어떻게 탐지하고 어떻게 고치는지, 그리고 그중 무엇을 기계에 맡길 수 있고 무엇은 끝까지 사람이 해야 하는지를 나눠 적었습니다. 이 검사들을 어느 단계에 배치하는지는 파이프라인 전체를 다룬 글에서 정리했으니, 여기서는 검사 자체를 봅니다.

실패 유형 한눈에 보기 — 탐지 가능성으로 나눈 지도

여섯 가지를 먼저 표로 놓겠습니다. 정렬 기준은 심각도가 아니라 기계로 잡을 수 있는 정도입니다. 가드레일을 설계할 때 실제로 필요한 정보가 이것이기 때문입니다.

읽어야 할 것은 오른쪽 두 열의 관계입니다. 자동 탐지가 높은 항목도 사람이 볼 부분이 남고, 그 남은 부분이 항상 판단입니다. 기계는 "이 인용문이 원문에 없다"까지 말해 주고, "이 인용이 원문의 뜻을 뒤집었다"는 말해 주지 못합니다. 가드레일을 짤 때 이 경계를 흐리면, 통과했으니 괜찮다는 착각이 파이프라인에 들어옵니다.

지어낸 출처와 인용 — 형식은 완벽하고 내용만 없습니다

가장 흔하고 가장 치명적인 실패입니다. 모델은 URL, 논문 제목, 저자 이름, 문서 번호처럼 형식이 규칙적인 것을 아주 잘 만들어냅니다. 형식이 규칙적이라는 말은 학습하기 쉽다는 뜻이고, 그럴듯한 새 조합을 만들어내기도 쉽다는 뜻입니다. 그래서 실재하지 않는 논문이 정확한 인용 양식으로 등장하고, 죽은 앵커가 붙은 URL이 자연스러운 경로 구조를 갖고 나타납니다.

여기서 오해를 하나 풀어야 합니다. 검색 기능을 붙였다고 이 문제가 사라지지 않습니다. 검색으로 문서를 가져왔더라도, 요약하는 과정에서 원문에 없는 문장이 인용문 자리에 들어갈 수 있습니다. 실제로 자주 나오는 형태는 완전한 창작이 아니라 원문의 여러 문장을 섞어 한 문장으로 합친 것입니다. 내용은 대체로 맞는데 그 문장은 원문에 없습니다. 인용 부호를 붙인 순간 이것은 오류입니다.

탐지는 다행히 기계가 잘합니다. 축자 인용을 요구하고 그 문자열이 원문에 있는지 대조하면 됩니다. 이 대조 스크립트는 파이프라인 글에 실어 뒀으니 여기서는 결과를 어떻게 다룰지만 적겠습니다.

• 인용문이 원문에 없다: 인용 부호를 지우고 요약으로 바꾸거나, 주장을 통째로 버립니다. 비슷한 문장을 찾아 끼워 맞추지 마세요. 그건 검증이 아니라 사후 정당화입니다.
• 링크가 열리지 않는다: 그 주장에 근거가 없다고 보고 처리합니다. 검색해서 다른 링크를 찾아 붙이는 건 다른 작업이며, 원래 주장이 맞았는지와는 무관합니다.
• 1차 출처가 아니다: 요약 기사에서 원문으로 거슬러 올라갑니다. 이 과정에서 원문이 실제로는 다른 말을 하고 있는 경우를 자주 만납니다.

고치는 쪽에서 실무적으로 가장 효과가 큰 습관은, 주장을 먼저 쓰고 출처를 찾는 순서를 뒤집는 것입니다. 출처를 먼저 읽고 그 안에서만 쓰면 지어낼 자리가 생기지 않습니다.

낡은 정보 — 모델은 모른다고 말하는 대신 옛날을 현재형으로 말합니다

지식 컷오프는 널리 알려져 있지만, 실제 사고는 컷오프 자체가 아니라 컷오프를 표시하지 않는 방식에서 납니다. 모델은 "제가 아는 시점 이후는 모릅니다"라고 말하는 대신, 마지막으로 아는 상태를 현재형으로 서술합니다. 문장에 시점이 표시되지 않으니 읽는 사람은 그것이 오래된 정보인지 알 수 없습니다.

위험 항목은 정해져 있습니다. 가격과 요금제, 제품·모델 이름, API 파라미터와 기본값, 버전 번호와 지원 종료일, 회사의 정책 문구, 그리고 사람의 소속과 직함입니다. 공통점은 자주 바뀌면서 확인이 쉽다는 것입니다. 확인이 쉽다는 말은 독자가 바로 알아챈다는 뜻이기도 합니다.

부분 자동화가 가능합니다. 시점에 의존하는 표현을 기계로 표시해 두고, 사람이 그 자리만 확인하는 방식입니다.

# 시점 의존 표현을 뽑아 리뷰 대상만 좁힙니다. 실패로 처리하지 않는 것이 요령입니다.
# 정밀도가 낮은 검사를 게이트로 만들면 곧 무시하게 되고, 무시되는 게이트는 없는 것만 못합니다.
rg -n --no-heading \
  -e '최신|현재|지금은|올해|작년|최근' \
  -e '가장 (빠른|저렴한|큰|많은)|업계 최초|유일한' \
  -e '무료(입니다|이며)|[0-9]+ *(달러|원|USD)' \
  -e 'v?[0-9]+\.[0-9]+(\.[0-9]+)? *(버전|릴리스)?' \
  data/blog/**/*.mdx

고치는 방법은 문장에 시점을 박아 넣는 것입니다. "현재 무료입니다" 대신 "2026년 7월 기준 무료 티어가 제공됩니다"로 쓰면, 나중에 틀려도 글이 거짓말을 한 것이 되지는 않습니다. 시점을 못 박기 싫은 서술은 대개 확인하지 않은 서술입니다.

한 가지 더. 모델에게 "최신 정보로 업데이트해 줘"라고 요청하는 것은 해결책이 아닙니다. 모델은 자기 컷오프 밖을 알 수 없으므로, 그 요청을 받으면 최신처럼 보이는 문장을 만들어 냅니다. 낡은 정보가 그럴듯한 낡은 정보로 바뀔 뿐입니다.

늘려 쓴 문단과 근거 없는 단정 — 문장 단위의 두 실패

같은 말을 늘려 쓴 문단

모델은 분량을 채우라는 압력을 받으면 새로운 정보 대신 같은 정보를 다른 말로 반복합니다. 이게 눈에 잘 안 띄는 이유는 각 문단이 개별적으로는 멀쩡하기 때문입니다. 문단 세 개를 따로 읽으면 다 말이 되는데, 이어서 읽으면 두 번째와 세 번째가 첫 번째의 재진술입니다.

기계로 잡을 수 있습니다. 문단을 조각으로 잘라 겹치는 비율을 재면 됩니다.

// find-duplicate-paragraphs.mjs — 근접 중복 문단을 유사도 순으로 뽑습니다.
// 완전 일치가 아니라 '실질적으로 같은 말'을 찾는 것이 목적이라 shingle+Jaccard로 충분합니다.
import { readFileSync } from 'node:fs'

const K = 4 // 한국어는 어절이 짧아 4어절 조각이 잘 맞습니다. 영어라면 5~6으로 올리세요.
const THRESHOLD = 0.35

const shingles = (text) => {
  const words = text
    .replace(/`[^`]*`/g, ' ') // 코드 조각은 비교에서 제외
    .replace(/[^\p{L}\p{N}\s]/gu, ' ')
    .split(/\s+/)
    .filter(Boolean)
  const set = new Set()
  for (let i = 0; i + K <= words.length; i++) set.add(words.slice(i, i + K).join(' '))
  return set
}

const jaccard = (a, b) => {
  if (!a.size || !b.size) return 0
  let shared = 0
  for (const s of a) if (b.has(s)) shared++
  return shared / (a.size + b.size - shared)
}

const body = readFileSync(process.argv[2], 'utf8')
  .replace(/^---[\s\S]*?\n---\n/, '')
  .replace(/```[\s\S]*?```/g, '') // 펜스 블록 제외
  .replace(/^\|.*\|$/gm, '') // 표 행 제외: 표는 원래 형식이 반복됩니다

const paras = body
  .split(/\n{2,}/)
  .map((p) => p.trim())
  .filter((p) => p.length > 120 && !p.startsWith('#') && !p.startsWith('-'))

const pairs = []
const sets = paras.map(shingles)
for (let i = 0; i < paras.length; i++) {
  for (let j = i + 1; j < paras.length; j++) {
    const score = jaccard(sets[i], sets[j])
    if (score >= THRESHOLD) pairs.push({ score, i, j })
  }
}

pairs.sort((a, b) => b.score - a.score)
for (const { score, i, j } of pairs.slice(0, 5)) {
  console.log(`\n유사도 ${score.toFixed(2)} — 문단 ${i + 1} 과 문단 ${j + 1}`)
  console.log(`  A: ${paras[i].slice(0, 90)}...`)
  console.log(`  B: ${paras[j].slice(0, 90)}...`)
}
console.log(`\n문단 ${paras.length}개 중 임계값 이상 쌍 ${pairs.length}개`)

임계값은 취향입니다. 0.35 근처에서 시작해 오탐이 많으면 올리세요. 다만 이 도구는 표시만 하고 판단하지 않습니다. 반복이 의도적인 경우도 있습니다. 앞에서 세운 원칙을 뒤에서 사례로 다시 짚는 것은 반복이 아니라 구조입니다.

고치는 방법은 문단을 다듬는 것이 아니라 지우는 것입니다. 두 문단이 같은 말이면 더 구체적인 쪽을 남기고 나머지를 삭제합니다. 합쳐서 하나의 긴 문단으로 만들면 문제가 그대로 남습니다.

근거 없이 단정하는 문장

사람이 글을 쓸 때는 확신의 정도가 문장에 새어 나옵니다. 잘 모르면 "아마", "경우에 따라", "제가 본 범위에서는" 같은 표현이 붙습니다. 모델의 출력에는 이 신호가 균일하게 없습니다. 수천 번 확인된 사실과 방금 만들어낸 문장이 같은 어조로 나옵니다.

그래서 단정 자체가 신호가 됩니다. 아래는 검증하지 않은 초안에서 반복적으로 나타나는 문장 패턴입니다.

이 표의 왼쪽 열은 기계로 검색할 수 있습니다. 정규식으로 후보를 뽑아 놓고 사람이 하나씩 판정하는 방식이 현실적입니다. 자동으로 고치게 하면 안 됩니다. 모델에게 "단정을 완화해 줘"라고 시키면 근거가 없는 문장에 헤지만 붙여서, 틀린 말이 조심스러운 틀린 말이 됩니다.

얇은 글과 반복 표현 — 독자와 검색이 실제로 벌하는 것

여기서 널리 퍼진 오해를 먼저 정리하겠습니다. 구글은 AI로 만들었다는 이유로 콘텐츠에 불이익을 주지 않습니다. 검색 센터의 공식 입장은 생산 수단이 아니라 품질을 본다는 것이고, 이 기준은 자동 생성이 문제가 되기 전부터 같았습니다.

실제로 벌점을 받는 것은 따로 있습니다. 스팸 정책 문서는 검색 순위를 목적으로 독자에게 값을 더하지 않는 글을 대량 생산하는 행위를 대량 생성 콘텐츠 남용으로 명시합니다. 여기서 판정 기준이 "AI가 썼는가"가 아니라 "값을 더했는가"라는 점이 중요합니다. 사람이 열 명을 고용해 같은 짓을 해도 같은 정책에 걸립니다.

그리고 검색엔진보다 먼저 벌하는 것은 독자입니다. 얇은 글의 증상은 명확합니다. 스크롤은 길고, 다 읽고 나면 검색하기 전에 알던 것에서 늘어난 게 없습니다. 이런 글은 순위가 떨어지기 전에 재방문이 끊깁니다.

자가 진단으로 쓸 만한 질문 세 개를 적어 둡니다.

1. 이 글에만 있는 것이 무엇인가. 직접 해 본 결과, 실제로 만난 실패, 확인해서 알아낸 사실 중 하나라도 없다면 얇은 글입니다.
2. 상위 결과 세 개를 읽은 사람이 이 글을 또 읽을 이유가 있는가. 같은 내용을 다른 말로 쓴 것이라면 이유가 없습니다.
3. 절 하나를 통째로 지웠을 때 독자가 잃는 것이 있는가. 없으면 그 절은 분량용입니다.

반복 표현은 이 문제의 겉으로 드러난 형태입니다. 특정 키워드를 억지로 반복하면 문장이 부자연스러워지고, 그 부자연스러움은 사람이 먼저 알아챕니다. 검사 자체는 간단합니다. 본문 전체에서 단어 빈도를 세고 상위 항목이 문맥상 필요한 만큼만 나오는지 보면 됩니다. 다만 한국어는 조사가 붙어 형태가 갈라지므로, 단순 문자열 카운트는 실제 빈도를 낮게 잡습니다. 어간 기준으로 세거나, 눈으로 훑는 편이 정확합니다.

표절과 저작권 — 출력이 원문을 얼마나 닮았는가

이 항목은 자동 탐지가 가장 어렵고, 그래서 규칙으로 다뤄야 합니다.

먼저 쟁점을 정확히 놓겠습니다. 실무에서 문제가 되는 것은 모델이 무엇으로 학습했는가가 아니라 출력물이 특정 원문을 얼마나 재현했는가입니다. 학습 데이터의 적법성은 소송과 입법의 영역이고 아직 정리되는 중이지만, 내 글에 남의 표현이 그대로 들어갔는지는 지금 내가 통제할 수 있는 문제입니다.

위험이 커지는 조건은 예측 가능합니다. 원문이 널리 인용된 유명한 텍스트일 때, 요청이 "이 글을 정리해 줘"처럼 원문 하나에 밀착돼 있을 때, 그리고 표현이 정형화된 영역(정의문, 법조문, 제품 설명)일 때입니다. 이런 조건에서는 모델이 원문의 문장 구조를 거의 그대로 재생산하는 일이 실제로 일어납니다.

실무 규칙은 단순하게 유지하는 편이 낫습니다.

• 인용은 인용 부호와 출처를 반드시 붙이고, 길이를 짧게 유지합니다. 요약으로 대체할 수 있으면 요약합니다.
• 원문 한 편만 넣고 정리시키지 않습니다. 최소 두세 개의 출처를 함께 넣으면 특정 표현에 밀착될 확률이 떨어집니다.
• 번역은 표절 회피 수단이 아닙니다. 번역해도 표현의 실질적 유사성은 남습니다.
• 이미지, 표, 도식도 같은 기준으로 봅니다. 출처가 있는 표를 옮길 때는 출처를 적습니다.
• 라이선스가 명시된 자료는 그 조건을 지킵니다. 이건 판단이 아니라 준수의 문제입니다.

탐지는 부분적으로만 가능합니다. 특징적인 문장을 골라 검색해 보는 수동 검사가 여전히 가장 확실하고, 자동 도구는 참고 수준입니다. 대신 위 규칙을 지키면 사고가 날 확률 자체가 크게 낮아집니다. 이 항목은 탐지보다 예방이 압도적으로 싼 영역입니다.

마치며 — 가드레일의 목적은 통과가 아니라 어디를 볼지 정하는 것입니다

여섯 가지를 다시 놓고 보면 공통점이 보입니다. 전부 문장의 품질이 아니라 문장 밖의 사실에서 무너집니다. 인용이 원문에 있는지, 정보가 지금도 맞는지, 이 문단이 앞 문단과 다른 말인지, 이 단정에 근거가 있는지. 문장만 읽어서는 하나도 판정되지 않고, 그래서 아무리 잘 읽어도 걸러지지 않습니다.

가드레일을 붙이는 목적도 여기서 나옵니다. 검사를 통과했으니 안전하다고 말하기 위해서가 아니라, 사람이 어디를 봐야 하는지 좁혀 주기 위해서입니다. 축자 인용 대조는 지어낸 인용을 지우고 남은 인용만 읽게 해 주고, 중복 탐지는 의심스러운 문단 쌍만 보여 줍니다. 그다음 판단은 여전히 사람 몫이고, 그 몫을 없애려 하면 가드레일이 검증의 대체물이 되어 버립니다.

한 줄로 줄이면 이렇습니다 — AI가 쓴 글에서 고쳐야 할 것은 대부분 문장이 아니라, 그 문장이 사실이라고 믿을 근거입니다.

참고 자료

• Google Search Central — AI 생성 콘텐츠에 대한 구글의 입장
• Google Search Central — 스팸 정책: 대량 생성 콘텐츠 남용
• Google Search Central — 유용하고 신뢰할 수 있는 사람 중심 콘텐츠 만들기
• Survey of Hallucination in Natural Language Generation — 환각의 유형 분류와 평가 방법
• A Survey on Hallucination in Large Language Models — 원인, 탐지, 완화 기법 정리
• AI로 블로그 글 파이프라인 만들기 — 검증을 중심에 둔 전체 흐름 (관련 글)