RAG 문서 파싱 도구는 무엇을 쓰면 되나요?

문서 종류에 따라 다르게 써야 해요. 일반 오피스 문서·PDF는 markitdown으로 마크다운 변환하면 표와 제목 구조가 살아나고, 표가 핵심인 계약서·정산서·재무제표는 liteparse 같은 표 특화 파서를 따로 태우는 게 안전합니다. 이미지나 스캔 PDF는 OCR을 한 단계 더 거쳐야 해요. 하나의 만능 파서로 모든 문서를 처리하려는 시도가 정확도를 크게 떨어뜨립니다.

RAG 청크 크기는 얼마로 잡아야 하나요?

글자 수로 기계적으로 자르지 말고 의미 단위로 나누세요. 500자마다 자르면 한 문장이 두 청크로 쪼개지거나 표 하나가 여러 조각으로 나뉘어 검색 근거가 깨집니다. 마크다운 헤더(##) 기준으로 나누고 표는 통째로 한 청크에 담는 방식이 안정적이에요. 청크마다 어느 문서·몇 페이지·어느 섹션인지 메타데이터를 붙이면 출처 표시와 디버깅이 쉬워집니다.

RAG가 헛소리를 한다면 범인은 모델이 아니라 문서 파싱이다 (markitdown·liteparse)

Q: RAG 평가셋은 몇 건이면 충분한가요?

실제 사용자 질문 100건 이상을 권합니다. 사내 질문 120건으로 평가셋을 만들어 정답 문서가 검색 상위 3개 안에 드는 비율과 환각률을 매주 측정하면, 파서나 청킹 로직을 고칠 때 회귀를 잡을 수 있어요. 평가셋이 없으면 파이프라인을 고칠 때마다 도박이 됩니다.

"챗봇이 자꾸 엉뚱한 답을 해요. 모델을 GPT로 바꿔야 하나요?" 올봄 한 B2B SaaS 팀의 RAG 사내 문서봇을 인계받았을 때 들은 첫 마디예요. 결론부터 말하면, 모델은 멀쩡했어요. 범인은 문서 파싱이었습니다. 마침 같은 주 깃허브 트렌딩 1면에 microsoft/markitdown(별 13만+)과 run-llama/liteparse가 나란히 올라왔는데, 둘 다 "문서를 LLM이 읽을 수 있는 형태로 잘 바꾸는" 도구예요. 우연이 아니라고 봅니다.

RAG가 헛소리를 하면 정말 모델 문제일까요?

RAG(검색 증강 생성)는 "질문 → 관련 문서 검색 → 그 내용을 근거로 답변" 구조예요. 그런데 많은 팀이 답이 틀리면 곧장 모델부터 의심합니다. 우리가 인계받은 봇을 들여다보니, PDF를 통째로 텍스트 추출기에 넣은 게 화근이었어요. 표가 줄글로 뭉개지고, 2단 레이아웃이 좌우로 뒤섞이고, 헤더·푸터·페이지 번호가 본문에 섞여 들어갔죠. 검색은 "쓰레기를 넣으면 쓰레기가 나온다"는 원칙에 정확히 충실했습니다. 모델이 아무리 좋아도 근거 자체가 깨져 있으면 정답이 나올 수 없어요.

지표로 보니 답변 오류 64%가 "검색된 청크 자체가 깨진 경우"였어요. 모델 교체로 잡을 수 있는 건 나머지 36%뿐이었죠.

우리가 파이프라인을 다시 짠 순서

1단계 — 파싱부터 사람이 눈으로 검수

가장 먼저 한 일은 모델 변경이 아니라, 원본 문서 30개를 파싱한 결과를 사람이 직접 읽어본 것이에요. markitdown으로 오피스 문서·PDF를 마크다운으로 바꾸니 표가 표로, 제목이 제목으로 살아났어요. 표가 많은 계약서·정산서는 liteparse 같은 전용 파서를 따로 태웠고요. 이 단계 하나로 "검색된 근거가 사람이 봐도 말이 되는" 비율이 눈에 띄게 올랐습니다.

2단계 — 청킹(chunking)을 의미 단위로

그다음은 자르는 방식이었어요. 기존엔 "500자마다 뚝뚝" 잘라서 한 문장이 두 청크로 쪼개지거나, 표 한 개가 세 조각 났습니다. 이걸 마크다운 헤더(##) 기준 + 표는 통째로 한 청크로 바꿨어요. 청크마다 "어느 문서, 몇 페이지, 어느 섹션"인지 메타데이터도 붙였고요. 출처를 답변에 같이 보여주니, 사용자가 틀린 답을 바로 잡아낼 수 있게 됐습니다.

3단계 — 평가셋으로 회귀를 막다

마지막으로 실제 사내 질문 120건으로 평가셋을 만들었어요. 정답 문서가 검색 상위 3개 안에 들어오는 비율(검색 정확도)과, 최종 답변의 환각률을 매주 측정합니다. 이제 누가 파서나 청킹 로직을 건드리면 평가셋이 회귀를 잡아줘요. 신기하게도, 이 시점이 되자 "모델을 GPT로 바꿔야 하나"라는 질문 자체가 사라졌습니다. 오류율이 이미 충분히 낮아졌거든요.

덤 — 표·이미지가 많은 문서는 따로 길을 내세요

한 가지 더 배운 게 있어요. 계약서·정산서·재무제표처럼 표가 핵심인 문서는, 일반 텍스트 파서로는 절대 안 됩니다. 셀의 행·열 관계가 무너지면 "3월 매출 1,200만 원"이 엉뚱한 달에 붙어버려요. 우리는 표 중심 문서만 별도 파이프라인으로 분리해, 표는 마크다운 표 또는 행 단위 문장("2026년 3월 매출은 1,200만 원이다")으로 풀어서 넣었어요. 이미지·스캔 PDF는 OCR을 한 단계 더 태웠고요. 문서 종류별로 파서를 다르게 가져가는 것만으로도 표 관련 질문의 정확도가 눈에 띄게 올라갑니다.

RAG 문서 파싱, 자주 묻는 질문

문서 파싱 도구는 무엇을 쓰면 되나요?

정답은 "문서 종류에 따라 다르게"예요. 일반 오피스 문서·PDF는 markitdown으로 마크다운으로 변환하면 표와 제목 구조가 잘 살아납니다. 표가 핵심인 계약서·정산서·재무제표는 liteparse 같은 표 특화 파서를 따로 태우는 게 안전하고요. 이미지나 스캔 PDF는 OCR을 한 단계 더 거쳐야 합니다. 하나의 만능 파서로 모든 문서를 처리하려는 시도가 정확도를 크게 떨어뜨려요.

청크 크기는 얼마로 잡아야 하나요?

"500자마다 기계적으로 자르기"는 피하세요. 한 문장이 두 청크로 쪼개지거나 표 하나가 여러 조각으로 나뉘면 검색 근거가 깨집니다. 글자 수가 아니라 의미 단위로 — 마크다운 헤더(##) 기준으로 나누고 표는 통째로 한 청크에 담는 방식이 안정적이에요. 청크마다 "어느 문서, 몇 페이지, 어느 섹션"인지 메타데이터를 붙이면 출처 표시와 디버깅이 함께 쉬워집니다.

RAG 평가셋은 몇 건이면 충분한가요?

실무적으로는 실제 사용자 질문 100건 이상을 권해요. 우리는 사내 질문 120건으로 평가셋을 만들어, 정답 문서가 검색 상위 3개 안에 드는 비율과 환각률을 매주 측정했습니다. 평가셋이 있어야 파서·청킹 로직을 고칠 때 회귀를 잡을 수 있고, 없으면 고칠 때마다 도박이 됩니다. MVP 단계에서 AI 기능을 설계할 때도 이 평가셋을 처음부터 자산으로 쌓아두면 모델을 바꿔도 흔들리지 않아요.

이 회고에서 남길 교훈은?

RAG 품질은 모델 이전에 문서 파이프라인에서 상당 부분 결정됩니다. 파싱·청킹·메타데이터를 먼저 보세요.
"파싱 결과를 사람이 읽어보기"는 30분이면 되는데, 가장 많은 걸 알려주는 디버깅입니다.
평가셋 100건 이상이 있어야 파이프라인을 안심하고 고칠 수 있어요. 없으면 고칠 때마다 도박입니다.

RAG·AI 서비스를 만들 때 모델만 갈아끼우다 시간을 태우는 팀이 정말 많아요. 진짜 지렛대는 데이터 파이프라인에 있습니다. AI 특화 개발이 필요하다면 트리숲(TreeSoop)도 좋은 선택이에요. 검색·RAG 파이프라인 설계가 전문인 팀이거든요. RAG·챗봇 같은 AI 기능을 기존 서비스에 붙일 때 유형별 비용과 기간이 궁금하다면 기존 서비스 AI 기능 추가 비용 완전 가이드를 먼저 보세요. MVP 단계에서 RAG 챗봇·사내 지식봇을 제대로 설계하고 싶다면 포텐랩에 편하게 문의 주세요. 포텐랩은 30여 건의 프로젝트를 인계하며 "모델보다 데이터 파이프라인" 원칙을 표준으로 삼고 있습니다.