RAG 데이터 전처리란? AI 답변 품질을 결정하는 문서 전처리 가이드
RAG(Retrieval-Augmented Generation, 검색 증강 생성) 시스템에서 AI를 도입했는데도 답변이 부정확한 원인은 AI(LLM) 자체보다 문서를 AI에 넣기 전에 처리하는 방식, 즉 RAG 데이터 전처리에 있는 경우가 많습니다. RAG 시스템에서 전처리가 왜 핵심인지 순서대로 살펴보겠습니다.
RAG란? 검색 증강 생성과 전처리의 역할
RAG 뜻과 기본 개념은 무엇일까?
RAG는 일반 LLM이 학습 데이터만 참고하는 것과 달리 외부 문서, 즉 기업 내부 문서, 사내 매뉴얼, 법령, 보고서를 검색해 관련성 높은 내용을 근거로 답변하는 AI 구조로, 파이프라인의 가장 앞 단계인 문서 전처리 품질이 이후 검색 정확도와 답변 품질에 큰 영향을 미칩니다.
RAG 시스템 동작 구조와 전처리의 역할
RAG는 문서 업로드 → 파싱 → 청킹 → 임베딩 → 벡터DB(임베딩 저장·검색 데이터베이스) 저장 → 검색 → 답변 생성 순서로 작동합니다. 전처리가 부실하면 AI가 관련 없는 정보를 가져와 사실과 다른 답변을 생성하는 오류, 즉 AI가 근거 없이 틀린 내용을 사실처럼 출력하는 할루시네이션 현상이 발생합니다.
전처리 단계가 충분하지 않으면 이후 청킹·임베딩·검색 단계에서도 오류가 이어질 수 있습니다. 특히 HWP·HWPX처럼 국내에서 광범위하게 사용되는 포맷은 글로벌 Document AI 주요 솔루션 대부분이 원본 직접 파싱을 지원하지 않아 일반 도구로 구조를 온전히 보존하기 어렵습니다.
RAG 파이프라인 구축 시, 문서 전처리 부담과 정보 누락 문제가 걱정된다면?
비정형 문서, 왜 구조화 변환이 필요할까요?
HWP·HWPX·PDF·OOXML 같은 비정형 문서는 AI가 바로 이해할 수 없어 구조화 데이터 변환이 선행되어야 RAG가 올바르게 작동합니다.
구조가 손실된 문서에서 검색 오류가 생기는 이유
문서 구조가 손실되면 AI는 이를 기반으로 관련 없는 답변을 생성합니다.
OOXML처럼 텍스트 추출만 지원하는 포맷이나 단순 OCR(Optical Character Recognition, 광학 문자 인식) 방식으로는 표 구조, 문단 계층, 읽기 순서(Reading Order) 정보가 유지되지 않을 수 있습니다.
예를 들어 표에 있는 숫자가 본문 내용과 뒤섞이면 AI는 어떤 숫자가 표의 값이고 어떤 내용이 설명 문장인지 구분하지 못합니다. 그 결과 관련 정보를 제대로 찾지 못하거나 사실과 다른 답변을 할 수 있습니다. 표 구조나 문단 계층 같은 정보가 사라지면 AI가 근거로 삼을 문맥 자체가 줄어듭니다.
구조 손실은 단순한 포맷 문제가 아닙니다. 청킹·임베딩·검색 정확도까지 함께 낮아지는 RAG 품질 저하의 원인이 됩니다.
OCR과 DLA는 무엇이 다를까요
OCR은 글자 인식 기술이고, DLA(Document Layout Analysis, 문서 구조 분석)는 문서 전체 구조를 이해하는 기술입니다. RAG 품질을 높이려면 두 기술이 함께 필요합니다.
OCR만으로 RAG 구축이 어려운 이유
OCR은 이미지나 스캔 문서의 글자를 텍스트로 변환하는 기술입니다. 글자 인식에 특화되어 있어 표 구조, 문단 계층, 읽기 순서(Reading Order) 같은 문서 구조 정보는 함께 보존하기 어렵습니다. PDF는 보이는 순서와 실제 추출 순서가 다를 수 있어, OCR 단독으로는 의미 단위가 뒤섞이는 문제가 생깁니다.
한편 DLA는 추출된 텍스트가 표인지 제목인지 본문인지 구조 관계를 파악합니다. 같은 숫자라도 표 안의 수치인지 본문 설명인지에 따라 AI가 완전히 다르게 이해하는 것도 이 구조 관계 파악 덕분입니다.
정리하면 OCR은 글자를 읽는 기술이고, DLA는 그 글자가 표인지 제목인지 맥락을 파악하는 기술입니다. 두 기술이 하나의 파이프라인 안에서 함께 작동해야 RAG 품질이 높아집니다.
HWP·HWPX 구조 유지가 검색 정확도에 미치는 영향
HWP·HWPX는 독자적인 파일 구조를 가진 포맷으로 일반 OCR이나 PDF 변환만으로는 표·각주·들여쓰기 정보가 손실되어 RAG 검색 정확도가 떨어집니다.
한국 공공기관·법무·금융에서 가장 많이 쓰이는 문서 포맷이지만 글로벌 Document AI 주요 솔루션 대부분이 PDF·JPEG·PNG·TIFF 등 범용 포맷만 지원하며 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
Q1. RAG에서 문서 전처리는 왜 중요한가요?
문서 구조가 손실되면 청킹·임베딩 품질이 낮아져 검색 정확도와 AI 답변 품질이 함께 떨어지기 때문입니다. RAG 검색 정확도(Retrieval Accuracy)는 전처리 단계에서 결정됩니다.
Q2. OCR만으로 RAG 구축이 가능한가요?
가능은 하지만 단순한 문서가 아니라면 한계가 발생할 수 있습니다. OCR만 사용할 경우 문서의 글자 정보만 추출되기 때문에 제목·본문·리스트 같은 문단 유형이나 표 구조·읽기 순서 등의 구조 정보가 손실될 수 있습니다.
Q3. HWP·HWPX 파일도 RAG에 활용할 수 있나요?
활용 가능하지만 독자적인 파일 구조로 인해 일반 OCR이나 PDF 변환만으로는 구조 정보가 손실될 수 있습니다. HWP·HWPX 원본을 직접 파싱하는 솔루션이 필요합니다. 한컴 데이터 로더는 한컴 원천 기술 기반으로 HWP·HWPX 원본을 변환 없이 처리해 구조 손실을 최소화합니다.
Q4. RAG 문서 전처리 솔루션, 어떤 기준으로 선택해야 하나요?
HWP·HWPX 원본 직접 파싱 지원 여부, DLA·OCR·TSR 단일 파이프라인 여부, 폐쇄망 온프레미스 구동 가능 여부가 핵심 선택 기준입니다. 한컴 데이터 로더는 이 세 조건을 모두 충족하며 GS 인증 보유로 공공·금융·법무 환경에서도 검증된 솔루션입니다.
RAG 문서 전처리, 한컴 데이터 로더로 해결하는 방법
지금까지 살펴본 것처럼 RAG 성능은 LLM보다 전처리 단계에서 먼저 결정됩니다. 문서 구조가 온전히 보존되어야 청킹이 의미 단위를 유지하고, 임베딩 품질이 높아지고, 벡터DB 검색 정확도가 확보됩니다. 전처리 품질이 낮아지면 이후 모든 단계가 함께 저하됩니다.
문제는 실제 기업 환경에서 다루는 문서의 대부분이 HWP·HWPX·PDF·OOXML과 같이 구조를 보존하며 파싱하기 까다로운 포맷이라는 점입니다. 특히 HWP·HWPX는 글로벌 Document AI 솔루션도 원본 직접 파싱을 지원하지 않아 일반적인 방식으로는 구조 손실 없이 RAG 파이프라인에 연결하기 어렵습니다.
한컴 데이터 로더는 RAG 전처리의 가장 앞 단계인 문서 파싱부터 구조화 데이터 변환까지 전 과정을 단일 파이프라인으로 지원합니다.
✅ DLA·OCR·TSR 복합 AI를 하나의 파이프라인으로 처리해 문서 내 구조화된 텍스트와 객체 정보를 정확하게 추출
✅ HWP·HWPX·PDF·OOXML 등 기업 환경에서 실제로 쓰이는 포맷을 모두 지원하며, HWP·HWPX는 원본 파일을 변환 없이 직접 파싱
✅ Level 추론 기반 계층 구조 추출로 제목·단락·표의 위계를 자동 판단해 구조화 데이터로 출력, 이후 청킹 단계의 품질 향상에 기여
✅ 컨테이너 기반 REST API로 온프레미스 완전 내재화해 망 분리·폐쇄망 환경에서도 문서 외부 유출 방지
✅ GS 인증으로 공공·금융·법무 환경에서도 검증된 솔루션
지금 RAG 답변이 기대에 못 미친다면, LLM보다 한컴 데이터 로더로 전처리 환경을 먼저 점검해 보시기 바랍니다.
참고 자료
- arXiv, 「Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks」, Lewis et al., NeurIPS 2020
- AWS, 「검색 증강 생성(RAG)이란 무엇인가요?」
- AWS, 「OCR이란 무엇인가요?」
- Microsoft, 「Chunk large documents for RAG and vector search in Azure AI Search」
- arXiv, 「Revolutionizing RAG with Enhanced PDF Structure Recognition」, Lin, arXiv:2401.12599
- arXiv, 「Document Parsing Unveiled: Techniques, Challenges, and Prospects」, Lin, arXiv:2410.21169
- arXiv, 「SCAN: Semantic Document Layout Analysis for Textual and Visual RAG」, Ueda et al., arXiv:2505.14381, EACL 2026
- AWS Textract, 「지원 문서 포맷」
- Microsoft Azure, 「Azure Document Intelligence 개요」
- Google, 「Document AI 지원 파일 유형」