HNSW란? AI에서 계층형 그래프로 비슷한 벡터를 빠르게 찾는 방법

TL;DR

HNSW는 가까운 벡터를 여러 층의 그래프로 연결해 검색 범위를 줄이는 근사 최근접 이웃(ANN) 인덱스입니다. 위층에서 먼 거리를 빠르게 이동하고 아래층으로 내려가며 가까운 후보를 더 살핍니다. 검색이 빠르다는 말은 매번 정확한 이웃을 보장한다는 뜻이 아닙니다. m, 구축 후보 수, 검색 후보 수와 메모리 비용을 함께 평가해야 합니다.

핵심 3줄 요약

• 핵심 1
  층을 나눠 탐색합니다. 상층의 드문 연결로 큰 범위를 건너뛰고 아래층의 촘촘한 연결에서 가까운 벡터를 찾습니다.
• 핵심 2
  빠른 대신 근사합니다. 모든 벡터를 직접 비교하지 않으므로 정확 검색의 상위 결과와 차이가 날 수 있습니다.
• 핵심 3
  설정은 비용의 교환입니다. 연결 수·구축 후보·검색 후보를 늘리면 품질이 나아질 여지가 있지만 메모리와 처리 시간도 확인해야 합니다.

이 글에서 다룰 내용

HNSW를 한 문장으로 정의하면 무엇인가요?

HNSW(Hierarchical Navigable Small World)는 벡터의 이웃 관계를 여러 층의 근접 그래프에 저장하고 그 연결을 따라 가까운 후보를 탐색하는 ANN 인덱스 방식입니다. 원 논문은 저장된 원소의 일부가 위층에도 나타나는 다층 그래프를 점진적으로 만드는 방법을 제안합니다. 새로운 질의가 오면 모든 항목의 거리를 재는 대신 그래프의 연결을 따라 이동합니다.

ANN은 근사 최근접 이웃 검색이라는 큰 범주이며 HNSW는 그 안의 한 가지 알고리즘입니다. Faiss는 IndexHNSWFlat을 계층형 그래프 탐색 인덱스로 분류하고, pgvector와 Qdrant도 HNSW를 벡터 검색 인덱스로 설명합니다. 구현마다 매개변수 이름, 필터 처리와 저장 방식이 달라 같은 설정 숫자를 그대로 옮기면 안 됩니다.

한 줄 정리: HNSW는 벡터의 의미를 새로 만드는 모델이 아니라 이미 만들어진 벡터에서 비슷한 후보를 빠르게 찾도록 연결망을 준비하는 검색 인덱스입니다.

쉬운 예시로 이해해 볼까요?

감자나라ai님이 AI 용어 설명 수만 건을 임베딩으로 저장하고, 새 질문과 가장 비슷한 글을 찾는다고 가정해 보겠습니다. 정확 검색은 질문 벡터를 저장된 모든 글 벡터와 비교합니다. HNSW는 미리 연결해 둔 이웃을 따라가며 유망한 구역부터 살핍니다. 글의 수가 커질수록 모든 대상을 매번 확인하지 않는 접근의 이유가 분명해집니다.

서가가 여러 층인 도서관을 떠올려 보세요. 맨 위층의 표지는 주요 구역으로 향하는 길을 빠르게 알려 줍니다. 아래층으로 내려가면 그 구역의 책을 더 세밀하게 둘러볼 수 있습니다. 실제 HNSW에는 사람이 붙인 도서 분류표가 없습니다. 데이터의 벡터 거리와 그래프 연결이 길잡이 역할을 한다는 점만 비유와 같습니다.

쉬운 예시: 도서관의 빠른 안내 표지처럼 상층에서 큰 방향을 잡고 하층에서 후보를 고릅니다. 다만 안내 경로가 모든 책을 확인한 것과 같지는 않습니다.

왜 AI에서 HNSW가 중요한가요?

벡터가 많을 때 후보 탐색을 줄입니다

RAG는 질문과 연관된 문서 조각을 먼저 찾고 그 조각을 답변 생성에 전달합니다. 모든 조각을 매번 비교하는 것이 부담스러울 때 HNSW 같은 ANN 인덱스를 검색 후보 단계에 쓸 수 있습니다. 모델의 문장 생성 자체를 빠르게 만드는 방법은 아닙니다. 검색 단계의 지연과 후보 품질을 따로 측정해야 효과를 알 수 있습니다.

원 논문은 다층 근접 그래프와 이웃 선택 휴리스틱을 제안하고 속도와 높은 재현율 사이의 성능을 평가합니다. 그 결과를 내 데이터에서의 속도 보증으로 받아들여서는 안 됩니다. 벡터 수·차원·거리·하드웨어·필터·동시 요청이 다르면 병목도 달라집니다.

검색 품질과 자원 사용을 함께 설계하게 합니다

HNSW는 조회 때 연결을 따라 후보를 살피는 대신 인덱스를 만들고 이웃 연결을 보관해야 합니다. pgvector 문서는 HNSW가 IVFFlat에 비해 검색의 속도·재현율 절충에서 유리하지만 구축 시간이 길고 메모리를 더 쓴다고 안내합니다. 이 차이는 해당 구현 설명이며 모든 제품에서 동일한 순위를 약속하는 문장이 아닙니다.

HNSW는 어떤 순서로 작동하나요?

1. 벡터를 이웃 그래프에 연결합니다

인덱스를 만들 때 저장 벡터를 노드로 두고 가까운 이웃에 연결을 만듭니다. 원 논문은 원소가 포함되는 최고 층을 무작위로 고르는 계층 구조를 설명합니다. 위층에는 비교적 적은 노드가 남고 아래층으로 갈수록 더 많은 벡터가 등장합니다. 연결은 원문 문장들의 하이퍼링크가 아니라 임베딩 좌표 사이의 탐색 경로입니다.

2. 위층에서 멀리 이동한 뒤 아래층으로 내려갑니다

질의 벡터가 들어오면 위층의 연결을 따라 더 가까운 노드를 찾고 한 층씩 내려갑니다. Qdrant 문서는 위층을 더 드문 연결, 아래층을 더 조밀한 연결로 설명합니다. 먼 곳에서 가까운 곳으로 탐색의 초점을 좁히는 셈입니다. 첫 출발점이 답에 가장 가깝다고 확정하는 절차는 아닙니다.

3. 검색 결과를 실제 목적에 맞춰 확인합니다

인덱스가 반환한 이웃은 문서 전체의 정답이나 AI 응답의 근거가 아닙니다. RAG라면 원문 접근 권한, 문서 버전과 청킹 경계를 확인한 뒤 필요한 경우 리랭킹으로 후보의 순서를 다시 매깁니다. 정확 검색의 상위 목록을 비교 기준으로 삼으면 근사 탐색이 어떤 질문에서 중요한 후보를 놓치는지 볼 수 있습니다.

핵심 인사이트: 그래프의 층은 큰 범위를 건너뛰기 위한 탐색 구조입니다. 반환된 문서가 답변에 적합한지는 별도의 평가 문제입니다.

m·ef_construction·ef_search는 무엇을 바꾸나요?

m은 그래프 연결 수의 상한에 영향을 줍니다

pgvector는 m을 층별 최대 연결 수로 설명합니다. Qdrant도 노드의 최대 연결 수를 제한하는 설정으로 안내합니다. 연결이 많아지면 탐색할 길이 늘어 가까운 후보를 찾기 쉬워질 수 있지만 그래프를 저장할 공간과 구축 비용도 함께 점검해야 합니다. m을 결과 개수나 임베딩 차원과 혼동하지 마세요.

ef_construction은 구축 때 살피는 후보 폭입니다

pgvector 문서는 ef_construction을 그래프를 만드는 동안 유지하는 동적 후보 목록의 크기로 설명합니다. 더 크게 하면 재현율에 도움이 될 수 있지만 인덱스 구축 시간이나 삽입 속도에 비용이 듭니다. Qdrant 문서에는 비슷한 역할의 이름이 ef_construct로 표기됩니다. 서로 다른 설정명을 같은 API 문법으로 복사하지 말고 해당 제품 문서를 따릅니다.

ef_search는 조회할 때의 후보 폭입니다

pgvector의 hnsw.ef_search는 검색 시 동적 후보 목록의 크기입니다. 값을 올리면 재현율이 나아질 수 있는 대신 조회 속도가 느려질 수 있다고 문서는 안내합니다. Qdrant는 검색 단계의 ef를 설명합니다. 이 둘이 모든 제품에서 동일한 설정 항목이나 동일한 기본값이라는 뜻은 아닙니다.

HNSW와 헷갈리는 용어는 무엇이 다른가요?

정확 최근접 이웃 검색과 HNSW의 차이

정확 검색은 같은 거리 기준 아래 모든 저장 벡터를 비교해 가까운 결과를 찾는 기준점입니다. HNSW는 그래프를 따라 일부 후보를 우선 살피는 근사 방식입니다. 작은 데이터에서는 정확 검색이 충분할 수 있고, 큰 데이터에서도 중요한 평가 질문은 정확 검색의 상위 결과와 대조해야 누락을 확인할 수 있습니다.

ANN과 HNSW의 차이

ANN은 전체를 직접 검사하지 않고 가까운 항목을 근사적으로 찾는 문제와 알고리즘 범주입니다. HNSW는 그 범주 안의 계층형 그래프 방식입니다. 기존 Glossary의 ANN 글은 정확 검색과 근사 검색의 범주 차이에 집중합니다. 여기서는 그래프의 계층, m과 두 후보 폭, 구축·메모리 비용을 따로 설명합니다.

IVFFlat과 HNSW의 차이

Faiss는 HNSW를 그래프 탐색 계열로, IVFFlat을 역파일 기반 후보 분류 인덱스로 구분합니다. pgvector도 두 종류를 별도로 지원합니다. pgvector 문서에 따르면 HNSW는 IVFFlat보다 인덱스 구축이 느리고 메모리를 더 쓰는 대신 조회 성능과 재현율 절충이 유리합니다. 그 설명을 다른 엔진에 그대로 적용하지 말고 같은 데이터로 비교합니다.

리랭킹·RRF와 HNSW의 차이

HNSW는 벡터 인덱스에서 가까운 후보를 처음 찾는 방식입니다. 리랭킹은 이미 찾은 후보를 더 자세히 평가해 순서를 바꾸는 단계입니다. RRF는 여러 검색 결과 목록의 순위를 합치는 방식입니다. 그래프 탐색, 후보 재정렬, 목록 융합은 검색 파이프라인의 서로 다른 작업이므로 어느 한 용어로 나머지를 대신 부를 수 없습니다.

비교 정리: ANN은 근사 검색의 범주, HNSW는 그래프 인덱스, 리랭킹은 후보 재평가, RRF는 여러 목록의 순위 결합입니다. 이들이 같은 단계에서 같은 문제를 푸는 것은 아닙니다.

실전에서는 어디에 쓰이나요?

RAG 문서 조각 검색

질문 임베딩과 관련된 문서 조각을 벡터 인덱스에서 찾는 첫 단계에 쓸 수 있습니다. 사내 문서라면 원문 권한과 수정 시점을 결과에서 함께 확인하세요. 찾은 조각이 질문에 필요한 증거를 포함했는지 따져야 하며, HNSW 인덱스가 근거 검증을 대신하지는 않습니다.

이미지·상품의 유사 항목 탐색

이미지나 상품 설명을 같은 임베딩 체계로 표현했다면 비슷한 항목의 후보 검색에 활용합니다. 대상 데이터가 바뀌면 새 벡터가 적절하게 반영되는지, 중복 상품이나 비슷한 배경만 선택하는지 확인합니다. 빠른 검색 수치 하나로 추천의 유용성을 판정하지 않습니다.

제품 문서 속 인덱스 선택

HNSW 인덱스를 적용할 때 어떤 순서로 확인하나요?

1. 벡터와 거리 기준을 먼저 고릅니다

사용할 임베딩 모델과 차원, 정규화 여부, 코사인·내적·유클리드 같은 거리 기준을 정합니다. 같은 단어가 들어간 문서라도 임베딩이 업무 의미를 담지 못하면 빠르게 엉뚱한 이웃을 찾습니다. Faiss 문서는 코사인 검색에 정규화한 벡터를 내적 검색에 쓰는 방식을 설명합니다. 거리와 정규화 가정을 기록하세요.

2. 정확 검색을 비교 기준으로 만듭니다

대표 질문 묶음에서 완전 탐색이 찾아낸 상위 항목을 저장하고 HNSW 결과와 비교합니다. 키워드 검색이나 사람의 정답표와는 목적이 다릅니다. 정확 검색 대비 재현율은 근사 인덱스의 손실을, 사람의 정답표는 업무 관련성을 평가합니다. 두 기준을 한 점수로 합치지 않습니다.

3. 구축·검색 설정을 따로 조절합니다

m과 구축 후보 폭을 조정할 때는 인덱스 크기, 구축 시간, 삽입 비용을 함께 기록합니다. 검색 후보 폭을 조정할 때는 같은 질문의 재현율과 지연 분포를 비교합니다. 어느 하나의 수치가 좋아졌다고 모든 환경에서 최적이라고 단정하지 말고 실제 동시 요청과 데이터 규모를 반영하세요.

4. 필터를 포함한 최종 결과를 검토합니다

언어, 게시일, 접근 권한 같은 조건을 붙인 뒤에도 요청한 수만큼 유효한 문서가 나오는지 확인합니다. Qdrant는 벡터 인덱스와 payload 인덱스를 구분하며 필터가 검색에 영향을 미친다고 설명합니다. 필터 없는 실험만 통과했다면 실제 서비스 검색을 검증한 것이 아닙니다.

실전 팁: 빠른 응답, 높은 정확 검색 대비 재현율, 낮은 메모리 사용을 한 번에 단정하지 마세요. 같은 질문·데이터·거리 기준을 고정하고 비용을 나란히 기록합니다.

사용할 때 무엇을 주의해야 하나요?

첫째, 근사 결과를 정확한 정답으로 부르지 않습니다. 탐색 후보가 제한되면 가까운 벡터를 놓칠 수 있습니다. 정확 검색 대비 재현율과 실제 질문의 관련성을 각각 확인하세요. 반복 조회에서 결과가 달라진다면 인덱스 갱신, 필터, 설정과 데이터 상태도 함께 봅니다.

둘째, 거리 기준과 임베딩 전처리를 섞지 않습니다. 생성 때와 검색 때 다른 모델이나 정규화 방식을 적용하면 그래프를 제대로 탐색해도 의도한 유사도를 얻지 못합니다. 저장 벡터의 생성 버전과 인덱스의 거리 설정을 같이 보관하세요.

셋째, 필터 후 결과 부족을 단순한 k 문제로 단정하지 않습니다. pgvector 문서는 필터 적용과 반복 스캔 설정을 별도로 안내합니다. Qdrant도 payload 인덱스와 필터 인식 연결을 따로 설명합니다. 필터가 인덱스 탐색 전후 어느 단계에 작용하는지 제품별로 확인해야 합니다.

넷째, 메모리와 구축 시간을 서비스 예산에 넣습니다. 그래프의 이웃 연결은 저장 공간을 차지하고 데이터 삽입에도 계산이 필요합니다. 정적 벤치마크의 조회 속도만으로 운영 비용을 계산하면 데이터 증가와 재색인 작업을 놓칩니다.

다섯째, 결과의 권한과 최신성을 따로 검증합니다. HNSW는 접근 제어 또는 문서 버전 정책이 아닙니다. 검색이 가까운 문서를 찾았어도 그 문서를 현재 사용자에게 보여도 되는지, 더 최신 문서가 있는지 확인해야 합니다.

주의: HNSW의 빠른 검색은 정확한 이웃, 올바른 근거, 접근 권한을 자동으로 보장하지 않습니다. 각각 별도의 시험이 필요합니다.

자주 묻는 질문

Q1. HNSW는 임베딩 모델인가요?

아닙니다. 임베딩 모델은 텍스트나 이미지의 수치 벡터를 만들고, HNSW는 만들어진 벡터에서 가까운 이웃을 찾을 인덱스와 탐색 경로를 만듭니다. 좋은 인덱스를 써도 임베딩의 의미 표현이 부정확하면 관련 문서를 잘 찾기 어렵습니다.

Q2. HNSW를 쓰면 항상 정확 검색보다 빠르고 결과도 같나요?

결과가 항상 같지는 않습니다. HNSW는 탐색 범위를 줄이는 근사 방식이므로 일부 이웃을 놓칠 수 있습니다. 속도 이점도 데이터 규모, 구축 비용과 시스템 조건에 달려 있습니다. 작은 데이터라면 정확 검색을 비교 대상으로 먼저 시험하세요.

Q3. m과 ef_search는 같은 값인가요?

다릅니다. m은 그래프 연결의 최대 수와 관련되고 ef_search는 pgvector에서 조회할 때 탐색할 동적 후보 목록의 크기입니다. Qdrant는 검색 후보 폭을 ef라고 부릅니다. 각 제품의 이름과 설정 범위를 확인하세요.

Q4. RAG를 쓰면 반드시 HNSW가 필요한가요?

아닙니다. RAG는 문서를 찾아 답변 생성에 쓰는 흐름입니다. 문서가 적으면 정확 검색으로도 운영할 수 있고, 키워드 검색을 결합할 수도 있습니다. 데이터 규모와 지연 요구, 평가 결과가 HNSW 도입의 근거가 됩니다.

Q5. 조건으로 필터링하면 검색 품질도 그대로인가요?

그렇게 가정하면 안 됩니다. 벡터 그래프에서 찾은 후보와 필터가 허용하는 문서의 교집합이 작을 수 있습니다. pgvector와 Qdrant는 필터 동작을 각각 따로 설명하므로 사용 중인 제품의 필터 순서와 인덱스 설정을 확인하고 필터된 질문으로 다시 평가합니다.

출처

마무리

HNSW는 벡터를 계층형 이웃 그래프로 연결해 비슷한 항목을 빠르게 찾는 ANN 방식입니다. 상층에서 큰 방향을 잡고 아래층에서 후보를 좁힙니다. 이 방식이 쓰이는 범주와 그래프 탐색 과정은 기존 ANN 개요와 연결되지만, 연결 수와 구축·검색 후보 폭을 어떻게 잡느냐가 실제 운용의 핵심입니다.

처음 적용한다면 임베딩과 거리 기준을 고정한 뒤 정확 검색을 비교 기준으로 만드세요. 그다음 재현율·지연·구축 시간·메모리·필터 적용 결과를 함께 보며 설정을 조정합니다. 검색된 문서가 사용자의 질문에 답할 근거인지와 보여도 되는 자료인지는 별도로 확인해야 합니다.