출처
- source_url: https://aisparkup.com/posts/14909
- author: Spark
- published: Sat, 01 Aug 2026 04:07:30 +0000
- raw: raw source:
2026-08-01-aisparkup-post-14909-db-numpy
벡터DB 없이 numpy 한 줄로 백만 건 검색한 결과
개요
문서가 약 100만 건인 경우에도 벡터DB를 도입하기 전에 NumPy 기반 전수 검색을 검토할 수 있다는 주장입니다. Doug Turnbull은 쿼리 벡터와 전체 문서 임베딩 배열의 내적(dot product)을 계산하는 방식으로, 별도 인덱스나 근사 검색 알고리즘 없이 검색 성능을 측정했습니다. M4 맥북에서 384차원 임베딩 100만 개를 대상으로 단일 스레드 초당 79.7건, 10개 스레드 초당 170.5건을 기록했으며 지연 시간은 약 12~58밀리초였습니다. 글의 핵심은 데이터 규모와 검색 트래픽이 감당 가능한 수준이라면 복잡한 벡터DB 도입을 늦추고 단순한 브루트포스 검색을 먼저 검토하라는 것입니다.
핵심 포인트
- 384차원 임베딩 100만 개를 대상으로 전체 벡터를 순회하며 내적을 계산하는 전수 검색을 수행했습니다.
- 사용한 핵심 연산은 쿼리 벡터와 문서 벡터 배열을 곱하는 NumPy의 dot product 한 번입니다.
- M4 맥북 기준 처리량은 단일 스레드 초당 79.7건, 10개 스레드 초당 170.5건이었습니다.
- 데이터 규모를 884만 건으로 늘렸을 때는 단일 스레드 초당 9.34건, 10개 스레드 초당 18.34건을 기록했습니다.
- 문서 약 100만 건, 낮은 쿼리 트래픽, 사전 임베딩 완료라는 조건에서는 벡터DB가 불필요할 수 있다고 설명합니다.
- 규모가 커지면 벡터DB뿐 아니라 FAISS처럼 전체 데이터를 메모리에 올리는 라이브러리도 대안이 될 수 있으며, 배치 처리와 상위 결과 선별을 통해 성능을 더 개선할 여지가 있다고 덧붙입니다.
왜 중요한가
- 벡터 검색 시스템을 설계할 때 데이터 규모와 트래픽을 먼저 측정하고, 필요한 수준의 가장 단순한 구현부터 검토하게 합니다.
- 전수 검색은 인덱스 구축과 운영 복잡도가 없으므로 초기 프로토타입이나 소규모·저트래픽 서비스에 적합할 수 있습니다.
- 다만 성능 수치는 특정 하드웨어와 조건에서 측정된 결과이므로, 실제 도입 전에는 임베딩 차원·동시성·메모리·검색량을 기준으로 자체 벤치마크가 필요합니다.
참고 링크
- 원문: https://aisparkup.com/posts/14909
- 출처 글: https://softwaredoug.com/blog/2026/07/29/just-brute-force-embeddings.html
관련 위키
원문 보존 위치
원문 전체는 raw source: 2026-08-01-aisparkup-post-14909-db-numpy에 source_url 및 HTML 원문과 함께 저장되어 있습니다.