RAG와 파인튜닝 차이부터 전처리 도구 선택까지 | 사내 문서 AI, 무엇부터 정해야 할까

AI 전환(AX)를 위해 사내 문서 기반 AI를 구축할 때 가장 먼저 결정해야 하는 것은 모델을 학습시킬지, 필요한 문서를 검색해 활용할지입니다.

이 선택지에서 RAG와 파인튜닝 비교가 시작됩니다. RAG(Retrieval-Augmented Generation, 검색 증강 생성)는 모델 바깥의 문서를 검색해 답변 근거로 삼는 방식이고, 파인튜닝은 모델 자체를 추가 학습시켜 특정 지식이나 답변 방식을 반영하는 방식입니다.

이번 글에서는 RAG와 파인튜닝의 차이를 비교하고, 사내 문서 AI를 구축할 때 무엇부터 정해야 하는지, RAG를 선택했다면 전처리 도구를 어떤 기준으로 봐야 하는지까지 정리했습니다.

LLM만으로는 왜 사내 문서 질문에 정확히 답하지 못할까

LLM이 학습 데이터로 반영한 지식의 기준 시점을 지식 컷오프(knowledge cutoff)라고 부릅니다. 학습 데이터에 없는 사내 문서를 물으면 모델은 “모른다.”고 답하기보다 그럴듯한 내용을 지어내는 경향이 있는데, 이렇게 사실과 다른 답을 사실처럼 만들어내는 현상이 할루시네이션입니다.

그래서 사내 문서 기반 AI를 만들 때는 “우리 지식을 모델에 어떻게 연결할 것인가.”라는 질문이 생깁니다.

그 답은 크게 두 갈래로 나뉩니다. 하나는 모델 자체를 우리 데이터로 다시 학습시키는 파인튜닝이고, 다른 하나는 모델 자체를 다시 학습시키지 않고 필요한 문서를 검색해 그 내용을 근거로 답변을 생성하는 RAG입니다. 두 방식이 구체적으로 어떻게 다른지 이 글에서 간단하게 비교해 보겠습니다.

RAG와 파인튜닝의 차이 비교

RAG와 파인튜닝은 LLM을 특정 업무에 맞게 조정하는 두 가지 방법입니다. Google Cloud의 파인튜닝 설명에 따르면, 파인튜닝은 사전 학습된 LLM을 작업별 데이터 세트로 추가 학습시켜 모델의 파라미터를 조정하는 방식입니다. 반면 RAG는 모델을 다시 학습시키기보다, 질문이 들어올 때 모델 외부의 문서 저장소에서 관련 내용을 찾아 프롬프트에 함께 넣어 활용하는 방식입니다.

쉽게 말해 RAG는 모델 옆에 ‘사내 문서 도서관’을 두고 필요할 때마다 찾아보게 하는 방식이고, 파인튜닝은 모델이 특정 업무 지식이나 답변 방식을 더 잘 따르도록 추가로 훈련하는 방식에 가깝습니다.

RAG와 파인튜닝의 작동 방식 비교

RAG는 모델 자체를 다시 학습시키기보다, 질문이 들어올 때 외부 문서 저장소에서 관련 내용을 찾아 프롬프트에 함께 넣는 방식입니다. 

반면 파인튜닝은 작업별 데이터로 모델을 추가 학습시켜, 특정 도메인의 지식이나 답변 방식을 모델에 반영하는 방식입니다. 두 방식은 무엇을 바꾸는지부터 다릅니다. 

Microsoft 연구진의 비교 연구에서는 RAG를 외부 데이터로 프롬프트를 보강하는 방식으로, 파인튜닝을 추가 지식을 모델 자체에 통합하는 방식으로 설명합니다. 같은 지식 보강이라도 RAG는 관련 문서를 검색해 답변 맥락으로 제공하고, 파인튜닝은 작업별 데이터로 모델을 추가 학습시킨다는 점에서 차이가 있습니다. 

RAG와 파인튜닝의 작동 방식 비교

비교 기준	RAG	파인튜닝
지식을 활용하는 방식	필요한 정보를 모델 외부의 문서에서 찾아 답변에 함께 활용합니다.	작업별 데이터로 모델을 추가 학습해 특정 업무에 맞게 조정합니다.
모델 변경 방식	모델 자체를 크게 바꾸지 않고 검색 결과를 답변 맥락으로 제공합니다.	모델의 가중치 또는 일부 파라미터를 조정할 수 있습니다.
새 문서 반영 방식	새 문서를 검색 대상에 반영해 최신 정보를 활용할 수 있습니다.	새 정보를 모델에 반영하려면 추가 학습이나 재학습을 검토해야 합니다.
답변 근거 확인	검색된 문서를 함께 제시하면 답변 근거를 확인하기 쉽습니다.	모델 내부에서 생성된 답변이라 문서 단위의 근거 추적은 상대적으로 어렵습니다.
적합한 상황	문서가 자주 바뀌거나 답변 출처 확인이 중요한 업무에 적합합니다.	전문 용어, 답변 형식 일치, 분류 기준을 맞춰야 할 때 적합합니다.

RAG와 파인튜닝은 어느 한쪽이 무조건 더 낫다고 보기 어렵습니다. Microsoft의 비교 연구에서도 특정 농업 데이터 세트를 대상으로 파인튜닝과 RAG를 함께 적용했을 때 정확도가 추가로 개선된 사례가 확인됐습니다. 즉 두 방식은 경쟁 관계라기보다, 목적에 따라 따로 쓰거나 함께 조합할 수 있는 보완 관계에 가깝습니다. 최신 문서를 빠르게 반영하고 답변 출처를 확인해야 한다면 RAG를, 특정 업무의 표현 방식이나 응답 형식을 조정해야 한다면 파인튜닝을 우선 검토할 수 있습니다. 

도메인 특화 모델 구축 사례: 블룸버그GPT(Bloomberg GPT)

파인튜닝은 특정 업무의 표현 방식이나 응답 형식을 모델에 맞추는 데 유용한 방법입니다. 다만 모델 자체에 특정 도메인의 지식을 더 넓고 깊게 반영하려는 방향으로 갈수록, 데이터 준비와 학습 인프라 부담도 함께 커집니다. 블룸버그GPT가 대표적인 사례입니다.

블룸버그GPT 논문에 따르면 블룸버그GPT는 금융 데이터와 범용 데이터를 함께 활용해 처음부터 학습한 500억 파라미터 규모의 금융 특화 LLM입니다. 일반적인 파인튜닝 사례라기보다, 모델 자체를 금융 도메인에 맞춰 설계하고 학습한 대규모 사전학습(Pre-training) 사례에 가깝습니다.

이처럼 도메인 특화 모델은 높은 전문성을 기대할 수 있지만, 그만큼 학습 자원도 크게 필요합니다. HPCwire 분석에서는 블룸버그GPT 학습에 약 130만 GPU 시간이 투입됐고, AWS 기준 약 300만 달러 규모의 비용이 들었을 것으로 추정했습니다.

따라서 파인튜닝이나 자체 모델 구축은 목적과 예산이 분명할 때 강력한 선택지가 될 수 있습니다. 다만 대부분의 공공기관과 기업이 사내 문서 기반 AI를 처음 구축하는 단계라면, 모델 자체를 새로 학습하기보다 외부 문서를 검색해 답변에 활용하는 RAG를 현실적인 출발점으로 검토하는 경우가 많습니다.

RAG 선택 기준, 어떤 환경에서 RAG가 맞을까

문서가 자주 바뀌거나, 답변 근거를 확인해야 하거나, 사내 문서를 외부로 보내기 어려운 환경이라면 RAG를 우선 검토할 수 있습니다. 사내 문서 기반 AI에서는 이런 조건이 자주 나타나기 때문에, RAG가 현실적인 출발점이 되는 경우가 많습니다.

RAG 구축 시 고려하면 좋을 기준

사내 문서가 자주 바뀌거나, 답변의 근거를 확인해야 하거나, 문서를 외부로 보내기 어려운 환경이라면 RAG를 우선 검토할 수 있습니다. RAG는 모델 자체를 다시 학습시키는 방식이 아니라, 필요한 문서를 검색해 답변 맥락으로 활용하는 방식이기 때문입니다.

예를 들어 정책 문서, 업무 매뉴얼, 공문, 법무·금융 자료처럼 내용이 계속 추가되거나 변경되는 문서라면 매번 모델을 다시 학습시키는 방식은 운영 부담이 커질 수 있습니다. 반면 RAG는 새 문서를 파싱·청킹·임베딩해 검색 대상에 반영하는 방식으로 최신 문서를 활용할 수 있습니다.

또 공공·금융·법무처럼 답변 출처를 확인해야 하는 업무에서도 RAG가 유리합니다. 검색된 원본 문서를 함께 제시하면 답변이 어떤 문서를 근거로 생성됐는지 확인하기 쉽기 때문입니다. 여기에 보안상 문서를 외부 클라우드로 전송하기 어려운 환경이라면, 내부망에 문서 저장소와 검색 파이프라인을 두는 온프레미스 방식의 RAG 구성을 함께 검토할 수 있습니다.

정리하면, 문서가 자주 바뀌고 출처 확인이 중요한 사내 문서 기반 AI라면 RAG가 현실적인 출발점이 될 수 있습니다. 반대로 특정 업무의 말투, 응답 형식, 분류 기준처럼 모델의 답변 방식 자체를 조정해야 한다면 파인튜닝을 함께 검토하는 것이 좋습니다.

*참고 콘텐츠: elastic, 「RAG vs. Fine Tuning, a practical approach」, 2025

RAG 전처리 품질의 중요성

RAG의 답변 품질은 LLM 성능만으로 결정되지 않습니다. 문서를 얼마나 정확하게 읽고, 구조를 얼마나 잘 보존해 검색 가능한 데이터로 바꾸는지가 함께 중요합니다. 아무리 좋은 모델을 쓰더라도 문서가 잘못 추출되면 AI는 잘못된 근거를 바탕으로 답변할 수 있기 때문입니다. 

문제는 데이터 추출 단계에서 자주 발생합니다. 예를 들어 표 제목과 데이터의 연결이 끊긴 채 추출되면, AI는 같은 숫자를 읽더라도 그 숫자가 어떤 항목의 값인지 구분하기 어렵습니다. 표의 행과 열, 제목과 본문, 캡션과 이미지의 관계가 무너지면 검색된 문서 조각 자체가 불완전해질 수 있습니다. 

그래서 RAG의 출발점은 “어떤 LLM을 쓸까.”만이 아니라 “문서를 어떻게 정확히 파싱할까.”까지 함께 보는 데 있습니다. ChatDOC 연구진은 PDF 파싱 정확도가 낮으면 전문 지식 기반 질의응답 품질에 영향을 줄 수 있다고 지적했습니다. 실제 비교 실험에서도 문서 구조를 더 잘 인식한 파서가 더 정확하고 완전한 검색 결과를 제공해, RAG 답변 품질 개선으로 이어질 수 있음을 보였습니다. 

📚 함께 읽으면 좋은 글
RAG 성능은 AI가 아닌 ‘문서 전처리’에서 결정됩니다 | 한컴 데이터 로더

RAG 전처리 도구를 선택할 때 확인해야 할 기준

RAG 전처리 도구, 곧 문서를 AI가 읽을 데이터로 바꾸는 LLM 전처리 도구는 원본을 직접 파싱하는지, 표 구조와 문서 구조를 인식하는지, 문서 계층을 살려 추출하는지, 온프레미스로 배포할 수 있는지를 기준으로 선택해야 합니다.

원본 직접 파싱 지원 여부

전처리 도구를 고를 때는 문서를 PDF로 변환하지 않고 원본을 직접 파싱하는지부터 확인해야 합니다. 변환 과정에서 정보가 손실되기 때문입니다.

‘지원’이라고 표기되어 있어도 내부적으로 PDF로 변환한 뒤 처리하는 도구가 있는데, 이때 표 구조나 제목 계층이 깨지는 HWP 파싱 오류가 생기기 쉽습니다. 특히 HWP·HWPX는 국내 공공기관 문서에서 비중이 높아, 변환 없이 원본을 직접 파싱하는지 확인이 중요합니다. 

표 구조 인식(TSR)과 문서 구조 분석(DLA)

RAG 전처리 도구를 볼 때는 TSR(Table Structure Recognition, 표 구조 인식)과 DLA(Document Layout Analysis, 문서 구조 분석)를 함께 확인해야 합니다. 사내 문서에는 병합 셀, 다단 헤더, 주석, 이미지가 섞인 표가 많은데, 이를 단순 텍스트로만 추출하면 행과 열의 관계가 끊어지기 쉽습니다.

예를 들어 표 안의 숫자만 추출되고, 그 숫자가 어떤 항목과 기간을 의미하는지 연결되지 않으면 AI는 같은 데이터를 보고도 잘못된 답을 만들 수 있습니다. 이때 필요한 기술이 TSR입니다. TSR은 셀 간 관계를 파악해 행·열 구조를 보존하고, 병합 셀이나 복잡한 표도 AI가 이해하기 쉬운 형태로 변환하는 역할을 합니다.

표만 정확히 읽는다고 충분한 것도 아닙니다. 문서 안에서 제목, 본문, 표, 이미지, 캡션이 어떤 순서와 관계로 배치되어 있는지 함께 파악해야 합니다. DLA는 이런 문서 구성 요소를 구분하고 읽기 순서를 복원해, 이후 청킹 단계에서 의미 단위가 끊기지 않도록 돕습니다.

청킹 품질과 문서 계층 반영

문서의 계층 구조를 반영해 청킹하는지가 검색 정확도를 좌우하므로, 전처리 단계에서 제목과 본문의 계층 정보를 살려 추출하는지 확인해야 합니다.

긴 문서를 검색에 쓰려면 적당한 크기로 나누는 청킹 과정을 거칩니다. 이때 글자 수로 기계적으로 자르는 대신 제목·소제목·본문의 계층과 의미를 반영해 자르는 문서 청킹(Chunking) 전략, 곧 시맨틱 청킹(Semantic Chunking)을 쓰면 의미가 한 덩어리로 묶여 검색 정확도가 올라갑니다. Microsoft Azure의 RAG 청킹 가이드도 문서 구조가 청킹 방식에 영향을 준다고 설명합니다. 

청킹 자체는 전처리 도구가 아니라 RAG 솔루션 단계의 작업이지만, 전처리 도구가 계층 정보를 정확히 추출해 둘수록 이후 의미 단위 청킹이 그 정보를 기준으로 더 잘 작동합니다. 전처리 단계에서 계층을 얼마나 살려 추출하는지가 청킹 품질의 출발점인 셈입니다.

배포 방식과 보안 환경

RAG 전처리 도구를 선택할 때는 온프레미스 배포와 SaaS API 연동을 모두 확인하는 것이 좋습니다. 클라우드로 문서를 보내기 어려운 금융망, 폐쇄망, 공공기관 환경이라면 내부망에 직접 설치해 운용할 수 있는 온프레미스 방식이 적합합니다. 문서가 외부로 전송되지 않는 구조로 운영할 수 있어 보안 요구 수준이 높은 환경에서 검토하기 좋습니다.

반대로 빠른 테스트나 파일럿 도입이 필요하다면 SaaS API 방식도 선택할 수 있습니다. SaaS API 방식은 별도 서버 구축 없이 연동할 수 있고, 페이지 단위 과금 구조로 사용한 만큼 비용이 발생하기 때문에 초기 투자 부담을 줄일 수 있습니다. 온프레미스 구축 전 실제 문서로 파싱 품질을 확인하는 용도로도 활용할 수 있습니다.

👉 내 문서로 파싱 결과 바로 확인하기 (라이브 데모)

RAG 전처리 도구 도입 환경: 공공·금융·사내 문서

HWP·HWPX 비중이 높거나, 폐쇄망·금융망처럼 문서를 외부로 전송하기 어려운 환경이라면 RAG 전처리 도구 선택이 더 중요해집니다. 특히 표, 이미지, 계층 구조가 많은 문서는 단순 텍스트 추출만으로는 의미 관계가 끊길 수 있어, 원본 문서를 직접 파싱하고 구조를 보존할 수 있는지가 핵심입니다. 

공공기관·금융·법무 문서 기반 RAG

공공기관·금융·법무 영역에서는 문서 보안과 답변 출처 확인이 중요합니다. 이런 환경에서는 외부 클라우드에 문서를 올리는 방식보다, 내부망에서 문서를 처리할 수 있는 온프레미스 기반 RAG 구성을 우선 검토하는 경우가 많습니다.

또 공공 문서 환경에서는 HWP·HWPX와 PDF가 함께 쓰이는 경우가 많습니다. HWPX는 XML 기반 개방형 포맷이라 구조화 데이터로 활용하기에 유리하지만, 기존 HWP 문서와 PDF까지 함께 처리해야 하는 현장에서는 여러 포맷을 안정적으로 파싱할 수 있는 전처리 도구가 필요합니다.

사내 지식검색·업무 챗봇 구축

사내 매뉴얼, 보고서, 지침서에는 표와 계층 구조가 많이 포함되어 있습니다. 이때 제목과 본문, 표 제목과 데이터, 이미지와 캡션의 관계가 끊긴 채 추출되면 챗봇 답변의 정확도도 떨어질 수 있습니다.

사내 AI 도입의 시작, 한컴 데이터 로더

🖥️한컴 데이터 로더

사내 문서는 HWP·HWPX와 PDF가 섞여 있는 경우가 많아, 이를 단일 솔루션으로 처리할 수 있는지가 운영 효율을 좌우합니다. 공공·교육 영역에는 이미 적용 사례가 보도된 바 있습니다. 경기도교육청 AI 디지털 플랫폼 구축 사업에서는 LG CNS 주관 컨소시엄에 한컴이 참여해, 학교 홈페이지와 안내자료, 지침·법령 데이터를 HWP·HWPX·PDF의 계층·좌표·복잡한 표까지 살려 구조화하는 전처리를 맡았습니다.

사내 문서 AI는 파인튜닝과 RAG 중 무엇을 택할지에서 시작하되, 문서가 자주 바뀌고 출처 확인이 중요한 환경에서는 RAG가 현실적인 출발점이 될 수 있습니다. RAG를 택했다면 답변 품질은 전처리 품질에 크게 좌우되므로, 전처리 도구를 어떤 기준으로 고르는지가 결국 핵심이 됩니다.

사내 문서 AI 도입을 검토하고 있다면, 먼저 한컴 데이터 로더 라이브 데모에서 실제 문서를 업로드해 파싱 결과를 확인해보세요. 

👉 내 문서로 파싱 결과 바로 확인하기 (라이브 데모)
👉 우리 환경에 맞는 도입 상담받기

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

---

참고 자료

1. Google Cloud, 「LLM 및 AI 모델 파인 튜닝」
2. Arxiv, 「RAG vs Fine-tuning: Pipelines, Tradeoffs, and a Case Study on Agriculture」, 2024
3. Arxiv, 「BloombergGPT: A Large Language Model for Finance」, 2023
4. HPCwire, 「Bloomberg Uses 1.3 Million Hours of GPU Time for Homegrown Large Language Model」, 2023
5. Arxiv, 「Revolutionizing Retrieval-Augmented Generation with Enhanced PDF Structure Recognition」, 2024
6. Elasticsearch Labs, 「RAG vs. Fine Tuning, a practical approach」, Elasticsearch Labs, 2025
7. Microsoft Learn, 「RAG 솔루션 개발 – 청크화 단계」