RAG는 왜 기대보다 자주 실망스러울까라는 질문은 실제 운영자들이 아주 자주 부딪히는 질문입니다. 검색을 붙이면 더 정확해질 것 같지만, 실제로는 틀리는 이유가 더 복잡해질 뿐인 경우도 많습니다.
이번 글에서는 검색 품질, chunking, retrieval mismatch, citation illusion, 평가 루프 부족 같은 지점에서 왜 RAG가 흔들리는지 운영 관점으로 정리하겠습니다.
복잡도를 너무 빨리 올리지 말라는 점은 Anthropic의 Building Effective AI Agents 글과도 맞닿습니다. retrieval과 예시만 잘 다듬어도 해결되는 문제를, RAG 전체 문제로 과장하면 오히려 디버깅이 더 어려워집니다.
검색을 붙였는데도 왜 틀릴까
많은 팀이 처음에는 “검색 결과만 붙이면 모델이 더 정확해지겠지”라고 생각합니다. 하지만 검색 결과가 부정확하거나, 너무 넓거나, 질문과 미묘하게 어긋나면 모델은 오히려 더 자신 있게 잘못된 답을 만들 수도 있습니다.
- 검색 결과 자체가 질문과 정확히 맞지 않을 수 있다
- 검색 결과는 맞는데 필요한 부분이 chunking 과정에서 잘릴 수 있다
- 검색은 잘 되었지만 모델이 그중 핵심을 제대로 쓰지 못할 수 있다
chunking은 생각보다 훨씬 중요하다
RAG에서 자주 과소평가되는 부분이 chunking입니다. 문서를 어떻게 자르느냐에 따라 모델이 보는 문맥 단위가 달라지고, 결국 답의 품질도 달라집니다.
너무 크게 자르면 잡음이 늘고, 너무 작게 자르면 필요한 맥락이 사라집니다. 그래서 RAG는 모델 선택보다 문서를 어떤 단위로 읽게 할 것인가가 더 중요한 순간이 많습니다.
retrieval mismatch는 왜 자주 생길까
retrieval mismatch는 검색 시스템이 “비슷해 보이는 것”을 가져왔지만, 사용자가 실제로 원한 근거와는 어긋나는 상황입니다. 표면 키워드는 맞아도, 질문의 의도와 문서의 관점이 다를 수 있습니다.
이 문제는 프롬프트 한 줄로 해결되기 어렵습니다. 인덱스 구조, 메타데이터, 질의 재작성, reranking 같은 단계가 같이 흔들리기 때문입니다.
진짜로 실망스러운 RAG 실패 케이스를 보자
예를 들어 사내 인사 규정 봇을 만든다고 가정해보겠습니다. 사용자가 “육아휴직 중 성과평가 기준이 어떻게 적용되나요?”라고 묻습니다. 문서 저장소에는 인사 규정 PDF, FAQ 문서, 오래된 공지, 팀별 운영 메모가 뒤섞여 있습니다.
- 검색기는 “성과평가”, “휴직”, “평가 제외” 키워드가 들어간 오래된 공지를 먼저 가져온다
- 정작 최신 규정 PDF의 핵심 문장은 chunking 과정에서 절반쯤 잘려 나온다
- 모델은 오래된 공지 문장과 잘린 최신 규정 일부를 이어붙여 그럴듯한 답을 만든다
- 출처 링크까지 붙으니 사용자는 더 믿게 된다
이 상황이 특히 위험한 이유는 답이 완전히 엉터리는 아니라는 점입니다. 일부는 맞고 일부는 틀리기 때문에, 데모에서는 잘 안 잡히고 운영에서 불신만 커집니다.
운영자는 보통 여기서 “모델이 멍청하다”고 느끼지만, 실제로는 문제 원인이 여러 층에 흩어져 있습니다.
- 검색 우선순위가 최신성보다 키워드 매칭을 더 강하게 봤을 수 있다
- chunk 크기가 규정 문단 구조와 맞지 않았을 수 있다
- 메타데이터가 약해서 최신 문서 가중치가 실리지 않았을 수 있다
- 최종 답을 검증하는 평가 루프가 없었을 수 있다
이런 실패는 “검색을 붙였는데도 왜 실망스럽지?”라는 체감을 가장 강하게 만듭니다. 그리고 이때 필요한 것은 프롬프트 문장 한 줄이 아니라, 검색과 문서 구조와 평가 체계를 다시 보는 일입니다.
citation illusion도 조심해야 한다
RAG가 붙으면 사람은 종종 “출처가 있으니 더 믿을 수 있다”고 느낍니다. 하지만 링크가 있다고 해서 답이 자동으로 맞는 것은 아닙니다. 모델이 검색된 문서를 정확히 근거로 쓴 것이 아니라, 비슷한 문장을 보고 자연스럽게 이어붙였을 수도 있습니다.
즉 출처가 있다는 사실보다, 그 출처가 실제 답의 핵심 주장과 정말 연결되는지를 봐야 합니다.
결국 평가 루프가 없으면 착시가 커진다
RAG 시스템이 실망스럽게 느껴지는 가장 큰 이유 중 하나는 평가 없이 좋아 보이는 데모만 먼저 보게 되기 때문입니다. 한두 개 질문에서는 좋아 보일 수 있지만, 실제 운영 입력을 넓게 넣어보면 실패 패턴이 금방 드러납니다.
이 점은 프롬프트 엔지니어링 글과도 이어집니다. 시스템 품질은 문장 하나보다 평가 체계에서 더 안정적으로 잡힙니다.
RAG를 덜 실망스럽게 쓰려면
- 검색 품질을 먼저 점검한다
- chunking 전략을 질문 유형에 맞춘다
- retrieval과 generation을 따로 평가한다
- 출처가 정말 근거 역할을 하는지 본다
- 데모가 아니라 실패 사례로 품질을 본다
Anthropic 글도 복잡도를 필요 이상으로 빨리 올리지 말라고 말합니다. 즉 RAG도 “붙이면 해결되는 기능”이 아니라, 검색과 생성의 결합 품질을 계속 다듬어야 하는 시스템입니다.
구조 차이 관점은 에이전트와 워크플로 자동화 차이 글과 함께 보면 더 입체적으로 볼 수 있습니다.
마무리
RAG는 검색을 붙였다고 해서 자동으로 정답률이 올라가는 구조가 아닙니다. 검색 품질, chunking, retrieval mismatch, citation illusion, 평가 루프 같은 요소가 함께 맞아야 기대한 품질이 나옵니다.
그래서 RAG가 자주 실망스러운 이유는 모델이 멍청해서라기보다, 검색과 생성 사이의 연결 고리가 생각보다 더 많고 섬세하기 때문입니다.
