[Proxmox 시리즈 9편] 남는 하드웨어로 완성형 Self-Hosted 웹 인프라 만들기

Proxmox는 단일 서버 가상화 도구로 소개되지만, 실제로는 남는 미니 PC와 중고 장비를 묶어 “내 손으로 만든 웹 인프라”를 운영하게 만드는 운영 모델입니다. 이번 편에서는 시리즈 전체를 마무리하는 의미로, Proxmox 한 대—or 두 대—를 기반으로 웹 애플리케이션, 리버스 프록시, 모니터링, 테스트용 Windows, 그리고 OPNsense를 활용한 사설망·VPN 확장까지 포함한 완성형 흐름을 보여 줍니다.

이 글의 흐름

하드웨어 구성과 자원 배분 예시
역할별 VM/LXC 설계: 앱 서버, 프록시, 모니터링, Windows
네트워크 구조: 브리지, OPNsense, 사설망, VPN 확장
템플릿과 IaC 없이도 반복 가능한 배포 절차 만들기
소규모 팀·홈랩에서 실용적인 운영 루틴 정착

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

OPNsense: FreeBSD 기반 방화벽/라우터 배포판으로, Proxmox VM으로 올려 사설망과 VPN을 제어할 수 있습니다.
Jump VM: 외부 접속 시 Bastion처럼 쓰는 보안용 접점으로, VPN 또는 SSH를 통해 내부 리소스에 접근합니다.
Provisioning Template: Proxmox에서 만든 VM/LXC를 템플릿으로 전환해 반복 배포에 쓰는 기본 이미지입니다.

구성 개요

필수/선택 요소 구분

필수: Proxmox 호스트 1대, 리버스 프록시, 앱 서버, 모니터링 스택, OPNsense 기반 내부망(PVE 외부 노출 최소화)
선택: Windows 테스트 VM, Jump VM, 두 번째 Proxmox 호스트, PBS/NAS, VLAN 분리, 하드웨어 OPNsense 이중화

아키텍처 다이어그램

                 ┌───────────── 인터넷/ISP 라우터 ─────────────┐
                 │                                            │
            (물리 NIC 1)                                 (물리 NIC 2)
                 │                                            │
             [vmbr0 - WAN]                             [vmbr1 - LAN]
                 │                     ┌──────────────────────┴────────────┐
                 │                     │ OPNsense VM (WAN=vmbr0, LAN=vmbr1) │
                 │                     └──────────────┬────────────────────┘
                 │                                    │ 내부 DHCP/VPN/방화벽
   Proxmox UI, SSH, PBS                               │
                 │          ┌──────────────┬──────────┴──────────┬─────────┐
                 │          │              │                     │         │
             외부 접근   Reverse Proxy   App Server        Monitoring   Windows / Jump VM
                                    (모두 vmbr1에 연결, 필요 시 VLAN 분리)

읽기 카드

예상 소요 시간: 22분

사전 준비: Proxmox에서 VM/LXC 생성과 네트워크 브리지 설정 경험

읽고 나면: 미니 PC 여러 대를 활용해 self-hosted 웹 인프라를 구성하고 운영 루틴을 유지하는 과정을 설명할 수 있습니다.

하드웨어 구성 예시

역할	하드웨어	주요 자원
Proxmox 호스트 A	11세대 i5 미니 PC, 6~8코어, 32GB RAM, 1TB NVMe	메인 앱/프록시/모니터링
Proxmox 호스트 B (선택)	중고 데스크톱, 16GB RAM, 512GB SSD	PBS 혹은 테스트/HA 실험
NAS/PBS (선택)	저전력 미니 PC + 4TB HDD	백업·아카이브

단일 호스트에서도 시작할 수 있지만, 백업 전용 NAS/PBS가 따로 있으면 복구 루틴이 단단해집니다. NIC 두 개 이상이 가장 큰 선행 조건입니다. 기본적으로:

NIC 1 → vmbr0 (WAN/관리망) → 가정용 라우터와 직접 연결, Proxmox UI·SSH 노출
NIC 2 → vmbr1 (OPNsense LAN) → 내부 VM 전용. NIC가 하나뿐이면 USB NIC를 추가하거나, 임시로 단일 NIC + VLAN으로 시작한 뒤 추후 확장합니다.

메모리 배분 예시는 아래와 같습니다(총 32GB 기준).

워크로드	vCPU	RAM	디스크	비고
OPNsense	2	4GB	20GB	VPN/방화벽 처리량에 따라 4GB 이상 권장
Reverse Proxy	2	2GB	20GB	TLS 종료, ACME
App Server	4	8GB	120GB	Docker, DB 캐시, 추후 확장 시 RAM 추가
Monitoring	2	2GB	40GB	Prometheus + Grafana + 로그
Windows Test (선택)	2	6GB	80GB	오프라인일 때 RAM 회수
Jump VM (선택)	1	1GB	10GB	Tailscale/WireGuard 클라이언트
남는 리소스	-	약 9GB	-	Proxmox, 버퍼, 일시적 복구용

역할별 워크로드 설계

1. 앱 서버 (VM)

Ubuntu 24.04 LTS VM, 4 vCPU / 8GB RAM / 120GB 디스크 (동시 접속 50명 내외, Docker 컨테이너 2~3개 운영을 가정)
Docker 혹은 Podman으로 웹 애플리케이션과 백엔드 서비스 운영
GitOps 대신 간단한 Ansible 플레이북이나 스크립트로 패키지 설치, 사용자 생성, 서비스 부팅을 자동화해 재현성을 확보합니다.

2. 리버스 프록시 (LXC 혹은 VM)

Debian 기반 LXC, 2 vCPU / 2GB RAM / 20GB 디스크 (TLS 연결 수 기준 1Gbps 이하 트래픽 가정)
Caddy 혹은 Nginx Proxy Manager로 SSL 종단, HTTP→HTTPS 강제, WebSocket 처리
ACME DNS-01을 쓰면 80/443 외 포트를 노출하지 않고도 와일드카드 인증서를 자동 갱신할 수 있지만, DNS API 자격증명 보안에 유의합니다.

3. 모니터링 + 로깅 (LXC)

2 vCPU / 2GB RAM / 40GB 디스크
Prometheus + Grafana, Loki 혹은 Vector 기반 로깅을 설치
호스트와 VM/LXC에 node exporter, journald remote logging을 배포해 CPU·RAM·백업 실패 이벤트를 중앙에서 확인합니다.

4. 테스트용 Windows (VM)

Windows 11 Pro, 2 vCPU / 6GB RAM / 80GB 디스크
브라우저 호환성 검증, RDP를 통한 사내 솔루션 점검에 활용
필요할 때 켜고, 스냅샷으로 초기 상태 유지

5. OPNsense 방화벽 (VM)

2 vCPU / 4GB RAM / 20GB 디스크 (VPN 클라이언트 수에 따라 6GB까지 확장)
NIC 2개 이상 할당: vmbr0(WAN), vmbr1(LAN). WAN NIC는 가정용 라우터 IP대역과 통신하고, LAN NIC는 내부 VM DHCP·DNS·WireGuard를 담당합니다.
Proxmox 호스트의 vmbr1 포트 그룹은 외부 물리망과 분리되어야 하며, 실수로 브리지를 잘못 묶으면 OPNsense가 부팅되어도 트래픽이 우회할 수 있습니다.

각 워크로드는 cloud-init 혹은 템플릿을 기반으로 빠르게 복원할 수 있어야 합니다. 앱 서버와 프록시는 VM 템플릿에서, 모니터링과 보조 서비스는 LXC 템플릿에서 출발하면 배포 시간이 크게 줄어듭니다.

네트워크 구조 잡기

vmbr0 (WAN/관리망): 물리 NIC 1개를 가정용 라우터에 연결하고, 해당 NIC를 vmbr0에 브리지합니다. Proxmox UI, SSH, PBS 트래픽을 이 브리지로 제한하고 라우터에서 방화벽/포트포워딩 정책을 명확히 합니다.
vmbr1 (LAN): 물리 NIC 2개를 OPNsense 내부망 전용으로 씁니다. vmbr1에 연결된 VM은 외부와 직접 통신하지 않고, OPNsense VM의 LAN 인터페이스를 게이트웨이로 사용합니다. NIC가 하나뿐이라면 USB NIC 추가나 VLAN 태깅(vmbr0 하나에 tag=10/20)으로 임시 분리합니다.
OPNsense 정책: WAN→LAN 포트포워딩, NAT, WireGuard를 명시합니다. 예: WAN 443 → 프록시 VM 443(HTTPS), WireGuard 포트 51820 개방, 내부망에서 WAN으로 나갈 때만 NAT 허용. 방화벽 룰이 적용되어야만 “프록시 80/443만 외부 노출”이 성립합니다.
Jump VM (선택): 관리자가 WireGuard/Tailscale로만 내부망에 들어오도록 별도 Linux VM을 만들 수 있습니다. Jump VM은 vmbr1에 붙이고, WireGuard 서버는 OPNsense에서 운영하여 Jump VM은 클라이언트·보조 Bastion 역할만 담당하도록 분리합니다.

이 흐름을 문서화하면 문제 발생 시 “어디까지 접근이 허용되어야 하는가”를 명확히 추적할 수 있습니다.

반복 가능한 배포 절차

Day 0 - 네트워크 준비: Proxmox에서 vmbr0, vmbr1을 만들고 OPNsense VM을 먼저 배포해 DHCP·DNS를 설정합니다.
Day 1 - 템플릿 구축: OS 설치 후 보안 패치, 기본 패키지, 사용자 셋업을 마치고 Convert to Template를 실행합니다. 동일 OS 버전마다 템플릿을 1개씩 유지합니다.
Day 1 - Cloud-init 적용: Ubuntu cloud 이미지와 Proxmox cloud-init 기능(Hardware > Cloud-Init)을 활용해 hostname, SSH 키, 네트워크를 주입하면 5분 내 초기 부팅이 끝납니다.
Day 2 - 태그/네이밍 규칙: role=proxy, role=app, env=prod 등의 태그, VM ID 범위(예: 100대 앱, 200대 모니터링)를 정해 Datacenter 리스트를 빠르게 필터링합니다.
Day 2 - Ansible/스크립트: Docker 설치, 사용자 생성, 모니터링 에이전트 배포 등을 플레이북으로 자동화해 템플릿 간 드리프트를 줄입니다.
Day 3 - 백업·스냅샷 작업: Datacenter > Backup에서 PBS 대상으로 앱/프록시/OPNsense를 매일 백업하고, 모니터링·Windows는 주간 작업에 묶습니다. 작업 결과 알림을 이메일 혹은 ChatOps로 전달되게 설정합니다.

소규모 팀·홈랩 운영 루틴

변경 전 스냅샷: 앱 서버와 프록시에 중요한 변경을 적용하기 전 최신 스냅샷을 수동 촬영.
주간 리포트: PBS 백업 로그, Proxmox Task 로그, 모니터링 대시보드 스크린샷을 정리해 작은 리포트로 남깁니다.
월간 복구 연습: 아래 순서를 그대로 따라 30분 내 복구를 목표로 합니다.
1. 기존 앱 서버를 일시 중지하고, PBS에서 최신 백업을 선택.
2. 새 VM ID(app-restore-YYYYMM)로 복구하고 vmbr1에만 연결.
3. 서비스 기동 후 헬스체크(URL 응답, DB 연결)를 기록.
4. 복구에 걸린 시간과 실패 구간을 리포트에 포함.
확장 경로 검토: 필요 시 두 번째 Proxmox 호스트를 추가해 HA를 구성하거나, OPNsense를 실제 하드웨어로 옮겨 네트워크를 더 세분화합니다.

이 루틴은 기업형 IaC를 도입하지 않아도 재현성과 복구력을 높여 줍니다.

확장 아이디어: 사설망과 VPN

OPNsense + WireGuard: 외부에서 스마트폰/노트북으로 WireGuard 연결을 맺고, 내부망 리소스를 안전하게 관리합니다.
VLAN으로 서비스 분리: 앱 서버, 관리, IoT, 게스트 등으로 VLAN을 나누고, Proxmox 브리지에서 Tagged 포트를 설정해 각 VM/LXC에 다른 VLAN을 붙입니다.
하드웨어 방화벽 이중화: 저전력 x86 박스에 OPNsense를 별도로 올리고, VM과 CARP(가상 IP)로 상태를 동기화하면 VM 장애나 호스트 재부팅 시 네트워크가 유지됩니다. 단, 구성이 복잡하고 최소 2개의 WAN/LAN 포트가 필요합니다.

마무리

이제 하나의 Proxmox 노드가 단순 실험실을 넘어, 앱 서버·프록시·모니터링·Windows·OPNsense·백업이 맞물린 self-hosted 웹 인프라로 완성되었습니다. 단일 호스트는 어디까지나 홈랩/소규모 내부용이며, HA를 원한다면 최소 3노드(쿼럼)와 공유 스토리지를 별도로 계획해야 합니다. 핵심은 “작은 장비도 운영 모델만 명확하면 충분히 실용적”이라는 점입니다. 이 시리즈를 통해 Proxmox를 단순 UI가 아닌 운영 체계로 바라보고, 스토리지·네트워크·백업·배포를 하나의 흐름으로 묶는 감각을 가져가길 바랍니다.