RAG 성능 안 나오는 7가지 진짜 이유에 대한 고찰

본 이미지는 AI로 생성한 이미지입니다.

RAG 성능이 안 나오는 진짜 이유: LLM문제가 아닌 검색의 병목현상

최근 인공지능(AI) 솔루션을 개발하거나 사내 AI 전환(AX)을 추진하는 수많은 기업에서 가장 활발하게 도입하는 기술이 바로 RAG(Retrieval-Augmented Generation, 검색 증강 생성)입니다. RAG는 대형 언어 모델(LLM)의 대표적인 한계인 환각(Hallucination) 현상을 방지하고, 사내 보안 문서나 최신 데이터를 정확하게 참조하여 답변하도록 만드는 필수 아키텍처로 평가받고 있습니다.

하지만 막상 현업에 RAG 시스템을 구축해 보면 기대했던 수준에 턱없이 미치지 못하는 정답률 때문에 실망하는 개발자와 기업 IT 리더들이 적지 않습니다. "최신 GPT-4o나 Claude 3.5 Sonnet 같은 프론티어 LLM을 썼는데 왜 자꾸 엉뚱한 소리를 할까?", "모델을 더 큰 것으로 바꿔야 하나?"라며 고뇌에 빠지곤 합니다.

실제로 해외 레디트(Reddit) 등 글로벌 개발자 커뮤니티에서도 이와 관련된 열띤 토론이 이어지고 있습니다. 커뮤니티의 현직 AI 엔지니어들이 입을 모아 말하는 결론은 명확합니다. "RAG 성능 저하의 원인은 90% 이상 LLM 모델이 아니라, 앞단의 검색(Retrieval) 파이프라인에 있다"는 사실입니다.

아무리 똑똑한 AI 모델이라도 제대로 된 자료를 찾아 전달해 주지 않으면 정답을 내놓을 수 없습니다. 오늘 포스팅에서는 RAG 성능이 제대로 나오지 않는 진짜 이유 7가지와 함께, 이를 극복하고 답변 정확도를 획기적으로 끌어올릴 수 있는 실전 RAG 최적화 가이드를 알기 쉽게 정리해 드립니다.

1. 데이터 청킹(Chunking)과 원천 데이터 품질의 비극

RAG 파이프라인의 첫 단계는 문서를 적절한 크기로 잘라(Chunking) 벡터 데이터베이스에 저장하는 것입니다. 하지만 많은 구축 사례에서 이 첫 단추부터 잘못 꿰어지고 있습니다.

• 원인 1: 엉터리 청킹(Chunking) 전략 문서를 단순히 500자, 1,000자 단위로 기계적으로 쪼개는 '고정 길이 청킹'을 사용할 경우, 문맥의 끊김 현상이 발생합니다. 하나의 의미 있는 문장이나 표, 단락이 중간에서 싹뚝 잘려 나가면서 의미가 왜곡되거나 중요한 맥락이 손실됩니다. 반대로 청크 크기가 너무 크면 불필요한 노이즈 데이터가 대량 포함되어 검색 정밀도가 급격히 떨어집니다.

• 원인 2: 정제되지 않은 원천 데이터(Garbage In, Garbage Out) RAG에 투입되는 사내 문서(PDF, Word, HWP 등)의 정제 상태가 엉망인 경우가 태반입니다. 머리말, 꼬리말, OCR 오인식 문치, 깨진 표(Table) 서식 등이 그대로 벡터 DB에 들어가면, 검색 엔진은 이 노이즈를 중요한 정보로 착각하게 됩니다. 아무리 뛰어난 AI라도 불량 원재료를 받으면 불량 결과를 만들어낼 수밖에 없습니다.

2. 검색(Retrieval)의 한계: 단일 임베딩, 키워드 누락, 리랭킹 부재

레디트 개발자들이 가장 강조하는 RAG 성능의 핵심 병목 구간은 바로 문서 검색(Retrieval) 단계입니다.

• 원인 3: 단일 벡터(Dense Embedding) 검색에 대한 과도한 의존 대다수 초기 RAG 구축팀은 텍스트를 숫자로 바꾸는 벡터 임베딩 모델 하나만 믿고 의미론적(Semantic) 검색을 수행합니다. 하지만 벡터 검색은 '제품 품번', '특정 법률 조항 번호', '사람 이름', '전문 용어' 같은 정확한 고유명사 키워드를 잘 찾지 못합니다.

• 원인 4: 하이브리드 검색(Hybrid Search)의 부재 문맥의 의미를 파악하는 벡터 검색(Dense Retrieval)과 정확한 단어 매칭에 강한 키워드 검색(Sparse Retrieval, 예: BM25)을 결합한 '하이브리드 검색'을 적용하지 않으면, 사용자가 구체적인 단어를 물어보았을 때 검색 누락(Miss)이 대거 발생합니다.

• 원인 5: 리랭킹(Re-ranking) 과정의 생략 벡터 DB가 1차로 찾아낸 상위 10개(Top-K) 문서가 실제 질문과 얼마나 깊게 연관되어 있는지 재평가하는 '리랭커(Re-ranker)' 모델을 거치지 않는 문제입니다. 1차 검색 결과는 단순 유사도 순일 뿐, 질문의 의도에 부합하는 순서가 아니기 때문에 최상위에 무관한 문서가 들어갈 위험이 높습니다.

3. 컨텍스트 오염과 정밀한 성능 평가 시스템의 결여

검색된 문서를 LLM에 전달하고 결과를 확인하는 최종 단계에서도 심각한 오류가 발생합니다.

• 원인 6: 컨텍스트 오염 및 'Lost in the Middle' 현상 검색된 문서의 양이 너무 많으면 LLM에 전달되는 컨텍스트(Context) 창이 오염됩니다. 최근 LLM들은 긴 문맥을 지원하지만, 수천 자에 달하는 참조 문서의 '중간에 위치한 핵심 정보'를 제대로 인지하지 못하고 놓쳐버리는 'Lost in the Middle' 현상이 일어납니다. 즉, 불필요한 참고 자료를 너무 많이 주면 오히려 AI가 혼란에 빠져 오답을 내놓게 됩니다.

• 원인 7: 체계적인 RAG 평가(Evaluation) 프레임워크의 부재 대다수 프로젝트가 "몇 가지 질문을 던져보고 답변이 그럴듯하면 성공"이라는 주관적인 느낌으로 평가합니다. 검색 적합도(Retrieval Recall/Precision)와 생성 적합도(Generation Faithfulness)를 객관적 수치로 측정해 주는 평가 프레임워크(RAGAS, TruLens 등)를 도입하지 않으면, 시스템의 어디가 병목인지 파악조차 불가능합니다.

4. RAG 성능을 확실히 올리기 위한 실전 최적화 솔루션

그렇다면 성공적인 RAG 시스템을 완성하기 위해 개발자와 기업은 어떤 개선 조치를 취해야 할까요?

1. 상맥 인식 청킹(Semantic/Parent-Document Chunking) 도입: 단순 길이가 아닌 문단, 헤딩, 문맥 단위로 문서를 자르고, 소형 청크로 검색한 뒤 상위 부모 문서 전체를 LLM에 넘기는 파이프라인 구축

2. 하이브리드 검색 + Cross-Encoder 리랭커 결합: BM25 키워드 검색과 벡터 검색을 5:5 비율로 융합하고, BGE-Reranker 같은 전문 리랭킹 모델을 추가하여 상위 Top-3 문서의 정밀도 극대화

3. 전처리(Pre-processing) 데이터 파이프라인 강화: Unstructured, LlamaParse 등의 도구를 활용해 PDF 내부의 표와 이미지 서식을 깨끗하게 텍스트 및 마크다운으로 변환

4. 정기적인 RAGAS 평가 자동화: 검색 파이프라인과 생성 파이프라인의 성능 점수를 지표화하여 모니터링 체계 구축

모델 교체보다 검색 파이프라인 정비가 먼저다

RAG 시스템의 답변 정밀도가 떨어져 고민 중이시라면, 더 비싼 최신 LLM으로 모델을 바꿀 생각을 하기 전에 '우리가 LLM에게 넘겨주는 참조 문서(Retrieval Context)가 과연 깨끗하고 정확한가?'를 먼저 점검해야 합니다.

레디트의 수많은 실무 개발자들이 입증했듯이, RAG의 핵심 성패는 90% 이상 앞단의 데이터 데이터 정제, 하이브리드 검색, 리랭킹이라는 검색 파이프라인의 고도화에 달려 있습니다.

오늘 살펴본 7가지 원인을 하나씩 체크해 보시고, 하이브리드 검색과 정밀 청킹 전략을 적용해 보세요. 엉뚱한 답변만 내놓던 AI가 사내 최고 전문가 수준의 완벽하고 정밀한 정답을 내놓는 놀라운 변화를 경험하실 수 있을 것입니다.