파일 창고였던 클라우드 스토리지, 이제 벡터 검색까지 삼키는 중

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

• 클라우드 스토리지가 파일을 쌓아두는 공간에서, 검색과 분석까지 맡는 쪽으로 이동 중임.

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

• AWS가 내놓은 ‘아마존 S3 벡터스’는 이 구조를 S3 안으로 끌어들임.

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

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

• 배경에는 AI 에이전트와 검색 증강 생성(RAG)이 있음.

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

• AWS 수치도 꽤 세게 나옴.

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

• AWS는 가격과 검색 범위도 공격적으로 손봤음.

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

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

• S3는 벡터 검색뿐 아니라 메타데이터 조회 기능도 강화하고 있음.

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

• 마이크로소프트와 구글도 저장·검색·연산을 묶는 방향으로 움직이고 있음.

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

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

• 앞으로는 데이터 배치가 더 계층형으로 갈 가능성이 큼.

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

• 전용 검색 엔진과 데이터베이스가 유리한 영역은 여전히 남아 있음.

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

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

---

기술 맥락

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

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

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

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

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