Garage: S3 호환 분산 스토리지의 모든 것 - 아키텍처부터 실전 구축까지

Garage: The Complete Guide to S3-Compatible Distributed Storage

2026-02-06 IT/기술

서론: 셀프호스팅 시대의 오브젝트 스토리지

Amazon S3(Simple Storage Service)가 2006년에 등장한 이후, 오브젝트 스토리지는 현대 인프라의 핵심 구성 요소로 자리 잡았습니다. 이미지, 동영상, 백업 데이터, 로그 파일 등 비정형 데이터를 저장하고 관리하는 데 있어 S3 API는 사실상의 표준(de facto standard)이 되었으며, 수많은 애플리케이션과 도구들이 S3 호환 인터페이스를 기본으로 지원하고 있습니다.

그러나 퍼블릭 클라우드 의존은 비용 폭증, 데이터 주권 문제, 벤더 종속(Vendor Lock-in)이라는 근본적 과제를 수반합니다. 이에 따라 온프레미스 또는 개인 서버에서 S3 호환 스토리지를 직접 운영하려는 셀프호스팅 수요가 꾸준히 증가해 왔습니다. 대표 주자였던 MinIO는 높은 성능과 간편한 배포로 많은 사랑을 받았지만, AGPLv3 + 상용 이중 라이선스 체계로 전환하면서 오픈소스 진영에서 이탈하는 움직임을 보였고, 최근에는 GitHub 저장소가 유지보수 모드로 전환되면서 대안에 대한 관심이 급격히 높아졌습니다.

이러한 배경에서 주목받고 있는 프로젝트가 바로 Garage입니다. 프랑스의 비영리 단체 Deuxfleurs가 개발한 Garage는 "데이터센터 밖에서도 안정적으로 운영할 수 있는 S3 오브젝트 스토어"를 표방하며, 소규모 셀프호스팅 환경에 최적화된 독특한 접근 방식을 제시합니다. 이 글에서는 Garage의 핵심 철학, 내부 아키텍처, 설치 및 운영 가이드, 성능 튜닝, 그리고 경쟁 솔루션과의 비교까지 총체적으로 살펴보겠습니다.

1. Garage란 무엇인가?

1.1 Garage의 철학과 설계 목표

Garage는 2020년 첫 릴리스 이후, Deuxfleurs라는 프랑스의 소규모 비영리 호스팅 제공자에 의해 꾸준히 개발되어 온 S3 호환 분산 오브젝트 스토리지입니다. Deuxfleurs는 실제로 Garage를 자체 프로덕션 환경에서 사용하고 있으며, 3개 물리적 위치에 분산된 9개 노드로 구성된 멀티사이트 클러스터를 운영하고 있습니다.

Garage의 설계는 4가지 핵심 원칙에 기반합니다:

인터넷 친화(Internet-enabled): 데이터센터, 사무실, 가정 등 일반적인 인터넷 연결(FTTH 등)로 상호 연결된 멀티사이트 환경을 위해 설계되었습니다. 고속 전용선이 아닌 일반 가정용 인터넷으로도 충분히 동작합니다.
자족적이고 경량(Self-contained & Lightweight): 외부 서비스(etcd, ZooKeeper, PostgreSQL 등)에 의존하지 않으며, 단일 바이너리로 어디서든 실행할 수 있습니다. 하이퍼컨버지드 인프라에 자연스럽게 통합됩니다.
고복원력(Highly Resilient): 네트워크 장애, 네트워크 지연, 디스크 장애, 심지어 관리자의 실수에 대해서도 높은 복원력을 보장합니다.
단순성(Simple): 이해하기 쉽고, 운영하기 쉽고, 디버깅하기 쉬운 시스템을 지향합니다.

특히 주목할 점은 EU(유럽연합) 펀딩을 통해 2025년까지 안정적인 개발 자금을 확보했다는 것입니다. 이는 오픈소스 프로젝트의 지속 가능성이 종종 문제되는 상황에서 Garage의 장기적 비전에 대한 신뢰를 높여줍니다.

1.2 핵심 기능 요약

Garage가 제공하는 주요 기능은 다음과 같습니다:

S3 호환 API: GetObject, PutObject, DeleteObject, ListObjects, Multipart Upload 등 핵심 S3 연산을 지원합니다. 단, 오브젝트 버전관리(Versioning)나 오브젝트 잠금(Object Lock) 등 일부 고급 기능은 아직 미지원입니다.
지리 분산 복제(Geo-distributed Replication): 각 노드의 물리적 위치를 인식하여 데이터 복제본을 지리적으로 분산 배치합니다. 이는 재해 복구(DR) 시나리오에서 큰 장점이 됩니다.
정적 웹사이트 호스팅: 별도의 웹 서버 없이 Garage 자체적으로 버킷의 내용을 정적 웹사이트로 서빙할 수 있습니다. 도메인 이름이 버킷 이름에 직접 매핑되어 간편합니다. 이 기능은 MinIO나 Ceph에서는 지원하지 않는 Garage만의 특징입니다.
Admin REST API: 프로그래밍 방식으로 클러스터를 관리할 수 있는 완전한 REST API를 제공합니다.
모니터링 지원: Prometheus 포맷의 내부 메트릭과 OpenTelemetry 포맷의 트레이스 내보내기를 지원합니다.
K2V(실험적): 많은 소형 Key-Value 쌍의 저장과 조회를 위한 실험적 API로, S3 API를 보완하여 메타데이터 관리에 활용할 수 있습니다.
Zstd 압축 및 데이터 중복 제거: 저장되는 모든 데이터에 대해 선택적으로 Zstd 압축을 적용할 수 있으며, 동일한 데이터 블록은 자동으로 중복 제거됩니다.

한편, Garage는 몇 가지 명시적 비목표(Non-goals)를 선언하고 있습니다:

S3 API를 넘어선 기능 확장성 추구 안 함
이레이저 코딩(Erasure Coding) 등의 저장 최적화 기법 미적용 (단순 복제만 사용)
POSIX 파일시스템 호환성 미제공

2. Garage 아키텍처 심층 분석

2.1 분산 시스템 이론적 기반

Garage의 아키텍처는 분산 시스템 분야의 최신 연구 성과를 적극적으로 활용합니다. 핵심적인 세 가지 기반 기술은 다음과 같습니다:

Amazon Dynamo 패턴: 고가용성 Key-Value 스토어의 설계 원칙을 차용합니다. Dynamo가 제시한 "항상 쓰기 가능(Always Writable)" 철학을 따라, 일부 노드에 장애가 발생하더라도 데이터의 읽기와 쓰기가 계속 가능하도록 설계되었습니다.
CRDT(Conflict-Free Replicated Data Types): 여러 노드가 동시에 데이터를 수정하더라도 별도의 조율(coordination) 없이 일관된 최종 상태로 수렴하는 데이터 구조를 사용합니다. 이를 통해 네트워크 파티션 상황에서도 각 노드가 독립적으로 동작할 수 있습니다.
Maglev 로드 밸런싱: Google이 개발한 Maglev 해싱 알고리즘을 활용하여 요청을 효율적으로 분배합니다. 일관된 해싱(Consistent Hashing)을 통해 노드 추가/제거 시에도 최소한의 데이터 재배치만 발생합니다.

2.2 데이터 복제와 일관성 모델

Garage는 최종 일관성(Eventual Consistency) 모델을 채택하면서도, 실용적으로 강력한 보장을 제공합니다:

쿼럼 기반 읽기/쓰기: 단일 진실 공급원(Single Source of Truth) 대신, 읽기와 쓰기 모두 쿼럼(정족수) 합의를 통해 처리됩니다. 예를 들어, replication_factor = 3일 때 쓰기 연산은 3개 노드에 전송하되 2개 노드의 응답이 확인되면 성공으로 반환하고, 세 번째 노드의 쓰기는 비동기로 완료됩니다.
복구 메커니즘: 불일치가 발생한 경우 자동 복구(repair) 메커니즘이 일관성을 회복합니다.
Tombstone 마커: 분산 환경에서의 삭제 연산은 Tombstone(논리적 삭제 표시)을 사용하여 처리합니다. 이를 통해 "삭제한 데이터가 다른 노드에서 되살아나는" 문제를 방지합니다.

복제 계수(Replication Factor)는 사용자가 선택할 수 있으며, 대부분의 경우 replication_factor = 3이 권장됩니다. 이는 최대 1개 노드의 완전한 장애를 허용하면서도 데이터 가용성을 유지할 수 있음을 의미합니다. 저장 공간이 부족한 환경에서는 replication_factor = 2를 선택할 수도 있지만, 복원력이 떨어지므로 주의가 필요합니다.

2.3 노드 통신과 클러스터 관리

Garage의 클러스터 관리 방식은 기존 분산 스토리지 시스템과 크게 다릅니다:

Gossip 프로토콜: 중앙 코디네이터(etcd, ZooKeeper, Consul 등) 없이 노드 간 직접적인 피어-투-피어(P2P) 통신으로 클러스터 상태를 공유합니다. 이는 운영 복잡성을 대폭 낮추고 단일 장애점(SPOF)을 제거합니다.
Rust 단일 바이너리: 전체 시스템이 Rust로 작성되어 단일 바이너리로 컴파일됩니다. 메모리 효율성이 뛰어나며, Raspberry Pi 수준의 저사양 하드웨어에서도 동작할 수 있습니다. JVM이나 Python 런타임 등 별도의 의존성이 필요 없습니다.
이기종 하드웨어 지원: 대부분의 분산 스토리지 시스템이 균일한 고성능 하드웨어를 전제하는 반면, Garage는 서로 다른 스펙의 장비들을 혼합하여 클러스터를 구성할 수 있습니다. 각 노드의 저장 용량과 물리적 위치 정보를 활용하여 최적의 데이터 배치 계획을 자동으로 수립합니다.
자동 리밸런싱: 노드가 추가되거나 제거될 때, Garage는 자동으로 데이터를 재분배하여 원하는 복제 수준을 유지합니다.

3. Garage 설치 및 클러스터 구축 가이드

3.1 사전 요구사항

Garage 클러스터를 구축하기 위한 최소 요구사항은 다음과 같습니다:

노드 수: replication_factor = 3 사용 시 최소 3대의 머신이 필요합니다. 단일 노드 테스트 환경도 가능하지만, 프로덕션에서는 반드시 다중 노드를 권장합니다.
네트워크: 각 노드 간에 IP 통신이 가능해야 합니다. NAT 뒤에 있는 노드들은 퍼블릭 IPv4가 없을 수 있으므로, IPv6 사용이 가능하면 우선 권장됩니다.
VPN 솔루션: NAT 환경에서 IPv6를 사용할 수 없는 경우, Nebula, Yggdrasil, WireGuard 등의 메시 VPN을 구성하여 노드 간 직접 통신을 확보할 수 있습니다.
스토리지: 메타데이터 저장용 SSD와 데이터 저장용 HDD를 분리하는 것이 성능에 유리합니다.

3.2 설치 방법별 가이드

Garage는 다양한 방식으로 설치할 수 있습니다:

Docker 컨테이너 배포:

# docker-compose.yml 예시
version: '3'
services:
  garage:
    image: dxflrs/garage:v1.0
    ports:
      - "3900:3900"   # S3 API
      - "3901:3901"   # RPC
      - "3902:3902"   # Admin API
      - "3903:3903"   # Web (정적 사이트)
    volumes:
      - ./garage.toml:/etc/garage.toml
      - ./meta:/var/lib/garage/meta
      - ./data:/var/lib/garage/data
    restart: unless-stopped

Systemd 서비스 등록:

[Unit]
Description=Garage S3-compatible object store
After=network-online.target
Wants=network-online.target

[Service]
Type=simple
ExecStart=/usr/local/bin/garage server
Environment=GARAGE_CONFIG_FILE=/etc/garage.toml
Restart=always
RestartSec=5
StateDirectory=garage

[Install]
WantedBy=multi-user.target

Kubernetes 배포: Garage는 Helm 차트를 통한 Kubernetes 배포도 지원합니다. StatefulSet으로 구성되며, PersistentVolume을 통해 메타데이터와 데이터 스토리지를 관리합니다.

3.3 설정 파일(garage.toml) 핵심 항목

Garage의 설정은 garage.toml 파일 하나로 관리됩니다. 주요 설정 항목은 다음과 같습니다:

# 메타데이터 저장 경로 (SSD 권장)
metadata_dir = "/var/lib/garage/meta"

# 데이터 블록 저장 경로 (HDD 가능)
data_dir = "/var/lib/garage/data"

# 데이터베이스 엔진 선택
db_engine = "lmdb"

# RPC 통신 설정
rpc_bind_addr = "[::]:3901"
rpc_public_addr = "192.168.1.10:3901"
rpc_secret = "여기에_32바이트_헥스_시크릿_입력"

# 복제 설정
replication_factor = 3

# 블록 크기 (기본 1MB)
block_size = 1048576

# S3 API 엔드포인트
[s3_api]
api_bind_addr = "[::]:3900"
s3_region = "garage"
root_domain = ".s3.garage.localhost"

# S3 웹 (정적 사이트 호스팅)
[s3_web]
bind_addr = "[::]:3903"
root_domain = ".web.garage.localhost"

# Admin API
[admin]
api_bind_addr = "[::]:3902"
admin_token = "관리자_토큰"
metrics_token = "메트릭_토큰"

설정 파일 작성 후, 클러스터 구성은 garage CLI를 통해 진행합니다:

# 클러스터 상태 확인
garage status

# 노드에 저장 용량 할당 (예: 100GB, zone 'dc1', 태그 'node1')
garage layout assign -z dc1 -c 100G -t node1 <node-id>

# 레이아웃 변경사항 적용
garage layout apply --version 1

# 버킷 생성
garage bucket create my-bucket

# 액세스 키 생성
garage key create my-app-key

# 키에 버킷 권한 부여
garage bucket allow --read --write my-bucket --key my-app-key

4. Garage 튜닝 및 운영 최적화

4.1 메타데이터 엔진 선택

Garage v0.8.0부터 복수의 메타데이터 저장 엔진을 지원합니다. 선택 시 고려할 사항은 다음과 같습니다:

엔진	특징	권장 환경
LMDB (기본)	최고 성능, 가장 많이 테스트됨. 단, 아키텍처 종속적이고 32비트 미지원	replication_factor >= 2인 프로덕션 클러스터
SQLite	이식성 좋음, 비정상 종료에 강함. LMDB보다 느림	단일 노드 또는 아키텍처 이종 환경
Fjall (실험적)	LSM 트리 기반, 이론적으로 높은 쓰기 처리량	테스트 환경만 (프로덕션 사용 금지)

LMDB 사용 시 주의할 점이 있습니다. 비정상 종료 후 데이터베이스 파일이 손상될 수 있으므로, 정기적인 메타데이터 스냅샷이 필수입니다. Garage v0.9.4부터 내장된 자동 스냅샷 기능을 제공하며, BTRFS나 ZFS 파일시스템의 스냅샷 기능을 활용하는 것도 좋은 방법입니다. 스냅샷은 기본적으로 metadata_dir 하위의 snapshots/ 디렉토리에 저장되는데, 원본과 유사한 용량을 차지하므로 별도의 넉넉한 스토리지 경로로 변경하는 것을 권장합니다.

4.2 성능 튜닝

Garage의 성능을 최적화하기 위한 주요 튜닝 포인트는 다음과 같습니다:

block_size 조정: Garage는 저장되는 오브젝트를 block_size(기본 1MB) 단위의 연속 청크로 분할합니다. 대용량 파일을 주로 다루는 환경에서는 이 값을 늘려 청크 수를 줄일 수 있고, 소형 파일이 많은 환경에서는 기본값을 유지하는 것이 적합합니다.
쓰기 버퍼(Write Buffer): 쿼럼 쓰기 방식에서 세 번째 노드로의 비동기 쓰기를 버퍼링하는 메모리 영역입니다. 기본값은 256MiB이며, 쓰기 부하가 높은 환경에서는 이 값을 늘려 처리 속도를 개선할 수 있습니다.
SSD/HDD 분리 전략: 메타데이터(metadata_dir)는 SSD에, 데이터 블록(data_dir)은 HDD에 배치하는 것이 비용 대비 성능의 최적 조합입니다. 메타데이터 접근 속도가 Garage의 전체 응답 시간에 큰 영향을 미치기 때문입니다.
파일시스템 선택: 메타데이터 스토리지에는 BTRFS 또는 ZFS를 권장합니다. 체크섬 검증, 스냅샷, 자체 복구 기능 등이 LMDB의 안정성을 보완합니다. 데이터 스토리지에는 ext4도 충분합니다.

4.3 모니터링 및 로깅

Garage의 모니터링과 로깅은 다음과 같이 구성할 수 있습니다:

로그 레벨: RUST_LOG 환경 변수로 제어합니다. 사용 가능한 레벨은 error, warn, info(기본), debug, trace 순입니다. S3 API 호출이 예상대로 동작하지 않을 때 RUST_LOG=debug로 설정하면 상세한 디버그 정보를 얻을 수 있습니다.
Prometheus 메트릭: Admin API 엔드포인트에서 /metrics 경로로 Prometheus 포맷의 메트릭을 수집할 수 있습니다. Grafana 대시보드와 연동하면 클러스터의 상태를 시각적으로 모니터링할 수 있습니다.
OpenTelemetry 트레이싱: 분산 요청의 경로를 추적하기 위한 OpenTelemetry 호환 트레이스를 내보낼 수 있어, Jaeger나 Zipkin 등의 트레이싱 백엔드와 연동하여 성능 병목을 분석할 수 있습니다.

5. Garage vs 경쟁 솔루션 비교

5.1 Garage vs MinIO

MinIO는 오랫동안 셀프호스팅 S3 스토리지의 대표 주자였지만, 최근 라이선스 변경과 오픈소스 축소로 논란이 되고 있습니다. 두 솔루션의 핵심 차이점은 다음과 같습니다:

리소스 요구량: Garage는 Raspberry Pi에서도 동작할 정도로 경량인 반면, MinIO는 적정 성능을 위해 중~고사양 하드웨어를 요구합니다.
성능: 원시 처리량(Raw Throughput) 벤치마크에서는 MinIO가 우세합니다. 그러나 Garage는 리소스 효율성 측면에서 더 나은 가성비를 제공합니다.
지리 분산: Garage의 가장 큰 차별점입니다. MinIO에서 멀티사이트 배포를 구성하려면 복잡한 아키텍처 설계가 필요하지만, Garage는 지리 분산이 핵심 설계 원칙에 포함되어 있어 기본적으로 지원합니다.
라이선스: 둘 다 AGPLv3이지만, MinIO는 상용 라이선스를 추가로 요구하는 이중 라이선스 체계로 전환했으며, 최근 오픈소스 버전의 기능을 축소하고 있습니다.

5.2 Garage vs Ceph RGW

Ceph는 가장 성숙하고 기능이 풍부한 분산 스토리지 시스템이지만, 그만큼 복잡합니다:

복잡도: Ceph는 OSD, MON, MDS, CRUSH 알고리즘 등 다수의 컴포넌트와 개념을 이해해야 합니다. 전문 인력이 필요하며, 학습 곡선이 가파릅니다. Garage는 단일 바이너리와 하나의 설정 파일로 구성 가능합니다.
저장 효율: Ceph는 이레이저 코딩(Erasure Coding)을 지원하여 복제보다 적은 오버헤드로 데이터를 보호할 수 있습니다. Garage는 현재 단순 복제만 지원하므로, 3x 복제 시 저장 용량의 3배가 필요합니다.
멀티테넌시: Ceph RGW는 네임스페이스 격리, 리소스 쿼터, 정교한 접근 제어 등 엔터프라이즈급 멀티테넌시를 지원합니다. Garage는 버킷별-키별 권한 관리라는 단순한 모델을 사용합니다.
적용 범위: Ceph는 오브젝트, 블록, 파일 스토리지를 모두 제공하는 통합 솔루션인 반면, Garage는 오브젝트 스토리지에만 집중합니다.

5.3 비교 요약 표

항목	Garage	MinIO	Ceph RGW
개발 언어	Rust	Go	C++
라이선스	AGPLv3	AGPLv3 + 상용	LGPL (완전 오픈소스)
배포 복잡도	매우 낮음 (단일 바이너리)	낮음~중간	높음
S3 호환성	핵심 기능 중심 (확장 중)	가장 완전	광범위
이레이저 코딩	미지원 (3x 복제)	지원	지원 (유연한 K+M)
지리 분산	핵심 기능	복잡한 구성 필요	지원 (복잡)
리소스 요구량	매우 낮음	중~높음	높음
정적 사이트 호스팅	내장 지원	미지원	미지원
최적 대상	소~중규모 셀프호스팅, 지리 분산	고성능 단일 클러스터	대규모 통합 스토리지

6. 실전 활용 사례와 통합

Garage는 S3 호환 API를 제공하므로, S3를 지원하는 대부분의 애플리케이션과 자연스럽게 연동됩니다. 실전에서 자주 활용되는 시나리오들은 다음과 같습니다:

Nextcloud 외부 스토리지: Nextcloud의 "External Storage" 앱을 통해 Garage를 S3 호환 백엔드로 연결할 수 있습니다. 사용자 파일을 Nextcloud 서버의 로컬 디스크가 아닌 Garage 클러스터에 저장하여, 스토리지 확장성과 데이터 복원력을 동시에 확보할 수 있습니다.
Mastodon/Misskey 미디어 저장소: ActivityPub 기반 소셜 미디어 서버에서 사용자가 업로드하는 이미지, 동영상 등의 미디어 파일을 Garage에 저장합니다. Mastodon은 S3 호환 스토리지 설정을 기본으로 제공하므로 연동이 간편합니다.
정적 웹사이트 호스팅: Garage의 고유 기능으로, 별도의 Nginx나 Apache 없이 버킷의 내용을 웹사이트로 직접 서빙할 수 있습니다. Hugo, Jekyll, Astro 등 정적 사이트 생성기의 빌드 결과물을 배포하는 데 유용합니다.
Peertube 동영상 스토리지: 분산형 비디오 호스팅 플랫폼 Peertube의 동영상 파일 저장소로 활용할 수 있습니다.
백업 저장소: rclone, restic, Duplicity 등의 백업 도구와 연동하여 원격 백업 저장소로 활용할 수 있습니다. 지리 분산 복제 기능 덕분에 재해 복구(DR) 전략의 핵심 구성 요소로 적합합니다.
PowerDNS 백엔드: DNS 서버인 PowerDNS의 데이터 백엔드로 Garage를 활용하는 사례도 보고되고 있습니다.
GitLab/Gitea 아티팩트 스토리지: CI/CD 파이프라인에서 생성되는 빌드 아티팩트, 컨테이너 이미지 레이어 등을 Garage에 저장하여 Git 호스팅 서버의 로컬 디스크 부담을 줄일 수 있습니다.

결론: Garage를 선택해야 하는 경우

Garage는 모든 상황에 적합한 만능 솔루션이 아닙니다. 그러나 특정 조건에서는 다른 어떤 대안보다 탁월한 선택이 될 수 있습니다. Garage가 빛을 발하는 시나리오는 다음과 같습니다: 소규모~중규모 셀프호스팅 환경에서 운영 복잡성을 최소화하고 싶을 때, 여러 물리적 위치에 분산된 장비들을 하나의 스토리지 클러스터로 묶고 싶을 때, 이기종 하드웨어(구형 PC, Raspberry Pi, NAS 등)를 활용하고 싶을 때, 그리고 외부 의존성 없이 단순하고 견고한 오브젝트 스토리지가 필요할 때입니다.

반면, 현재 Garage의 한계도 명확합니다. 오브젝트 버전관리(Versioning)를 아직 지원하지 않으며, 이레이저 코딩 미지원으로 인해 3x 복제 시 저장 공간 효율이 낮습니다. S3 API의 완전한 구현이 아니므로, 고급 S3 기능에 의존하는 워크플로우에서는 호환성 문제가 발생할 수 있습니다. 또한 원시 성능 측면에서 MinIO에 미치지 못하므로, 고처리량이 필수적인 AI/ML 파이프라인이나 대규모 데이터 분석 워크로드에는 적합하지 않습니다.

결론적으로, 스토리지 솔루션 선택은 기능 목록만으로 결정할 문제가 아닙니다. 워크로드 특성, 장애 모델, 운영 제약 조건을 종합적으로 고려해야 합니다. 대규모 엔터프라이즈 통합 스토리지가 필요하다면 Ceph를, 단일 클러스터에서 최대 성능이 필요하다면 MinIO(또는 RustFS, SeaweedFS 등 대안)를, 소규모 셀프호스팅 환경에서 단순하고 견고한 지리 분산 스토리지가 필요하다면 Garage를 선택하시기 바랍니다. Garage는 "작지만 강한" 스토리지 솔루션으로서, 셀프호스팅 생태계에서 자신만의 확고한 위치를 구축해 나가고 있습니다.

목록으로 돌아가기