출처: Dev.to

왜 당신의 벡터 데이터베이스는 과대평가되고 있는가: Lucene의 32배 압축과 서버리스 경제학

2026년, “검색 엔진”과 “AI 인프라” 사이의 경계는 사라졌다. 텍스트 인덱싱으로 시작했던 기술은 이제 검색 보강 생성(RAG), 벡터 데이터베이스, 서버리스 AI 파이프라인의 핵심이 되었다. 이것은 Java 생태계에서 가장 오래된 검색 기술이 어떻게 당신이 눈치채지 못한 가장 중요한 인프라가 되었는지를 보여주는 이야기다.

5년 전만 해도 Apache Lucene이 차세대 AI 인프라를 이끌 것이라고 말한다면 방 안에서 비웃음을 받을 수밖에 없었다. Lucene은 Elasticsearch를 구동하는 지루한 Java 라이브러리였으며—신뢰성은 있었지만 흥미롭지는 않았다. 주목받던 분야는 벡터 데이터베이스였다: Pinecone, Weaviate, Qdrant. 멋진 사람들은 이미 다른 곳으로 떠난 것이었다.

그 이야기는 2025년에 사라졌다.

구조적 역전이 일어났다

벡터‑네이티브 데이터베이스가 한 가지(빠른 유사도 검색)에 최적화된 반면, 실제 운영상의 고통 포인트는 다른 곳에 있었다: 하이브리드 검색, 메타데이터 필터링, 출처 추적, 다중 테넌트 보안, 그리고 가장 중요한 문서와 벡터를 하나의 통합 시스템에서 동시에 조회할 수 있는 능력.

Lucene은 이 전환을 단순히 버텨낸 것이 아니라 직접 설계했다. 버전 10.0부터 10.4까지 진행된 일련의 공격적인 하드웨어‑네이티브 최적화를 통해 Lucene은 텍스트 인덱서에서 벡터 검색 커널로 변모했으며, 특화된 데이터베이스보다 뛰어난 성능을 보이면서도 기업이 실제로 필요로 하는 운영 성숙도를 유지했다.

그리고 Lucene의 뒤를 이어가는 Elasticsearch는 단순히 벡터를 통합한 수준을 넘어, 무상태(serverless) 플랫폼으로 재구성되었다. 이제는 검색을 수행하는 서버리스 서비스가 된 것이다.

이 글에서는 그 변혁을 세 단계로 살펴본다: 엔진(Lucene), 플랫폼(Elasticsearch), 아키텍처(AI‑네이티브 검색 인프라). 각 단계마다 다른 이야기가 있지만, 공통된 실은 “AI 인프라의 미래는 머신러닝 연구자가 아니라 검색 엔지니어가 만든다”는 점이다.

벡터 데이터베이스의 숨은 비밀: 메모리 낭비

대부분의 시스템은 전체 HNSW 그래프를 RAM에 올려두어야 한다. 즉, 인덱스 전체가 메모리에 상주해야 한다는 뜻이다. 10 억 개의 768 차원 벡터라면 수 테라바이트 규모의 RAM이 필요하다. 디스크가 아니라 RAM이다.

Lucene의 접근은 알고리즘이 아니라 아키텍처에 있었다. JVM 힙에 벡터를 저장하는 대신, Lucene은 HNSW 그래프 파일을 메모리‑맵하고 OS 페이지 캐시가 로딩을 담당하도록 했다. 검색 중에 실제로 접근되는 페이지만 메모리에 올리고, 메모리 압박이 생기면 자동으로 내보낸다. 따라서 Lucene의 벡터 검색 메모리 사용량은 인덱스 크기가 아니라 OS 페이지 캐시 크기에 의해 결정된다.

하지만 Lucene은 여기서 멈추지 않았다.

2‑bit 스칼라 양자화: 작은 변화가 모든 것을 바꾸다

Lucene 10.4는 겉보기에 사소해 보이지만 실질적으로는 혁신적인 2‑bit 스칼라 양자화를 도입했다. 이제 차원당 1, 2, 4, 7, 8 bit 로 양자화할 수 있다. 2‑bit 포맷은 메모리를 16배 절감하면서도 4‑bit 포맷보다 높은 리콜을 제공한다. 더 나아가 1‑bit “Better Binary Quantization”(BBQ)은 32배 압축을 달성하면서도 2‑3 % 수준의 리콜 손실만 발생한다.

이는 단순히 압축이 아니라 정확도‑비용 트레이드오프의 근본적인 재협상이다. 과거엔 비트 깊이가 낮을수록 검색 품질이 떨어졌지만, 이제는 많은 워크로드에서 2‑bit 양자화가 4‑bit보다 더 나은 선택이 된다.

실무자 입장에서는 “수십억 규모 인덱스를 일반 서버에서도 운영 가능”해졌다. 특수 GPU 인스턴스나 테라바이트‑급 RAM 노드가 필요 없다. 64‑128 GB RAM을 장착한 NVMe 기반 일반 서버면 충분하다.

양자화를 넘어선 성능 최적화

Lucene 성능팀은 양자화에 머물지 않고 핵심 거리 계산 로직을 JDK Vector API(JDK 21 인큐베이터, 22+에서 안정화)로 재작성했다. 이를 통해 Intel AVX‑512, AMD AVX2, ARM Neon 등 다양한 SIMD 명령어 집합을 자동으로 활용한다. 또한 부동소수점 벡터를 64 byte 단위로 디스크에 정렬함으로써 다음과 같은 효과를 얻었다:

• **40 %**의 레키컬(lexical) 검색 속도 향상 (Lucene 10.2 → 10.3)
• **15‑20 %**의 벡터 검색 속도 향상 (캐시‑패럴렐 페치 최적화)
• **연간 60 %**의 쿼리 처리량 증가: 벤치마크에서 QPS 170 → 272

핵심 인사이트는 Lucene이 디스크 레이아웃, 메모리 매핑, CPU 명령어 집합을 하나의 통합 시스템으로 조율한다는 점이다. 대부분의 벡터 데이터베이스는 이 중 하나만 최적화하지만, Lucene은 세 가지를 모두 최적화하고 서로 상호작용하도록 설계했다.

인덱싱 처리량도 중요하다

벡터 검색이 화제이지만, 실제 운영에서는 인덱싱 처리량이 결정적이다. Lucene 10.2는 HNSW 그래프 병합 시간을 25 % 단축했다. “IDEA”(deduplication‑aware indexing) 연구에서는 중복을 제거한 코퍼스에 대해 인덱스 크기를 73 % 줄이고 인덱싱 시간을 94 % 감소시켰다.

또한 Lucene 10.0에 도입된 Doc value skip index는 필터와 집계 필드가 다를 때 집계 속도를 최대 28배 가속한다—분석 중심 워크로드에서 흔히 나타나는 패턴이다. IndexInput#prefetch는 데이터가 이미 캐시돼 있을 경우 madvise 오버헤드를 자동으로 감소시켜, 쿼리당 수천 건의 불필요한 시스템 콜을 없앤다.

이 모든 효과가 합쳐져 2026년의 Lucene은 2024년과는 전혀 다른 엔진이 되었다. 벡터‑네이티브, 하드웨어‑인식, 메모리‑효율적인 검색 커널이며, 텍스트 검색도 뛰어나게 수행한다.

Elasticsearch의 가장 큰 구조적 변화: 영구 로컬 스토리지 삭제

Elasticsearch는 새로운 기능을 추가하기보다 삭제를 통해 아키텍처를 혁신했다. 데이터 노드에서 “영구 로컬 스토리지” 개념을 없앤 것이다.

2025년 ACM SoCC에서 발표된 무상태(stateless) 아키텍처는 컴퓨트와 스토리지를 완전히 분리한다. 객체 스토어(S3, GCS, Azure Blob)가 **단일 진실 원천(single source of truth)**이 된다. Primary‑replica 복제는 사라지고, 샤드 복구는 데이터 복사가 아니라 포인터 재지정으로 이루어진다. 자동 스케일링은 더 세분화되고 즉시 적용된다.

이 변화는 단순히 운영을 단순화하는 수준을 넘어 검색 비용 구조 자체를 바꾼다. 기존에는 24 시간 내내 피크 용량을 프로비저닝해야 했지만, 이제는 요청당 과금이 된다. 예를 들어, 기존 모델에서는 월 $2,000이 들던 개발 클러스터가 쿼리량이 적다면 새 모델에서는 $200 수준으로 감소할 수 있다.

DiskBBQ: 디스크‑네이티브 ANN 알고리즘

Elasticsearch 9.2에서 가장 기술적으로 인상적인 기능은 DiskBBQ다. 이는 메모리‑내 HNSW를 대체하는 디스크‑네이