RG 4 Tech가 ZimaBoard 2로 프라이빗 클라우드를 구축하는 방법

RG 4 Tech는 ZimaBoard 2를 단순한 소형 파일 서버 이상으로 활용합니다. 그의 구성은 저소음 x86 하드웨어, 직접 연결한 두 개의 드라이브, ZimaOS RAID 1 스토리지 풀, Home Assistant를 브라우저로 관리하는 하나의 시스템에 결합합니다. 그 결과 파일과 스마트 홈 서비스를 위한 실용적인 프라이빗 클라우드 기반이 마련되지만, 여전히 독립적인 백업과 Home Assistant Container와 Home Assistant OS의 차이를 고려한 배포 계획이 필요합니다.

전체 설정 과정을 기록해 준 RG 4 Tech에게 감사드립니다. 그의 원본 영상에서는 하드웨어, 내부 냉각, 초기 ZimaOS 구성, 2드라이브 RAID 1 설정, 애플리케이션 설치 및 Home Assistant 시작 과정을 다룹니다.

출처 참고: 이 글은 RG 4 Tech의 영상에 소개된 구성과 관찰 내용을 재구성한 것입니다. 이 글에서는 해당 협업 주장이 독립적으로 확인되지 않았으므로, 영상에 보이는 모든 기기가 ZimaSpace에서 제공되었다고 가정하지 않습니다. 인터페이스 세부 정보, 애플리케이션 버전, 제공 번들, 온도 및 호환성은 게시 후 변경될 수 있습니다.

결과: ZimaBoard 2는 RG 4 Tech에게 로컬 스토리지와 스마트 홈 제어를 위한 눈에 잘 띄지 않는 단일 플랫폼을 제공합니다. RAID 1은 구성 드라이브 중 하나에 장애가 발생해도 스토리지 풀을 계속 사용할 수 있게 해 주며, Home Assistant는 로컬 자동화 계층을 추가합니다. 그러나 두 기능 모두 중요한 데이터와 구성을 서버 외부에 백업해야 할 필요성을 없애 주지는 않습니다.

RG 4 Tech가 로컬 홈 서버로 시작하는 이유

영상에서 말하는 ‘클라우드와 작별’은 단순히 월 이용료를 피하는 것만을 의미하지 않습니다. 홈 서버를 사용하면 스토리지 하드웨어를 누가 제어하는지, 어떤 애플리케이션이 데이터를 처리하는지, 서비스가 네트워크에 어떻게 노출되는지, 용량을 언제 확장하는지를 직접 결정할 수 있습니다. 개인 파일과 스마트 홈 활동이 여러 제공업체에 나뉘어 저장될 수 있는 상황에서는 이러한 선택이 특히 중요해집니다.

로컬 소유권은 책임도 함께 이전합니다. 소유자는 드라이브 상태를 모니터링하고, 업데이트를 적용하며, 사용자 액세스를 관리하고, 백업을 유지하고, 장애 발생 후 서비스를 복구해야 합니다. 따라서 프라이빗 클라우드는 제공업체만 빠진 클라우드 서비스가 아니라, 운영 계획이 필요한 소규모 인프라입니다.

RG 4 Tech는 ZimaBoard 2를 폐쇄형 어플라이언스가 아닌 유연한 기반으로 활용합니다. 이 보드는 스토리지 서버로 시작한 뒤 ZimaOS를 통해 추가 애플리케이션을 호스팅할 수 있어, 실제 가정의 사용 방식에 맞춰 시스템을 확장할 수 있습니다.

ZimaBoard 2가 이 구성에 적합한 이유

ZimaBoard 2  미니 홈 서버는 Intel N150 프로세서, 온보드 메모리와 시스템 스토리지, 2개의 2.5GbE 포트, 2개의 SATA 연결부, 개방형 PCIe 확장 인터페이스를 결합합니다. 이 조합이 중요한 이유는 홈 서버에 CPU 성능 이상의 요소가 필요하기 때문입니다. 스토리지, 네트워킹, 향후 하드웨어를 위한 실용적인 연결 경로가 필요합니다.

두 개의 SATA 포트를 사용하면 USB 스토리지 브리지에 의존하지 않고 HDD 또는 SSD 두 개를 직접 연결할 수 있습니다. 듀얼 네트워크 인터페이스는 스토리지 링크, 네트워크 분리, 라우터 프로젝트 또는 포트 하나만으로는 제약이 생기는 다른 네트워크 구성을 지원할 수 있습니다. PCIe를 활용하면 NVMe 스토리지나 특정 작업에 맞는 다른 어댑터 등 필요한 확장 장치를 선택해 추가할 수 있습니다.

플랫폼은 여전히 컴팩트합니다. 하나의 PCIe 경로에 모든 확장 장치를 동시에 연결할 수는 없고, 두 개의 SATA 포트가 다중 베이 NAS를 만들어 주는 것도 아니며, Intel N150을 코어 수가 많은 가상화 프로세서처럼 취급해서도 안 됩니다. 액세서리를 추가하기 전에 서버의 주요 역할을 정하는 것이 이 설계에 가장 적합합니다.

섀시를 열면 냉각 전략이 드러납니다

08:16에 RG 4 Tech는 ZimaBoard 2 인클로저를 열고 내부 보드 구조와 액티브 쿨링에 사용하는 위치를 보여 줍니다. 완성된 외관만으로는 프로세서와 주변 부품에서 열이 어떻게 빠져나가는지 알 수 없기 때문에 유용한 장면입니다.

알루미늄 구조는 열 방출에 기여하며, 보드가 더 따뜻한 장소에 놓이거나 더 무거운 작업을 지속적으로 수행해야 할 때는 팬이 공기 흐름을 보강할 수 있습니다. 스토리지 활동, 애플리케이션 인덱싱, 실내 온도, 케이블 배치, 주변 표면은 모두 실제 설치 환경의 열 조건에 영향을 줍니다.

액티브 쿨링은 장식이 아니라 작업 부하에 따른 결정으로 봐야 합니다. 부하가 적은 파일 서버는 스토리지 전송, 애플리케이션 업데이트, 미디어 인덱싱, 스마트 홈 서비스를 동시에 실행하는 동일한 보드와 다르게 작동할 수 있습니다. 조립 후에는 유휴 상태의 온도만 확인하지 말고, 실제로 사용할 복합 부하에서 온도를 점검해야 합니다.

풀을 생성하기 전에 물리적 스토리지 계획하기

RG 4 Tech는 ZimaOS에서 스토리지를 구성하기 전에 두 드라이브를 연결합니다. 순서가 당연해 보이지만, 이는 어떤 디스크에 활성 데이터가 저장되고, 어떤 디스크가 이중화에 참여하며, 백업을 어디에 둘지 결정하기 전에 공유 폴더를 만들거나 애플리케이션을 설치하는 실수를 예방합니다.

두 개의 드라이브를 사용하는 서버에는 여러 가지 레이아웃을 적용할 수 있습니다. 디스크를 독립적으로 유지하거나, 성능 또는 용량을 위해 결합하거나, 중복성을 위해 서로 미러링할 수 있습니다. 올바른 선택은 사용 가능한 공간, 드라이브 장애 후에도 지속되는 가용성, 서로 다른 데이터 클래스 간의 분리 중 무엇을 우선시하는지에 따라 달라집니다.

드라이브 간 조합도 주의해야 합니다. 미러는 일반적으로 용량이 더 작은 구성 드라이브를 기준으로 용량을 제공하므로, 크기가 크게 다른 드라이브를 함께 사용하면 공간이 낭비될 수 있습니다. 새 풀에 중요한 데이터를 옮기기 전에 두 드라이브를 모두 테스트하고, 상태를 모니터링하며, 일련번호를 기록해야 합니다.

ZimaOS에서 두 드라이브 RAID 1 풀 생성하기

16:50에 RG 4 Tech는 ZimaOS 스토리지 인터페이스를 사용해 두 디스크를 선택하고 RAID 1을 구성합니다. 이 레이아웃은 구성 드라이브 전체에 미러링된 복사본을 기록하며, 드라이브 하나에 장애가 발생해도 풀을 계속 사용할 수 있는 대신 두 드라이브의 총 원시 용량 중 절반을 사용하지 못하게 됩니다.

ZimaOS는 ZimaOS RAID 옵션 가이드에서 RAID 1을 중복성 중심 옵션으로 제시합니다. 그래픽 워크플로를 사용하면 명령줄에서 어레이 전체를 직접 구성하지 않아도 드라이브를 식별하고 스토리지 모드를 선택할 수 있어, 처음 NAS를 구축하는 사용자의 진입 장벽을 낮춰 줍니다.

이 인터페이스를 사용하더라도 선택 내용을 확인해야 합니다. 새 어레이를 생성하면 선택한 디스크의 기존 데이터가 삭제될 수 있습니다. 최종 작업을 승인하기 전에 드라이브 식별 정보, 용량 및 필요한 복사본이 있는지 확인해야 합니다.

RAID 1이 유용하지만 여전히 백업이 아닌 이유

RAID 1은 특정한 한 가지 장애, 즉 구성 드라이브 중 하나의 손실을 해결합니다. 디스크 하나가 작동을 멈추면 다른 복사본을 통해 풀이 계속 접근 가능한 상태로 유지되며, 장애 장치를 교체하고 어레이를 재구축할 수 있습니다. 계속 온라인 상태를 유지해야 하는 서버에서는 이러한 가용성이 중요합니다.

미러링은 논리적 변경 사항을 두 드라이브에 모두 반복 적용합니다. 따라서 실수로 삭제한 파일, 덮어쓴 파일, 랜섬웨어 공격, 손상된 애플리케이션 상태 또는 관리자의 잘못된 명령이 두 복사본 모두에 영향을 줄 수 있습니다. 서버 전체가 도난당하거나 전기적 손상을 입거나 물리적으로 유실되면 어레이 전체가 한 번에 사라질 수 있습니다.

더 안전한 설계는 RAID 1과 다른 위치에 저장되는 버전 관리 백업을 결합합니다. RAID 레이아웃 및 NAS 백업 계획에 대한 ZimaSpace 가이드는 중복성, 백업 기록, 장치 외부 복사본이 서로 다른 위험을 해결하는 이유를 설명합니다.

ZimaOS, 스토리지 하드웨어를 앱 플랫폼으로 전환

풀이 준비되면 서버는 더 이상 기본적인 네트워크 공유로 남아 있을 필요가 없습니다. ZimaOS는 브라우저 기반 파일 관리와 애플리케이션 환경을 제공하므로 동일한 인터페이스에서 스토리지와 셀프 호스팅 서비스를 관리할 수 있습니다.

이 점에서 하드웨어는 단순한 2베이 디스크 인클로저보다 더 유용해집니다. 애플리케이션은 영구 파일을 로컬 풀에 저장하고, 운영 환경은 애플리케이션의 수명 주기를 관리할 수 있습니다. 가정에서는 파일 스토리지로 시작한 다음 첫날부터 완전한 홈 랩 스택을 배포하는 대신 서비스를 하나씩 추가할 수 있습니다.

애플리케이션 데이터가 보이지 않는 인프라가 되어서는 안 됩니다. 서비스를 설치하기 전에 구성 디렉터리, 데이터베이스, 업로드된 파일, 네트워크 포트 및 백업 방법을 확인하세요. 실행 중인 컨테이너는 쉽게 다시 만들 수 있지만, 컨테이너 내부의 상태 데이터는 그렇지 않을 수 있습니다.

Home Assistant를 설치하면 로컬 스마트 홈 제어 기능이 추가됩니다

19:07에 Home Assistant가 시작되고 RG 4 Tech가 초기 온보딩 화면에 도달합니다. 이는 ZimaBoard 2가 스토리지 환경과 함께 애플리케이션을 호스팅할 수 있음을 확인해 주며, 프로젝트에 호환되는 스마트 홈 장치와 자동화를 로컬에서 조정하는 두 번째 명확한 역할을 부여합니다.

Home Assistant를 사용하면 모든 자동화를 공급업체 클라우드를 통해 전송하는 대신 많은 결정을 홈 네트워크 내부에서 처리할 수 있습니다. 실제 로컬 제어 수준은 각 장치와 통합에 따라 달라집니다. 일부 제품은 로컬 API를 제공하지만, 다른 제품은 여전히 외부 계정이나 클라우드 연결을 요구합니다.

첫 화면은 배포의 시작이지 완료가 아닙니다. 시스템을 안정적으로 사용할 수 있으려면 소유자는 여전히 관리자 계정을 만들고, 집 위치를 설정하고, 검색된 장치를 검토하고, 안전한 원격 액세스를 구성하고, 자동화를 테스트하고, 백업 일정을 수립해야 합니다.

Home Assistant Container와 Home Assistant OS는 서로 다른 선택지입니다

기존 애플리케이션 플랫폼을 통해 Home Assistant를 설치한다는 것은 일반적으로 Home Assistant Container를 실행한다는 의미입니다. 공식 Home Assistant 설치 개요에서는 컨테이너 방식이 사용자가 직접 관리하는 호스트 및 컨테이너 환경을 사용한다고 설명합니다. 또한 Home Assistant OS에서 제공되는 앱 시스템도 포함하지 않습니다.

컨테이너 배포는 Home Assistant가 스토리지 및 다른 애플리케이션과 함께 실행될 수 있으므로 다목적 ZimaOS 서버에 적합합니다. Home Assistant OS는 시스템 전체를 Home Assistant 전용으로 사용하고 통합 관리 환경을 원하는 경우에 더 가전제품과 같은 선택지입니다.

RG 4 Tech의 방식은 여러 역할을 통합한다는 점에서 매력적입니다. 하지만 장애 범위를 고려해야 합니다. 공유 서버를 재부팅하거나 수리하는 동안 파일 액세스와 스마트홈 제어가 모두 일시적으로 영향을 받을 수 있습니다.

스토리지와 스마트홈 서비스에는 별도의 복구 계획이 필요합니다

미러링된 스토리지 풀과 실행 중인 홈 어시스턴트 인스턴스는 서로 다른 대상을 보호합니다. RAID 1은 구성 드라이브 하나에 장애가 발생해도 풀이 유지되도록 돕습니다. 홈 어시스턴트 백업은 구성, 자동화 및 지원되는 애플리케이션 상태를 보존합니다. 어느 쪽도 서버 외부에 안전한 복사본을 자동으로 생성하지는 않습니다.

이제 홈 어시스턴트는 설치 유형 전반에서 백업 생성 및 복원을 지원하며, 자세한 내용은 백업 통합 문서에 설명되어 있습니다. 이러한 백업은 동일한 2디스크 어레이와 동일한 물리적 시스템에 의존하지 않는 대상으로 복사해야 합니다.

실용적인 복구 테스트에서는 두 가지 질문을 별도로 확인해야 합니다. NAS를 잃은 후에도 가정의 파일을 복원할 수 있는가, 그리고 애플리케이션 호스트를 잃은 후에도 홈 어시스턴트를 복원할 수 있는가입니다. 두 답변 모두 동일한 서버가 계속 작동해야 한다면, 이 시스템에는 여전히 하나의 장애 도메인만 존재합니다.

이 통합 서버가 잘 처리하는 작업

같은 방식의 ZimaBoard 2 서버를 구축해야 하는 사람은 누구일까요?

이 구성은 첫 프라이빗 클라우드, 드라이브 두 개를 사용하는 가족용 NAS, 로컬 스마트홈 컨트롤러 또는 각 역할마다 별도의 컴퓨터를 할당하지 않고 컴팩트한 애플리케이션 호스트를 원하는 사람에게 적합합니다. 세련된 밀폐형 기기 디자인보다 조용한 작동과 개방형 하드웨어 확장성을 중요하게 여기는 경우 특히 매력적입니다.

NAS 유지보수 중에도 자동화를 계속 사용할 수 있어야 한다면 전용 Home Assistant 장치가 더 나은 선택일 수 있습니다. 더 큰 멀티 베이 NAS는 여러 용량 계층, 독립적인 스토리지 풀 여러 개 또는 더 폭넓은 드라이브 장애 허용성을 원하는 사용자에게 적합합니다. 코어 수가 더 많은 서버는 무거운 가상 머신을 여러 개 실행하거나 컴퓨팅 작업을 지속적으로 처리해야 할 때 더 적합합니다.

결정은 하드웨어가 실행할 수 있는 앱의 수가 아니라 장애 도메인에서부터 시작해야 합니다. 통합하면 공간과 전력, 관리 노력을 절약할 수 있지만, 재부팅 한 번이나 하드웨어 문제 하나로 여러 가정용 서비스가 동시에 중단될 수도 있습니다.

RG 4 Tech, 명확한 가정용 작업을 중심으로 프라이빗 클라우드 구축

RG 4 Tech의 프로젝트가 성공적인 이유는 모든 주요 단계에 목적이 있기 때문입니다. 섀시를 열면 열 관리와 유지보수 경로를 확인할 수 있습니다. 드라이브 두 개를 연결하면 스토리지 기반이 마련됩니다. RAID 1은 디스크 하나에 장애가 발생한 후에도 가용성을 높여 줍니다. ZimaOS는 이러한 스토리지를 더 쉽게 관리하게 해 주며, Home Assistant는 시스템을 로컬 자동화 플랫폼으로 확장합니다.

이 구축의 강점은 이러한 이점을 정확하게 설명할 때 가장 잘 드러납니다. RAID 1은 중복성을 제공할 뿐 백업이 아닙니다. Home Assistant 컨테이너는 Home Assistant OS와 동일하지 않습니다. 조용한 서버 한 대로 여러 유용한 작업을 통합할 수 있지만, 백업과 복구 계획을 서버 외부에 마련하지 않으면 위험 또한 한곳에 집중됩니다.

내부 하드웨어 점검, ZimaOS 스토리지 구성, RAID 1 워크플로와 Home Assistant 설치 과정을 확인하려면 RG 4 Tech의 전체 영상을 시청하세요. 또 다른 로컬 스마트홈 구축 방법은 ZimaBoard에서 Home Assistant 실행하기에서 확인하거나, ZimaSpace Discord 커뮤니티에 참여해 다른 사용자들과 홈 서버 구축 사례를 비교해 보세요.