Azure AI Search에서 10억 벡터 문제 정복하기
By Mirko Peters ·
최신 엔터프라이즈 인공지능에서 가장 시급한 과제 중 하나인, 수십억 건의 레코드로 벡터 검색을 확장하는 문제를 깊이 있게 다뤄 보겠습니다. 검색 증강 생성(RAG) 시스템, 시맨틱 검색 엔진, AI 어시스턴트를 다뤄 보셨다면 데이터가 얼마나 빠르게 쌓이는지 이미 체감하셨을 것입니다…
Automatically translated with AI from the original post. Read the English original
최신 엔터프라이즈 인공지능에서 가장 시급한 과제 중 하나인, 수십억 건의 레코드로 벡터 검색을 확장하는 문제를 깊이 있게 다뤄 보겠습니다. 최신 검색 증강 생성(RAG) 시스템, 시맨틱 검색 엔진, AI 어시스턴트를 다뤄 보셨다면 데이터가 얼마나 빠르게 쌓이는지 이미 체감하셨을 것입니다. 조직이 수백만, 때로는 수십억 건의 문서, 이미지, 사용자 상호 작용을 수집하면서 기존 검색 아키텍처는 부하를 견디지 못하고 무너지기 시작합니다. 그래서 이제 수십억 규모 벡터 인덱싱의 작동 원리를 이해하는 것은 아키텍트와 개발자에게 선택이 아니라, 살아남기 위한 필수 역량입니다.
이 포괄적인 블로그 글에서는 고차원 벡터 공간의 기술적 난제를 풀어 보고, 업계를 선도하는 그래프 기반 인덱싱 알고리즘 두 가지인 HNSW(Hierarchical Navigable Small World)와 Microsoft의 DiskANN을 비교한 다음, Azure AI Search가 이러한 워크로드를 효율적으로 처리하도록 어떻게 지원하는지 살펴보겠습니다. 메모리 매개변수를 조정하든, 하드웨어 인프라 비용을 관리하든, 검색 재현율을 극대화하고자 하든, 이 가이드가 필요한 기술 로드맵을 제공합니다. 이 개념을 오디오 중심으로 정리한 내용이 필요하다면 M365 FM의 관련 팟캐스트 에피소드 HNSW vs DiskANN for Vector Search in Azure AI Search도 꼭 확인해 보시기 바랍니다.
Azure AI Search의 10억 벡터 문제
수십억 규모 벡터 검색의 과제
엔터프라이즈 AI에서 방대한 데이터셋을 인덱싱하고 검색해야 할 때 10억 벡터 문제에 직면하게 됩니다. 수십억 개의 벡터를 다루려면 고유한 기술적 과제가 따릅니다. 처리 속도가 떨어지지 않으면서 대규모 데이터를 처리할 수 있는 효율적인 인덱싱 시스템을 구축해야 합니다. 검색 결과가 최신 상태를 유지하고 관련성을 잃지 않으려면 실시간 업데이트가 중요합니다. 또한 정확한 검색 결과를 얻으려면 고차원 임베딩을 관리하는 것이 필수적입니다.
수십억 규모 데이터셋을 다룰 때는 다음과 같은 몇 가지 한계에 부딪힙니다.
- 고차원은 연산 비용을 높이고 검색 성능을 떨어뜨릴 수 있습니다.
- 벡터 표현과 실제 의미 사이의 시맨틱 격차로 인해 부정확한 결과가 나올 수 있습니다.
- 가비지 수집이 어려워져 인덱스에서 오래된 정보를 제거하기 힘들어집니다.
- 벡터의 품질은 선택한 임베딩 모델에 따라 달라지며, 이는 검색 정확도에 영향을 미칩니다.
- 확장성 요구가 커지면 메모리 요구량이 늘어나고 검색 시간이 길어질 수 있습니다.
- 콜드 스타트 문제로 인해 좋은 벡터 표현이 없으면 새 항목을 검색하기 어렵습니다.
- 해석 가능성이 낮아서 특정 검색 결과가 왜 나타났는지 파악하기 어려울 수 있습니다.
이러한 과제 때문에 10억 벡터 문제는 최신 AI에서 가장 어려운 문제 중 하나가 됩니다.
알고리즘 선택이 중요한 이유
어떤 알고리즘을 선택하느냐에 따라 10억 벡터 문제를 해결하는 방식이 직접적으로 달라집니다. HNSW와 같은 알고리즘을 선택하면 대규모 데이터셋에서도 빠른 액세스와 효율적인 검색을 얻을 수 있습니다. 다만 많은 RAM이 필요하므로 비용이 늘어날 수 있습니다. 완전 탐색 KNN 같은 다른 알고리즘은 정확도는 높지만 훨씬 많은 연산이 필요해서 소규모 데이터셋에 더 적합합니다. 올바른 알고리즘을 고르면 속도, 정확도, 리소스 사용 사이에서 균형을 맞출 수 있습니다. 애플리케이션의 요구에 맞춰 알고리즘을 선택하면 특정 환경에 맞게 성능을 최적화할 수 있습니다. 이 결정은 방대한 데이터셋을 얼마나 잘 처리하고 하드웨어에 얼마를 지출할지를 좌우합니다.
Azure AI Search 개요
Azure AI Search는 10억 벡터 문제를 해결할 수 있는 강력한 플랫폼을 제공합니다. 고급 정리 및 보강 도구로 데이터를 사전 처리할 수 있으므로 인덱싱 전에 벡터의 품질을 높일 수 있습니다. 이 플랫폼은 정보를 검색 작업과 최신 검색 요구에 맞게 설계된 벡터 데이터베이스로 구성합니다. 시맨틱 이해를 위한 자연어 처리를 포함한 견고한 검색 및 조회 기능을 활용할 수 있습니다. 또한 암호화와 액세스 제어를 갖추고 있어 데이터를 강력하게 보호합니다.
Azure AI Search는 다른 Microsoft Azure 서비스 및 서드파티 플랫폼과 원활하게 통합됩니다. 키워드 검색과 벡터 검색을 결합한 하이브리드 검색을 사용하면 최상의 결과를 얻을 수 있습니다. 순위 지정과 관련성 튜닝을 통해 검색 결과의 표시 방식을 조정할 수 있으므로 사용자에게 더 유용한 결과를 제공할 수 있습니다. 이 플랫폼은 자동 완성, 추천 결과 등 스마트 검색 환경도 제공합니다. Azure의 글로벌 인프라를 기반으로 구축된 Azure AI Search는 대규모 데이터 세트와 대규모 데이터 프로젝트에 필요한 확장성과 안정성을 제공합니다.
그래프 기반 인덱스: HNSW와 DiskANN

HNSW란 무엇인가
HNSW라는 이름을 들어보셨을 것입니다. 계층적 탐색 가능 소세계(hierarchical navigable small world)의 약자입니다. 이 그래프 기반 인덱스 알고리즘은 대규모 데이터 세트에서 유사한 벡터를 빠르게 찾는 데 도움이 됩니다. HNSW는 데이터 포인트를 연결하는 다중 계층 그래프 구조를 구성하여 검색을 빠르고 정확하게 만듭니다. 그래프의 각 계층은 밀도가 다릅니다. 상위 계층은 노드가 적고 하위 계층은 노드가 많습니다. 이러한 설계 덕분에 상위 계층에서 검색을 시작해 아래로 내려가며 결과 범위를 점차 좁힐 수 있습니다. HNSW는 메모리 내 벡터 검색에 최적화되어 있어 전체 그래프를 RAM에 보관합니다. 이 방식은 지연 시간이 짧은 결과를 제공하지만, 데이터 세트가 커지면 많은 메모리가 필요하다는 뜻이기도 합니다.
DiskANN이란 무엇인가
DiskANN은 수십억 규모의 벡터 검색이 직면한 과제에 대한 Microsoft의 해답입니다. 이 그래프 기반 인덱스는 메모리와 SSD 스토리지를 결합한 하이브리드 방식을 사용합니다. DiskANN을 사용하면 인덱스의 대부분을 RAM보다 훨씬 저렴한 SSD에 저장할 수 있습니다. 메모리에는 가장 중요한 탐색 데이터만 유지하면 됩니다. 이러한 설계 덕분에 높은 하드웨어 비용 없이 대규모 데이터 세트를 관리할 수 있습니다. DiskANN은 Vamana 그래프 알고리즘을 사용하여 데이터 내에서 검색을 안내합니다. 또한 그래프를 다양하고 효율적으로 유지하기 위한 특수한 가지치기(pruning) 방식을 사용합니다. Microsoft의 DiskANN은 Azure AI Search 및 기타 서비스의 기반이 되며, 엔터프라이즈 AI를 위한 핵심 혁신입니다.
| 혁신 | 설명 |
|---|---|
| 고속 ANN 검색 | DiskANN의 아키텍처는 SSD에서 효율적인 ANN 검색을 가능하게 하여 하드웨어 비용을 줄이는 데 도움을 줍니다. |
| 하이브리드 메모리 시스템 | DiskANN은 DRAM과 SSD를 결합하여 단일 머신에서 수십억 개의 포인트를 관리합니다. |
| 비용 효율적인 스토리지 | DiskANN은 ANN 인덱스를 디스크에 저장하여 고차원 데이터 처리를 위한 경제적인 솔루션을 제공합니다. |
HNSW의 작동 방식
그래프 구성
HNSW는 검색 그래프의 계층 구조를 만들어 그래프 기반 인덱스를 구성합니다. 빈 구조에서 시작합니다. 처음 추가하는 벡터가 상위 계층의 유일한 노드가 됩니다. 새로 추가되는 각 벡터에 대해 HNSW는 무작위 과정을 통해 몇 개의 계층에 참여할지 결정합니다. 새 벡터는 할당된 최대 계층까지 각 계층에서 가장 가까운 이웃과 연결됩니다. 상위 계층의 노드가 가장 적어 검색의 좋은 출발점이 됩니다. 하위 계층은 노드가 더 많아 세밀한 검색이 가능합니다. HNSW는 전체 재구축 없이 그래프를 업데이트할 수 있으므로 요구 사항이 늘어나도 새 데이터를 추가할 수 있습니다.
검색 과정
HNSW로 검색할 때는 그래프의 상위 계층에서 시작합니다. 장거리 링크를 사용해 목표 벡터가 있을 법한 영역으로 빠르게 이동합니다. 각 계층을 내려갈수록 연결이 더 촘촘해집니다. 이를 통해 검색 범위를 좁혀 최적의 일치 항목에 더 가까워질 수 있습니다. 가장 하위 계층에서 HNSW는 빔 검색(beam search)을 사용해 최근접 이웃을 찾습니다. 이 과정은 특히 전체 그래프가 메모리에 들어갈 때 빠르고 정확한 결과를 제공합니다.
- HNSW의 설계 원칙:
- 메모리 내 작업에 최적화되어 짧은 지연 시간과 높은 재현율을 제공합니다.
- 소세계 네트워크를 기반으로 한 다중 계층 그래프 구조를 사용합니다.
- 가지치기 전략을 사용해 중복 엣지를 제거하고 다양성을 높입니다.
- 검색 과정은 계층을 내려가는 방식으로, 희소한 장거리 링크로 시작해 기본 계층의 빔 검색으로 끝납니다.
HNSW와 DiskANN은 모두 그래프 기반 인덱스를 사용하지만, 설계는 서로 다른 요구에 맞춰져 있습니다. HNSW는 모든 데이터를 메모리에 보관할 수 있을 때 가장 잘 작동합니다. DiskANN은 SSD를 활용해 수십억 개의 벡터까지 확장할 수 있으므로 Azure AI Search의 엔터프라이즈 워크로드에 이상적입니다.
DiskANN의 작동 방식
하이브리드 메모리 및 SSD 아키텍처
DiskANN으로 수십억 개 벡터를 검색할 때 독특한 접근 방식을 만나게 됩니다. DiskANN은 메모리와 SSD 스토리지를 결합해 하이브리드 아키텍처를 구성합니다. 이 설계 덕분에 벡터 인덱스의 대부분을 RAM보다 저렴한 SSD에 저장할 수 있습니다. 메모리에는 필수적인 탐색 데이터만 유지하면 됩니다. 이 방식을 사용하면 고가의 하드웨어 없이도 수십억 개 벡터까지 검색 규모를 확장할 수 있습니다.
DiskANN은 스토리지와 속도를 최적화하기 위해 두 가지 주요 기법을 사용합니다.
- Vamana 그래프: 인덱스를 효율적으로 탐색하기 위해 이 구조를 사용합니다.
- 제품 양자화(PQ): 메모리에서 벡터를 압축해 RAM 사용량을 줄입니다.
2단계 쿼리 실행 프로세스의 이점을 누릴 수 있습니다. 첫 번째 단계에서 DiskANN은 RAM에 있는 PQ 압축 벡터를 사용해 후보 집합을 빠르게 식별합니다. 이 단계에서는 디스크를 읽을 필요가 없습니다. 두 번째 단계에서 DiskANN은 후보 집합에 대해 SSD에서 전체 정밀도 벡터를 가져옵니다. 그다음 정확한 거리를 계산해 가장 적합한 결과를 찾습니다. 이 프로세스를 통해 메모리 요구량은 낮게 유지하면서도 높은 재현율과 낮은 지연 시간을 얻을 수 있습니다.
팁: DiskANN의 메모리와 SSD 하이브리드 아키텍처는 범용 하드웨어에서도 웹 규모 검색을 가능하게 합니다. 벡터 인덱스를 RAM 대신 SSD에 저장할 수 있으므로 대규모 애플리케이션을 더 합리적인 비용으로 운영할 수 있습니다.
검색 프로세스
DiskANN에서 검색은 메모리에 있는 압축 벡터를 사용해 Vamana 그래프를 탐색하는 것으로 시작합니다. 이 단계에서 유망한 후보를 빠르게 찾을 수 있습니다. 이 단계에서는 디스크 읽기를 피하므로 프로세스가 더 빨라집니다. 후보 집합이 준비되면 DiskANN은 다음 단계로 넘어갑니다.
각 후보에 대해 SSD에서 전체 정밀도 벡터를 가져옵니다. 쿼리와 이들 후보 사이의 정확한 거리를 계산합니다. 이 2단계 프로세스 덕분에 검색 속도를 떨어뜨리지 않고도 정확한 결과를 얻을 수 있습니다. DiskANN이 가장 좋은 후보를 세밀하게 검사하므로 높은 재현율을 달성합니다. 또한 대부분의 작업이 메모리에서 이루어지므로 지연 시간도 낮게 유지됩니다.
DiskANN의 검색 프로세스는 대규모 데이터셋에 잘 맞습니다. 막대한 양의 RAM 없이도 수십억 개 벡터를 처리할 수 있습니다. 데이터가 늘어나도 빠르고 안정적인 결과를 얻을 수 있습니다. 이 때문에 DiskANN은 Azure AI Search에서 엔터프라이즈 AI 워크로드에 적합한 선택지가 됩니다.
| 단계 | 수행 작업 | 이점 |
|---|---|---|
| 1단계: 탐색 | RAM의 PQ 압축 벡터를 사용해 후보를 찾음 | 빠른 검색, 디스크 읽기 없음 |
| 2단계: 정제 | SSD에서 전체 정밀도 벡터를 가져와 거리를 계산함 | 높은 재현율, 낮은 지연 시간 |
DiskANN의 하이브리드 아키텍처와 검색 프로세스 덕분에 수십억 개 벡터 문제를 효율적으로 해결할 수 있습니다. 데이터가 늘어나도 검색 규모를 확장하고 비용을 줄이며 성능을 유지할 수 있습니다.
장단점
HNSW의 장단점
HNSW는 최첨단 수준의 검색 속도와 높은 재현율을 제공하기 때문에 벡터 검색에 자주 선택하게 됩니다. HNSW를 제대로 튜닝하면 빠르고 정확한 결과를 얻을 수 있습니다. 최신 AI 워크로드에서 중요한 고차원 벡터 데이터도 잘 처리합니다. 또한 증분 추가를 지원하므로 모든 것을 다시 구축하지 않고도 인덱스를 업데이트할 수 있습니다.
HNSW의 장단점을 간단히 정리하면 다음과 같습니다.
| 장점 | 단점 |
|---|---|
| 적절히 튜닝하면 최첨단 수준의 검색 속도와 높은 재현율을 제공합니다. | 벡터마다 그래프 링크를 저장하므로 메모리 사용량이 많습니다. |
| 고차원 데이터를 잘 처리합니다. | 고품질 구축 매개변수를 사용하면 인덱스 구축 시간이 깁니다. |
| 증분 추가를 효율적으로 지원합니다. | 요소 삭제가 복잡해 시간이 지나면서 성능이 저하될 수 있습니다. |
인덱스 구축에 O(N log N)을 사용하므로 HNSW는 효율적으로 확장됩니다. 병렬 구축을 활용하면 멀티코어 프로세서를 사용할 수 있어 속도가 빨라집니다. 메모리 사용량은 데이터셋 크기에 비례해 선형으로 증가하므로 스토리지 요구량을 예측할 수 있습니다. 다만 전체 그래프를 RAM에 유지해야 하므로 수십억 개 벡터 데이터셋에서는 확장성에 한계가 있습니다.
DiskANN의 장단점
RAM으로 감당할 수 있는 범위를 넘어 벡터 검색을 확장해야 할 때 DiskANN을 선택하게 됩니다. DiskANN은 SSD 사용에 최적화되어 있어 하드웨어 비용을 줄이고 대규모 데이터셋을 관리할 수 있게 해 줍니다. 메모리 내 검색과 일괄 SSD 읽기를 결합해 높은 정확도와 낮은 지연 시간을 얻을 수 있습니다. 또한 DiskANN은 실시간 업데이트와 하이브리드 검색을 지원하므로 벡터를 효율적으로 필터링하고 검색할 수 있습니다.
DiskANN에 대해 다음 사항을 고려해 보십시오.
- RAM 대신 SSD를 사용해 비용 효율적으로 확장할 수 있습니다.
- 메모리 내 검색과 SSD 읽기를 통해 규모가 커도 높은 정확도와 낮은 지연 시간을 제공합니다.
- 실시간 업데이트와 벡터 및 필터 결합 하이브리드 검색
- Vamana 그래프 구축은 계산 부하가 커서 빌드 시간이 깁니다.
- 성능은 SSD의 처리량과 지연 시간에 따라 달라집니다.
- 업데이트 비용은 HNSW 같은 인메모리 구조에 비해 더 높습니다.
- 구현과 튜닝에는 신중한 최적화가 필요합니다.
DiskANN은 양자화된 벡터를 처리할 수 있어서 이점이 있습니다. 데이터를 압축해 메모리 효율적인 검색을 가능하게 합니다. RAM 한계를 걱정하지 않고 DiskANN으로 수십억 벡터 워크로드를 처리할 수 있습니다.
메모리 및 스토리지 효율성
벡터 검색에 HNSW와 DiskANN 중 무엇을 선택할지 고민할 때는 메모리와 스토리지 효율성을 반드시 고려해야 합니다. HNSW는 데이터셋이 서버 RAM에 들어갈 때 잘 작동합니다. 빠른 액세스와 높은 성능을 얻을 수 있지만 메모리 한계를 넘어 확장할 수는 없습니다. DiskANN은 데이터셋 크기를 디스크 용량까지 늘릴 수 있으며, 그 대가로 속도를 일부 포기합니다. 인덱스의 대부분을 SSD에 저장하므로 DiskANN은 대규모 벡터 데이터셋에 이상적입니다.
| 기능 | HNSW | DiskANN |
|---|---|---|
| 메모리 효율성 | 서버 캐시(RAM)에 들어가는 데이터셋에 매우 효율적입니다. | RAM에 들어가기 어려울 만큼 큰 데이터셋을 위해 설계되었습니다. |
| 스토리지 효율성 | 사용 가능한 RAM 용량에 의해 제한됩니다. | 데이터셋 크기를 디스크 용량까지 확장하며, 그 대가로 속도를 일부 포기합니다. |
| 성능 최적화 | 빠른 메모리 액세스를 활용해 속도를 높입니다. | 느린 디스크 스토리지에 따른 성능 저하를 최소화합니다. |
| 데이터셋 적합성 | RAM에 들어가는 데이터셋에 적합합니다. | RAM 용량을 넘는 대규모 데이터셋에 적합합니다. |
HNSW와 DiskANN 모두 양자화된 벡터를 사용해 스토리지 요구량을 줄이고 검색 속도를 높일 수 있습니다. DiskANN의 하이브리드 아키텍처를 사용하면 비용을 낮게 유지하면서 벡터 검색 규모를 확장할 수 있습니다. 특히 양자화된 벡터와 SSD 스토리지를 함께 사용하면 대규모 검색 작업에서도 메모리 효율적인 검색을 구현할 수 있습니다.
벡터 검색 알고리즘 비교

규모에 따른 성능
데이터셋이 커질 때 벡터 검색 알고리즘의 성능을 측정해야 합니다. HNSW와 DiskANN은 모두 높은 재현율과 속도를 목표로 하지만 접근 방식이 다릅니다. HNSW는 인메모리 그래프에 의존하므로 벡터가 RAM에 들어갈 때 빠른 최근접 이웃 검색을 얻을 수 있습니다. DiskANN은 메모리와 SSD를 결합한 하이브리드 방식을 사용하므로 메모리 한계를 걱정하지 않고 검색 성능을 확장할 수 있습니다.
수백만 개의 벡터에 대해 최근접 이웃 검색을 수행하면 HNSW는 고속 검색과 낮은 지연 시간을 제공합니다. 재현율과 속도를 위해 매개변수를 조정할 수 있습니다. DiskANN은 데이터셋이 늘어나도 높은 재현율과 속도를 유지합니다. 인덱스의 대부분을 SSD에 저장하므로 수십억 개의 벡터도 처리할 수 있습니다. 두 단계 검색을 사용해 속도와 정확도의 균형을 맞출 수 있습니다. 첫 번째 단계에서는 메모리에서 후보를 찾고, 두 번째 단계에서는 SSD를 사용해 결과를 정제합니다.
두 알고리즘 모두 높은 재현율과 속도를 달성할 수 있지만, DiskANN을 사용하면 RAM 한계를 넘어 검색 성능을 확장할 수 있습니다.
수십억 개 벡터를 위한 확장성
데이터셋이 수백만 개에서 수십억 개의 벡터로 늘어나면 새로운 과제에 직면하게 됩니다. HNSW는 최대 5천만 개의 벡터까지 잘 작동합니다. 기본 벡터 검색 알고리즘으로 HNSW를 사용하고 재현율을 위해 매개변수를 조정합니다. 5천만~5억 개의 벡터에 이르면 샤딩과 스칼라 양자화를 적용합니다. 효율성을 위해 두 단계 검색을 고려할 수도 있습니다. 5억 개가 넘는 데이터셋에는 계층적 검색과 다계층 아키텍처가 필요합니다. 콜드 데이터에는 공격적인 양자화를 사용합니다.
| 벡터 수 범위 | HNSW 전략 |
|---|---|
| 1~5천만 | 기본 알고리즘으로 HNSW를 사용하고, 벡터가 RAM에 들어가도록 보장하며, 재현율을 위해 매개변수를 조정합니다. |
| 5천만~5억 | 샤딩을 적용하고, 스칼라 양자화를 활성화하며, 효율성을 위해 두 단계 검색을 고려합니다. |
| 5억 이상 | 계층적 검색, 다계층 아키텍처를 사용하고, 콜드 데이터에는 공격적인 양자화를 적용합니다. |
DiskANN은 수십억 규모의 벡터 검색에서 판도를 바꿉니다. 인덱스의 대부분을 SSD에 저장하므로 RAM 한계를 걱정할 필요가 없습니다. 제품 양자화를 사용해 벡터를 압축하고, 탐색 데이터는 메모리에 유지합니다. 검색 성능을 희생하지 않고 최근접 이웃 검색을 수십억 개의 벡터로 확장할 수 있습니다. DiskANN은 클러스터링 기반 근사 검색과 하이브리드 검색을 지원하므로 대규모 데이터셋을 관리하는 데 도움이 됩니다.
DiskANN을 사용하면 수십억 개의 벡터를 대상으로 벡터 검색 알고리즘을 확장할 수 있어 엔터프라이즈 워크로드에 이상적입니다.
쿼리 지연 시간과 처리량
대규모로 벡터 검색을 실행할 때는 쿼리 지연 시간과 처리량을 중요하게 보셔야 합니다. HNSW는 그래프 전체를 메모리에 유지하기 때문에 최근접 이웃 검색의 지연 시간이 낮습니다. RAM에 들어가는 데이터셋이라면 빠른 쿼리 응답과 높은 처리량을 얻을 수 있습니다. 데이터셋이 커지면 샤딩을 하거나 다계층 아키텍처를 사용하면서 지연 시간이 늘어납니다.
DiskANN은 두 단계 검색 과정을 사용합니다. 먼저 메모리에 있는 압축 벡터를 검색해 후보를 빠르게 선별합니다. 그다음 SSD에서 전체 정밀도 벡터를 가져와 쿼리 결과를 정제합니다. 이 방식은 수십억 개 규모의 데이터셋에서도 지연 시간을 낮게 유지하고 높은 처리량을 보장합니다. SSD 읽기를 일괄 처리하고 효율적인 탐색 구조를 사용하면 검색 성능을 더 최적화할 수 있습니다.
DiskANN을 사용하면 쿼리 양이 늘어나도 높은 재현율과 속도를 확보할 수 있습니다. 메모리 한도를 걱정할 필요가 없으므로 엔터프라이즈 애플리케이션에서 검색 성능을 확장할 수 있습니다.
DiskANN을 사용하면 쿼리 지연 시간과 처리량을 안정적으로 유지할 수 있어, 대규모 최근접 이웃 검색에 적합한 선택입니다.
비용 및 리소스 영향
Azure AI Search에서 벡터 검색 알고리즘을 선택할 때는 비용과 리소스 영향을 반드시 고려해야 합니다. 알고리즘마다 메모리와 스토리지를 사용하는 방식이 다르기 때문에 예산과 확장 능력에 차이가 생깁니다.
DiskANN은 수십억 개 벡터 워크로드에서 특히 돋보입니다. 인덱스의 대부분을 RAM보다 저렴한 SSD에 저장할 수 있습니다. 이 설계 덕분에 메모리 비용을 크게 늘리지 않고도 수천 개에서 수십억 개 벡터까지 확장할 수 있습니다. DiskANN은 SSD를 효율적으로 활용하고 가장 중요한 데이터만 메모리에 유지하므로 프로덕션 AI 워크로드에 적합합니다.
HNSW는 중간 규모 데이터셋에 가장 적합합니다. 전체 인덱스를 RAM에 유지해야 하므로 확장에 제약이 있습니다. 데이터셋이 지나치게 커지면 운영 비용이 높아질 수 있습니다. 또한 HNSW는 2,000차원으로 제한되어 사용 사례가 제한될 수 있습니다.
| 인덱스 유형 | 수십억 벡터 워크로드 적합성 | 메모리 요구 사항 | 운영 비용 |
|---|---|---|---|
| DiskANN | 예, SSD 성능에 맞게 설계됨 | 수천 개에서 수십억 개 벡터까지 확장 가능 | 프로덕션 AI 워크로드에 권장 |
| HNSW | 아니요, 중간 규모 데이터셋에 적합 | 인덱스가 RAM에 들어가야 함 | 2,000차원으로 제한 |
팁: 비용을 관리하면서 검색을 수십억 개 벡터 규모로 확장하려면 DiskANN이 분명한 이점을 제공합니다. 저렴한 SSD를 활용하고 메모리 요구량을 낮게 유지할 수 있습니다.
실제 사용 사례
이러한 알고리즘의 가치는 실제 애플리케이션에서 확인할 수 있습니다. 많은 조직이 서로 다른 유형의 벡터 검색 문제에 DiskANN과 HNSW를 활용하고 있습니다.
- 근사 최근접 이웃 검색에는 비용 효율적인 하이브리드 방식을 사용할 수 있습니다. 이 방식은 SSD 스토리지와 메모리 내 그래프 구조를 결합합니다.
- 연구 코퍼스처럼 데이터가 자주 바뀌지 않는 정적 데이터셋에는 DiskANN을 배포할 수 있습니다.
- 비용에 민감한 배포에는 DiskANN을 선택할 수 있습니다. 비용을 통제해야 하는 수십억 규모 애플리케이션에 적합합니다.
- 지연 시간이 10밀리초 미만이어도 괜찮은 쿼리에는 DiskANN을 사용할 수 있습니다. 이 속도는 많은 엔터프라이즈 검색 작업에 충분히 빠릅니다.
- 하이브리드 검색을 위해 HNSW를 디스크 기반 역인덱스(HNSW-IF)와 결합할 수 있습니다. 이 방식은 높은 재현율을 달성하면서 지연 시간을 낮게 유지합니다.
| 사용 사례 | 설명 |
|---|---|
| 정적 데이터셋 | 데이터가 자주 바뀌지 않는 연구 코퍼스에 이상적입니다. |
| 비용에 민감한 배포 | 비용이 문제가 되는 수십억 규모 애플리케이션에 적합합니다. |
| 지연 시간 허용 쿼리 | 지연 시간이 10ms 미만이어도 괜찮은 쿼리에 적합합니다. |
참고: 많은 조직이 하이브리드 방식을 사용해 10ms 지연 시간에서 90% 재현율을 달성합니다. 이 성능은 대부분의 엔터프라이즈 AI 검색 애플리케이션 요구를 충족합니다.
워크로드에 맞게 알고리즘을 선택하면 됩니다. 확장, 비용 관리, 낮은 지연 시간이 모두 필요하다면 DiskANN이 필요한 유연성과 효율성을 제공합니다.
HNSW 또는 DiskANN 선택 시점
Azure AI Search 워크로드에 맞는 알고리즘을 선택하면 속도, 비용, 정확도에 큰 차이가 생길 수 있습니다. 데이터, 하드웨어, 데이터 변경 빈도를 함께 살펴봐야 합니다. 벡터 검색 요구에 가장 적합한 도구를 고를 수 있도록 주요 결정 기준을 정리해 보겠습니다.
결정 기준
데이터셋 크기
먼저 데이터셋의 규모부터 살펴보는 것이 좋습니다. 수백만 개의 벡터를 다룬다면 HNSW가 빠르고 정확한 검색 결과를 제공합니다. HNSW는 데이터가 메모리에 들어갈 때 가장 잘 작동합니다. 데이터셋이 수십억 개의 벡터로 커지면 DiskANN이 더 나은 선택이 됩니다. DiskANN은 인덱스의 대부분을 SSD에 저장하므로 RAM이 부족해질 걱정을 하지 않아도 됩니다.
| 기준 | HNSW | DiskANN |
|---|---|---|
| 데이터셋 규모 | 수백만 개의 벡터에 적합 | 수십억 개의 벡터에서 강점을 보임 |
HNSW는 소규모 워크로드에 적합하고, DiskANN은 속도 저하 없이 대규모 데이터셋을 처리한다는 점을 확인할 수 있습니다.
하드웨어와 비용
하드웨어와 예산도 큰 역할을 합니다. HNSW는 그래프 전체를 메모리에 유지하기 때문에 많은 RAM이 필요합니다. 벡터 데이터베이스가 커질수록 이 비용은 높아질 수 있습니다. DiskANN은 인덱스의 대부분을 RAM보다 저렴한 SSD에 저장하여 비용을 절감하는 데 도움이 됩니다. 인덱스의 탐색 부분을 위한 메모리만 있으면 됩니다.
| 기준 | HNSW | DiskANN |
|---|---|---|
| 인프라 | RAM 요구 사항 | 메모리 비용 절감 |
비용을 낮게 유지하면서 수십억 개의 벡터를 검색하려면 DiskANN이 분명한 이점을 제공합니다.
지연 시간 요구 사항
검색 결과를 얼마나 빨리 받아야 하는지도 고려해야 합니다. HNSW는 메모리에서 검색하기 때문에 지연 시간이 매우 낮습니다. 데이터가 RAM에 들어갈 수 있다면 결과를 단 몇 밀리초 만에 얻을 수 있습니다. DiskANN은 속도와 규모의 균형을 맞춥니다. 두 단계의 검색 과정을 사용하므로 데이터셋이 매우 커도 빠른 결과를 얻을 수 있습니다. 대부분의 엔터프라이즈 애플리케이션에서 DiskANN은 쿼리 시간을 10밀리초 미만으로 유지합니다.
- HNSW는 밀리초 단위의 차이가 중요한 워크로드에 가장 적합합니다.
- DiskANN은 대규모 데이터셋을 빠르게 검색해야 하면서 지연 시간이 약간 늘어나는 것을 감수할 수 있을 때 효과적입니다.
업데이트 패턴
데이터가 얼마나 자주 변경되는지도 선택에 영향을 줍니다. HNSW는 정적이거나 변경이 느린 데이터에 잘 맞습니다. 벡터를 자주 업데이트한다면 인덱스를 다시 빌드해야 할 수 있으며, 이 작업에는 시간이 걸립니다. DiskANN은 빈번한 업데이트에 더 잘 적응합니다. 벡터를 자주 추가하거나 변경하더라도 정확도와 재현율을 안정적으로 유지합니다.
| 기능 | HNSW | DiskANN |
|---|---|---|
| 업데이트 지연 시간 | 인덱스 전체를 다시 빌드해야 함 | 변경 사항에 효율적으로 적응함 |
| 재현율 | 높지만 변경의 영향을 받음 | 잦은 변경에도 정확도가 안정적임 |
애플리케이션이 많은 업데이트를 처리해야 한다면 DiskANN이 더 큰 유연성을 제공합니다.
예시 시나리오
실제 시나리오를 참고하면 어떤 알고리즘이 요구 사항에 맞는지 판단하는 데 도움이 됩니다.
| 지표 | HNSW | DiskANN |
|---|---|---|
| 평균 재현율 | 0.6 | 0.7 |
| 엔드 투 엔드 정확도 | 0.972 | 0.933 |
| Robustness-0.2@10 | 0.998 | 0.984 |
| Robustness-0.9 | 0.84 | 0.81 |
- HNSW는 높은 재현율과 빠른 쿼리 처리량을 제공합니다. SIFT1M과 같은 데이터셋에서 CPU 기준으로 쿼리당 1~2밀리초 만에 10개 결과 기준 약 95%의 재현율에 도달할 수 있습니다.
- DiskANN은 평균 재현율이 더 높게 나타납니다. 이는 대규모 데이터셋에서 실제 일치 항목을 더 많이 찾는다는 의미입니다. 데이터가 늘어나도 정확도를 높게 유지합니다.
- HNSW는 최고 수준의 정확도와 속도가 필요한 추천 시스템이나 검색 엔진에 가장 적합합니다.
- DiskANN은 수십억 개의 제품 이미지나 문서를 검색하는 것처럼 속도, 비용, 규모의 균형이 필요한 대규모 검색에 적합합니다.
HNSW는 소규모 데이터셋에서 가능한 가장 빠른 검색이 필요한 워크로드에서 두드러집니다. DiskANN은 예산을 크게 초과하지 않으면서 방대한 양의 데이터를 검색해야 할 때 빛을 발합니다.
마이그레이션과 하이브리드 접근 방식
모든 상황에서 알고리즘 하나만 선택해야 하는 것은 아닙니다. 많은 조직은 소규모 데이터셋에는 HNSW로 시작합니다. 벡터 데이터베이스가 커지면 더 많은 데이터를 처리하고 비용을 낮추기 위해 DiskANN으로 전환합니다. 하이브리드 방식을 사용할 수도 있습니다. 예를 들어 가장 자주 사용되거나 최근의 벡터는 HNSW로 메모리에 보관하고, 오래되었거나 사용 빈도가 낮은 벡터는 DiskANN으로 SSD에 저장할 수 있습니다.
- 빠른 프로토타이핑과 소규모 워크로드에는 HNSW로 시작하십시오.
- 데이터셋이 메모리 한계를 넘으면 DiskANN으로 마이그레이션하십시오.
- 두 방식을 결합하면 속도와 규모의 최적 균형을 얻을 수 있습니다.
팁: 워크로드를 주기적으로 검토하십시오. 데이터와 요구 사항이 바뀌면 접근 방식을 조정하여 최고의 성능과 가치를 얻을 수 있습니다.
데이터셋 규모, 하드웨어, 지연 시간 요구 사항, 업데이트 패턴을 이해하면 HNSW와 DiskANN 중에서 현명한 선택을 할 수 있습니다. 이를 통해 목표에 맞고 비즈니스와 함께 성장하는 벡터 검색 시스템을 구축할 수 있습니다.
Azure의 벡터 검색 모범 사례
인덱스 구성 팁
Azure AI Search에서 높은 성능을 얻으려면 몇 가지 중요한 구성 팁을 따르면 됩니다. 먼저 인덱스 크기가 단일 벡터 검색 단위 안에 들어가도록 하십시오. 이렇게 하면 검색을 빠르고 안정적으로 유지하는 데 도움이 됩니다. 임베딩 크기는 가능한 한 줄이십시오. 임베딩이 작을수록 쿼리 시간이 단축되고 초당 쿼리 수가 늘어납니다. 효율을 높이려면 ANN(Approximate Nearest Neighbor) 쿼리를 사용하십시오. 정확도를 크게 희생하지 않으면서 검색 속도를 높여 줍니다.
쿼리당 결과 수는 10개에서 100개 사이로 유지하십시오. 이 범위는 지연 시간을 줄이고 검색 응답성을 유지하는 데 도움이 됩니다. 운영 환경에서는 0으로 축소되는(scale to zero) 모델 엔드포인트를 사용하지 마십시오. 콜드 스타트는 검색 속도를 떨어뜨리고 사용자에게 불편을 줄 수 있습니다. 검색 트래픽이 갑자기 늘어나도 시스템이 감당할 수 있도록 쿼리 급증에 대비하십시오. 안전하고 효율적인 인증을 위해서는 OAuth 토큰과 함께 서비스 주체(service principal)를 사용하십시오. 성능 개선 사항을 활용하려면 항상 최신 버전의 Python SDK를 사용하십시오. 더 높은 처리량이 필요하면 엔드포인트를 확장하거나 여러 엔드포인트에 작업을 분산하십시오.
팁: 잘 구성된 인덱스는 Azure에서 최적화된 벡터 검색의 기반입니다.
모니터링 및 최적화
특히 수십억 개 벡터 워크로드에서 높은 성능을 유지하려면 검색 시스템을 지속적으로 모니터링하고 최적화해야 합니다. 아래 표는 효과적인 기법을 보여 줍니다.
| 기법 | 설명 |
|---|---|
| 다계층 인덱스 | 자주 사용하는 데이터에는 빠른 인덱스를 사용하고, 자주 사용하지 않는 데이터는 압축해 공간을 절약하십시오. |
| 팬아웃 제어 | 샤드와 클러스터 간 상호 작용을 관리해 네트워크 홉을 줄이십시오. |
| 양자화 | IVF-PQ와 같은 방법으로 벡터 크기를 줄여 메모리 한도에 맞추십시오. |
| 센트로이드 튜닝 | 센트로이드 수를 조정해 재현율과 오버헤드의 균형을 맞추십시오. |
| 비대칭 거리 계산 | 전체 정밀도 쿼리를 압축된 벡터와 비교해 검색 속도를 높이십시오. |
| 의도적 쿼리 라우팅 | 메타데이터와 클러스터링을 활용해 검색 중 불필요한 브로드캐스트를 피하십시오. |
| 네트워크 페이로드 최소화 | 노드 간에는 전체 벡터가 아니라 ID와 점수만 전송하십시오. |
| 계층적 집계 | 결과를 로컬에서 집계해 조정 작업을 줄이고 지연 시간을 안정시키십시오. |
| 메모리 우선 | 최상의 검색 성능을 위해 벡터가 메모리에 모두 들어가도록 하십시오. |
| 상황에 따른 GPU 사용 | 필요하면 인덱싱에 GPU를 사용하되, 검색 처리량 향상에 실제로 도움이 되는지 확인하십시오. |
| 네트워크 품질 | 네트워크 상태는 검색 지연 시간에 영향을 주므로 지속적으로 모니터링하십시오. |
참고: 정기적인 모니터링은 문제를 조기에 발견하고 검색이 원활하게 동작하도록 유지하는 데 도움이 됩니다.
흔한 함정
Azure에서 검색 시스템을 설정하거나 확장할 때 흔히 마주치는 함정이 있습니다. 대표적인 실수는 단일 검색 단위에 비해 인덱스가 지나치게 커지도록 방치하는 것입니다. 이 경우 쿼리가 느려지고 검색 안정성도 떨어질 수 있습니다. 큰 임베딩을 사용하는 것도 성능을 해칠 수 있습니다. 사용 사례에 맞는 범위에서 임베딩은 항상 최대한 작게 유지하십시오.
또 다른 함정은 쿼리 급증을 무시하는 것입니다. 검색 트래픽이 갑자기 늘어나는 상황에 대비하지 않으면 시스템이 부하를 견디지 못하고 실패할 수 있습니다. 0으로 축소되는 엔드포인트에 의존하면 콜드 스타트 지연이 발생해 검색 속도가 느려집니다. SDK를 업데이트하지 않거나 OAuth 토큰을 사용하지 않으면 보안 위험이 생기고 성능 개선 기회도 놓치게 됩니다.
참고: 이러한 함정을 피하면 검색을 빠르고 안전하며 안정적으로 유지할 수 있습니다.
이러한 모범 사례를 따르면 Azure에서 견고하고 효율적인 검색 환경을 구축할 수 있습니다. 대용량 데이터셋도 손쉽게 처리하고, 사용자에게 빠르고 정확한 결과를 제공할 수 있습니다.
Azure AI Search에서 수십억 벡터 문제는 요구 사항에 맞는 알고리즘을 선택하면 해결할 수 있습니다. DiskANN은 대규모 데이터셋에 비용 효율적인 확장성을 제공하고, HNSW는 규모가 작은 워크로드에서 빠른 결과를 제공합니다. 워크로드, 규모, 예산에 맞춰 알고리즘을 선택하십시오. 아래 표는 적합한 엔드포인트를 고르는 데 도움이 됩니다.
| SKU 유형 | 사용 사례 설명 |
|---|---|
| 표준 엔드포인트 | 지연 시간이 중요하고 인덱스가 3억 2천만 개 벡터 미만인 경우에 적합합니다. |
| 스토리지 최적화 엔드포인트 | 벡터가 1,000만 개 이상이고 일부 지연 시간을 감수할 수 있으며 비용 효율이 필요한 경우에 이상적입니다. |
- 문서 몇 개로 테스트해 스토리지 요구 사항을 추정하십시오.
- 업데이트와 전체 콘텐츠 양을 고려해 계획하십시오.
Azure AI Search는 유연성을 제공하며 엔터프라이즈 AI를 위한 Microsoft의 혁신을 지원합니다. 이러한 기술적 인사이트를 실제 클라우드 아키텍처와 연결해 보려면 함께 제공되는 팟캐스트 에피소드 HNSW vs DiskANN for Vector Search in Azure AI Search를 꼭 들어 보십시오.
자주 묻는 질문
HNSW와 DiskANN의 가장 큰 차이점은 무엇인가요?
HNSW는 메모리 내 벡터 검색에 사용합니다. DiskANN은 인덱스의 대부분을 SSD에 저장할 수 있게 해 줍니다. 그래서 메모리 비용을 크게 늘리지 않고도 수십억 개의 벡터를 처리하는 데 DiskANN이 더 적합합니다.
DiskANN을 실시간 애플리케이션에 사용할 수 있나요?
네, 가능합니다. DiskANN은 지연 시간이 짧은 검색을 제공하며, 대개 10밀리초 미만입니다. 데이터셋이 매우 커도 실시간 AI 검색 작업에 사용할 수 있습니다.
Azure AI Search에서 어떤 알고리즘을 사용할지 어떻게 결정하나요?
RAM에 들어가는 더 작은 데이터셋에는 HNSW를 선택합니다. 비용 효율적인 확장이 필요한 대규모 데이터셋에는 DiskANN을 선택합니다. 데이터 크기, 하드웨어, 지연 시간 요구 사항을 함께 고려하세요.
DiskANN에는 특별한 하드웨어가 필요한가요?
아니요. SSD가 장착된 일반 서버에서 DiskANN을 실행할 수 있습니다. 값비싼 고용량 메모리 장비는 필요하지 않습니다. 그래서 확장이 더 쉽고 비용 부담도 줄어듭니다.
Azure AI Search는 데이터를 어떻게 안전하게 보호하나요?
Azure AI Search는 암호화와 액세스 제어를 사용합니다. 데이터에 접근할 수 있는 사용자는 직접 관리합니다. Microsoft의 보안 기능을 활용하면 민감한 정보를 보호하는 데 도움이 됩니다.
다운타임 없이 벡터 인덱스를 업데이트할 수 있나요?
HNSW와 DiskANN 인덱스 모두 업데이트할 수 있습니다. DiskANN은 대규모 데이터셋에서도 효율적인 업데이트를 지원합니다. 시스템을 중단하지 않고도 검색 결과를 최신 상태로 유지할 수 있습니다.
벡터 검색 성능을 최적화하기 위한 모범 사례에는 무엇이 있나요?
더 작은 임베딩을 사용하고, 인덱스를 단일 검색 단위 안에 유지하며, 쿼리 지연 시간을 모니터링하세요. 또한 항상 SDK를 최신 버전으로 업데이트하고, 쿼리 급증에 대비한 계획을 세워 높은 성능을 유지하세요.
🎧 이 에피소드 듣기
Azure AI Search의 Vector Search에서 HNSW와 DiskANN을 비교하는 실용적인 설명을 원하신다면, 이 에피소드가 도움이 됩니다. 이 주제를 명확하게 풀어 설명하고, Microsoft 365, Azure, Power Platform, 보안, AI, 그리고 현대적인 업무 환경에서 왜 중요한지 보여 드립니다.
다음과 같은 내용을 알고 싶다면 이 에피소드를 들어 보세요:
- Azure AI Search의 Vector Search에서 HNSW와 DiskANN의 핵심 개념 이해하기
- Microsoft 기술 생태계 전반에서 이 주제가 어떻게 적용되는지 살펴보기
- 조직에서 실질적인 가치를 만들 수 있는 지점 파악하기
다음 M365 FM 관련 에피소드도 함께 즐겨 보세요:
- 벡터 검색을 넘어 Microsoft Copilot 정확도 높이기
- Azure AI Search – 쉽게 정리한 개념
- Vector Databases - 쉽게 정리한 개념
- 엔터프라이즈 시맨틱 검색을 위한 Microsoft Graph API Discovery
- SharePoint 검색에서 올바른 파일이 먼저 나오게 하기
M365 FM에서 실무에 바로 도움이 되는 Microsoft 이야기를 더 찾아보세요.
최종 검토: 2026년 7월.
누가 들으면 좋을까요
이 에피소드는 구현, 운영, 거버넌스 결정을 내리기 전에 실무적인 기초 지식이 필요한 Microsoft 관리자, 아키텍트, 개발자, 보안 전문가, 그리고 비즈니스 리더를 위한 내용입니다.
🎧 함께 들으면 좋은 에피소드
- Azure Resource Manager — 이 주제를 확장하기 위한 매우 관련성 높은 다음 단계입니다.
- Infrastructure as Code — 이 주제를 확장하기 위한 매우 관련성 높은 다음 단계입니다.
- Azure Policy — 이 주제를 확장하기 위한 매우 관련성 높은 다음 단계입니다.