RAG의 한계와 에이전트 기반 하이브리드 검색 — 청킹은 요약본을 주고 풀본을 쓰라는 것과 같다

들어가며 — “RAG면 충분하지 않냐?”

회사에서 AI 챗봇 도입 논의가 있었다. 누군가가 이렇게 말했다.

“사이트맵 정도 수준에서 간단한 RAG는 충분히 가능하지 않냐, 비싼 돈 들이지 않고서.”

틀린 말은 아니다. FAQ 수준의 챗봇이라면 RAG(Retrieval Augmented Generation)로 충분하다. 하지만 내가 직접 MVP를 만들어보면서 깨달은 건, 복잡한 업무 문서를 다루는 챗봇에서는 RAG만으로 부족하다는 것이었다.

수백 페이지짜리 서류를 청킹하고, 임베딩하고, 벡터 DB에 넣고, 리랭킹까지 해봤다. 결과는? AI에게 책의 요약본을 주고 “전체 내용에 대해 완전하게 답해라"고 하는 것과 같았다.

이 글에서는 그 삽질 과정과, 어떤 아키텍처가 실제로 필요한지를 정리한다.

전통 RAG 파이프라인의 구조

먼저 RAG가 어떻게 동작하는지 간단히 짚자.

사용자 질문
    ↓
질문을 벡터로 변환 (임베딩)
    ↓
벡터 DB에서 유사한 청크 검색
    ↓
검색된 청크들을 LLM 프롬프트에 삽입
    ↓
LLM이 답변 생성

핵심은 원본 문서를 작은 조각(청크)으로 쪼개서 벡터화한다는 것이다. 이 과정에서 문제가 시작된다.

한계 1: 청킹은 정보를 파괴한다

요약본을 주고 풀본을 쓰라는 것

500~1000 토큰 단위로 문서를 자르면 어떤 일이 벌어질까?

PMC(2024)에 게재된 임상 의사결정 지원 RAG 연구에서도, 고정 크기 청킹이 의미 단위를 파괴하여 정확도와 안전성이 유의미하게 하락함이 실증되었다.

직접 겪은 문제

내 경우, 업무용 문서를 청킹해서 벡터 DB에 넣었더니 이런 상황이 발생했다:

질문: "A기업의 특수관계인 현황을 정리해줘"

RAG 답변: "A기업은 특수관계인이 존재합니다.
          관련 내용은 제출 서류를 참조하시기 바랍니다."
          (← 실제 명단이나 지분율은 다른 청크에 있어서 못 찾음)

원본 문서에는 명단, 지분율, 거래 내역이 모두 있었지만, 청킹 과정에서 흩어져버린 것이다. 리랭킹을 아무리 돌려도 이미 잘린 조각의 맥락은 복원할 수 없다.

한계 2: 한국어 임베딩의 부정확성

0.06%의 한국어 학습 데이터

주요 다국어 LLM의 한국어 학습 비중을 보면 충격적이다.

“특수관계인”, “상장적격성”, “심사역 의견서” 같은 전문 용어는 바이트 수준으로 분해되어 의미가 손실된다. “햄버거"라는 일상 단어조차 바이트 토큰으로 쪼개지는데, 법률/금융 용어는 오죽하겠는가.

번역 벤치마크의 함정

영어를 한국어로 번역한 벤치마크에서는 성능이 괜찮아 보인다. 하지만 실제 한국어 원문으로 만든 벤치마크에서는 성능이 급락한다.

2025년 발표된 KorFinMTEB(한국어 금융 텍스트 임베딩 벤치마크)에서 이것이 실증되었다:

번역 벤치마크(FinMTEB 한국어 번역) 대비, 실제 한국어 원문 벤치마크(KorFinMTEB)에서 다국어 모델의 성능이 유의미하게 하락 — arXiv:2502.07131

반면 한국어 전용 모델(KoBERT 기반)은 범용 다국어 모델 대비 93% 성능 향상을 기록했다 (KAIST, 2024).

실무에서의 영향

# 벡터 유사도 검색 결과
query = "특수관계인 정리 의무 근거"

# 다국어 임베딩 모델 결과 (실제 경험)
# → "특수" + "관계" + "인"으로 분해되어
# → "특수한 관계를 가진 사람들"에 대한 일반적 문서가 상위 랭크
# → 정작 법적 정의와 의무를 담은 문서는 하위 랭크

이 문제는 청킹의 문제와 복합적으로 작용한다. 부정확한 임베딩으로 잘못된 청크가 검색되고, 그 청크마저 불완전하다.

한계 3: 동적으로 추가되는 자료를 반영할 수 없다

업무 문서는 정적이지 않다. 예를 들어 심사 과정에서는:

[최초 제출] → [1차 질의] → [답변 + 추가 증빙] → [2차 질의] → [추가 소명] → ...

자료가 계속 추가된다. 전통 RAG에서 이를 반영하려면:

1. 새 자료를 다시 청킹
2. 임베딩 재생성
3. 벡터 DB 업데이트
4. 기존 청크와의 관계 재설정

매번 전체 파이프라인을 재실행해야 하고, 새 자료와 기존 자료 간의 교차 참조 관계는 벡터 유사도만으로 포착이 어렵다.

IBM Think(2024)에서도 전통 RAG의 5가지 핵심 문제로 집계 연산 불가, 관계 추론 불가, 실시간 데이터 접근 불가, 접근 제어 어려움, 복잡 쿼리 처리 불가를 지목했다.

깨달음: LLM의 인터넷 검색과 동일한 원리

여기서 발상의 전환이 일어났다. LLM이 인터넷을 검색해서 답변하는 구조를 생각해보자:

사용자 질문
    ↓
의도 파악
    ↓
기존 학습 지식 확인
    ↓
인터넷 검색 (Google 등)
    ↓
원문 읽기 + 이해
    ↓
종합 답변 생성

LLM은 요약본을 받는 게 아니라, 직접 검색해서 원문을 읽는다. 이걸 내부 문서에 똑같이 적용하면 되는 것 아닌가?

사용자 질문
    ↓
의도 분류 (Intent Classification)
    ↓
메모리 확인 (기 분석된 요약/맥락)
    ↓
검색엔진 조회 (Elasticsearch)
    ↓
원문 읽기 + 이해
    ↓
종합 답변 생성

AI에게 요약본(청크) 대신 원본을 검색할 수 있는 도구(Elasticsearch)를 제공하면 된다. 이것이 핵심 아이디어다.

제안 아키텍처: 에이전트 기반 하이브리드 검색

4단계 파이프라인

Stage 1: 의도 분류 (Intent Classification)

사용자의 질의를 분석해서 최적 검색 전략을 라우팅한다.

기존 RAG는 모든 질의에 동일한 파이프라인을 적용하지만, 에이전트는 질의 유형에 따라 검색 전략을 동적으로 결정한다.

Stage 2: 메모리 확인 (Memory / Context Check)

기 분석된 문서 요약, 이전 대화 맥락, 성공한 검색 패턴을 확인한다.

• 이미 답변한 질문 → 캐시에서 즉시 응답
• 같은 기업에 대한 반복 질문 → 이전 분석 결과 활용
• 유사 질문 이력 → 성공했던 검색 전략 재활용

LLM 에이전트 메모리 동역학 연구(arXiv:2505.16067, 2025)에서는, 단순 메모리 축적이 아닌 품질 관리가 장기 성능에 결정적 영향을 미친다고 밝혔다. 잘못된 과거 답변이 그대로 재활용되면 오류가 전파되기 때문이다.

Stage 3: 하이브리드 검색 (Hybrid Retrieval)

이 단계가 핵심이다. 복수 검색 전략을 병렬 실행한다:

[Elasticsearch BM25]     [벡터 유사도 검색]     [메타데이터 필터]
 정확한 키워드 매칭        의미적 유사성           구조화 조건
 "특수관계인" 정확 매칭    "유사 사례" 검색       "2024년 3월 이후" 필터
         ↓                     ↓                      ↓
         └──────── RRF 결합 (Reciprocal Rank Fusion) ──┘
                           ↓
                  최종 랭킹 + 원문 접근

왜 하이브리드인가?

• 벡터 검색만으로는 부족: “특수관계인"이라는 정확한 용어를 검색할 때, BM25 키워드 매칭이 벡터 유사도보다 압도적으로 정확하다
• 키워드 검색만으로도 부족: “이전 유사한 거절 사례"처럼 의미적 유사성이 필요한 질의에는 BM25가 한계
• RRF(Reciprocal Rank Fusion): 서로 다른 검색 방식의 결과를 순위 기반으로 통합하여 양쪽 장점 확보

50개 이상의 프로덕션 RAG 배포를 분석한 연구(Dev.to, 2024)에서도 BM25 + 벡터 검색 조합이 단일 방식 대비 일관되게 높은 정확도를 보였다.

Stage 4: LLM 종합 답변 (Synthesis)

검색된 원문을 기반으로 답변을 생성한다.

# 기존 RAG
context = [chunk_1, chunk_2, chunk_3]  # 500토큰짜리 조각들
answer = llm.generate(question, context)

# 에이전트 기반
full_documents = elasticsearch.search(query, filters)  # 원본 문서
answer = llm.generate(question, full_documents)
# → 답변 충분성 자체 평가
# → 부족하면 Stage 3 재실행

핵심 차이: 에이전트가 답변의 충분성을 스스로 평가하고, 부족하면 추가 검색을 수행한다. 기존 RAG는 한 번의 검색으로 끝이지만, 에이전트는 반복적으로 정제할 수 있다.

Elasticsearch가 핵심인 이유

왜 하필 Elasticsearch인가?

특히 Nori 형태소 분석기는 한국어에 최적화된 토크나이저로, 다국어 임베딩 모델의 한국어 한계를 우회할 수 있다:

// Elasticsearch + Nori 설정 예시
{
  "settings": {
    "analysis": {
      "analyzer": {
        "korean": {
          "type": "custom",
          "tokenizer": "nori_tokenizer",
          "filter": ["nori_readingform", "lowercase"]
        }
      }
    }
  }
}

이렇게 하면 “특수관계인"을 “특수/관계/인"으로 정확히 분리하여 검색할 수 있다. 바이트 수준으로 분해하는 다국어 임베딩과는 차원이 다르다.

기존 RAG vs 제안 아키텍처 비교

정확도 2배, 지연 2.4배는 GraphRAG 연구(Cognilium AI, 2024)에서 나온 수치다. 정확도가 중요한 업무(금융, 법률, 의료)에서는 이 트레이드오프가 충분히 가치 있다.

보완 기술의 위치: 기본 위에 쌓는 것

이 아키텍처는 벡터DB, 그래프DB, RAG를 부정하는 것이 아니라 우선순위를 재정립하는 것이다.

기본 토대 (반드시 필요):

1. 의도 분류 — 사용자가 뭘 원하는지 먼저 파악
2. 메모리/맥락 관리 — 이전 대화와 분석 결과 기억
3. 전문 검색엔진 — 원본에 접근할 수 있는 능력
4. LLM 종합 판단 — 검색 결과를 읽고 답변 생성

보완 기술 (기본 위에 추가):

• 벡터 DB: 의미적 유사 검색 (키워드로 못 찾는 것 보완)
• 그래프 DB: 엔티티 간 관계 추적 (관계인 관계도 등)
• RAG 청킹: 빠른 요약/개요 제공 (상세 검색 전 프리뷰)
• 리랭킹: 검색 결과 정밀도 향상

비용 분석: “비싼 돈 안 들이고”

같은 비용으로 구조만 바꾸면 된다. Elasticsearch는 오픈소스이므로 추가 라이선스 비용이 없고, LLM API 비용은 단순 RAG든 에이전트 기반이든 동일하게 발생한다.

단계별 구축 로드맵

한꺼번에 다 만들 필요 없다. Phase 1-2만으로도 단순 RAG 대비 실질적 향상이 가능하다.

주의사항과 알려진 함정

메모리 오류 전파

에이전트가 이전에 잘못 답변한 내용을 메모리에 저장하면, 이후 유사 질문에서 같은 오류를 반복한다. 메모리에는 품질 평가 메커니즘이 필수다.

Elasticsearch 단독으로는 부족

BM25는 키워드 매칭에 강하지만, “이전 유사한 사례를 찾아줘” 같은 의미적 검색에는 약하다. 반드시 벡터 검색과 함께 써야 한다.

한국어 전용 모델의 필요성

다국어 모델에 의존하지 말 것. 한국어 금융/법률 도메인에서는 KoBERT 기반 전용 모델이 93% 더 나은 성능을 보인다. Phase 3에서 반드시 도입해야 한다.

응답 지연 트레이드오프

에이전트 기반 아키텍처는 기존 RAG 대비 2.4배 느리다. 실시간 고객 응대에는 부적합할 수 있다. 업무 정확도가 중요한 백오피스 시스템에 적합하다.

결론

“RAG면 충분하다"는 절반만 맞다. FAQ, 사이트맵 안내 수준이라면 충분하다.

하지만 복잡한 업무 문서를 다루는 챗봇에서는:

1. 청킹은 정보를 파괴한다 — 요약본을 주고 풀본을 쓰라는 것과 같다
2. 한국어 임베딩은 아직 부정확하다 — 학습 데이터 0.06%로 전문 용어를 정확히 이해할 수 없다
3. 동적 자료 반영이 어렵다 — 매번 전체 파이프라인을 재실행해야 한다

해결책은 복잡하지 않다:

• AI에게 요약본 대신 원본을 검색할 수 있는 도구(Elasticsearch)를 제공한다
• 이것은 LLM이 인터넷을 검색해서 답변하는 것과 동일한 원리이다
• 여기에 의도 분류와 메모리 관리를 추가하면 실무 수준의 챗봇이 된다

이것이 기본이고, 벡터DB, 그래프DB, 고급 RAG 기법은 이 기본 위에 보완하는 것이다.

참고 자료