AI 워크로드를 위한 객체 스토리지
AI 워크로드를 위한 객체 스토리지
객체 스토리지는 데이터를 디스크의 폴더나 블록 안의 파일로 저장하는 대신, 독립적인 객체로 저장합니다. 이는 사진, 비디오, 오디오, 이메일, 웹 페이지, 센서 판독값, 그리고 AI 애플리케이션이 생성하는 벡터 임베딩과 같은 비정형 데이터를 위해 구축되었습니다.
클라우드 객체 저장소는 이 데이터를 여러 머신에 분산하지만, HTTP API를 통해 모든 데이터를 단일 풀처럼 접근할 수 있게 합니다. 각 객체는 세 가지를 담고 있습니다: 데이터 자체, 사용자가 추가한 메타데이터, 그리고 고유 ID입니다. 파일 유형이 무엇이든 해당 ID로 어떤 객체든 가져오거나 분석할 수 있습니다.
최초의 클라우드 객체 저장소인 Amazon S3는 이제 500조 개 이상의 객체를 보관하고 있습니다. 이는 클라우드의 기본 스토리지 계층이 되었습니다.
객체 스토리지의 작동 방식
세 가지 스토리지 모델은 데이터를 서로 다르게 처리합니다. 파일 시스템은 데이터를 중첩된 폴더에 넣습니다. 블록 스토리지는 데이터를 디스크의 고정 크기 블록으로 나눕니다. 객체 스토리지는 각 항목을 버킷이라는 평면 컨테이너 안에 전체로 보관하며, 폴더는 없습니다.
파일을 저장하기 위해 시스템은 데이터를 가져와 사용자가 제공한 메타데이터를 추가하고 ID를 붙입니다. 그런 다음 앱은 HTTP API를 통해 해당 ID로 객체를 읽고, 쓰고, 삭제합니다. 파일 경로나 마운트 지점은 없습니다.
PUT /my-bucket/embedding-batch-042.parquet # 객체 저장
GET /my-bucket/embedding-batch-042.parquet # ID로 가져오기
DELETE /my-bucket/embedding-batch-042.parquet # 제거
평면 구조가 객체 스토리지를 확장 가능하게 만드는 요소입니다. 폴더 트리를 재작업하는 것이 아니라 풀에 머신을 추가해 용량을 늘리므로, 단일 버킷은 거의 제한 없이 커질 수 있습니다. 2006년에 출시된 Amazon S3는 업계의 나머지가 모방한 API를 정립했으며, Ceph, MinIO, OpenStack Swift는 모두 S3 호환이고, 다른 주요 클라우드도 마찬가지입니다.
| 서비스 | 제공업체 | API 표준 |
|---|---|---|
| Amazon S3 | AWS | S3 (사실상의 표준) |
| Cloud Storage | Google Cloud | S3 상호 운용 + 네이티브 |
| Blob Storage | Microsoft Azure | 네이티브 + S3 호환 게이트웨이 |
| MinIO / Ceph | 자체 호스팅(오픈 소스) | S3 호환 |
주요 기능과 한계
객체 스토리지의 설계는 명확한 강점과 명확한 한계를 제공합니다.
주요 기능
- 거의 제한 없이 확장됩니다. 단일 버킷은 필요한 만큼 많은 객체를 담습니다. 더 많은 데이터를 쓰는 방식으로 용량을 추가하고, 사전에 크기를 정해야 하는 클러스터 없이 저장한 만큼만 비용을 지불합니다.
- 내구성과 복원력이 뛰어납니다. 객체 저장소는 각 객체의 복사본을 여러 머신에 보관하며, 종종 데이터 센터나 리전에 걸쳐 보관합니다. Amazon S3는 99.999999999%의 내구성(일레븐 나인)을 위해 구축되었으며, 모든 객체는 최소 세 개의 Availability Zone에 걸쳐 저장됩니다.
- 저렴하며, 티어가 있습니다. 기가바이트당 가격은 블록 또는 파일 스토리지보다 훨씬 낮고, 콜드 데이터는 자동으로 더 저렴한 티어로 이동합니다.
- 풍부한 메타데이터와 함께 어떤 데이터든 보관합니다. 하나의 버킷은 어떤 종류의 비정형 데이터든 담을 수 있으며, 각 객체는 사용자가 정의한 메타데이터를 지닙니다. 파일 유형이 무엇이든 해당 메타데이터로 객체를 찾고 필터링할 수 있습니다.
- 개방적이고 접근하기 쉽습니다. 객체는 일반 HTTP API를 통해 읽힙니다. S3 API는 사실상의 표준이므로, 많은 도구가 특별한 커넥터 없이 같은 버킷을 읽습니다.
한계
- 블록 스토리지보다 느립니다. 모든 요청이 HTTP를 거치므로, 객체 스토리지는 지연 시간이 낮아야 하는 랜덤 액세스 작업이나 트랜잭션 데이터베이스에는 적합하지 않습니다.
- 제자리 편집이 없습니다. 객체의 일부를 변경하는 대신 전체 객체를 교체하므로, 객체 스토리지는 자주 변경되는 데이터에는 잘 맞지 않습니다.
- 작은 읽기는 비용이 많이 듭니다. 많은 작은 읽기를 수행하는 워크로드는 데이터 자체가 작더라도 큰 API 요금이 발생할 수 있습니다.
- 내장 검색이나 컴퓨트가 없습니다. 객체 스토리지는 바이트를 저장하고 제공합니다. 인덱스도, 검색도, 분석도 없습니다. "이 객체를 ID로 가져오기"를 넘어서는 모든 것은 그 위에 쿼리 엔진이 필요합니다. 이 마지막 공백이 바로 객체 스토리지가 AI 데이터의 기반이지만, 그 자체만으로는 AI 검색을 제공할 수 없는 이유입니다.
사용 사례, 그리고 AI로 가는 다리
오브젝트 스토리지의 규모, 내구성, 저비용은 많은 워크로드의 기본 저장소가 되게 합니다:
- 데이터 레이크 (표준 스토리지 기반)
- 백업 및 재해 복구
- 장기 아카이브
- 미디어 저장 및 전송
- 로그 및 분석 데이터
- ML 학습 세트 (모델이 학습하는 대규모 데이터셋)
AI 검색은 이제 오브젝트 스토리지에 데이터를 보관하는 것 이상의 역할을 요구하고 있습니다. 임베딩은 시맨틱 검색과 검색 증강 생성(RAG)의 기반이 되는 수치 벡터입니다. 그 수가 엄청나게 많고, 각각의 크기도 크며, 이를 전문 데이터베이스에 저장하면 비용이 많이 듭니다.
그래서 팀들은 임베딩을 오브젝트 스토리지에 직접 보관하기 시작했습니다. 2025년 12월부터 일반 공급된 Amazon S3 Vectors는 S3에 네이티브 벡터 저장 및 검색 기능을 추가합니다. AWS는 이를 통해 전문 벡터 데이터베이스 대비 벡터 저장 및 쿼리 비용을 최대 90% 절감하고, 인덱스당 최대 20억 개의 벡터를 보관하며, 빈번한 쿼리는 약 100밀리초, 드문 쿼리는 1초 미만에 응답한다고 말합니다.
문제는 속도입니다. 오브젝트 스토리지는 이제 벡터를 저렴하게 저장하고 검색할 수 있지만, 데이터가 오브젝트 스토리지에 그대로 있고 별도의 빠른 저장소로 복사되지 않는 상태에서 검색에 빠르게 응답하는 것이 어려운 부분입니다.
AI 인프라에서의 오브젝트 스토리지
오브젝트 스토리지에는 AI에 있어 한 가지 진짜 공백이 있습니다. 스스로를 검색할 방법이 없다는 점입니다. 임베딩은 그 안에 저렴하게 보관되지만, 유사도 검색을 하려면 두 가지 나쁜 선택지가 있습니다. 데이터를 전용 벡터 데이터베이스로 복사하면, 이제 두 개의 복사본을 유지하고, 두 개의 비용을 지불하며, 둘을 동기화해야 합니다. 인덱스 없이 원시 파일을 검색하면, 프로덕션에 쓰기에는 너무 느립니다.
해결책은 오브젝트 스토리지에 부족한 한 가지, 즉 데이터가 있는 곳에서 데이터를 검색할 방법을 제공하는 것입니다. 여기에는 세 가지 요소가 필요하며, 그중 어느 것도 기본 제공되지 않습니다:
- 데이터 옆의 인덱스. 벡터 인덱스는 별도 시스템이 아니라 데이터 옆의 오브젝트 스토리지에 위치합니다.
- 필요한 것만 가져오는 읽기. 쿼리 엔진은 전체 파일이 아니라 쿼리가 건드리는 인덱스 페이지와 데이터 조각만 가져옵니다.
- 앞단의 캐시. 메모리 또는 로컬 SSD가 오브젝트 스토리지 앞에 위치해 핫 데이터가 왕복 없이 제공되도록 합니다.
이 세 가지를 결합하면 오브젝트 스토리지를 수동적인 저장소로 취급하는 대신 직접 검색할 수 있습니다.
Zilliz Vector Lakebase는 이러한 방식으로 구축된 시스템 중 하나입니다. 데이터와 인덱스를 오브젝트 스토리지에 유지하고, 이를 쿼리하는 컴퓨트와 분리합니다. 여러 컴퓨트 클러스터가 서빙, 디스커버리, 분석을 위해 동일한 데이터 복사본을 중복 없이 동시에 읽을 수 있습니다. External Collections 기능은 이미 보유한 레이크 테이블이 Lance, Iceberg, Parquet 또는 자체 Vortex 형식이든 이를 가리키고, 그 자리에서 벡터 검색을 실행합니다.
10억 개 벡터를 가진 Iceberg 테이블에 대한 Zilliz의 벤치마크에서 속도는 데이터가 어떻게 캐시되는지에 따라 달라집니다:
- 인덱스 없음 (브루트포스 Spark 스캔): 수 시간
- 콜드 (약 20분 만에 인덱스 막 구축): ~30초
- 웜 (로컬 SSD 캐시에서): 수십 밀리초
- 핫 (메모리에서): 한 자릿수 밀리초
각 쿼리는 필요한 페이지만 로드하기 때문에, Zilliz는 읽기 증폭(낭비되는 데이터 전송)을 90% 이상 줄이며, Vortex 형식은 읽기당 S3에서 Parquet보다 135배 적은 데이터를 이동한다고 보고합니다.
이 패턴은 특정 제품 하나보다 더 큰 흐름입니다. 오브젝트 스토리지는 AI 데이터가 저장되는 곳일 뿐만 아니라 직접 검색되는 장소로 변하고 있습니다.
자주 묻는 질문
오브젝트 스토리지는 AI 워크로드에 적합한가요?
예, 내구성, 거의 무제한에 가까운 용량, 저비용이 효과를 발휘하는 대규모 학습 데이터, 임베딩, 모델 아티팩트 저장에 적합합니다. 한계는 속도입니다. 해당 데이터를 빠르게 검색하려면 원시 저장소 위에 인덱스와 컴퓨트가 필요합니다.
오브젝트 스토리지와 벡터 데이터베이스의 차이는 무엇인가요?
객체 스토리지는 ID로 접근하는 모든 비정형 데이터를 위한 범용 저장소입니다. 벡터 데이터베이스는 임베딩에 대한 유사도 검색을 위해 구축되며, 빠른 최근접 이웃 쿼리에 맞게 조정된 인덱스를 갖습니다. 이 둘은 수렴하고 있습니다. 팀들은 점점 더 벡터를 객체 스토리지에 보관하고 그 위에 검색 계층을 추가하고 있습니다.
객체 스토리지에서 직접 벡터 검색을 실행할 수 있나요?
점점 더 그렇습니다. AWS S3 Vectors는 네이티브 벡터 검색을 추가하며, 레이크 테이블을 제자리에서 가리키는 플랫폼을 사용하면 객체 스토리지 데이터를 밖으로 복사하지 않고도 검색할 수 있습니다. 쿼리는 인메모리 인덱스보다 느리게 실행되지만 비용은 훨씬 낮습니다.
데이터 레이크는 왜 객체 스토리지를 사용하나요?
데이터 레이크는 방대한 양의 정형 및 비정형 데이터를 저렴하고 내구성 있게, 오픈 포맷으로 보관해야 하며, 동시에 여러 엔진에서 접근할 수 있어야 합니다. 객체 스토리지의 평면적이고 ID로 주소 지정되는 풀은 파일 또는 블록 스토리지보다 이에 더 잘 맞습니다.
객체 스토리지는 블록 스토리지보다 느린가요?
단일 작업의 경우 보통 그렇습니다. 블록 스토리지는 트랜잭션 및 랜덤 액세스 작업에 매우 낮은 지연 시간을 제공합니다. 객체 스토리지는 HTTP를 통해 읽는 크고 대부분 정적인 객체에 대해 처리량, 내구성, 비용을 얻는 대신 이를 포기합니다. 큰 순차 읽기에서는 격차가 줄어들지만, 작고 지연 시간에 민감한 읽기에서는 여전히 큽니다.
AI를 위한 객체 스토리지: 다음 단계
객체 스토리지는 나머지 AI 데이터 스택이 구축되는 기반입니다. 벡터 네이티브 플랫폼이 객체 스토리지 데이터를 대상으로 직접 검색, 탐색, 분석을 실행하는 방식을 보려면 From Vector Database to Vector Lakebase를 읽거나 Zilliz Cloud platform을 살펴보세요.