지자체·공공기관 RAG 프로젝트가 문서 포맷 때문에 흔들리는 5가지 패턴
모델이 아니라 입력이 문제인 경우가 훨씬 많다
RAG 프로젝트가 기대한 만큼의 답변 품질을 못 낼 때, 가장 먼저 의심받는 것은 임베딩 모델이나 LLM 자체입니다. 하지만 실제로 원인을 추적해보면 모델 이전 단계, 즉 문서를 벡터 DB에 넣기 전 전처리 과정에서 정보가 이미 손상된 경우가 적지 않습니다. 아래는 HWP/HWPX 기반 문서를 다루는 프로젝트에서 반복적으로 관찰되는 패턴입니다. 특정 기관이나 사업의 사례가 아니라, 문서 포맷 특성상 구조적으로 발생하기 쉬운 일반적인 패턴을 정리한 것입니다.
패턴 1: 표의 행·열 관계가 사라져 수치가 엉뚱하게 매칭된다
예산 총괄표나 평가 배점표처럼 행과 열의 교차 지점 자체가 의미인 문서에서, 단순 텍스트 추출은 셀 내용을 순서대로 나열해버립니다. 그 결과 "A 항목 300만원"이어야 할 정보가 "B 항목 300만원"으로 LLM에 전달되고, 답변은 그럴듯해 보이지만 틀린 수치를 인용하게 됩니다. 이런 오류는 표를 직접 열어보지 않으면 발견하기 어렵고, 챗봇 답변만 봐서는 '자연스럽게 틀린' 것처럼 보이기 때문에 원인 추적이 오래 걸립니다.
패턴 2: 구버전 문서가 최신 문서와 동일한 신뢰도로 검색된다
부서별·연도별로 파편화된 아카이브를 그대로 색인하면, 이미 개정되어 폐기된 규정과 현행 규정이 벡터 DB에 나란히 존재하게 됩니다. 검색 시 두 문서 모두 관련도가 비슷하게 나올 수 있어, AI가 폐기된 기준을 현행 기준인 것처럼 인용하는 결과로 이어집니다. 문서에 유효 기간이나 개정 이력 메타데이터가 없으면 이 문제는 시스템적으로 감지되지 않습니다.
패턴 3: 제목·본문 구분이 사라져 문서 구조가 평평해진다
앞선 글에서 다뤘듯 HWPX의 서식 정보는 본문에 직접 있지 않고 별도 스타일 정의를 참조하는 구조입니다. 이 참조 관계를 풀어내지 않고 텍스트만 추출하면 "제1장", "제1조" 같은 제목과 본문 조항이 구분 없이 하나의 덩어리로 합쳐집니다. 이렇게 되면 청킹(chunking) 단계에서 조항 하나가 중간에 잘리거나, 반대로 관련 없는 여러 조항이 한 청크에 뒤섞이는 문제가 생깁니다.
패턴 4: 이미지에 담긴 정보가 통째로 유실된다
조직도, 절차 흐름도, 도장·서명이 이미지로 삽입된 문서에서 텍스트만 추출하면 그 이미지가 전달하던 정보는 그냥 사라집니다. 사용자가 "이 문서에 있는 승인 절차를 알려줘"라고 물었을 때, 정작 절차가 흐름도 이미지로만 표현되어 있었다면 AI는 답할 수 있는 근거 자체가 없는 상태가 됩니다.
패턴 5: 보안 등급이 다른 문서가 같은 파이프라인을 통과한다
대외비 문서와 공개 문서를 구분 없이 동일한 처리 경로(특히 외부 API를 호출하는 파이프라인)에 태우는 경우입니다. 이는 검색 품질 문제라기보다 컴플라이언스 리스크에 가깝지만, 실제로는 "일단 다 넣고 나중에 걸러내자"는 접근에서 뒤늦게 발견되는 경우가 많습니다.
공통적으로 필요한 것: 넣기 전에 검증하는 단계
다섯 가지 패턴의 공통점은, 문제가 모델 튜닝이 아니라 벡터 DB에 넣기 이전 단계에서 이미 결정되어 있었다는 점입니다. 문서를 대량으로 색인하기 전에 문서 유형별 샘플을 뽑아 표·구조·메타데이터가 원문과 일치하는지 확인하는 검증 단계를 파이프라인에 넣는 것이, 사후에 답변 품질을 튜닝하는 것보다 근본적인 해결책입니다.
참고 자료
이 글에서 다룬 패턴은 문서 포맷의 구조적 특성에서 비롯되는 일반적인 현상을 설명한 것이며, 특정 기관·기업의 실제 사례를 지칭하지 않습니다.