[Proxmox 시리즈 3편] VM과 LXC 사이에서 워크로드를 어떻게 나눌 것인가

Proxmox VE를 쓰다 보면 "이 서비스는 VM으로, 저 서비스는 LXC로" 나누라는 말을 자주 듣습니다. 하지만 초보자는 기준을 찾지 못해 결국 모든 것을 VM으로 만들거나, 반대로 LXC만 잔뜩 만든 뒤 커널 제약을 만나는 경우가 많습니다. 이번 글은 실제 홈랩 워크로드를 예로 들어 어떤 기준으로 결정을 내리면 좋은지 정리합니다.

핵심은 격리 강도, 커널 의존성, 장기 업데이트 계획, 스냅샷·백업 전략을 함께 고려해 반복 가능한 규칙을 만드는 것입니다. 이 규칙이 있으면 워크로드가 늘어날수록 판단이 빨라지고, 나중에 여러 노드로 확장할 때도 기준을 그대로 가져갈 수 있습니다.

이 글의 흐름

판단 프레임워크: 격리, 상태, 커널, 복구 비용
사례별 판단: Reverse proxy, 모니터링, 앱 서버, 데이터베이스, Docker 호스트, Windows 테스트 박스
의사결정 테이블 만들기
흔한 실수와 회피 전략
다음 단계: 표준 VM 템플릿으로 연결하기

이번 글에서 새로 나오는 용어

커널 의존성: 특정 커널 모듈이나 버전에 묶인 요구사항을 의미합니다.
상태 밀도 (state density): 데이터베이스처럼 디스크 상태가 복잡하고 변경 빈도가 높은 워크로드의 특성입니다.
조정 비용 (tuning cost): 워크로드별로 적용해야 하는 커널 파라미터나 cgroup 설정 등 추가 조정 비용입니다.
복구 지연 (recovery lag): 장애 발생 후 정상 상태로 돌아오기까지 필요한 시간과 절차를 뜻합니다.
의사결정 테이블: 워크로드와 기준을 한눈에 볼 수 있게 만든 표입니다.

읽기 카드

예상 소요 시간: 22분

사전 준비: Proxmox 기본 레이아웃(스토리지·브리지·백업)을 정리한 상태

읽고 나면: 주요 홈랩 워크로드를 어떤 기준으로 VM 또는 LXC에 배치할지 설명할 수 있습니다.

판단 프레임워크: 격리, 상태, 커널, 복구 비용

다음 네 축에서 점수를 매기면 대부분의 워크로드에 일관된 결론을 낼 수 있습니다.

축	1점	2점	3점
격리 강도	사용자/프로세스 분리만 필요 (프록시)	시스템 패키지 충돌 방지 필요 (모니터링)	커널단까지 격리 필수 (DB, Docker, Windows)
상태 밀도	설정 파일, 캐시 수준	애플리케이션 상태·볼륨 데이터 혼재	데이터베이스·로그 장기보존처럼 변경 빈도·복잡도가 높음
커널 의존성	추가 모듈 요구 없음	eBPF, AppArmor 등 호스트 설정과 맞물림	커널 버전 통제·독립 업데이트가 필요한 수준
복구 비용	5분 이내, 템플릿 클론으로 끝	5~30분, 스크립트나 일부 수동작업 필요	30분 이상, 데이터 검증·복원 절차 필수

격리 강도: 운영체제부터 완전히 분리해야 한다면 VM을 선택합니다. 사용자 계정과 파일 경계만 분리하면 되는 수준이라면 LXC를 고려할 수 있습니다.
상태 밀도: 데이터가 빠르게 변하고 복구에 민감한 워크로드는 VM 쪽이 편합니다. LXC도 가능하지만 스냅샷·백업 도구가 다르고, 복원 시 커널 버전에 더 민감합니다. LXC 스냅샷은 ZFS, LVM-Thin, btrfs 백엔드에서는 가능하지만, dir 스토리지의 ext4/xfs에서는 지원되지 않습니다.
커널 의존성: 특정 커널 모듈, AppArmor, eBPF, iptables 등 기능이 필요한지 확인합니다. LXC는 호스트 커널을 공유하므로 호스트 커널을 업그레이드하면 모든 컨테이너가 즉시 영향을 받습니다.
복구 비용: 문제가 났을 때 재설치와 복원이 빠른 워크로드는 LXC에서 이득을 봅니다. 반대로 복구 절차가 복잡하면 VM으로 격리를 강하게 유지하는 것이 안전합니다. 데이터베이스처럼 상태 밀도가 높은 서비스는 거의 항상 3점입니다.

이 네 요소를 1~3점으로 매겨 합계가 높으면 VM, 낮으면 LXC로 가는 식으로 단순화할 수 있습니다. 중요도가 다른 항목이 있다면 가중치를 곱해도 좋습니다(예: 상태 밀도 ×1.5). 점수표 옆에 실제 점수 기준을 간단히 남겨 두면 팀원과 함께 쓰기 좋습니다.

스토리지와 스냅샷

ZFS, LVM-Thin, btrfs → LXC/VM 스냅샷 지원

dir(ext4/xfs) → VM(LVM) 스냅샷만 가능, LXC는 pct snapshot 불가

dir+btrfs → LXC 스냅샷 가능, 단 btrfs 유지관리 필요 스냅샷 전략을 먼저 정한 뒤 워크로드를 배치해야, 나중에 스토리지 제한으로 선택을 번복하지 않습니다.

사례별 판단

Reverse proxy (예: Nginx, Caddy)

격리: 낮음. 네트워크 포트와 TLS 키만 분리하면 됩니다.
상태: 매우 낮음. 설정 파일과 인증서 정도입니다.
커널: 특별한 의존성 없음.
복구 비용: 낮음. 템플릿에서 바로 복제 가능.

추천: LXC. 단, TLS 키를 안전하게 다루기 위해 파일 권한과 백업 경로만 명확히 설정하십시오. 외부와 맞닿는 LXC는 가능하면 unprivileged 모드(호스트 root 권한과 UID를 분리)로 만들고, 필요한 스토리지(ZFS/LVM-Thin/btrfs)를 선택해 스냅샷 지원 여부를 확인하십시오. Privileged 모드가 필요하다면 격리 강도를 2점 이상으로 재분류하십시오.

모니터링 스택 (예: Prometheus, Netdata)

격리: 중간. 호스트 메트릭 수집 시 권한이 필요합니다.
상태: Retention이 길 경우 디스크 사용량이 큽니다.
커널: 일부 eBPF 기능이 필요할 수 있습니다.
복구 비용: 중간. 장시간 데이터 보존이 필요하면 복원 절차가 복잡합니다.

추천: Netdata처럼 가벼운 도구는 LXC(unprivileged)로 시작하되, 호스트 메트릭이나 eBPF 수집이 필요하면 privileged LXC나 VM으로 승급하십시오. 장기간 데이터가 필요한 Prometheus+Grafana 조합은 VM에서 운영하면서 별도 디스크를 붙입니다. Prometheus가 필요한 cAdvisor/eBPF 모듈은 커널 버전 의존성이 크므로, 호스트 커널 업데이트 전에 테스트 컨테이너를 복제하여 영향을 사전 검증하십시오.

앱 서버 (예: Ubuntu + Docker + 애플리케이션)

격리: 높음. Docker 데몬과 애플리케이션 스택을 다른 서비스와 분리하고 싶습니다.
상태: 중간. 애플리케이션 데이터가 외부 DB를 쓰더라도 배포 파이프라인과 이미지 캐시가 남습니다.
커널: Docker를 LXC 안에서 돌리면 cgroup nested 문제가 발생하기 쉽습니다.
복구 비용: 중간 이상. 배포 자동화가 없으면 수작업이 많습니다.

추천: VM. Ubuntu나 Debian VM을 기준 템플릿으로 만들어 반복적으로 클론하십시오. LXC 내부에서도 Docker를 기술적으로 실행할 수 있지만, cgroup v1/v2, overlayfs, seccomp 프로파일 설정을 세심하게 맞춰야 하고 Proxmox가 공식적으로 지원하지 않습니다. 테스트 용도로만 LXC+Docker를 써보고, 장기 운영이나 업그레이드 독립성이 필요하다면 VM으로 전환하십시오.

데이터베이스 (예: PostgreSQL, MariaDB)

격리: 높음. 파일시스템과 I/O 스케줄러까지 통제해야 합니다.
상태: 매우 높음. 복구 지연이 가장 큰 워크로드입니다.
커널: EXT4, XFS 옵션이나 HugePages 등 커널 튜닝이 필요할 수 있습니다.
복구 비용: 매우 높음.

추천: VM 고정. 전용 가상 디스크를 두고, 백업은 Proxmox 백업과 DB 전용 백업 모두 준비합니다. 디스크 I/O 튜닝이나 HugePages 설정도 VM 안에서 관리하면 다른 워크로드에 영향을 주지 않습니다.

Docker 호스트 (여러 컨테이너 묶음)

격리: 높음. Docker와 Proxmox LXC를 중첩하면 관리 복잡도가 커집니다.
상태: 중간. 컨테이너는 stateless라도 볼륨 데이터가 남습니다.
커널: Docker 기능과 함께 커널 버전을 스스로 조절하고 싶을 수 있습니다.
복구 비용: 중간.

추천: VM. 시스템 업그레이드와 도커 버전을 독립적으로 관리할 수 있습니다. LXC와 Docker를 중첩하면 커널·스토리지·보안 설정 모두에서 관리 복잡도가 폭증합니다. 굳이 LXC를 선택해야 한다면 privileged 컨테이너, 전용 cgroup2 설정, nesting=1과 keyctl=1 같은 추가 옵션을 이해한 뒤 제한된 테스트 범위 내에서만 사용하십시오.

Windows 테스트 박스

격리: 최상. 리눅스 커널과 분리해야 합니다.
상태: 중간. 실험용이라면 스냅샷만으로도 충분합니다.
커널: Linux LXC에서 Windows를 돌릴 수 없습니다.
복구 비용: 낮음. 스냅샷에서 복원하면 됩니다.

추천: VM. CPU 가상화 옵션, UEFI/BIOS 모드, VirtIO 드라이버를 사전에 준비하십시오. Windows는 전혀 다른 커널을 사용하므로 LXC 컨테이너로 실행할 수 없습니다.

의사결정 테이블 예시

워크로드	격리	상태	커널	복구 비용	총점	권장
Reverse proxy	1	1	1	1	4	LXC
모니터링(Netdata)	2	1	2	2	7	LXC (호스트 메트릭 수집 시 privileged·VM 고려)
모니터링(Prometheus)	2	2	2	3	9	VM
앱 서버(Docker)	3	2	3	2	10	VM
데이터베이스	3	3	3	3	12	VM
Docker 호스트	3	2	3	2	10	VM
Windows 테스트	3	2	3	2	10	VM

총점 7 이하를 LXC 후보, 8 이상을 VM 후보로 두면 빠르게 분류할 수 있습니다. 다만 상태 밀도나 격리 강도가 3점을 찍는 순간에는 전체 합과 무관하게 VM을 우선 검토하는 식으로 상한선을 두십시오. 필요하면 각 항목에 "공유 네트워크 요구" 같은 기준을 더 추가하십시오.

흔한 실수와 회피 전략

모든 것을 LXC로 통일: 가볍다는 이유로 LXC에 Docker 호스트나 데이터베이스를 넣으면 커널 제약과 백업 복잡도가 폭발합니다.
VM에서만 백업: LXC도 동일한 백업 정책이 필요합니다. 컨테이너라고 해서 복구가 쉬운 것은 아닙니다.
커널 튜닝을 호스트에서 해결하려는 습관: 특정 워크로드만 필요한 튜닝이라면 VM 안에서 해결해야 합니다. 호스트 커널을 조정하면 모든 LXC에 영향을 줍니다.
복구 시나리오 미검증: 스냅샷과 백업을 혼동하면 LXC를 삭제했다가 되돌릴 수 없는 상황을 만나게 됩니다. 아래와 같이 최소한의 리허설을 해 두십시오.

# LXC 백업 검증
pct list
pct backup 200 local       # 임시 컨테이너 백업
pct stop 200 && pct destroy 200
pct restore 200 local/backup/vzdump-lxc-200.tar.zst
pct exec 200 -- hostname

# VM 백업 검증
qm list
vzdump 110 --storage local --mode snapshot
qmrestore local:backup/vzdump-qemu-110.vma.zst 111 --unique  # 테스트 복구

마무리

VM과 LXC 선택은 감이 아니라 구조화된 기준에서 출발해야 합니다. 격리, 상태, 커널, 복구 비용을 최소한으로 평가하면 대부분의 홈랩 워크로드를 빠르게 분류하고, 팀이 늘어나도 동일한 기준을 공유할 수 있습니다. 이번 글에서 만든 의사결정 테이블을 각자의 환경에 맞게 수정해 두면, 추후 노드를 추가하거나 워크로드를 이동할 때도 판단이 흔들리지 않습니다.

다음 글에서는 이렇게 분류된 워크로드 중 "표준 Linux VM"에 해당하는 케이스를 어떻게 템플릿으로 만들고, CPU·메모리·디스크 옵션을 어떻게 조정해야 하는지 다룹니다.

공유 커널 리스크 무시: 규제나 다중 테넌트 상황에서는 점수가 낮아도 VM을 택해야 합니다. 서로 다른 고객이나 신뢰 경계를 공유 커널 위에 올리면 권한 상승이 곧바로 전체 호스트에 영향을 줍니다.