AI 결과물 검수 게이트 운영 기록 — 클레임 3축 분리(출처 정합·외부 검증·공개 방식)와 실제 차단 사례 4건

시도하고자 했던 것

저는 리서치를 많이 시킵니다 — 유튜브 강의 요약, 경쟁사 조사, 시장 수치. 문제는 AI가 가져온 결과물을 그대로 믿으면 사고가 난다는 것입니다. 그래서 "근거 없는 문장이 검증된 지식으로 승격되지 못하게 하는" 검수 워크스페이스를 만들어 운영해 왔고, 이번 주 과제 틀(워크스페이스 + 인제스트 + 생성/검수 차이)에 맞춰 그 구조와 실제로 잡아낸 사고 목록을 공유합니다.

진행 방법 — 검수 워크스페이스의 4층

1) 인제스트: 원본은 지문과 함께 격리 검수 대상(영상 자막, 웹 글)은 raw/ 폴더에 원문 그대로 캡처하고 SHA-256 해시를 매니페스트에 기록합니다. raw는 불변 — 수정·정규화 금지, 원본이 바뀌면 새 캡처 ID로 추가합니다. 검수의 기준점이 흔들리면 그 위의 모든 판정이 무효가 되기 때문입니다. (버디님 세법 위키 시연에서 조문마다 SHA-256을 "문서 지문"으로 쓰시는 걸 보고, 독립적으로 같은 설계에 수렴했다는 걸 알고 반가웠습니다.) 2) 클레임 분해: 문장 단위로, 세 축을 분리해서 요약 전에 원문을 "한 문장짜리 검증 가능한 최소 주장(클레임)"으로 쪼개고, 클레임마다 세 축을 독립적으로 기록합니다. 출처 정합: 원문의 그 위치가 이 주장을 실제로 뒷받침하는가 (supported/unclear/unsupported) 외부 검증: 원문 밖 1차 자료가 확인해주는가 (verified/mixed/not_verified/not_applicable) 공개 방식: 사실로 서술 가능한가, "저자는 ~라고 말한다"로 귀속해야 하는가 (factual/attributed/blocked) 이 분리가 핵심입니다. "저자가 40/40을 달성했다고 쓴 것"은 출처 정합 supported이지만 외부 검증 not_verified — 그래서 attributed로만 쓸 수 있습니다. 축을 안 나누면 "원문에 있으니 사실"이라는 오염이 일어납니다. 3) 기계 게이트: 검증기가 요약문을 반려한다 요약 문서는 검증 스크립트를 통과해야 합니다. 핵심 문장마다 [factual]/[attributed] 마커와 클레임 ID가 붙어 있는지, attributed 문장에 "저자는/논문은/~에 따르면" 같은 귀속 어법이 실제로 들어있는지까지 기계가 검사합니다. 어제 제 요약문이 이 게이트에 두 번 반려당했습니다. 실제 로그입니다: 1차: FAIL — "summary line 44 lacks factual/attributed marker" (마커 없는 문장 발견) 2차: FAIL — "summary line 15 lacks explicit attribution wording" ([attributed]를 붙였는데 문장에 귀속 주어가 없음) 3차: PASS_WITH_CAVEATS — errors: 0 (경고 10건은 not_verified 클레임 — attributed 유지 조건으로 통과) 귀찮은데, 이 귀찮음이 정확히 "생성 결과"와 "검수된 결과"의 차이입니다. 4) 독립 재검색 게이트: 원문 다시 읽기는 검증이 아니다 verified 등급은 캡처한 원문을 재독해서는 못 붙입니다. 원문의 오류를 그대로 통과시키기 때문입니다. 반드시 출처를 새로 검색해서(공식 문서, 다른 1차 자료) 교차 확인해야 verified가 됩니다. 검증을 서브에이전트에 위임할 때도 프롬프트에 "다시 읽지 말고 새로 검색해 대조하라"를 명시합니다.

결과와 배운 점

이 게이트가 최근 실제로 잡은 것

"13만 스타" → 실측 163,642: 유튜버가 소개한 오픈소스 저장소 스타 수. 영상 발언(출처 정합 supported)과 실측(외부 검증)이 달랐습니다. 방향은 같지만 25% 차이 — 제안서에 들어갔으면 숫자가 틀린 문서가 됐습니다. "완전 호환·10배 빠름" → 공식 README 미부합: 영상 주장을 해당 프로젝트 공식 문서와 대조하니 지원 범위가 달랐습니다. attributed로 강등. 공차율 40.2% → 2013년 자료: 시장조사에서 인용 직전에 데이터 시점을 확인하니 13년 묵은 수치였습니다. 이 사건으로 게이트에 "근거 시효" 조항을 추가했습니다 — 시계열 수치는 확인한 날짜가 아니라 데이터의 시점을 병기하고, 5년+ 지났으면 stale 표기 후 재검색. 제 요약문 2건: 위에서 말한 검증기 반려. 검수 대상 1호는 남의 글이 아니라 제 산출물이었습니다.

시행착오

처음엔 검증 = "꼼꼼히 다시 읽기"인 줄 알았습니다. 같은 텍스트를 두 번 읽으면 같은 오류를 두 번 믿게 될 뿐이었습니다. 독립 재검색으로 바꾼 뒤에야 위 1·2번이 잡혔습니다. "확인 못 함"을 상태로 만들어야 했습니다. 비교 대상이 없거나 표본이 부족하면 pass도 fail도 아닌 not_checked/확인 불가로 명기합니다. 빈칸을 통과로 해석하는 순간 게이트가 뚫립니다. 아직 못 한 것: 검증 도구 자체의 재검증(도구가 틀리면 판정 전체가 틀립니다)과, 스터디장님이 소개하신 인간 전문가 합치도 측정. 루브릭 주차(3주차)에서 배워서 붙이고 싶습니다.

꿀팁

게이트 규칙은 "실패 우선"으로 씁니다: 출처 정합이 supported가 아니면 무조건 blocked, not_verified면 factual 금지 — 승격 조건이 아니라 차단 조건부터 정의해야 구멍이 안 납니다. 할루시네이션 도미노를 막는 가장 싼 지점은 인제스트 직후입니다. 요약이 만들어진 뒤에는 어느 문장이 원문에서 왔는지 재구성하는 비용이 훨씬 큽니다.

도움이 필요한 부분

감사 패킷과 압축 패킷의 경계: 근거를 상세히 기록할수록 모델 입력이 무거워집니다(다른 사례글에서 887→10,172 토큰 증가 보고를 봤습니다). 어디까지 모델에게 주고 어디부터 감사용으로 뺄지, 기준을 잡으신 분이 있다면 배우고 싶습니다. 인간 합치도: AI 검수 판정과 사람 판정의 합치율을 개인 규모에서 실용적으로 재는 방법이 궁금합니다.

도움 받은 글·강의

스터디 1주차 OT — 전문가 표준 기반 루브릭(LG AI 연구원 사례), 할루시네이션 도미노 비유 버디님 세법 LLM 위키 시연 — SHA-256 지문, 클레임 단위 판정(서포티드/인서피션트), 일부러 틀린 답을 주입하는 테스트 22기 딥리서치 사례글 — "원문 재독이 아니라 독립 재검색" 게이트의 원류 도도치 이야기 002 — 자기채점 금지, 검증 도구 자체의 재검증