Zima에서 전하는 말
Bob님, ZimaCube와 함께한 시간을 일반적인 리뷰보다 훨씬 유용한 기록으로 만들어 주셔서 감사합니다. Bob님의 꾸준한 일지는 첫인상과 하드웨어 분해부터 ZimaOS, Windows Server, Proxmox, 백업, 모니터링, AI 에이전트, 심지어 가상화된 라우터에 이르기까지 장비의 역할이 어떻게 변해 가는지를 따라가면서, 마음에 드는 부분과 불편한 부분을 같은 기록 안에 함께 담고 있습니다. 이러한 장기적이고 솔직한 실험은 ZimaCube가 무엇을 할 수 있는지뿐만 아니라, 실제 홈랩의 일부가 된 뒤 어떤 일이 일어나는지도 이해하는 데 도움이 됩니다.
— Zima
Bob Loves Tech을 만나보세요
Bob Loves Tech은 Windows, Linux, 가상화, 네트워킹, 셀프 호스팅, 그리고 이를 뒷받침하는 하드웨어를 아우르며 활동하는 홈랩 사용자이자 기술 크리에이터입니다.
그가 Zima 하드웨어와 맺어 온 인연은 이 프로젝트보다 오래되었습니다. Bob은 Zima Pioneer Programme에 참여하기 전부터 ZimaBoard와 ZimaBlade를 비롯한 이전 Zima 제품을 이미 사용해 본 경험이 있었습니다. ZimaCube가 도착했을 때 그는 하나의 완성도 높은 리뷰를 작성하고 끝내는 대신, 홈랩과 함께 장비가 변화할 때마다 계속 확장되는 공개 저장소인 ZimaCube Experience Blog를 만들었습니다.
Bob은 이를 공식 리뷰가 아니라 꾸준히 이어가는 일지라고 설명합니다. 이러한 구분이 이 프로젝트를 잘 보여줍니다. 여기에는 하드웨어에 대한 첫 반응, 개봉 후 발견한 점, 사용해 본 운영 체제, 장비 주변에 구축한 인프라, 그리고 몇 주간 사용한 뒤 달라진 결론이 담겨 있습니다.
첫인상을 넘어 ZimaCube 기록하기
Bob의 프로젝트 초기 기록은 대부분의 하드웨어 이야기와 마찬가지로 장비를 개봉하고, 빌드 품질을 살펴보고, 포트와 드라이브 캐디를 확인하며, 하드웨어를 실제 책상 위에 올려두었을 때 무엇이 다르게 느껴지는지 판단하는 데서 시작합니다.
하지만 이 일지는 여기서 멈추지 않습니다. Bob은 제품과 함께 생활한 뒤 다시 하드웨어로 돌아갑니다. 그의 저장소에는 전용 하드웨어 개요, 전체 분해기, 6주 후속 기록, CPU 코어가 아니라 메모리가 실질적인 병목이 된 이유를 자세히 살펴본 글, 그리고 결국 모든 리뷰어가 마주하게 되는 질문을 던지는 별도 글이 포함되어 있습니다. 그가 정말 자신의 돈을 들여 구매할 것인가?
이러한 진행 과정이 이 프로젝트를 가치 있게 만듭니다. 첫인상은 제품이 어떤 상태로 도착하는지 알려줍니다. 반면 꾸준히 기록한 일지는 새로움이 사라진 뒤에도 무엇이 남는지 보여줍니다.
하드웨어를 열어보고 세부 사항을 따라가기
하드웨어 관련 장 중 하나의 제목은 단순히 분해하기입니다. 이는 Bob의 접근 방식을 잘 보여줍니다.
그는 ZimaCube를 밀봉된 NAS 어플라이언스로 취급하는 대신 섀시를 열어 내부를 기록했습니다. 여기에는 냉각 시스템과, 누군가 이 장비를 직접 정비하고 개조할 수 있어야 한다고 판단했을 때 비로소 드러나는 작은 하드웨어 세부 사항도 포함됩니다.
이 분해 작업은 이후 기록의 또 다른 부분으로 이어집니다. 6주 후 무엇이 달라졌고 무엇이 달라지지 않았는지에 관한 내용입니다. 시간이 지나면서 중요도가 낮아지는 관찰도 있습니다. 반면 냉각, 팬 작동, 메모리 용량, 업그레이드 접근성, 그리고 상시 가동 환경에 하드웨어가 어떻게 어울리는지를 비롯한 요소는 더욱 중요해집니다.
동일한 하드웨어에 관한 내용을 더 자세히 살펴보고 싶은 독자를 위해, ZimaCube 분해 가이드에서는 내부 구조와 업그레이드 경로를 자세히 설명합니다. 또한 ZimaCube의 영리한 설계 디테일 7가지에서는 사양표만 볼 때가 아니라 시스템을 직접 열어 보았을 때 확인할 수 있는 세부 사항을 자세히 살펴봅니다.
더 많은 CPU 코어보다 RAM이 중요하다는 사실을 알아내다
이후 하드웨어 관련 기록 중 하나는 또 다른 벤치마크 차트보다 훨씬 유용한 결론에 도달합니다. Bob의 워크로드에 ZimaCube는 더 많은 CPU 코어가 필요하지 않았습니다. 더 많은 메모리가 필요했습니다.
그의 기록에 따르면 게스트 10개가 실행 중인데도 CPU 사용량은 약 4%에 머물렀지만, 메모리 사용량은 약 27GB까지 증가했습니다. 이는 하드웨어를 평가하는 방식 자체를 바꿉니다. 실제로 먼저 한계에 도달한 것은 프로세서가 아니었습니다. 기본 메모리 구성이었습니다.
가상화 호스트, 백업 서버, 모니터링 노드, 라우터 VM 호스트, AI 실험 환경으로 점차 발전하는 시스템에서는 메모리 용량이 사양이 아니라 인프라가 됩니다.
이야기가 장기간 이어진 사용자 경험에서 바로 이런 결론이 도출됩니다. CPU가 이론적으로 무엇을 할 수 있는지 묻는 데서 나온 결론이 아닙니다. 실제 워크로드가 점점 쌓인 뒤 시스템이 어떻게 작동하는지 지켜보면서 얻은 결과입니다.
ZimaOS 삭제 및 Windows Server 2025 설치
Bob의 저장소에서 가장 눈에 띄는 실험은 ZimaOS를 제거하고 Windows Server 2025를 ZimaCube에 직접 설치하면서 시작되었습니다.
Bob은 이 조합이 어울리지 않는다고 설명했으며, 바로 그 점 때문에 시도했습니다. 이 프로젝트는 기본 제공 소프트웨어 환경에 의존하지 않고 하드웨어를 테스트하는 방법이 되었습니다. 설치 동작, 드라이버 탐색, 네트워킹, 스토리지, 그리고 소형 NAS 플랫폼을 범용 Windows 서버처럼 사용할 때도 여전히 의미가 있는지를 확인한 것입니다.
이 실험은 Zima 하드웨어 철학의 중요한 한 부분도 보여 줍니다. ZimaOS를 제거해도 장비의 유용한 수명이 끝나는 것은 아닙니다. x86 하드웨어는 다른 운영 체제를 중심으로 다시 구축할 수 있는 플랫폼으로 남아 있습니다.
이 실험을 보다 체계적인 ZimaCube에 Windows Server 2025 설정 가이드로 정리했습니다. 이 가이드에서는 설치 과정, Intel 네트워크 드라이버 작업, 그리고 같은 방향을 시도하려는 사용자를 위한 스토리지 구성을 다룹니다.
다음 단계로 넘어가기 전 ZimaOS 공정하게 테스트하기
Windows Server는 운영 체제 이야기의 일부일 뿐입니다. Bob은 Homelab Journal에 별도의 ZimaOS 리뷰도 작성했습니다.
그의 결론은 의도적으로 “좋다” 또는 “나쁘다”보다 더 미묘합니다. 저장소의 설명에 따르면 ZimaOS는 소형 장치에 잘 맞지만, ZimaCube를 가상화와 홈랩 인프라에 더 깊이 활용하려는 사용자에게 단순화된 경험이 원하는 수준에 부합하는지는 의문입니다.
이 비판이 유용한 이유는 Bob이 셀프 호스팅을 처음 시도하는 사람의 입장에서 ZimaOS를 평가하는 것이 아니기 때문입니다. 그는 이미 여러 시스템으로 구성된 홈랩을 운영하고 있으며 하위 계층을 직접 관리하는 데 익숙한 사람의 관점에서 평가하고 있습니다.
다른 사용자에게는 단순함이 계속 사용하게 되는 이유일 수 있습니다. 하지만 Bob에게는 인프라의 복잡성이 커지면서 결국 떠나게 된 이유가 되었습니다.
동일한 트레이드오프는 ZimaOS와 Proxmox, Windows Server 비교에서도 다뤄집니다. 이 글은 더 폭넓은 동일 실험에서 발전한 것입니다.
홈랩의 중심에 Proxmox 두기
다른 방향들을 시도한 끝에 Bob은 ZimaCube에 어떤 운영 체제를 설치하고 싶은지에 대해 훨씬 더 확고한 결론에 도달했습니다. 그의 홈랩에는 Proxmox가 가장 적합한 환경이었습니다.
이 글은 ZimaCube가 Synology의 NFS 스토리지와 함께 작동하며 3호스트로 구성된 시스템의 일부가 되는 과정을 설명합니다. 이 시점에서 이 장비는 더 이상 주로 NAS로 평가되지 않습니다. 인프라가 된 것입니다.
이러한 변화는 이후 여러 일지로 이어집니다. Proxmox가 다음 실험을 위한 기반을 제공하기 때문입니다. 백업 인프라, 모니터링, AI 서비스, 네트워크 가상화 등이 그 예입니다.
같은 기반을 구축하려는 사용자를 위해 ZimaCube + Proxmox 설정 가이드에서는 BIOS 준비부터 VM, LXC 컨테이너, 스토리지, 네트워킹, 패스스루까지의 과정을 다룹니다.
인프라를 중심으로 백업 구축하기
어떤 장비가 인프라가 되고 나면 다음 질문은 더 이상 그 장비가 서비스를 더 실행할 수 있는지가 아닙니다. 그 서비스 중 하나가 사라지면 어떻게 되는지가 중요합니다.
Bob의 백업 일지는 이러한 전환을 따라갑니다. Proxmox Backup Server가 등장하고, 보호 대상 시스템의 일부인 인프라를 사용해 인프라 자체를 백업한다는 난감하고 순환적인 문제도 함께 다룹니다.
그 결과는 하나의 완벽한 백업 대상을 찾는 것보다, 복구를 충분히 예측 가능하게 만들어 Bob이 백업을 끊임없이 고민하지 않아도 되는 계층을 구축하는 데 더 가깝습니다.
이 경험을 바탕으로 Proxmox Backup Server 가이드를 제작했습니다. 이 가이드에서는 증분 VM 및 컨테이너 백업, 보존, 검증, 추가 보호 계층으로 아이디어를 확장합니다.
끊임없이 확인하는 대신 플릿 지켜보기
홈랩이 몇 가지 서비스를 넘어 성장한 사람이라면 Bob의 다음 질문이 익숙할 것입니다. 한 사람이 실제로 얼마나 많은 모니터링을 필요로 할까요?
그의 플릿 지켜보기 글에서는 Pulse와 Proxmox Data Center Manager를 비롯한 도구를 살펴보지만, 더 중요한 목표는 인프라에 필요한 수동 관리를 줄이는 것입니다.
유용한 모니터링 시스템은 하루 종일 지켜봐야 하는 또 하나의 대시보드를 만들어서는 안 됩니다. 정상 작동은 조용히 유지하고, 실제로 주의가 필요할 때 장애를 눈에 띄게 알려야 합니다.
Bob의 경험에서 그 부분을 더 발전시킨 내용을 홈 서버 모니터링 가이드에서 다룹니다. Pulse, Uptime Kuma, Proxmox Data Center Manager와 함께 모니터링이 유지 관리 부담을 늘리는 대신 줄여야 하는 시점까지 설명합니다.
AI 에이전트에게 영구적인 보금자리 제공하기
이 기록은 결국 셀프 호스팅의 또 다른 영역, 즉 ZimaCube에서 지속형 AI 에이전트를 실행하는 단계로 나아갑니다.
Hermes Agent가 ZimaCube에 있어야 하는 이유에서 Bob은 이 시스템을 단순한 스토리지 또는 가상화 인프라가 아니라, 셀프 호스팅 에이전트가 상주할 수 있는 상시 가동 환경으로 바라봅니다.
이 조합은 지금까지의 모든 과정과 연결해 보면 자연스럽습니다. ZimaCube가 이미 연중무휴로 온라인 상태를 유지하고 홈랩에 연결되어 있으며 백업과 모니터링까지 이루어지고 있다면, 에이전트는 노트북 세션에 묶인 무언가가 아니라 또 하나의 지속형 서비스가 될 수 있습니다.
이 워크플로를 ZimaOS에서 직접 살펴보고 싶다면, 저희 ZimaOS용 Hermes Agent 설정 가이드에서 설치, 모델 구성, 메시징 통합, Hermes 대시보드 액세스 방법을 확인할 수 있습니다.
ZimaCube를 OPNsense 라우터로 전환하기
이후 진행된 가장 흥미로운 실험 중 하나는 시스템을 다시 완전히 다른 역할, 즉 네트워크 인프라로 전환합니다.
Bob의 OPNsense 기록에서는 Proxmox와 함께 ZimaCube의 듀얼 2.5GbE 인터페이스를 살펴보며, 라우터 VM이 지금까지 이 하드웨어를 활용하는 가장 설득력 있는 방법 중 하나일 수 있는지 질문합니다.
이때 앞서 내린 운영체제 선택이 효과를 발휘하기 시작합니다. Proxmox를 사용하면 동일한 물리적 시스템에서 기존에는 별도의 장비가 필요했던 워크로드를 호스팅할 수 있으며, 두 개의 이더넷 인터페이스는 가상화된 방화벽 설정에서 WAN과 LAN을 분리하는 자연스러운 방법을 제공합니다.
저희 Proxmox 가이드에서도 ZimaCube에서 OPNsense를 소프트웨어 라우터 VM으로 실행하는 방법을 다룹니다. 여기에는 별도의 2.5GbE 인터페이스를 네트워크 어플라이언스에 전달하는 아이디어도 포함됩니다.
가치는 최종 결론이 아니라 기록에 있습니다
전체적으로 보면 Bob의 프로젝트는 결론이 정해진 리뷰보다 훨씬 흥미롭습니다.
하나의 ZimaCube가 저장소의 전체 기간 동안 여러 가지 모습으로 등장합니다.
새 하드웨어로 시작합니다. Bob은 제품을 개봉하고, 제작 상태를 살펴보고, 섀시를 열어 냉각 성능을 검토한 뒤 업그레이드를 고민하기 시작합니다.
Windows Server 실험으로 이어집니다. ZimaOS를 제거하고, 기본으로 제공된 소프트웨어 없이도 기반 하드웨어가 여전히 유용한지 테스트합니다.
운영체제에 대한 질문으로 돌아갑니다. Bob은 ZimaOS를 직접 평가한 후, 점점 복잡해지는 환경에 다른 무언가가 필요하다고 판단합니다.
Proxmox 호스트가 됩니다. 그다음부터 이 장비는 더 큰 플릿에 합류하고 인프라 운영에 대한 책임을 점점 더 맡게 됩니다.
백업 및 모니터링 시스템의 일부가 됩니다. Proxmox Backup Server, Pulse, 플릿 관리가 목표를 “서비스를 계속 추가하기”에서 “더 이상 신경 쓰지 않아도 될 만큼 서비스를 안정적으로 운영하기”로 바꿉니다.
그러고 나면 AI 호스트이자 네트워크 어플라이언스가 됩니다. Hermes Agent와 OPNsense는 고립된 실험이 아닙니다. 앞선 인프라 계층이 이미 구축되어 있기 때문에 가능한 일입니다.
그 결과는 Bob이 처음 약속했던 바로 그것입니다. 공식 리뷰가 아니라, 기록과 실험, 경험에 따라 달라지는 의견, 그리고 점점 더 야심 차게 확장되는 하나의 홈랩 프로젝트입니다.
한 사용자의 이야기가 ZimaCube 가이드 모음으로 발전했습니다
Bob의 프로젝트는 장기적인 커뮤니티 테스트가 한 사람의 홈랩을 넘어선 가치를 지니는 이유도 보여 줍니다.
ZimaCube Experience Blog에 기록된 여러 실험은 이후 더 심층적인 Zima 리소스로 발전했습니다. Windows Server 설치, Proxmox 배포, 운영 체제 선택, 백업 아키텍처, 홈랩 모니터링이 그 예입니다.
이 과정은 커뮤니티 경험과 문서 사이에 유용한 순환을 만들어 냅니다. Bob은 호기심이 생겨 무언가를 시도합니다. 저널에는 그 결과가 기록됩니다. 유용한 내용은 다음 사람이 재현하기 더 쉬워집니다.
이야기는 아직 작성 중입니다
Bob Loves Tech와 Zima의 이야기는 아직 작성 중입니다. 그의 ZimaCube Experience Blog는 이미 제품 개봉과 하드웨어 분해부터 ZimaOS, Windows Server, Proxmox, 백업, 플릿 모니터링, Hermes Agent, OPNsense까지 다루었으며, 계속 이어지는 기록의 핵심은 최종 구성이 꼭 필요하지 않다는 점입니다.
홈랩이 변화함에 따라 ZimaCube의 역할도 함께 달라질 수 있습니다. Bob이 다음에 무엇을 실험할지 보고 싶다면 GitHub에서 계속 업데이트되는 ZimaCube Experience Blog를 팔로우하세요.
