---
title: "파일 창고였던 클라우드 스토리지, 이제 벡터 검색까지 삼키는 중"
published: 2026-07-29T13:05:04.887Z
canonical: https://jeff.news/article/5209
---
# 파일 창고였던 클라우드 스토리지, 이제 벡터 검색까지 삼키는 중

클라우드 스토리지가 단순 파일 보관소에서 검색과 분석까지 맡는 인프라로 바뀌고 있어. AWS의 S3 벡터스는 오브젝트 스토리지 안에 AI용 벡터 데이터를 저장하고 유사도 검색까지 처리하면서, 기존 벡터 데이터베이스와 검색 엔진의 일부 역할을 흡수하고 있어.

## 클라우드 스토리지가 그냥 파일 창고가 아니게 됨

- 클라우드 스토리지가 파일을 쌓아두는 공간에서, 검색과 분석까지 맡는 쪽으로 이동 중임.
  - 예전 구조는 원본 파일은 S3 같은 오브젝트 스토리지에 두고, 검색용 데이터는 별도 벡터 데이터베이스나 검색 엔진에 다시 넣는 방식이었음.
  - 이러면 같은 데이터를 여러 곳에 저장해야 해서 비용이 늘고, 새 문서가 생길 때마다 검색 인덱스도 따로 갱신해야 함.
  - 동기화가 꼬이면 원본과 검색 데이터가 달라지는 문제도 생김. 이거 운영해본 사람은 바로 피곤해지는 포인트임.

- AWS가 내놓은 ‘아마존 S3 벡터스’는 이 구조를 S3 안으로 끌어들임.
  - S3 안에 AI용 벡터 데이터를 저장하고 유사도 검색까지 수행함.
  - 인덱스 하나에 최대 20억개의 벡터를 저장할 수 있음.
  - 자주 실행되는 검색은 약 100밀리초 이하 응답 속도를 낸다고 설명함.
  - AWS는 전용 벡터 데이터베이스 대비 업로드·저장·검색 비용을 최대 90% 줄일 수 있다고 밝힘.

> [!IMPORTANT]
> 핵심은 “S3가 검색 엔진을 완전히 대체한다”가 아니라, 값싼 스토리지 안에서 기본 벡터 검색까지 처리하게 됐다는 점임. AI 검색 워크로드의 시작 비용이 확 내려갈 수 있음.

## 왜 갑자기 벡터 검색이 스토리지 안으로 들어오나

- 배경에는 AI 에이전트와 검색 증강 생성(RAG)이 있음.
  - 챗봇이나 AI 에이전트는 질문을 받을 때마다 사내 문서, 고객 기록, 상품 이미지, 과거 대화에서 관련 내용을 찾아야 함.
  - 문서 하나도 여러 조각으로 쪼개져 각각 벡터로 저장되기 때문에, 검색용 데이터는 원본보다 훨씬 빠르게 불어남.

- AWS 수치도 꽤 세게 나옴.
  - 지난해 7월 시험 서비스를 시작한 뒤 약 넉 달 만에 사용자가 만든 벡터 인덱스가 25만개를 넘김.
  - 저장된 벡터는 400억개를 넘었고, 검색 요청은 10억회를 돌파함.
  - AI 서비스가 늘수록 ‘검색 가능한 저장소’ 자체가 핵심 인프라가 된다는 신호임.

- AWS는 가격과 검색 범위도 공격적으로 손봤음.
  - 지난달 1000만개가 넘는 대형 벡터 인덱스의 검색 데이터 처리 요금을 최대 80% 내림.
  - 한 번에 받을 수 있는 유사 검색 결과도 100개에서 1만개로 늘림.
  - AI가 먼저 넓게 후보를 찾고, 별도 모델로 다시 순위를 매기거나 중복을 제거하는 다단계 검색 수요를 노린 조치임.

## S3만의 얘기는 아님, 업계 전체가 그쪽으로 감

- S3는 벡터 검색뿐 아니라 메타데이터 조회 기능도 강화하고 있음.
  - 저장된 파일의 형식, 생성 시각, 암호화 여부 같은 메타데이터를 자동으로 표 형태로 만들고 SQL로 조회할 수 있음.
  - 파일 하나에 업무 설명, 보안 등급, 프로젝트명 같은 정보를 최대 1000개까지 붙이는 어노테이션 기능도 공개함.
  - 파일을 열지 않고도 조건으로 문서를 찾는 구조라, 저장소가 카탈로그이자 분석 시스템처럼 바뀌는 중임.

- 마이크로소프트와 구글도 저장·검색·연산을 묶는 방향으로 움직이고 있음.
  - 마이크로소프트는 애저 블롭 스토리지의 문서를 자동으로 나누고 벡터로 변환해 애저 AI 서치 인덱스에 넣는 과정을 통합함.
  - 구글은 클라우드 스토리지의 이미지·음성 같은 비정형 데이터를 빅쿼리 표 안에서 참조하고 분석하도록 연결함.

## 그래도 전용 데이터베이스가 죽는 건 아님

- 앞으로는 데이터 배치가 더 계층형으로 갈 가능성이 큼.
  - 자주 쓰지 않는 대량 데이터는 값싼 오브젝트 스토리지에 둠.
  - 직접 검색하고 빠른 응답이 필요한 일부 데이터만 고성능 데이터베이스나 검색 엔진에 올림.
  - 이러면 비용과 성능 사이에서 더 세밀하게 선택할 수 있음.

- 전용 검색 엔진과 데이터베이스가 유리한 영역은 여전히 남아 있음.
  - 수십 밀리초 수준 응답이 필요하거나, 초당 대량 검색을 처리해야 하거나, 키워드 검색과 의미 검색을 섞어야 하면 전문 시스템이 유리함.
  - 복잡한 필터와 집계도 S3 기본 검색보다 검색 엔진 쪽이 맞음.
  - AWS도 이런 작업에는 S3의 벡터 데이터를 오픈서치(OpenSearch)로 보내도록 설계했음.

> [!TIP]
> RAG를 새로 붙일 때 처음부터 전용 벡터 데이터베이스를 고정값으로 두기보다, 데이터 규모·응답 시간·필터 복잡도·락인 위험을 같이 보고 스토리지 기반 검색으로 충분한지 먼저 따져볼 만함.

- 대신 생태계 락인 문제는 더 커질 수 있음.
  - 저장, 검색, 분석 기능까지 한 클라우드 사업자 안에서 묶어 쓰면 API와 데이터 관리 체계 의존도가 깊어짐.
  - 앞으로 클라우드 경쟁은 데이터를 얼마나 많이 저장하느냐보다, 저장된 데이터를 얼마나 싸고 빠르게 활용하게 해주느냐로 옮겨갈 가능성이 큼.

---

## 기술 맥락

- 이 변화의 핵심은 “검색 인프라를 어디에 둘 것인가”예요. 예전에는 원본은 오브젝트 스토리지, 검색은 벡터 데이터베이스나 검색 엔진에 맡기는 게 자연스러웠는데, AI 워크로드가 커지면서 그 복제와 동기화 비용이 부담으로 올라온 거예요.

- S3 Vectors가 노리는 지점은 최고 성능 검색이 아니라 기본 검색의 비용 절감이에요. 인덱스 하나에 최대 20억개 벡터를 넣고, 자주 쓰는 검색을 약 100밀리초 이하로 처리한다면 초기 RAG나 대량 아카이브 검색에는 꽤 매력적이거든요.

- 다만 모든 검색을 스토리지로 밀어 넣으면 안 돼요. 수십 밀리초 응답, 초당 대량 질의, 키워드와 벡터의 하이브리드 검색, 복잡한 필터와 집계가 필요하면 OpenSearch 같은 전문 검색 엔진이 여전히 맞아요.

- 그래서 실무 판단은 단순해져요. 원본과 검색 인덱스를 따로 운영할 만큼 성능 요구가 강한지, 아니면 스토리지 안의 기본 검색으로 비용과 운영 복잡도를 줄이는 게 더 중요한지부터 봐야 해요.

- 클라우드 사업자 입장에서는 이게 락인을 강화하는 전략이기도 해요. 저장, 메타데이터, 벡터 검색, 분석까지 한 API 체계 안에 들어오면 개발은 편해지지만 나중에 데이터를 옮기거나 멀티클라우드로 빼는 비용은 커질 수 있거든요.

## 핵심 포인트

- AWS S3 벡터스는 인덱스 하나에 최대 20억개 벡터를 저장하고, 자주 쓰는 검색은 약 100밀리초 이하 응답을 목표로 해.
- AWS는 전용 벡터 데이터베이스 대비 업로드·저장·검색 비용을 최대 90% 줄일 수 있다고 설명해.
- AI 에이전트와 검색 증강 생성이 커지면서, 원본 저장소와 검색 인덱스를 따로 관리하는 구조의 비용·동기화 문제가 더 크게 드러나고 있어.
- 전용 검색 엔진과 데이터베이스가 사라지는 건 아니고, 고성능 검색·복잡한 필터·집계가 필요한 영역은 여전히 전문 시스템이 유리해.

## 인사이트

스토리지와 데이터베이스의 경계가 흐려지는 흐름이 꽤 중요해. 개발자 입장에서는 벡터 검색을 무조건 별도 데이터베이스로 시작할지, 값싼 오브젝트 스토리지 기반 검색으로 충분한지부터 다시 따져봐야 하는 시점이야.