AI가 생성한 글을 그대로 WordPress에 자동 발행하면 반드시 문제가 생깁니다. 존재하지 않는 통계, 잘못된 날짜, 지어낸 인용구 — 이른바 AI 환각(hallucination)이 포함된 콘텐츠가 검색 노출까지 되고 나면 수정이 훨씬 번거로워집니다. 이 글에서는 자동 발행 파이프라인에 환각 검증 게이트를 끼워 넣는 구조, 그리고 fact_issues 필드를 활용한 체크 구현 방법을 설명합니다.
자동 발행 파이프라인 전체 흐름
왜 검증 게이트가 필요한가
AI 글쓰기 자동화는 속도 면에서 효율적이지만, LLM(대형 언어 모델)은 구조적으로 사실과 허구를 구분하지 않고 문장을 생성합니다. 특히 다음 세 가지 상황에서 환각이 자주 발생합니다.
- 구체적인 수치나 통계를 요청했을 때
- 특정 인물의 발언이나 논문을 인용할 때
- 최신 이벤트나 날짜를 포함한 내용을 생성할 때
이 세 가지 유형은 독자 신뢰도와 직결됩니다. 한 번 잘못된 정보가 인덱싱되면 SEO 측면에서도 이후 수정 비용이 발생합니다. 그래서 발행 직전 단계에 자동 검증 게이트를 배치하는 구조가 필요합니다.
fact_issues 필드의 역할
fact_issues는 AI가 생성한 원고를 검증 단계에서 처리할 때, 문제가 있는 문장이나 항목을 별도 배열로 기록하는 커스텀 필드입니다. 발행 여부를 결정하는 플래그 역할을 합니다.
기본 구조는 다음과 같습니다.
{
"fact_issues": [
{
"type": "unverified_stat",
"text": "전 세계 사용자의 78%가 AI를 활용한다",
"reason": "출처 없음, 수치 확인 불가"
},
{
"type": "false_quote",
"text": "Sam Altman은 2024년 3월 인터뷰에서 ...",
"reason": "해당 인터뷰 존재 확인 불가"
}
],
"fact_check_passed": false
}fact_issues 배열이 비어 있고 fact_check_passed가 true일 때만 WordPress 발행 API를 호출하는 방식입니다. 하나라도 항목이 남아 있으면 발행을 보류하고 검토 대기 상태로 전환합니다.
fact_issues JSON 구조 예시
WordPress 자동 발행 검증 게이트 구현 단계
전체 파이프라인은 크게 4단계로 구성됩니다.
1단계 — 원고 생성 후 검증 프롬프트 호출
원고 생성이 끝난 직후, 동일한 LLM에 검증 전용 프롬프트를 별도로 실행합니다. 원고 전문을 입력으로 넘기고, 다음 항목을 점검하도록 지시합니다.
- 수치·통계 — 출처가 명시되지 않은 숫자
- 인용 — 실존 인물의 발언이나 논문 제목
- 날짜 — 특정 이벤트와 날짜의 매칭 여부
- 고유명사 — 기업명, 제품명, 인물명의 오기
검증 프롬프트 출력은 반드시 JSON 형식으로만 받도록 지정합니다. 자유 형식 텍스트로 받으면 이후 파싱 처리가 복잡해집니다.
2단계 — fact_issues 파싱 및 게이트 판단
검증 결과 JSON에서 fact_issues 배열 길이를 확인합니다. 길이가 0이면 fact_check_passed: true로 업데이트하고 다음 단계로 진행합니다. 길이가 1 이상이면 발행을 중단하고 해당 원고를 별도 검토 큐에 저장합니다.
if len(fact_issues) == 0:
fact_check_passed = True
proceed_to_publish()
else:
save_to_review_queue(fact_issues)
notify_editor()3단계 — 검토 큐에서 수동 또는 재생성 처리
fact_issues가 남은 원고는 두 가지 경로로 처리할 수 있습니다.
| 처리 방식 | 적용 상황 | 비고 |
|---|---|---|
| 수동 검토 후 수정 | 문제 항목이 1~2개, 핵심 문장에 포함된 경우 | 에디터가 직접 수정 후 재검증 |
| 해당 섹션 재생성 | 문제 항목이 3개 이상, 특정 섹션에 집중된 경우 | 섹션 단위로 LLM 재호출 |
| 원고 폐기 | 전체 구조에 사실 오류가 분산된 경우 | 새 원고 생성으로 대체 |
4단계 — WordPress REST API로 발행 또는 임시저장
fact_check_passed: true가 확인된 원고만 WordPress REST API를 통해 발행합니다. 발행 상태는 status: publish로 설정하고, 검토 대기 원고는 status: draft로만 저장합니다.
WordPress REST API 공식 문서는 developer.wordpress.org — Posts endpoint에서 확인할 수 있습니다.
게이트 통과 여부 분기 처리 흐름
구현 시 주의사항
검증 게이트를 실제 파이프라인에 붙일 때 자주 발생하는 문제와 대응 방법입니다.
- LLM이 검증도 틀리는 경우 — LLM 기반 팩트 체크는 완벽하지 않습니다.
fact_issues가 비어 있어도 실제 오류가 포함될 수 있습니다. 자동화는 1차 필터 역할로만 활용하고, 고위험 콘텐츠(수치, 의료, 법률)는 반드시 사람이 최종 확인합니다. - JSON 파싱 실패 — LLM이 지시를 어기고 자유 형식으로 응답하면 파싱이 깨집니다. 응답 형식을 강제하는
response_format: {"type": "json_object"}파라미터를 활용하거나, 재시도 로직을 추가합니다. - 검증 비용 증가 — 원고 1건당 검증 호출이 추가되므로 API 비용이 늘어납니다. 토큰 사용량을 줄이려면 원고 전문 대신 수치·인용구가 포함된 문장만 발췌해서 검증 프롬프트에 넘기는 방식이 효율적입니다.
자주 묻는 질문
Q. LLM이 스스로 생성한 글을 스스로 검증하면 의미가 있나?
같은 모델이 생성과 검증을 모두 담당하면 동일한 오류를 반복할 수 있습니다. 이를 보완하는 방법은 두 가지입니다. 첫째, 검증 전용 프롬프트에서 “네가 생성한 글이 아닌 외부 원고를 팩트체크한다”는 맥락을 명시합니다. 둘째, 생성 모델과 검증 모델을 다르게 구성합니다. 완벽한 자동화보다는 발행 전 1차 필터 역할로 설계하는 것이 현실적입니다.
Q. fact_issues 외에 추가로 체크할 항목이 있나?
사실 오류 외에도 저작권 문제(타 콘텐츠 직접 인용 여부), 브랜드 안전성(경쟁사·민감 키워드 포함 여부), SEO 품질(키프레이즈 밀도, 중복 콘텐츠 여부)을 함께 체크하면 발행 후 리스크를 줄일 수 있습니다. 이 항목들은 fact_issues와 별개의 필드로 분리해서 관리하는 것이 구조적으로 깔끔합니다.
Q. n8n이나 Make 같은 노코드 자동화 도구에서도 구현이 가능한가?
가능합니다. n8n 기준으로는 LLM 노드에서 검증 프롬프트를 실행하고, IF 노드에서 fact_issues.length === 0 조건으로 분기하면 됩니다. true 경로는 WordPress 노드로 발행, false 경로는 Notion이나 Google Sheets에 검토 큐로 저장하는 방식으로 구성합니다.
자동 발행 파이프라인은 속도보다 신뢰도가 먼저입니다. fact_issues 게이트 하나만 제대로 붙여도 발행 후 수정 작업이 눈에 띄게 줄어드는 것을 확인할 수 있습니다. 완벽한 자동화는 없지만, 검증 없는 자동화보다는 확실히 낫습니다.
썸네일: Immo Wegmann on Unsplash