RAG 구축 실무 가이드 – 사내 문서 검색 AI, 만드는 순서와 답이 틀릴 때 고치는 법

핵심 요약

• RAG(검색 증강 생성)는 답변 전에 관련 문서를 검색해 모델에 제공하는 구조입니다. 문서가 바뀌면 검색 인덱스와 캐시에도 변경 사항이 반영됐는지 확인해야 합니다.
• RAG 품질 문제는 필요한 문서를 못 찾는 "검색 실패"와 찾았는데 틀리게 답하는 "생성 실패"로 나눠 진단해야 하며, 두 문제의 해결책은 다릅니다.
• 한국 기업 문서에 흔한 HWP 파일과 스캔 문서는 별도의 텍스트 추출이나 OCR이 필요하므로 파일럿 초기에 추출 품질을 확인해야 합니다.
• 공개 사례 연구에서 싱가포르 프롭테크 스타트업의 RAG 매물 검색은 14주 프로젝트로, 매물 탐색 시간 65% 단축, 사용자 참여 40% 증가, 매물 정보 할루시네이션 0건을 기록했습니다.
• 문서가 수정·삭제되면 해당 문서만 다시 색인하고 폐기 문서를 인덱스에서 지우는 갱신 절차가 없으면, RAG는 시간이 지날수록 오래된 내용을 근거로 답하게 됩니다.

RAG 구축 순서 – 문서에서 답변까지 6단계

1. 문서 수집과 정리. PDF, Word, 엑셀, 사내 위키, HWP 파일에서 텍스트를 추출하고 구버전과 중복 문서를 걸러 냅니다. 스캔 문서에는 OCR(이미지 속 글자를 텍스트로 바꾸는 기술)이 필요합니다.
2. 청킹(Chunking). 문서를 검색하기 좋은 크기의 조각으로 나누는 작업입니다. 조항 번호, 표, 제목 구조를 살려 나눠야 "제3조 2항"처럼 구체적인 질문에 맞는 조각이 검색됩니다.
3. 임베딩과 벡터 저장소. 임베딩은 문장의 의미를 숫자 벡터로 바꾸는 과정이고, 벡터 저장소는 이 벡터를 저장해 의미가 비슷한 조각을 빠르게 찾게 해 주는 데이터베이스입니다. 문서 종류, 작성 부서, 열람 권한 같은 메타데이터도 함께 저장합니다.
4. 검색 설계. 의미 기반 벡터 검색에 키워드 검색을 섞는 하이브리드 검색과, 검색 결과를 다시 정렬하는 재순위화(re-ranking)를 조합합니다. 한국어는 조사와 띄어쓰기 변형이 많아 키워드 검색 보완이 도움이 되는 경우가 많습니다.
5. 답변 생성 규칙. 검색된 내용만 근거로 답하고, 근거가 없으면 "문서에서 찾을 수 없다"고 답하도록 지시합니다.
6. 평가 세트로 측정. 현업이 실제로 묻는 질문 50–100개와 정답 문서를 짝지어 두고, 설정을 바꿀 때마다 같은 세트로 정답률과 출처 정확도를 비교합니다.

답이 틀릴 때 – 증상별 원인과 대응

이 구분 없이 모델만 더 비싼 것으로 바꾸면 비용은 늘고 품질은 그대로인 경우가 생깁니다. 개선 작업은 한 번에 한 가지 설정만 바꾸고 평가 세트로 다시 측정하는 방식으로 진행해야 효과를 확인할 수 있습니다. 진단을 쉽게 하려면 질문마다 검색된 문서 조각과 최종 답변을 함께 로그로 남겨 두십시오. 검색 결과에 정답 문서가 있었는지만 확인해도 문제의 절반은 원인이 드러납니다.

권한과 개인정보는 설계 단계에서

운영 단계에서 자주 놓치는 것은 문서 갱신 파이프라인입니다. 문서가 수정되면 바뀐 문서만 다시 청킹·임베딩하고, 삭제되거나 폐기된 문서는 인덱스에서도 지워야 합니다. 이 작업을 자동화하지 않으면 몇 달 뒤 챗봇이 폐기된 규정을 근거로 답하게 됩니다.

인사 문서처럼 일부 직원만 볼 수 있는 문서가 검색 결과에 섞이지 않도록 기존 권한 체계를 검색 필터에 반영해야 합니다. 문서 내용이 외부 LLM API로 전송되는지, 어느 지역 클라우드에 저장되는지도 구축 범위에서 합의할 사항입니다. 개인정보가 담긴 문서를 다룬다면 개인정보 보호법과, 개인정보보호위원회가 2025년 8월 공개한 생성형 AI 개발·활용을 위한 개인정보 처리 안내서를 확인하십시오(2026년 10월 기준). 이 부분은 일반적인 정보이며 법률 자문이 아닙니다.

공개 사례와 시작 규모

베트남 하노이의 AI 엔지니어링 기업 NKKTech Global이 공개한 사례 연구 중 싱가포르 프롭테크 스타트업의 RAG 매물 검색은 14주 동안 구축되었고, 매물 탐색 시간 65% 단축, 사용자 참여 40% 증가, 매물 정보 할루시네이션(근거 없는 내용을 사실처럼 만들어 내는 현상) 0건이라는 결과가 공개되어 있습니다. 한국 고객 사례는 아니지만, "근거 없는 답변 0건"처럼 할루시네이션을 측정 가능한 목표로 두는 방식은 사내 문서 검색에도 그대로 적용할 수 있습니다.

처음부터 전사 문서를 다루기보다 부서 하나의 문서 묶음으로 시작하는 편이 안전합니다. 문서 수가 적어야 평가 세트의 정답을 현업이 직접 확인할 수 있고, 검색 설정을 바꿨을 때의 효과도 빠르게 비교할 수 있습니다. RAG와 파인튜닝 중 무엇을 쓸지는 LLM 파인튜닝 vs RAG에서, 한국어 모델 선택은 한국어 LLM 선택 가이드에서 다룹니다. 구축 방식은 RAG 개발 서비스에 정리되어 있습니다.

자주 묻는 질문

RAG 구축에는 기간이 얼마나 걸리나요? 문서 묶음 하나를 대상으로 한 파일럿은 3–4주 안에 검증할 수 있는 경우가 많습니다. 여러 부서의 문서, 권한 연동, 운영 모니터링까지 포함하는 본 구축은 범위에 따라 더 길어지며, 공개 사례 연구의 싱가포르 프롭테크 RAG 검색은 14주가 걸렸습니다.

한글(HWP) 문서나 스캔 문서도 RAG에 쓸 수 있나요? 쓸 수 있습니다. HWP는 별도의 텍스트 추출 처리가, 스캔 문서는 OCR이 필요하고 표나 서식이 복잡하면 정리 작업이 늘어납니다. 대표 문서 몇 개로 추출 품질을 먼저 확인하는 것이 좋습니다.

RAG 챗봇이 엉뚱한 답을 하면 어떻게 고치나요? 먼저 올바른 문서를 찾지 못한 검색 문제인지, 찾았는데 잘못 답한 생성 문제인지 구분합니다. 검색 문제는 청킹과 검색 방식을, 생성 문제는 지시문과 전달하는 문서 양을 조정해 해결하며, 같은 평가 세트로 개선 여부를 확인합니다.