2026년 셀프 호스팅 S3 대안 (RustFS, Garage, SeaweedFS, Ceph)
MinIO 이후 셀프호스팅 S3 선택
Amazon S3는 오브젝트 저장소의 사실상 표준 API가 되었습니다. 오픈소스 MinIO 저장소가 2026년 4월에 아카이브 처리된 이후, 7개의 신뢰할 수 있는 셀프호스팅 대안 솔루션이 남아 있습니다.
이러한 솔루션들은 서로 호환 가능한 것이 아닙니다. 일부는 자체 데이터 레이아웃을 관리하는 완전한 오브젝트 스토리지 엔진인 반면, 다른 일부는 이미 보유한 파일들을 노출하는 얇은 게이트웨이입니다. 이 구분 — 네이티브 스토어와 파일시스템 기반 게이트웨이 — 은 기능 목록보다 백업, 복구, 마이그레이션에 더 많은 영향을 미칩니다.
이 글에서는 RustFS, Garage, SeaweedFS, Ceph RGW, VersityGW, S3Proxy, rclone를 비교합니다. 각 섹션은 스토리지 모델, S3 기능 지원 범위, 프로젝트가 적합한 위치, 그리고 선택을 결정하는 통상적인 한계점을 다루며, 단일 서버 및 다중 서버 배포를 위한 의사결정 가이드가 글의 끝을 마무리합니다.
오브젝트 스토리지, 데이터베이스, 검색, AI 네이티브 데이터 레이어 등 더 큰 그림을 보려면 AI 시스템을 위한 데이터 인프라를 참조하세요.
셀프호스팅 S3 스토리지 비교
가장 중요한 질문은 분산 오브젝트 스토어가 필요한지, 아니면 이미 존재하는 저장소 앞에 S3 인터페이스가 필요한지 여부입니다.
| 소프트웨어 | 스토리지 모델 | 분산 | S3 호환성 | 디스크에 일반 파일 저장 | 복잡성 | 최적 용도 |
|---|---|---|---|---|---|---|
| RustFS | 네이티브 오브젝트 스토어 | 네 | 높음, 테스트된 하위 집합 | 아니오 | 낮음~중간 | 일반적 MinIO 대체 |
| Garage | 네이티브 오브젝트 스토어 | 네 | 좋음, 더 좁은 API | 아니오 | 낮음~중간 | 소규모 분산 클러스터 |
| SeaweedFS | 분산 블롭 및 파일 스토어 | 네 | 높음 | 아니오 | 중간 | 방대한 파일 수 및 혼합 스토리지 |
| Ceph RGW | Ceph 오브젝트 게이트웨이 | 네 | 높음 | 아니오 | 높음 | 대규모 스토리지 인프라 |
| VersityGW | POSIX 기반 S3 게이트웨이 | 백엔드에 따라 다름 | 좋음 | 네 | 낮음 | 일반 파일 위에 S3 제공 |
| S3Proxy | S3 변환 레이어 | 백엔드에 따라 다름 | 중간 | filesystem-nio2 사용 시 네 | 중간 | 게이트웨이 및 프로토콜 변환 |
| rclone serve s3 | S3 게이트웨이 | 백엔드에 따라 다름 | 기본적, 실험적 | 로컬 백엔드 사용 시 네 | 매우 낮음 | 단순하고 가벼운 배포 |
RustFS는 일반적인 MinIO 배포에 가장 가까운 직접 대체 솔루션입니다. Garage는 소규모 분산 클러스터에 적합합니다. SeaweedFS와 Ceph는 더 광범위한 스토리지 문제를 해결합니다. VersityGW는 오브젝트 페이로드를 일반 파일로 유지하면서 기존 POSIX 파일시스템을 S3를 통해 노출할 수 있습니다. Garage, MinIO, AWS S3의 기능별 비교 매트릭스는 Garage vs MinIO vs AWS S3에서 확인하세요.
두 가지 유형의 S3 스토리지
네이티브 오브젝트 스토어는 자신의 스토리지 레이아웃을 소유합니다:
RustFS, Garage, Ceph RGW, SeaweedFS는 이 범주에 속합니다. 하위 디스크에서 볼 수 있는 파일들은 구현 세부 사항이며, 애플리케이션이 직접 조작해서는 안 됩니다.
파일시스템 기반 S3 게이트웨이는 저장소와 다른 관계를 가집니다:
VersityGW와 같은 소프트웨어에서는 파일시스템이 권위적인 표현을 유지할 수 있습니다. 다음과 같은 오브젝트:
s3://archive/documents/2026/report.pdf
는 직접적으로 다음 경로에 대응할 수 있습니다:
/storage/archive/documents/2026/report.pdf
RustFS: MinIO의 가장 가까운 대체 솔루션
RustFS는 Rust로 작성되고 Apache-2.0 라이선스로 배포된 분산 오브젝트 스토리지 시스템입니다. MinIO 사용자에게 익숙한 S3 지향 운영 모델을 제공하여 MinIO를 대체할 때 첫 번째로 평가해야 할 프로젝트가 됩니다.
현재 S3 구현은 대부분의 애플리케이션이 기대하는 작업을 포함합니다: 버킷, 오브젝트, 멀티파트 업로드, 조건부 요청, 오브젝트 메타데이터, 태그, 버전 관리, 라이프사이클 관리, 오브젝트 잠금, 사전 서명된 URL, 버킷 정책, CORS, 알림, 복제 구성, 서버 측 암호화 등입니다.
RustFS는 테스트된 하위 집합으로, Amazon S3의 완전한 커버리지를 주장하는 것이 아닌 S3 호환성 매트릭스를 게시합니다. 2026년 8월 9일 1e6f5f1e 커밋 기준으로 검증된 스냅샷은 455개의 구현된 표준 테스트, 5개의 라이프사이클 동작 테스트, 17개의 미구현 표준 테스트, 그리고 호환성 게이트를 막지 않는 270개의 제외 사례를 목록화합니다. 해당 수치가 변할 때 scripts/s3-tests 아래에 있는 실행 가능 목록이 진실의 원천(source of truth)이 됩니다.
RustFS의 적합성
RustFS는 애플리케이션이 적절한 S3 오브젝트 스토리를 기대할 때 후보가 됩니다.
대표적인 사용 용도로는 애플리케이션 오브젝트 스토리지, 백업 저장소, 미디어 스토리지, AI 및 데이터 파이프라인 산출물, 내부 S3 인프라, Kubernetes 워크로드, 기존 MinIO 엔드포인트 대체가 있습니다.
AWS SDK와 일반적인 S3 클라이언트와 함께 작동합니다. 애플리케이션은 일반적으로 사용자 정의 엔드포인트, 자격 증명, 필요한 경우 리전 설정, 경로 스타일 주소 지정(path-style addressing)이 필요합니다.
중요한 한계점
RustFS는 스토리지 표현을 소유합니다. 데이터 디렉터리 아래에 있는 파일들은 RustFS 내부 구조입니다.
이것은 모든 S3 오브젝트가 오브젝트 스토리지 소프트웨어 없이도 검사, 복사, rsync, 복구가 가능한 일반 파일로 남아야 하는 요구사항이 있을 때 RustFS가 잘못된 답임을 의미합니다. 이러한 요구사항은 파일시스템 기반 게이트웨이를 선택하게 합니다.
Garage: Ceph 규모의 복잡성 없는 분산 S3
Garage는 소규모 및 중규모 셀프호스팅 설치 환경용 S3 호환 분산 오브젝트 스토어입니다. Deuxfleurs가 AGPL v3 라이선스 하에 개발하며, 2020년 프로젝트의 초기 릴리스부터 프로덕션 환경에서 운영해 왔습니다.
Garage는 여러 대의 일반 서버, 물리적으로 다른 위치에 있는 서버를 포함한 서버 전체에서 실행되도록 설계되었습니다. 복제(replication)는 설계의 일부입니다.
전용 스토리지 하드웨어 랙이 아닌 세 대의 소형 서버를 가지고 있을 때 Garage가 매력적입니다. Docker부터 클러스터 레이아웃, 복제, 리버스 프록시를 통한 TLS까지 작동하는 설정 경로는 Garage 퀵스타트에 있습니다.
Garage의 적합성
Garage는 홈 랩, 소형 호스팅 플랫폼, 지리적으로 분산된 서버, 복제된 백업, Ceph가 과도할 클러스터에 적합합니다.
그 범위는 AWS S3보다 좁습니다. Garage의 호환성 테이블에는 버킷 정책, ACL, 버킷 버전 관리가 빠져 있습니다. 가볍고 다중 노드 복제가 주요 요구사항일 때 Garage를, 더 넓은 S3 동작과 MinIO 유사한 애플리케이션 호환성이 더 중요할 때 RustFS를 선택하세요.
SeaweedFS: 오브젝트 스토어를 넘어
SeaweedFS는 방대한 수의 파일을 효율적으로 저장하는 것으로 시작했습니다. 현재는 S3, FUSE 파일시스템, WebDAV, SFTP, HDFS를 노출하는 분산 스토리지 플랫폼입니다. SeaweedFS 4.48은 2026년 9월 28일에 릴리스되었습니다.
볼륨 서버는 블롭(blobs)을 추가 전용(append-only) 볼륨 파일에 패키징합니다. 마스터는 개별 파일이 아닌 볼륨을 추적합니다. 필러(filer)는 계층적 파일시스템 의미를 제공합니다. 이 설계는 수백만 개 또는 수십억 개의 비교적 작은 오브젝트를 다루는 워크로드를 목표로 합니다.
S3 지원
SeaweedFS는 버전 관리, 오브젝트 잠금, 라이프사이클 규칙, 태깅, CORS, 체크섬, 사전 서명된 URL, 멀티파트 업로드, 버킷 정책, IAM, STS, 그리고 몇 가지 서버 측 암호화 모드를 문서화합니다.
동일한 클러스터는 S3 테이블 버킷과 내장된 Iceberg REST 카탈로그를 제공할 수 있으므로, Spark, Trino, DuckDB 및 유사한 엔진은 별도의 Hive Metastore나 Glue 없이 Iceberg 테이블을 사용할 수 있습니다. 프로젝트의 1-커맨드 S3 예제는 포트 8333에서 수신합니다.
SeaweedFS의 적합성
웹 크롤러 및 아카이브, 이미지 및 문서 저장소, 수십억 개의 작은 오브젝트, 데이터 레이크, S3 및 파일시스템이 혼합된 워크로드, 볼륨 서버를 추가하여 확장되는 스토리지를 위해 SeaweedFS를 고려해 보세요.
간단한 RustFS 설치보다 이해해야 할 구성 요소가 더 많습니다. SeaweedFS는 필러와 FUSE 마운트를 통해 파일시스템 의미를 제공할 수 있지만, 오브젝트는 그 볼륨 형식 안에 저장됩니다. 모든 S3 오브젝트가 호스트 파일시스템에 있는 독립적인 일반 파일로 남아야 하는 요구사항을 충족하지 않습니다.
Ceph RGW: 인프라 규모 옵션
Ceph는 S3 스토리지보다 더 광범위합니다. 클러스터는 RBD를 통한 블록 디바이스, CephFS를 통한 파일시스템, RADOS Gateway(RGW)를 통한 오브젝트 스토리지를 제공할 수 있습니다. RGW는 RADOS 기반의 S3 호환 API를 제공합니다.
Ceph는 복제, 익명 코딩(erasure coding), 장애 도메인, 다중 게이트웨이, 멀티사이트 배포, 액세스 정책, 클러스터 관리 툴링을 지원합니다.
Ceph의 적합성
오브젝트 스토리지가 더 큰 스토리지 플랫폼의 한 부분일 때 Ceph가 적합합니다: Kubernetes 영속 볼륨, 가상 머신 디스크, 공유 파일시스템, 대규모 S3 저장소, 명시적인 장애 도메인이 필요한 클러스터 등이 해당됩니다.
수 테라바이트의 단일 서버에 S3 엔드포인트를 얻기 위해 Ceph를 설치하는 것은 정당화하기 어렵습니다. 이미 Ceph를 운영 중이라면 RGW가 자연스러운 S3 선택지입니다. 그렇지 않다면, RustFS 또는 Garage는 더 적은 장비로 유용한 오브젝트 스토리지에 도달할 수 있습니다.
VersityGW: 일반 파일 위의 S3
VersityGW는 파일시스템 자체가 중요할 때 평가해야 할 옵션입니다. Apache-2.0 라이선스로 된 S3 게이트웨이로, POSIX 파일시스템, ScoutFS, Azure Blob Storage, 다른 S3 서비스, 사용자 정의 백엔드를 노출할 수 있습니다.
그의 POSIX 백엔드는 S3 버킷과 오브젝트를 디렉터리와 파일에 매핑합니다. 예를 들어:
s3://website-assets/images/logo.png
는 다음과 같은 경로에 매핑됩니다:
/storage/website-assets/images/logo.png
logo.png 페이로드는 여전히 정상적인 파일로 남습니다.
일반 파일이 유용한 이유
일반적인 Unix 도구로 스토리지를 검사할 수 있습니다:
find /storage -type f
du -sh /storage/*
S3 서버 없이도 오브젝트를 읽을 수 있습니다:
cat /storage/archive/2026/source.html
전통적인 파일시스템 백업 도구가 직접 적용됩니다: rsync, restic, borg, tar, zfs send. 게이트웨이 소프트웨어가 사라져도 페이로드는 디렉터리 트리 안에 있는 파일로 남아 있습니다.
POSIX 백엔드에서의 S3 메타데이터
S3 메타데이터는 POSIX 파일 자체에 들어맞지 않습니다. VersityGW는 기본적으로 확장 속성(extended attributes)에 저장합니다. 2026년 3월부터, 파일시스템 키 길이 제한을 충족했기 때문에 오브젝트 메타데이터는 JSON을 포함하는 단일 user.metadata xattr입니다. versitygw utils convert-xattr-metadata 커맨드는 이전의 키별 속성을 다시 작성합니다. user.metadata가 없으면 읽기는 여전히旧的 레이아웃으로 폴백됩니다.
xattr가 없는 파일시스템은 --sidecar(또는 VGW_META_SIDECAR)를 사용하여 메타데이터를 별도의 디렉터리 트리에 유지할 수 있습니다. 프로젝트는 사이카르(sidecar)와 --nometa를 xattr보다 덜 테스트된 것으로 표시합니다. --nometa는 메타데이터 저장을 비활성화하며, 이미 존재하는 데이터셋의 읽기 전용 호스팅을 위해 사용됩니다; 버킷 정책과 ACL은 메타데이터이므로 그 모드에서는 사용할 수 없습니다.
오브젝트 버전은 별도의 디렉터리에 존재할 수 있습니다. 프로젝트의 POSIX 예제는 현재 페이로드가 자연스러운 경로에 남아 있는 동안 이전 버전을 위해 --versioning-dir를 전달합니다.
게이트웨이 뒤에서 파일을 변경하면 ETag를 포함한 S3 메타데이터가 새로운 바이트와 일치하지 않게 될 수 있습니다. 작동할 수 있는 운영 모델은 다음과 같습니다:
Application access:
Read through S3
Write through S3
Administrator access:
Read the filesystem directly
Inspect the filesystem directly
Back up the filesystem directly
Avoid modifying objects behind the gateway
VersityGW 1.8.0은 2026년 9월 COSI 드라이버 릴리스가 표적으로 삼은 버전으로, 스탠드얼론 IAM 서비스(versitygw iam), STS AssumeRoleWithWebIdentity, 그리고 IAM 정책 조건을 추가합니다.
S3Proxy: 범용 변환 레이어
S3Proxy는 S3 API를 구현하고 요청을 여러 백엔드로 변환합니다: 로컬 파일, Azure Blob Storage, Google Cloud Storage, OpenStack Swift, SFTP, 다른 S3 서비스 등입니다. Java 17 이상이 필요합니다.
권장되는 온디스크 프로바이더는 filesystem-nio2입니다. 이전의 filesystem 프로바이더는 비추천(deprecated)되었습니다. 오브젝트 키는 파일시스템 경로가 되고, 메타데이터는 사용자 확장 속성을 사용하므로 페이로드는 일반 파일로 남습니다.
파일시스템 백엔드는 오브젝트 버전 관리와 서버 측 암호화를 거부합니다. 버전 관리는 지원되지 않습니다(supportsVersioning()는 false이며, 해당 요청은 HTTP 501로 남음). 실제 디스크에 작성된 버전 레이아웃은 프로젝트가 유지해야 할 형식이 되어버리기 때문입니다. 서버 측 암호화는 동일한 종류의 이유로 거부됩니다: 누군가가 읽을 수 있는 평문 파일에 대해 AES256을 보고하는 것은 거짓 주장이 되기 때문입니다. 인메모리 transient-nio2 백엔드는 둘 다 구현하며, 데이터는 프로세스와 함께 죽습니다. 프로젝트 README는 또한 버킷 정책, 오브젝트 태깅, private과 public-read를 제외한 ACL도 미지원으로 나열합니다.
S3Proxy는 백엔드 간에 그러한 변환이 필요할 때의 도구입니다. 직선적인 S3-to-POSIX 게이트웨이에 대해선, VersityGW가 더 작은 표면적(surface)을 가집니다.
rclone serve s3: 가볍지만 실험적
rclone serve s3는 rclone 백엔드를 S3 호환 API를 통해 노출합니다. 문서에서는 여전히 이 커맨드를 실험적(experimental)으로 분류합니다.
로컬 파일시스템의 경우:
rclone serve s3 \
--addr :9000 \
--auth-key ACCESS_KEY,SECRET_KEY \
local:/srv/s3
--addr가 없으면 서버는 127.0.0.1:8080에 바인딩됩니다. --auth-key는 Signature Version 4를 활성화합니다. 멀티파트 업로드는 파트 번호 순서로 임시 오브젝트에 작성되고, 완료 시 지정된 이름으로 변경되어, 실패한 업로드가 기존 오브젝트를 대체하지 않습니다.
local 백엔드를 통해 작성된 오브젝트는 그 경로 아래의 파일이 됩니다. 동일한 커맨드는 다른 rclone 리모트 앞에 놓일 수 있습니다. 내부 툴링, 랩, 또는 임시 마이그레이션 홉에는 적절한 선택지입니다. 그러나 수많은 독립적인 프로덕션 애플리케이션을 위한 약한 영구 S3 레이어입니다.
MinIO는 어떤가요?
MinIO GitHub 저장소는 2026년 2월 13일에 아카이브 처리되고, 잠시 아카이브가 해제되었다가 2026년 4월 25일에 다시 아카이브 처리되었습니다. 현재는 읽기 전용입니다. 저장소 공지 사항은 MinIO의 상업적 배포판인 AIStor로 운영자를 유도하며, 커뮤니티 에디션이 소스 전용(source-only)임을 명시합니다.
기존 MinIO 배포는 계속 실행될 수 있으며, 특히 격리되어 있고其行为가 이미 이해되고 있는 경우 더 그렇습니다. 전체 타임라인, 운영 리스크, 단계별 마이그레이션 계획은 2026년의 MinIO CE에 있습니다.
떠나고 있을 수 있는 시스템의 S3 동작에 대해, AWS S3 대안으로서의 MinIO는 MinIO가 S3로 어떻게 매핑되는지를 문서화합니다. MinIO 커맨드 라인 치트시트는 여전히 가동 중인 클러스터의 감사 동반자입니다. 새로운 설치의 경우, 적극적으로 유지 관리되는 대안이 기본이 됩니다.
일반 파일 vs 네이티브 오브젝트 스토리지
오브젝트 스토어가 내구성, 메타데이터, 분산, 레이아웃을 제어해야 할 때 RustFS, Garage, SeaweedFS, Ceph를 사용하세요. 그러면 더 풍부한 S3 의미론, 복제 또는 익명 코딩, 수평 스케일링, 프로젝트가 구현한 버전 관리가 보장됩니다. 비용은 엔진의 온디스크 표현에 대한 의존성입니다.
기존 파일시스템이 권위적인 상태로 남아야 할 때 VersityGW, S3Proxy, rclone를 사용하세요. 그러면 평범하고 복구 가능한 파일, 전통적인 백업, 직접 검사, ZFS, XFS, ext4, NFS와의 호환성이 보장됩니다. 분산 내구성은 그때 S3 프로세스가 아니라 파일시스템 또는 스토리지 어레이에서 나와야 합니다. 단일 서버 또는 NAS에서는 이러한 교환이 종종 올바른 선택입니다.
올바른 셀프호스팅 S3 서버 선택
MinIO와 유사해야 하는 단일 서버의 경우, RustFS부터 시작하세요.
복제가 주요 요구사항이고 애플리케이션이 버킷 정책과 버전 관리 없이 작동할 수 있는 3대 이상의 중형 서버의 경우, Garage를 선택하세요.
소규모 오브젝트 수가 방대하거나, 파일시스템 액세스가 혼합되거나, Iceberg 테이블로 성장할 수 있는 데이터 레이크 워크로드의 경우, SeaweedFS를 고려하세요.
동일한 클러스터가 블록 디바이스와 분산 파일시스템도 제공해야 할 때, Ceph RGW를 선택하세요.
요구사항이 구체적으로 일반 파일 위의 S3 API — NAS, 아카이브, 문서 저장소, 크롤러, 백업 대상 — 일 때, VersityGW부터 시작하세요.
S3를 Azure, GCS, Swift, SFTP, 또는 다른 S3 서비스로 변환하는 것이 작업일 때, S3Proxy를 사용하세요.
배포가 작고, 임시이며, 실험적인 서버를 허용할 수 있을 때, rclone serve s3가 충분할 수 있습니다.
단일 스토리지 서버를 위한 권장 아키텍처
애플리케이션이 S3를 통해서만 데이터에 도달해야 할 경우, RustFS는 오브젝트 레이어를 소유하고 파일시스템은 구현 세부 사항이 됩니다:
파일 자체는 게이트웨이가 사라져도 살아남아야 할 경우, 데이터를 POSIX 트리에 유지하세요:
두 번째 설계에서는, 중복성은 ZFS 미러, RAID, 스냅샷, 파일시스템 복제, 또는 전통적인 백업 도구입니다. S3 서비스는 데이터 형식을 다시 작성하지 않고도 교체될 수 있습니다.
최종 생각
MinIO의 공개 저장소가 읽기 전용이 된 후에도 유지 관리되는 셀프호스팅 S3는 여전히 존재합니다. 중요한 선택은 S3가 바이트를 소유하는지, 아니면 이미 존재하는 파일의 프론트만 하는지 여부입니다. 위 모든 비교는 그 답변에서 파생됩니다.
