Qdrant 개요
Qdrant 개요 (overview)
환영합니다! (Welcome)
Qdrant 오픈소스든 클라우드든 처음 시작하시는 분이라면, 이 짧은 입문서가 플랫폼의 전반적인 이해를 돕는 데 아주 유용해요. Qdrant로 개발을 시작하기 전에 이 개요를 먼저 읽어 보시길 강력히 권장해요.
검색 과정 (Retrieval Process)
벡터 검색은 키워드 매칭을 넘어서 의미(semantic meaning)에 기반해 데이터를 찾는 혁신적인 정보 검색 기법이에요. 이 과정은 임베딩 모델에서 시작돼요. 임베딩 모델은 텍스트, 이미지, 오디오 같은 비정형 데이터를 밀집 벡터 임베딩(dense vector embeddings), 즉 데이터의 개념적 본질을 나타내는 고정 길이의 숫자 목록으로 변환해요. 이 벡터들은 고차원의 벡터 공간에 매핑되고, 같은 의미를 가진 항목끼리 가까이 위치하게 돼요. 이런 공간적 구성 덕분에 "기후 변화(climate change)"라고 검색해도 정확한 단어가 다르더라도 "지구 온난화(global warming)"에 관한 문서를 찾아낼 수 있어요.
밀집 벡터는 문맥을 잘 잡아내지만, 특정 기술 용어나 고유 식별자를 놓칠 때도 있어요. 이 간극을 메우기 위해 Qdrant는 특정 키워드에 대한 정확한 **어휘 매칭(lexical match)**을 잡아내도록 설계된 **희소 벡터(sparse vector)**도 함께 활용해요. 자세한 내용은 이 가이드에서 볼 수 있어요.
비정형 데이터에서 임베딩을 생성하는 과정을 추론(inference)이라고 불러요. Qdrant Cloud에서는 Cloud Inference를 사용해 Qdrant가 서버 쪽에서 임베딩을 생성하게 할 수 있어요. 또는 FastEmbed 같은 라이브러리를 클라이언트 쪽에서 사용해 임베딩을 생성할 수도 있어요.
검색 과정 자체는 Top-K 검색이라는 개념을 중심으로 이뤄져요. 사용자가 요청을 보내면 그 요청은 즉시 **쿼리 벡터(query vector)**로 변환돼요. 엔진은 이 쿼리 벡터와 문서 벡터 사이의 유사도를 계산해, 가장 가까운 "Top-K" 개의 일치 항목을 반환해요. 여기서 K는 사용자가 원하는 결과의 양을 나타내는 값이에요. 이를 통해 개발자는 검색의 폭(breadth)과 답변의 정밀도(precision) 사이의 균형을 세밀하게 조정할 수 있어요.
가장 견고한 검색 경험을 제공하기 위해 Qdrant는 의미 검색과 어휘 검색을 결합한 **하이브리드 검색(Hybrid Retrieval)**을 지원해요. 자세한 내용은 여기에서 확인할 수 있어요.
아키텍처 (Architecture)
Qdrant는 클라이언트-서버 아키텍처로 동작하며, Python, JavaScript/TypeScript, Rust, Go, .NET, Java용 공식 클라이언트 라이브러리를 제공해요. 또한 Qdrant는 HTTP와 gRPC 인터페이스를 노출해 사실상 모든 프로그래밍 언어와 통합할 수 있게 해 줘요.
데이터 구조 (Data Structure)
Qdrant 컬렉션은 수평·수직 확장(horizontal and vertical scaling)을 위해 설계됐어요. 위 다이어그램의 세부 사항은 아래 링크에서 배울 수 있어요:
배포 (Deployments)
Qdrant는 서로 다른 인프라와 운영 요구에 맞춘 여러 배포 모델을 지원해요. 올바른 선택은 보안 제약과 운영 모델에 따라 달라져요: Qdrant가 관리하는 인프라(Managed Cloud), 자체 클러스터와 책임을 공유하는 방식(Hybrid Cloud), 또는 완전한 소유와 독립성(Private Cloud 또는 Open Source)을 고를 수 있어요.
| 기능 | 이점 | OSS | Managed | Hybrid | Private |
|---|---|---|---|---|---|
| 배포 (Deployment) | 인프라 요구에 따라 Qdrant 벡터 DB를 어디에·어떻게 배포할지 선택. | ✅ | ✅ | ✅ | ✅ |
| 고가용성 (High Availability) | 벡터 검색이 항상 가능하도록 자동 페일오버와 복제. | ❌ | ✅ | ✅ | ✅ |
| 무중단 업그레이드 (Zero-Downtime Upgrades) | 복제를 사용해 서비스 중단 없이 Qdrant DB를 업그레이드. | ❌ | ✅ | ✅ | ✅ |
| 모니터링 & 알림 (Monitoring & Alerting) | 클러스터의 상태와 성능을 관찰하는 내장 모니터링과 알림. | ❌ | ✅ | ✅ | ❌ |
| 중앙 관리 UI (Central Management UI) | 모든 Qdrant DB 클러스터를 생성·구성·관리하는 통합 콘솔. | ❌ | ✅ | ✅ | ❌ |
| 수평·수직 확장 (Horizontal & Vertical Scaling) | 자동 샤드 리밸런싱과 리샤딩으로 클러스터 확장·축소·분산. | ❌ | ✅ | ✅ | ✅ |
| 백업 & 재해 복구 (Backups & Disaster Recovery) | 데이터 내구성과 우아한 복구를 위한 자동 백업·복원. | ❌ | ✅ | ✅ | ✅ |
| 데이터 프라이버시 & 제어 (Data Privacy & Control) | 모든 사용자 데이터를 외부가 접근할 수 없는 자체 인프라·네트워크에 보관. | ✅ | ❌ | ✅ | ✅ |
| 멀티클라우드 & 온프레미스 (Multi-Cloud & On-Premises) | 요구에 따라 AWS, GCP, Azure, 온프레미스, 엣지에 배포. | ✅ | ❌ | ✅ | ✅ |
| 엔터프라이즈 지원 (Enterprise Support) | 프로덕션 배포를 위한 Qdrant 엔터프라이즈 지원 서비스. | ❌ | ✅ | ✅ | ✅ |
| 인프라 관리 없음 (No Infrastructure Management) | Qdrant가 인프라를 완전 관리하므로 애플리케이션 구축에 집중. | ❌ | ✅ | ❌ | ❌ |
확장 고려 사항 (Scaling Considerations)
Qdrant의 기본 구성은 POC나 사이드 프로젝트를 시작할 때 합리적이에요. 하지만 프로덕션으로 전환하고 데이터 크기와 동시 사용자가 늘어나면, 고가용성, 지연 시간, 처리량에 대한 기대치가 달라져요. 서비스를 확장할 계획이 있다면 처음부터 이런 도전에 대비한 시스템을 구축해야 해요. 특히 Qdrant를 처음 시작하거나, 빠른 성장을 예상하거나, 시스템을 미래에도 대비하고 싶다면 알아 두면 좋은 몇 가지 흔한 시나리오가 있어요.
메모리 요구사항 (Memory Requirements)
메모리는 벡터 검색을 확장할 때 중요한 리소스예요. 기본적으로 Qdrant는 최대 검색 성능을 위해 벡터를 RAM에 저장해요. 하지만 컬렉션이 수백만 개의 벡터로 커지면 모든 것을 메모리에 유지하는 것이 비싸져요. Qdrant는 데이터를 디스크로 내림(offload)으로써 메모리 사용량을 제어할 수 있게 해 주고, 이 메커니즘은 기존 컬렉션에서도 언제든 활성화할 수 있어요:
- 벡터를 디스크에 저장하면 자주 접근하는 벡터는 자연스럽게 캐시에 남고, 다른 벡터는 필요할 때만 디스크에서 읽어요.
- HNSW 인덱스를 디스크에 저장하면 그래프 탐색에 IO 연산이 필요할 수 있어요. RAM이 심하게 제한된 경우에만 둘 다 디스크에 두고, 빠른 NVMe 스토리지를 확보하세요.
필터링 (Filtering)
벡터 검색만으로도 사용자에게 괜찮은 검색 경험을 제공할 수 있어요. 하지만 의미적 유사성만이 고려해야 할 유일한 요소인 경우는 드물어요. 임베딩은 가격 같은 속성을 잡아내지 못하므로, 일반적으로 특정 페이로드 속성에 대한 필터를 적용해야 해요. 이 필터링을 효과적으로 만들려면 페이로드 인덱스(payload index) 같은 Qdrant의 특정 메커니즘을 알아 두는 게 좋아요.
페이로드 인덱스 (Payload Indexes)
페이로드 인덱스는 특정 페이로드 속성에 대한 효과적인 필터링을 가능하게 하는 보조 데이터 구조예요. 관계형 데이터베이스에서 자주 필터링하는 컬럼에 인덱스를 만드는 것과 친숙한 개념이에요. 마찬가지로 Qdrant에서도 필터링에 사용하는 필드에 페이로드 인덱스를 만들어야 해요.
페이로드 인덱스의 독특한 점은 HNSW 그래프를 확장해서, 의미 검색 단계에서 필터링 조건을 적용할 수 있게 한다는 거예요. 즉 사전 필터링(pre-filtering)이나 사후 필터링(post-filtering)이 아니라 단일 패스 그래프 탐색이에요. 두 방식 모두 단점이 있거든요.
페이로드 인덱스가 HNSW 그래프를 확장한다는 것은, 데이터를 인덱싱하기 전에 만드는 것이 더 효율적이라는 뜻이에요. 옵티마이저가 그래프를 한 번만 구축하면 되기 때문이에요. 다만 어떤 경우에는 이미 많은 벡터가 있는 컬렉션에서 특정 속성으로 필터링해야 할 필요를 깨달을 수도 있어요. 이런 경우에도 여전히 페이로드 인덱스를 만들 수는 있지만, HNSW 그래프에는 즉시 영향을 미치지 않아요.
검색 연산에서 고카디널리티(high cardinality) 필터가 여러 개 있다면, ACORN이라는 추가 메커니즘이 검색 정확도를 높여줄 수 있어요.
확장 (Scaling)
수직 확장에는 자연스러운 한계가 있어요. 결국 사용 가능한 하드웨어의 최대 용량에 도달하고, 단일 노드 배포에는 이중화가 없어요. 샤딩(sharding), 복제(replication), 세그먼트 구성(segment configuration) 옵션으로 확장을 최적화하세요.
Qdrant는 샤딩을 사용해 컬렉션을 여러 노드로 분할해요. 각 샤드는 point의 독립적인 저장소예요. 일반적인 권장 사항은 12개의 샤드로 시작하는 거예요. 그러면 리샤딩 없이 1~2, 3, 6, 12개 노드로 확장할 수 있는 유연성이 확보돼요. 다만 이 방식은 각 노드가 여러 샤드를 관리하므로 작은 클러스터에서 처리량을 제한할 수 있어요.
최적의 처리량을 원한다면 shard_number를 노드 수와 동일하게 설정하세요 (자세한 내용은 여기). 샤딩을 더 잘 제어하려면 Qdrant는 사용자 정의 샤드를 지원해요.
복제 (Replication)
복제 계수(replication factor)는 각 샤드의 복사본이 몇 개 존재하는지를 결정해요. 프로덕션 시스템에서는 복제 계수를 최소 2로 설정할 것을 강력히 권장해요.
세그먼트 구성 (Segment Configuration)
각 샤드는 여러 세그먼트에 데이터를 저장해요. 세그먼트는 샤드에 있는 point의 일부에 대한 모든 데이터 구조를 저장해요. 세그먼트 수가 적으면 더 큰 세그먼트가 생기고, 더 큰 HNSW 인덱스는 더 적은 비교를 필요로 하므로 검색 처리량이 좋아져요. 하지만 큰 세그먼트는 만들고 재생성하는 데 시간이 더 걸려 쓰기와 최적화가 느려져요. 세그먼트가 많으면 인덱싱이 빨라지지만, 쿼리가 더 많은 세그먼트를 스캔하므로 검색 성능은 낮아져요. 세그먼트 구성에 대한 자세한 내용은 관련 문서를 참고하세요.
안전 (Safety)
일부 컬렉션 수준 연산은 Qdrant 클러스터의 성능을 저하시킬 수 있어요. Qdrant의 strict mode는 여러 제어를 통해 비효율적인 사용 패턴을 막아줘요: 인덱스되지 않은 페이로드 필드에 대한 필터링·업데이트 차단, 쿼리 결과 크기와 타임아웃 제한, 필터 조건의 복잡도와 개수 제한, 페이로드 인덱스 수 상한, 배치 업서트 크기 제약, 최대 컬렉션 저장 한도(벡터·페이로드·point 수) 시행, 그리고 시스템 과부하를 막기 위한 읽기·쓰기 연산 속도 제한 구현 등을 할 수 있어요.
OSS 버전은 아무것도 강제하지 않지만, 애플리케이션 요구에 따라 strict mode 설정을 활성화하고 구성하는 것을 고려해 주세요. 그렇지 않으면 일부 API 호출이 Qdrant를 최적이 아닌 방식으로 사용해 클러스터 성능에 영향을 줄 수 있어요.
도움 받기 (Getting Help)
Qdrant가 처음이라면, 핵심 개념과 모범 사례를 다루는 무료 Essentials Course로 시작해 보세요. 질문, 문제 해결, 커뮤니티 지원을 원한다면 Discord Community에 참여해 보세요. Qdrant 사용자와 핵심 팀 모두에게 도움을 받을 수 있는 최고의 장소예요. 유료 고객은 Qdrant Cloud Console을 통해 Support Portal에 접근해 직접적인 기술 지원과 우선 응답을 받을 수 있어요.