MinIO의 대안 찾기 — 싱글 노드 로컬 S3 대체제 6종 비교

본문

2025년 말 MinIO를 개발하던 회사가 다른 상업적 이익을 좇아 프로젝트를 사실상 포기하면서, 로컬에서 S3 스토리지를 에뮬레이션하던 수많은 데모와 S3 호환성 검증용 빌드 파이프라인이 흔들리게 되었습니다. 저자는 '가장 간단한 대체제'라는 기준을 세웠습니다. Docker 이미지가 존재할 것, S3 호환 API를 제공할 것, Apache 2.0 같은 OSI 정의상 오픈소스 라이선스로 무료 사용이 가능할 것, 싱글 노드 배포가 단순할 것, 그리고 6개월 뒤에 또 이 작업을 반복하지 않도록 활발한 커뮤니티나 상업적 후원자가 있을 것입니다. 멀티 노드 배포나 분산 스토리지, 프로덕션 운영은 평가 범위에서 제외했습니다.

테스트 환경과 기준선

기준선은 DuckDB가 Iceberg REST Catalog를 통해 S3에 데이터를 읽고 쓰는 단순한 Docker Compose 스택입니다. MinIO가 로컬 S3를 제공하고, MinIO CLI인 mc가 버킷 생성을 자동화합니다. DuckDB에 INSERT한 데이터는 Iceberg 포맷으로 MinIO에 parquet, avro, metadata.json 파일로 저장되며, 각 대체제마다 test.sh 스크립트로 동일한 스모크 테스트를 수행해 검증했습니다. S3 클라이언트로는 mc를 그대로 두었는데, s3cmd나 AWS CLI로 쉽게 교체할 수 있기 때문입니다.

대체제별 평가

S3Proxy(3.0.0)는 설정이 가장 쉬운 축에 속하고 가벼운 선택지로 평가받았습니다. Apache 2.0 라이선스에 Docker 이미지 다운로드 500만 회 이상입니다. 다만 의존 프로젝트인 jclouds가 2025년 중반 Apache Attic으로 이관되어 은퇴했다는 점을 지적했는데, 로컬 스토리지만 쓴다면 큰 문제는 아니라고 덧붙였습니다.

RustFS(1.0.0-alpha.79) 역시 설정이 쉽고 GUI까지 제공하지만, 최근 심각한 보안 취약점이 발견되어 일부 사용자가 기피한다는 점, 웹사이트가 겉만 번지르르하고 아직 알파 단계라는 점이 약점입니다. GitHub 스타는 19.7k로 높지만 첫 커밋이 2024년인 신생 프로젝트입니다.

SeaweedFS(4.06)는 Docker 이미지 교체만으로 거의 끝나지만 인증 설정을 위해 별도 설정 파일이 필요했고, 저자는 Docker Compose에 인라인으로 넣어 해결했습니다. 블로그 게시 직후 프로젝트 측이 이 추가 요구사항을 제거하겠다고 응답한 점도 소개됩니다. 2018년 0.91 릴리스부터 S3를 지원해온 오래된 프로젝트(GitHub 스타 29.5k)이며 기본 UI도 제공합니다. 다만 공식 사이트가 'SeaweedFS Enterprise'라는 제목과 가격 페이지만 있고 GitHub 링크도 찾기 어려워 OSS 프로젝트인지 오해하기 쉽다고 지적했습니다.

Zenko CloudServer(9.2.8)는 Scality가 만든 Zenko 도구 모음의 일부로, 과거 S3 Server로 불렸습니다. MinIO 교체 자체는 쉽지만 cloudserver/zenko/scality라는 이름들이 얽혀 있어 어떤 소프트웨어를 실행해야 하는지 파악이 다소 어려웠고, 문서가 구형 Docker 이미지를 가리키는 문제도 있었습니다.

Garage(1.0.0)는 설정이 가장 어려운 축입니다. garage 컨테이너 외에 초기 설정용 컨테이너와 TOML 설정 파일이 필요하고, 'GK로 시작하는 12바이트 hex 인코딩' 형식의 키 ID처럼 프로덕션 위생에는 훌륭하지만 로컬 데모에는 과도한 요구사항들이 있습니다. 라이선스도 AGPL입니다. 저자는 친구의 도움을 받아서야 구성을 마쳤다고 밝혔습니다.

Apache Ozone(2.1.0)은 Hadoop의 HDFS 프로젝트에서 2015년에 시작해 2020년 독립한 프로젝트로, S3 호환은 되지만 최소 4개 노드 없이는 배포 방법을 찾지 못할 정도로 무겁습니다. Ceph Object Gateway는 설치 문서를 보는 순간 포기했다고 적었습니다.

결론과 선택 기준

저자의 최종 선택은 SeaweedFS와 S3Proxy이고, RustFS는 '아마도', CloudServer는 '조건부 긍정', Garage와 Ozone은 이 용도에는 부적합으로 결론 내렸습니다. 마지막으로 두 가지 고려사항을 남겼습니다. 첫째 거버넌스로, Ozone만이 Apache Software Foundation 소유이고 나머지는 이론상 MinIO처럼 언제든 라이선스를 바꿀 수 있다는 점, 둘째 커뮤니티 건강도로, S3Proxy와 SeaweedFS처럼 오랜 역사를 가진 프로젝트도 사실상 단일 컨트리뷰터에 의존하는 '버스 팩터' 문제가 있다는 점입니다. 덧붙여 2026년 3월 Ruohang Feng이 MinIO를 pgsty/minio로 포크해 CVE 패치된 안정 배포판을 유지하겠다고 약속한 사례도 언급됩니다.

Hacker News 반응

• @sdcfgy — 그냥 파일시스템을 쓰면 됩니다. 왜 모두가 모든 것 사이에 HTTP를 끼워 넣으려 하는지 모르겠습니다.
• @xienze — S3만 지원하는 소프트웨어를 로컬에서 돌리고 싶을 수 있기 때문입니다.
• @Tostino — 프로덕션에서 쓸 도구를 로컬이나 CI에서 모킹하려는 것이며, 환경마다 애플리케이션 동작을 바꾸지 않아도 되는 좋은 이유가 있습니다.
• @wink — 이 글은 파일시스템 대체가 아니라 로컬 S3 스탠드인에 관한 것입니다. 프로덕션 배포에서 S3는 로컬 파일시스템과 다른 문제를 해결하는 경우가 많습니다.
• @Mashimo — S3 지원 도구를 출시하면 고객이 클라우드에 저장할지 로컬에 Docker 컨테이너를 띄울지 직접 결정할 수 있기 때문입니다.

원문: rmoff.net (Robin Moffatt) / 번역·요약: Trawling