검색(retrieval) 인프라 & 벡터 스토어

벡터 검색 개념 증명(proof-of-concept)과 실제 쿼리 부하에서도 견디는 프로덕션 시스템은 완전히 다른 엔지니어링 문제입니다. 저희는 여러분의 RAG 파이프라인, 에이전트 워크플로, 또는 시맨틱 검색 제품 아래에 자리 잡는 검색(retrieval) 인프라 계층 — 벡터 엔진, 이를 공급하는 임베딩 파이프라인, 이를 건강하게 유지하는 인덱스 수명 주기 관리, 그리고 사용자가 알아차리기 전에 품질 저하를 포착하는 관측 가능성(observability) 스택 — 을 구축하고 운영합니다.

저희의 실무는 다음 엔진들에 대해 벤더 중립적입니다 Qdrant, Milvus, Weaviate, pgvector, 그리고 Elasticsearch kNN. 그리고 어느 것을 권장할지는 여러분의 벡터 수, 쿼리 패턴, 멀티테넌시 요구사항, 그리고 운영 역량에 따라 달라집니다.

5만 벡터 데모에서 2억 벡터 프로덕션까지

데모와 프로덕션 시스템 사이의 간극은 거의 전적으로 인프라 문제입니다. 데모는 5만 벡터 를 Pinecone에 로드하고, 코사인 유사도 쿼리를 실행하여 40ms만에 결과를 반환합니다. 프로덕션은 그것과 전혀 다릅니다.

• 2억 벡터 그리고 초당 500쿼리 를 지속적으로 처리
• 15개의 메타데이터 필터 차원 그리고 매시간 업데이트되는 문서
• 엄격한 테넌트 격리 하에 하나의 클러스터를 공유하는 세 팀

그 규모에서는 HNSW 컴팩션 스파이크가 P99를 800ms로 폭증시키고, 점진적 업데이트 일주일 후 재현율이 소리 없이 저하되며, 임베딩 파이프라인이 문서 변경 속도를 따라잡지 못합니다. 바로 이 지점이 저희가 일하는 곳입니다.

엔진 선택은 브랜드 결정이 아니라 벤치마킹 작업입니다

모든 벤더가 업계 최고의 성능을 주장하지만, 벤치마크는 더 미묘한 이야기를 들려줍니다. 저희는 기능 매트릭스에서 데이터베이스를 고르지 않습니다 — 여러분의 실제 벡터를 로드하고, 여러분의 실제 메타데이터 필터로 여러분의 실제 쿼리를 실행하며, 동시 부하 하에서 P50/P95/P99 지연 시간과 함께 운영상 관련 있는 k 값에서의 재현율을 측정합니다.

결과는 종종 벤더 마케팅과 상반됩니다. Pinecone의 서버리스 티어는 지속적인 고 QPS 워크로드가 읽기 단위 비용을 자체 호스팅 손익분기점 너머로 밀어 올릴 때까지는 비용 효율적으로 보이고, pgvector는 반복 스캔이 필터링 검색 격차를 메우기 전까지는 제한적으로 보입니다.

임베딩 파이프라인이야말로 프로덕션 검색이 실제로 무너지는 곳입니다

팀들은 60% 의 벡터 검색 엔지니어링 노력을 스토어가 아닌 파이프라인에 씁니다. 파이프라인은 문서 수집, 청킹, 임베딩 모델 추론, 문서 업데이트 시 점진적 재인덱싱, 그리고 메타데이터 전파를 처리합니다 — 그리고 모든 단계에는 검색 품질을 소리 없이 저하시키는 실패 모드가 있습니다.

• 오래된 지식(Stale knowledge) — 두 번째로 흔한 프로덕션 RAG 실패입니다. Confluence에서 문서가 업데이트되어도 인덱스는 여전히 옛 임베딩을 제공합니다. 해결책은 야간 배치 재인덱싱이 아니라, 점진적으로 재임베딩하는 변경 데이터 캡처(CDC) 트리거입니다.
• 유령 문서(Ghost documents) — 원본 문서는 삭제되었으나 그 벡터가 남아, 더 이상 존재하지 않는 콘텐츠에 대한 결과를 반환합니다. 분리된 아키텍처에서는 원천(source-of-truth) 시스템과 벡터 스토어에 걸친 원자적 트랜잭션이 거의 불가능하기 때문에, 저희는 고아 벡터(orphaned vectors)를 탐지하고 제거하는 조정(reconciliation) 계층을 구축합니다.

임베딩 모델 선택은 대부분의 팀이 깨닫는 것보다 더 중요하며, 나중에 바꾸는 것은 비용이 큽니다: 800만 문서 를 text-embedding-ada-002 에서 text-embedding-3-large 로 업그레이드할 때 재임베딩하는 것은 수일간의 컴퓨팅 비용이 들고, 다운타임을 피하기 위한 이중 쓰기(dual-write) 인프라가 필요합니다. 저희는 여러분이 확정하기 전에 도메인 특화 쿼리 세트에 대해 모델을 평가합니다.

• Cohere embed-v4 — 다국어 검색을 선도합니다: 100만 토큰당 $0.01 로 100개 이상의 언어에서.
• Nomic Embed v2 — 1억 3,700만 파라미터로 CPU에서 실행되며, 시장에서 최고의 품질 대비 크기 비율을 갖습니다.
• OpenAI text-embedding-3-large — 강력한 만능형 모델.

올바른 선택은 여러분의 언어 구성, 지연 시간 요구사항, 그리고 API 의존성을 수용할 수 있는지 아니면 온프레미스 추론이 필요한지에 달려 있습니다.

인덱스 수명 주기: 아무도 경고해주지 않는 운영상의 문제

HNSW 인덱스는 저하됩니다 — 버그가 아니라 아키텍처적 현실입니다. 1억 6천만 벡터에서 전체 HNSW 재구축은 3~6시간이 걸립니다. 점진적 업데이트는 그래프 구조를 최적이 아니게 만들고 시간이 지나며 재현율을 침식합니다. 컴팩션 이벤트는 쿼리 지연 시간을 급증시키며, 모든 업서트, 삭제, 세그먼트 병합은 서브 인덱스 재구축을 유발해 쿼리 처리 대신 유지보수에 CPU를 소모합니다. 이 트레이드오프는 피할 수 없습니다: 0.8에서 0.95 재현율 로 끌어올리면 HNSW 지연 시간이 대략 31%증가합니다.

저희는 품질 손실 없이 지속적인 수집을 흡수하는 수명 주기 관리를 설계합니다:

• 블루-그린 인덱스 교체(Blue-green index rotation) — 별도 인프라에서 재구축하고 다운타임 없이 원자적으로 교체합니다.
• 자동화된 재현율 검증 게이트 — 모든 주요 작업 후 골든 쿼리 세트를 현재 인덱스와 비교하여, 재현율이 임계값 아래로 떨어지면 교체가 일어나지 않습니다.
• Qdrant와 Elasticsearch에서의 GPU 가속 HNSW 구축 은 재구축 시간을 한 자릿수(order of magnitude) 단축하지만, 언제 재구축하고, 어떻게 검증하며, 어떻게 교체할지의 오케스트레이션은 맞춤 엔지니어링입니다.

양자화는 이를 한층 더 확장합니다. Qdrant는 이제 1.5비트, 2비트, 그리고 비대칭 양자화를 제공하며, Elasticsearch BBQ는 float32 대비 힙을 95% 이상줄입니다. 이는 메모리를 절약하고 처리량을 높이지만, 각 방식은 서로 다른 데이터 분포에 대해 서로 다른 재현율 프로파일을 갖습니다 — 그래서 저희는 프로덕션에 양자화를 배포하기 전에 여러분의 특정 벡터에 대한 재현율 영향을 특성화합니다.

실제 규모에서의 멀티테넌시와 격리

다음을 서비스하는 플랫폼 팀은: 200개 이상의 내부 ML 팀, 또는 수천 개의 고객 테넌트를 가진 SaaS 제품은, 격리를 보장하는 인프라가 필요합니다: 테넌트 A의 쿼리는 절대 테넌트 B의 데이터를 반환해서는 안 되고, 감사 로그는 모든 쿼리를 테넌트 신원까지 추적해야 하며, 유휴(cold) 테넌트는 활성(hot) 테넌트가 필요로 하는 자원을 소비해서는 안 됩니다.

• Weaviate — 테넌트 상태(ACTIVE, INACTIVE, S3로 OFFLOADED)를 갖춘 테넌트당 단일 샤드(one-shard-per-tenant) 모델은 높은 테넌트 수 배포를 위한 가장 성숙한 구현입니다.
• Milvus — 데이터베이스, 컬렉션, 파티션, 또는 파티션 키 수준에서의 격리를 지원하여, 여러분의 규정 준수 요구사항에 세분성을 맞춥니다.

둘 다 규모에서 맞춤 오케스트레이션을 요구합니다 — 테넌트 프로비저닝, 상태 전환, 쿼터 관리, 그리고 테넌트 간 유출 탐지는 데이터베이스 자체가 처리하지 않습니다. 저희는 다음을 요구하는 규제 대상 배포에서 멀티테넌시를 관리 가능하게 만드는 운영 계층을 구축합니다: SOC 2 또는 ISO 27001 규정 준수.

에이전트 워크플로가 인프라 요구사항을 재편하고 있습니다

에이전트형 AI 물결은 벡터 스토어가 해야 할 일을 바꿉니다. 정적 RAG는 고정된 코퍼스에 대해 문서를 검색합니다. 에이전트 워크플로는 다음을 요구합니다: 일화 기억(episodic memory) (대화 이력과 중간 추론), 시맨틱 검색 (대규모 문서 코퍼스에 대한), 그리고 사용자 프로필 계층 — 종종 단일 에이전트 단계에서 이 세 가지를 모두 건드립니다. 400ms 미만 이라는 지연 시간 요구사항은 배치 RAG보다 더 빡빡하며, ACID 트랜잭션 지원은 부분 쓰기 없이 상태를 업데이트하는 다단계 에이전트에게 필수가 되고 있습니다.

단일 벡터 데이터베이스로는 세 가지 기억 계층을 모두 잘 처리할 수 없으므로, 팀들은 멀티 스토어 아키텍처를 조립합니다: Redis 는 세션 상태를, Qdrant 또는 Milvus 는 시맨틱 검색을, 그리고 그래프 데이터베이스 는 관계 추적을 담당합니다. Oracle의 Unified Memory Core (2026년 3월) 는 벡터, JSON, 그래프, 관계형, 공간 쿼리를 하나의 엔진으로 수렴시키려 시도합니다. 저희는 에이전트형 시스템을 위한 검색 계층을 설계합니다 — 어떤 스토어가 어떤 기억 유형을 처리할지, 쿼리가 스토어 전반에 어떻게 라우팅될지, 그리고 에이전트가 단일 추론 단계에서 여러 백엔드에 걸쳐 상태를 업데이트할 때 일관성이 어떻게 유지될지를.

저희가 제공하는 것

모든 프로젝트는 다음으로 시작합니다: 벤치마킹 단계: 저희는 여러분의 벡터를 로드하고, 여러분의 쿼리를 실행하며, 정량화된 엔진 권장 사항을 만들어냅니다. 그로부터 저희는 프로덕션 인프라를 구축합니다:

• ​ 벡터 스토어 클러스터, 용량 계획과 스케일링 런북을 포함.
• ​ 임베딩 파이프라인, CDC 트리거 점진적 재인덱싱과 모델 버전 관리를 포함.
• ​ 인덱스 수명 주기 자동화, 블루-그린 교체와 재현율 검증 게이트를 포함.
• ​ 멀티테넌시 오케스트레이션 계층, 테넌트 격리가 필요할 때.
• ​ 관측 가능성 스택, 드리프트 탐지, 재현율 회귀 알림, 그리고 P95/P99 지연 시간 모니터링을 포함.
• 마이그레이션 도구 엔진 간 이동하는 팀을 위해, 전체 재임베딩을 강제하는 대신 차원이 일치하는 경우 임베딩을 보존하도록 중간 Parquet 형식을 사용합니다.

저희는 모든 프로젝트를 다음과 함께 명시적으로 산정합니다: 월간 인프라 비용 예측, 그래서 여러분은 확정하기 전에 프로덕션이 얼마나 들지 알 수 있습니다.