P1-13.4 벡터 검색 구현의 직관¶

Section ID: P1-13.4 Version: v2026.07.20

P1-13.1에서는 텍스트(text)를 벡터(vector)로 표현하는 임베딩(embedding)을 봤습니다. P1-13.2에서는 가까운 벡터를 찾는 유사도 검색(similarity search)을 봤습니다. P1-13.3에서는 검색된 후보를 LLM 입력 맥락(context)에 붙이는 RAG(retrieval-augmented generation)를 봤습니다.

이제 벡터가 아주 많아지면 가까운 후보를 어떻게 빨리 찾을 것인가?라는 질문이 남습니다. P1-13.4는 이 질문을 깊은 알고리즘이 아니라 구현 직관으로 다룹니다.

벡터 검색 구현은 많은 벡터 중에서 가까운 후보를 빠르게 찾기 위해 저장 구조, 인덱스, 근사 검색 방법을 함께 설계하는 일이다.

여기서 핵심은 “정확한 수학 공식”보다 “왜 그냥 전부 비교하면 어려운가”입니다.

Part 1에서 벡터 검색(vector search) 구현, 인덱스(index), 근사 최근접 이웃(approximate nearest neighbor, ANN), 그래프 기반 검색(graph-based search), 벡터 데이터베이스(vector database)의 기본 구분은 여기서 잡습니다. 13.1에서는 임베딩을, 13.2에서는 유사도 검색을, 13.3에서는 RAG를 봤고, 여기서는 그 흐름이 실제 저장소와 검색 구현에서 어떻게 빨라지는가를 정리합니다.

여기서는 먼저 벡터가 아주 많아졌을 때 가까운 후보를 어떻게 빨리 찾는가를 닫습니다. HNSW(hierarchical navigable small world), FAISS, product quantization 같은 이름은 Part 5의 P5-13.1, P5-13.2에서 서비스 관점의 검색 저장소와 인덱스 품질로 다시 이어지고, 여기서는 전체 비교를 줄이는 구현 직관만 붙잡습니다.

Part 2에서 그래프(graph) 자료구조를 다시 보면, 이 절의 그래프 기반 인덱스(index) 설명이 더 자연스럽게 연결됩니다. 지금은 노드(node)와 간선(edge)으로 가까운 벡터들의 연결을 만들어 검색 경로를 줄인다는 직관만 잡습니다.

인덱스, ANN, 그래프 기반 검색, 벡터 데이터베이스는 서로 다른 구현 층위의 개념입니다. 여기서는 각 용어의 역할을 먼저 다음처럼 구분합니다.

여기서는 전체 비교는 느리고, 인덱스와 ANN은 빠르게 후보를 줄이기 위한 장치라는 구분을 기준선으로 둡니다.

벡터 검색 구현 흐름을 읽는 기준¶

• 벡터 검색이 데이터가 커질수록 계산 문제가 된다는 점을 이해합니다.
• 인덱스(index)를 검색을 빠르게 하기 위해 미리 만든 구조로 이해합니다.
• 근사 최근접 이웃(approximate nearest neighbor, ANN)을 빠른 후보 탐색을 위한 절충으로 이해합니다.
• 그래프(graph) 기반 인덱스가 가까운 벡터 사이의 연결을 이용한다는 직관을 잡습니다.
• 벡터 데이터베이스(vector database)가 검색 알고리즘만이 아니라 저장, 필터링, 메타데이터, 운영을 함께 다루는 시스템임을 이해합니다.

세 가지 기준¶

여기서는 벡터 데이터베이스 내부 구현을 깊게 파기보다, 검색 구현이 어떤 단계로 읽히는지 정리하는 데 집중합니다. 본문을 읽을 때 기준이 되는 세 가지 관점은 다음과 같습니다.

모든 벡터를 매번 비교하면 느려진다¶

가장 단순한 방법은 질문 벡터를 모든 문서 벡터와 비교하는 것입니다.

질문 벡터 -> 문서 벡터 1과 비교 -> 문서 벡터 2와 비교 -> 문서 벡터 3과 비교 -> ... -> 가장 가까운 후보 선택

이런 방식을 전체 비교(brute-force search)라고 부를 수 있습니다. 데이터가 적을 때는 단순하고 정확합니다.

하지만 문서 조각이 많아지면 문제가 됩니다.

유사도 검색은 보통 상위 k개(top-k) 후보를 찾습니다. 이때 모든 벡터를 매번 비교하면 정확할 수는 있지만, 응답 시간이 길어지고 비용이 커질 수 있습니다.

그래서 검색 시스템은 “매번 처음부터 모두 비교하지 않기 위한 준비”를 합니다. 그 준비가 인덱스(index)입니다.

인덱스는 빠르게 찾기 위한 준비 구조다¶

인덱스(index)는 검색을 빠르게 하기 위해 미리 만들어 둔 구조입니다.

여기서는 책의 색인이나 도서관 분류에 비유해 이해할 수 있습니다.

색인 없음: 책 전체를 처음부터 끝까지 훑는다.

색인 있음: 관련 단어와 위치를 먼저 보고 필요한 곳으로 이동한다.

벡터 검색에서도 비슷한 문제가 생깁니다.

인덱스 없음: 질문 벡터를 모든 문서 벡터와 비교한다.

인덱스 있음: 가까울 가능성이 높은 영역이나 연결을 먼저 따라간다.

다만 벡터 인덱스는 책의 단어 색인과 같지는 않습니다. 벡터는 고차원 공간(high-dimensional space)에 놓인 수치 표현입니다. 그래서 벡터 인덱스는 가까운 후보를 빨리 찾기 위한 별도의 자료구조(data structure)와 알고리즘을 사용합니다.

근사 검색은 빠르지만 절충이 있다¶

근사 최근접 이웃(approximate nearest neighbor, ANN)은 정확히 가장 가까운 후보를 항상 찾겠다고 약속하기보다, 충분히 가까운 후보를 빠르게 찾는 접근입니다.

정확 검색(exact search): 가장 가까운 벡터를 찾기 위해 가능한 비교를 충분히 수행한다.

근사 검색(approximate search): 조금의 누락 가능성을 감수하고 빠르게 가까운 후보를 찾는다.

여기서 근사는 대충 찾는다는 뜻이 아닙니다. 검색 속도와 검색 품질 사이의 균형을 조절한다는 뜻에 가깝습니다.

RAG 시스템에서는 근사 검색이 자주 고려됩니다. 사용자가 질문했을 때 몇 초씩 기다리게 만들 수 없고, 문서 저장소는 계속 커질 수 있기 때문입니다.

그래프 기반 검색은 가까운 길을 따라간다¶

그래프(graph)는 노드(node)와 간선(edge)으로 관계를 표현하는 자료구조입니다.

벡터 검색에서 그래프 기반 인덱스는 각 벡터를 노드처럼 보고, 가까운 벡터끼리 연결을 만들어 둔다고 이해할 수 있습니다.

벡터 A -- 가까움 -- 벡터 B 벡터 B -- 가까움 -- 벡터 C 벡터 B -- 가까움 -- 벡터 D

검색할 때는 모든 벡터를 하나씩 비교하지 않고, 가까워 보이는 연결을 따라가며 후보를 좁힙니다.

질문 벡터 -> 시작 노드 선택 -> 더 가까운 이웃으로 이동 -> 다시 더 가까운 이웃으로 이동 -> 충분히 가까운 후보 집합 선택

HNSW(hierarchical navigable small world)는 이런 그래프 기반 근사 최근접 이웃 검색의 대표적인 방법으로 자주 언급됩니다. 이름에 hierarchical이 들어가는 것처럼 여러 층(layer)의 그래프를 사용해 멀리 이동하는 단계와 가까운 후보를 좁히는 단계를 나눕니다.

여기서는 길 찾기에 비유해 이해할 수 있습니다.

넓게 이동하는 길: 대략 가까운 영역으로 빠르게 간다.

좁게 살피는 길: 그 영역 안에서 더 가까운 후보를 찾는다.

이 설명은 알고리즘의 정확한 구현이 아니라 직관입니다. 실제 HNSW는 그래프를 만들고, 이웃을 선택하고, 검색 폭을 조절하는 세부 파라미터가 있습니다. 여기서는 그런 구현 세부로 들어가지 않습니다.

벡터 데이터베이스는 검색 알고리즘만이 아니다¶

벡터 데이터베이스(vector database)는 벡터를 저장하고 검색하기 위한 시스템입니다. 하지만 실제로는 단순히 “가까운 벡터 찾기 알고리즘”만 의미하지 않습니다.

실제 서비스에서는 다음 기능이 함께 필요합니다.

예를 들어 조직 내부 문서 검색이라면 가까운 벡터만으로는 부족합니다.

질문과 가까운 문서인가? 사용자가 볼 권한이 있는 문서인가? 최신 문서인가? 같은 문서가 중복 검색되지는 않았는가? 답변에 출처를 붙일 수 있는가?

따라서 벡터 데이터베이스는 RAG 시스템의 한 구성요소입니다. RAG 전체 품질은 벡터 데이터베이스만으로 결정되지 않고, 문서 준비, 임베딩 모델, 검색 설정, 프롬프트 구성, 답변 검토와 함께 결정됩니다.

속도, 품질, 비용은 함께 움직인다¶

벡터 검색 구현에서는 보통 세 가지를 동시에 봅니다.

여기서 recall과 precision은 나중에 평가 지표에서 다시 다룹니다. 여기서는 다음 직관만 먼저 잡습니다.

recall: 찾아야 할 후보를 놓치지 않는 정도

precision: 가져온 후보 중 실제로 관련 있는 것이 많은 정도

검색을 더 넓게 하면 필요한 문서를 놓칠 가능성은 줄어들 수 있지만, 관련 없는 문서도 더 많이 들어올 수 있습니다. 검색을 좁게 하면 빠르고 간결할 수 있지만, 중요한 근거를 놓칠 수 있습니다.

그래서 벡터 검색 구현은 하나의 정답 설정을 찾는 일이 아니라, 목적에 맞는 균형을 찾는 일에 가깝습니다.

체크리스트¶

• 전체 비교(brute-force search)가 데이터가 커질수록 느려질 수 있음을 설명할 수 있다.
• 인덱스(index)를 검색을 빠르게 하기 위해 미리 만든 구조로 설명할 수 있다.
• 근사 최근접 이웃(approximate nearest neighbor, ANN)을 빠른 후보 탐색을 위한 절충으로 설명할 수 있다.
• 그래프(graph) 기반 검색을 가까운 벡터 사이의 연결을 따라가는 방식으로 설명할 수 있다.
• HNSW(hierarchical navigable small world)를 그래프 기반 ANN의 대표적 예로 설명할 수 있다.
• 벡터 데이터베이스(vector database)가 벡터 저장, 인덱스, 메타데이터, 필터링, 업데이트를 함께 다룬다는 점을 설명할 수 있다.
• 벡터 검색 구현에서 속도(latency), 품질(recall, precision), 비용(cost)의 균형이 필요함을 설명할 수 있다.
• 전체 비교, 인덱스, 근사 검색, 운영 균형을 나누어 실제 서비스에서 왜 이런 구조가 필요한지 설명할 수 있다.
• 벡터 데이터베이스를 단순 알고리즘이 아니라 저장·필터링·운영을 포함한 시스템으로 설명할 수 있다.

출처와 참고 자료¶

• Yu. A. Malkov, D. A. Yashunin, Efficient and robust approximate nearest neighbor search using Hierarchical Navigable Small World graphs, arXiv, 2016, 확인 날짜: 2026-06-23.
• Jeff Johnson, Matthijs Douze, Herve Jegou, Billion-scale similarity search with GPUs, arXiv, 2017, 확인 날짜: 2026-06-23.