MinIO CE가 사실상 사라진 2026년, 이제 뭘 써야 할까
조용히 사라진 MinIO CE
최근 몇 달 사이 MinIO CE 관련 이슈들이 눈에 자꾸 걸렸습니다. 처음엔 단발성 잡음 정도로 봤는데, 하나씩 연결해보니 그게 아니더라고요. 2026년 현재 MinIO CE는 사실상 커뮤니티 배포가 중단된 상태입니다.
이게 하나의 사건이 아니라 점진적인 변화였다는 점이 핵심입니다. 2025년 5월부터 주요 관리 기능이 엔터프라이즈로 옮겨가기 시작했고, 10월에는 커뮤니티 Docker 이미지와 바이너리 배포가 멈췄어요. 12월에 유지보수 모드 메시지가 떴고, 2026년 2월 저장소가 처음 보관되었다가 4월부터는 아예 잠긴 상태입니다.
타임라인을 쭉 늘어놓고 보면 패턴이 보입니다. 한 번에 문을 닫은 게 아니라, 운영자들이 알아채기 어려운 속도로 천천히 잠근 거죠. 그래서 더 위험합니다. 한 방에 끊겼으면 다들 곧장 대안을 찾았을 텐데, 점진적이라 '아직은 괜찮겠지' 하고 넘어가게 되니까요.
라이선스는 여전히 AGPLv3입니다. 다만 실질적으로는 소스에서 직접 빌드해야 하는 상황이 됐어요. 라이선스 문구는 그대로인데 운영 경험은 완전히 달라진 셈이죠.
운영팀에게 생긴 새로운 부담
객체 스토리지가 바이너리 패치를 더 이상 받지 않는다는 건, 단순히 다운로드 링크 하나가 사라진 문제가 아닙니다. 패치 파이프라인 자체가 통째로 바뀌는 일이죠.
패치 사이클의 변화
- 기존: CVE 발표 → 패치된 바이너리 다운로드 → 배포 (몇 시간)
- 현재: CVE 발표 → 소스 클론 → 빌드 → 검증 → 배포 (며칠)
몇 시간짜리 작업이 며칠짜리로 바뀌면, 그 시간 차이만큼 노출 창이 열려 있다는 뜻이기도 합니다. 보안 패치는 속도가 곧 방어력인데, 그 속도를 잃는 거죠.
더 골치 아픈 건 일의 성격이 바뀐다는 점입니다. 모든 보안 이슈가 빌드 문제로 치환되면서, 제품에 집중해야 할 시니어 엔지니어가 객체 스토리지 빌드를 들여다보고 있게 됩니다. 운영 PM으로 일하면서 가장 아까웠던 게 바로 이런 종류의 시간이었어요. 누군가는 해야 하는데, 그게 만든 가치는 0에 가까운 일. 패치 빌드는 정확히 그 범주에 들어갑니다. 특히 인터넷에 노출된 클러스터를 굴리고 있다면 이 부담은 선택이 아니라 의무가 됩니다.
여기에 더해, 공개 Docker 이미지를 전제로 짜둔 CI/CD 파이프라인들이 예고 없이 깨지기 시작했어요. 이미지 풀(pull) 한 줄에 의존하던 자동화가 어느 날 빨갛게 물드는 식이죠. 생태계 전반의 호환성 문제도 같이 따라옵니다. 한 컴포넌트의 배포 모델이 바뀌면, 그걸 기반으로 쌓아 올린 것들이 줄줄이 흔들립니다.
실제로 쓸 만한 대안들
운영자 커뮤니티에서는 이미 2025년부터 짐을 싸기 시작했습니다. 지금 시점에서 어느 정도 검증된 옵션들을 정리해보면 이렇습니다.
SeaweedFS - 실용적인 선택
강점
- 소형 파일 처리에 강함 (Ceph 대비 훨씬 효율적)
- Apache 2.0 라이선스로 거버넌스가 명확함
- 활발한 커뮤니티와 안정적인 릴리스
- 일반 하드웨어에서도 성능이 나옴
약점
- S3 호환성이 좋긴 한데 100%는 아님
- MinIO 대비 브랜드 인지도가 낮음
라이선스가 Apache 2.0이라는 점은 생각보다 무겁게 봐야 합니다. 이번 MinIO 건이 결국 거버넌스와 배포 모델 문제였으니까요. 같은 함정을 두 번 밟지 않으려면 라이선스부터 보는 게 맞습니다. 대부분의 자체 호스팅 환경이라면 SeaweedFS가 가장 무난한 선택이라고 봅니다.
Garage - 경량화의 강자
강점
- 최소한의 리소스로 동작 (ARM 환경에서도 원활)
- 지리적 분산 설계가 처음부터 고려됨
- 운영 오버헤드가 매우 낮음
약점
- 전체 S3 기능 대비 제한적
- 상대적으로 작은 생태계
기능을 덜어내고 운영성을 챙긴 쪽입니다. 모든 걸 다 하려는 플랫폼보다, 할 일을 분명히 정해둔 플랫폼이 작은 팀에선 오히려 편하죠. 소규모 팀이나 엣지 환경이라면 Garage가 더 맞을 겁니다.
Ceph RGW - 엔터프라이즈 급
강점
- 성숙한 엔터프라이즈급 안정성
- 광범위한 S3 기능 지원 (버전 관리, 객체 잠금 등)
- 대규모 환경에서 검증됨
약점
- Ceph 운영 전문성 필요
- 높은 인프라 복잡도
- 학습 곡선이 가파름
Ceph는 강력하지만 공짜가 아닙니다. 라이선스 비용이 아니라 운영 인력 비용으로 청구되는 종류의 도구죠. OpenStack을 다뤄본 입장에서 보면 Ceph 운영은 '한 명이 풀타임으로 붙어도 될까 말까'한 영역입니다. 엄격한 S3 호환성이 필요한 대기업이라면 Ceph RGW가 답이겠지만, 대부분의 팀에는 과한 선택입니다. 객체 스토리지 하나 바꾸려다 클러스터 운영 조직을 새로 꾸리게 될 수도 있어요.
RustFS - 미래의 가능성
MinIO와 가장 비슷한 배포 경험을 준다고 합니다. 다만 아직 알파 단계예요. 실험적인 파일럿 정도로만 만져볼 만하고, 프로덕션 데이터를 맡기기엔 이릅니다. 마이그레이션을 고민하는 입장에서 '익숙함'은 큰 유혹이지만, 그 익숙함 하나 때문에 알파 버전에 데이터를 올리는 건 다른 차원의 도박이죠.
마이그레이션 계획 세우기
지금 MinIO CE를 쓰고 있다면, 한 번에 갈아엎는 대신 단계를 밟길 권합니다.
- 현황 파악: 버킷 수, 객체 수, 성장률 확인
- 위험도 분류: 인터넷 노출 여부, 중요도별로 우선순위 설정
- 호환성 테스트: 후보 플랫폼에서 실제 워크로드로 검증
- 점진적 이전: 저위험 워크로드부터 단계적으로 옮기기
호환성 테스트를 별도 단계로 빼둔 데는 이유가 있습니다. S3 호환이라고 적혀 있어도, 우리 애플리케이션이 실제로 호출하는 API가 다 받쳐주는지는 또 다른 문제거든요. 멀티파트 업로드, 버전 관리, 프리사인드 URL 같은 것들이 묘하게 안 맞아서 운영 중에 터지는 경우가 있습니다. 문서가 아니라 우리 워크로드로 검증해야 하는 이유죠.
특히 인터넷에 노출된 클러스터는 최우선으로 잡아야 합니다. 패치 속도가 며칠 단위로 늘어난 지금, 노출된 클러스터는 가장 먼저 위험이 현실화되는 지점이니까요.
대안별 적합한 사용 사례
| 상황 | 추천 대안 | 이유 |
|---|---|---|
| 일반적인 자체 호스팅 | SeaweedFS | 균형 잡힌 기능과 운영성 |
| 소규모/엣지 환경 | Garage | 낮은 리소스 요구사항 |
| 엔터프라이즈/금융 | Ceph RGW | 검증된 안정성과 완전한 S3 호환 |
| 실험/테스트 | RustFS | 향후 가능성 (단, 프로덕션 비추천) |
표로 정리하면 깔끔해 보이지만, 결국 선택은 '우리 팀이 어디까지 운영할 수 있는가'에 달려 있습니다. 기능표만 보고 Ceph를 골랐다가 운영 인력이 받쳐주지 않아 고생하는 경우를 적지 않게 봤어요.
생각해볼 점
이번 일을 보면서 다시 확인한 건, 오픈소스의 지속가능성은 기술적 우수성만으로 결정되지 않는다는 점입니다. MinIO CE는 여전히 좋은 소프트웨어예요. 코드 품질이 떨어져서 사람들이 떠나는 게 아니라, 커뮤니티 배포 모델이 바뀌면서 실질적인 운영 리스크가 생긴 겁니다. 원인과 결과를 분리해서 봐야 하는 지점이죠.
그래서 플랫폼을 고를 때 코드만 보면 안 됩니다. 누가 어떤 모델로 이걸 배포하고 유지하는지, 그 거버넌스가 우리 운영 가정과 충돌하지 않는지를 같이 봐야 해요. 기술은 코드에, 리스크는 배포 모델에 숨어 있는 경우가 많습니다.
당장 패닉할 일은 아닙니다. 기존 MinIO CE 클러스터가 오늘 멈추는 건 아니니까요. 다만 새로운 배포는 여기서 멈추고, 단계적인 마이그레이션 계획을 슬슬 깔아두는 게 합리적이라고 봅니다. 객체 스토리지처럼 데이터가 쌓이는 컴포넌트는 옮기는 비용이 시간이 갈수록 커지거든요. 미루는 만큼 청구서가 늘어나는 구조입니다.
결국 플랫폼의 안전은 코드가 아니라 그 뒤에 선 커뮤니티와 배포 모델의 건강함에 달려 있다는 걸, 이번에도 다시 확인하게 됐네요.