KISDI

2026-07-13 · 정우진 (수석연구원)

벡터 검색은 어떻게 동작하나요? HNSW·IVF 인덱싱과 유사도 검색 내부 원리 완전 가이드

#벡터검색#벡터데이터베이스#hnsw#ivf#임베딩#유사도검색#rag#양자화#하이브리드검색

벡터 검색(Vector Search)은 텍스트나 이미지를 숫자 배열인 임베딩으로 바꾼 뒤, 수백만~수십억 개의 벡터 중에서 질의와 의미가 가장 가까운 것을 찾아내는 기술입니다. 핵심은 두 가지인데요. 거리를 재는 유사도 지표(코사인·내적)와, 전수 비교 없이 근사적으로 빠르게 찾는 인덱싱 알고리즘(HNSW·IVF·양자화)입니다. 이 글은 벡터 데이터베이스가 "무엇인가"보다 "내부에서 어떻게 검색이 일어나는가"에 초점을 맞춘 기술 가이드입니다. RAG의 검색 품질과 비용은 결국 이 인덱스 설계에서 갈립니다.

목차

현장에서 마주친 검색 지연 문제

작년에 사내 문서 300만 건을 다루는 RAG 챗봇을 만들 때 일입니다. 처음엔 단순하게 접근했는데요. 모든 문서를 임베딩으로 바꿔 배열에 넣고, 질문이 들어오면 300만 개 벡터와 하나하나 코사인 거리를 계산했습니다. 정확도는 완벽했습니다. 이론상 가장 가까운 문서를 무조건찾아내니까요. 문제는 속도였습니다. 질문 한 번에 4초가 넘게 걸렸고, 동시 사용자가 열 명만 붙어도 서버가 버티질 못했어요.

원인은 명확했습니다. 전수 비교(brute-force)는 벡터 개수가 늘수록 시간이 선형으로 증가합니다. 300만 개면 300만 번, 3천만 개면 3천만 번을 계산해야 하죠. 여기서 배운 게 있는데요. 벡터 검색의 진짜 기술은 "정확한 답"이 아니라 "충분히 정확한 답을 극도로 빠르게" 찾는 데 있다는 점이었습니다. 근사 최근접 이웃(ANN, Approximate Nearest Neighbor) 인덱스를 도입하자 같은 질의가 40밀리초로 줄었습니다. 정확도(recall)는 98% 수준으로 살짝 떨어졌지만, 실사용에서는 체감이 거의 없었습니다. 이 트레이드오프를 이해하는 게 벡터 검색의 출발점입니다.

돌이켜 보면 초기 실패의 진짜 원인은 알고리즘 지식의 부재였습니다. 인덱스를 그저 "빠르게 해주는 옵션" 정도로만 여겼는데, 실제로는 인덱스 종류와 파라미터 하나하나가 지연 시간·정확도·메모리·비용을 동시에 결정하는 설계 요소였습니다. 특히 RAG 시스템에서는 이 검색 단계가 답변 품질을 좌우합니다. 검색이 엉뚱한 문서를 물어오면 아무리 좋은 언어 모델을 붙여도 헛소리를 내놓으니까요. 그래서 이 글에서는 벡터 검색의 내부를 하나씩 뜯어보려 합니다.

벡터 검색이란 무엇이고 왜 필요한가

전통적인 데이터베이스 검색은 정확히 일치하는 값을 찾습니다. "사과"를 검색하면 "사과"라는 글자가 든 행만 나옵니다. "능금"이나 "apple"은 걸러지죠. 키워드 기반이라 의미를 모릅니다. 반면 사람은 "능금"과 "사과"가 같은 것임을 압니다. 이 의미의 간극을 메우려는 게 벡터 검색입니다.

임베딩 모델은 단어·문장·이미지를 고차원 공간의 좌표로 바꿉니다. 예를 들어 문장 하나가 1,536개 숫자로 된 벡터가 되는데요. 이 공간에서는 의미가 비슷한 것들이 물리적으로 가까이 모입니다. "강아지"와 "반려견"은 붙어 있고, "자동차"는 멀리 떨어져 있죠. 그래서 질의 문장을 같은 방식으로 벡터화한 뒤, 가장 가까운 이웃 벡터들을 찾으면 곧 "의미가 가장 비슷한 문서"를 찾는 셈이 됩니다.

문제는 규모입니다. 기업 데이터는 보통 수백만에서 수십억 벡터인데다, 각 벡터가 수백~수천 차원입니다. 이걸 전수 비교하면 앞서 겪은 것처럼 느려집니다. 그래서 벡터 데이터베이스는 벡터를 그냥 저장만 하는 게 아니라, 검색을 빠르게 하는 특수 인덱스 구조로 미리 정리해 둡니다. 이 인덱스가 벡터 DB의 심장입니다. 벡터 검색을 RAG 파이프라인에 왜 넣는지, 임베딩이 무엇인지에 대한 개괄은 아래 "같이 읽으면 좋은 것들"의 벡터 데이터베이스 개요 글에서 더 폭넓게 다루고 있습니다.

유사도는 어떻게 계산하나: 코사인과 내적

"가깝다"를 수치로 정의해야 검색이 가능합니다. 벡터 검색에서 가장 많이 쓰는 지표는 세 가지입니다.

코사인 유사도(Cosine Similarity)는 두 벡터가 이루는 각도를 봅니다. 방향이 같으면 1, 직각이면 0, 반대면 -1입니다. 벡터의 길이(크기)는 무시하고 방향만 비교하기 때문에, 문서 길이가 제각각인 텍스트검색에서 특히 안정적입니다. 대부분의 임베딩 기반 시맨틱 검색이 코사인을 기본값으로 씁니다.

내적(Dot Product)은 방향과 크기를 함께 반영합니다. 임베딩을 정규화(길이를 1로 맞춤)해 두면 내적과 코사인이 수학적으로 같아지는데요. 그래서 많은 시스템이 벡터를 미리 정규화한 뒤 계산이 더 가벼운 내적으로 검색합니다. OpenAI 같은 일부 모델은 이미 정규화된 임베딩을 내보내서, 내적만으로 코사인 결과를 그대로 얻을 수 있습니다.

유클리드 거리(L2)는 두 점 사이의 직선 거리입니다. 이미지나 좌표처럼 절대적 위치가 의미 있는 데이터에서 유용합니다.

여기서 실무 팁이 하나 있는데요. 임베딩 모델이 권장하는 지표를 반드시 확인해야 합니다. 코사인용으로 학습된 모델에 유클리드를 쓰면 검색 품질이 눈에 띄게 떨어집니다. 지표 선택은 취향이 아니라 모델 스펙에 종속된 결정입니다.

HNSW와 IVF: 인덱싱 알고리즘의 내부

이제 핵심입니다. 전수 비교를 피하면서도 정확한 이웃을 찾는 대표적인 두 알고리즘을 봅시다.

HNSW(Hierarchical Navigable Small World)는 벡터들을 그래프로 연결합니다. 각 벡터가 노드가 되고, 의미가 비슷한 벡터끼리 간선으로 이어집니다. 특이한 건 여러 층(layer)으로 쌓는다는 점인데요. 위층은 노드가 드문드문하고 간선이 길어서 먼 거리를 빠르게 건너뛰고, 아래층으로 갈수록 촘촘해집니다. 검색은 맨 위층에서 대략적인 방향을 잡고, 층을 내려가며 점점 정밀하게 목표에 접근합니다. 마치 지도에서 대륙 → 도시 → 골목 순으로 좁혀 가는 방식이죠. 덕분에 수십억 벡터에서도 로그 시간에 가깝게 답을 찾습니다. 정확도와 속도가 매우 뛰어나 2026년 현재 사실상 표준입니다.

단점은 메모리입니다. HNSW는 기본적으로 인메모리 인덱스라서, 그래프 전체를 RAM에 올려야 최고 성능이 나옵니다. 벡터가 많아지면 메모리 비용이 급증합니다. 튜닝 파라미터로는 노드당 간선 수를 정하는 M, 인덱스를 만들 때 탐색 폭을 정하는 ef_construction, 검색 시 탐색 폭인 ef_search가 있는데요. 값을 키우면 정확도가 오르지만 속도와 메모리를 내줍니다.

IVF(Inverted File Index)는 접근이 다릅니다. 먼저 전체 벡터를 군집화(클러스터링)해서 여러 개의 구역으로 나눕니다. 각 구역에는 대표점(centroid)이 있고요. 질의가 들어오면 모든 벡터를 뒤지는 대신, 질의와 가까운 몇 개 구역만 골라 그 안에서만 비교합니다. 도서관에서 책을 찾을 때 전체 서가가 아니라 해당 분류구역만 뒤지는 것과 같습니다. nprobe라는 파라미터로 몇 개 구역을 뒤질지 정하는데, 많이 뒤질수록 정확하지만 느려집니다. IVF는 디스크 기반으로도 동작해 메모리 부담이 HNSW보다 적어서, 초대규모 데이터에서 자주 쓰입니다.

정리하면 이렇습니다. 지연 시간과 정확도가 최우선이고 메모리 여유가 있으면 HNSW, 데이터가 극단적으로 크고 메모리를 아껴야 하면 IVF, 이렇게 나눠서 접근합니다. 실제로는 IVF에 HNSW를 결합한 하이브리드 인덱스도 널리 쓰입니다.

양자화로 메모리를 줄이는 법

벡터 DB 비용의 가장 큰 변수는 벤더가 아니라, 벡터 하나가 RAM에서 몇 바이트를 차지하느냐입니다. 여기서 양자화(Quantization)가 등장합니다. 원본 벡터를 더 적은 비트로 압축해 메모리를 절감하는 기법입니다.

스칼라 양자화(Scalar Quantization)는 32비트 실수를 8비트 정수로 줄입니다. 메모리가 약 4배 절약되고 정확도 손실은 작습니다. 곱 양자화(Product Quantization, PQ)는 벡터를 여러 조각으로 쪼갠 뒤 각 조각을 코드북으로 근사해, 4~8배까지 압축합니다. 가장 공격적인 건 이진 양자화(Binary Quantization)인데요. 각 차원을 0 또는 1로 만들어 최대 32배까지 줄입니다. 이 정도면 정확도가 꽤 떨어지지만, 압축본으로 후보를 빠르게 추린 뒤 원본으로 재순위(re-ranking)를 매기면 손실을 상당 부분 회복할 수 있습니다.

작년 프로젝트에서 이진 양자화 + 재순위 조합으로 인덱스 메모리를 5분의 1로 줄이면서도 최종 recall을 96%대로 지킨 경험이 있습니다. 클라우드 인스턴스를 한 단계 낮출 수 있어서 월 비용이 눈에띄게 내려갔고요. 규모가 커질수록 양자화는 선택이 아니라 필수에 가까워집니다.

제품 선택: pgvector부터 Milvus까지

2026년 기준 주요 제품을 인덱싱·운영 관점에서 정리하면 다음과 같습니다.

제품특징적합한 규모
pgvector기존 PostgreSQL에 확장으로 추가, 별도 인프라 불필요수백만 벡터 이하
QdrantRust 기반, 필터링·하이브리드 검색·양자화 강점, 단일 바이너리대부분의 프로덕션 RAG
Pinecone완전 관리형 SaaS, 수십억 벡터·재순위 내장운영 부담 최소화
Weaviate검색뿐 아니라 AI 파이프라인 전반 지향통합 플랫폼이 필요할 때
Milvus분산 아키텍처·GPU 인덱싱, 초대규모에 강함10억 벡터 이상

선택 기준은 규모와 운영 여력입니다. 이미 PostgreSQL을 쓰고 벡터가 500만 개 미만이면 pgvector로 충분한 경우가 많습니다. 별도 시스템을 두지 않아도 되니까요. 반대로 데이터가 수억을 넘고 GPU 가속이 필요하면 Milvus가 유리합니다. 운영 인력을 최소화하고 싶다면 완전 관리형인 Pinecone이, 필터가 많은 프로덕션 RAG를 단순하게 굴리고 싶다면 Qdrant가 2026년의 무난한 기본값으로 자주 꼽힙니다. 정답은 없고 워크로드에 달렸습니다.

실전 튜닝 4단계 가이드

처음 벡터 검색을 도입한다면 아래 순서를 권합니다.

1단계, 지표부터 맞춥니다. 사용하는 임베딩 모델의 문서를 열어 권장 유사도 지표를 확인하세요. 코사인이면 벡터를 정규화하고 내적으로 계산해 속도를 챙깁니다.

2단계, 인덱스를 고릅니다. 벡터가 수백만 이하면 HNSW로 시작하는 게 편합니다. 정확도가 높고 튜닝이 직관적입니다. 수억을 넘어가면 IVF나 IVF+PQ를 검토합니다.

3단계, recall을 측정합니다. 정답이 있는 평가용 질의 세트를 만들어 recall과 지연 시간을 함께 잽니다. ef_search나 nprobe를 조금씩 올리며 "정확도 대비 속도" 곡선을 그려 보세요. 감이 아니라 숫자로 결정해야 합니다.

4단계, 필요하면 양자화와 하이브리드를 더합니다. 메모리가 빠듯하면 스칼라·이진 양자화에 재순위를 붙이고, 키워드 정확도가 중요하면 BM25 같은 키워드 검색과 벡터 검색을 섞는 하이브리드 검색에 재순위 모델을 얹습니다. 2026년 프로덕션 RAG의 사실상 표준 구성입니다.

이 네 단계만 지켜도 "느리고 부정확한" 초기 실패의 대부분을 피할 수 있습니다.

하이브리드 검색과 2026 트렌드

순수 벡터 검색만으로는 부족한 순가니 있습니다. 예를 들어 제품 코드나 사람 이름처럼 정확히 일치해야 하는 키워드는 의미 기반 검색이 오히려 놓치기 쉽습니다. "A-2201"을 찾는데 의미가 비슷한 다른 코드를 물어오면 곤란하죠. 그래서 2026년 프로덕션 현장의 사실상 표준은 하이브리드 검색입니다. 키워드 정확도를 담당하는 희소 검색(BM25 등)과 의미를 담당하는 밀집 벡터 검색을 함께 돌린 뒤, 두 결과를 하나의 순위로 합칩니다. 이때 RRF(Reciprocal Rank Fusion) 같은 방식으로 순위를 융합하고, 그 위에 교차 인코더 재순위 모델을 얹어 최종 상위 결과를 정교하게 다듬는 3단계 파이프라인이 널리 쓰입니다.

또 하나 눈에 띄는 흐름은 검색이 병목이 됐다는 인식입니다. 예전에는 언어 모델의 생성 품질이 관건이었다면, 지금은 무엇을 검색해 넣어주느냐가 답변의 질을 사실상 결정합니다. 그래서 단순 벡터 검색을 넘어, 그래프 순회로 관계를 확장하는 GraphRAG나, 에이전트가 대화 맥락을 장기 기억으로 관리하는 구조가 함께 조합되고 있습니다. 실제로 진지한 프로덕션 배포일수록 벡터 검색에 그래프와 단기 메모리를 섞는 하이브리드 형태가 늘고 있는데요. 벡터 검색은 그 조합의 가장 기본이 되는 1차 검색 엔진 역할을 맡습니다. 인덱스와 유사도의 내부를 이해해 두면, 이런 상위 아키텍처를 설계할 때도 병목이 어디서 생기는지 훨씬 빠르게 짚어낼 수 있습니다.

FAQ

벡터 검색은 항상 정확한 답을 보장하나요? 아니요. 실무에서 쓰는 ANN 인덱스는 근사 검색이라 100% 정답을 보장하지 않습니다. 대신 recall 95\~99% 수준을 유지하면서 속도를 수십\~수백 배 끌어올립니다. 전수 비교만이 완벽하지만 규모가 커지면 현실적으로 쓰기 어렵습니다.
HNSW와 IVF 중 무엇을 골라야 하나요? 지연 시간과 정확도가 최우선이고 메모리 여유가 있으면 HNSW, 데이터가 초대규모이고 메모리·비용을 아껴야 하면 IVF가 유리합니다. 많은 시스템이 둘을 결합한 하이브리드 인덱스도 제공하니 워크로드에 맞춰 실측으로 정하는 게 좋습니다.
양자화를 쓰면 검색 품질이 많이 나빠지나요? 압축률이 높을수록 손실은 커지지만, 압축본으로 후보를 추린 뒤 원본으로 재순위를 매기면 상당 부분 회복됩니다. 이진 양자화 + 재순위 조합으로 메모리를 크게 줄이면서 recall을 90%대 후반으로 유지한 사례가 많습니다.
초보자도 직접 구축할 수 있나요? 네. 기존에 PostgreSQL을 쓰고 있고 벡터가 수백만 개 이하라면 pgvector 확장만 설치해도 시작할 수 있습니다. 규모가 커지면 Qdrant나 관리형 Pinecone으로 옮기는 경로가 일반적입니다. 처음부터 초대규모 분산 시스템을 잡을 필요는 없습니다.

같이 읽으면 좋은 것들

출처