AI에게 글을 맡기면 문장은 잘 나오지만, 문제는 근거입니다. 그럴듯한 기관명과 그럴듯한 주소를 갖춘 출처가 붙어 있는데 열어보면 존재하지 않는 페이지인 경우가 있습니다. 이 글은 그런 날조 출처를 발행 전에 기계적으로 걸러내는 게이트를 어떻게 구성하는지 정리합니다.
왜 사람 눈으로는 걸러지지 않는가
날조된 출처는 어색하지 않습니다. 실존하는 기관 이름에 실존할 법한 경로를 붙이기 때문에, 형태만 보면 정상 출처와 구분되지 않습니다. 검토자가 "출처 확인하셨나요?"라고 묻고 작성자가 "확인했습니다"라고 답하는 절차로는 아무것도 검증되지 않습니다.
여기에 두 가지 조건이 겹치면 사고가 커집니다. 첫째, 글이 많아질수록 사람이 모든 링크를 클릭할 수 없습니다. 둘째, 검색 노출을 노린 콘텐츠는 대개 분량이 길고 출처 수가 많습니다. 실제로 이 문제는 검색 광고 심사에서 콘텐츠 품질 문제로 먼저 드러나기도 합니다. 그때는 이미 다수의 글에 퍼져 있는 상태입니다.
그래서 규칙을 사람의 성실성에 맡기지 말고, 발행 파이프라인이 막게 만들어야 합니다. AI 출력의 사실성을 높이는 일반적인 접근은 AI 환각 줄이는 방법에서 다루지만, 출처 문제는 생성 단계가 아니라 발행 단계에서 잡는 편이 확실합니다.
게이트 1: 링크가 실제로 열리는지 기계로 확인한다
가장 효과가 큰 장치입니다. 글에 등장하는 모든 외부 링크를 뽑아 HTTP 응답 코드를 확인하고, 200이 아닌 링크가 하나라도 있으면 발행을 멈춥니다.
# 마크다운 파일에서 외부 링크만 뽑아 응답 코드 확인
grep -oE 'https?://[^)"[:space:]]+' 글.md | sort -u | while read -r url; do
code=$(curl -s -o /dev/null -w '%{http_code}' --max-time 10 -L "$url")
echo "$code $url"
done
운영해 보면 다음 원칙이 필요해집니다.
- 200만 통과로 본다. 301·302는 최종 도착지까지 따라가서 200을 확인합니다(
-L). - 403·404는 즉시 차단. 특히 404는 날조 가능성이 높습니다.
- 타임아웃은 재시도 후 판단. 한 번 실패를 곧바로 날조로 판정하면 정상 링크를 잃습니다.
- 논문·기관 문서는 식별자까지 확인. 응답이 200이어도 제목이 인용 내용과 무관할 수 있습니다.
게이트 2: 겪지 않은 경험은 쓰지 않는다
날조는 링크에서만 나오지 않습니다. 더 걸러내기 어려운 것은 1인칭 경험담입니다. "직접 써 보니", "저희 팀은 이렇게 해서 3주 만에" 같은 문장은 검증할 대상 자체가 없습니다.
규칙을 단순하게 정하는 편이 잘 지켜집니다.
우리가 실제로 겪지 않은 일은 1인칭으로 쓰지 않는다.
주제에 대해 직접 경험이 없다면, 있는 척하는 대신 "일반적으로 이렇게 알려져 있다", "공개된 사례에서는" 같은 표현으로 쓰고 근거를 붙입니다. 경험 없는 후기를 쓰지 않는 것은 신뢰의 문제이기도 하지만, 실무적으로는 검증 불가능한 문장을 글에서 없애는 일입니다.
게이트 3: 단정할 수 없는 수치는 단정하지 않는다
가격·성능·해상도처럼 자주 바뀌는 수치는 날조가 아니라도 곧 거짓이 됩니다. 이 경우 두 가지 선택이 있습니다.
- 수치를 쓰지 않고 경향만 서술한다(강점·용도 비교 등).
- 수치를 쓰되 확인 시점과 출처를 함께 남기고, 공식 페이지 확인을 권한다.
어느 쪽이든 "최신", "최고", "가장 빠른" 같은 표현은 근거 없이 쓰지 않습니다. 특히 건강·금융처럼 사람의 결정에 직접 영향을 주는 주제라면, 단정하지 않는 원칙을 더 엄격하게 적용하고 전문가 상담 안내를 함께 붙이는 편이 안전합니다.
게이트 4: 발행 체크리스트를 순서대로 통과시킨다
앞의 게이트를 사람 기억에 맡기지 말고 목록으로 고정합니다. 실무에서 쓰는 순서는 대략 이렇습니다.
| 순서 | 항목 | 통과 기준 |
|---|---|---|
| 1 | 메타데이터 스키마 | 필수 필드 누락 0 |
| 2 | 외부 링크 응답 | 전부 200(리다이렉트 추적 후) |
| 3 | 1인칭 경험담 | 검증 불가 문장 0건 |
| 4 | 단정 표현 | 근거 없는 수치·최상급 0건 |
| 5 | 내부 링크 | 대상 페이지 실존 |
| 6 | 빌드 | 에러 0, 예상 페이지 수 일치 |
| 7 | 발행 후 확인 | 실제 주소 200, 사이트맵 포함 |
여기서 자주 빠뜨리는 항목이 5번과 7번입니다. 내부 링크는 오타 하나로 404가 되고, 발행됐다고 해서 실제로 접근 가능한지는 확인 전까지 알 수 없습니다. 발행은 "커밋했다"가 아니라 "주소가 200을 반환했다"로 완료 판정합니다.
검증 자체를 검증한다
게이트를 만들었다면, 그 게이트가 실제로 작동하는지도 확인해야 합니다. 방법은 간단합니다. 일부러 깨진 링크를 하나 넣고 게이트가 막는지 확인하는 것입니다. 막지 못하면 그 게이트는 초록불만 켜는 장식입니다.
이 원리를 일반화한 절차는 AI의 "완료했습니다"를 검증하는 방법에서 다룹니다. 검사 대상이 비어 있으면 검증 스크립트가 아무것도 확인하지 않고 통과를 반환할 수 있으므로, 통과라는 결과만으로는 안심할 수 없습니다.
자주 묻는 질문
- Q. AI가 출처를 지어내는 이유는 무엇인가요?
- A. 언어 모델은 문맥상 그럴듯한 다음 토큰을 생성하는 방식으로 동작하므로, 형태가 자연스러운 기관명과 주소를 만들어낼 수 있습니다. 실제 존재 여부를 조회하는 단계가 없다면 결과물은 형식만 갖춘 출처가 됩니다.
- Q. 출처 검증을 자동화하려면 무엇부터 해야 하나요?
- A. 글에서 외부 링크를 모두 추출해 HTTP 응답 코드를 확인하는 스크립트를 발행 절차에 넣는 것이 첫 단계입니다. 리다이렉트를 따라간 최종 응답이 200인지 확인하고, 200이 아닌 링크가 있으면 발행을 중단시키면 됩니다.
- Q. 응답이 200이면 출처로 믿어도 되나요?
- A. 접근 가능하다는 것만 확인된 상태입니다. 페이지 제목이나 문서 식별자가 인용한 내용과 실제로 일치하는지 확인해야 합니다. 특히 논문 인용은 식별자까지 대조하는 편이 안전합니다.
- Q. 경험담을 넣으면 글이 더 읽히지 않나요?
- A. 읽히지만 검증할 수 없는 문장이 늘어납니다. 직접 경험이 없다면 1인칭 대신 공개된 사례와 근거를 인용하는 방식으로 쓰고, 경험이 있다면 그 기록을 함께 남겨두는 편이 낫습니다.
더 읽을거리
AI 출력의 사실성을 높이는 접근은 AI 환각 줄이는 방법, 검증 절차 일반론은 완료 보고 검증법, 여러 에이전트가 함께 글을 만드는 구조는 멀티에이전트 운영법에서 다룹니다. 개념 정리는 환각 용어 페이지를 참고하세요.
이 글에서 다룬 날조 출처 사건을 포함해, 발행 게이트가 생기게 만든 사고 5건과 그때 만들어진 규약 파일들은 멀티에이전트 스타터 키트에 실려 있습니다. 사고별로 어떤 규칙이 붙었는지까지 함께 적었습니다.