Sbinske와 ZimaOS: 레트로 LAN 파티 서버 구축

sbinske를 만나 보세요

sbinske는 자신을 비전문 기술 사용자이자 DIY 취미 사용자라고 설명합니다. 이 구분은 이 이야기에서 중요합니다. 그는 다른 플랫폼을 벤치마킹하려는 시스템 관리자로서 ZimaOS에 접근한 것이 아니었습니다. 무언가를 만들고, 하드웨어를 재활용하며, 모든 프로젝트를 엔터프라이즈 인프라로 만들지 않고 실용적인 결과를 얻는 것을 즐기는 사람으로서 접근했습니다.

ZimaOS를 선택하기 전, 그는 Unraid의 대안을 오랫동안 찾아다녔습니다. 그가 매력을 느낀 부분은 기능을 하나씩 맞춰 놓은 동등성이 아니었습니다. 오히려 그가 마음에 들어 한 점 중 하나는 ZimaOS가 더 가볍게 느껴졌고 Unraid만큼 방대한 기능을 제공하려 하지 않았다는 것입니다.

2026년 2월에 진행한 그의 프로젝트는 이 아이디어를 매우 구체적으로 시험하는 계기가 되었습니다. 비교적 가벼운 홈 서버 OS가 복고풍 LAN 파티에 필요한 컨테이너, 가상 머신, 네트워킹, 스토리지의 조합을 실행할 수 있을까요?

복고풍 LAN 파티가 테스트 사례가 되다

이 서버는 인프라를 로컬에서 운영하며 여러 외부 서비스 스택에 의존하지 않고 행사를 지원해야 하는, 전통적인 LAN 파티를 위해 준비되고 있었습니다.

그가 이 구성을 기록할 무렵, ZimaOS에서는 이미 두 개의 Docker 컨테이너가 실행 중이었습니다. TeamSpeak 서버와 DNS 서버였습니다. 이와 함께 세 개의 가상 머신도 있었습니다. ETI-SyncServer, LanPage VM, 그리고 행사와 관련된 나머지 서비스를 구성하기 위한 또 다른 VM이었습니다.

이러한 작업 환경 덕분에 이 프로젝트는 단순한 NAS 테스트보다 흥미로웠습니다. 스토리지는 그중 한 부분에 불과했습니다. 시스템은 네트워크 서비스를 호스팅하는 동시에 여러 개의 격리된 가상 머신도 실행해야 했습니다.

ZimaOS가 가벼운 Unraid 대안으로 작동한 이유

sbinske의 Unraid 비교는 의도적으로 실용적이었습니다. 그는 ZimaOS가 Unraid의 모든 기능을 재현할 것이라고 기대하지 않았습니다. 자신에게 실제로 필요한 기능을 제공하면서도 취미 사용자가 충분히 이해하고 다룰 수 있는 더 작은 시스템을 원했습니다.

하드웨어 문제가 해결된 후 그의 전반적인 경험은 긍정적이었습니다. 시스템은 안정적인 상태를 유지했고, 그가 이를 중심으로 구축한 LAN 파티 작업도 원활하게 처리했습니다.

현재 ZimaOS 문서에서도 가상 머신은 여전히 발전 중인 플랫폼 기능으로 설명하고 있으며, 전체 시스템은 스토리지, Docker 애플리케이션, 가상화를 하나의 인터페이스로 통합합니다. 따라서 sbinske의 프로젝트는 각 기능을 별도의 데모로 다루기보다 이러한 요소를 함께 활용한 좋은 사례입니다.

첫 번째 주요 문제는 ZimaOS가 멈춘 것처럼 보였습니다

빌드는 순조롭게 시작되지 않았습니다. sbinske는 ZimaOS가 약 20분 작동한 후 완전히 멈춘다고 보고했습니다.

로그를 확인하고 구성 요소를 테스트한 후, 그는 첫 번째 문제의 원인이 오래된 NVIDIA GeForce GT 710이라고 추적했습니다. 터미널을 통해 드라이버를 수동으로 설치하려 했지만 문제가 해결되지는 않았습니다. 또한 가상 드라이브와 관련된 변경 사항도 시도했지만 성공하지 못했습니다.

결국 그는 그래픽 카드를 제거하고 시스템을 초기화한 뒤, 그래픽 카드 없이 ZimaOS를 다시 설치했습니다. 새로 설치한 시스템은 다시 정상적으로 작동했습니다.

이는 모든 GT 710이 모든 ZimaOS 빌드와 호환되지 않는다는 일반적인 주장이 아니라, 그의 특정 시스템에서 크리에이터가 보고한 호환성 문제로 봐야 합니다. 원문은 이 구성에서 발생한 일을 기록한 것이며, 보편적인 드라이버 규칙을 확립하는 것은 아닙니다.

GPU를 다시 장착하자 더 복잡한 하드웨어 문제가 드러났습니다

sbinske가 그래픽 카드를 다시 장착하자 동작이 달라졌습니다. 단순히 그래픽 드라이버 문제로 보이는 현상만 나타나는 대신, 시스템이 하드 드라이브와 네트워크 카드를 반복적으로 연결 해제했다가 다시 인식하기 시작했습니다.

로그에는 오류가 표시되었지만, 그는 이를 특정 네트워크 어댑터 하나나 그래픽 카드만의 문제라고 확신할 수 없었습니다. 그래서 문제 해결 방식을 바꿨습니다. 하드웨어를 한 번에 한 부품씩 제거하고, 시스템이 더 이상 오류를 일으키지 않는 지점을 확인했습니다.

이 과정을 통해 전체 디버깅 세션에서 가장 명확한 결과를 얻었습니다. 시스템은 추가 네트워크 카드 3개와 메인보드의 온보드 네트워크 인터페이스를 함께 사용하면 불안정했습니다. 추가 네트워크 카드 2개만 사용하면 시스템은 원활하게 작동했습니다.

PCIe 레인 할당을 의심했지만 입증하지는 못했습니다

호스트는 서버 전용으로 설계된 하드웨어가 아니었습니다. AMD Ryzen 5 2600, MSI B450 Plus 메인보드, 64GB RAM을 사용했으며, 본질적으로 프로젝트에 사용할 수 있었던 여분의 하드웨어였습니다.

sbinske는 메인보드, CPU, 그래픽 카드 및 여러 네트워크 어댑터의 조합에서 PCIe 레인 또는 리소스 할당 문제가 발생했을 수 있다고 추측했다. 그러나 추가 네트워크 카드 두 장만으로도 컴퓨터가 이미 자신의 요구를 충족했기 때문에 그 이론을 입증할 만큼 조사를 계속하지는 않았다.

이 경계는 중요하다. 성공적인 문제 해결 결과는 알려져 있다. 확장 카드 조합을 줄이자 시스템이 안정되었다. 정확한 전기적, 펌웨어 또는 레인 할당상의 근본 원인은 제작자가 제시한 가설일 뿐이며, 확인된 ZimaOS 결함은 아니다.

하드웨어가 안정된 후 서버는 계속 안정적으로 작동했다

네트워크 카드 수를 줄이고 문제가 된 하드웨어 조합을 제거한 후, sbinske는 시스템이 안정적으로 실행되었다고 보고했다.

이로 인해 그는 프로젝트를 바라보는 관점이 달라졌다. 초기의 멈춤 현상 때문에 설치가 불안정해 보였지만, 이후의 동작은 운영 체제와 재사용된 데스크톱 부품의 이례적인 조합 사이에 더 복잡한 상호 작용이 있음을 시사했다.

DIY 빌드에서는 완벽한 근본 원인을 찾아내는 것보다 그 차이가 더 중요했다. 그는 LAN 파티 서비스를 계속 실행할 수 있는 구성에 도달했으며, 계획했던 역할에는 네트워크 카드 두 장이면 이미 충분했다.

ZimaOS가 Unraid보다 덜 친화적으로 느껴졌던 곳은 App Store였다

sbinske의 설문에서 가장 강하게 드러난 사용성 비판은 타사 Docker 컨테이너를 위한 App Store 경험이었다.

그가 기준으로 삼은 것은 Unraid였다. App Store를 설치하고, 컨테이너를 검색한 뒤, 명확한 설명과 설정 양식에 따라 설치하는 방식이다. 그는 ZimaOS도 같은 결과에 도달할 수 있다고 보았지만, 익숙하지 않은 컨테이너나 타사 컨테이너를 추가하려면 비전문가와 취미 사용자에게 너무 많은 지식이 필요하다고 느꼈다.

이 피드백은 2026년 2월에 기록되었다. 현재 ZimaOS 문서에 따르면 사용자는 임의의 Docker Compose YAML을 가져오고, 구성을 직접 편집하며, 여러 컨테이너로 구성된 스택을 실행하고, 커뮤니티가 유지 관리하는 타사 스토어를 사용할 수 있다. 개발자 문서에는 현재 App Store 패키징 작업 흐름도 훨씬 자세히 설명되어 있다.

이러한 최신 기능이 그의 원래 경험을 지워 주는 것은 아니다. 다만 유용한 맥락을 제공한다. 그가 지나치게 복잡하다고 느꼈던 작업 흐름은 ZimaOS가 이후 2026년에 계속 확장해 나간 바로 그 영역이었다.

스토리지 유연성 역시 부족했던 부분이었다

sbinske는 또한 여러 디스크를 서로 다른 작업 부하에 맞춰 여러 스토리지 그룹으로 나눌 수 있는 더 많은 자유를 원했다.

그의 예시는 실용적이었다. 한 쌍의 디스크는 중복성보다 용량과 속도가 중요할 때 RAID 0으로 사용하고, 다른 한 쌍은 미러링이 필요한 데이터에 RAID 1로 사용할 수 있었다. 특히 그의 SyncServer 작업에는 4TB를 초과하는 공간이 필요했지만, 더 중요한 스토리지와 동일한 수준의 데이터 보호는 필요하지 않았다.

그의 관점에서는 기존의 더 저렴한 디스크를 워크로드별 어레이로 결합할 수 있다면 하드웨어 비용을 낮추고 이미 보유한 드라이브를 더 효율적으로 활용할 수 있습니다.

현재 ZimaOS 문서에는 RAID 0, RAID 1, RAID 5, RAID 6, JBOD 및 ZFS가 안내되어 있습니다. 그러나 이 사례를 위해 검토한 공개 문서에서는 sbinske가 요청한 정확한 다중 어레이 워크플로, 예를 들어 일반 UI를 통해 동일한 호스트에서 디스크 두 개로 RAID 0을 독립적으로 만들고 별도로 디스크 두 개로 RAID 1을 만드는 방법을 명시적으로 확인하지 않습니다. 따라서 이 페이지에서는 해당 요청이 완전히 해결되었다고 주장하지 않고 그대로 보존합니다.

비전문가 사용자가 정의한 성공

이 프로젝트가 유용한 이유는 sbinske가 시스템이 얼마나 많은 고급 기능을 제공하는지로 평가하지 않았기 때문입니다. 그는 실제로 실행하고 싶었던 서비스를 지원할 수 있는지를 기준으로 평가했습니다.

하드웨어 문제를 해결한 뒤의 답은 대체로 그렇다는 것이었습니다. ZimaOS는 Unraid보다 가벼웠지만, LAN 파티 서버에 Unraid의 모든 기능이 필요하지 않았기 때문에 괜찮았습니다. Docker 컨테이너 두 개, 가상 머신 세 개, 로컬 DNS, 음성 통신, 동기화 및 이벤트 관리 서비스만으로도 서버는 충분히 유용했습니다.

그의 비판도 같은 실용적인 관점에서 나왔습니다. 서드파티 Docker 설치를 더 쉽게 만들면 학습 곡선을 낮출 수 있습니다. 디스크 그룹을 더 유연하게 구성할 수 있다면 하드웨어 비용을 줄일 수 있습니다. 특이한 데스크톱 확장 카드 조합과의 호환성이 개선되면 남는 하드웨어를 활용한 프로젝트를 더 예측 가능하게 만들 수 있습니다.

이야기는 아직 진행 중입니다

sbinske와 Zima의 이야기는 아직 진행 중입니다. 그의 현재 프로젝트는 레트로 LAN 파티를 위한 가벼운 Unraid 대안으로 시작했으며, 혼합된 Docker 및 VM 워크로드에서 재사용 데스크톱 하드웨어로 ZimaOS가 어떻게 작동하는지 검증하는 실제 테스트가 되었습니다.

최종 결과가 처음부터 완벽하게 깔끔한 설치였던 것은 아닙니다. GT 710을 제거하고, 확장 카드 조합을 줄이고, 실제로 필요했던 두 개의 NIC만 유지한 뒤, 시스템이 안정적으로 유지되자 계속 진행하는 방식으로 부품 단위 문제 해결을 거쳐 작동하는 DIY 시스템에 도달했습니다.

자신을 전문가가 아닌 취미 사용자라고 명확히 설명한 사람에게는, 프로젝트의 가장 유용한 결과였을 수 있습니다. 시스템이 모든 기술적 세부 정보를 그에게 숨긴 것은 아니지만, 하드웨어 조합을 단순화하자 그가 찾던 더 가벼운 홈 서버 환경을 제공했습니다.

현재 플랫폼 관련 내용은 ZimaOS 기능 개요와 현재 RAID 구성 참조를 확인하세요.