Qdrant와 Meilisearch를 활용한 한글 최적화 하이브리드 검색 구현

 

I. 기반 검색 엔진: 두 패러다임의 이해

 

효과적인 하이브리드 검색 시스템을 구축하기 위해서는 각 구성 요소의 근본적인 아키텍처 철학을 이해하는 것이 선행되어야 한다. 벡터 검색 엔진 Qdrant와 전문 검색(Full-text search) 엔진 Meilisearch는 단순히 기능적으로 다른 도구가 아니라, 데이터 색인 및 검색 문제에 대해 각기 다른 패러다임에 기반하여 설계되었다. 이러한 상호 보완적인 설계 철학은 두 엔진을 경쟁자가 아닌, 강력한 하이브리드 시스템의 파트너로 만든다.

 

1.1 Qdrant: 의미론적 유사성의 아키텍처

 

Qdrant는 고차원 벡터 데이터를 효율적으로 저장, 관리, 검색하기 위해 특별히 설계된 벡터 유사도 검색 엔진이다.1 그 핵심은 키워드 일치를 넘어 데이터의 의미적, 문맥적 유사성을 찾는 데 있다.

 

핵심 개념: Points, Payloads, Collections

 

Qdrant의 기본 데이터 단위는 '포인트(Point)'이다.2 각 포인트는 고유 ID, 데이터의 의미를 나타내는 고차원 벡터(임베딩), 그리고 필터링 및 추가 정보 저장을 위한 JSON 객체인 '페이로드(Payload)'로 구성된다.1 이러한 포인트들은 '컬렉션(Collection)'이라는 논리적 그룹으로 묶여 관리된다. 각 컬렉션은 내부에 저장될 벡터의 차원(dimensionality)과 유사도 측정 기준(distance metric)을 사전에 정의해야 한다. 코사인 유사도(Cosine Similarity), 유클리드 거리(Euclidean Distance) 등이 주로 사용되며, 이는 쿼리 벡터와 가장 '유사한' 벡터를 찾는 의미론적 검색의 기반이 된다.1

 

BASE 지향 설계 철학

 

Qdrant는 ACID(원자성, 일관성, 고립성, 지속성)를 보장하는 전통적인 데이터베이스와 달리, BASE(Basically Available, Soft state, Eventually consistent) 철학을 기반으로 설계되었다.5 이는 벡터 검색 워크로드의 특성을 반영한 중요한 아키텍처적 선택이다. 벡터 검색은 대용량 트래픽 하에서도 높은 가용성과 낮은 지연 시간을 유지하는 것이 엄격한 데이터 일관성보다 중요하기 때문이다.5 따라서 Qdrant는 전통적인 데이터 저장소보다는 검색 엔진처럼 작동하며, 높은 처리량과 수평적 확장성에 최적화되어 있다.5

 

동적 색인을 위한 세그먼트 기반 아키텍처

 

HNSW(Hierarchical Navigable Small World)와 같은 ANN(근사 근접 이웃) 인덱스는 검색 성능은 뛰어나지만, 데이터가 계속 추가되거나 변경될 때 인덱스를 업데이트하는 비용이 매우 크다. Qdrant는 이 문제를 해결하기 위해 '세그먼트(Segment)'라는 계층화된 아키텍처를 도입했다.5 새로운 데이터는 쓰기 성능을 위해 작고 변경 가능한(mutable) 세그먼트에 먼저 수집된다. 이후 이 세그먼트들은 최적화 과정을 거쳐 HNSW 인덱스가 완전히 구축된 크고 변경 불가능한(immutable) 세그먼트로 통합된다.5 이처럼 쓰기 작업과 검색 작업을 지능적으로 분리함으로써, Qdrant는 지속적으로 데이터가 유입되는 실제 운영 환경에서도 성능 저하 없이 색인과 검색을 동시에 수행할 수 있다.5

 

HNSW 색인 및 필터링 가능한 검색

 

Qdrant의 핵심 색인 알고리즘은 HNSW로, 검색 속도와 정확도 사이의 균형을 맞추는 데 효과적이다.1

m(노드당 엣지 수), ef_construct(색인 구축 시 탐색 범위), ef(쿼리 시 탐색 범위)와 같은 파라미터를 통해 이 균형을 세밀하게 조정할 수 있다.6 특히 Qdrant는 페이로드 기반 필터링을 HNSW 그래프 탐색 과정에 직접 통합한 '필터링 가능한 HNSW(Filterable HNSW)'를 구현했다. 이는 검색 전 필터링(pre-filtering)이나 검색 후 필터링(post-filtering) 방식의 한계를 극복하고, 복잡한 메타데이터 조건을 만족하는 벡터들 내에서 효율적인 의미 검색을 가능하게 한다.5

 

확장성 및 스토리지

 

Qdrant는 수평적 확장을 위해 데이터를 여러 노드에 분산하는 '샤딩(Sharding)'과 고가용성을 위한 '복제(Replication)' 메커니즘을 지원한다.8 또한, 최고 속도를 위한 '인메모리(In-memory)' 스토리지와 대용량 데이터셋을 위한 '메모리 맵(Memmap)' 스토리지 옵션을 제공하여, 다양한 성능 및 비용 요구사항에 맞춰 시스템을 구성할 수 있다.1

 

1.2 Meilisearch: 어휘적 정확성의 메커니즘

 

Meilisearch는 전문 검색(Full-text search)에 특화된 '번개처럼 빠른(lightning-fast)' 검색 엔진으로, 사용자에게 직관적인 검색 경험을 제공하는 데 초점을 맞춘다.9

 

핵심 개념과 인버티드 인덱스

 

Meilisearch의 기본 데이터 단위는 필드로 구성된 JSON 객체인 '문서(Document)'이다.11 Meilisearch의 압도적인 검색 속도의 핵심은 '인버티드 인덱스(Inverted Index)'에 있다.12 이 데이터 구조는 문서 내 단어(토큰)를 해당 단어가 포함된 문서의 ID에 매핑한다. 덕분에 사용자가 쿼리를 입력하면 전체 문서를 스캔할 필요 없이 즉시 관련 문서를 찾아낼 수 있으며, 이는 50ms 미만의 'search-as-you-type' 경험을 가능하게 하는 기반 기술이다.10

 

토크나이제이션 파이프라인

 

색인의 첫 단계는 텍스트를 검색 가능한 단위인 '토큰(Token)'으로 분해하는 토크나이제이션이다. Meilisearch는 자체 개발한 오픈소스 토크나이저 'Charabia'를 사용하여 이 과정을 수행한다.12 Charabia는 텍스트의 언어를 감지하고, 해당 언어에 맞는 파이프라인을 통해 분할(segmentation) 및 정규화(normalization)를 진행한다.14 이 과정에서 텍스트는 토큰으로 나뉘고, 소문자로 변환되며, 불용어(stop words)가 제거되는 등 검색에 최적화된 형태로 가공되어 인버티드 인덱스에 저장된다.12

 

LMDB 스토리지 엔진

 

Meilisearch는 스토리지 엔진으로 LMDB(Lightning Memory-Mapped Database)를 채택했다.15 LMDB는 ACID 속성을 가진 트랜잭션 키-값 저장소로, 안정성과 고성능을 동시에 제공한다.15 특히 메모리 맵(memory-mapped) 방식으로 작동하기 때문에 디스크의 데이터를 메모리에 복사하는 과정 없이 직접 접근할 수 있어 읽기 성능이 매우 뛰어나다.15 다만 이러한 설계는 장단점을 수반하는데, 데이터를 삭제해도 디스크 공간이 운영체제에 즉시 반환되지 않고 내부적으로 재사용 대기 상태로 표시되기 때문에 데이터베이스 파일 크기는 계속 증가하는 경향이 있다.15

 

내장 하이브리드 검색 기능

 

Meilisearch는 자체적으로 하이브리드 검색 기능을 제공한다. 사용자는 semanticRatio 파라미터를 조정하여 Meilisearch의 네이티브 키워드 검색 결과와 외부 임베딩 모델을 통해 생성된 벡터 검색 결과를 혼합할 수 있다.16 이는 간단한 하이브리드 검색 요구사항을 단일 플랫폼 내에서 해결할 수 있는 옵션을 제공한다.

두 엔진의 아키텍처 선택은 각자가 해결하고자 하는 문제의 본질을 명확히 보여준다. Qdrant의 BASE 철학과 세그먼트 기반 아키텍처는 가용성과 처리량이 중요하고 데이터가 동적으로 변하는 의미론적 검색 환경에 최적화되어 있다. 반면, Meilisearch의 LMDB와 인버티드 인덱스 조합은 어휘적 정확성과 예측 가능한 순위, 빠른 응답 속도가 중요한 키워드 검색 환경에 이상적이다. 결국 Qdrant는 의미론적 재현율(recall), 즉 문맥적으로 관련된 모든 것을 찾는 데 중점을 두고 설계되었고, Meilisearch는 어휘적 정확성(precision), 즉 키워드와 정확히 일치하는 것을 찾는 데 초점을 맞추고 있다. 이처럼 근본적으로 다른 두 설계 철학의 상호 보완성이야말로 성공적인 하이브리드 검색 시스템의 이론적 토대가 된다.

 

II. 한국어 처리를 위한 최적화

 

범용 검색 시스템을 넘어 한국어 환경에 특화된 고성능 검색 시스템을 구축하기 위해서는 언어의 고유한 특성을 고려한 최적화가 필수적이다. 이는 임베딩 모델 선택부터 토크나이제이션, 문서 청킹 전략에 이르기까지 전 과정에 걸쳐 세밀한 접근을 요구한다.

 

2.1 이해의 심장: kure-v1 임베딩 모델 심층 분석

 

의미론적 검색의 성능은 임베딩 모델의 품질에 의해 결정된다. 한국어 검색에서는 한국어의 복잡한 문맥과 의미를 정확하게 벡터 공간에 투영할 수 있는 모델을 선택하는 것이 가장 중요하다.

 

기술 사양 및 학습 방법론

 

kure-v1은 고려대학교 NLP&AI 연구실에서 개발한 최신 한국어 검색(retrieval) 특화 임베딩 모델이다.18 이 모델은 강력한 다국어 모델인

BAAI/bge-m3를 기반으로 파인튜닝되었다.19 주요 기술 사양은 다음과 같다:

• 임베딩 차원: 1024차원으로, 풍부한 의미 정보를 벡터 공간에 표현할 수 있다.18
• 최대 시퀀스 길이: 8192 토큰으로, 법률 문서나 기술 매뉴얼과 같은 긴 텍스트를 효과적으로 처리하는 데 매우 적합하다.19

kure-v1의 뛰어난 성능은 특화된 학습 방식에서 비롯된다. 약 200만 쌍의 대규모 한국어 질의-문서 데이터를 기반으로 학습되었으며, 각 데이터 쌍마다 5개의 어려운 부정 예제(hard negatives)를 함께 사용하여 모델이 미묘한 의미 차이를 구분하도록 훈련되었다. 이때 CachedGISTEmbedLoss 손실 함수가 사용되어 검색 성능을 극대화했다.19

 

성능 분석 및 비교

 

kure-v1은 공개된 여러 한국어 검색 벤치마크에서 기존 모델들을 압도하는 최상위 성능을 입증했다.18

kure-v1의 성능을 다른 주요 한국어 임베딩 모델과 비교하면 그 우수성이 더욱 명확해진다.

모델명	기반 모델	임베딩 차원	최대 시퀀스 길이	검색 F1	검색 Recall	검색 Precision	KorSTS 성능 (Pearson)
nlpai-lab/KURE-v1	BAAI/bge-m3	1024	8192	-	-	-	-
hunkim/sentence-transformers-klue-bert-base	klue/bert-base	768	512	-	-	-	-
jhgan/ko-sbert-sts	-	768	128	-	-	-	81.55
jhgan/ko-sbert-multitask	-	768	128	-	-	-	84.13
BAAI/bge-m3 (Baseline)	-	1024	8192	0.35	0.70	0.23	-

표 1: 한국어 임베딩 모델 성능 비교 (성능 데이터는 사용 가능한 소스 기반으로 작성됨 18)

KLUE-BERT는 62GB의 대규모 한국어 코퍼스로 사전 학습된 모델로, 한국어의 형태론적 구조를 존중하는 독창적인 '형태소 기반 서브워드 토크나이저'가 특징이다.25 이를 문장 임베딩용으로 파인튜닝한

hunkim/sentence-transformers-klue-bert-base 모델은 768차원 벡터를 생성한다.21 Ko-SBERT 계열 모델들은 한국어 의미 유사도(STS) 및 자연어 추론(NLI) 태스크에 특화되어 KorSTS 벤치마크에서 높은 성능을 보인다.22

kure-v1의 기반이 된 bge-m3 모델 자체도 한국어 검색 테스트에서 강력한 성능을 보여주며, kure-v1은 이를 뛰어넘는 성능을 목표로 개발되었다.24

kure-v1은 긴 시퀀스 처리 능력과 검색에 특화된 학습 방식으로 인해 복잡한 한국어 문서 검색에서 가장 신뢰할 수 있는 선택지이다.

 

2.2 한글 해체: Meilisearch의 토크나이제이션과 전문 검색 색인

 

Meilisearch의 전문 검색 성능은 Charabia 토크나이저에 의해 좌우된다.13 한국어 처리의 경우, Charabia는

lindera 라이브러리와 한국어 사전(KO-dict)을 사용하여 텍스트를 형태소 단위로 분절한다.13 이는 교착어인 한국어의 특성을 고려한 사전 기반 접근 방식이다.

그러나 중요한 고려사항은 성능이다. Charabia의 공식 문서에 따르면, 한국어 토크나이제이션 성능은 "🟥" 등급(1-3 MiB/sec)으로, 공백으로 단어를 구분하는 라틴어 계열 언어에 비해 현저히 느리다.13 이는 대규모 한국어 문서를 Meilisearch에 색인할 때 잠재적인 성능 병목 현상이 발생할 수 있음을 시사하며, 데이터 수집 및 색인 파이프라인 설계 시 반드시 고려해야 할 요소이다.

 

2.3 한국어 문서 구조화: 고급 청킹 전략

 

RAG(검색 증강 생성) 시스템의 검색 품질은 문서 청킹(chunking) 전략에 크게 의존한다. 특히 여러 형태소가 결합하여 하나의 어절을 이루는 한국어의 교착어적 특성 때문에, 단순한 공백이나 글자 수 기반의 청킹은 의미 단위를 파괴할 위험이 크다.28

 

청킹 전략 비교 분석

 

다양한 청킹 전략을 한국어 문서의 특성에 맞춰 분석하고 최적의 방안을 도출해야 한다.

전략명	작동 방식	한국어 처리 장점	한국어 처리 단점	이상적인 활용 사례
고정 크기 분할 (Fixed-Size)	지정된 토큰/문자 수로 텍스트 분할	구현이 간단함	의미 있는 형태소 결합을 절단할 위험이 매우 높음	빠른 전처리 또는 탐색적 분석
재귀적 문자 분할 (Recursive)	문단, 문장, 단어 등 계층적 구분자로 분할	문단/문장 구조를 존중하여 고정 크기 분할보다 문맥 보존에 유리함	어절 단위에서 여전히 의미 단위를 파괴할 수 있음	구조화된 긴 문서(보고서, 기사)
문서 구조 기반 분할 (Structural)	마크다운 헤더, HTML 태그 등 문서 구조를 기준으로 분할	저자의 논리적 그룹화를 그대로 유지하여 언어와 무관하게 문맥 보존	구조가 없는 문서에는 적용 불가	법률 문서, 기술 매뉴얼, API 문서
의미론적 분할 (Semantic)	임베딩 유사도를 계산하여 의미적으로 관련된 문장들을 그룹화	kure-v1과 결합 시, 한국어 의미론을 존중하는 가장 일관성 있는 청크 생성 가능	계산 비용이 높고, 임베딩 모델의 성능에 의존적임	주제 전환이 잦은 비정형 텍스트
에이전틱 분할 (Agentic)	LLM을 사용하여 인간의 판단을 모방, 텍스트를 논리적으로 분할/요약	가장 복잡하고 비구조적인 문서도 처리 가능	비용과 지연 시간이 가장 높음	고도로 복잡한 비정형 문서

표 2: 한국어 문서 청킹 전략 분석 29

 

한국어 문서를 위한 최적의 청킹 전략 제안

 

한국어 문서의 특성을 고려할 때, 다단계 하이브리드 청킹 전략이 가장 효과적이다.

1. 1단계 (구조적 분할): 먼저 LangChain의 MarkdownHeaderTextSplitter와 같은 구조 기반 분할기를 사용하여 문서를 헤더나 목차 기준으로 큰 논리적 섹션으로 나눈다.35 이는 문서의 전체적인 구조와 문맥을 보존한다.
2. 2단계 (의미론적 분할): 각 섹션 내부에서 kure-v1 모델을 활용한 의미론적 분할(예: LangChain의 SemanticChunker)을 적용한다.33 이를 통해 의미적으로 긴밀하게 연결된 문장들을 하나의 청크로 묶어, 한국어의 교착어적 특성으로 인한 의미 단절을 방지한다.

이러한 접근 방식은 문서의 거시적 구조와 미시적 의미를 모두 보존하여 검색 품질을 극대화한다.

시스템의 각 구성요소는 서로 긴밀하게 연결되어 있다. 예를 들어, kure-v1 모델이 8192 토큰이라는 긴 컨텍스트 창을 지원한다는 사실은 청킹 전략에 직접적인 영향을 미친다.18 과거에는 임베딩 모델의 컨텍스트 창 제약 때문에 256-512 토큰 단위의 작은 청크를 생성하는 것이 일반적이었다.36 하지만

kure-v1을 사용하면, 의미론적 분할을 통해 생성된 더 크고 문맥적으로 완전한 단락 전체를 하나의 청크로 만들 수 있다. 이렇게 더 큰 단위로 청킹하면 전체 청크의 수가 줄어들고, 이는 Meilisearch의 상대적으로 느린 한국어 토크나이저의 색인 작업 부담을 완화하는 부수적인 효과를 가져온다.13 즉, 강력한 임베딩 모델의 선택이 더 나은 전처리 전략을 가능하게 하고, 이는 결과적으로 다운스트림 시스템의 잠재적 병목 현상을 완화하는 연쇄 효과를 낳는다.

 

III. 하이브리드 검색 시스템 아키텍처 설계

 

Qdrant의 의미론적 검색 능력과 Meilisearch의 어휘적 정확성을 결합하기 위한 아키텍처는 크게 두 가지 패턴으로 나눌 수 있다. 각 패턴은 지연 시간, 비용, 검색 품질 간의 서로 다른 트레이드오프를 가지며, 최종 선택은 애플리케이션의 구체적인 요구사항과 사용자 경험(UX) 목표에 따라 결정되어야 한다.

 

3.1 패턴 I: 병렬 검색 및 상호 순위 융합 (RRF)

 

이 아키텍처는 속도와 효율성을 중시하는 실시간 상호작용 애플리케이션에 적합하다.

 

아키텍처 개요

 

사용자 쿼리가 입력되면, 시스템은 이를 Qdrant와 Meilisearch에 동시에 전송한다.37 Meilisearch는 쿼리 텍스트를 기반으로 키워드 검색을 수행하고, Qdrant는 쿼리를 임베딩 벡터로 변환하여 벡터 유사도 검색을 수행한다. 이렇게 독립적으로 실행된 두 검색 결과(각각 순위가 매겨진 문서 ID 목록)는 후처리 단계에서 하나의 통합된 목록으로 융합된다.38

 

융합 알고리즘: Reciprocal Rank Fusion (RRF)

 

두 개의 이질적인 결과 목록을 융합하는 가장 효과적인 방법 중 하나는 상호 순위 융합(Reciprocal Rank Fusion, RRF)이다.39 RRF는 각 검색 결과의 절대적인 점수(score) 대신 순위(rank) 정보만을 사용한다. 특정 문서의 최종 RRF 점수는 해당 문서가 각 결과 목록에서 차지하는 순위를 기반으로 계산된다. 공식은 다음과 같다:

RRFscore​(d)=r∈R∑​k+rankr​(d)1​

여기서 d는 문서, R은 검색기(retriever) 집합(이 경우 Meilisearch와 Qdrant), $rank_r(d)$는 검색기 r의 결과에서 문서 d의 순위, 그리고 k는 상수(일반적으로 60)이다.39 상수

k는 최상위 순위 결과가 전체 점수를 과도하게 지배하는 것을 방지하고 하위 순위 결과에도 일정 부분 기여할 기회를 주는 역할을 한다.40

 

RRF와 점수 정규화 방식의 비교

 

RRF는 가중치 합(weighted sum)이나 최소-최대 정규화(min-max normalization) 같은 단순한 점수 기반 융합 방식보다 훨씬 견고하다.41 키워드 검색(예: BM25) 점수와 벡터 검색(예: 코사인 유사도) 점수는 서로 다른 척도와 분포를 가지기 때문에 직접 비교하거나 정규화하기 어렵다. RRF는 순위 위치만을 사용함으로써 이러한 점수 분포의 차이나 이상치(outlier)에 영향을 받지 않고 안정적인 융합 결과를 제공한다.42

 

가중 RRF (Weighted RRF)

 

더 나아가, 쿼리의 특성에 따라 특정 검색 결과에 더 높은 가중치를 부여하는 '가중 RRF(Weighted RRF)'를 적용할 수 있다.43 예를 들어, 모호하고 문맥적인 쿼리에는 벡터 검색 결과의 RRF 점수에 더 높은 가중치를 곱하고, 제품 번호와 같은 명확한 키워드 쿼리에는 키워드 검색 결과에 더 높은 가중치를 부여하여 융합의 유연성을 높일 수 있다.44

 

3.2 패턴 II: 다단계 검색과 Cross-Encoder 재순위화

 

이 아키텍처는 응답 속도보다 검색 결과의 최종 정확성을 극대화하는 것이 중요한 애플리케이션에 적합하다.

 

아키텍처 개요

 

이 패턴은 현대 정보 검색 시스템에서 널리 사용되는 다단계 '깔때기(funnel)' 접근 방식을 따른다.45

• 1단계 (검색/재현율 단계): Meilisearch와 같은 빠르지만 상대적으로 정확도가 낮은 검색기를 사용하여 대규모의 초기 후보군(예: 상위 100개 문서)을 신속하게 검색한다. 이 단계의 목표는 관련 문서를 놓치지 않는 것, 즉 높은 재현율(recall)을 확보하는 것이다.
• 2단계 (재순위화/정확성 단계): 1단계에서 선별된 소수의 후보군만을 대상으로, 계산 비용이 높지만 훨씬 정교한 모델을 사용하여 순위를 재조정한다. 이 단계에서는 Cross-Encoder 모델이 뛰어난 성능을 발휘한다.46 임베딩에 사용되는 Bi-Encoder와 달리, Cross-Encoder는 쿼리와 후보 문서를 쌍으로 입력받아 함께 처리하므로, 둘 사이의 상호작용을 더 깊이 이해하고 훨씬 정확한 관련도 점수를 계산할 수 있다.48

 

효율성 대 정확성 트레이드오프

 

이 아키텍처는 의도적으로 지연 시간을 희생하여 정확성을 얻는 구조이다.46 계산량이 많은 Cross-Encoder를 전체 문서가 아닌 소수의 후보군에만 적용함으로써, 전체 시스템의 실행 가능성을 유지하면서 최종 결과의 품질을 극대화한다. 병렬 RRF 방식보다 응답 시간은 길어지지만, 일반적으로 더 높은 품질의 최종 순위를 제공한다.46

 

조건부 실행

 

이 패턴의 변형으로, 2단계 검색을 조건부로 실행하는 전략도 가능하다. 예를 들어, 1단계 키워드 검색에서 제품 ID와 같이 신뢰도 높은 정확한 일치 항목이 발견되면, 비용이 많이 드는 2단계 의미 검색 및 재순위화 과정을 건너뛰고 즉시 결과를 반환하여 불필요한 지연 시간을 줄일 수 있다.50

 

3.3 하이브리드 아키텍처 비교 분석

 

두 아키텍처 패턴의 선택은 기술적 트레이드오프를 넘어, 애플리케이션이 제공하고자 하는 핵심 사용자 경험에 대한 전략적 결정과 맞닿아 있다. 병렬 RRF 패턴은 빠른 응답을 통해 실시간 상호작용의 만족도를 높이는 데 초점을 맞춘다. 반면, 다단계 재순위화 패턴은 다소 시간이 걸리더라도 가장 정확하고 신뢰할 수 있는 정보를 제공하여 깊이 있는 탐색을 지원하는 데 중점을 둔다. 따라서 개발자는 시스템을 구축하기에 앞서 '사용자는 즉각적인 답변을 원하는가, 아니면 가장 정확한 단 하나의 문서를 원하는가?'와 같은 근본적인 질문에 답해야 한다. 이 질문에 대한 답이 최적의 아키텍처를 결정하는 가장 중요한 지침이 될 것이다.

아키텍처 패턴	주요 목표	지연 시간	계산 비용	구현 복잡도	결과 품질 (정확성)	이상적인 활용 사례
병렬 검색 및 RRF	속도, 효율성	낮음	중간	중간	높음	실시간 챗봇, 전자상거래 검색, Search-as-you-type
다단계 및 재순위화	정확성, 신뢰성	높음	높음	높음	매우 높음	법률/의료 연구, 학술 논문 검색, 기업 내부 지식 관리

표 3: 하이브리드 검색 아키텍처 트레이드오프 비교 39

 

IV. 구현을 위한 청사진: RAG 파이프라인

 

이론적 아키텍처를 실제 시스템으로 구현하기 위한 구체적인 데이터 흐름과 파이프라인을 제시한다. 전체 프로세스는 오프라인에서 수행되는 '색인 파이프라인'과 온라인에서 실시간으로 처리되는 '검색 및 생성 파이프라인'으로 나뉜다.

 

4.1 색인 데이터 흐름

 

색인 파이프라인은 원본 문서를 검색 가능한 형태로 가공하여 Qdrant와 Meilisearch에 저장하는 오프라인 배치(batch) 작업이다. 데이터 흐름도(Data Flow Diagram, DFD)의 관점에서 각 단계를 시각화할 수 있다.51

• 1단계: 문서 수집 (Document Ingestion): 외부 데이터 소스(예: 파일 시스템, 데이터베이스)에서 한국어 원본 문서를 가져온다. LangChain의 PyPDFLoader와 같은 데이터 커넥터를 사용하여 PDF, Notion 페이지 등 다양한 형식의 문서를 로드할 수 있다.52
• 2단계: 전처리 및 청킹 (Preprocessing & Chunking): 수집된 문서에서 불필요한 공백이나 특수문자를 제거하는 정제 작업을 수행한다. 이후, II장에서 제안한 '한국어 최적화 다단계 청킹 전략'을 적용하여 문서를 의미 있는 청크(chunk) 단위로 분할한다. 표와 같은 구조화된 데이터의 경우, 이를 자연어 요약문으로 변환하거나 일반 텍스트로 직렬화한 후 청킹을 적용하는 전략을 사용한다.54
• 3단계: 임베딩 (Embedding): 생성된 각 청크의 텍스트 내용을 kure-v1 임베딩 모델에 입력하여 1024차원의 고밀도(dense) 벡터를 생성한다.52
• 4단계: 이중 색인 (Dual Indexing):

• Meilisearch로 전송: 각 청크의 원본 텍스트와 메타데이터(원본 문서명, 섹션 헤더 등)를 Meilisearch 인덱스에 전송하여 전문 검색을 위한 인버티드 인덱스를 생성한다.52
• Qdrant로 전송: 3단계에서 생성된 kure-v1 벡터를 Qdrant 컬렉션에 저장한다. 이때, 청크의 원본 텍스트와 모든 메타데이터는 해당 벡터 포인트의 **페이로드(payload)**에 함께 저장된다.55 두 시스템 간의 데이터 일관성을 위해 각 청크에는 고유한 ID를 부여하고, 이 ID를 Qdrant와 Meilisearch 양쪽에서 동일하게 사용해야 한다.

 

4.2 검색 및 생성 데이터 흐름

 

검색 및 생성 파이프라인은 사용자 쿼리를 받아 실시간으로 답변을 생성하는 온라인 작업이다.

• 1단계: 쿼리 처리 (Query Processing): 사용자가 한국어로 쿼리를 입력한다.
• 2단계: 이중 검색 실행 (Dual Search Execution - RRF 패턴 기준):

• 사용자의 원본 쿼리 텍스트는 Meilisearch API로 전송되어 키워드 기반 검색을 수행한다.
• 동시에, 쿼리 텍스트는 kure-v1 모델을 통해 임베딩 벡터로 변환된 후 Qdrant API로 전송되어 벡터 유사도 검색을 수행한다.55

• 3단계: 결과 융합 (Result Fusion): Meilisearch와 Qdrant로부터 반환된 두 개의 순위화된 문서 ID 목록을 RRF 알고리즘에 입력하여, 최종적으로 통합된 상위 K개의 문서 ID 목록을 생성한다.39
• 4단계: 컨텍스트 검색 (Context Retrieval): 융합된 상위 K개 문서 ID를 사용하여 해당 청크들의 전체 텍스트 내용을 검색한다. 색인 파이프라인에서 Qdrant의 페이로드에 전체 텍스트를 저장해두었기 때문에, Qdrant에 ID 목록을 전달하는 단일 API 호출로 필요한 모든 컨텍스트를 효율적으로 가져올 수 있다.
• 5단계: 증강 및 생성 (Augmentation & Generation): 검색된 텍스트 청크들을 하나의 긴 문자열로 결합하여 '컨텍스트'를 구성한다. 이 컨텍스트와 사용자의 원본 쿼리를 프롬프트 템플릿에 맞게 조합한 후, 최종적으로 대규모 언어 모델(LLM)에 전달하여 자연스러운 한국어 답변을 생성한다.52

 

V. 전략적 제언 및 미래 전망

 

본 분석을 통해 Qdrant와 Meilisearch를 결합하고, 한국어 특화 모델 및 처리 기법을 적용하여 고성능 하이브리드 검색 시스템을 구축하기 위한 포괄적인 청사진을 제시했다. 최종 시스템 아키텍처 선택과 향후 발전 방향에 대한 전략적 제언은 다음과 같다.

 

결정 프레임워크

 

최적의 아키텍처는 기술적 우월성만으로 결정되지 않으며, 비즈니스 요구사항과 사용자 경험 목표에 부합해야 한다.

• 병렬 검색 및 RRF 아키텍처: 실시간 챗봇, 대화형 AI 에이전트, 전자상거래 상품 검색과 같이 낮은 지연 시간이 사용자 만족도에 결정적인 영향을 미치는 애플리케이션에 이 패턴을 권장한다. 빠른 응답 속도를 통해 원활한 상호작용을 보장하는 것이 핵심이다.
• 다단계 재순위화 아키텍처: 법률 문서 분석, 의료 정보 검색, 학술 연구와 같이 답변의 정확성과 신뢰성이 속도보다 훨씬 중요한 전문 분야 애플리케이션에 이 패턴을 권장한다. 다소의 지연 시간을 감수하더라도 가장 정확한 정보를 제공하는 것이 시스템의 가치를 결정한다.

모든 시나리오에서, 복잡한 한국어 문서를 다룰 때는 본 보고서에서 제안한 **다단계 하이브리드 청킹 전략(구조적 분할 후 의미론적 분할)**을 적용하여 검색 품질의 기반을 다지는 것이 필수적이다.

 

미래 동향 및 발전 가능성

 

현재 제안된 시스템은 최신 기술을 기반으로 하지만, 정보 검색 분야는 빠르게 발전하고 있다. 향후 다음과 같은 기술들을 통합하여 시스템을 더욱 고도화할 수 있다.

• 고급 재순위화 모델 도입: Qdrant가 지원하는 ColBERT와 같은 다중 벡터 표현 기반 재순위화 모델은 Cross-Encoder의 정확성과 Bi-Encoder의 효율성 사이의 균형을 제공하며, 성능과 속도를 모두 개선할 수 있는 유망한 대안이다.5
• GraphRAG 활용: 문서 내의 개체와 그 관계를 지식 그래프로 구축하고 이를 검색에 활용하는 GraphRAG는 단순한 의미적 유사성을 넘어, 데이터 간의 복잡한 관계를 이해하는 차세대 검색 패러다임을 제시한다.59
• 한국어 언어 모델의 지속적 발전: kure-v1과 같은 고성능 한국어 특화 모델의 등장은 앞으로도 계속될 것이다. 더 정교하고 효율적인 모델이 등장함에 따라, 임베딩, 의미론적 청킹, 재순위화 등 파이프라인의 모든 단계에서 성능 향상을 기대할 수 있다.

결론적으로, 성공적인 하이브리드 검색 시스템 구축은 단순히 두 개의 검색 엔진을 연결하는 것을 넘어, 각 엔진의 아키텍처 철학을 이해하고, 대상 언어의 특성에 맞는 데이터 처리 전략을 수립하며, 최종적으로는 애플리케이션의 핵심 가치에 부합하는 아키텍처를 선택하는 종합적인 과정이다. 본 보고서에서 제시된 분석과 청사진이 이러한 복잡한 과제를 해결하는 데 있어 실질적인 가이드가 되기를 기대한다.

참고 자료

1. What is Qdrant? - Qdrant, https://qdrant.tech/documentation/overview/
2. The Fundamentals of Qdrant: Understanding the 6 Core Concepts - Airbyte, https://airbyte.com/blog/fundamentals-of-qdrant
3. A Deep Dive into Qdrant, the Rust-Based Vector Database - Analytics Vidhya, https://www.analyticsvidhya.com/blog/2023/11/a-deep-dive-into-qdrant-the-rust-based-vector-database/
4. A Deep Dive into Qdrant, the Rust-Based Vector Database - Analytics Vidhya, https://www.analyticsvidhya.com/back-channel/download-pdf.php?pid=134583&next=
5. Built for Vector Search - Qdrant, https://qdrant.tech/articles/dedicated-vector-search/
6. Vector Search Resource Optimization Guide - Qdrant, https://qdrant.tech/articles/vector-search-resource-optimization/
7. Understanding Vector Search using Qdrant | by Abhishek Kumar - Medium, https://medium.com/@abhishekkrtrivedi995/understanding-vector-search-using-qdrant-a0f72acf09a6
8. qdrant-multi-node-cluster/docs/guides/architecture.md at main - GitHub, https://github.com/Mohitkr95/qdrant-multi-node-cluster/blob/main/docs/guides/architecture.md
9. meilisearch/meilisearch: A lightning-fast search engine API bringing AI-powered hybrid search to your sites and applications. - GitHub, https://github.com/meilisearch/meilisearch
10. What is Meilisearch? - Meilisearch Documentation, https://www.meilisearch.com/docs/learn/getting_started/what_is_meilisearch
11. Documents - Meilisearch, https://www.meilisearch.com/docs/learn/getting_started/documents
12. What is full-text search and how does it work? - Meilisearch, https://www.meilisearch.com/blog/how-full-text-search-engines-work
13. meilisearch/charabia: Library used by Meilisearch to ... - GitHub, https://github.com/meilisearch/charabia
14. Tokenization - Meilisearch Documentation, https://www.meilisearch.com/docs/learn/indexing/tokenization
15. Storage - Meilisearch Documentation, https://www.meilisearch.com/docs/learn/engine/storage
16. Full-text search vs vector search - Meilisearch, https://www.meilisearch.com/blog/full-text-search-vs-vector-search
17. Hybrid search: Definition, how it works, benefits and more - Meilisearch, https://www.meilisearch.com/blog/hybrid-search
18. KURE-v1 | AI Model Details - AIModels.fyi, https://www.aimodels.fyi/models/huggingFace/kure-v1-nlpai-lab
19. nlpai-lab/KURE-v1 · Hugging Face, https://huggingface.co/nlpai-lab/KURE-v1
20. KURE-v1 - PromptLayer, https://www.promptlayer.com/models/kure-v1
21. hunkim/sentence-transformers-klue-bert-base · Hugging Face, https://huggingface.co/hunkim/sentence-transformers-klue-bert-base
22. jhgan/ko-sbert-sts · Hugging Face, https://huggingface.co/jhgan/ko-sbert-sts
23. Ko Sbert Multitask · Models · Dataloop, https://dataloop.ai/library/model/jhgan_ko-sbert-multitask/
24. 한국어 임베딩 모델 성능 비교 테스트 결과 — Steemit, https://steemit.com/krdev/@anpigon/20240604t162445271z
25. Bert Base · Models - Dataloop, https://dataloop.ai/library/model/klue_bert-base/
26. klue/bert-base · Hugging Face, https://huggingface.co/klue/bert-base
27. Ko Sbert Sts · Models - Dataloop, https://dataloop.ai/library/model/jhgan_ko-sbert-sts/
28. Rules for NP chunking in Korean texts | Download Table - ResearchGate, https://www.researchgate.net/figure/Rules-for-NP-chunking-in-Korean-texts_tbl1_221324448
29. Chunking strategies for RAG tutorial using Granite | IBM, https://www.ibm.com/think/tutorials/chunking-strategies-for-rag-with-langchain-watsonx-ai
30. A Guide to Chunking Strategies for Retrieval Augmented Generation (RAG) - Sagacify, https://www.sagacify.com/news/a-guide-to-chunking-strategies-for-retrieval-augmented-generation-rag
31. Semantic Chunking for RAG: Optimizing Retrieval-Augmented Generation, https://www.machinelearningplus.com/gen-ai/semantic-chunking-for-rag-optimizing-retrieval-augmented-generation/
32. Text splitters | 🦜️ LangChain, https://python.langchain.com/docs/concepts/text_splitters/
33. How to split text based on semantic similarity | 🦜️ LangChain, https://python.langchain.com/docs/how_to/semantic-chunker/
34. Mastering Document Chunking Strategies for Retrieval-Augmented ..., https://medium.com/@sahin.samia/mastering-document-chunking-strategies-for-retrieval-augmented-generation-rag-c9c16785efc7
35. Experiment with 5 Chunking Strategies via LangChain for LLM ..., https://medium.com/@zilliz_learn/experimenting-with-different-chunking-strategies-via-langchain-694a4bd9f7a5
36. Mastering RAG: Advanced Chunking Techniques for LLM Applications - Galileo AI, https://galileo.ai/blog/mastering-rag-advanced-chunking-techniques-for-llm-applications
37. Hybrid query - Azure AI Search - Learn Microsoft, https://learn.microsoft.com/en-us/azure/search/hybrid-search-how-to-query
38. How do hybrid approaches combine full-text and vector search? - Milvus, https://milvus.io/ai-quick-reference/how-do-hybrid-approaches-combine-fulltext-and-vector-search
39. Hybrid search scoring (RRF) - Azure AI Search | Microsoft Learn, https://learn.microsoft.com/en-us/azure/search/hybrid-search-ranking
40. Reciprocal Rank Fusion (RRF) explained in 4 mins — How to score results form multiple retrieval methods in RAG | by Deval Shah | Medium, https://medium.com/@devalshah1619/mathematical-intuition-behind-reciprocal-rank-fusion-rrf-explained-in-2-mins-002df0cc5e2a
41. Mastering Hybrid Search in MyScale: A Comprehensive Guide - Medium, https://medium.com/@myscale/mastering-hybrid-search-in-myscale-a-comprehensive-guide-504be8cb70e8
42. Introducing reciprocal rank fusion for hybrid search - OpenSearch, https://opensearch.org/blog/introducing-reciprocal-rank-fusion-hybrid-search/
43. Hybrid Search in Cosmos DB Database (Preview) - Microsoft Fabric, https://learn.microsoft.com/en-us/fabric/database/cosmos-db/hybrid-search
44. Hybrid Search in RAG — Concept of Weighted Reciprocal Rank ..., https://medium.com/@shubhamsarkar996/hybrid-search-in-rag-concept-of-weighted-reciprocal-rank-fusion-rrf-part-1-ae570d9c1879
45. The multi-stage architecture of modern information retrieval systems ..., https://www.researchgate.net/figure/The-multi-stage-architecture-of-modern-information-retrieval-systems_fig1_349914311
46. Reranking in Semantic Search - Qdrant, https://qdrant.tech/documentation/search-precision/reranking-semantic-search/
47. Improving Vector Search - Reranking with PostgresML and LlamaIndex, https://www.llamaindex.ai/blog/improving-vector-search-reranking-with-postgresml-and-llamaindex
48. Mastering RAG: How to Select A Reranking Model - Galileo AI, https://galileo.ai/blog/mastering-rag-how-to-select-a-reranking-model
49. Re-ranking in Retrieval Augmented Generation: How to Use Re-rankers in RAG - Chitika, https://www.chitika.com/re-ranking-in-retrieval-augmented-generation-how-to-use-re-rankers-in-rag/
50. What is Hybrid Search?. There is not a single definition of… | by ..., https://medium.com/@qdrant/what-is-hybrid-search-2a0c30d0f3d2
51. What Is a Data Flow Diagram (DFD)? - IBM, https://www.ibm.com/think/topics/data-flow-diagram
52. How to Build a RAG Pipeline: A Step-by-Step Guide - Meilisearch, https://www.meilisearch.com/blog/how-to-build-a-rag-pipepline
53. langchain-rag-techniques/Rerank-Fusion-Ensemble-Hybrid-Search.ipynb at main - GitHub, https://github.com/edumunozsala/langchain-rag-techniques/blob/main/Rerank-Fusion-Ensemble-Hybrid-Search.ipynb
54. How to Build a Better RAG System: Smart Hybrid Search for Tables ..., https://medium.com/@maksimov.dmitry.m/how-to-build-a-better-rag-system-smart-hybrid-search-for-tables-7bbea69a31f2
55. 5 Minute RAG with Qdrant and DeepSeek - Qdrant, https://qdrant.tech/documentation/rag-deepseek/
56. Qdrant - ️ LangChain, https://python.langchain.com/docs/integrations/vectorstores/qdrant/
57. How to build a RAG system (with Meilisearch), https://www.meilisearch.com/blog/how-to-build-rag
58. My Journey into Hybrid Search. BGE-M3 & Qdrant : r/vectordatabase - Reddit, https://www.reddit.com/r/vectordatabase/comments/1jo9jtx/my_journey_into_hybrid_search_bgem3_qdrant/
59. Examples - Qdrant, https://qdrant.tech/documentation/examples/