벡터 검색은 결국 저장 비용 싸움
RAG를 붙이면 벡터가 쌓입니다. 문서가 늘고, 청크 크기를 바꿔 다시 임베딩하고, 모델을 바꿔 또 임베딩합니다.
전용 벡터 데이터베이스는 빠릅니다. 대신 대부분 인덱스를 메모리나 빠른 디스크에 올려 두는 구조라, 벡터가 늘어날수록 비용도 같이 늘어납니다. 질의가 하루 몇 번뿐인 사내 문서 검색에도 같은 비용을 냅니다.
S3 Vectors는 이 지점을 겨냥한 서비스입니다. 벡터를 객체 저장소에 두고, 검색 기능을 저장소 쪽에 붙였습니다.
정식 출시 때 바뀐 숫자
AWS 글에 나온 수치를 프리뷰와 비교하면 이렇습니다.
| 항목 | 프리뷰 | 정식 출시 |
|---|---|---|
| 인덱스당 벡터 | 5천만 개 | 20억 개 |
| 질의당 결과 | 30개 | 100개 |
| 리전 | 5곳 | 14곳 |
벡터 버킷 하나에는 최대 20조 개까지 담을 수 있습니다. 한 벡터씩 스트리밍으로 넣을 때는 초당 PUT 1,000건까지 받습니다.
비용에 대해서는 전용 벡터 DB 대비 저장과 질의 총비용을 최대 90% 줄일 수 있다고 주장합니다. 비교 대상과 조건은 글에 구체적으로 나오지 않으니, 실제 비용은 자기 워크로드로 계산해 봐야 합니다.
지연 시간이 고정값이 아니다
눈여겨볼 문장은 지연 시간 설명입니다. 자주 오지 않는 질의는 1초 안에, 잦은 질의는 100ms 안팎으로 응답한다고 합니다.
질의 빈도에 따라 지연이 달라진다는 뜻입니다. 자주 찾는 인덱스는 캐시가 데워져 빨라지는 구조로 읽힙니다. 고정된 지연을 보장한다는 문장은 없습니다.
그래서 쓰임새가 갈립니다.
- 맞는 곳: 사내 문서 검색, 에이전트의 장기 기억, 가끔 돌리는 유사도 분석. 1초 정도는 기다려도 되는 일
- 조심할 곳: 사용자가 입력할 때마다 즉시 추천을 띄우는 화면. 첫 질의가 느릴 수 있음
연동이 사실상 핵심
S3 Vectors 단독보다 연동 소식이 더 실용적이었습니다.
Bedrock Knowledge Bases의 벡터 저장 엔진으로 정식 지원됩니다. Knowledge Bases로 RAG를 만들 때 저장소로 S3 Vectors를 고르면 됩니다.
OpenSearch와의 연동도 정식입니다. S3 Vectors를 저장 계층으로 두고 검색·분석은 OpenSearch가 맡는 구조입니다. 오래된 벡터는 S3에 두고, 자주 쓰는 벡터만 빠른 엔진에 올리는 계층형 설계를 떠올릴 수 있습니다.
미리 알아 둘 제약
글에 적힌 제약도 정리해 둡니다.
- 거리 함수는 코사인과 유클리드 두 가지뿐입니다. 내적을 쓰는 모델이라면 정규화를 먼저 확인해야 합니다.
- 인덱스 차원은 임베딩 모델의 출력 차원과 같아야 합니다. 모델을 바꾸면 인덱스를 새로 만들어야 합니다.
- 벡터 하나에 메타데이터 키는 50개까지, 그중 필터에 쓰지 않는 키는 10개까지입니다.
요금은 세 갈래입니다. 올린 데이터 양 기준의 PUT, 저장, 그리고 질의입니다. 질의 요금은 API 호출당 요금에 인덱스 크기 기준 TB당 요금이 붙고, 벡터가 10만 개를 넘으면 TB당 단가가 내려갑니다.
함께 읽을 개념 정리
- 벡터 검색에 조건을 붙이면 결과가 모자라는 이유: 근사 검색과 필터링이 부딪히는 지점
- RAG와 하이브리드 검색을 한 장으로: RAG가 풀려던 문제와 키워드·벡터 검색을 섞는 법
영상으로 더 보기
S3 Vectors가 AI 저장 비용 구조를 어떻게 바꾸는지 다룬 re:Invent 세션입니다.
전용 벡터 DB는 사라질까
아마 아닐 겁니다. 밀리초 단위 응답이 꾸준히 필요하거나, 복잡한 하이브리드 검색을 한 엔진 안에서 끝내야 한다면 전용 엔진이 여전히 맞습니다.
다만 "일단 벡터 DB부터 띄운다"는 기본값은 바뀔 것 같습니다. 질의가 드물고 데이터가 큰 쪽은 S3 Vectors에서 시작하고, 지연이 문제가 될 때 빠른 엔진을 앞에 붙이는 순서가 더 합리적으로 보입니다. 정식 출시 시점에 이미 인덱스 25만 개, 벡터 400억 개가 들어왔다는 AWS 집계도 그 수요를 보여 줍니다.
