요즘 AI 실무에서 자주 듣는 말이 있다.
“RAG is dead.”
처음 들으면 RAG가 완전히 끝난 기술처럼 느껴진다. 그런데 실제로 현장에서 겪는 문제를 보면, 죽은 건 RAG 자체가 아니라 문서를 대충 잘라서 벡터 검색만 믿는 단순 운영 방식이다.
AI 활용 고지: 이 글은 생성형 AI를 활용해 구조화한 뒤, 사람 검토를 거쳐 작성했습니다.
Flux/Essay/images/essay-15-rag-evolution-cover.png
flowchart LR A[문서 단순 청킹] --> B[맥락 손실] B --> C[검색은 맞는데 답이 틀림] D[맥락 보강 + 하이브리드 검색] --> E[관련 문서 정확도 상승] E --> F[답변 신뢰도 개선]
왜 “RAG는 끝났다”는 말이 나왔을까
RAG를 처음 붙인 팀이 가장 자주 겪는 장면은 비슷하다.
- 문서에는 분명히 있는 내용인데 AI가 못 찾는다.
- 찾긴 찾는데 엉뚱한 문장으로 답한다.
- 그럴듯하게 말해서 더 위험하다.
문제의 출발점은 보통 “문서 분할”이다.
문서를 몇백 토큰씩 잘라 저장하는 순간, 원래 문맥이 끊긴다. 한 조각만 보면 맞는 문장인데, 앞뒤가 사라져서 의미가 달라지는 일이 벌어진다.
쉽게 말해 책 한 페이지를 찢어서 건네고 “이걸로 전체 문맥을 이해해”라고 하는 것과 비슷하다.
단순 RAG가 실무에서 흔들리는 이유
첫째, 의미 검색만으로는 부족하다.
유사 의미를 잘 찾는 건 맞지만, 고유명사·정확한 숫자·버전명 같은 건 키워드 검색이 더 잘 잡는다.
둘째, 검색 결과 정제 단계가 없다.
상위 몇 개를 그냥 모델에 던지면, 관련도 낮은 문서가 섞여 답변 품질이 흔들린다.
셋째, 비용과 운영 복잡도의 균형이 깨진다.
그래프 기반 고급 구조는 성능은 좋지만, 업데이트와 유지보수 비용이 높다. 중소 규모 팀엔 과할 수 있다.
그러면 현실적인 대안은?
1) 하이브리드 검색 + 재랭킹
- 의미 검색(벡터) + 키워드 검색(BM25류)을 같이 쓴다.
- 결과를 한 번 더 걸러 “진짜 관련” 문서만 남긴다.
2) 컨텍스트 붙인 청킹
문서 조각 앞에 “이 조각이 문서 어디에서 나온 내용인지”를 짧게 붙여 저장한다.
조각만 봐도 위치/역할을 알 수 있어 맥락 손실을 줄인다.
3) 요약본으로 찾고, 답변은 원문으로
검색용 인덱스는 요약으로 가볍게 만든다.
하지만 최종 답변에는 원문 단락을 넣어 정확도를 지킨다.
4) 문서가 적으면 통째 컨텍스트도 고려
문서량이 작고 비용 허용 범위면, 굳이 잘게 쪼개지 않고 통째로 넣는 방식이 오히려 안정적일 때가 있다.
팀에서 오늘 바로 적용할 5가지
- 문서 검색을 벡터 단일 방식에서 하이브리드로 전환
- 상위 검색 결과 재랭킹 단계 추가
- 청킹 단위에 문맥 메타(문서/섹션/시점) 추가
- 최종 답변은 원문 인용 기반으로 제한
- “정확도·재현율·오답 유형” 주간 리포트 운영
결론
RAG는 죽지 않았다.
대신 “대충 붙인 RAG”의 수명이 끝나가고 있다.
앞으로의 차이는 모델 크기보다 운영 설계에서 난다.
어떤 팀은 같은 모델로도 신뢰를 쌓고, 어떤 팀은 같은 모델로도 사고를 반복한다.
차이를 만드는 건 한 문장이다.
검색을 잘하는 시스템이 아니라, 맥락을 보존하는 시스템으로 바꿨는가?