[LLM Wiki 22] Qdrant란 무엇인가: FAISS와 HNSW의 관계

앞 글에서는 HNSW가 수많은 벡터 중 가까운 벡터를 어떻게 찾는지 살펴봤습니다. 그러면 다음 질문이 생깁니다.

HNSW를 실제 서비스에서 사용하게 해주는 Qdrant는 무엇이고, 비슷해 보이는 FAISS와는 어떻게 다를까?

결론부터 말하면 세 이름은 서로 다른 층에 있습니다.

HNSW  = 가까운 벡터를 빠르게 찾는 알고리즘
FAISS = 여러 벡터 검색 알고리즘을 제공하는 라이브러리
Qdrant = 벡터 저장, 검색, 필터, API를 제공하는 데이터베이스 서버

Qdrant가 FAISS를 내부에 넣고 사용하는 구조는 아닙니다. FAISS와 Qdrant는 벡터 검색이라는 같은 문제를 각자의 코드로 해결하는 별개의 오픈소스 프로젝트입니다.

---

Qdrant는 무엇인가

Qdrant는 보통 “큐드런트” 정도로 읽습니다. 문서, 이미지, 상품 같은 데이터를 숫자 배열인 vector, 벡터로 저장하고, 질문과 가까운 벡터를 빠르게 찾는 vector database, 벡터 데이터베이스입니다.

일반 데이터베이스가 정확한 조건 검색에 강하다면 Qdrant는 의미가 비슷한 데이터를 찾는 데 초점을 둡니다.

찾으려는 것	잘 맞는 도구
department = '인사팀'인 행	관계형 데이터베이스
‘육아휴직’이 들어간 문서	키워드 검색 엔진
“자녀 양육을 위해 쉬는 절차”와 의미가 비슷한 문서	Qdrant 같은 벡터 데이터베이스

Qdrant는 일반 데이터베이스를 완전히 대체하지 않습니다. 주문과 결제 같은 업무 데이터는 관계형 데이터베이스에 두고, 의미 검색에 필요한 벡터와 문서 정보를 Qdrant에 두는 식으로 함께 사용합니다.

---

문장을 숫자로 바꾸는 일은 누가 하나

Qdrant가 문장을 직접 읽고 의미를 이해하는 것은 아닙니다. 먼저 embedding model, 임베딩 모델이 문장을 벡터로 바꿉니다. 임베딩은 문장이나 이미지의 특징을 숫자 배열로 표현하는 작업입니다.

“점포 침수 대응 절차”
→ 임베딩 모델
→ [0.12, -0.41, 0.73, 0.08, ...]

사용자의 질문도 같은 계열의 임베딩 모델로 바꿉니다.

“매장에 물이 들어오면 어떻게 하나요?”
→ 임베딩 모델
→ [0.10, -0.39, 0.70, 0.11, ...]

Qdrant는 두 벡터 사이의 거리를 계산해 질문과 가까운 문서를 찾습니다. 일반적인 self-hosted 구성에서는 애플리케이션이 임베딩을 만들어 Qdrant에 보냅니다. Qdrant Cloud의 Cloud Inference나 FastEmbed 같은 선택지를 사용하면 임베딩 생성 단계를 Qdrant 생태계 안에서 처리할 수도 있습니다.

---

Collection, Point, vector, payload

Qdrant의 데이터 구조는 네 가지 말로 설명할 수 있습니다.

• Collection, 컬렉션: 검색할 데이터를 담는 큰 묶음
• Point, 포인트: 저장되는 데이터 한 건
• vector, 벡터: 데이터의 의미를 나타낸 숫자 배열
• payload, 페이로드: 제목, 부서, 날짜, 권한 같은 부가정보

포인트 한 건은 다음처럼 생겼습니다.

{
  "id": 129,
  "vector": [0.12, -0.41, 0.73, 0.08],
  "payload": {
    "title": "점포 침수 대응 절차",
    "department": "시설관리팀",
    "year": 2026,
    "acl": ["store-team", "facility-team"]
  }
}

id는 포인트를 구분하는 고유 번호입니다. vector는 의미 검색에 사용하고, payload는 검색 조건과 결과 화면에 사용할 정보를 담습니다. Qdrant 공식 문서도 포인트를 vector와 선택적인 payload로 구성된 레코드로 정의합니다.

같은 컬렉션 안의 vector는 정해진 차원과 거리 계산 설정을 공유합니다. 차원(dimension)은 벡터 안에 숫자가 몇 개 있는지를 뜻합니다. 예를 들어 1,536차원 벡터라면 숫자가 1,536개 들어 있습니다.

---

질문 하나가 처리되는 과정

RAG는 Retrieval-Augmented Generation, 검색 증강 생성의 약자입니다. 관련 문서를 먼저 검색하고, 그 문서를 근거로 LLM이 답변하게 만드는 방식입니다. LLM(Large Language Model)은 문장을 읽고 생성하는 대규모 언어 모델입니다.

사용자가 “매장 침수 시 어떻게 하나요?”라고 물으면 다음 순서로 처리됩니다.

1. 임베딩 모델이 질문을 vector로 변환합니다.
2. Qdrant가 가까운 문서 vector를 검색합니다.
3. 부서와 접근 권한 같은 payload 조건을 적용합니다.
4. 관련 문서와 유사도 점수를 애플리케이션에 반환합니다.
5. LLM이 검색된 문서를 읽고 최종 답변을 작성합니다.

역할을 나누면 다음과 같습니다.

구성 요소	맡는 일
임베딩 모델	문장과 이미지를 vector로 변환
Qdrant	vector와 payload를 저장하고 관련 자료 검색
LLM	검색된 근거를 읽고 답변 생성

Qdrant는 답변 문장을 만드는 AI가 아닙니다. LLM이 답하는 데 사용할 근거를 찾아주는 저장소와 검색 엔진입니다.

---

HNSW는 Qdrant 안에서 어디에 있나

HNSW는 Hierarchical Navigable Small World의 약자로, 가까운 벡터를 빠르게 찾기 위한 계층형 그래프 검색 알고리즘입니다.

Qdrant는 dense vector의 빠른 검색 인덱스로 HNSW를 사용합니다. Dense vector, 밀집 벡터는 문장 전체의 의미를 비교적 촘촘한 숫자 배열로 표현한 벡터입니다.

Qdrant
├─ Collection과 Point 관리
├─ vector와 payload 저장
├─ payload 필터
├─ 검색 API
└─ dense vector 검색
   └─ HNSW 인덱스

따라서 HNSW와 Qdrant는 경쟁 제품이 아닙니다. HNSW가 탐색 방법이라면 Qdrant는 그 탐색 방법을 실제 데이터 저장과 API에 결합한 제품입니다.

Qdrant는 HNSW의 M, ef_construct, 검색 시 hnsw_ef 같은 값을 조정할 수 있게 제공합니다. 설정이 의미하는 바는 HNSW 글에서 자세히 설명했습니다.

---

Payload filter, 의미 검색에 업무 조건을 더한다

임베딩은 문장의 의미를 표현하지만 가격, 작성연도, 재고 상태, 사용자 권한 같은 조건을 완벽히 담지 못합니다. 이런 조건은 payload에 저장하고 검색할 때 filter, 필터로 제한합니다.

의미 조건
질문 vector와 가까운 문서

업무 조건
department = 시설관리팀
year = 2026
acl에 store-team 포함

자주 필터링하는 payload 필드에는 payload index를 만드는 것이 좋습니다. Payload index는 일반 데이터베이스에서 자주 조회하는 열에 인덱스를 만드는 것과 비슷합니다.

Qdrant는 필터를 고려하도록 HNSW 그래프에 추가 연결을 만들 수 있습니다. 필터가 엄격하면 원래 그래프의 이동 경로가 제외돼 검색 품질이 떨어질 수 있기 때문입니다. 그래서 Qdrant 공식 문서는 가능하면 데이터를 넣기 전에 payload index를 만들도록 권장합니다.

Payload에 acl을 저장했다고 사용자 인증이 자동으로 해결되는 것은 아닙니다. 애플리케이션이 로그인 사용자를 확인하고 모든 검색 요청에 올바른 ACL 필터를 넣어야 합니다. 필터가 빠지면 권한 없는 문서가 검색될 수 있습니다.

---

Dense와 sparse를 함께 검색한다

Dense vector는 의미 검색에 강하지만 문서번호, 제품명, 사내 약어 같은 정확한 단어를 놓칠 수 있습니다.

의미 검색이 필요한 질문
“매장에 물이 들어오면 어떻게 하나요?”

정확한 단어 검색이 필요한 질문
“SWS2023”, “RFC-9457”, “재고감모”

Sparse vector, 희소 벡터는 대부분의 값이 0이고 특정 단어나 토큰에만 값이 있는 표현입니다. 정확한 단어와 어휘 검색에 유리합니다.

Qdrant는 한 포인트에 dense vector와 sparse vector를 함께 저장할 수 있습니다. 두 검색 결과를 합치는 방식을 hybrid search, 하이브리드 검색이라고 합니다.

Dense 검색  → 의미가 비슷한 문서
Sparse 검색 → 정확한 단어가 맞는 문서
결과 융합   → 최종 순위

Qdrant의 Query API는 RRF 같은 방식으로 두 결과를 합치거나, 저렴한 검색으로 후보를 찾은 뒤 더 정밀한 모델로 다시 평가하는 다단계 검색을 구성할 수 있습니다. RRF(Reciprocal Rank Fusion)는 여러 검색 결과의 점수 단위가 달라도 각 결과에서의 순위를 이용해 하나의 순위로 합치는 방법입니다.

---

FAISS는 무엇인가

FAISS는 보통 “페이스”라고 읽습니다. 전체 이름은 Facebook AI Similarity Search입니다. Meta의 AI 연구 조직에서 시작한 C++ 기반 벡터 검색 라이브러리이며 Python 인터페이스도 제공합니다.

라이브러리는 개발자가 작성한 프로그램 안에 불러와 사용하는 코드 묶음입니다.

import faiss

index = faiss.IndexFlatL2(1536)
index.add(document_vectors)
distances, ids = index.search(query_vector, k=5)

FAISS는 벡터 검색 알고리즘과 계산에 집중합니다.

• 모든 벡터를 비교하는 정확 검색
• HNSW 그래프 검색
• IVF를 이용한 후보 그룹 검색
• PQ를 이용한 vector 압축
• CPU, GPU 검색
• 검색 성능 평가와 파라미터 튜닝

IVF(Inverted File Index)는 벡터를 여러 그룹으로 나누고 관련 있는 그룹만 검색하는 방식입니다. PQ(Product Quantization)는 벡터를 작은 코드로 압축해 메모리 사용량을 줄이는 방식입니다.

---

FAISS와 Qdrant의 관계

두 도구는 가까운 벡터를 찾는다는 공통점이 있지만 제공 범위가 다릅니다.

항목	FAISS	Qdrant
성격	벡터 검색 라이브러리	벡터 데이터베이스 서버
실행 위치	애플리케이션 프로세스 안	별도 서버 또는 Cloud
인덱스 선택	Flat, IVF, PQ, HNSW 등 다양	Dense 검색은 HNSW 중심
GPU 검색	강력한 지원	일반적인 서버 검색은 CPU 중심
Payload와 필터	외부 DB와 직접 구성	JSON payload와 filter 제공
데이터 변경 API	직접 구현	추가, 수정, 삭제 API 제공
영속 저장과 복구	인덱스 파일 관리 필요	데이터베이스 기능으로 제공
분산 운영	직접 구성	Shard와 replication 제공

Shard, 샤드는 데이터를 여러 서버나 저장 단위에 나누는 방법입니다. Replication, 복제는 같은 데이터를 여러 곳에 보관해 일부 서버가 고장 나도 서비스를 계속할 수 있게 하는 방법입니다.

가장 중요한 관계는 다음과 같습니다.

잘못된 이해
Qdrant → FAISS → HNSW

실제 관계
FAISS  → FAISS가 구현한 HNSW를 선택할 수 있음
Qdrant → Qdrant가 구현한 HNSW를 dense 검색에 사용

Qdrant를 사용할 때 FAISS를 따로 설치해 연결할 필요는 없습니다.

---

FAISS로 Qdrant 같은 서비스를 만들 수 있나

가능합니다. 하지만 벡터 검색 이외의 부분을 직접 만들어야 합니다.

FAISS
+ PostgreSQL 같은 원본 DB
+ 검색 API 서버
+ vector와 문서 ID 동기화
+ 인덱스 파일 저장과 복구
+ 데이터 추가와 삭제 처리
+ 사용자 권한 필터
+ 여러 서버로 나누는 구조
+ 모니터링
= 자체 벡터 검색 서비스

작은 실험에서는 이 구성이 단순할 수 있습니다. 운영 서비스로 커지면 벡터와 원본 데이터의 동기화, 동시 요청, 장애 복구, 권한 필터를 계속 관리해야 합니다. Qdrant는 이 가운데 많은 부분을 벡터 데이터베이스 제품으로 제공합니다.

반대로 FAISS는 검색 인덱스를 더 자유롭게 선택하고 GPU에서 대규모 실험을 수행하기 좋습니다. Qdrant를 선택하면 Qdrant가 지원하는 데이터 모델과 검색 구조 안에서 시스템을 구성해야 합니다.

---

무엇을 선택해야 하나

상황	더 맞는 선택	이유
임베딩 검색 품질을 노트북에서 실험	FAISS	프로그램 안에서 빠르게 인덱스를 비교할 수 있음
IVF, PQ, HNSW를 세밀하게 비교	FAISS	지원하는 인덱스 종류와 조합이 다양함
GPU에서 대규모 벡터 검색	FAISS	GPU 검색과 다중 GPU 기능에 강점
여러 사용자가 동시에 사용하는 RAG	Qdrant	서버 API와 데이터 관리 기능 제공
부서, 날짜, 권한 조건이 필요한 검색	Qdrant	Payload와 필터를 함께 관리
문서가 계속 추가, 수정, 삭제됨	Qdrant	CRUD API와 영속 저장 제공
여러 서버로 확장하고 복제가 필요함	Qdrant	분산 운영 기능 제공

선택 질문은 간단합니다.

벡터 검색 알고리즘이 필요한가, 벡터 검색 서비스가 필요한가?

알고리즘을 실험하고 프로그램 내부에서 직접 제어하려면 FAISS가 잘 맞습니다. 데이터를 지속적으로 저장하고 여러 애플리케이션에 검색 API를 제공하려면 Qdrant가 잘 맞습니다.

---

Qdrant가 해주지 않는 것

Qdrant를 설치한다고 RAG가 자동으로 완성되지는 않습니다. 다음 작업은 여전히 애플리케이션과 데이터 파이프라인의 책임입니다.

• PDF, HTML, Confluence 같은 원본에서 문서 수집
• 긴 문서를 검색하기 좋은 크기로 나누는 chunking
• 임베딩 모델 선택과 vector 생성
• 로그인 사용자 확인과 실제 권한 판정
• 검색 결과를 다시 평가하는 reranking
• LLM의 최종 답변 생성
• 검색 품질과 권한 누출 평가

Chunking, 청킹은 긴 문서를 검색 가능한 작은 조각으로 나누는 작업입니다. Reranking, 재정렬은 처음 검색한 후보를 더 정밀한 모델로 다시 평가해 순서를 바꾸는 작업입니다.

전체 구조에서 Qdrant의 위치를 다시 놓아보면 다음과 같습니다.

문서 수집
→ 청킹
→ 임베딩 생성
→ Qdrant 저장
→ 질문 vector 검색
→ 권한 필터
→ 재정렬
→ LLM 답변

Qdrant는 이 가운데 저장, 후보 검색, 필터를 담당하는 핵심 부품입니다. 하지만 좋은 답변은 문서 품질, 청킹, 임베딩, 권한, 재정렬과 평가가 함께 맞아야 나옵니다.

---

한 번에 정리하기

HNSW
가까운 vector를 빠르게 찾는 그래프 알고리즘

FAISS
HNSW, Flat, IVF, PQ 같은 검색 방식을 제공하는 라이브러리

Qdrant
자체 HNSW 검색과 vector 저장, payload, 필터, API를 묶은 데이터베이스

Qdrant를 도서관에 비유하면 Collection은 서고, Point는 책 한 권, vector는 책 내용의 의미 좌표, payload는 제목과 부서와 열람권한을 적은 분류표입니다. HNSW는 비슷한 책이 있는 곳으로 빠르게 이동하는 지도입니다.

FAISS는 그 지도를 만드는 여러 방법과 고속 탐색 엔진을 개발자가 직접 조립할 수 있게 제공하는 도구 상자에 가깝습니다. Qdrant는 그 탐색 엔진을 데이터 저장과 서비스 운영 기능에 결합한 시스템입니다.

---

참고 자료

• Qdrant 공식 개요
• Qdrant Point와 데이터 관리
• Qdrant HNSW와 필터 인덱싱
• Qdrant 하이브리드 검색
• FAISS 공식 저장소
• FAISS 인덱스 종류