벡터 데이터베이스 선택 기준 — 무엇을 보고 고를까

RAG나 추천·검색 기능을 붙이려고 하면 곧장 부딪히는 질문이 “벡터 데이터베이스를 무엇으로 고르냐”입니다. 후보는 전용 벡터 DB부터 기존 관계형 DB의 확장 기능까지 다양하고, 저마다 강점을 내세웁니다. 하지만 선택의 핵심은 제품의 화려함이 아니라, 내 데이터 규모·요구 지연·필터링과 하이브리드 검색의 필요·운영 인력이라는 몇 가지 축에 내 상황을 대입하는 일입니다. 이 글에서는 벡터 DB가 정확히 무슨 일을 하는지, 무엇을 기준으로 비교해야 하는지, HNSW 같은 인덱스가 왜 필요한지, 그리고 작은 사이트라면 어떻게 현실적으로 시작하면 좋을지를 정리합니다.

벡터 데이터베이스가 하는 일

벡터 데이터베이스는 임베딩 모델이 만든 고차원 벡터를 저장하고, 주어진 질의 벡터와 가장 가까운 벡터들을 빠르게 찾아 주는 시스템입니다. 여기서 “가깝다”는 것은 코사인 유사도나 내적, 유클리드 거리 같은 척도로 정의됩니다. 핵심 연산은 최근접 이웃 탐색(nearest neighbor search)인데, 수백만~수억 개의 벡터를 일일이 비교하면 너무 느리기 때문에, 정확도를 약간 양보하고 속도를 크게 얻는 근사 최근접 이웃(ANN) 알고리즘을 씁니다.

전통적인 관계형 DB가 “정확히 일치하는 행”을 찾는 데 최적화돼 있다면, 벡터 DB는 “의미적으로 비슷한 항목”을 찾는 데 최적화돼 있습니다. 그래서 키워드가 정확히 겹치지 않아도 뜻이 통하는 문서를 찾아낼 수 있고, 이것이 RAG·시맨틱 검색·추천의 기반이 됩니다. 다만 의미 검색만으로는 정확한 코드명이나 고유명사 매칭에 약해, 뒤에서 설명할 하이브리드 검색으로 보완하는 경우가 많습니다.

선택 기준 1 — 데이터 규모와 성장 속도

가장 먼저 따질 것은 저장할 벡터의 개수와, 앞으로의 증가 추세입니다. 벡터 수가 수만~수십만 개 수준이라면 사실 전용 벡터 DB가 없어도 됩니다. 메모리에 올려 라이브러리로 검색하거나, 이미 쓰고 있는 관계형 DB의 벡터 확장으로 충분합니다. 반면 수천만~수억 개로 커지면 인덱스 구조, 메모리 사용량, 샤딩·분산 지원이 본격적으로 중요해집니다.

벡터 하나가 차지하는 메모리도 무시할 수 없습니다. 차원 수가 클수록 벡터당 메모리가 늘어, 같은 개수라도 임베딩 차원에 따라 필요한 자원이 크게 달라집니다. 규모를 추산할 때는 “벡터 개수 × 차원 × 자료형 크기”를 대략 계산해 보고, 인덱스가 추가로 차지하는 메모리까지 감안해야 합니다. 증가 속도가 빠른 서비스라면, 지금 당장 맞는 도구보다 1~2년 뒤 규모를 감당할 수 있는지를 함께 보는 편이 안전합니다.

선택 기준 2 — 요구 지연과 처리량

같은 검색이라도 실시간 챗봇 응답에 쓰는지, 야간 배치 분석에 쓰는지에 따라 요구 지연이 다릅니다. 사용자가 기다리는 대화형 기능이라면 검색 단계의 지연을 수십 밀리초 수준으로 잡아야 전체 응답이 쾌적합니다. ANN 인덱스는 이 지연을 좌우하는 설정값이 있어, 정확도와 속도를 저울질해 조정합니다.

처리량(초당 질의 수)도 중요합니다. 동시 접속이 많은 서비스라면 단일 노드 성능뿐 아니라 수평 확장과 복제 지원을 봐야 합니다. 검색 지연만 보고 골랐다가, 트래픽이 몰릴 때 처리량 한계에 부딪히는 경우가 흔합니다. 벤치마크 수치는 데이터 분포·차원·인덱스 설정에 크게 좌우되므로, 공개된 숫자보다 내 데이터로 직접 측정한 결과를 신뢰하는 편이 정확합니다.

선택 기준 3 — 메타데이터 필터링과 하이브리드 검색

실무에서 순수 벡터 검색만으로 끝나는 경우는 드뭅니다. “최근 1년 문서 중에서”, “특정 카테고리 안에서”처럼 메타데이터로 후보를 좁히는 필터링이 거의 항상 필요합니다. 여기서 중요한 것은 필터를 벡터 검색 전에 적용하느냐(pre-filtering) 후에 적용하느냐(post-filtering)입니다. 사후 필터링은 검색한 결과를 거른 뒤 남는 게 너무 적어질 수 있고, 사전 필터링은 후보를 정확히 좁히지만 인덱스 구조상 구현이 까다롭습니다. 후보 DB가 이 필터링을 어떻게 처리하는지 반드시 확인해야 합니다.

하이브리드 검색은 의미 기반 벡터 검색과 키워드 기반 검색(예: BM25)을 결합하는 기법입니다. 의미 검색은 뜻이 통하는 문서를 잘 찾지만 정확한 제품명·코드·숫자 매칭에 약하고, 키워드 검색은 그 반대입니다. 둘을 합쳐 점수를 섞으면 두 약점을 서로 메웁니다. 한국어처럼 형태소 처리가 중요한 언어에서는 키워드 쪽 토크나이징 품질도 함께 따져야 합니다. 하이브리드 검색을 내장 지원하는지, 아니면 직접 두 검색을 합쳐야 하는지가 선택의 갈림길이 됩니다.

인덱스의 원리 — HNSW와 그 친구들

벡터 DB의 성능은 어떤 ANN 인덱스를 쓰느냐에 크게 좌우됩니다. 대표적인 방식 몇 가지의 개념만 짚어 보겠습니다.

HNSW(계층적 탐색 가능한 작은 세계 그래프)

벡터들을 노드로 보고 가까운 것끼리 이어 다층 그래프를 만든 뒤, 위층에서 대략적인 위치를 빠르게 좁히고 아래층으로 내려가며 정밀하게 탐색하는 방식입니다. 검색 속도와 정확도의 균형이 좋아 가장 널리 쓰입니다. 다만 그래프를 메모리에 올려야 해 메모리 사용량이 큰 편이고, 그래프를 만드는 색인 단계가 무겁습니다. 탐색 폭을 키우면 정확도가 오르고 속도는 떨어지는 식의 조절 손잡이가 있습니다.

IVF(역색인 파일)

벡터 공간을 여러 군집으로 나눠 두고, 질의가 들어오면 가까운 몇 개 군집만 뒤지는 방식입니다. 탐색할 군집 수를 줄이면 빨라지고 정확도는 내려갑니다. 대규모 데이터에서 메모리 효율이 좋은 편이라, 양자화(PQ 등)와 결합해 메모리를 더 줄이는 조합도 자주 씁니다.

양자화(Quantization)

벡터를 더 적은 비트로 압축해 저장·검색 비용을 낮추는 기법입니다. 메모리를 크게 아끼지만 정밀도가 일부 손실되므로, 대규모에서 비용을 줄이려는 목적에 맞습니다. 인덱스 종류와 설정은 정확도·속도·메모리의 삼각 트레이드오프이며, 정답은 데이터 규모와 요구 지연에 따라 달라집니다.

관리형 vs 셀프호스트 — 운영비의 갈림길

같은 기능이라도 누가 운영하느냐에 따라 비용 구조가 완전히 달라집니다. 관리형(SaaS) 서비스는 인프라·확장·장애 대응을 대신 해 주므로 초기 진입이 빠르고 운영 인력이 적게 듭니다. 대신 사용량에 따라 비용이 붙고, 데이터가 외부에 저장된다는 점에서 보안·규제 요건을 확인해야 합니다. 셀프호스트는 인프라 비용만 들고 데이터를 내부에 둘 수 있지만, 확장·백업·모니터링·버전 업그레이드를 직접 책임져야 합니다.

비용을 비교할 때는 표면 단가뿐 아니라 임베딩 차원에 따른 저장량, 트래픽에 따른 질의 비용, 재색인 빈도까지 함께 추산해야 실제 운영비에 가깝습니다. 구체적인 요금과 무료 한도는 시점마다 바뀌므로 각 서비스의 공식 가격 페이지를 확인하는 것이 정확합니다.

작은 사이트의 현실적인 선택

개인 또는 소규모 팀이 RAG·시맨틱 검색을 붙이는 단계라면, 처음부터 대규모를 가정한 전용 솔루션은 과합니다. 다음 순서로 단계를 밟는 편이 합리적입니다.

• 1단계 — 이미 쓰는 DB 확장: 데이터가 적고 운영 DB가 있다면 그 DB의 벡터 확장으로 시작합니다. 스택이 늘지 않아 가장 가볍습니다. 예를 들어 PostgreSQL이라면 pgvector 공식 저장소의 설치·인덱스 가이드를 참고할 수 있습니다.
• 2단계 — 관리형 서비스: 데이터가 늘고 필터링·하이브리드 검색이 필요해지면, 운영 부담이 적은 관리형으로 옮겨 출시 속도를 확보합니다.
• 3단계 — 셀프호스트 전용 DB: 규모가 크고 비용·보안 요건이 분명해지면, 인덱스 설정까지 통제하는 셀프호스트로 전환합니다.

중요한 것은 처음 선택이 영구적이지 않다는 점입니다. 청킹과 임베딩 모델을 일관되게 관리해 두면, 벡터 DB는 나중에 교체하기 비교적 수월한 계층입니다. 그러니 지금 단계에서 과하게 키우기보다, 현재 규모에 맞는 가장 단순한 선택을 하고 측정하며 옮겨 가는 편이 낫습니다.

도입 전 점검 체크리스트

• 현재 벡터 개수와 1~2년 뒤 예상 규모를 추산했는가
• 실시간 응답인지 배치인지에 맞춰 요구 지연·처리량을 정의했는가
• 메타데이터 필터링의 사전/사후 방식과 한국어 하이브리드 검색 지원을 확인했는가
• 문서 갱신·삭제가 잦다면 실시간 upsert/delete 비용을 점검했는가
• 관리형과 셀프호스트의 총비용(저장·질의·인건비)을 함께 비교했는가
• 데이터 위치에 대한 보안·규제 요건을 확인했는가
• 내 데이터로 직접 벤치마크해 공개 수치를 검증했는가

자주 묻는 질문

꼭 전용 벡터 DB가 있어야 하나요?

아닙니다. 데이터가 수십만 건 이하이고 이미 관계형 DB를 쓰고 있다면 pgvector 같은 확장으로 충분한 경우가 많습니다. 규모와 요구 성능이 분명히 한계에 닿았을 때 전용 솔루션으로 옮겨도 됩니다.

HNSW와 IVF 중 무엇이 더 나은가요?

상황에 따라 다릅니다. HNSW는 속도·정확도 균형이 좋지만 메모리를 많이 쓰고, IVF는 대규모에서 메모리 효율이 좋은 편이며 양자화와 결합해 비용을 더 줄일 수 있습니다. 데이터 규모와 요구 지연으로 결정하는 것이 맞습니다.

하이브리드 검색은 항상 필요한가요?

정확한 고유명사·코드·숫자 매칭이 중요한 도메인이라면 큰 도움이 됩니다. 순수 의미 검색만으로 충분한지 먼저 평가해 보고, 키워드 매칭에서 자주 실패한다면 하이브리드를 도입하세요. 한국어는 키워드 쪽 토크나이징 품질도 함께 봐야 합니다.

관리형이 셀프호스트보다 비싼가요?

규모와 트래픽에 따라 다릅니다. 소규모에서는 인건비를 아끼는 관리형이 총비용에서 유리할 수 있고, 대규모에서는 셀프호스트가 단가에서 유리해지는 지점이 옵니다. 저장·질의·인건비를 함께 추산해 비교해야 하며, 단가는 공식 가격 페이지를 확인하세요.

나중에 다른 벡터 DB로 옮기기 쉬운가요?

청킹과 임베딩 모델을 일관되게 관리해 두었다면 비교적 수월합니다. 벡터 자체는 임베딩 기준이 같으면 재사용할 수 있고, 주로 적재·인덱싱 파이프라인만 다시 맞추면 됩니다. 반대로 임베딩 모델을 바꾸는 변경은 전체 재색인을 동반합니다.

이 글은 벡터 데이터베이스를 선택할 때 고려할 일반적인 기준과 인덱스 원리를 정리한 기술 참고 자료이며, 특정 제품의 우열을 단정하지 않습니다. 각 솔루션의 기능 지원 범위, 성능, 요금, 무료 한도는 버전과 시점에 따라 달라지므로, 도입 전에 해당 제품의 공식 문서와 가격 정책을 확인하고 내 데이터로 직접 벤치마크하시기 바랍니다.