RAG란? 청킹·임베딩·벡터DB 저장까지 파이프라인 가이드

챗GPT에 질문했는데 전혀 다른 답이 돌아온 적 있으신가요? 이를 AI 환각(Hallucination)이라 합니다. 이 한계를 구조적으로 보완하기 위해 등장한 기술이 RAG(Retrieval-Augmented Generation, 검색 증강 생성)입니다.

RAG란? LLM 시대에 등장한 이유

RAG 뜻과 개념 쉽게 이해하기

RAG(Retrieval-Augmented Generation, 검색 증강 생성)는 외부 문서를 검색(Retrieval)한 뒤 그 내용을 바탕으로 답변을 생성(Generation)하는 AI 구조입니다. 최신 문서나 사내 자료까지 실시간으로 참고할 수 있는 것이 특징이에요.

기존 LLM의 한계와 LLM, RAG의 차이점

LLM(대형 언어 모델)은 학습 데이터가 고정되어 있어 최신 정보를 알 수 없고, 없는 내용을 사실처럼 만들어내는 환각 문제도 있습니다. 기업 내부 문서 같은 비공개 정보도 활용하기 어렵습니다.

RAG는 외부 문서를 실시간으로 검색해 답변에 반영하기 때문에 이 두 한계를 동시에 보완합니다. 검색 근거가 생기는 만큼 환각 위험도 낮아지고, 내부 자료도 활용할 수 있습니다.

구분	LLM 단독	RAG
정보 범위	학습 시점까지만	외부 문서 실시간 참조
환각 위험	높음	낮음 (검색 근거 있음)
내부 자료 활용	불가	가능
최신 정보 반영	불가	가능

그렇다면 RAG와 파인튜닝(Fine-tuning)은 어떻게 다를까요? 

파인튜닝은 특정 도메인 데이터로 모델 자체를 재학습시키는 방식입니다. 학습 비용이 크고 새로운 데이터가 추가될 때마다 재학습이 필요합니다. 

반면 RAG는 모델을 건드리지 않고 외부 문서만 교체하면 되므로 유지 비용이 낮습니다. 실시간 정보 반영이 필요하거나 기업 내부 문서를 활용해야 한다면 RAG가 현실적인 선택입니다.

RAG 파이프라인 전체 구조 이해하기

RAG 파이프라인은 어떻게 동작할까?

RAG는 문서 업로드 → 파싱 → 청킹 → 임베딩 → 벡터DB 저장 → 검색 → 답변 생성 순서로 동작합니다.

앞 단계 품질이 낮으면 이후 모든 단계가 영향을 받습니다.

실무에서 RAG 품질이 나쁠 때 원인의 대부분은 LLM이 아니라 파싱과 청킹 단계에 있습니다. 이 중 문서 파싱은 데이터 로더가 담당하며, 청킹 이후 과정은 별도의 RAG 시스템에서 수행됩니다. PDF 파싱 품질이 낮으면 전문 지식 기반 QA 성능이 직접적으로 떨어지는 것이 실증 실험을 통해 확인된 바 있습니다.

💡 RAG 파이프라인, 첫 단계부터 막히고 있다면? 

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

RAG 검색 정확도, 왜 문서 구조가 중요할까?

문서 파싱이란?

문서 파싱(Document Parsing)은 PDF, HWP·HWPX, PPT 같은 비정형 문서를 AI가 이해할 수 있는 구조화 데이터로 변환하는 과정입니다. 단순 텍스트 추출과 달리, 표의 행·열 관계와 제목·본문의 계층 구조까지 의미 있게 정리하며 JSON·HTML 같은 구조화 형식으로 출력합니다.

국내 공공·기업 환경에서 가장 많이 쓰이는 HWP·HWPX는 상황이 다릅니다. AWS Textract, Azure Document Intelligence, Google Document AI 등 글로벌 Document AI 주요 솔루션 모두 PDF·JPEG·PNG·TIFF 등 범용 포맷만 지원하며 HWP·HWPX 원본 직접 파싱은 지원하지 않습니다. 국내 문서를 RAG에 연결하려는 조직에서 가장 먼저 마주치는 병목 지점이 됩니다.

문서 구조가 깨지면 RAG에서 어떤 일이 생길까?

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

2단 레이아웃 회의록을 단순 텍스트로 추출하면 읽기 순서가 뒤바뀝니다. AI는 뒤섞인 텍스트를 제대로 구분하지 못해 3월 회의 결정 사항을 물어봐도 다른 안건 내용을 섞어서 대답할 수 있어요. 표가 포함된 문서는 더 심각합니다. 예산 표에서 행·열 구조가 무너지면 AI는 ‘1분기’와 ‘2억 원’이 같은 항목이라는 관계를 알지 못해 엉뚱한 숫자를 답합니다.

구조 파싱을 강화한 RAG 시스템은 기준 시스템 대비 약 47%의 질문에서 더 정확한 답변을 제공하는 것으로 나타났습니다. 문서 파싱 품질이 RAG 전체 성능을 좌우하는 핵심 변수입니다.

RAG에서 OCR만으로 부족한 이유

OCR과 문서 구조 분석 차이, 그리고 HWP·HWPX 파싱이 어려운 이유

OCR(Optical Character Recognition, 광학 문자 인식)은 글자를 텍스트로 변환하는 기술이고, 문서 구조 분석(DLA, Document Layout Analysis)은 문서 내 요소들의 위치와 의미를 분석해 제목·본문·표·이미지 등 문서의 구조와 관계를 파악하는 기술입니다. 

같은 ‘2억 원’이라도 표 안의 수치인지 본문 설명인지에 따라 AI는 완전히 다르게 이해합니다. 

OCR은 문자를 인식할 뿐이고, DLA가 있어야 그 문자의 문서 내 역할과 계층을 판별할 수 있습니다. SCAN 연구에 따르면 단순히 제목·문단·표 등을 작은 단위로 잘게 나누는 전통적인 레이아웃 분석 방식은 문맥이 끊겨 오히려 비주얼 RAG 정확도를 최대 40.5%까지 떨어뜨릴 수 있는 것으로 나타났습니다. 

반면 문맥을 보존하는 방식으로 설계된 DLA 기법은 텍스트 RAG 정확도를 최대 9.0%, 비주얼 RAG 정확도를 최대 6.4%까지 끌어올리는 것으로 실험에서 확인되었습니다. 

HWP·HWPX는 국내 업무 환경에 최적화된 독자 포맷이라, 일반 도구로는 내부 구조를 온전히 읽어내기 어렵습니다. PDF로 변환해 파싱하면 각주, 표 병합 셀 같은 핵심 서식이 손실돼요. HWP·HWPX 파일 구조에 직접 접근하는 기술 없이는 RAG 수준의 구조화 데이터 확보가 어렵습니다. 

💡 HWP 원본 구조를 그대로 유지한 채 RAG에 연결하는 방법이 궁금하다면?

PDF 변환 없이 HWP 원본을 직접 파싱하고, DLA·TSR로 표와 문단 계층까지 보존하는 방식을 확인해 보세요. 

👉 한컴 데이터 로더 라이브 데모 보기

청킹(Chunking)과 임베딩, 벡터DB 저장, RAG 검색은 어떻게 이루어질까?

청킹 뜻과 전략 비교

청킹(Chunking)은 긴 문서를 AI가 검색하기 쉬운 작은 의미 단위로 나누는 과정입니다. 청킹 전략 선택은 RAG 시스템 신뢰도에 직접 영향을 줍니다.

고정 크기 전략

구현이 단순하지만 문장 중간에서 끊길 수 있어요. 처리 속도가 우선일 때 씁니다. 

의미 기반 전략

내용이 바뀌는 지점을 판단해 자릅니다. 정확도가 높지만 처리 비용이 큰 편이에요. 

재귀적 전략

제목→단락→문장 순서로 계층을 따라 분할합니다.

RAG 청킹과 LLM 청킹은 목적이 다릅니다. LLM 청킹이 토큰 한계를 맞추기 위한 것이라면, RAG 청킹은 검색 시 의미 있는 조각이 나오도록 구조를 잡는 것입니다.

좋은 청킹은 결국 좋은 파싱에서 시작합니다. 문서의 제목·단락·표 계층이 정확하게 추출되어야 의미 단위 청킹이 가능하기 때문입니다.

임베딩, 벡터DB 저장과 RAG 검색 실패 원인

임베딩(Embedding)은 텍스트를 숫자 배열로 변환해 AI가 의미 기반으로 검색할 수 있게 하는 기술입니다. ‘자동차’와 ‘차량’처럼 표현이 달라도 의미가 비슷하면 같은 맥락으로 인식해요. 쉽게 말해, AI가 단어와 문장의 의미를 이해할 수 있도록 각각의 내용을 숫자로 표현하고, 의미가 비슷한 내용끼리는 가깝게 연결해 주는 작업이라고 볼 수 있습니다.

벡터DB는 이렇게 변환된 데이터를 저장하고, 질문과 의미가 가장 비슷한 정보를 빠르게 찾는 데이터베이스입니다. 마치 도서관 사서가 책 제목이 아니라 내용의 의미를 기준으로 관련 자료를 찾아주는 것과 비슷합니다.

잘못된 청킹이나 표 구조 손실이 있으면 임베딩 단계에서 이미 의미가 흐려져, 아무리 좋은 LLM을 연결해도 벡터DB 검색 정확도에 한계가 생깁니다. RAG 데이터 전처리 단계의 품질이 최종 답변 품질을 결정하는 이유가 여기에 있습니다. 한컴 데이터 로더는 이 중 파싱 단계를 담당하며, 청킹 이후 임베딩·벡터DB 저장·검색 단계는 한컴피디아와 연계해 구성할 수 있습니다. 

RAG관련 자주 묻는 질문 FAQ

HWP, HWPX 파싱, RAG 문서 전처리에서 실제로 어떻게 해결할까?

HWP·HWPX 문서를 구조 손실 없이 RAG에 연결하려면 원본 포맷을 직접 파싱할 수 있는 환경이 필요합니다.

외부 클라우드 API는 폐쇄망에서 쓸 수 없고, HWP·HWPX 고유 구조를 온전히 지원하는 파싱 도구도 사실상 없었습니다. 한컴 데이터 로더는 이 문제를 다음과 같이 해결합니다.

✅ 국내 유일 HWP·HWPX 지원 

한컴의 30년 원천 기술을 기반으로으로 PDF 변환 없이 원본 파일에서 직접 데이터 추출

변경추적 문서·각주·미주·수식·병합 셀 등 20종 이상 레이아웃 요소 인식

✅ 문서 구조 분석(DLA) + OCR + 표 구조 인식(TSR) 복합 AI 단일 파이프라인 

문서 구조 분석(DLA)·OCR·표 구조 인식(TSR)을 단일 파이프라인으로 처리

테두리 없는 표, 병합 셀, 중첩 표까지 인식 

✅ Level 추론 기반 계층 구조 추출 

제목·부제목·본문 등 문단 계층을 자동 판단해 구조화 데이터로 출력

이후 청킹 단계에서 RAG 검색 정확도 향상에 기여 

✅ 다양한 포맷 지원 

HWP·HWPX·PDF·OOXML(PPTX, DOCX, XLSX) 등 다양한 문서 포맷 입력을 지원

포맷 특성에 따라 JSON·HTML 등 구조화 데이터로 추출 가능 

✅ 완전 온프레미스 내재화 

Docker REST API 기반 내부 서버 설치

문서 외부 전송 없이 망 분리·폐쇄망 환경 대응

✅ 한컴 데이터 로더 GS 인증 보유 

공공 조달 및 대기업 납품 레퍼런스 기반 공신력

지금 바로 한컴 데이터 로더를 경험해 보세요!

👉 한컴 데이터 로더 API 가이드 보기

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

---

참고 자료

1. arXiv, 「Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks」, Lewis, P. et al., 2020
2. AWS, 「검색 증강 생성(RAG)이란 무엇인가요?」
3. IBM, 「RAG, 검색 증강 생성이란 무엇인가요?」
4. Microsoft Azure, 「RAG 청킹 단계」
5. IBM, 「LangChain과 watsonx.ai를 사용하여 RAG 청킹 전략 구현」
6. Microsoft Azure, 「RAG 임베딩 생성 단계」
7. arXiv, 「SCAN: Semantic Document Layout Analysis for Textual and Visual RAG」, Ueda et al., EACL 2026
8. arXiv, 「Document Parsing Unveiled: Techniques, Challenges, and Prospects」, Lin, 2024
9. arXiv, 「A Systematic Analysis of Chunking Strategies for Reliable Question Answering」, Bennani & Moslonka, 2026
10. NVIDIA, 「Finding the Best Chunking Strategy for Accurate AI Responses」, 2025
11. arXiv, 「Revolutionizing RAG with Enhanced PDF Structure Recognition」, Lin, 2024
12. AWS Textract, 「지원 문서 포맷」
13. Microsoft Azure, 「Azure Document Intelligence 개요」
14. Google, 「Document AI 지원 파일 유형」
15. 한국경제, 「한컴, ‘한컴 데이터 로더’ 글로벌 출시」, 2024.04
16. 머니투데이, 「HWP 퇴출 아닌 ‘AI 원료化’」, 2026.04