인메모리 벡터 검색에서 Elasticsearch로

출발점

• DB 전수 스캔을 인메모리 정규화 벡터 검색으로 전환
• 청크 20,002개 기준 검색 지연 6,458ms → 25ms

문제

• 데이터 증가에 비례하는 힙 사용량과 선형 검색 비용
• 인스턴스별 인덱스 사본과 단일 relay 마킹으로 발생하는 다중 인스턴스 정합성 결함
• 재시작마다 필요한 전체 인덱스 재구축

선택

• 공유 벡터 저장소와 BM25 확장성을 위한 Elasticsearch kNN — 채택
• 도메인 의존성을 차단하기 위한 자체 VectorIndex 포트와 어댑터 유지
• 20k rebuild OOM을 막기 위한 500건 단위 bulk 처리

검증 방법

• 같은 20,002개 청크를 nomic-embed-text로 임베딩해 인메모리와 Elasticsearch 인덱스에 각각 적재
• 답이 있는 고정 질문 30개를 두 구현에 동일하게 입력하고 기대 문서가 상위 4개에 포함되는지 비교
• 검색 어댑터 호출 전후 시간을 기록해 평균 지연을 비교하고, 애플리케이션 재시작 뒤 전체 rebuild 필요 여부와 소요 시간을 측정

검증 결과

지표	인메모리	Elasticsearch
상위 4개 검색 결과 적중률	93.3%	90.0%
검색 지연	22.8ms	12.8ms
재시작 후 rebuild	6.3s	0s

한계

• Elasticsearch JVM 힙과 운영 복잡도 증가
• refresh 계층으로 반영 지연 127ms → 879ms 증가
• 정확도와 지연을 함께 조정해야 하는 num_candidates 설정