Proxmox TrueNAS SCALE ZFS 비교: 홈랩 스토리지 선택 가이드

Proxmox TrueNAS SCALE ZFS 비교를 찾다 보면 결국 부딪히는 건 기능표보다 장애를 어떻게 감당할지입니다. 저도 홈랩 NAS를 몇 번 갈아엎고 나서야 이걸 제대로 봤습니다. 둘 다 ZFS를 쓴다는 사실보다, 문제가 났을 때 어느 계층을 먼저 의심해야 하는 구조인가가 훨씬 중요하더라고요.

같은 디스크, 같은 HBA, 같은 ZFS라도 Proxmox VE는 VM과 LXC가 주인공인 설계에 가깝고, TrueNAS SCALE은 데이터셋과 공유 정책이 중심입니다. 참고로 TrueNAS SCALE은 2025년 25.04 계열부터 커뮤니티 에디션 명칭이 함께 쓰이지만, 검색과 실사용 맥락에선 여전히 TrueNAS SCALE이라는 표현이 널리 남아 있습니다. 그래서 둘 중 무엇이 더 낫냐고 묻기보다, 내 홈랩에서 가장 먼저 살아 있어야 하는 것이 VM인지 데이터인지부터 정하는 쪽이 훨씬 정확합니다.

운영 피로도도 빼놓기 어렵습니다. 한 대 서버에 VM, LXC, SMB, NFS, iSCSI, 백업 저장소까지 전부 몰아넣으면 평소엔 편해 보여도 디스크 이슈가 한 번 터졌을 때 복구 동선이 길어집니다. 저도 초기에 부팅 풀과 VM 스토리지, 백업 파일을 너무 가깝게 붙여놨다가 유지보수 창에서 손이 괜히 빨라지는 경험을 했거든요. 홈랩은 성능 숫자보다도 구조를 단순하게 유지하는 능력이 오래 갑니다.

Proxmox VE와 TrueNAS SCALE이 각각 어떤 위치에서 가장 빛나는지 한눈에 보여주는 홈랩 구성 예시입니다.

왜 Proxmox TrueNAS SCALE ZFS 비교가 자주 나올까요?

겉으로 보면 둘 다 웹 UI가 있고, 둘 다 ZFS를 쓰고, 둘 다 스냅샷을 말합니다. 그런데 실제 운영 동선은 꽤 다릅니다. Proxmox VE는 저장소를 게스트 워크로드를 올려두는 기반으로 보고, TrueNAS SCALE은 저장소를 권한, 공유, 스냅샷, 복제 정책을 설계하는 대상으로 다룹니다.

이 차이는 같은 작업을 할 때도 바로 드러납니다. Proxmox VE에선 "이 VM 디스크를 어디 둘까"가 먼저고, TrueNAS SCALE에선 "이 데이터셋을 누구에게 어떤 프로토콜로 공개할까"가 먼저입니다. 둘 다 ZFS 위에서 돌아가지만, 관리 UI가 사용자를 유도하는 방향이 달라서 실제 사용감도 꽤 다릅니다.

제가 보기엔 이 비교에서 가장 많이 놓치는 포인트가 하나 있습니다. ZFS를 잘 쓰는 것과 ZFS를 얹은 제품을 잘 운영하는 것은 다른 문제라는 점입니다. 전자는 풀 상태와 데이터셋 구조, 스냅샷 정책의 문제이고, 후자는 장애 범위와 복구 순서, 권한 모델, 서비스 의존성의 문제입니다.

핵심 개념: ZFS 기반 홈랩 스토리지를 어떻게 봐야 하나

1. Proxmox VE는 "VM이 주인공"인 구조

Proxmox VE에서 ZFS는 보통 VM 디스크, 컨테이너 루트 파일시스템, 스냅샷, 복제, 백업 작업의 기반으로 쓰입니다. 즉 스토리지 관리의 중심이 파일 공유가 아니라 게스트 워크로드의 수명주기에 붙어 있습니다. Kubernetes 테스트 노드, 방화벽 VM, DB 실험 환경, Git 러너, 내부 서비스처럼 VM과 LXC가 자주 생겼다 지워지는 환경이라면 이 흐름이 정말 자연스럽습니다.

• 장점: VM/LXC 생성과 삭제, 스냅샷, 스토리지 매핑 동선이 짧습니다.
• 장점: 하이퍼바이저와 스토리지가 같은 컨텍스트에 있어 초기 구축 속도가 빠릅니다.
• 주의: 파일 서버 역할까지 한 박스에 합치면 장애 분석에서 컴퓨트와 스토리지가 한 번에 얽힙니다.
• 주의: 백업 파일까지 같은 풀에 두면 "백업은 있는데 공간이 부족해 복구가 불편한" 상황이 생기기 쉽습니다.

2. TrueNAS SCALE은 "데이터가 주인공"인 구조

TrueNAS SCALE은 데이터셋 경계, 공유 정책, 스냅샷, 복제, SMB/NFS/iSCSI 제공이 우선입니다. VM 기능도 있지만 운영 감각으로 보면 "가상화가 가능한 NAS"에 더 가깝습니다. 가족 사진, 미디어 라이브러리, 백업 저장소, 다른 하이퍼바이저에 제공할 공유 스토리지, 장기 보관 데이터처럼 데이터 수명주기가 먼저인 환경에서 확실히 손에 맞습니다.

• 장점: 데이터셋 기준으로 권한, 스냅샷, 공유 대상을 나누기 쉽습니다.
• 장점: SMB, NFS, iSCSI처럼 외부 소비자가 많은 환경에서 관리 포인트가 명확합니다.
• 주의: VM 운영을 주력으로 삼으면 Proxmox보다 동선이 길고, 하이퍼바이저 관점의 자동화도 덜 자연스럽습니다.
• 주의: NAS 안에서 애플리케이션과 스토리지를 함께 굴릴 때도 결국 I/O 혼합 문제는 피하기 어렵습니다.

Proxmox VE vs TrueNAS SCALE 비교 표

제가 직접 굴려보며 정리한 현실적인 배치 패턴

홈랩에선 대체로 세 가지 구조로 정리됩니다.

1. 올인원 Proxmox VE: 한 대 서버에 Proxmox VE와 ZFS를 올리고, VM과 LXC를 로컬 스토리지에서 직접 운영
2. 분리형: Proxmox VE는 컴퓨트, TrueNAS SCALE은 스토리지 전용으로 역할 분리
3. TrueNAS 중심: 파일 서버와 백업이 주력이고, VM은 소수만 운영

초기 구축 난이도만 보면 1번이 가장 쉽습니다. 장비도 덜 들고, 네트워크 설계도 단순합니다. 다만 올인원은 문제가 나기 전까지는 단순하고, 문제가 난 뒤에는 복잡해지는 구조입니다. 반대로 2번은 처음부터 케이블, 스위치, 전력, 장비 공간을 더 생각해야 하지만 장애가 났을 때 원인 분리가 빠릅니다. 3번은 홈 미디어, 문서 보관, 백업 허브처럼 데이터 중심 가정 환경에 잘 맞습니다.

제 기준으로는 이렇게 나뉩니다. 하루에 VM을 여러 번 만들고 지우거나, LXC 템플릿과 테스트 클러스터를 자주 만지면 Proxmox VE 쪽이 맞습니다. 반면 파일 공유, 스냅샷, 복제, ACL, 사용자 권한, 백업 보존 기간이 더 중요하면 TrueNAS SCALE이 더 손에 맞습니다. 양쪽이 모두 중요하다고 느껴지는 시점부터는 사실상 분리형으로 가는 편이 덜 후회하더라고요.

가상화 노드와 NAS를 역할별로 분리했을 때 관리 포인트가 어떻게 달라지는지 보여주는 예시입니다.

실전 구현 1: Proxmox VE에서 ZFS 상태 확인과 스토리지 구조 점검

운영 전에 가장 먼저 볼 건 성능 수치가 아니라 풀의 건강 상태와 저장소 역할 분리입니다. ZFS가 불안정한데 그 위에 VM을 계속 얹는 건, 바닥이 젖은 창고에 선반부터 세우는 느낌과 비슷합니다.

zpool status -v
zpool list -o name,size,alloc,free,frag,health
zfs list -o name,used,avail,refer,mountpoint
pvesm status
journalctl -u pvestatd --since -1h

위 명령은 Proxmox VE에서 ZFS 상태와 스토리지 인식 상태를 빠르게 같이 볼 때 유용합니다. 특히 pvesm status와 journalctl -u pvestatd는 ZFS 자체 문제인지, 아니면 Proxmox가 저장소를 인식하는 상위 계층 문제인지 가르는 데 도움이 됩니다.

• zpool status -v: ONLINE이 아니면 성능 튜닝보다 원인 확인이 먼저입니다.
• zpool list: 공간뿐 아니라 frag와 health를 같이 봅니다. 용량 여유가 부족한 풀은 성능보다 운영 여유가 먼저 줄어듭니다.
• pvesm status: Proxmox가 인식하는 저장소가 비정상인지, 단지 ZFS CLI 상의 문제인지 구분합니다.
• journalctl -u pvestatd: 스토리지 인식 지연, 타임아웃, 마운트 문제 같은 상위 계층 신호를 볼 때 유용합니다.

Proxmox VE 쪽에선 저장소를 기능별로 나누는 게 중요합니다. 특히 VM 디스크와 ISO, 템플릿, 백업 파일을 같은 경로에 몰아두면 관리가 금방 흐려집니다.

zfspool: local-zfs
    pool rpool/data
    content images,rootdir
    sparse 0

dir: local
    path /var/lib/vz
    content iso,vztmpl

dir: backup-store
    path /mnt/backup
    content backup

이 예시는 Proxmox VE의 /etc/pve/storage.cfg에 들어가는 형태를 기준으로 한 겁니다. 포인트는 단순합니다. local-zfs는 게스트용, local은 설치 자산용, backup-store는 복구 자산용입니다. 이 셋이 섞이기 시작하면 장애가 났을 때 판단이 흐려집니다.

또 하나, Proxmox에서 ZFS를 쓸 때는 데이터셋 속성만 보지 말고 게스트 유형별 I/O 패턴을 먼저 떠올리는 게 좋습니다. 예를 들어 로그가 많은 리눅스 VM과 대용량 미디어 파일은 같은 디스크라도 이상적인 속성이 다릅니다. VM 디스크는 무작정 큰 블록이 유리하다고 보기 어렵고, 미디어 저장소는 너무 작은 블록이 오히려 메타데이터 부담만 늘릴 수 있습니다.

실전 구현 2: TrueNAS SCALE 쪽에서 ZFS 데이터셋과 공유 전에 꼭 보는 것

TrueNAS SCALE에서는 공유를 열기 전에 데이터셋 경계를 먼저 설계하는 게 핵심입니다. 제 경험상 여기서 서두르면 나중에 ACL, 스냅샷 정책, 복제 범위를 다시 뜯게 됩니다. 홈랩에서 자주 쓰는 패턴은 vmstore, backup, media, homes처럼 용도별로 쪼개는 방식입니다.

zpool status -v
zfs list -r tank
zfs create -o compression=lz4 -o atime=off tank/backup
zfs create -o compression=lz4 -o atime=off -o recordsize=1M tank/media
zfs create -o compression=lz4 -o atime=off tank/homes
zfs snapshot tank/backup@pre-share-change
zfs get compression,atime,recordsize,mountpoint tank/media

이 명령 자체보다 더 중요한 건 왜 데이터셋을 나눴는가입니다. TrueNAS 공식 문서도 공유를 만들기 전에 데이터셋과 zvol을 먼저 구조화하는 흐름을 권장합니다. 이 순서를 지키면 나중에 권한과 스냅샷 정책이 덜 꼬입니다.

• backup: 변경 빈도와 보존 정책이 중요합니다.
• media: 큰 파일 위주면 작은 블록 이득이 거의 없고, 오히려 메타데이터 부담이 커질 수 있습니다.
• homes: 사용자 권한과 스냅샷 복구 포인트가 더 중요합니다.

여기서 자주 생기는 실수가 있습니다. SMB 공유부터 먼저 만들고 나중에 데이터셋을 분리하는 방식입니다. 가능은 하지만 운영이 길어질수록 권한 모델과 스냅샷 범위가 꼬이기 쉽습니다. TrueNAS SCALE은 UI가 잘 되어 있어 보여도, 기반은 결국 ZFS입니다. 경계는 UI가 아니라 데이터셋에서 잡아야 나중이 편합니다.

VM용 블록 스토리지를 제공할 계획이라면 zvol 설계도 초기에 생각해두는 편이 좋습니다. 특히 volblocksize는 만든 뒤 변경이 까다롭기 때문에, 나중에 성능이 마음에 안 들어 구조를 다시 만지는 경우가 적지 않습니다.

zfs create -V 500G -o compression=lz4 -o volblocksize=16K tank/vmstore/proxmox-iscsi-01
zfs get volblocksize,compression,used,referenced tank/vmstore/proxmox-iscsi-01

여기서 16K는 예시일 뿐 정답은 아닙니다. 워크로드에 따라 더 작거나 큰 값이 맞을 수 있습니다. 핵심은 블록 스토리지는 파일 공유 데이터셋과 다르게 생각해야 한다는 점입니다. 미디어 보관용 데이터셋과 VM용 zvol을 같은 감각으로 만들면 나중에 체감이 어색해집니다.

데이터셋을 먼저 나누고 공유를 나중에 여는 흐름이 왜 중요한지 보여주는 구성 예시입니다.

재현 가능한 시나리오: VM 저장소와 NAS 저장소를 한 풀에 같이 둔 경우

이건 홈랩에서 정말 흔합니다. 한 대 서버에 Proxmox VE를 올리고, 같은 ZFS 풀에 VM 디스크, 미디어 파일, 백업 아카이브, 다운로드 작업 디렉터리까지 다 넣는 구조죠. 평소엔 잘 굴러가도 서로 다른 I/O 패턴이 겹치는 순간 반응이 확 달라집니다. 예를 들어 백업 압축, 미디어 라이브러리 스캔, VM 패키지 업데이트가 겹치면 게스트 내부에서 체감이 둔해집니다.

이때 CPU와 RAM을 먼저 의심하기 쉽지만 실제 병목은 스토리지 큐와 지연일 때가 많습니다. 그래서 필요한 건 감이 아니라 관찰입니다.

iostat -x 1
zpool iostat -v 1
qm list
pct list

이 조합은 디스크 지연과 풀별 I/O, 그리고 실제로 어떤 게스트가 떠 있는지를 같이 보는 데 좋습니다. 짧은 스파이크보다 지속적으로 길어지는 대기 시간이 더 위험 신호인 경우가 많습니다.

• iostat -x 1: 특정 디스크의 대기 시간이 길게 유지되는지 봅니다.
• zpool iostat -v 1: 풀 전체가 아니라 특정 vdev만 바쁜지 구분합니다.
• qm list, pct list: 어떤 게스트가 실제로 그 시간대에 스토리지를 적극 사용 중인지 대조합니다.

여기서 핵심 판단은 "더 튜닝할까"보다 "이 워크로드를 같은 풀에 계속 둘 가치가 있나"입니다. 홈랩에선 성능 최적화보다 역할 분리가 더 큰 효과를 내는 경우가 많습니다. 메인 가족 사진과 테스트 VM을 한 운명으로 묶어두는 건, 실험의 자유를 데이터 안전과 교환하는 선택이 되기 쉽습니다.

실패 모드별로 보는 근본 원인: 겉증상보다 구조를 봐야 합니다

⚠️ 주의사항과 트러블슈팅: 제가 많이 부딪힌 부분

디스크 패스스루(pass-through)로 TrueNAS를 VM 안에 넣는 경우

Proxmox 위에 TrueNAS SCALE VM을 올리고 디스크나 HBA를 패스스루하는 구성은 학습용으로 좋습니다. 다만 메인 NAS로 오래 가져갈 때는 질문이 달라집니다. 문제가 났을 때 하이퍼바이저 문제와 스토리지 문제를 분리해서 볼 수 있는가? 이게 핵심입니다.

• 디스크 식별이 꼬이거나 컨트롤러 인식이 흔들리면 장애 분석이 길어집니다.
• 부팅 순서와 장치 초기화 타이밍이 꼬이면 NAS VM 기동이 늦어질 수 있습니다.
• 스토리지 문제와 하이퍼바이저 문제를 별개로 다뤄야 하는데, 이 구조에선 둘이 자주 함께 움직입니다.

제 판단은 분명합니다. 학습, 실험, 임시 구축에는 괜찮습니다. 하지만 가족 데이터, 장기 보관 백업, 다른 노드가 의존하는 공유 스토리지를 실으면 구조 난도가 올라갑니다. 홈랩이더라도 메인 데이터는 가상화 실험의 부속품이 아니어야 마음이 편합니다.

스냅샷은 백업이 아닙니다

ZFS 스냅샷은 되돌리기에는 훌륭하지만, 같은 풀 안에 남아 있는 한 장애 도메인이 동일합니다. 사용자 실수 복구에는 강하지만 장치 고장, 잘못된 운영 변경, 랜섬웨어 성격의 암호화 사고, 풀 자체 문제까지 모두 덮어주진 못합니다. 홈랩에서도 최소한 다른 장비나 원격 대상으로 복제하거나 백업을 보내는 구조가 필요합니다.

SMB 권한과 Linux 퍼미션이 어긋나는 경우

TrueNAS SCALE에서 흔한 착시는 "공유가 열렸으니 서비스 문제는 아니다"라고 생각하는 겁니다. 실제로는 공유 서비스보다 데이터셋 권한, ACL, 소유권 설계에서 막히는 경우가 더 많습니다. 특히 한 데이터셋을 여러 용도에 같이 쓰면 나중에 한쪽 요구사항을 맞추다가 다른 쪽이 깨지기 쉽습니다. 제 경험상 이 문제는 튜닝으로 해결되지 않고, 데이터셋 경계 재설계로 끝나는 경우가 많았습니다.

저장소 속성을 한 번에 통일하는 경우

모든 데이터셋에 동일한 속성을 주는 것도 자주 보이는 실수입니다. 미디어 보관, VM 블록 스토리지, 사용자 홈 디렉터리, 백업 아카이브는 액세스 패턴이 다릅니다. 속성값 하나로 모두 해결하려 하면 결국 어느 쪽에서도 만족스럽지 않은 결과가 나옵니다. 홈랩에서도 최소한 대용량 순차 파일과 작은 랜덤 I/O 정도는 분리해서 생각하는 편이 낫습니다.

검증과 결과 확인: 무엇을 보면 구성이 잘 됐다고 판단할까

다 만들어놓고 "일단 잘 되네"에서 멈추면, 실제 검증은 아직 덜 된 셈입니다. 저는 적어도 아래 항목은 확인해야 구축이 끝났다고 봅니다.

1. 재부팅 후 풀 상태가 자동으로 정상 인식되는지 확인
2. 스냅샷이 의도한 데이터셋 또는 게스트 범위에서만 생성되는지 확인
3. VM 또는 컨테이너가 해당 저장소를 안정적으로 읽고 쓰는지 확인
4. SMB, NFS, iSCSI 접근 권한이 예상한 사용자와 장치에만 적용되는지 확인
5. 백업 또는 복제 대상에서 실제 복구 테스트가 가능한지 확인

예를 들어 Proxmox VE에서는 게스트가 붙어 있는 저장소가 부팅 후 정상 활성화되는지와, 백업 경로가 일시적으로 마운트 실패했을 때 어떤 경고가 나는지를 보는 게 중요합니다. TrueNAS SCALE에서는 공유 서비스가 떠 있는지만 볼 게 아니라, 데이터셋 마운트 상태와 권한이 함께 정상인지를 확인해야 합니다.

zfs list -o name,mounted,readonly
zpool status -x
showmount -e nas-host
smbclient -L //nas-host -U username

이 명령은 검증 관점에서 꽤 실용적입니다. 단, showmount는 NFS 서버가 실제로 export를 제공할 때 의미가 있고, smbclient는 Samba 클라이언트 패키지가 설치돼 있어야 합니다. 화려하진 않지만 이런 확인이 벤치마크보다 더 값질 때가 많습니다. 홈랩에서 오래 버티는 구성은 평균 성능이 약간 더 좋은 구성이 아니라, 이상 징후를 빨리 드러내는 구성이더라고요.

ZFS 상태, 스냅샷, 공유, VM 연결 상태를 한 번에 점검하는 검증 관점의 결과 화면 예시입니다.

상황별 추천: 이런 경우엔 Proxmox VE, 이런 경우엔 TrueNAS SCALE

여기서는 애매하게 말하지 않겠습니다.

• VM, LXC, 실험용 서비스가 중심이라면 Proxmox VE가 맞습니다. 로컬 ZFS로 단순하게 가져가고, 백업 저장소만 별도 경로 또는 별도 장비로 떼는 구성이 운영이 편합니다.
• 파일 공유, 미디어, 장기 보관, 백업 허브가 중심이라면 TrueNAS SCALE이 더 맞습니다. 데이터셋과 권한 모델을 먼저 설계하는 편이 결과가 좋습니다.
• 둘 다 중요하고, 둘 다 메인 서비스라면 분리형이 맞습니다. Proxmox VE는 컴퓨트, TrueNAS SCALE은 스토리지. 홈랩에서 비용은 조금 늘어도 판단 비용과 복구 비용이 줄어듭니다.
• 한 대 장비로 반드시 끝내야 하는 상황이라면 Proxmox VE 단독 또는 TrueNAS 중심 중 하나를 고르고, 반대 역할은 최소화하는 편이 낫습니다. 둘을 동등한 주인공으로 세우는 순간 구조가 무거워집니다.

이 판단에서 중요한 건 제품 팬심이 아니라 장애 우선순위입니다. 서버가 멈췄을 때 가장 먼저 살리고 싶은 것이 VM이라면 Proxmox VE, 가장 먼저 지키고 싶은 것이 데이터라면 TrueNAS SCALE입니다. 이 기준이 서지 않으면 계속 기능 비교만 하게 됩니다.

관련 글이 있다면 Proxmox 백업 전략, ZFS 스냅샷 정책, 홈랩 NAS 네트워크 분리 구성도 함께 읽어보세요. 이 세 가지를 같이 보면 장비 선택보다 구조 선택이 먼저라는 점이 더 또렷해집니다.

FAQ 성격으로 짧게 짚고 가는 포인트

Q. 홈랩 입문자는 뭘 먼저 시작하는 게 좋을까요?

서비스 여러 개를 띄워보며 익히는 게 목표면 Proxmox VE부터, 집안 파일 서버와 백업 체계를 안정적으로 만들고 싶으면 TrueNAS SCALE부터 시작하는 편이 시행착오가 적습니다.

Q. 한 대 서버로 둘 다 하고 싶으면요?

가능은 합니다. 다만 메인 데이터까지 얹는다면 복구 순서를 종이에 적어보는 걸 권합니다. 하이퍼바이저가 안 뜰 때 NAS 접근을 어떻게 할지, NAS가 안 뜰 때 VM 백업을 어디서 꺼낼지 막히면 아직은 역할을 더 줄이는 편이 낫습니다.

Q. ZFS를 쓰니까 둘 다 체감 차이가 거의 없지 않나요?

그렇지 않습니다. 파일시스템은 같아도 관리 흐름, 장애 대응, 공유 제공 방식, 권한 모델, 복구 순서가 다릅니다. 체감 차이는 대개 평상시보다 문제 상황에서 크게 드러납니다.

Q. 언제 굳이 쓰지 말아야 하나요?

Proxmox VE는 메인 데이터 보관과 테스트 워크로드를 한 박스에 무리하게 합칠 때 조심해야 하고, TrueNAS SCALE은 잦은 VM 실험과 하이퍼바이저 자동화가 핵심일 때 굳이 주력으로 잡지 않는 편이 낫습니다.

마무리: 제가 지금 다시 홈랩을 짠다면 이렇게 갑니다

제가 지금 처음부터 다시 짠다면, VM 실험과 서비스 배포가 메인이면 Proxmox VE에 로컬 ZFS를 쓰고 백업 저장소는 반드시 다른 경로나 다른 장비로 분리하겠습니다. 반대로 가족 사진, 미디어, 백업 아카이브가 더 중요하면 TrueNAS SCALE을 별도 장비로 두고, Proxmox는 그 저장소를 소비하는 쪽으로 붙일 겁니다.

가상화가 중심이면 Proxmox VE, 데이터가 중심이면 TrueNAS SCALE. 둘 다 중요하면 역할 분리입니다. 홈랩에선 이 판단이 장비 스펙보다 오래 갑니다. ZFS는 둘 다 훌륭하지만, 차이를 만드는 건 파일시스템 이름보다도 무엇을 먼저 지키도록 구조를 짰느냐였습니다.

어떤 환경에서 무엇을 고르면 되는지 빠르게 판단할 수 있도록 핵심 선택 기준을 요약한 이미지입니다.