RAG 데이터 전처리란? AI 답변 품질을 결정하는 문서 전처리 가이드

RAG(Retrieval-Augmented Generation, 검색 증강 생성) 시스템에서 “AI 도입했는데 왜 엉뚱한 답변이 나오지?”라는 물음의 원인은 AI(LLM) 자체보다 문서를 AI에 넣기 전에 처리하는 방식, 즉 RAG 데이터 전처리에 있는 경우가 많습니다. RAG 시스템에서 전처리가 왜 핵심인지 순서대로 살펴보겠습니다.

RAG란? 검색 증강 생성과 전처리의 역할

RAG 뜻과 기본 개념은 무엇일까?

RAG(Retrieval-Augmented Generation, 검색 증강 생성)는 외부 문서를 검색해 그 내용을 기반으로 답변하는 AI 구조로, 파이프라인의 가장 앞 단계인 문서 전처리 품질이 이후 검색 정확도와 답변 품질에 큰 영향을 미칩니다. 

RAG는 일반 LLM이 학습 데이터만 참고하는 것과 달리, 기업 내부 문서, 사내 매뉴얼, 법령, 보고서를 검색해 관련성 높은 내용을 근거로 답변해요.

RAG 시스템 동작 구조와 전처리의 역할

RAG는 문서 업로드 → 파싱 → 청킹 → 임베딩 → 벡터DB 저장 → 검색 → 답변 생성 순서로 작동합니다. 전처리가 부실하면 AI가 엉뚱한 정보를 가져와 사실과 다른 답변을 생성하는 오류, 즉 AI가 근거 없이 틀린 내용을 사실처럼 출력하는 할루시네이션(hallucination) 현상이 발생합니다.

전처리 단계가 부실하면 이후 청킹·임베딩·검색 전 단계가 연쇄적으로 영향을 받아요. 특히 HWP·HWPX처럼 국내에서 광범위하게 사용되는 포맷은 AWS Textract, Azure Document Intelligence, Google Document AI 등 글로벌 Document AI 주요 솔루션 모두 원본 직접 파싱을 지원하지 않아 일반 도구로 구조를 온전히 보존하기 어렵습니다.

RAG 파이프라인 구축 시, 문서 전처리 부담과 정보 누락 문제가 걱정된다면?

👉  한컴 데이터 로더 살펴보기

비정형 문서, 왜 구조화 변환이 필요할까요?

PDF, HWP·HWPX, PPTX 같은 비정형 문서는 AI가 바로 이해할 수 없어, 구조화 데이터 변환이 선행되어야 RAG가 올바르게 작동합니다.

구조가 깨진 문서에서 검색 오류가 생기는 이유

문서 구조가 손실되면 AI는 구조가 깨진 텍스트를 기반으로 엉뚱한 답변을 생성합니다.

OOXML처럼 텍스트 추출만 지원하는 포맷이나 단순 OCR 방식으로는 표 구조, 문단 계층, 읽기 순서(Reading Order) 정보가 유지되지 않을 수 있습니다.  

예를 들어 표에 있는 숫자가 본문 내용과 뒤섞이면, AI는 어떤 숫자가 표의 값이고 어떤 내용이 설명 문장인지 구분하지 못합니다. 그 결과 관련 정보를 제대로 찾지 못하거나, 잘못되거나 엉뚱한 답변을 할 수 있습니다. 결국 문서 구조가 손실되면 정보의 의미도 함께 손실되고, 이는 RAG 할루시네이션(hallucination)의 주요 원인이 됩니다.

구조 손실은 단순한 포맷 문제가 아닙니다. 청킹·임베딩·검색 정확도까지 연쇄적으로 무너지는 RAG 품질 저하의 시작점이에요. 구조를 보존한 파싱이 선행되어야 이후 모든 단계가 제대로 작동합니다.

OCR과 문서 구조 분석(DLA)은 무엇이 다를까요?

OCR(Optical Character Recognition, 광학 문자 인식)은 글자 인식 기술이고, 문서 구조 분석(DLA, Document Layout Analysis)은 문서 전체 구조를 이해하는 기술입니다. RAG 품질을 높이려면 두 기술이 함께 필요해요.

OCR만으로 RAG 구축이 어려운 이유

OCR은 이미지나 스캔 문서의 글자를 텍스트로 변환하는 기술입니다. 글자 인식에 특화되어 있어 표 구조, 문단 계층, 읽기 순서(Reading Order)  같은 문서 구조 정보는 함께 보존하기 어려워요. PDF는 보이는 순서와 실제 추출 순서가 다를 수 있어, OCR 단독으로는 의미 단위가 뒤섞이는 문제가 생기죠.

반면 문서 구조 분석(Document Layout Analysis)은 추출된 텍스트가 표인지 제목인지 본문인지 구조 관계를 파악합니다. 같은 숫자라도 표 안의 수치인지 본문 설명인지에 따라 AI가 완전히 다르게 이해하는 것도 이 구조 관계 파악 덕분이에요.

정리하면 OCR은 글자를 읽는 기술이고, DLA는 그 글자가 표인지 제목인지 맥락을 파악하는 기술입니다. RAG 품질을 높이려면 두 기술이 하나의 파이프라인 안에서 함께 작동해야 합니다.

HWP·HWPX 구조 유지가 검색 정확도에 미치는 영향

HWP·HWPX는 독자적인 파일 구조를 가진 포맷으로, 일반 OCR이나 PDF 변환만으로는 표, 각주, 들여쓰기 정보가 손실되어 RAG 검색 정확도가 떨어집니다.

한국 공공기관, 법무, 금융에서 가장 많이 쓰이는 문서 포맷이지만, AWS Textract, Azure Document Intelligence, Google Document AI 등 글로벌 Document AI 주요 솔루션 모두 PDF·JPEG·PNG·TIFF 등 범용 포맷만 지원하며 HWP·HWPX 원본 직접 파싱은 지원하지 않아요. HWP·HWPX 원본을 직접 파싱해야 RAG 검색 정확도를 유지할 수 있습니다.

HWP·HWPX 원본을 직접 파싱하려면 독자 포맷 구조에 접근하는 원천 기술이 필요합니다. 일반 도구처럼 PDF로 변환해 처리하면 각주·병합 셀·들여쓰기 같은 핵심 서식이 손실될 수 있어요.

💡 한컴의 30년 기술을 기반으로 HWP·HWPX 원본을 변환 없이 직접 파싱하는 방법은?

👉한컴 데이터 로더 살펴보기

RAG 청킹과 임베딩: 전처리 품질 영향

청킹은 문서를 의미 단위로 나누는 과정, 임베딩은 텍스트를 숫자 벡터로 변환해 검색 가능하게 만드는 과정입니다. 두 단계 모두 전처리 품질에 의존해요. 

청킹 품질이 검색 정확도를 결정하는 이유

청킹은 문서를 의미 단위로 나누는 과정으로, 청킹 전략 선택이 RAG 시스템의 검색 정확도(Retrieval Accuracy)를 직접 결정합니다.

청킹은 단순히 잘게 자르는 게 아니라 문단의 의미가 온전히 유지된 채 나누는 것이 핵심입니다. 의미 유사도 기반 방식(Semantic Chunking), 계층 구조 기반 방식(Hierarchical Chunking) 모두 문서 구조가 사전에 보존되어 있어야 효과적으로 작동해요. 문서 구조 분석(DLA)이 선행되지 않으면 어떤 청킹 방식도 한계에 부딪혀요.

의미 기반 청킹이든 계층 구조 기반 청킹이든, 문서의 제목·단락·표 계층이 먼저 정확하게 추출되어야 효과적으로 작동합니다. 어떤 청킹 전략을 선택하기 전에 문서 파싱 품질을 먼저 확보해야 하는 이유입니다.

잘못된 청킹과 임베딩이 AI 답변 품질을 떨어뜨리는 이유

청킹 품질이 낮으면 임베딩 단계에서 의미가 흐려지고, 결국 벡터DB 검색 정확도와 AI 답변 품질이 함께 떨어집니다.

청킹 품질이 낮으면 문맥이 분리되거나 의미 단위가 깨지고, 텍스트를 숫자 벡터로 변환하는 임베딩 품질도 함께 낮아져요. 결국 벡터DB(임베딩 저장·검색 데이터베이스) 검색 정확도가 낮아져 RAG 할루시네이션(hallucination) 가능성이 높아집니다. RAG 임베딩 실패의 원인이 LLM이 아닌 전처리 단계에 있는 경우가 대부분인 이유가 여기에 있어요.

RAG전처리 관련 자주 묻는 질문 FAQ

RAG 문서 전처리, 한컴 데이터 로더로 해결하는 방법

지금까지 살펴본 것처럼 RAG 성능은 LLM보다 전처리 단계에서 먼저 결정됩니다. 문서 구조가 온전히 보존되어야 청킹이 의미 단위를 유지하고, 임베딩 품질이 높아지고, 벡터DB 검색 정확도가 확보됩니다. 전처리가 무너지면 이후 모든 단계가 함께 무너져요.

문제는 실제 기업 환경에서 다루는 문서의 대부분이 PDF·HWP·HWPX·Microsoft Office 문서와 같이 구조를 보존하며 파싱하기 까다로운 포맷이라는 점입니다. 특히 HWP·HWPX는 글로벌 Document AI 솔루션도 원본 직접 파싱을 지원하지 않아, 일반적인 방식으로는 구조 손실 없이 RAG 파이프라인에 연결하기 어렵죠.

한컴 데이터 로더는 RAG 전처리의 가장 앞 단계인 문서 파싱부터 구조화 데이터 변환까지, 전 과정을 단일 파이프라인으로 지원합니다.

✅ 문서 구조 분석(DLA) · OCR · 표 구조 인식(TSR) 복합 AI를 하나의 파이프라인으로 처리해 문서 내 구조화된 텍스트와 객체 정보를 정확하게 추출 

✅ HWP·HWPX·PDF·OOXML(DOCX·XLSX·PPTX) 등 기업 환경에서 실제로 쓰이는 포맷을 모두 지원하며, HWP·HWPX는 원본 파일을 변환 없이 직접 파싱 

✅ Level 추론 기반 계층 구조 추출로 제목·단락·표의 위계를 자동 판단해 구조화 데이터로 출력, 이후 청킹 단계의 품질 향상에 기여 

✅ Docker REST API 기반 온프레미스 완전 내재화로 망 분리·폐쇄망 환경에서도 문서 외부 유출 방지

✅ GS 인증 보유로 공공·금융·법무 환경에서도 검증된 솔루션 

지금 RAG 답변이 기대에 못 미친다면, LLM보다 한컴 데이터 로더로 전처리 환경을 먼저 점검해 보세요.

👉 한컴 데이터 로더 라이브 데모 사용하러 가기 

👉 한컴 데이터 로더 도입 문의하기

---

참고 자료

1. arXiv, 「Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks」, Lewis et al., NeurIPS 2020
2. AWS, 「검색 증강 생성(RAG)이란 무엇인가요?」
3. AWS, 「OCR이란 무엇인가요?」
4. Microsoft, 「Chunk large documents for RAG and vector search in Azure AI Search」
5. arXiv, 「Revolutionizing RAG with Enhanced PDF Structure Recognition」, Lin, arXiv:2401.12599
6. arXiv, 「Document Parsing Unveiled: Techniques, Challenges, and Prospects」, Lin, arXiv:2410.21169
7. arXiv, 「SCAN: Semantic Document Layout Analysis for Textual and Visual RAG」, Ueda et al., arXiv:2505.14381, EACL 2026
8. AWS Textract, 「지원 문서 포맷」
9. Microsoft Azure, 「Azure Document Intelligence 개요」
10. Google, 「Document AI 지원 파일 유형」