WebFetch로 PDF 표를 요약시켰더니 두 번이나 확신 있게 틀렸다

행정기관이 올린 공고문 PDF 여러 건을 클로드 코드로 처리하면서, WebFetch로 페이지를 요약시켜 핵심 숫자(세대수, 특별공급·일반공급 구분)를 뽑아 콘텐츠를 썼다. 그런데 나중에 원문 PDF를 직접 열어보니, 4건 중 2건에서 숫자가 틀려 있었다.

증상 — 애매한 오답이 아니라 확신에 찬 오답

첫 번째 사례. WebFetch 요약은 이렇게 답했다.

이번 추가모집: 공공지원민간임대 2세대 + 일반공급 2세대 (총 4세대)

원문 PDF를 pdftotext로 직접 뽑아보니 이랬다.

- 공급호수 : 총 125세대 중 공공지원민간임대 111세대 중 금회 추가모집 2세대
(일반공급 2세대 : 18A 1세대, 37A 1세대)

실제로는 “일반공급 2세대”가 전부였다. WebFetch는 “공공지원민간임대 111세대”라는 상위 항목과 “추가모집 2세대”라는 하위 항목을 각각 별도의 숫자로 오인해서 더해버린 것으로 보인다.

두 번째 사례는 더 미묘했다.

WebFetch 요약: "특별공급 1세대, 일반공급 3세대"
원문 PDF:      "일반공급 2세대, 특별공급 1세대 (총 3세대)"

총 세대수(3)는 우연히 앞뒤가 맞았는데, 일반공급 숫자만 2에서 3으로 바뀌어 있었다. 둘 다 “그럴듯하게 말이 되는” 틀린 답이라 요약만 보고는 의심할 지점이 없었다.

원인 — 표가 문장으로 풀리면서 위치 정보가 사라진다

원본 PDF의 표는 대략 이런 구조다.

[공급현황]
주거전용(타입)   공급유형   금회공급호수   보증금   임대료
18.03(18A)      일반       1            6,620    66
37.88(37A)      일반       1            10,800   98

이 표를 사람이 보면 “18A형이 1세대, 37A형이 1세대, 합쳐서 2세대”라는 게 열의 위치로 명확하다. 그런데 웹페이지를 텍스트로 변환하고 그걸 다시 요약하는 과정에서는, 어느 숫자가 어느 열·어느 행에 속했는지에 대한 정보가 사라진다. 남는 건 숫자들의 나열뿐이고, 요약 모델은 그 숫자들을 문맥상 가장 그럴듯한 방식으로 다시 이어 붙인다 — 그 결과가 “공공지원민간임대 2세대 + 일반공급 2세대”처럼, 표에는 없던 조합이다.

이게 무서운 이유는 모델이 확신을 갖고 말한다는 것이다. “잘 모르겠다”거나 “표가 복잡해서 확인이 필요하다”고 하지 않고, 마치 원문에 그렇게 쓰여 있었던 것처럼 단정적으로 답한다. 산문 요약에서는 이런 실수가 나면 문장이 어색해서 눈치채기 쉬운데, 표의 숫자 요약은 애초에 “숫자 하나가 어색한지”를 판단할 근거가 요약문 안에 없다.

어떻게 대응했나 — 요약을 한 겹 걷어냈다

해법은 복잡하지 않았다. 요약을 거치지 않고 원문을 직접 눈으로 보는 것.

# 1) PDF 원본을 받는다
curl -s -A "Mozilla/5.0" -o /tmp/x.pdf "https://example.gov/fileDown.do?atchFileId=...&fileSn=1"

# 2) 텍스트만 뽑는다 (macOS에 poppler의 pdftotext가 이미 있는 경우가 많다)
pdftotext /tmp/x.pdf /tmp/x.txt

# 3) 원하는 문장을 직접 눈으로 확인한다 — 요약이 아니라 원문 그대로
grep -n "공급호수\|주택위치\|공급일정" /tmp/x.txt

grep으로 나온 결과는 PDF에 실제로 인쇄된 문장 그대로다. “공급호수 : 총 125세대 중 공공지원민간임대 111세대 중 금회 추가모집 2세대”처럼, 요약이 아니라 원문이 그대로 나온다. 이 문장을 그대로 인용하면 요약 단계에서 발생하는 오류가 애초에 낄 자리가 없다.

이후 남은 두 건도 같은 방식으로 재검증했는데, 다행히 정확했다 — 이 방식이 “느리지만 확실하다”는 걸 다시 확인한 셈이다.

표가 뒤섞였을 때는 추측하지 않는다

pdftotext도 만능은 아니다. 복잡한 다단 표(30%·40%·50% 같은 여러 단계 옵션이 나열된 표)에서는 숫자 순서가 뒤섞여 나오는 경우가 실제로 있었다. 이럴 때 “아마 이 숫자가 이 타입 것일 거야”라고 추측해서 채워 넣으면, 요약 모델이 틀렸던 것과 똑같은 실수를 사람이 반복하는 셈이다. 그래서 정한 규칙은 하나다 — 애매하면 “확인되지 않는다”고 쓰고, 확신 있는 틀린 숫자를 쓰지 않는다.

정리

표가 있는 공식 문서를 AI로 처리할 때는 요약 결과를 최종 답으로 삼지 않는 게 안전하다. 표는 위치(행·열)가 의미를 만드는 구조인데, 요약은 그 구조를 문장으로 풀면서 위치 정보를 지운다. 지워진 자리는 그럴듯한 추측으로 다시 채워지고, 그 추측은 확신에 찬 문장으로 나온다. curl+pdftotext+grep처럼 요약을 거치지 않고 원문을 직접 보는 단계를 하나 끼워 넣는 것만으로, 이번 사례에서는 오류가 완전히 사라졌다.