CasaOS vs ZimaOS vs Unraid: 혼합 드라이브 NAS에 가장 적합한 홈 서버 OS는?

혼합 드라이브가 OS 선택에 미치는 영향

전통적인 RAID는 멤버 드라이브가 용량과 성능이 비슷할 때 가장 예측 가능하게 작동합니다. 용량이 다른 드라이브가 섞여 있으면, 가장 작은 멤버가 각 디스크가 기여하는 공간을 결정할 수 있습니다. 따라서 큰 디스크는 배열에서 즉시 사용할 수 없는 용량을 가질 수 있습니다.

Unraid는 다른 접근 방식을 취합니다. 기본 배열은 개별적으로 포맷된 데이터 디스크에 파일을 저장하고 패리티를 별도로 계산합니다. 중요한 크기 규칙은 어떤 데이터 디스크도 패리티 디스크보다 커서는 안 된다는 것입니다. 이중 패리티의 경우, 두 패리티 디스크 모두 가장 큰 데이터 디스크만큼 크거나 커야 하며, 이는 공식 문서의 Unraid 배열 아키텍처 및 패리티 크기에서 설명되어 있습니다.

이 구분은 비교를 안내할 다섯 가지 질문을 만듭니다:

• 각 드라이브 용량 중 얼마나 많은 부분이 사용 가능한가요?
• 저장소 모델이 중복성을 제공하나요?
• 풀을 재구성하지 않고 다른 크기의 드라이브를 추가할 수 있나요?
• 보호 체계가 감당할 수 있는 것보다 더 많은 드라이브가 고장 난 후에도 어떤 데이터에 접근할 수 있나요?
• 얼마나 많은 수동 Linux 관리가 필요한가요?

세 가지 저장소 모델, 세 가지 다른 장애 경계

세 플랫폼 모두 네트워크를 통해 파일을 노출하고 컨테이너화된 애플리케이션을 실행할 수 있지만, 저장소 관리 방식은 다릅니다. 운영 체제, 저장소 계층, 애플리케이션 대시보드 간의 구분이 시각적 유사성보다 더 중요합니다.

Unraid: 전용 패리티가 있는 독립 데이터 디스크

Unraid는 독립적으로 포맷된 데이터 디스크를 공유 저장소로 결합하면서 한두 개의 드라이브를 패리티용으로 예약합니다. 기존 RAID 5나 RAID 6처럼 모든 파일을 모든 배열 구성원에 스트라이핑하지는 않습니다.

이 결과는 드라이브 크기가 다를 때 특히 유용합니다. 4TB와 8TB 데이터 디스크는 할당된 패리티 디스크가 가장 큰 데이터 디스크 이상인 한 각각의 용량을 기여할 수 있습니다. 단점은 패리티 디스크가 일반 파일 용량 대신 보호 기능을 제공한다는 점입니다.

ZimaOS: RAID 및 JBOD를 위한 그래픽 관리

ZimaOS는 그래픽 저장소 관리를 갖춘 목적 특화 홈 서버 운영체제입니다. 현재 저장소 인터페이스는 RAID 0, RAID 1, RAID 5, RAID 6 및 JBOD를 지원하며, ZFS는 별도의 옵션으로 제공됩니다.

기존 RAID는 강력한 중복성을 제공하지만, 구성원 드라이브 용량이 일치할 때 가장 공간 효율적입니다. JBOD는 혼합된 컬렉션의 원시 용량을 더 많이 사용할 수 있지만 중복성을 제공하지 않습니다.

CasaOS: Linux 저장소 위의 애플리케이션 계층

CasaOS는 Debian 또는 Ubuntu 같은 Linux 배포판 위에 설치된 경량 애플리케이션 및 Docker 관리 계층에 가깝습니다. CasaOS와 완전한 저장소 중심 운영체제의 차이는 CasaOS와 ZimaOS 홈 서버 역할 가이드에서도 설명되어 있습니다.

CasaOS는 마운트된 저장소를 표시하고 애플리케이션에서 사용할 수 있도록 하지만, 더 고급 풀링과 패리티는 보통 그 인터페이스 아래에서 생성해야 합니다. 이는 Linux 파일 시스템, 소프트웨어 RAID, MergerFS, SnapRAID 또는 다른 저장소 관리 계층을 포함할 수 있습니다.

각 시스템에서 동일한 혼합 드라이브 세트가 어떻게 변하는지

4TB 드라이브 1개, 8TB 드라이브 1개, 16TB 드라이브 1개가 포함된 홈 서버를 고려해 보세요. 목표는 단일 드라이브 고장에 대비하면서 공유 저장소를 만드는 것입니다.

Unraid에서 16TB 디스크를 패리티로 사용하면 4TB와 8TB 디스크가 데이터 멤버가 되어 파일 시스템 오버헤드 전 약 12TB의 사용 가능한 파일 용량을 제공합니다. 16TB 디스크를 데이터 디스크로 사용하려면 최소 16TB 크기의 패리티 디스크가 필요합니다.

ZimaOS는 현재 저장 마법사를 확인하지 않고 정확한 혼합 드라이브 RAID 5 용량을 할당해서는 안 됩니다. 문서에 따르면 시스템이 생성 중에 예상 용량을 계산하지만 4TB+8TB+16TB의 구체적인 결과를 공개하지는 않습니다. 따라서 ZimaOS RAID 및 JBOD 옵션 공식 가이드를 실제 장치에 표시된 예상치와 함께 사용해야 합니다.

CasaOS에서는 드라이브가 독립적으로 유지될 수 있지만, 이를 하나의 보호된 저장 풀로 제시하려면 추가적인 리눅스 구성이 필요합니다. 최종 용량과 장애 동작은 CasaOS 자체보다는 선택한 도구에 따라 달라집니다.

네이티브 패리티가 실제로 제공하는 것

이 비교에서 Unraid의 주요 장점은 단순히 크기가 다른 드라이브를 인식하는 것이 아닙니다. 그 장점은 혼합 용량 데이터 디스크, 공유 폴더, 전용 패리티, 그리고 그래픽 관리 워크플로의 조합에 있습니다.

단일 패리티에서는 배열이 하나의 실패한 디스크를 복구할 수 있습니다. 이중 패리티에서는 최대 두 개의 동시 디스크 실패를 복구할 수 있습니다. 패리티 디스크는 가장 큰 데이터 멤버의 크기 요구 사항을 충족해야 하며, 실패한 디스크를 교체하려면 여전히 정상인 배열과 유효한 패리티 정보가 필요합니다. Unraid 배열에 데이터 및 패리티 디스크를 추가하는 공식 절차에서 이러한 제약 조건을 문서화하고 있습니다.

데이터 디스크가 개별 파일 시스템을 유지하기 때문에 파일이 모든 배열 디스크에 걸쳐 블록으로 나누어지지 않습니다. 장애가 가용 패리티 보호를 초과하면 정상 디스크의 데이터는 개별적으로 접근 가능할 수 있습니다. 이는 유용한 장애 경계이지만 파일 시스템 손상, 컨트롤러 고장, 실수로 인한 삭제, 악성코드, 또는 다중 동시 디스크 손실에 대한 보장은 아닙니다.

세련된 스토리지 인터페이스가 바꿀 수 없는 것

ZimaOS는 스토리지 생성을 쉽게 만듭니다. 인터페이스는 사용자가 디스크 선택, 지원되는 RAID 모드 선택, 용량 추정, 배열 생성 및 상태 모니터링을 안내할 수 있습니다. 이는 터미널에서 리눅스 스토리지를 완전히 관리하고 싶지 않은 사용자에게 설정 장벽을 줄여줍니다.

그러나 인터페이스는 선택한 스토리지 모델의 근본적인 트레이드오프를 제거하지는 않습니다. RAID 0은 중복성 없이 성능과 용량을 제공합니다. RAID 1은 데이터를 미러링합니다. RAID 5는 단일 디스크 장애 허용, RAID 6는 이중 디스크 장애 허용을 제공합니다. JBOD는 용량 유연성을 우선시하지만 패리티나 미러링을 제공하지 않습니다.

중요한 데이터를 저장하기 전에 복구 워크플로우도 테스트해야 합니다. 오픈된 ZimaOS 베타 RAID 수리 이슈는 약간 더 큰 교체 디스크가 인식되었지만 인터페이스를 통해 RAID 5 수리를 시작할 수 없었던 가상 머신 테스트를 문서화했습니다.

이 보고서는 모든 현재 ZimaOS 설치가 동일한 제한을 가진다는 것을 증명하지 않습니다. 이는 베타 시기의 단일 사례이지만, 스토리지 인터페이스는 초기 설정 마법사뿐만 아니라 교체 및 복구 워크플로우로 평가되어야 함을 보여줍니다.

간단한 앱 대시보드가 DIY 스토리지 스택이 될 때

CasaOS는 주된 목표가 애플리케이션 배포, Docker 컨테이너 관리, 이미 마운트된 스토리지를 깔끔한 인터페이스를 통해 노출하는 것일 때 매력적입니다. 그러나 요구 사항이 서로 다른 디스크로 구성된 패리티 보호 풀로 변경되면 덜 직관적이 됩니다.

일반적인 리눅스 기반 설계 중 하나는 MergerFS와 SnapRAID를 결합하는 것입니다:

• MergerFS는 여러 파일 시스템의 디렉터리를 하나의 병합된 마운트 포인트로 제공합니다.
• SnapRAID는 별도의 데이터 디스크 간에 패리티를 계산하며, 구성된 패리티 디스크가 커버하는 실패 수만큼 복구를 도울 수 있습니다.
• CasaOS는 애플리케이션을 실행하고 스토리지 계층이 구성된 후 결과 마운트 포인트를 노출합니다.

MergerFS는 크기와 유형이 다른 파일 시스템을 풀링할 수 있습니다 모든 디스크를 스트라이프 배열로 다시 포맷할 필요 없이. 실패한 디스크는 일반적으로 전체 풀에 파일을 분산시키기보다는 해당 파일 시스템에 저장된 파일에 영향을 미칩니다. MergerFS 자체는 패리티나 실패한 데이터 재구성을 제공하지 않습니다.

SnapRAID는 누락된 패리티 계층을 제공하지만 Unraid의 배열 보호와 동일하지 않습니다. SnapRAID 패리티는 동기화가 실행될 때 업데이트됩니다. 가장 최근 동기화 이후에 추가되거나 변경된 파일은 아직 복구할 수 없을 수 있어, 이 설계는 데이터베이스, 활성 가상 머신 디스크 또는 자주 변경되는 애플리케이션 데이터보다는 미디어 라이브러리 및 아카이브 데이터에 더 적합합니다.

DIY 경로는 저렴하고 유연할 수 있지만, 관리자는 마운트 순서, 패리티 동기화, 예약된 스크럽, SMART 모니터링, 권한, 교체 절차 및 알림에 책임을 져야 합니다. 이는 경험 있는 Linux 사용자를 위한 합리적인 엔지니어링 선택이며, Unraid의 무설정 대체품은 아닙니다.

확장, 복구 및 유지 관리가 초기 설정보다 더 중요합니다

만들기 쉬운 스토리지 시스템도 확장하거나 복구하기 어려울 수 있습니다. 운영 체제를 선택하기 전에 다음 드라이브가 더 클 때, 디스크가 오류를 보고하기 시작할 때, 시스템 디스크 자체를 다시 설치해야 할 때 어떤 일이 발생하는지 고려하세요.

시간에 따른 용량 추가

Unraid는 점진적 확장을 위해 설계되었습니다. 새로운 데이터 디스크는 기존 모든 디스크가 일치할 필요 없이 추가할 수 있으며, 단 패리티 디스크를 초과하지 않아야 합니다. 더 큰 데이터 디스크가 필요한 경우 먼저 패리티 디스크를 업그레이드해야 할 수 있습니다.

기존 RAID 및 ZFS 확장은 정확한 배열 또는 vdev 설계에 따라 다릅니다. 하나의 불일치 디스크를 추가한다고 해서 반드시 그 용량 전체가 즉시 사용 가능한 것은 아닙니다. ZimaOS 사용자는 원래 풀을 생성하기 전에 예상 용량과 지원되는 확장 절차를 확인해야 합니다.

CasaOS는 다른 마운트된 파일 시스템을 풀에 추가할 수 있기 때문에 MergerFS에서 유연한 확장을 상속할 수 있습니다. SnapRAID가 보호를 제공하는 경우, 패리티 크기 조정 및 동기화도 수동으로 업데이트해야 합니다.

장애 복구

Unraid는 이 특정 혼합 드라이브 사용 사례에 대해 세 가지 중 가장 통합된 복구 경로를 제공합니다. ZimaOS는 그래픽 RAID 상태 및 복구 제어를 제공하지만, 작업 흐름은 선택한 RAID 유형과 현재 소프트웨어 동작에 따라 달라집니다. CasaOS 복구는 거의 전적으로 기본 Linux 스토리지 설계에 의존합니다.

이 방법들 중 어느 것도 테스트된 백업의 필요성을 없애지 않습니다. 복구 계획은 어떤 파일이 백업되었는지, 암호화 키와 구성 파일이 어디에 저장되었는지, 패리티나 RAID 수준이 감당할 수 있는 것보다 더 많은 디스크가 고장 났을 때 시스템을 어떻게 복원할지 식별해야 합니다.

어떤 설정이 혼합 드라이브 NAS에 적합한가요?

최근 Unraid와 ZimaOS의 실사용 테스트는 Unraid를 고급 NAS 기능과 접근성 좋은 인터페이스의 균형으로 평가했으며, ZimaOS는 초보자와 재활용 하드웨어에 특히 친숙하다고 평가했습니다.

이 비교는 저장소 아키텍처의 증거라기보다는 1인칭 경험으로 유용합니다. 공식 문서는 패리티 한계, RAID 지원, 용량 계산 및 복구 절차에 대한 주요 출처로 남아야 합니다.

라이선스도 결정에 영향을 줄 수 있습니다. 2026년 7월 기준으로 Unraid의 입문 라이선스는 $49부터 시작하며 평생 라이선스는 훨씬 더 비쌉니다. ZimaOS는 디스크 수로 제한된 무료 티어와 저렴한 평생 Plus 라이선스를 제공합니다. CasaOS는 무료이자 오픈 소스이지만 DIY 관리자는 저장소 계층을 구축하고 유지하는 데 더 많은 시간을 쓸 수 있습니다.

오래된 드라이브 박스를 재사용하기 전에

혼합 드라이브 지원은 노후된 디스크를 동일하게 신뢰할 수 있게 만들지 않습니다. 배열이나 풀을 만들기 전에:

1. 드라이브에 이미 저장된 모든 파일을 백업하세요.
2. SMART 데이터를 검토하고 확장된 드라이브 자체 테스트를 실행하세요.
3. 재할당, 대기 중이거나 수정 불가능한 섹터가 있는지 확인하세요.
4. 부하가 걸릴 때 SATA, USB 및 전원 연결이 안정적인지 확인하세요.
5. Unraid 배열을 구축할 때 가장 큰 정상 드라이브를 패리티로 사용하세요.
6. 드라이브 일련 번호와 물리적 베이 위치를 기록하세요.
7. 장애 알림과 교체 절차를 테스트하세요.
8. NAS가 작동한 후 중요한 파일의 별도 백업을 유지하세요.

회전 속도가 다른 드라이브는 공존할 수 있지만, 작업에 참여하는 가장 느린 디스크가 성능을 제한할 수 있습니다. USB 인클로저와 포트 멀티플라이어도 드라이브 식별과 오류 복구를 복잡하게 만들 수 있으므로, 영구 NAS에는 직접 SATA 또는 신뢰할 수 있는 HBA 연결이 더 바람직합니다.

최종 요약

중앙 요구 사항이 서로 다른 용량의 드라이브로 조립된 패리티 보호 NAS이고 한 번에 한 디스크씩 확장하는 것이라면 Unraid를 선택하세요. 라이선스 비용이 추가되지만 스토리지 모델이 혼합 드라이브 문제를 직접 해결합니다.

사용 편의성, 매력적인 스토리지 제어, 애플리케이션 배포, 그리고 낮은 라이선스 비용이 불일치하는 드라이브 모음에서 최대 보호 용량을 추출하는 것보다 중요하다면 ZimaOS를 선택하세요. 중요한 데이터를 옮기기 전에 정확한 RAID 구성에 대한 용량 추정과 교체 작업 흐름을 확인하세요.

주로 간단한 애플리케이션 대시보드를 원하고 스토리지를 별도의 리눅스 엔지니어링 프로젝트로 다루는 데 익숙하다면 CasaOS를 선택하세요. MergerFS와 SnapRAID는 능력 있는 혼합 드라이브 시스템을 만들 수 있지만 운영 작업이 추가되며 Unraid의 네이티브 대안으로 제시되어서는 안 됩니다.