왜 지금 봐야 하나
Weaviate 1.38은 세 가지 변화를 담은 릴리스다.
- HFresh 디스크 기반 벡터 인덱스 GA. HNSW가 모든 벡터를 메모리에 올리는 구조였다면, HFresh는 클러스터 중심점만 메모리에 두고 나머지는 디스크에 유지한다. 수십억 규모 벡터를 비용 합리적으로 운영할 수 있는 구조다.
- MCP Server GA. Claude, Codex 등의 AI 에이전트가 별도 코드 없이 Weaviate를 직접 읽고 쓸 수 있다. Weaviate를 에이전트의 장기 메모리 레이어로 붙이는 아키텍처가 표준화됐다.
- 비동기 복제 스케줄러 재구성. 노드별 분산 스케줄러에서 클러스터 단일 스케줄러로 바뀌었고, 복제된 컬렉션에서 기본값으로 켜진다.
이 세 변화는 서로 다른 문제를 건드린다. HFresh는 비용, MCP Server는 연동 방식, 비동기 복제는 가용성이다.
변화 한눈에 보기
| 항목 | 이전(1.36 이전) | 1.38 |
|---|---|---|
| 디스크 벡터 인덱스 | Flat(브루트포스)만 존재 | HFresh GA (SPFresh 기반) |
| MCP Server | 기술 프리뷰 (1.36) | GA |
| 비동기 복제 | 노드별 독립 스케줄러 | 클러스터 단일 스케줄러, 기본 활성화 |
| 중첩 객체 필터링 | 미지원 | 기술 프리뷰 (21단계 구현) |
| Boost API | 미지원 | 기술 프리뷰 (소프트 랭킹) |
| Query Profiling | 미지원 | 스테이지·샤드별 타이밍 반환 |
HFresh: 메모리를 아끼는 벡터 인덱스의 구조
왜 HNSW는 메모리를 많이 쓰는가
HNSW(Hierarchical Navigable Small World)는 모든 벡터를 다층 그래프 노드로 연결한다. 쿼리가 들어오면 최상위 레이어에서 시작해 가장 가까운 이웃을 타고 내려오며 k-NN을 찾는다.
- 장점: 검색 속도 빠름, recall 높음, 동적 삽입 가능.
- 단점: 모든 벡터(그리고 그래프 엣지)가 메모리에 있어야 한다. 1,536차원 float32 벡터 1억 개는 약 614GB 메모리를 요구한다. 여기에 그래프 구조 오버헤드가 더해진다.
수십억 규모에서는 메모리 비용이 운영의 병목이 된다.
HFresh의 아이디어: 클러스터 + 디스크
HFresh는 SPFresh 알고리즘에서 영감을 받은 계층적 클러스터 기반 인덱스다.
구조는 두 계층으로 나뉜다.
- 상위 계층 (메모리): 클러스터 중심점(centroid)만 모아 작은 HNSW 인덱스를 만든다. 8비트 회전 양자화(Rotational Quantization, RQ)로 압축한다.
- 하위 계층 (디스크): 각 클러스터에 속한 실제 벡터들을 "포스팅 리스트(posting list)"로 묶어 LSM 스토리지에 저장한다. 1비트 RQ로 압축한다.
쿼리가 오면 이렇게 동작한다.
- 메모리 HNSW로 쿼리에 가장 가까운 상위 k개 클러스터를 찾는다.
- 해당 클러스터의 포스팅 리스트를 디스크에서 읽어 후보 벡터를 모은다.
- 후보 벡터를 재점수화(rescoring)해서 최종 k-NN을 반환한다.
업데이트 방식: 전체 재구축 없음
HNSW에서는 대규모 삽입·삭제 후 주기적 재구축이 필요하다. HFresh는 증분 리밸런싱으로 이 문제를 피한다.
- 포스팅이 너무 커지면 분할(split)
- 포스팅이 너무 작아지면 병합(merge)
- 경계가 이동하면 영향 받는 벡터만 재할당(reassign)
대부분의 삽입·삭제가 한정된 클러스터에만 영향을 미치기 때문에 전체 인덱스를 잠그지 않아도 된다.
HNSW vs HFresh: 언제 무엇을 쓰나
| 기준 | HNSW | HFresh |
|---|---|---|
| 메모리 | 전체 벡터 비례 | 중심점만 (수십 배 절약) |
| 검색 지연시간 | 낮음 (메모리 직접 접근) | I/O 추가 (디스크 읽기 포함) |
| 수십억 규모 운영 | 비용 매우 높음 | 실용적 |
| 정확도(Recall) | 높음 | 재점수화로 유지 가능 |
| 인덱스 업데이트 | 점진적 삽입 가능 | 증분 리밸런싱 |
| 적합한 경우 | 수백만 이하, 저지연 우선 | 수억 이상, 메모리 비용 우선 |
같은 데이터셋이라도 HNSW에서 HFresh로 전환 시 지연시간이 늘어날 수 있다. 디스크 I/O를 피할 수 없기 때문이다. 운영 환경에서 99 퍼센타일 지연시간을 먼저 측정하고 전환 여부를 결정해야 한다.
MCP Server GA: Weaviate를 에이전트 장기 메모리로
무엇이 달라졌나
Weaviate 1.38에서 MCP Server가 GA가 됐다. 이 의미는 다음과 같다.
- Claude Code, Codex, Cursor 같은 MCP 호스트가 Weaviate를 도구로 직접 붙일 수 있다.
- 에이전트가
검색·삽입·삭제작업을 Weaviate에 직접 수행한다. 중간 레이어 코드가 없어도 된다. - 하이브리드 검색(BM25 + 밀집 벡터 + 메타데이터 필터)을 MCP 단일 인터페이스로 호출한다.
기본 알파 값이 0.75로 설정돼 있다. 이는 벡터 유사도보다 키워드 점수에 약간 더 비중을 두는 설정이다.
Prometheus 메트릭 통합
MCP Server 호출에 대한 Prometheus 메트릭이 추가됐다. 에이전트가 Weaviate를 얼마나 자주 호출하는지, 지연시간 분포가 어떻게 되는지 기존 모니터링 인프라로 추적할 수 있다.
운영 고려사항
- 멀티테넌시가 지원되므로 테넌트 격리 기반으로 에이전트별 독립 메모리를 줄 수 있다.
- 환경 변수로 런타임 구성이 가능해 배포 시 재시작 없이 일부 설정 변경이 가능하다.
- MCP Server를 통한 쓰기도 Weaviate의 일반 쓰기 경로를 거치므로 복제·WAL 동작은 동일하다.
비동기 복제 재구성: 단일 스케줄러
이전 구조의 문제
이전 비동기 복제는 각 노드가 독립적으로 복제 작업을 스케줄링했다. 이 방식에서 레이스 컨디션이 발생할 수 있었고, 복구 중 체크포인트 없이 재시작하면 어디까지 복제됐는지 파악하기 어려웠다.
새 구조
1.38에서는 클러스터 단일 스케줄러가 복제 작업을 조율한다.
- 레이스 컨디션 방지를 위해 피어 비교 시 레벨별 식별자(discriminant) 사용
- 체크포인트: 스케줄러가 중단됐다 재시작해도 어디까지 완료됐는지 복원 가능
- 기본값으로 활성화: 복제된 컬렉션이 있으면 별도 설정 없이 비동기 복제가 동작한다.
이 변화로 인해 기존에 비동기 복제를 명시적으로 끈 경우, 1.38 업그레이드 후 기본 활성화 여부를 확인해야 한다.
Query Profiling과 나머지 변화
Query Profiling
쿼리 응답에 스테이지별·샤드별 타이밍 정보가 포함된다. 이전에는 느린 쿼리의 원인이 인덱스 접근인지, 포스트필터인지, 네트워크인지 구분하기 어려웠다. 이제 단일 쿼리 응답으로 병목 지점을 특정할 수 있다.
Boost API (기술 프리뷰)
결과 재정렬을 위한 소프트 랭킹 인터페이스가 추가됐다. 벡터 유사도 점수 외에 비즈니스 규칙(최신성, 조회수, 신뢰도 점수 등)을 추가 신호로 섞을 수 있다. 아직 기술 프리뷰 단계이므로 API가 변경될 수 있다.
Nested Object Filtering (기술 프리뷰)
JSON 속성 계층을 따라 필터를 걸 수 있는 기능이 추가됐다. LSM 스토어에 중첩 경로를 저장하고, 복잡한 AND 조건도 상관 관계를 유지하며 처리한다. gRPC·GraphQL 양쪽 경로에서 동작한다. 실 서비스 투입 전에 스키마 설계와 성능 특성을 충분히 테스트하는 것을 권장한다.
도입 체크리스트
HFresh 전환 판단
- 현재 HNSW 인덱스의 메모리 사용량이 노드 메모리의 50% 이상인가?
- 데이터셋이 1억 건 이상인가?
- 99 퍼센타일 지연시간 SLO가 수백 ms 수준으로 허용 가능한가?
- 위 세 조건이 모두 맞다면 HFresh 테스트 환경에서 Recall·지연시간·메모리를 동시에 측정하라.
MCP Server 도입 판단
- AI 에이전트가 Weaviate에 직접 읽기·쓰기를 해야 하는 시나리오가 있는가?
- 기존 커스텀 API 레이어를 MCP로 대체할 수 있는가?
- Prometheus 메트릭 수집 구성이 준비됐는가?
비동기 복제 기본 활성화 확인
- 기존 배포에서 비동기 복제를 명시적으로 비활성화했는가? 그렇다면 1.38 업그레이드 후 동작 변경을 확인하라.
- 체크포인트 복구 동작을 테스트 환경에서 먼저 검증하라.
한 줄 결론
Weaviate 1.38은 메모리 vs. 비용의 벡터 인덱스 딜레마에 HFresh로 답하고, MCP Server GA로 에이전트 장기 메모리 아키텍처를 표준화하며, 비동기 복제를 기본값으로 바꿔 가용성 기준을 올렸다. 세 변화 모두 운영 규모가 커질수록 영향이 커지는 종류다.
References
- Weaviate v1.38.0 릴리스 노트 (GitHub): https://github.com/weaviate/weaviate/releases/tag/v1.38.0
- Weaviate 1.38 릴리스 블로그: https://weaviate.io/blog/weaviate-1-38-release
- Weaviate 1.36 릴리스 블로그 (HFresh 기술 프리뷰 최초 도입): https://weaviate.io/blog/weaviate-1-36-release
- Weaviate Vector Index 개념 문서: https://docs.weaviate.io/weaviate/concepts/vector-index
- SPFresh 논문 (HFresh의 알고리즘 기반): https://dl.acm.org/doi/10.1145/3514221.3526137