# [2편] 검수가 실제로 잡아낸 것들 — 5/5 FAIL과 뒤집힌 결론 3건

- 작성자: [Arin](https://community.clauders.ai/member/imported-member-zKTOlEbpYm)
- 공간: [에이전트 / 노코드 자동화](https://community.clauders.ai/automation)
- 게시: 2026-07-24
- 연재: [AI 결과물 검수 시스템](https://community.clauders.ai/series/ai-output-verification-systems) 3/6편
- 태그: #AI결과물검수
- 주소: https://community.clauders.ai/automation/post/2%ED%8E%B8-%EA%B2%80%EC%88%98%EA%B0%80-%EC%8B%A4%EC%A0%9C%EB%A1%9C-%EC%9E%A1%EC%95%84%EB%82%B8-%EA%B2%83%EB%93%A4-5-5-fail%EA%B3%BC-%EB%92%A4%EC%A7%91%ED%9E%8C-%EA%B2%B0%EB%A1%A0-3%EA%B1%B4-843662dd-10d6-8fc9-837b-37d9e3e44da1

---

> **TL;DR**

> - **충격의 5/5 FAIL**: 직접 읽고 작성한 요약이 전량 FAIL 판정을 받음. 원인은 `pdftotext` 줄바꿈, 유니코드 인코딩 차이, 그리고 과도한 Verbatim 인용 규칙 때문.
> - **가장 무서운 오류 (표 행 밀림)**: 숫자는 원문에 존재하지만 **'누구의 수치인가'가 틀린 오출처(Misattribution)** 발생. 결정론 검수기조차 pass한 이 오류 때문에 확정된 결론이 3건 뒤집힘.
> - **2분류(PASS/FAIL)의 한계**: "틀렸다(Contradicted)"와 "근거가 부족하다(Insufficient)"는 대응 방식이 완전히 다름. 3분류 체계 전환의 필요성 체감.

### 1) 할루시네이션 3종 검증 결과

이번 프로젝트 결과를 스터디 커리큘럼의 프레임워크에 대입해보았습니다.

- **거짓·오출처 (False / Misattribution)**

  👉 **부분적 방어 성공 (FAIL)**: 원문에 없는 수치는 단칼에 잡아내지만, **'표 행 밀림'으로 인한 연관성 오출처는 검수기를 통과함** (사건 2-1).
- **누락 (Omission)**

  👉 **경고 수준 방어 (WARN)**: 키포인트 커버율이 0.6 미만일 때 경고를 띄우지만, Exit Code에는 반영되지 않아 자동 파이프라인을 중단시키지는 못함.
- **부실 (Shallow Summary)**

  👉 **경고 수준 방어 (WARN)**: 최소 인용 개수 미달은 FAIL 처리 가능하나, 요약 내용의 논리적 깊이감까지 판단하는 것은 불가.

### 2) 판정 3분류 체계의 필요성: Insufficient의 부재

현재 제가 구축한 검수 스크립트는 **PASS / FAIL의 2분류 체계**로 작동합니다. 그러나 실전에서는 3분류 체계의 필요성이 절실했습니다.

- **Supported (근거 있음)** ➔ PASS
- **Contradicted (원문과 상충됨)** ➔ FAIL
- **Insufficient (근거 부족/확인 불가)** ➔ **? (현재는 통째로 FAIL 처리)**

현재 구조에서는 "원문 내용과 다르게 틀렸다(Contradicted)"와 "사실일 수 있으나 현재 파일로는 입증이 불가능하다(Insufficient)"가 **동일하게 FAIL로 처리**됩니다.

하지만 이 둘의 후속 조치는 완전히 다릅니다.

- _Contradicted_ ➔ 요약 오류이므로 **내용을 수정**해야 함
- _Insufficient_ ➔ 내용은 사실일 수 있으므로 **원문 PDF 재확인 또는 근거 수치 조율**이 필요함

앞서 언급한 `100200` 뭉침 현상이 전형적인 **Insufficient** 케이스였습니다. 시스템이 이를 구분하지 못하고 단순 FAIL로만 보고했기 때문에, 사람이 직접 원인을 파악하고 수치의 표현 정밀도를 낮추는 작업을 수동으로 수행해야 했습니다.

### 1. 검수는 작성자의 성실함을 평가하지 않는다

원문을 직접 읽고 정성껏 인용을 달았더라도 검수 기준에 미달하면 5/5 FAIL이 납니다. 검수 스크립트는 작성자의 노력이 아니라 "결과물 문자열이 원문에 실제로 존재하는가"라는 건조한 사실만 판정합니다. "내가 성실히 읽었으니 맞을 것"이라는 주관적 가정을 완벽히 배제하는 것이 검수 시스템의 존재 이유입니다.

### 2. "검수 통과"가 "100% 정답"을 의미하지는 않는다

검수를 통과했다고 해서 안심할 수 없습니다. 문자열 대조 방식의 검수는 오출처(잘못된 행의 숫자 인용)를 간과할 수 있습니다. 따라서 **검수 통과는 최소한의 1차 필터**로 인식하고, 표 파싱 등 오류 취약 구간에서는 별도의 검산 규약을 적용해야 합니다.

### 3. 교정 이력을 명확히 남길 때 신뢰도가 올라간다

잘못된 결론이 드러났을 때 이를 은폐하지 않고 **① 무엇이 틀렸는지, ② 왜 발생했는지, ③ 이로 인한 영향 범위가 어디까지인지**를 투명하게 기록했습니다. 영향 범위를 명확히 통제함으로써 결론 하나가 수정되더라도 전체 실행 플랜이 흔들리는 상황을 방지할 수 있었습니다.

## 💡 남은 과제 및 질문

1. **PDF 표(Table) 구조 파싱의 자동화 방안**

   현재는 라벨 수와 데이터 행 수를 비교하는 검산 로직을 수동으로 수행하고 있습니다. `pdfplumber`나 `Unstructured` 같은 표 구조 인식 라이브러리를 적용해 행 밀림 오류를 자동 감지하는 모듈 도입을 검토 중입니다.
2. **결정론 기반의 Insufficient 판정 구현 방식**

   "원문에 문자열이 없다"는 사실을 넘어, 이것이 단순 파싱 오류(Insufficient)인지 명백한 거짓(Contradicted)인지를 결정론적(Zero-LLM) 코드 수준에서 어떻게 정밀하게 분리할 수 있을지 고민을 이어가고 있습니다.
