3.6데이터와 질의에 맞는 검색 전략

"문서를 검색한다"는 하나의 작업처럼 보이지만, 실제 질의는 성격이 크게 다르고 각각 잘 맞는 방식이 다릅니다.

질의 유형	예	잘 맞는 방식
개념·의미 질의	"환불 관련 규정이 어떻게 되나요"	벡터(의미) 검색
정확 일치	"주문번호 A-99120 상태"	키워드·구조화 조회
고유명사·약어	"SLA-3 등급 조건"	키워드 검색
집계·계산	"지난달 환불 건수"	데이터베이스 질의
시간 범위	"2026년 이후 변경된 조항"	메타데이터 필터
관계 추적	"이 부품을 쓰는 모든 제품"	그래프·조인

이 표의 함의는 벡터 검색이 잘 못하는 것이 분명히 있다는 것입니다. 특히 두 가지에서 자주 무너집니다.

정확 일치와 희귀 토큰. 주문번호, 오류 코드, 제품 모델명 같은 것은 의미 공간에서 가까운 이웃이 없습니다. 임베딩은 "A-99120"과 "A-99121"을 거의 같은 위치에 놓지만 사용자에게는 완전히 다른 것입니다.

집계와 계산. "몇 건인가", "합계가 얼마인가" 같은 질의는 검색으로 답할 수 없습니다. 관련 문서를 아무리 잘 가져와도 모델이 세는 것은 신뢰할 수 없습니다. 이런 질의는 검색이 아니라 데이터베이스 질의로 분기해야 합니다.

따라서 실무 설계의 첫 단계는 질의를 분류하는 것입니다. 모든 질의를 같은 검색 경로로 보내는 시스템은 위 표의 절반에서 나쁜 답을 냅니다.

질의 유형을 완벽히 분류할 수 없을 때의 현실적인 답은 하이브리드 검색입니다. 벡터 검색과 키워드 검색을 함께 돌리고 결과를 합칩니다.

질의 ─┬─▶ 벡터 검색  ──┐
      └─▶ 키워드 검색 ──┴─▶ 결과 병합 ─▶ 재순위 ─▶ 상위 K개

이 구조가 강한 이유는 두 방식의 실패 지점이 다르기 때문입니다. 벡터가 놓치는 고유명사를 키워드가 잡고, 키워드가 놓치는 다른 표현을 벡터가 잡습니다.

병합할 때는 두 검색의 점수 체계가 다르므로 그대로 더할 수 없습니다. 순위 기반으로 합치는 방식(각 결과의 순위를 점수로 환산해 합산)이 널리 쓰입니다. 점수 정규화 방식은 구현마다 다르므로, 중요한 것은 서로 다른 척도를 그대로 섞지 않는 것입니다.

재순위(rerank) 는 병합된 후보를 질의와 함께 다시 채점해 순서를 바로잡는 단계입니다. 1차 검색은 넓고 빠르게, 재순위는 좁고 정밀하게 하는 분업입니다. 후보를 50개 뽑아 재순위로 5개를 고르는 구성이 전형적입니다.

재순위가 값진 이유는 1차 검색의 재현율을 높게 잡을 수 있게 해주기 때문입니다. 재순위가 없으면 상위 5개가 곧 최종이라 1차 검색을 정밀하게 맞춰야 하는데, 재순위가 있으면 1차에서는 놓치지 않는 데 집중하고 정밀도는 뒤에서 확보합니다.

비용은 지연시간입니다. 재순위는 추가 왕복이므로, 3.3에서 다룬 트레이드오프 판단이 그대로 적용됩니다.

데이터 자체의 성질도 전략을 제한합니다.

규모. 청크가 수천 개인 것과 수억 개인 것은 다른 문제입니다. 소규모에서는 전수 비교도 가능하고 인덱스 갱신이 가볍지만, 대규모에서는 근사 최근접 탐색이 필요하고 갱신 전략이 설계 항목이 됩니다.

갱신 빈도. 거의 바뀌지 않는 자료(법령, 매뉴얼)와 실시간으로 바뀌는 자료(재고, 티켓 상태)는 접근이 달라야 합니다. 실시간 데이터를 벡터 인덱스에 넣으면 인덱싱 지연만큼 항상 낡은 답을 하게 됩니다. 자주 바뀌는 데이터는 인덱싱하지 말고 조회 시점에 직접 질의하는 편이 낫습니다.

데이터 성격	접근
정적·대량·비정형	벡터 인덱스
정적·소량	통째로 컨텍스트에 넣는 것도 검토
동적·구조화	조회 시점 직접 질의 (툴)
동적·비정형	짧은 주기 증분 색인 + 신선도 표시

두 번째 줄이 자주 간과됩니다. 자료가 충분히 작으면 RAG 파이프라인을 만드는 것보다 그냥 전부 컨텍스트에 넣는 것이 단순하고 정확합니다. 검색 단계가 없으니 검색 실패도 없습니다. 파이프라인 구축·운영 비용과 캐싱을 감안하면 손익분기가 생각보다 높습니다.

구조화 정도. 표와 데이터베이스처럼 이미 구조가 있는 데이터를 텍스트로 평탄화해 벡터 인덱스에 넣는 것은 정보를 버리는 일입니다. 구조를 살려 질의하는 편이 정확합니다. 모델에게는 검색 결과 대신 질의를 수행하는 툴을 주는 것이 맞는 설계입니다.

사용자의 질문을 그대로 검색에 넣는 것이 항상 최선은 아닙니다. 질의 자체를 손보면 검색 품질이 크게 달라지는 경우가 있습니다.

대화 맥락 해소. 멀티턴 대화에서 "그건 언제부터 적용되나요"라는 질문은 그 자체로는 검색이 불가능합니다. 앞선 대화를 참조해 "환불 규정 개정안은 언제부터 적용되나요"로 재작성해야 검색이 됩니다. 대화형 RAG에서 빠뜨리면 안 되는 단계입니다.

질의 분해. 하나의 질문이 여러 사실을 요구하면 나눠서 검색하는 편이 낫습니다. "A와 B의 차이"는 A에 대한 검색과 B에 대한 검색으로 분해할 때 양쪽 근거를 모두 확보합니다. 통째로 검색하면 한쪽만 잡히는 경우가 흔합니다.

분기 판단. 앞 절의 질의 유형 분류가 여기서 실행됩니다. 집계 질의로 판정되면 벡터 검색을 건너뛰고 데이터베이스 툴로 보냅니다.

이 단계들은 왕복을 늘리므로 항상 넣을 것은 아닙니다. 판단 기준은 다음과 같습니다.

상황	질의 재작성
단발성 질의, 자립적인 문장	불필요
멀티턴 대화	맥락 해소는 사실상 필수
복합 질문이 흔한 도메인	분해가 재현율을 크게 올림
질의 유형이 섞여 들어옴	분기 판단 필요

주의할 점은 재작성이 원래 의도를 바꿔버릴 수 있다는 것입니다. 재작성된 질의를 로그에 남겨두면, 나쁜 답이 나왔을 때 재작성 단계가 원인인지 검색 단계가 원인인지 구분할 수 있습니다. 3.4에서 다룬 추적 기록에 이 필드를 포함시켜야 하는 이유입니다.