[NAS] MinIO로 Unraid 구축해 S3 호환 오브젝트 스토리지 만들기

목차

• 1. 왜 Unraid NAS에 MinIO를 올리게 됐는가
• 2. MinIO와 오브젝트 스토리지 개념부터 가볍게 정리
• 2.5. 제 홈랩에서 잡은 운영 기준
• 3. MinIO Unraid 실전 구축 단계
• 3.1 데이터 경로 설계
• 3.2 컨테이너 실행 예시
• 3.3 초기 접속과 버킷 생성
• 3.4 백업 도구와 연결하는 방식
• 4. 실제 활용 사례: 그냥 저장소가 아니라 워크플로우가 바뀝니다
• 4.1 백업 저장소 분리
• 4.2 S3 API 연동 테스트
• 4.3 로그와 산출물 보관
• 5. ⚠️ 구축하면서 실제로 겪은 문제와 해결법
• 5.1 포트 충돌
• 5.2 경로는 맞는데 권한처럼 보이는 문제
• 5.3 내부망 테스트 없이 외부 공개부터 하는 실수
• 5.4 작은 파일이 아주 많은 경우
• 6. 검증 방법과 결과 확인
• 7. 운영 팁: 처음부터 크게 가지 말고, 단순하게 시작하세요
• 8. 자주 묻는 질문과 마무리
• Q1. Unraid NAS에 MinIO를 올리면 기존 SMB 공유를 대체하나요?
• Q2. 꼭 외부 공개해야 하나요?
• Q3. 홈랩에서 어떤 용도가 가장 실용적이었나요?

[NAS] MinIO로 Unraid 구축해 S3 호환 오브젝트 스토리지 만들기

홈랩을 굴리다 보면 어느 순간 파일 공유만으로는 부족해질 때가 있습니다. 저도 처음엔 Unraid NAS에 SMB만 잘 붙여 쓰면 끝이라고 생각했었는데, 백업 도구나 애플리케이션이 S3 호환 스토리지를 요구하는 순간부터 이야기가 달라지더라고요. 그래서 이번 글에서는 MinIO Unraid 조합으로 오브젝트 스토리지(Object Storage, 객체 단위 저장소)를 올리고, 실제로 NAS 데이터 백업과 실험 환경에서 어떻게 써먹었는지 정리해보겠습니다. 제가 직접 해보니 생각보다 금방 붙긴 했는데, 중간에 포트 충돌이랑 권한 쪽에서 삽질 좀 했습니다 ㅎㅎ

특히 홈랩에서 S3 API를 흉내 내는 게 아니라, 실제로 S3 호환 오브젝트 스토리지처럼 동작하는 환경이 하나 있으면 백업 자동화, 애플리케이션 테스트, 로그 보관 같은 작업이 꽤 편해집니다. 혹시 "NAS는 있는데 S3는 너무 거창한 거 아닌가?" 싶으셨다면, 여기서 감이 좀 잡히실 겁니다.

Unraid NAS 위에 MinIO를 올리고 여러 클라이언트가 S3 API로 접속하는 전체 구조를 보여주는 이미지입니다.

1. 왜 Unraid NAS에 MinIO를 올리게 됐는가

제가 MinIO 구축을 고민하게 된 계기는 단순했습니다. 요즘 백업 도구나 개발 도구가 S3를 기본 대상으로 많이 보거든요. 예를 들어 백업 스크립트는 로컬 폴더보다 버킷(bucket, 오브젝트 저장 단위)을 기준으로 설계된 경우가 많고, 일부 앱은 아예 S3 엔드포인트(endpoint, 접속 주소)를 넣는 칸이 따로 있습니다.

• 백업 결과물을 파일 공유와 분리해서 관리하고 싶었습니다.
• 애플리케이션 테스트용으로 S3 API가 필요했습니다.
• 퍼블릭 클라우드에 올리기 전에 로컬에서 먼저 검증하고 싶었습니다.
• 홈랩에서도 운영 감각을 유지하고 싶었습니다.

결론부터 말하면, MinIO Unraid 조합은 이런 용도에 꽤 잘 맞았습니다. Unraid는 디스크 관리와 Docker 운영이 편하고, MinIO는 S3 호환 인터페이스가 분명해서요. 드디어 "NAS 안에 파일 폴더 하나 더 만든 수준"이 아니라, 오브젝트 스토리지를 별도 서비스처럼 다루게 되더라고요.

2. MinIO와 오브젝트 스토리지 개념부터 가볍게 정리

저도 처음엔 이게 뭔가 싶었는데, 쉽게 말해 오브젝트 스토리지는 파일을 폴더 트리 중심으로 다루기보다, 객체(object)와 메타데이터(metadata)를 API로 다루는 방식에 가깝습니다. NAS의 일반적인 파일 공유와 느낌이 꽤 달라요.

구분	파일 스토리지	오브젝트 스토리지
접근 방식	경로 기반	API 기반
대표 인터페이스	SMB, NFS	S3 API
데이터 단위	파일/폴더	버킷/오브젝트
잘 맞는 용도	일반 파일 공유	백업, 아카이브, 앱 연동

MinIO는 이런 S3 호환 인터페이스를 제공하는 소프트웨어입니다. 흔히 퍼블릭 클라우드의 S3와 비슷한 방식으로 애플리케이션을 붙여볼 수 있게 해주죠. 물론 완전히 같은 운영 환경이라고 보면 안 되고, 홈랩에서는 주로 테스트용, 내부 백업용, API 연동용으로 접근하는 게 현실적입니다.

여기서 중요한 포인트! Unraid는 저장소 관리 플랫폼이고, MinIO는 그 위에서 도는 오브젝트 스토리지 서비스입니다. 둘의 역할이 다르기 때문에, "NAS에 그냥 공유 폴더 만들면 되는 거 아닌가요?"라는 질문과는 결이 다릅니다. 실제로 써보니까 S3를 요구하는 앱에는 이 차이가 꽤 크게 느껴졌습니다.

2.5. 제 홈랩에서 잡은 운영 기준

무조건 화려하게 시작할 필요는 없었습니다. 오히려 처음에는 단순해야 덜 꼬입니다. 저는 아래 기준으로 잡았어요.

• 단일 노드(single node)로 시작하기
• Docker 컨테이너로 먼저 검증하기
• 데이터 경로와 앱 설정 경로를 분리하기
• 외부 공개보다 내부망 우선으로 운영하기
• 백업 도구 연동은 한 번에 하나씩 붙이기

이렇게 해두면 문제 생겼을 때 원인 추적이 쉽습니다. 처음부터 리버스 프록시(Reverse Proxy, 역방향 프록시), 인증서, 외부 DNS까지 한 번에 얹으면 어디서 꼬였는지 보기 어렵거든요.

3. MinIO Unraid 실전 구축 단계

이제 본론입니다. 저는 Unraid의 Docker 기능을 기준으로 구성했습니다. Community Applications에서 템플릿을 쓰는 방법도 있고, 직접 변수와 경로를 맞춰 넣는 방식도 있습니다. 여기서는 원리를 이해하기 쉬운 형태로 정리해볼게요.

1. Unraid에서 MinIO용 데이터 경로를 정합니다.
2. 관리 계정용 환경 변수를 준비합니다.
3. API 포트와 콘솔 포트를 분리합니다.
4. 컨테이너를 실행합니다.
5. 웹 콘솔과 S3 클라이언트로 동작을 확인합니다.

3.1 데이터 경로 설계

제가 추천하는 건 앱 설정과 실제 오브젝트 데이터를 분리하는 겁니다. 나중에 컨테이너를 갈아엎어도 데이터 손상 가능성을 줄이기 좋거든요.

# 예시 경로
/mnt/user/appdata/minio
/mnt/user/minio-data

보통은 아래처럼 나눠 생각하시면 됩니다.

• appdata: 컨테이너 설정 관련
• minio-data: 실제 버킷 데이터

3.2 컨테이너 실행 예시

Unraid 템플릿 화면에 아래 내용을 대응해서 넣으면 됩니다. 저는 처음엔 포트를 대충 잡았다가 기존 서비스와 충돌해서 다시 잡았어요. 이 부분 꼭 확인하세요.

docker run -d \
  --name=minio \
  -p 9000:9000 \
  -p 9001:9001 \
  -e MINIO_ROOT_USER=minioadmin \
  -e MINIO_ROOT_PASSWORD=change-this-password \
  -v /mnt/user/minio-data:/data \
  -v /mnt/user/appdata/minio:/root/.minio \
  quay.io/minio/minio server /data --console-address ":9001"

실제로 운영하실 땐 예시 비밀번호를 그대로 쓰시면 안 됩니다. 길고 복잡하게 잡으세요. 그리고 포트 9000은 S3 API, 9001은 관리 콘솔 용도로 많이 씁니다.

Unraid의 Docker 설정에서 포트와 볼륨 매핑을 어떻게 잡는지 한눈에 보여주는 이미지입니다.

3.3 초기 접속과 버킷 생성

컨테이너가 올라오면 브라우저에서 관리 콘솔에 접속해도 되고, 클라이언트 툴로 확인해도 됩니다. 저는 명령어로 확인하는 걸 좋아해서 mc를 같이 썼습니다. mc는 MinIO Client입니다.

mc alias set homelab http://NAS-IP:9000 minioadmin change-this-password
mc mb homelab/backup-bucket
mc ls homelab

여기까지 되면 일단 기본 뼈대는 완성입니다. 버킷이 보이면 ✅ 1차 성공입니다.

3.4 백업 도구와 연결하는 방식

제가 가장 먼저 붙여본 건 백업 작업이었습니다. NAS 데이터 백업 대상이 S3 형태를 지원하면 꽤 편해요. 도구마다 옵션 이름은 다르지만, 대체로 아래 정보가 필요합니다.

• 엔드포인트: http://NAS-IP:9000
• 액세스 키(access key)
• 시크릿 키(secret key)
• 버킷 이름
• 리전(region): 로컬 테스트에서는 도구 기본값 또는 지정 가능한 값 사용

예를 들어 rclone 같은 도구를 붙일 때는 S3 타입의 리모트를 만들고 엔드포인트를 직접 지정하는 식으로 접근합니다. 클라우드 이전 검증용으로도 괜찮았고, 내부망 백업 대상으로도 꽤 깔끔했습니다.

# 예시: 파일 업로드 테스트
mc cp /path/to/testfile homelab/backup-bucket

4. 실제 활용 사례: 그냥 저장소가 아니라 워크플로우가 바뀝니다

여기서부터가 진짜 재미있었습니다. MinIO Unraid를 올리고 나니 단순히 저장 공간 하나 생긴 게 아니라, 작업 흐름 자체가 달라졌거든요.

4.1 백업 저장소 분리

가장 먼저 체감한 건 백업 대상 분리였습니다. 기존에는 NAS 공유 폴더에 이것저것 백업을 던져 넣었는데, 나중에 보니 관리가 꽤 지저분해지더라고요. 버킷 단위로 분리하니까 프로젝트별, 서버별, 용도별 구분이 쉬웠습니다.

4.2 S3 API 연동 테스트

개발 환경이나 셀프호스팅 앱 중에는 파일 저장 백엔드로 S3를 기대하는 경우가 있습니다. 이럴 때 퍼블릭 클라우드 자격 증명을 바로 쓰기보다, 내부에서 먼저 S3 호환 스토리지로 붙여보는 게 훨씬 부담이 적습니다. 실패해도 비용 걱정이 덜하고, 네트워크도 단순하니까요.

4.3 로그와 산출물 보관

압축 아카이브, 빌드 결과물, 주기적 덤프 파일 같은 걸 장기 보관하기에도 감이 좋았습니다. 물론 홈랩에서는 무조건적인 고가용성(High Availability)을 기대하면 안 되지만, 워크플로우 분리 용도로는 충분히 유용했습니다.

5. ⚠️ 구축하면서 실제로 겪은 문제와 해결법

이 섹션은 이론보다 중요합니다. 저도 여기서 시간을 제일 많이 썼거든요.

5.1 포트 충돌

Unraid에는 이미 여러 컨테이너가 돌고 있을 가능성이 큽니다. 9000, 9001 포트가 비어 있을 거라고 생각하면 안 됩니다. 저는 처음에 콘솔이 안 열려서 한참 봤는데, 알고 보니 다른 서비스가 같은 포트를 쓰고 있었어요.

• 증상: 웹 콘솔 접속 실패
• 원인: 동일 포트 사용
• 해결: 컨테이너 포트는 유지하고, 호스트 포트를 다른 값으로 매핑

5.2 경로는 맞는데 권한처럼 보이는 문제

컨테이너가 데이터를 못 쓰는 것처럼 보일 때가 있습니다. 실제로는 경로 매핑이 꼬였거나, 예상한 위치와 다른 share를 가리키는 경우가 있었어요. 특히 Unraid는 share와 disk 경로 개념을 헷갈리면 시간을 날립니다.

• /mnt/user/... 기준으로 경로를 다시 확인하세요.
• 데이터용 경로와 설정용 경로를 섞지 마세요.
• 컨테이너 재생성 전에 마운트 대상이 맞는지부터 보세요.

5.3 내부망 테스트 없이 외부 공개부터 하는 실수

사실 저도 처음엔 "기왕이면 외부에서도 붙어야지" 하고 욕심냈었는데, 이건 순서가 아닙니다. 내부 IP로 접속, 버킷 생성, 업로드 테스트까지 끝난 다음에 리버스 프록시와 TLS를 얹는 게 맞더라고요. 안 그러면 네트워크 이슈인지 앱 이슈인지 구분이 안 됩니다.

5.4 작은 파일이 아주 많은 경우

이건 환경마다 체감 차이가 있지만, 작은 오브젝트가 매우 많이 쌓이는 패턴은 생각보다 운영 감각이 다릅니다. 저는 그래서 처음부터 "무엇을 넣을지"를 분명히 정했습니다. 범용 파일 공유처럼 다 때려 넣는 게 아니라, 백업 결과물이나 앱 산출물처럼 성격이 분명한 데이터에 쓰는 쪽이 관리가 편했습니다.

버킷 구조와 테스트 업로드 흐름을 설명하는 이미지로, 실제 운영 전에 어떤 데이터가 어디로 들어가는지 이해하는 데 도움이 됩니다.

6. 검증 방법과 결과 확인

구축은 올리는 것보다 검증이 더 중요합니다. "컨테이너가 떠 있다"와 "실제로 쓸 수 있다"는 전혀 다른 이야기거든요.

1. 웹 콘솔 접속 확인
2. 버킷 생성 확인
3. CLI 업로드/목록 조회 확인
4. 백업 도구 연동 테스트
5. 복구 또는 다운로드 테스트

mc ls homelab
mc cp homelab/backup-bucket/testfile ./restore-testfile

저는 마지막 복구 테스트까지 해보고 나서야 "이제 써도 되겠다" 싶었습니다. 업로드만 성공했다고 끝내면 안 됩니다. 복원 경로가 정상인지까지 봐야 하거든요. 실제로 써보니까 이 단계에서 버킷 정책이나 자격 증명 실수가 발견되는 경우가 있었습니다.

운영 결과로는 아래 세 가지가 가장 만족스러웠습니다.

• 백업 대상이 폴더 중심에서 버킷 중심으로 정리됐습니다.
• S3 연동 앱 테스트를 로컬에서 먼저 검증할 수 있었습니다.
• Unraid NAS 안에서 파일 공유와 오브젝트 스토리지 역할을 분리할 수 있었습니다.

MinIO 콘솔에서 버킷과 오브젝트가 정상적으로 보이는 상태를 나타내는 검증용 이미지입니다.

7. 운영 팁: 처음부터 크게 가지 말고, 단순하게 시작하세요

홈랩에서는 특히 그렇습니다. 처음부터 멀티노드, 외부 공개, 복잡한 인증 체계를 한 번에 구성하면 결국 디버깅 지옥으로 갑니다. 제가 추천하는 흐름은 이렇습니다.

1. 단일 컨테이너로 MinIO 구축
2. 내부망에서 버킷 생성 및 업로드 테스트
3. 백업 도구 하나만 먼저 연결
4. 복구 테스트 완료 후 운영 범위 확대
5. 필요하면 다음 글에서 리버스 프록시와 TLS를 다루기

이전 글에서 Unraid의 share 설계와 캐시 전략을 정리했다면 훨씬 수월하고, 다음 글에서는 MinIO 앞단에 프록시를 두는 방식도 다뤄볼 만합니다. 내부 링크 관점에서도 이 흐름이 자연스럽습니다.

8. 자주 묻는 질문과 마무리

Q1. Unraid NAS에 MinIO를 올리면 기존 SMB 공유를 대체하나요?

아닙니다. 성격이 다릅니다. SMB는 일반 파일 공유에, MinIO는 S3 호환 오브젝트 스토리지가 필요한 워크로드에 더 잘 맞습니다.

Q2. 꼭 외부 공개해야 하나요?

그럴 필요 없습니다. 저도 내부망에서만 오래 굴려봤고, 그 자체로도 충분히 유용했습니다. 오히려 처음에는 내부망 전용을 추천드립니다.

Q3. 홈랩에서 어떤 용도가 가장 실용적이었나요?

제 기준으로는 NAS 데이터 백업, 앱 파일 저장소 테스트, 아카이브 성격의 결과물 보관이 가장 실용적이었습니다.

정리해보면, MinIO Unraid 조합은 "집에 있는 NAS를 조금 더 클라우드스럽게 써보고 싶다"는 분에게 꽤 괜찮은 선택지였습니다. 제가 직접 해보니 설치 자체는 어렵지 않았고, 중요한 건 설계 욕심을 줄이고 검증 순서를 지키는 거였습니다. 처음엔 좀 헷갈렸는데, 버킷 생성과 업로드가 딱 성공하는 순간 "아, 이래서 다들 S3를 기준으로 얘기하는구나" 싶더라고요. 🎉

마지막 팁 하나만 드리면, MinIO 구축은 설치보다 운영 습관이 더 중요합니다. 무엇을 넣을지, 누가 접근할지, 복구는 어떻게 검증할지까지 같이 보셔야 합니다. 그걸 기준으로 잡으면 홈랩에서도 충분히 실용적인 오브젝트 스토리지를 만들 수 있습니다.

파일 공유와 오브젝트 스토리지의 차이, 그리고 홈랩에서의 활용 포인트를 요약한 마무리 이미지입니다.

📚 함께 읽으면 좋은 글

• Active Backup for Business vs Synology Active Backup: 백업 솔루션 비용 및 성능 비교
• rclone을 활용한 NAS-클라우드 백업, 치명적인 설정 실수와 복구 사례 연구
• TrueNAS ZFS 풀 확장: 성능 저하 없이 용량 늘리는 방법 분석
• 홈서버 OS 비교: Proxmox VE, TrueNAS SCALE, Unraid, OMV 완벽 분석