핵심 요약
- 단일 ‘사실 여부 검증’ 프롬프트는 개인 의견까지 사실로 판정하는 오작동과, 근거 없이 그럴듯한 결론을 생성하는 LLM 환각 현상을 함께 드러냈다.
- 팩트체크 결과가 노출된 뒤 작성자가 본문을 수정하면, 검증 대상 텍스트와 결과가 어긋나는 무결성 붕괴 문제가 발생했다.
- 개발자 dpcks666는 약 6개월 전 어흥 서비스를 처음 공개한 작성자와 동일 인물로 보이며, 이번 글은 1 P·댓글·토론 중심의 Show GN 형식 회고다.
AI 팩트체크는 ‘결론 단정형’ 도구가 아니라 ‘근거 제시형 보조 도구’로 포지셔닝하는 것이 적절해 보이며, 의견과 사실을 분리하는 다단계 프롬프트와 수정 이력 기반 재검증 파이프라인이 함께 설계되어야 운영 가능한 수준이 될 것으로 분석된다.
시민 참여형 정치 커뮤니티 ‘어흥'(도메인 app.uhheung.kr)에 AI 팩트체크 기능을 붙인 개발자 dpcks666는 6개월 전 첫 서비스를 공개한 당사자로서, 이번 글에서 시제품에서 실서비스로 옮기는 과정에서 드러난 세 가지 실패 모드를 공개했다. 본문은 그 시행착오를 시간 순으로 따라가며, 왜 단순한 ‘사실 여부 검증’ 프롬프트가 곧바로 무너졌는지를 진단한다.
프로젝트 배경과 도입 동기
어흥 서비스 개요와 6개월 전 첫 공개
어흥은 시민이 직접 정치 이슈에 참여하는 커뮤니티 서비스다. GeekNews에 약 6개월 전 처음 소개된 이 서비스는 댓글과 토론을 중심으로 운영되며, 이번 글도 1 P·댓글·토론 위주의 Show GN 형식으로 작성된 것으로 보인다. 같은 작성자가 다시 등장해 후속 회고를 남겼다는 점에서 1인 개발 프로젝트의 연속성이 확인된다.
커뮤니티 가짜뉴스와 소모적 논쟁 감소라는 목표
정치 커뮤니티의 고질적 문제로 지적되는 가짜뉴스 확산과 같은 사실 반복에 따른 소모적 논쟁을 줄이기 위해, AI 팩트체크를 글 단위 보조 도구로 도입하려 했다. 즉, 운영자의 직접 검열을 대체하기보다는 사용자가 스스로 사실 관계를 점검하도록 돕는 보조 수단을 도입 동기로 내세운 것으로 보인다.
초기 설계와 첫 번째 좌절: 단일 프롬프트의 함정
사실 여부 검증 단일 프롬프트 접근의 탄생
초기 구현은 단순했다. 타겟 텍스트와 ‘이 글이 사실인지 검증해줘’라는 단일 프롬프트를 LLM에 넘기고, 그 결과를 게시물 하단에 노출하는 방식이었다. 코드 변경량과 사용자 학습 비용을 최소화하려는 현실적 선택이었지만, 이후 문제가 되는 지점이 바로 여기서 출발했다.
개인의 의견까지 사실로 판정하는 오작동 사례
첫 번째 실패는 의견과 사실의 경계 붕괴다. ‘나는 A 정책이 위험하다고 본다’ 같은 명백한 개인 의견 글이 들어오면, LLM은 이를 검증 대상으로 받아들이고 사실 여부를 판정하려 시도했다. 검증 대상 자체가 사실이 아니라 가치 판단이나 관점이라는 점을 시스템이 구분하지 못한 것이다. 이 오작동은 작성자에게 ‘내 의견이 허위로 분류됐다’는 불만으로 이어졌을 가능성이 높다.
근거 없는 그럴싸한 결론으로 나타난 LLM 환각 현상
두 번째 실패는 LLM 환각이다. 정작 검증해야 할 사실 관계에 대해서는 그럴싸하지만 근거가 없는 결론이 생성됐다. 원문 작성자는 ‘근거 없이 그럴싸한 결론이 나왔다’고 표현하며, 이는 사실 확인이 필요한 영역일수록 환각 비용이 커진다는 점을 시사한다. 단일 프롬프트 구조는 ‘모르겠다’고 답하기보다 그럴듯한 답을 만들어내도록 유도하는 경향이 있다.
| 실패 모드 | 발생 조건 | 표면 증상 |
|---|---|---|
| 의견-사실 혼동 | 주관적 견해가 포함된 글 | 의견을 사실로 판정해 작성자 반발 |
| LLM 환각 | 출처가 불명확한 사실 관계 | 근거 없는 단정적 결론 생성 |
운영 환경에서 발견한 두 번째 실패 모드: 무결성 붕괴
팩트체크 결과 노출 후 작성자가 본문을 수정하는 상황
세 번째 실패는 시간 흐름에 따른 문제로 드러났다. 팩트체크 결과가 게시물에 고정 노출되면, 작성자는 결과가 좋지 않을 때 본문을 손본다. ‘이 글은 사실이다’라는 결과가 붙어 있는 본문이 ‘사실이 아닌 내용’으로 바뀌면, 결과와 본문이 가리키는 대상이 달라지는 것이다. 이는 단순 표시 문제가 아니라, 어떤 사실에 대한 검증인지를 특정할 수 없게 만드는 근본적 무결성 문제다.
검증 대상과 결과가 어긋나는 시간 정합성 붕괴
원문이 수정될 때마다 결과가 자동으로 갱신되지 않는다면 오래된 결과가 남아 사용자 혼선을 주고, 자동 갱신한다면 원문 작성자에게는 수정의 자유가 사실상 박탈된다. 이 두 선택지 모두 문제를 남기 때문에, ‘수정 시점과 검증 시점을 함께 기록하는’ 방식이 아니면 근본 해결이 어렵다는 교훈을 얻을 수 있다. 즉, 무결성은 결과가 아니라 이력에서 확보돼야 한다.
시행착오에서 도출한 설계 교훈
의견과 사실 영역을 분리하는 다단계 프롬프트 필요성
단일 프롬프트는 의견과 사실을 한 번에 다루려 하기 때문에 둘 다 실패한다. ‘이 글에 사실 관계 주장과 의견이 각각 어떻게 분포하는가’를 먼저 분류하고, 사실 주장에 대해서만 검증을 시도하는 다단계 파이프라인이 필요해 보인다. 이는 단순한 모델 성능 향상 문제가 아니라 시스템 설계 문제다.
결론 단정형에서 근거 제시형 보조 도구로의 포지셔닝 재조정
‘사실 / 거짓’ 이분법 결론은 환각과 무결성 붕괴를 동시에 증폭시킨다. ‘이 주장은 출처 A와 모순된다’, ‘이 부분은 추가 확인이 필요하다’처럼 근거와 신뢰도를 함께 노출하는 보조 도구 포지셔닝이 위험을 줄이는 방향으로 보인다. 단정형 UI는 사용자가 결과를 맹信하도록 만들어 책임 소재를 LLM에게 떠넘기는 결과를 낳기 쉽다.
수정 이력 추적과 재검증 파이프라인 설계 방향
본문이 수정될 때마다 새로운 스냅샷에 대해 팩트체크를 다시 수행하고, 과거 결과는 ‘수정 전 원문에 대한 검증’으로 분리 보존하는 구조가 하나의 대안이다. 이때 ‘어떤 원문에 대한 어떤 결과인가’를 항상 함께 표시해야 검증 결과의 의미가 유지된다.
시사점과 다음 단계: 팩트체크를 어떻게 붙일 것인가
1인 개발 규모에서 우선 적용할 현실적 개선 항목
1인 개발자에게 모델 자체를 학습시키는 방식은 비현실적이다. 대신 적용 가능한 항목은 (1) 의견/사실 분류 1차 프롬프트, (2) 출처 제시형 결과 템플릿, (3) 본문 해시 기반 스냅샷 저장, (4) 사용자 신고 기반 재검증 트리거 정도로 정리할 수 있다. 이 조합이면 모델 교체와 무관하게 운용 가능한 것으로 분석된다.
시민 참여형 서비스에 AI 검증을 얹을 때의 운영 원칙
시민 참여형 서비스에서 AI 검증은 ‘자동 심판’이 아니라 ‘열린 질문’을 제공하는 형태로 운용될 필요가 있다. 결과보다 과정을, 단정보다 근거를, 최신성보다 이력 정합성을 우선시하는 운영 원칙이 1인 개발자에게도 적용 가능한 최소 단위로 보인다. 결국 팩트체크는 글의 품질을 끌어올리는 도구가 아니라, 사용자가 스스로 생각하도록 돕는 보조 인터페이스에 가깝다.
전체 사후기는 GeekNews 원문 – Show GN: 정치 커뮤니티에 AI 팩트체크 기능을 붙이며 겪은 시행착오들에서 확인할 수 있으며, 동일 개발자가 6개월 전 남긴 어흥 서비스 최초 소개 게시물(GeekNews)과 비교해 보면 프로젝트의 방향성이 어떻게 정정되어 왔는지 추적할 수 있다.
핵심 포인트 정리
- 단일 검증 프롬프트는 의견-사실 혼동과 LLM 환각이라는 두 문제를 동시에 만든다.
- 본문 수정 이후의 무결성 붕괴는 결과 표시 방식이 아니라 스냅샷·이력 설계로 해결해야 한다.
- AI 팩트체크는 ‘단정형 심판’이 아니라 ‘근거 제시형 보조 도구’로 포지셔닝할 때 운영 리스크가 줄어든다.
- 1인 개발자도 적용 가능한 현실적 개선 항목은 의견/사실 분류 1차 프롬프트, 출처 제시형 템플릿, 본문 해시 스냅샷, 신고 기반 재검증 트리거다.