RAG를 처음 도입할 때는 보통 “임베딩 + 벡터DB + top-k"로 시작합니다. 이 방식은 빠르게 결과를 보여주기엔 좋지만, 운영 기간이 길어질수록 한계가 명확해집니다. 문서가 늘고 도메인이 복잡해지면, 정답 문서를 못 찾거나 찾더라도 LLM 입력 문맥이 길어져 품질과 비용이 동시에 흔들립니다.

그래서 요즘 팀들이 실제로 옮겨 가는 구조는 단순합니다. 검색 단계를 한 번 더 나누고, 컨텍스트를 압축해 “정확도-지연-비용"을 동시에 제어하는 파이프라인입니다. 핵심 조합은 하이브리드 검색(BM25 + 벡터) + 리랭커 + 컨텍스트 압축입니다.

이 글에서 얻는 것

  • 왜 벡터 검색 단독이 일정 규모 이후 흔들리는지, 병목이 생기는 지점을 구조적으로 이해할 수 있습니다.
  • 하이브리드 검색/리랭커/압축을 붙일 때의 **의사결정 기준(지표·임계치·우선순위)**을 바로 적용할 수 있습니다.
  • 4~6주 안에 파일럿에서 운영 승격까지 가져가는 현실적인 전개 순서를 잡을 수 있습니다.

핵심 개념/이슈

1) 트렌드의 핵심: “Retriever 품질"을 별도 제품으로 운영한다

예전에는 LLM 프롬프트 엔지니어링이 중심이었지만, 최근에는 retriever를 독립된 제품처럼 다룹니다. 이유는 명확합니다.

  • 잘못된 문서를 가져오면, 프롬프트를 아무리 잘 써도 답이 틀립니다.
  • 정답 문서가 있어도 순위가 낮으면 실제 입력 컨텍스트에 들어가지 못합니다.
  • 긴 컨텍스트를 무작정 넣으면 비용과 지연이 급격히 늘어납니다.

즉 “생성"보다 앞단인 “검색/선별/압축"이 품질의 70% 이상을 좌우하는 환경이 많아졌습니다. 배경 개념은 벡터 DB 내부 동작과 Context Engineering 트렌드를 함께 보면 연결이 쉽습니다.

2) 왜 하이브리드 검색이 기본값이 되었나

벡터 검색은 의미 유사성에 강하지만, 식별자·버전·에러코드 같은 정확 키워드에는 약한 경우가 있습니다. 반대로 BM25는 키워드 일치엔 강하지만 의미 확장엔 약합니다.

그래서 실무에서 많이 쓰는 기본형은 다음입니다.

  1. BM25와 벡터 검색을 병렬 실행
  2. Reciprocal Rank Fusion(RRF) 또는 가중 합으로 1차 결합
  3. 상위 문서에 리랭커 적용해 최종 top-n 결정

권장 시작점(파일럿 기준):

  • 후보 수집: BM25 top 40 + Vector top 40
  • 결합 후 리랭커 입력: 상위 30
  • 최종 LLM 컨텍스트 투입: 6~10개 청크

이 구조는 단순 top-k보다 지연이 약간 늘지만, 정답 문서 회수율(recall@k)이 올라가고 “그럴듯한 오답” 비율을 눈에 띄게 줄이는 경우가 많습니다.

3) 리랭커의 역할은 “성능 추가"가 아니라 “오탐 제거"다

많은 팀이 리랭커를 정확도 향상 도구로만 보는데, 운영 관점에선 오탐 제거 장치에 가깝습니다.

  • 유사하지만 무관한 문서(semantic false positive) 제거
  • 오래된 문서가 최신 문서를 밀어내는 문제 완화
  • 섹션 단위 relevance를 재평가해 컨텍스트 낭비 축소

특히 규정/정책/매뉴얼 문서처럼 표현이 비슷한 데이터셋에서 효과가 큽니다. 이 단계는 Evals 기반 개발 흐름처럼 테스트셋을 함께 관리해야 안정적으로 굴러갑니다.

4) 컨텍스트 압축이 없으면 정확도가 올라가도 비용이 무너진다

하이브리드 + 리랭커로 문서 품질을 높이면, 역설적으로 “넣고 싶은 문서"가 많아집니다. 이때 압축이 없으면 지연·비용이 급증합니다.

주요 압축 전략:

  • 쿼리 관련 문장만 추출(문서 전체 투입 금지)
  • 중복 근거 문장 병합(semantic dedup)
  • 테이블/코드블록은 요약 + 원문 포인터로 분리
  • 토큰 예산 초과 시 근거 신뢰도 낮은 청크 우선 제거

이렇게 해야 토큰 비용을 제어하면서도 근거 기반 응답을 유지할 수 있습니다. 보안/거버넌스 측면은 LLM Gateway + Prompt Firewall 트렌드와 함께 설계하는 편이 안전합니다.

실무 적용

1) 의사결정 기준(숫자·조건·우선순위)

우선순위는 정확도 안정화 > 지연 관리 > 비용 최적화 순으로 두는 게 보통 성공 확률이 높습니다.

운영 기준 예시:

  • 검색 품질: recall@20 >= 0.85를 파일럿 승격 최소 조건으로 설정
  • 답변 근거성: grounded answer 비율 90% 이상
  • 지연: retriever + reranker 구간 p95 700ms 이하
  • 비용: 요청당 평균 입력 토큰 30~40% 절감 목표
  • 안전장치: 잘못된 근거 문서 인용률이 주간 2%p 이상 상승하면 즉시 롤백

2) 6주 도입 플랜(과장 없는 현실 버전)

1주차: 기준선 수집

  • 현재 파이프라인의 recall, groundedness, p95 latency, 요청당 토큰 비용 측정
  • 도메인별 대표 질의 200~500개 평가셋 확정

2~3주차: 하이브리드 검색 적용

  • BM25 + 벡터 병렬 검색 추가
  • fusion 가중치 2~3안 실험, recall 중심으로 1차 선택

4주차: 리랭커 도입

  • 상위 후보 20~30개만 리랭킹해 지연 상한 제어
  • 도메인별 오탐 감소율을 별도 리포트

5주차: 컨텍스트 압축 적용

  • 문장 추출/중복 제거/토큰 예산 정책 도입
  • 비용 감소와 정답률 하락 여부를 같이 확인

6주차: 운영 게이트 설정

  • 지표 임계치 기반 자동 승격/롤백 규칙 연결
  • 배포 전 eval 통과 없으면 프로덕션 반영 금지

3) 팀 역할 분리 기준

혼선이 줄어드는 일반적인 분리는 아래와 같습니다.

  • 검색/데이터 팀: 인덱스, 청크 정책, fusion 튜닝
  • AI 애플리케이션 팀: 프롬프트/도구호출/응답 포맷
  • 플랫폼/SRE: 지표, 게이트, 비용/보안 정책

“한 팀이 전부” 구조로 가면 초기 속도는 빠르지만 2~3개월 후 운영 피로가 급격히 올라갑니다. 관측 기준선은 Observability Baseline을 맞춰 두면 관리가 쉽습니다.

트레이드오프/주의점

  1. 정확도 상승이 항상 사용자 체감으로 직결되진 않는다
    질문 의도 분류가 약하면 검색이 좋아져도 체감 개선이 제한됩니다.

  2. 리랭커는 지연 예산을 빠르게 소모한다
    후보 수를 과하게 늘리면 p95가 급상승합니다. “적정 후보 수"를 먼저 찾아야 합니다.

  3. 압축이 과하면 근거 손실이 생긴다
    토큰을 아끼려다 중요한 조건문/예외 규칙이 빠지면 오답이 늘어납니다.

  4. 평가셋이 낡으면 지표가 거짓 안정성을 만든다
    문서 구조와 사용자 질문이 바뀌는 주기에 맞춰 평가셋도 갱신해야 합니다.

체크리스트 또는 연습

체크리스트

  • 벡터 단독이 아니라 BM25 + 벡터 하이브리드 검색을 비교 실험했다.
  • 리랭커 도입 전/후 오탐률 변화를 수치로 기록한다.
  • 컨텍스트 압축 정책(추출/중복제거/예산)이 문서화돼 있다.
  • recall/groundedness/latency/cost를 한 대시보드에서 본다.
  • eval 미통과 시 배포 차단 규칙이 CI 또는 게이트웨이에 연결돼 있다.

연습 과제

  1. 현재 운영 질의 100개를 뽑아, 벡터 단독 vs 하이브리드의 recall@20 차이를 계산해 보세요.
  2. 리랭커 후보 수를 10/20/30으로 바꿔 p95 latency와 groundedness 변화를 비교해 보세요.
  3. 컨텍스트 압축 정책을 2가지(문장 추출형, 요약형)로 나눠 비용 대비 정답률을 비교해 보세요.

관련 글