Zima의 메시지
MorgothTheBauglir님, 확장을 고정된 한계가 아닌 설계 도구로 활용할 때 컴팩트한 홈 서버 플랫폼이 얼마나 멀리 나아갈 수 있는지 보여 주셔서 감사합니다. DIY NAS에서 ZimaOS를 발견한 것부터 ZimaBoard 2를 350TB를 넘어선 스토리지 시스템의 제어 지점으로 활용하기까지, 여러분의 작업은 셀프 호스팅 커뮤니티를 가치 있게 만드는 실습 중심의 실험 정신을 잘 보여 줍니다.
우리는 최종 용량 수치 이상의 내용을 공유해 주신 점을 특히 높이 평가합니다. 빌드를 문서화하고, 하드웨어 선택과 절충점을 설명했으며, 다른 홈랩 사용자들의 질문에 답하고, 시스템이 계속 확장되면서 결국 새로운 성능 한계에 도달하는 과정도 솔직하게 전해 주셨습니다. 이러한 개방성은 다른 빌더들에게 단순한 쇼케이스보다 더 유용한 것을 제공합니다. 직접 살펴보고, 질문하고, 배울 수 있는 실제 프로젝트입니다.
— Zima
MorgothTheBauglir를 만나보세요
MorgothTheBauglir는 ZimaSpace의 이전 350TB 사례 연구에서 Igor로 소개된 빌더의 Reddit 계정입니다. 해당 프로필에서는 그를 컴퓨터, 서버 아키텍처, 데이터 관리에 오랫동안 관심을 가져온 브라질 출신 네트워크 엔지니어로 소개했습니다. 그의 홈랩 작업은 같은 원칙을 따릅니다. 설치 공간은 관리 가능한 수준으로 유지하고, 적절한 경우 실용적인 하드웨어를 재사용하며, 계속 실험할 수 있도록 충분한 여지를 남겨두는 것입니다.
그의 Zima 이야기는 DIY NAS에서 ZimaOS를 발견한 것에서 시작해, ZimaBoard 2를 350TB를 넘어 성장한 스토리지 빌드의 제어 지점으로 활용하는 과정으로 이어졌습니다. Reddit에서의 공개 활동에서도 스토리지, HBA, 가상화, 네트워킹, 셀프 호스팅, ZimaOS에 관한 논의를 통해 이러한 실습 중심의 접근 방식을 이어가고 있습니다. Reddit에서 MorgothTheBauglir를 팔로우하면 이 페이지 이후에도 계속되는 프로젝트와 대화를 확인할 수 있습니다.
ZimaOS에서 전용 ZimaBoard 2로
ZimaBoard 2로 향하는 여정은 소프트웨어에서 시작되었습니다. ZimaSpace의 초기 사례 연구에 따르면, Igor는 NAS Compares를 통해 처음 ZimaOS를 접했고 DIY NAS에 설치했습니다. 인상적이었던 것은 하나의 기능이 아니라, 세련된 인터페이스와 가벼운 작동 방식, 그리고 기본 하드웨어를 감추지 않으면서도 쉽게 접근할 수 있었던 셀프 호스팅 워크플로의 조합이었습니다.
IceWhale 커뮤니티에 참여한 후, 그는 한 이벤트에서 ZimaBoard 2 832를 받았고 얼마 지나지 않아 더 높은 사양의 ZimaBoard 2 1664로 업그레이드했습니다. 이를 통해 다음 스토리지 실험에서는 이전에 사용하던 일반 미니 PC로는 동일한 컴팩트한 형태에서 구현할 수 없었던 기능을 얻었습니다. 훨씬 더 큰 시스템의 출발점으로 활용할 수 있는 직접적인 PCIe 확장 경로였습니다.
하나의 PCIe 확장 경로를 350TB 이상으로 확장하기
이 빌드를 특별하게 만든 프로젝트는 80TB NAS로 시작해 계속 확장되었습니다. 2026년 1월까지 MorgothTheBauglir는 10인치 미니 랙 안에서 ZimaBoard 2를 중심으로 시스템을 재구성했고, 혼합 스토리지 풀을 350TB 이상으로 늘렸습니다.
핵심 하드웨어 구성은 ZimaBoard 2에 IBM M1210 HBA와 Adaptec AEC-82885T SAS 익스팬더를 결합한 것이었습니다. 여기에 HDD와 SSD를 혼합해 사용하고, 전용 전원 분배 장치, 알루미늄 프로파일, 방대한 케이블, 냉각 장치, 3D 프린팅 마운트를 더했습니다. 그 결과는 시판 NAS라기보다 사용 가능한 부품, 용량, 공간에 맞춰 설계한 컴팩트한 스토리지 섀시에 가까웠습니다.
ZimaSpace는 350TB+ ZimaBoard 2 스토리지 사례 연구에서 아키텍처, 소프트웨어 스택, 확장 결정을 정리했습니다. 원본 Reddit 빌드 로그에는 공기 흐름 문제, 드라이브 캐디, 3D 프린팅 부품, 케이블 배선, 전원 분배, 고밀도 랙을 실용적으로 구현하는 데 필요한 소소한 개조 작업 등 작업 현장 수준의 세부 정보가 추가로 담겨 있습니다.
확장은 설계를 위한 도구였다
이 빌드에서 중요한 ZimaBoard 2의 기능은 단순히 더 많은 스토리지를 연결할 수 있다는 점이 아니었습니다. PCIe 슬롯에 실제 HBA를 직접 장착할 수 있다는 점이 핵심이었습니다. 덕분에 호스트 자체를 대형 범용 서버로 만들지 않고도 시스템을 컴팩트한 보드에서 SAS 확장 토폴로지로 전환할 수 있었습니다.
MorgothTheBauglir는 그 차이를 간단히 설명했습니다. 직접 HBA를 지원하면 컴팩트하면서도 고밀도인 NAS를 설계하는 방식이 달라집니다. 보드는 작은 크기를 유지하면서 주변 스토리지 패브릭은 훨씬 더 커질 수 있었습니다.
냉각, 전력, 공간도 스토리지 문제의 일부였습니다
용량만이 유일한 제약은 아니었습니다. 따뜻한 기후, 엔터프라이즈 드라이브, 제한된 가정 내 공간, 밀집된 10인치 랙 때문에 공기 흐름과 전력 분배를 데이터 경로와 함께 설계해야 했습니다. 팬, 드라이브 마운트, PSU 배치, 케이블 경로가 모두 동일한 물리적 레이아웃에 맞아야 했습니다.
이 때문에 이 빌드는 제시된 용량을 넘어선 유용성을 가집니다. 매우 큰 홈 스토리지는 단순히 디스크를 더 연결하는 문제인 경우가 드물며, 기계적 배치, 발열, 전력, 케이블 연결, 유지보수성이 모두 아키텍처의 일부가 된다는 점을 보여줍니다.
제약 조건을 중심으로 소프트웨어 선택하기
스토리지 소프트웨어에도 동일한 제약 우선 논리가 적용되었습니다. 메모리를 많이 사용하는 ZFS 토폴로지를 중심으로 전체 풀을 구축하는 대신, 가상화 계층으로 Proxmox VE를 사용하고, 스토리지 관리 워크로드에는 가벼운 Windows IoT 가상 머신을 사용했으며, 서로 다른 드라이브 간 유연한 풀링과 폴더 중복을 위해 StableBit DrivePool을 사용했습니다.
ZimaSpace 사례 연구에서 그가 제시한 요약은 의도적으로 간단했습니다. "모든 사람에게 RAID가 필요한 것은 아닙니다." 핵심은 특정 스토리지 설계가 보편적으로 더 낫다는 것이 아니었습니다. 가장 복잡한 옵션이라는 이유만으로 선택하기보다, 소프트웨어 스택이 실제 하드웨어와 복구 모델, 워크로드에 맞아야 한다는 의미였습니다.
결과만이 아닌 빌드 과정 공유
공개 빌드 로그는 이 이야기에서 중요한 부분입니다. MorgothTheBauglir는 완성된 랙 사진만 게시한 것이 아니라 주요 구성 요소를 나열하고, 3D 프린트 모델 링크를 공유하고, 조립 과정의 문제를 설명하며, 부품과 어려움에 관한 질문을 받았습니다. 이어진 토론에서는 전력 소비량, 네트워크 속도, 스토리지 사용 방식, 알루미늄 프로파일, 드라이브 마운트, 향후 업그레이드에 관한 질문에도 답변했습니다.
그의 폭넓은 셀프 호스팅 관련 논의에서도 같은 실용적인 분위기를 확인할 수 있습니다. 그는 Reddit 프로필에서 SATA 확장을 위해 HBA를 IT 모드로 사용하는 방식을 추천했으며, 이후 마이그레이션 논의에서는 사용 편의성을 중시할 때는 ZimaOS를 선택하고, 스냅샷·롤백·간편한 마이그레이션이 우선순위라면 Proxmox 가상화를 고려하라고 설명했습니다.
한계가 드러날 때까지 빌드를 확장하다
이야기는 350TB에서 멈추지 않았습니다. 시스템이 450TB를 넘어 성장하면서 MorgothTheBauglir는 지속적인 CPU 부하와 인터럽트와 함께 네트워크 전송 속도가 느려졌다고 보고했습니다. ZimaBoard 2 구성은 350TB 단계에서는 제대로 작동했지만, 더 큰 워크로드로 인해 다음 병목이 드러났습니다.
그는 이를 실패로 받아들이는 대신 아키텍처를 변경했습니다. 기본 스토리지 컴퓨팅은 더 많은 메모리, 더 빠른 PCIe 연결, 10GbE를 갖춘 고성능 호스트로 옮겼고, 랙과 확장 작업도 계속 발전했습니다. 그의 Reddit 450TB 업데이트는 성공적인 소형 설계가 마침내 다른 등급의 호스트를 정당화할 만큼 커진 시점을 기록하고 있어 유용한 후속 자료입니다.
이러한 발전 과정은 무제한 용량을 내세우는 주장보다 더 유용한 교훈을 줍니다. ZimaBoard 2는 이례적으로 집약적인 홈 스토리지 실험을 가능하게 했고, 그 실험을 통해 플랫폼이 적합한 지점과 워크로드가 플랫폼의 한계를 넘어선 지점에 대한 실제 정보가 나왔습니다.
변하지 않은 것
하드웨어가 바뀌는 동안에도 같은 엔지니어링 원칙은 계속 드러납니다. 현재 문제를 해결하는 확장 경로를 사용하고, 실질적인 이점을 주지 않는 복잡성은 피하며, 기계적 설계를 시스템 아키텍처의 일부로 만들고, 다른 사람이 그 결과에서 배울 수 있을 만큼 충분한 세부 정보를 공유하는 것입니다.
그렇기 때문에 이 사용자 스토리와 기술 사례 연구의 관계가 중요합니다. 350TB 글은 아키텍처를 설명하고, 이 페이지는 그 뒤에 있는 제작자와 그 단계에 이르게 한 결정, 그리고 프로젝트가 계속 커졌을 때 일어난 일을 기록합니다.
이야기는 아직도 계속 쓰이고 있습니다
MorgothTheBauglir와 Zima의 이야기는 아직도 계속 쓰이고 있습니다. 이 프로젝트는 이미 소규모 DIY NAS에서 350TB 이상의 ZimaBoard 2 시스템으로 발전했고, 이후 450TB를 넘어서는 새로운 단계에 들어섰습니다. 새로운 제약이 나타날 때마다 랙, 스토리지 풀, 소프트웨어 선택도 계속 바뀌고 있습니다.
ZimaBoard 2 단계의 기술적 구성을 자세히 알고 싶다면 전체 350TB ZimaBoard 2 사례 연구를 읽어 보세요. 그가 다음에 무엇을 만들고, 테스트하고, 추천하는지 확인하려면 Reddit에서 MorgothTheBauglir를 팔로우하세요.
