[Infra] OMV는 잊어라! 13년 차 엔지니어가 제안하는 Proxmox LXC + ZFS + Docker 초경량 홈랩 아키텍처

들어가며: 2026년 홈랩 트렌드, "군더더기를 걷어내라"

안녕하세요, 13년 차 시스템 엔지니어입니다.

최근 국내외 IT 커뮤니티와 홈랩(Home Lab) 구축기들을 살펴보면 하나의 거대한 흐름이 감지됩니다. 과거에는 Proxmox 위에 파일 공유를 위해 무거운 TrueNAS나 OMV(OpenMediaVault)를 가상머신(VM)으로 올리고, 디스크를 패스스루(Passthrough)하는 복잡한 방식이 유행했습니다. 하지만 2026년 현재, 숙련된 엔지니어들은 이 방식을 '불필요한 리소스 낭비(Overhead)'로 규정하고 있습니다.

4남매를 모두 재우고 고요한 밤에 제 홈랩 서버를 만지다 보면, 인프라는 결국 단순할수록(Simple is Best) 장애 포인트가 줄어든다는 진리를 다시금 깨닫습니다. 그래서 저는 무거운 NAS OS를 과감히 걷어냈습니다. 오늘은 Proxmox의 강력한 네이티브 기능인 ZFS와 가벼운 LXC(Linux Container) 기반의 Docker를 조합하여, 시스템 자원을 100% 극한으로 활용하는 최신 홈랩 스토리지 아키텍처를 소개합니다.

1. 헤비한 NAS OS(OMV, TrueNAS)를 버려야 하는 기술적 이유

홈랩에 입문하는 많은 분이 가상화 서버를 세팅할 때 으레 OMV 같은 NAS 전용 운영체제를 가상머신(VM)으로 올립니다. 하지만 시스템 엔지니어 관점에서 이는 구조적인 모순을 안고 있습니다.

• 이중 가상화의 비효율성: Proxmox는 데비안(Debian) 리눅스 기반이며, 그 자체로 세계 최고 수준의 파일 시스템인 ZFS를 네이티브로 완벽하게 지원합니다. 이미 호스트 OS에서 훌륭하게 스토리지를 관리할 수 있는데, 굳이 막대한 RAM과 CPU 코어를 할당해 가며 또 다른 OS를 띄울 필요가 있을까요?
• 디스크 패스스루의 복잡성: 가상머신에 설치된 NAS OS가 물리 디스크를 직접 제어하게 하려면 HBA 카드나 디스크 패스스루를 설정해야 합니다. 이는 향후 디스크 마이그레이션이나 백업 시 심각한 I/O 병목과 유지보수 장애를 유발합니다.
• 보안 및 업데이트 포인트 증가: OS가 늘어난다는 것은 곧 보안 패치를 적용해야 할 타겟이 늘어난다는 뜻입니다. 인프라 운영자에게 관리 포인트의 증가는 곧 퇴근 시간의 연장을 의미합니다.

2. 대세는 LXC(Linux Container): VM을 대체하는 가벼움

그렇다면 OMV 없이 어떻게 파일 서버와 각종 서비스(Nextcloud, Plex 등)를 띄울까요? 정답은 가상머신(VM)이 아닌 LXC입니다.

• 커널 공유의 마법: LXC는 호스트(Proxmox)의 리눅스 커널을 그대로 공유합니다. 가상머신처럼 별도의 하드웨어를 에뮬레이션하지 않기 때문에 CPU와 RAM 오버헤드가 사실상 '제로(0)'에 가깝습니다.
• Unprivileged(비특권) 컨테이너의 보안: 최신 Proxmox 버전에서는 비특권 컨테이너 생성이 기본값입니다. 이는 LXC 내부에서 루트(Root) 권한이 탈취되더라도 호스트 시스템에는 영향을 주지 못하도록 완벽하게 격리하는 안전한 샌드박스 환경을 제공합니다.
• 초고속 부팅: 가상머신이 부팅되는 데 3060초가 걸린다면, LXC 컨테이너는 단 **12초**면 서비스가 구동됩니다. 엔지니어에게 이 즉각적인 응답성은 엄청난 쾌감입니다.

3. 핵심 아키텍처: LXC 내부에 Docker 구축 및 ZFS 마운트

이제 인프라를 결합할 차례입니다. 파일 공유 서비스(SMB/NFS)조차 무거운 OS가 아닌 가벼운 Docker 컨테이너로 띄우는 것이 핵심입니다.

Step 1: ZFS 풀(Pool) 생성 및 ARC 최적화

Proxmox 호스트 자체에서 ZFS 풀을 생성합니다. 13년 차 엔지니어의 팁을 드리자면, 여기서 가장 중요한 것은 ZFS의 캐시 메모리인 ARC(Adaptive Replacement Cache) 관리입니다. 과거 Proxmox 8.0 이전에는 ARC가 호스트 RAM의 50%까지 잡아먹어 수동 제한이 필수였지만, 최신 Proxmox 8.1 이상부터는 기본값이 RAM의 10%(최대 16GB)로 안전하게 설정되어 나옵니다. 만약 구버전에서 업그레이드했거나 램이 아주 넉넉하다면 /etc/modprobe.d/zfs.conf를 튜닝해 내 환경에 딱 맞는 캐시 구간을 설정해 주는 것이 중요합니다.

Step 2: LXC 컨테이너에 ZFS 데이터셋 바인드 마운트(Bind Mount)

가장 중요한 기술적 포인트입니다. Proxmox 호스트의 ZFS 스토리지 경로를 LXC 컨테이너 내부의 특정 폴더로 직접 매핑(Bind Mount)합니다. 네트워크나 가상 디스크 드라이버를 거치지 않으므로 I/O 속도 저하 없이 네이티브에 준하는 스토리지 성능을 뽑아낼 수 있습니다.

Step 3: LXC 내부에 Docker 및 Samba 컨테이너 구동

Debian이나 Ubuntu 템플릿으로 만든 LXC 내부에 Docker를 설치합니다. 그리고 파일 공유를 위한 Samba(SMB) 서비스를 docker-compose.yml 파일로 선언하여 띄웁니다. 이렇게 하면 파일 서버의 설정마저 코드로 관리(Infrastructure as Code)할 수 있어, 훗날 서버가 날아가더라도 5분 만에 완벽하게 복구할 수 있습니다.

요약 및 결론: 인프라의 여백은 '다른 가능성'을 만든다

1. 군더더기 제거: 파일 서버 구축을 위해 무거운 OMV나 TrueNAS를 가상머신으로 띄우는 것은 2026년 기준 비효율적인 레거시(Legacy) 방식입니다.
2. 기술의 결합: Proxmox의 네이티브 ZFS 스토리지 기능을 호스트에서 직접 활용하고, 이를 가벼운 LXC 컨테이너와 Bind Mount로 연결하는 것이 대세입니다.
3. Docker의 유연성: 파일 공유(SMB)부터 각종 자동화 툴까지 모든 것을 LXC 내부의 Docker 컨테이너로 돌림으로써, 리소스 오버헤드를 없애고 완벽한 코드 기반 관리를 이뤄냅니다.

13년 차 시스템 엔지니어로서 제가 굳이 이 'LXC + Docker + ZFS' 아키텍처를 고집하는 이유는 단순합니다. 가상화에 낭비되던 소중한 CPU 코어와 8GB 이상의 RAM을 절약하면, 그 남는 자원으로 나만의 로컬 AI 모델(Local LLM)을 하나 더 띄우거나 가족들을 위한 게이밍 서버를 쾌적하게 돌릴 수 있기 때문입니다. 여러분의 홈랩은 지금 불필요한 가상화의 무게에 짓눌려 있진 않으신가요?

---