RAG 파이프라인이란? AI 할루시네이션부터 구성 요소까지 완벽 정리

“우리 회사에도 AI 챗봇 붙여보자.”

최근 기업 내부에서 사내 업무에 AI 도입을 하려는 논의가 늘어나고 있습니다. 실제로 활용해보면 문서 요약, 이메일 초안, 보고서 정리까지 상당히 유용합니다.

그런데 사내 규정, 제품 매뉴얼, 내부 보고서 기준으로 답변하게 만들면 문제를 마주하게 됩니다.

최신 개정안을 묻자 없는 내용을 말하거나, 분명 문서에 있는 내용인데도 찾지 못하는 경우가 있습니다. 이런 현상을 AI 할루시네이션이라고 합니다.

생성형 AI는 학습하지 않은 정보에 대해서도 그럴듯한 답변을 만들어낼 수 있습니다. 특히 사내 규정, 제품 매뉴얼, 보고서처럼 내부에만 있는 문서는 별도로 연결하지 않으면 답변 근거로 활용하기 어렵습니다. 이 한계를 보완하는 방식이 RAG(Retrieval-Augmented Generation, 검색 증강 생성)입니다.

RAG는 사내 문서를 검색한 뒤, 근거 기반으로 답변을 생성하게 만드는 기술입니다. RAG가 무엇인지, 그리고 RAG 파이프라인이 어떤 단계로 구성되는지 정리해보겠습니다.

RAG란? – LLM의 한계와 RAG가 등장한 이유

AI 할루시네이션이란, LLM은 왜 없는 내용을 지어낼까?

할루시네이션이란 실제로 존재하지 않는 것을 보거나 듣는 현상을 가리키는 말로, LLM 분야에서는 모델이 학습 데이터나 제공된 컨텍스트에 근거하지 않는 내용을 생성하는 현상을 의미합니다.

AI 할루시네이션이 발생하는 이유는 LLM의 구조적 한계와 관련이 있습니다. 먼저 LLM은 학습 데이터가 특정 시점에 고정되기 때문에, 이후 개정된 법령이나 내부 지침, 제품 정책을 기본적으로 알 수 없습니다. 

또한 회사 계약서, 제품 사양서, 보안 지침처럼 기업 내부에만 있는 비공개 문서는 처음부터 학습하지 않았습니다.

그 결과 2026년 법령과 같이 최신 정보가 필요한 질문에는 오래된 기준으로 답하거나, 내부 문서에 근거해야 하는 질문에는 존재하지 않는 내용을 사실처럼 말할 수 있습니다. 기업이 AI 챗봇을 업무에 도입할 때 RAG가 필요한 이유도 바로 여기에 있습니다.

RAG(검색 증강 생성) 개념과 읽는 법

RAG란, 대규모 언어 모델인 LLM이 답변을 생성하기 전에 외부 문서를 실시간으로 검색해 관련 정보를 찾아오고, 그 내용을 근거로 신뢰할 수 있는 답변을 생성하는 과정입니다. 

쉽게 말하면, RAG는 AI가 질문과 관련된 외부 문서나 사내 문서를 먼저 검색한 뒤, 확인된 근거를 바탕으로 답변해 AI 할루시네이션을 줄이는 방식입니다.

참고로 RAG는 다양하게 발음되고 있습니다. 해외에서는 [래그]라고 발음하며 국내에서는 [알에이지]라고 발음하기도 합니다.

LLM과 RAG 사용 비교표

기존 LLM과 RAG의 차이는 답변 전에 ‘관련 문서를 검색해 근거로 활용하는지’에 있습니다.

구분	LLM 단독 방식	RAG 기반 방식
답변 근거	학습된 데이터와 입력된 질문 중심	질문과 관련된 외부 문서·사내 문서 중심
정보 범위	학습 시점 이후 정보나 내부 자료 반영이 어려움	최신 문서와 내부 자료를 함께 참조 가능
AI 할루시네이션	근거가 부족하면 그럴듯한 오답이 나올 수 있음	확인된 근거를 바탕으로 답변해 위험을 줄일 수 있음
정보 업데이트	새 정보를 반영하려면 재학습이나 별도 입력이 필요	문서만 교체·추가해도 지식 기반을 갱신할 수 있음

🔗 RAG에 대해 더 깊이 알고 싶다면 [RAG 데이터 전처리란? AI 답변 품질을 결정하는 문서 전처리 가이드]

사내 AI 챗봇 구축 시 RAG가 필요한 이유

RAG를 활용하면 기업이 보유한 내부 문서나 최신 정보를 AI 답변에 반영할 수 있습니다. 이를 통해 별도로 대규모 모델을 다시 학습시키지 않아도, 비교적 짧은 시간과 낮은 비용으로 자사 업무에 맞는 생성형 AI 기능을 구현할 수 있습니다.

특히 사내 AI 챗봇처럼 실제 업무에 활용되는 서비스라면 RAG의 역할이 더 중요합니다. 내부 정책, 보안 지침, 제품 설명서처럼 기업마다 다른 정보를 근거로 답변해야 부정확한 안내나 오래된 정보가 전달되는 위험을 줄일 수 있기 때문입니다.

AI 챗봇이 잘못된 정보를 그럴듯하게 안내하면 단순한 오답을 넘어 고객 응대 오류나 업무상 책임 문제로 이어질 수 있습니다.

실제로 한 항공사는 자사 챗봇이 유가족 할인 운임 정책을 잘못 안내한 일로 고객 보상 책임을 인정받기도 했습니다.

RAG 파이프라인 구축 과정

RAG 파이프라인이란, 문서를 AI가 검색할 수 있는 형태로 가공·저장하고, 질문이 들어오면 관련 문서를 찾아 답변을 생성하기까지의 전체 처리 흐름을 단계별로 구조화한 것입니다.

RAG는 단순한 기술 개념을 넘어, 실제 업무 문서를 AI가 검색하고 활용하게 만드는 방식으로 자리 잡고 있습니다. 실제로, 국회는 방대한 HWP 문서를 AI로 검색·활용하기 위해 RAG 기반 빅데이터 플랫폼을 구축했습니다. 

RAG 파이프라인은 두 구간으로 나뉩니다. 질문 전 미리 준비하는 오프라인 단계(1~5단계)와, 질문이 들어오면 실시간으로 작동하는 온라인 단계(6~7단계)입니다.

1단계 – 문서 업로드 (Document Loader)

PDF, HWP, HWPX, OOXML, 웹페이지 등 AI가 참고할 문서를 RAG 시스템에 불러오는 단계입니다.

이 단계에서 문서를 시스템에 넣어야 이후 파싱, 청킹, 임베딩 과정을 거쳐 검색 가능한 데이터로 만들 수 있습니다. 지원하지 않는 문서 형식은 내용 추출이나 구조 분석이 어려울 수 있어, RAG 답변 품질에도 영향을 줄 수 있습니다.

2단계 – 파싱 (Parsing)

불러온 문서에서 텍스트, 표, 제목·본문 구조 등을 추출해 AI가 처리할 수 있는 형태로 정리하는 단계입니다. 이 과정을 파싱(Parsing)이라고 합니다.

PDF나 HWP, HWPX 파일은 사람 눈에는 잘 읽히지만, AI 시스템이 바로 문서 구조를 이해하기는 어렵습니다. 

스캔 PDF는 이미지처럼 처리될 수 있고, HWP·HWPX처럼 전용 포맷을 가진 문서는 별도의 해석 과정이 필요할 수 있습니다.

단순히 글자만 추출하는 것이 아니라, 표에서 행과 열의 관계, 제목과 본문의 계층 구조까지 추출해야 다음 단계에서 AI가 정확하게 이해할 수 있습니다.

예를 들어 예산표가 있다고 해보겠습니다. 

“1분기 마케팅 예산: 2억 원”이라는 정보가 표 안에 있을 때, 파싱이 제대로 되지 않으면 AI는 “1분기”와 “2억 원”이 같은 항목이라는 관계를 파악하기 어렵습니다. 수치를 읽어도 어떤 항목의 숫자인지 구분하기 어렵습니다.

따라서 파싱이 정확해야 이후 청킹, 임베딩, 검색 단계에서도 문서의 의미를 더 안정적으로 활용할 수 있습니다.

🔗 파싱이란 무엇인가요? [데이터 파싱(Parsing)개념 총정리 – 의미부터 과정까지 쉽게 이해하기]

3단계 – 청킹 (Chunking)

파싱이 끝난 문서를 AI가 검색하기 쉬운 작은 단위로 나누는 과정입니다. 수백 페이지짜리 문서를 통째로 넣으면 정보가 너무 많아 AI가 필요한 내용을 정확히 찾기 어려워집니다. 청킹은 긴 문서를 의미 있는 조각, 즉 Chunk 단위로 나눠 검색 정확도를 높이는 작업입니다.

청킹 전략은 문서와 목적에 따라 달라집니다. 글자 수나 토큰 수 기준으로 일정하게 자르는 고정 크기 방식, 내용이 바뀌는 지점을 기준으로 나누는 의미 기반 방식, 제목·단락·문장 같은 구분자를 순서대로 적용해 문맥을 최대한 보존하는 재귀적 방식이 대표적입니다.

다만 어떤 전략이든 좋은 청킹은 문서 구조를 정확하게 보존한 파싱에서 시작합니다. 문서의 제목, 단락, 표 계층이 앞 단계에서 정확하게 추출되어야 AI가 검색하기 좋은 의미 단위로 나눌 수 있기 때문입니다.

4단계 – 임베딩 (Embedding)

청킹된 텍스트 조각을 숫자 배열인 벡터로 변환하는 단계입니다. AI는 텍스트를 그대로 비교하는 것이 아니라, 숫자로 변환된 벡터 간 유사도를 계산해 의미가 가까운 내용을 찾아냅니다.

임베딩의 핵심은 의미 기반 검색입니다.

예를 들어 “자동차 수리 비용”을 검색했을 때 문서에 “차량 정비 비용”이라고 쓰여 있어도 찾아낼 수 있는 이유가 여기에 있습니다. 표현이 달라도 의미가 가까우면 벡터 공간에서 비슷한 위치에 배치되기 때문입니다.

다만 검색 품질은 임베딩 모델만으로 결정되지 않습니다. 앞 단계에서 파싱·청킹이 부정확하면 문맥이 끊기거나 의미 단위가 어색해진 채로 벡터화될 수 있습니다. 이 경우 좋은 임베딩 모델을 사용하더라도 사용자가 원하는 정보를 정확히 찾는 데 한계가 생길 수 있습니다.

5단계 – 벡터DB 저장

변환된 벡터를 저장하고, 필요할 때 빠르게 검색할 수 있도록 관리하는 단계입니다. 벡터DB는 텍스트 자체를 저장해 단어가 정확히 일치하는지 찾는 것이 아니라, 임베딩된 벡터를 기준으로 유사도가 높은 데이터를 검색할 수 있도록 설계된 데이터베이스입니다.

예를 들어 사용자가 “마케팅 예산”을 검색하면, 해당 질문도 벡터로 변환됩니다. 이후 벡터DB는 저장된 문서 벡터들과 비교해 의미상 가까운 내용을 찾아냅니다. 그래서 문서 안에 “광고비”나 “홍보 비용”처럼 다른 표현이 쓰여 있어도, 문맥상 관련성이 높다면 검색 결과에 포함될 수 있습니다. 대표적인 벡터DB로는 ChromaDB, Pinecone, Milvus 등이 있습니다. 

여기까지가 문서를 미리 수집하고 검색 가능한 형태로 준비하는 오프라인 단계입니다. 이제 사용자가 질문을 입력하면 온라인 단계가 시작됩니다.

6단계 – 검색 (Retrieval)

사용자가 질문을 입력하면 시스템은 그 질문도 벡터로 변환한 뒤, 벡터DB에서 의미가 가장 가까운 문서 조각을 찾아옵니다. 이 역할을 담당하는 구성 요소가 리트리버(Retriever)입니다.

리트리버의 성능은 앞선 파싱, 청킹, 임베딩 품질에 크게 영향을 받습니다.

파싱이 깨진 문서, 의미가 손실된 청크, 잘못 변환된 벡터가 누적되면 리트리버가 아무리 정교해도 관련 없는 조각을 가져올 수 있습니다. LangChain은 리트리버 기반의 RetrievalQA 체인을 제공해 이 과정을 하나의 파이프라인으로 연결할 수 있도록 돕습니다.

7단계 – 답변 생성 (Generation)

리트리버가 찾아온 문서 조각과 사용자 질문을 합쳐 LLM에 전달하면, LLM이 그 내용을 근거로 최종 답변을 생성합니다. RAG가 없을 때는 LLM이 학습 데이터만 보고 답했다면, 이 단계에서는 실제 문서를 참고해 답하는 구조입니다.

단, LLM은 넘겨받은 내용을 기반으로 답변을 구성할 뿐입니다. 앞 단계에서 잘못된 문서 조각이 넘어오면 LLM 성능이 아무리 높아도 답변 품질은 떨어집니다. RAG 파이프라인에서 LLM은 마지막 단계일 뿐, 전체 품질은 앞단이 결정합니다.

RAG 파이프라인 구축 실패의 주요 원인 – 파싱 단계 점검의 필요성

RAG를 도입했는데도 답변 품질이 기대에 못 미친다면, LLM이나 리트리버보다 파싱 단계를 먼저 점검해보세요.

파싱 단계에서 표 구조가 손실되면 청킹 단위가 흐트러지고, 임베딩 품질이 낮아지고, 리트리버가 관련 없는 문서 조각을 가져올 수 있습니다. 결국 LLM은 잘못된 근거로 답변을 생성할 수밖에 없습니다. 파이프라인은 각 단계가 연결된 구조이기 때문에, 앞단의 품질 문제는 이후 모든 단계에 영향을 주게 됩니다.

HWP·HWPX, 왜 일반 파서로는 한계가 있을까?

국내 공공·금융·법무 환경은 HWP·HWPX 문서가 대부분입니다. 하지만 많은 글로벌 파싱 솔루션은 HWP·HWPX를 지원하지 않거나 일부 기능만 지원하고 있습니다. 이를 해결하기 위해 HWP·HWPX를 PDF로 변환한 뒤 파싱하는 우회 방식을 사용하는 경우도 있습니다.

하지만 이 과정에서 각주·병합 셀·다단 구조·계층 정보가 손실되곤 합니다. 구조가 사라진 데이터는 청킹 및 임베딩 과정에 영향을 끼치게 됩니다.

RAG 파이프라인 구축의 시작, 한컴 데이터 로더 문서 파싱 솔루션

🖥️한컴 데이터 로더

한컴 데이터 로더는 HWP·HWPX·PDF·OOXML(DOCX·XLSX·PPTX) 등 다양한 문서 포맷을 구조화 데이터로 변환하는 문서 파싱(Document Parsing) 솔루션입니다. 한컴 30년 원천 기술을 기반으로 하며 특히 공공기관의 주요 포맷인 HWP·HWPX 원본을 PDF 변환 없이 직접 파싱할 수 있습니다.

HWP·HWPX 원본 직접 파싱 – PDF 변환 없이 유지

HWP·HWPX는 국내 업무 환경에 최적화된 독자 포맷이라, PDF로 변환해 파싱하면 각주·병합 셀·계층 구조 같은 핵심 서식이 손실됩니다. 한컴 데이터 로더는 이 변환 과정 없이 HWP·HWPX 원본 파일에서 직접 데이터를 추출합니다. 각주·미주·수식·변경 추적·병합 셀 등 다양한 레이아웃 요소를 손실 없이 인식합니다.

DLA·OCR·TSR 복합 AI – 표와 문서 계층 구조까지 보존

문서 구조 분석 (DLA, Document Layout Analysis)은 2단 레이아웃처럼 복잡한 문서도 사람이 읽는 순서 그대로 본문 흐름을 파악합니다. 표 구조 인식 (TSR, Table Structure Recognition)은 표 내부의 행과 열 관계를 복원해 구조화된 데이터로 출력합니다. 테두리 없는 표, 병합 셀, 중첩 표까지 인식하기 때문에 같은 수치라도 표 안의 데이터인지 본문 설명인지 구분할 수 있습니다. OCR (Optical Character Recognition, 광학 문자 인식)은 이미지 안에 포함된 텍스트까지 추출합니다.

RAG 파이프라인이 제대로 작동하려면 AI에게 넘어가는 데이터부터 정확해야 합니다. 그 시작이 파싱 단계이고, 파싱 품질이 전체 파이프라인 성능을 좌우하게 됩니다.

지금 구축 중인 RAG에서 HWP·HWPX·PDF·OOXML 파싱 품질이 걱정되시나요? 라이브 데모에서 설치과정없이 바로 체험해보세요.

👉 내 문서로 한컴 데이터 로더 체험해 보기

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

RAG 파이프라인 관련 자주 묻는 질문 FAQ

---

참고 자료

1. NVIDIA, 「RAG 101 」
2. 위키독스, 「랭체인 입문부터 응용까지」
3. AWS,「검색 증강 생성이란? 」
4. Intel, 「RAG란?」
5. IBM, 「What is RAG?」,2024
6. CBC News, 「Air Canada chatbot lawsuit 」
7. 조선비즈, 「한컴·삼성SDS 국회 빅데이터 플랫폼 수주 」
8. ETRI,「거대언어모델의 환각현상 완화 및 평가 기술 동향」, 2025 
9. 네이버 클라우드, 「 [온라인 웨비나] RAG 기반 AI 애플리케이션 개발 가이드 (고급) 」,2025