RAG는 죽었나? 사내 문서 검색이 실패하는 이유와 청킹·긴 컨텍스트·요약 검색 해결책

핵심 메시지

• 문서를 수백 단어 단위로 자르는 순간 앞뒤 맥락이 사라져, AI는 찾아낸 조각의 의미조차 제대로 해석하지 못한다.
• 클로드 코드처럼 문서를 쪼개지 않고 사람이 파일을 뒤지듯 필요한 부분만 읽어 나가는 접근도 대안으로 등장했다.
• 하이브리드 검색·리랭킹·그래프 기반 RAG는 성능은 뛰어나지만 구축과 유지 비용이 커서 인력이 적은 조직에는 부담이 크다.
• 컨텍스트 윈도우가 크게 넓어졌지만 비용, 용량 한계, 긴 글의 중간을 잊는 성향이라는 세 가지 벽이 남아 있다.
• 구글 파일 검색 도구, 조각에 맥락을 붙이는 방식, 검색은 요약본으로 답변은 원문으로 하는 방식이 현실적인 타협점이다.

쉽게 이해하기

회사 규정이나 계약서를 붙여 놓고도 AI가 "모른다"고 답하는 경험은 흔하다. 영상은 그 원인을 검색 증강 생성(RAG)의 첫 단계, 곧 문서를 잘게 자르는 청킹에서 찾는다. 예컨대 "마케팅 비용이 전 분기 대비 15% 증가했다"는 문장만 뚝 떼어 저장하면, 어느 회사의 몇 년도 몇 분기 이야기인지 알 방법이 사라진다. 두꺼운 책에서 한 페이지만 찢어 보여 주는 것과 같아서, AI가 조각을 정확히 찾아내더라도 엉뚱한 해석을 내놓게 된다.

그래서 아예 문서를 쪼개지 않는 제품도 등장했다. 코딩을 돕는 클로드 코드가 대표적인데, 만 줄짜리 코드라면 처음 열 줄만 읽어 구조를 파악하고 필요할 때 열 줄을 더 읽는 식으로 사람처럼 탐색한다. 영상은 이를 자율주행의 라이다 대 카메라 논쟁에 빗댄다. 정밀하지만 구축이 까다로운 라이다가 기존 RAG라면, 카메라 한 대와 방대한 학습량으로 밀어붙이는 방식이 AI의 직접 탐색에 해당한다는 것이다.

기존 RAG를 살리는 길도 있다. 의미 기반 검색과 키워드 검색을 함께 쓰는 하이브리드 검색, 검색 결과를 다시 평가하는 리랭킹, 문서 간 인용 관계를 지도처럼 그려 두는 그래프 방식이 그것이다. 성능은 확실히 좋아지지만 구축 비용이 크고 문서가 바뀔 때마다 관계도를 다시 그려야 한다. 전담 인력을 두기 어려운 스타트업이나 중소기업에는 사실상 선택하기 힘든 길이다.

그렇다면 문서를 통째로 넣으면 어떨까. 최근 3년 사이 컨텍스트 윈도우가 250배 가까이 커지면서 가능해진 선택지지만, 영상은 세 가지 한계를 짚는다. 책 수십 권 분량을 매번 밀어 넣으면 기존 RAG보다 비용이 크게 늘고, 수십만 건에 달하는 상담 이력이나 규정집은 애초에 한 번에 올릴 수 없다. 게다가 스탠퍼드 연구에 따르면 글이 길어질수록 AI도 처음과 끝은 기억하지만 중간을 잊어버려 성능이 30% 이상 떨어진다.

현실적인 해법으로는 세 가지가 제시된다. 첫째, 구글 제미나이 API에 내장된 파일 검색 도구처럼 청킹·임베딩·벡터 저장을 대행해 주는 서비스를 쓰는 것이다. 둘째, 앤트로픽이 제안한 방식대로 조각을 만들기 전에 그 조각이 문서의 어느 부분인지 꼬리표를 붙여 두면 검색 실패율을 67%까지 줄일 수 있다. 셋째, 단락별 요약문과 소제목으로 검색하되 답변을 만들 때는 원문 단락 전체를 넘기는 방식이다. 도서관에서 목록으로 책을 찾고 자리에 앉아 본문을 읽는 것과 같은 원리다.

주요 인사이트

• RAG가 실패하는 지점은 검색 알고리즘이 아니라 문서를 자르는 방식인 경우가 많다. 검색이 잘 돼도 조각에 맥락이 없으면 답은 흔들린다.
• 문서가 적다면 넓어진 컨텍스트 윈도우를 믿고 통째로 넣는 편이 단순하고 안전하다. 문제는 문서가 많아질 때 시작된다.
• 조각에 위치와 소속을 표시해 두는 것만으로도 검색 실패가 크게 줄어든다. 값비싼 구조 개편보다 먼저 시도할 만한 조치다.
• 검색용 표현과 답변용 원문을 분리하면, 검색 정확도와 답변 품질을 동시에 챙기면서 저장 구조는 단순하게 유지할 수 있다.
• 빅테크가 파이프라인을 대신 처리해 주는 서비스가 늘면서, 자체 벡터 DB 구축이 유일한 선택지이던 시기는 지나가고 있다.

자주 묻는 질문

관련 AI 소식