RAG 시스템 처음 구축한다면? 문서 파싱부터 질의 응답까지 단계별 정리

HANCOM 2026.08.11

“사내 문서로 챗봇을 만들라는데, RAG가 뭔지부터 막막해요.”

“구성 요소가 너무 많은데, 대체 어디서부터 손대야 하죠?”

RAG(Retrieval-Augmented Generation, 검색 증강 생성) 시스템을 처음 구축할 때 누구나 어려움을 겪습니다. RAG는 LLM이 답하기 전에 외부 문서를 먼저 검색해 근거로 삼는 기술인데, 들여다보면 청킹·임베딩·벡터DB 같은 낯선 용어가 줄줄이 등장합니다. 이번 글에서는 RAG의 개념부터 7가지 구성 요소, LangChain·LlamaIndex 구현 방법, 정확도를 좌우하는 문서 파싱·전처리까지 전체 흐름을 단계별로 정리합니다.

RAG 시스템이란? 검색 증강 생성 개념과 등장 배경

RAG(검색 증강 생성)는 LLM이 답변하기 전 외부 문서를 검색해 근거로 활용하는 기술로, 학습 데이터의 한계와 할루시네이션 문제를 보완하기 위해 도입되었습니다.

RAG 개념과 정의

RAG는 LLM이 답변을 생성하기 전 신뢰할 수 있는 외부 지식 소스에서 관련 정보를 먼저 검색하고, 그 정보를 근거로 답변을 만드는 기술입니다. 이름 그대로 검색(Retrieval) + 증강(Augmented) + 생성(Generation) 세 동작이 순서대로 결합된 구조를 뜻합니다.

문서가 수천 페이지면 LLM에 통째로 넣을 수 없어, 필요한 부분만 검색해 근거로 넣는 것이 RAG입니다. RAG 범용 미세 조정 방법 관련 논문에서도 외부 검색 인덱스를 결합하면 답변이 더 구체적이고 사실에 가까워진다고 보고했습니다.

LLM 단독 사용의 한계와 할루시네이션 문제

LLM은 학습 시점 이후의 정보나 학습하지 않은 도메인 지식을 알지 못해, 모르는 내용을 사실처럼 지어내는 할루시네이션(Hallucination, 환각)이 발생합니다.

원인은 두 가지입니다. 학습이 끝난 시점 이후의 정보를 알 수 없는 지식 제한 시점(knowledge cutoff)과, 학습하지 않은 사내 규정이나 전문 문서에 대한 도메인 지식 부재입니다. IBM도 모델이 새 데이터를 학습하지 못하면 환각이 발생하기 쉽다고 설명합니다.

RAG가 필요한 이유

RAG는 외부 데이터를 검색해 답변 근거로 활용하기 때문에, 모델을 재학습시키지 않고도 최신 정보를 반영하고 할루시네이션을 줄일 수 있습니다.

파인튜닝은 모델을 다시 학습해야 하지만, RAG는 외부 인덱스만 업데이트해 최신 정보를 반영할 수 있습니다. 또한 검색에 활용한 문서를 함께 제시할 수 있어 답변의 근거를 확인하기 쉽다는 장점이 있습니다. 재학습 비용 없이 최신 정보를 반영하고, 답변의 출처까지 확인할 수 있다는 점이 RAG를 선택하는 주요 이유입니다.

RAG 시스템 구성도, 핵심 구성 요소 7가지

RAG 시스템 구성도, 문서추출부터 LLM 답변까지

RAG 시스템은 문서추출 → 파싱 → 청킹 → 임베딩 → 벡터DB 저장 → 검색 → LLM 답변 순서로 작동합니다. 단계가 많아 보여도 두 그룹으로 나눠 보면 이해하기 쉽습니다.

문서 추출 – 원본 문서에서 내용을 가져옵니다
파싱 – 텍스트와 구조 정보로 추출합니다
청킹 – 문서를 작은 단위로 나눕니다
임베딩 – 나뉜 텍스트를 숫자 벡터로 변환합니다
벡터DB 저장 – 변환한 벡터를 검색용 저장소에 적재합니다
검색 – 질문과 가장 유사한 내용을 찾아냅니다
LLM 답변 – 찾은 내용을 근거로 답을 생성합니다

앞쪽 다섯 단계는 데이터를 미리 준비하는 인덱싱 과정이고, 뒤쪽 두 단계(검색·LLM 답변)는 질문이 들어올 때마다 실행되는 과정입니다.

AWS 지침서에도 임베딩 저장은 한 번이면 되지만 검색·증강·생성은 질문마다 반복된다고 안내하고 있습니다. 이 1회 준비와 반복 실행의 구분은 뒤에서 다룰 구축 방법을 이해하는 기준이 됩니다.

문서 파싱, RAG의 첫 단계이자 품질의 기준

문서 파싱(Document Parsing)은 HWP·HWPX·PDF 등 다양한 형식의 원본 문서를 텍스트와 구조 정보로 추출하는 단계로, 이후 청킹·임베딩·검색 품질을 결정합니다.

구조 정보가 이 단계에서 손상되면 이후 모든 단계가 구조 정보가 손실된 데이터를 그대로 이어받습니다. Unstructured의 오픈 소스 내용처럼 문서를 제목(Title)·본문(NarrativeText)·표(Table) 요소로 나누는 것이 파싱의 핵심인데, 국내 환경에 최적화된 HWP·HWPX는 그 난이도가 한층 높아집니다. 한컴 데이터 로더는 이런 HWP·HWPX를 PDF로 변환하지 않고 원본 바이너리 그대로 직접 파싱해 표 구조·각주·메타데이터를 보존하는 방식을 씁니다.

청킹과 임베딩의 역할

청킹은 문서를 작은 단위로 분할하는 과정이고, 임베딩은 분할된 텍스트를 의미를 담은 숫자 벡터로 변환하는 과정입니다.

청크가 너무 크면 서로 다른 내용이 하나로 섞여 검색 결과가 부정확해지고, 너무 작으면 앞뒤 맥락이 끊겨 의미를 제대로 파악하기 어렵습니다. 글자 수만 기준으로 문서를 자르는 전통적 방식은 제목이나 문단 같은 문서 구조를 반영하지 못합니다. RAG 청크와 프레임 워크를 연구에서는 충분한 의미를 담은 청크를 만들지 못한다고 지적합니다.

벡터 데이터베이스와 Top-K 검색

벡터 데이터베이스는 임베딩된 벡터를 저장하고, 사용자 질문과 가장 유사한 벡터를 빠르게 찾아내는 검색 전용 저장소입니다. 대표적인 벡터 데이터베이스로는 FAISS, Chroma 등이 있습니다.

Top-K는 검색 결과 중 유사도가 높은 항목을 몇 개까지 가져올지 결정하는 값입니다. K가 너무 크면 관련성이 낮은 정보까지 함께 검색될 수 있고, 너무 작으면 필요한 정보를 놓칠 수 있어 적절한 값을 선택하는 것이 중요합니다.

LLM 답변 생성 단계

LLM은 검색된 문서 조각을 컨텍스트로 받아, 사용자 질문과 결합한 프롬프트를 바탕으로 최종 답변을 생성합니다.

프롬프트는 검색한 문서 내용과 사용자 질문이 합쳐진 형태입니다. 모델이 자체적으로 기억하는 정보가 아니라 검색된 근거로 답하기 때문에, 앞 단계에서 얼마나 정확한 자료를 찾아 왔는지가 답변 품질을 좌우합니다.

RAG 시스템 구축 방법, 전처리부터 답변 생성까지

RAG 시스템 구축은 문서를 추출·구조화하는 전처리 영역과 청킹부터 답변 생성까지 처리하는 검색·생성 영역으로 구분되며, 두 영역을 각각 적합한 솔루션으로 연결하는 과정입니다.

RAG 시스템 구축, 문서

RAG 시스템 구축 프로세스는 문서를 추출·구조화하는 전처리 영역과 청킹부터 답변 생성까지 처리하는 검색·생성 영역으로 구분되며, 두 영역을 각각 적합한 솔루션으로 연결하는 과정입니다.

1단계, 문서 구조 분석과 RAG 문서 전처리

문서 전처리 단계에서는 원본 문서의 레이아웃, 표, 문단 계층을 분석해 구조화된 데이터로 변환하며, 이 결과물의 품질이 이후 청킹 정확도를 결정합니다.

이 과정의 핵심은 텍스트·이미지·표·그래픽을 구분하고 위치와 관계를 파악하는 DLA(Document Layout Analysis, 문서 구조 분석)입니다. 분석 결과는 LangChain의 도큐먼트 로더(DocumentLoader)가 만드는 표준 Document 객체처럼 정리됩니다. 다만 포맷과 표 구조, 한국어 문서 특성까지 고려해야 해서 이 단계만 전문적으로 처리하는 전처리 솔루션을 앞단에 두기도 합니다.

2단계, 청킹·임베딩·벡터 DB 저장

전처리된 데이터는 청킹을 거쳐 임베딩 모델로 벡터화되고, 벡터 데이터베이스에 저장되어 이후 검색에 활용됩니다.

이 과정은 질문이 들어오기 전에 검색에 필요한 데이터를 미리 준비하는 인덱싱 단계로, 일반적으로 RAG 프레임워크가 청킹·임베딩·벡터 데이터베이스 저장을 수행합니다.

3단계, 검색과 LLM 답변 생성

사용자 질문이 들어오면 동일한 임베딩 모델로 벡터화한 뒤 유사도 검색을 수행하고, 검색된 문서를 LLM에 전달해 최종 답변을 생성합니다.

이 RAG 검색 프로세스는 질문을 임베딩으로 바꿔 벡터DB에서 유사도 검색으로 관련 청크를 추출한 뒤, 프롬프트로 구성해 LLM이 답변하는 흐름입니다. 질문도 저장된 문서와 같은 방식으로 벡터화해야 의미가 비슷한 내용을 제대로 찾아낼 수 있습니다.

RAG 구현 방법, LangChain과 LlamaIndex 비교

RAG는 LangChain, LlamaIndex 같은 프레임워크로 구현할 수 있으며, 각 프레임워크는 문서 로딩부터 검색·생성까지 컴포넌트를 조합하는 방식이 다릅니다.

LangChain 기반 RAG 구현 방식

LangChain은 도큐먼트 로더, 텍스트 스플리터(Text Splitter), 리트리버(Retriever), 체인(Chain) 등의 컴포넌트를 조합해 RAG 파이프라인을 구성하는 프레임워크입니다.

구현 흐름은 도큐먼트 로더로 문서를 불러오고, 텍스트 스플리터로 나눈 뒤, 임베딩을 거쳐 벡터스토어에 저장하고, 리트리버로 검색한 결과를 체인으로 연결해 LLM을 호출하는 순서입니다. 컴포넌트를 조립하는 모듈형 구조라 복잡한 워크플로우에도 유연하게 대응할 수 있습니다.

LlamaIndex 기반 RAG 구현 방식

LlamaIndex는 다양한 데이터 소스를 인덱싱하는 데 특화된 프레임워크로, 문서 연결과 인덱스 구성에 강점이 있습니다.

핵심은 여러 소스의 콘텐츠를 Document 객체로 변환한 뒤 인덱스로 구축하는 데이터 커넥터입니다. LlamaIndex 공식 문서는 이 적재 과정을 불러오기·변환·인덱싱·저장 흐름으로 설명합니다. 같은 RAG라도 LangChain이 체인·에이전트 구성에 무게를 둔다면, LlamaIndex는 데이터 인덱싱과 검색 최적화에 강점이 있습니다.

RAG 문서 전처리 도구 선택 기준

RAG 문서 전처리 도구는 처리할 문서 포맷과 구조 복잡도에 따라 선택이 달라지며, 일반 텍스트·PDF는 기본 도큐먼트 로더로 충분하지만 복잡한 표나 국내 문서 포맷은 별도 전처리가 필요합니다.

청킹·검색·체인 구성처럼 파이프라인을 연결하는 일은 LangChain·LlamaIndex의 도큐먼트 로더가 잘 처리하지만, 이들은 PDF·텍스트 위주로 최적화돼 병합 셀이 섞인 표나 HWP·HWPX 같은 국내 포맷까지 구조를 보존하기는 어려운 경우가 있습니다.

AI타임스 보도에 따르면 따르면 한컴 데이터 로더는 PDF·오피스 문서에서 텍스트와 다양한 객체를 추출해 AI 학습용 데이터로 전처리하는 솔루션입니다. 이후 DLA와 OCR(Optical Character Recognition, 광학 문자 인식)·TSR(Table Structure Recognition, 표 구조 인식) 기반으로 HWP·HWPX·PDF·OOXML 전반의 구조화 데이터 추출까지 지원 범위를 넓혔습니다.

💡 표 구조나 HWP·HWPX 파싱이 RAG 파이프라인의 병목이라면, 한컴 데이터 로더 라이브 데모에서 실제 문서를 올려 추출 결과를 직접 확인할 수 있습니다.

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

LangChain과 LlamaIndex, 무엇이 다를까

LangChain은 다양한 LLM 체인과 에이전트 구성에 강하고, LlamaIndex는 대규모 문서의 인덱싱과 검색 최적화에 강점이 있어 프로젝트 목적에 따라 선택이 달라집니다.

IBM은 LangChain을 LLM 애플리케이션용 오케스트레이션 프레임워크로, LlamaIndex를 데이터 오케스트레이션 프레임워크로 구분합니다.

LangChain과 LlamaIndex의 강점과 적합 용도 비교

구분	LangChain	LlamaIndex
강점 영역	체인·에이전트 등 워크플로우 오케스트레이션	데이터 인덱싱·검색 최적화
적합한 경우	복크플로우, 다양한 도구 통잡한 워합	대규모 문서 질의, 가벼운 RAG
특화점	범용 LLM 애플리케이션 구성	데이터 소스 연결·인덱스 구축

다만 두 프레임워크 모두 결국 입력 문서 품질에 성능이 좌우됩니다. 아무리 잘 조립해도 처음 추출한 데이터가 부실하면 그 한계를 넘기 어렵습니다.

RAG 시스템 구축 시 자주 발생하는 문제와 해결 방법

RAG 구축 시 자주 발생하는 문제는 할루시네이션, 표·계층 구조 손실로 인한 검색 정확도 저하이며, 두 문제 모두 입력 문서의 전처리 품질과 직결됩니다.

RAG 환각 방지를 위한 핵심 원칙

RAG에서 할루시네이션을 줄이려면 검색된 문맥 안의 내용만 답변하도록 프롬프트에 명시하고, 문맥에서 답을 찾을 수 없을 때는 모른다고 답하도록 제약을 거는 것이 핵심 원칙입니다.

다만 RAG가 할루시네이션을 줄여도 완전히 없애지는 못합니다. LLM 오류에 대한 연구에 따르면 관련 컨텍스트가 주어져도 LLM이 뒷받침되지 않는 정보나 모순을 포함하는 경우가 여전히 많다고 보고되었습니다. 즉, 환각을 근본적으로 줄이는 길은 결국 입력 단계의 문서 품질에 있습니다.

TSR, 병합 셀과 다단 헤더 추출 방법

TSR은 셀 간의 행·열 관계를 복원해 병합 셀과 다단 헤더가 있는 표도 정형 데이터로 변환하는 기술입니다.

입력 단계에서 표 구조가 손실돼 검색 정확도가 떨어지는 경우가 많습니다. 표를 단순 텍스트로 처리하면, 어떤 값이 어떤 항목에 속하는지 알려주던 셀 간의 연결 정보가 없어지기 때문입니다.

STC(Structure-Aware Tabular Chunking, 구조 인식 표 청킹) 프레임워크 관련 연구에는 법률 계약서처럼 표가 많은 데이터를 대상으로, 질문에 맞는 문서 조각을 검색 결과 상위에 얼마나 잘 올리는지 보는 정확도 지표(MRR·Recall@1, 1에 가까울수록 정답을 잘 찾은 것)를 측정했습니다.

그 결과 표 구조를 보존해 청킹했을 때 이 지표는 약 0.36 수준에서 검색 방식에 따라 0.6~0.75 수준까지 향상됐습니다. 이는 표 구조를 유지한 청킹이 검색 성능 향상에 도움이 된다는 의미입니다. 따라서 TSR을 지원하는 전처리 솔루션을 사용하면, 복잡한 표가 많은 문서에서도 검색 정확도를 높이는 데 도움이 될 수 있습니다.

문서 전처리 품질과 RAG 성능의 관계

문서 전처리 품질은 RAG 시스템 전체 성능의 상한선을 결정하며, 추출 단계에서 발생한 오류는 청킹·검색·생성 단계로 그대로 전파됩니다.

구조 정보가 없는 텍스트는 의미 단위로 나누기 어렵고, 문맥이 끊긴 청크가 검색되면 LLM은 문맥에 맞지 않는 답을 생성합니다. ChatDOC의 자체 비교실험에서도 구조를 인식한 파싱이 일반 추출보다 우세 47퍼센트, 동률 38퍼센트, 열세 15퍼센트로 더 나은 결과를 보였습니다. 결국 문서 추출 단계부터 점검하는 것이 RAG 구축의 핵심입니다.

RAG 시스템 구축, 무엇부터 시작해야 할까

RAG 구축 전 체크리스트

RAG 시스템 구축 전에는 처리할 문서 포맷, 보안 환경, 인프라 조건, 표·이미지 비중 네 가지를 먼저 점검해야 합니다.

이 네 항목은 어떤 솔루션 조합이 필요한지를 결정하는 중요한 기준으로, 모델부터 고르기 전에 우리 문서와 환경이 어디에 해당하는지 확인해 보면 시행착오를 크게 줄일 수 있습니다.

RAG 구축 전 점검해야 할 네 가지 항목과 확인 내용

점검 항목	확인할 내용
문서 포맷	HWP·HWPX 등 국내 포맷 처리가 필요한가
보안 환경	외부 전송이 제한되는 폐쇄망 환경인가
인프라 조건	CPU 전용 등 제한된 환경에서 구동해야 하는가
표·이미지 비중	복잡한 표·이미지가 많아 AI 파이프라인 연동이 중요한가

외부로 문서를 내보내기 어려운 폐쇄망이라면 내부 서버에 직접 설치하는 온프레미스 방식이, 우선 작게 검증부터 하고 싶다면 페이지 단위로 과금하는 SaaS 방식이 파일럿 용도로 잘 맞습니다.

문서 전처리에서 막힐 때 확인할 점

문서 전처리 단계에서 표나 한국어 문서 구조가 깨졌다면, 원인은 RAG 프레임워크가 아니라 입력 문서를 구조화하는 전처리 솔루션에 있는 경우가 많습니다.

지금까지 짚은 할루시네이션, 표 구조 손실, 검색 정확도 저하는 겉으론 제각각이지만 공통 원인은 하나, 바로 문서 전처리 품질입니다.

CIO Korea 보도에 따르면 LLM의 환각 현상을 줄이는 해법으로 RAG가 주목받고 있지만, 정작 구조화되지 않은 기업 문서에서는 데이터 추출이 쉽지 않은 경우가 많습니다. 이 때문에 문서를 AI가 학습하기 좋은 형태로 가공하는 전처리 기술이 중요해지고 있습니다.

✅ 표·계층 구조 손실

병합 셀이나 다단 헤더가 있는 표, 제목과 본문의 위계가 검색 결과에서 제대로 구분되지 않는다면 추출 단계에서 구조가 손실되고 있을 가능성이 큽니다.

✅ 국내 문서 포맷 및 폐쇄망 환경

HWP·HWPX 비중이 높거나 외부 전송이 막힌 환경이라면, 범용 도큐먼트 로더만으로는 한계가 있어 별도 전처리 솔루션 검토가 필요합니다.

💻 한컴 데이터 로더

한컴 데이터 로더는 HWP·HWPX·PDF·OOXML을 구조화 데이터로 전환하는 문서 파싱 솔루션입니다. DLA·OCR·TSR을 기반으로 텍스트뿐 아니라 표·계층·좌표 같은 구조 정보까지 추출하며, 외부로 데이터를 전송하지 않는 온프레미스 환경도 지원합니다.

실제로 경기도교육청 AI 디지털플랫폼 구축 사업에서는 2,800여 개 학교 홈페이지와 4만여 건의 안내자료, 7,000여 건의 지침·법령 데이터를 한컴 데이터 로더로 AI가 학습 가능한 형태로 변환했고, 이 데이터를 기반으로 한컴피디아가 교직원에게 정확한 질의응답을 제공하고 있습니다.

RAG 구축에서 중요한 것은 단순히 모델 선택이 아니라, 자사 문서가 AI가 읽을 수 있는 데이터로 제대로 변환되는지 확인하는 것입니다.

에이전트가 신뢰할 수 있는 문서 전처리, 한컴 데이터 로더로 시작할 수 있습니다.

👉 한컴 데이터 로더 구경하기

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

참고 자료

arXiv, 「Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks」, 2020
IBM Think, 「What is RAG (Retrieval Augmented Generation)?」
AWS Prescriptive Guidance, 「Understanding Retrieval Augmented Generation」
Unstructured, 「Partitioning」
arXiv, 「Enhancing Retrieval Augmented Generation with Hierarchical Text Segmentation Chunking」, 2025
IBM Think, 「Llamaindex vs Langchain: What’s the difference?」
arXiv, 「Structure-Aware Chunking for Tabular Data in Retrieval-Augmented Generation」, 2026
arXiv, 「Revolutionizing Retrieval-Augmented Generation with Enhanced PDF Structure Recognition」, 2024
arXiv, 「Benchmarking LLM Faithfulness in RAG with Evolving Leaderboards」, 2025
AI타임스, 「한컴, 문서에서 AI 데이터 추출하는 ‘한컴 데이터 로더’ 출시」, 2024
CIO Korea, 「’문서에서 AI 데이터 추출’… 한글과컴퓨터, SDK 한컴 데이터 로더 글로벌 출시」, 2024
조선비즈, 「한컴, 경기도교육청 AI 디지털플랫폼 구축 사업 참여」