[홈랩] Proxmox ARM64 홈랩 1년 회고: 라즈베리 파이 5 기반 운영 경험과 교훈

Proxmox ARM64 조합이 궁금한 분들이 꽤 많으시더라고요. 특히 라즈베리 파이 5로 홈랩 구축을 시작하려는 분들은 “전력도 적게 먹고 조용한데, 이걸 ARM 서버처럼 굴릴 수 없을까?” 하는 생각 한 번쯤 해보셨을 겁니다. 저도 딱 그랬습니다. x86 미니 PC는 성능이 좋지만, 늘 켜두는 장비에서는 발열, 소음, 소비전력이 계속 신경 쓰이거든요. 그래서 한동안은 라즈베리 파이 5를 중심으로 ARM 서버 성격의 홈랩을 꾸려보면서, 어디까지 실전에 쓸 수 있는지 꽤 집요하게 확인해봤습니다.

다만 여기서 먼저 짚고 가야 할 게 있습니다. Proxmox VE는 전통적으로 x86_64 중심으로 많이 쓰여 왔고, ARM64 환경은 공식 배포판보다는 커뮤니티 포팅(community port, 비공식 이식판)이나 실험적 구성에 가깝습니다. 이 포인트를 빼고 이야기하면 괜히 기대만 높아지거든요. 저도 처음엔 “가볍게 되겠지” 했다가 삽질 좀 했습니다 ㅎㅎ 그래도 결론부터 말하면, 목적만 분명하면 꽤 재미있고 배울 점도 많았습니다.

이번 글은 “무조건 추천”보다도, 1년 가까이 ARM 기반 홈랩을 굴리며 느낀 현실적인 장단점에 더 가깝습니다. 혹시 지금 Proxmox ARM64, 라즈베리 파이 5, 홈랩 구축 사이에서 고민 중이시라면, 시행착오 줄이는 데 도움이 될 겁니다.

라즈베리 파이 5, 스토리지, 네트워크, 컨테이너와 VM 흐름을 한눈에 보여주는 전체 아키텍처 이미지입니다.

Proxmox ARM64를 어떻게 이해하면 좋을까

쉽게 말해 Proxmox VE는 KVM(커널 기반 가상머신)과 LXC(리눅스 컨테이너)를 웹 UI로 관리하기 편하게 묶어둔 가상화 플랫폼입니다. x86 서버에서는 워낙 익숙한 선택지죠. 문제는 ARM으로 오면 이야기가 조금 달라집니다.

왜냐하면 ARM64 환경에서는 CPU 아키텍처 자체가 다르기 때문에, x86에서 별생각 없이 쓰던 이미지나 패키지가 그대로 안 돌아가는 경우가 꽤 있더라고요. 예를 들어 Docker 이미지도 amd64만 제공하는 경우가 있고, VM 이미지도 cloud image(클라우드 이미지) 지원이 제각각이거든요. 즉, Proxmox ARM64 홈랩은 '설치가 끝'이 아니라 워크로드 호환성까지 같이 봐야 하는 구조입니다.

제가 직접 써보니 운영 감각은 이렇습니다.

• LXC(Container, 컨테이너) 위주의 경량 워크로드는 꽤 잘 맞습니다.
• KVM VM은 가능하더라도 이미지 호환성과 리소스 여유를 더 따져야 합니다.
• 스토리지와 전원 안정성이 생각보다 중요합니다. 여기서 삐끗하면 OS보다 먼저 데이터가 흔들립니다.
• 홈랩 구축 관점에서는 학습 가치가 매우 큽니다. 다만 프로덕션 흉내를 내기보다, 제약을 이해하는 실험실에 더 가깝습니다.

라즈베리 파이 5가 홈랩에 매력적인 이유

라즈베리 파이 5는 이전 세대보다 체감 성능이 꽤 좋아졌고, 네트워크/스토리지 주변 구성을 신경 쓰면 단순 장난감 수준은 확실히 넘습니다. 물론 기업용 서버 대체는 아니지만, 저전력 ARM 서버 실험 용도로는 진입 장벽이 낮더라고요. 실제로 써보니까 책상 한쪽에서 조용히 계속 돌아가는 점이 진짜 편했습니다.

제가 잡았던 운영 목표: “적게, 가볍게, 오래”

처음엔 이것저것 다 올리고 싶었습니다. 근데 라즈베리 파이 5 기반 Proxmox ARM64 환경에서 욕심내면 금방 한계가 보이더라고요. 그래서 운영 원칙을 아주 단순하게 잡았습니다.

1. 컨테이너 우선: 가능하면 LXC로 먼저 배치합니다.
2. 서비스 분리: DNS, 리버스 프록시(reverse proxy, 역방향 프록시), 모니터링, 파일 동기화처럼 역할을 분리합니다.
3. 스토리지 외장 분리: microSD 한 장에 모든 걸 맡기지 않습니다.
4. 백업 자동화: 실험 환경일수록 백업이 더 중요합니다.

여기서 중요한 포인트! ARM 서버 홈랩은 “최대한 많은 걸 띄우는 경쟁”보다 “어디까지 안정적으로 굴러가는지 이해하는 과정”이 훨씬 값집니다.

Proxmox ARM64 실전 구현: 설치 전 준비

비공식 ARM64 포팅 환경은 세부 절차가 배포 방식마다 조금씩 다를 수 있습니다. 그래서 저는 설치 문서의 명령을 그대로 외우기보다, 어떤 구성 원칙이 필요한지를 기준으로 접근하는 편을 추천드립니다. 아래 예시는 Debian/ARM64 기반에 가상화 관련 패키지와 브리지 네트워크(bridge network, 가상 스위치 역할)를 준비하는 흐름입니다.

1. 라즈베리 파이 5에 안정적인 전원을 준비합니다.
2. 운영체제는 microSD보다 SSD/NVMe 성격의 외장 스토리지를 우선 검토합니다.
3. 고정 IP를 잡고, 관리용 네트워크 대역을 분리합니다.
4. 업데이트 후 재부팅해서 기본 상태를 먼저 안정화합니다.

sudo apt update
sudo apt full-upgrade -y
sudo reboot

재부팅 이후에는 기본 정보부터 확인합니다. 이 과정을 은근히 많이 건너뛰시는데, 나중에 문제 생겼을 때 제일 먼저 다시 보게 되는 값들입니다.

uname -a
arch
ip addr
lsblk
free -h

실제로 써보니까 여기서 디스크 인식 상태와 네트워크 인터페이스 이름을 미리 확인해두는 게 중요했습니다. 예전 습관대로 `eth0`만 보고 설정했다가 이름이 달라서 한참 헤맨 적이 있거든요.

브리지 네트워크 구성 예시

Proxmox 계열 환경을 쓰면 결국 브리지 네트워크를 많이 만지게 됩니다. 브리지(bridge)는 쉽게 말해 호스트와 VM/LXC가 같은 스위치에 물린 것처럼 보이게 해주는 방식입니다.

auto lo
iface lo inet loopback

auto eth0
iface eth0 inet manual

auto vmbr0
iface vmbr0 inet static
    address 192.168.10.20/24
    gateway 192.168.10.1
    bridge-ports eth0
    bridge-stp off
    bridge-fd 0

이런 식의 구성은 개념 이해용으로 좋습니다. 다만 실제 파일 위치나 관리 방식은 사용 중인 배포 환경에 따라 달라질 수 있으니, 현재 배포판의 네트워크 관리 체계를 먼저 확인하고 적용하시는 게 안전합니다.

브리지 네트워크, 호스트, 컨테이너, VM이 어떻게 연결되는지 이해하기 쉽게 보여주는 구성도입니다.

실전 운영: 어떤 워크로드가 잘 맞았나

제가 1년 가까이 굴리면서 느낀 건 명확했습니다. Proxmox ARM64에서는 '가볍고 분리하기 쉬운 서비스'가 잘 맞습니다. 예를 들면 이런 부류입니다.

• Pi-hole 같은 DNS 기반 서비스
• Nginx Proxy Manager나 Caddy 같은 리버스 프록시
• Prometheus, Grafana 계열의 경량 모니터링
• 테스트용 Git 러너나 작은 자동화 작업
• 내부 문서, 파일 동기화, 간단한 API 실험

반대로 무거운 데이터베이스를 여러 개 올리거나, x86 전용 이미지 의존성이 큰 서비스는 금방 피곤해집니다. 처음엔 “이 정도면 되겠지” 했었는데, 막상 이미지 아키텍처가 안 맞거나 메모리 여유가 줄어들면 체감이 확 오더라고요.

LXC 우선 운영 예시

저는 가능한 서비스는 컨테이너 중심으로 나눠서 운영했습니다. 서비스가 꼬여도 한 덩어리 전체가 죽지 않게 하려는 의도였죠.

pct list
pct start 101
pct enter 101
apt update && apt install -y curl vim

여기서 `pct`는 Proxmox 환경에서 LXC를 다룰 때 자주 보는 명령입니다. 컨테이너 안으로 들어가서 패키지를 설치하고, 로그를 분리해서 보는 흐름이 익숙해지면 운영이 꽤 편해집니다.

백업과 스냅샷 관점에서 배운 점

홈랩은 어차피 실험용이라고 생각하면 백업을 소홀히 하게 되는데, 이상하게 꼭 주말 밤에 터집니다. 저도 그랬습니다. 그래서 나중엔 백업 정책을 단순하게 잡았습니다.

1. 설정 파일은 Git 또는 별도 백업 저장소로 이중화
2. 컨테이너 단위 백업 정기 실행
3. OS 디스크와 데이터 디스크를 논리적으로 분리
4. 업데이트 전 스냅샷 또는 설정 백업 선행

vzdump 101 --mode snapshot --compress zstd --storage local
vzdump 102 --mode stop --compress zstd --storage local

모든 환경에서 똑같이 동작하는 건 아니지만, 이런 식의 백업 흐름 자체는 꼭 익혀두시는 걸 추천드립니다. 실패를 빨리 복구하는 능력이 홈랩 만족도를 많이 좌우하거든요.

⚠️ 실제로 많이 부딪힌 문제들

이 섹션은 좀 현실적으로 적어보겠습니다. “잘 된다”보다 중요한 게, 어디서 잘 안 되는지 아는 거니까요.

1. ARM64 이미지 호환성 문제

가장 자주 맞닥뜨린 문제입니다. Docker든 VM 이미지든 amd64만 준비된 경우가 생각보다 많습니다. 이럴 땐 에뮬레이션(emulation, 다른 아키텍처 흉내)로 우회하고 싶어지는데, 홈랩에서는 성능과 복잡도가 동시에 올라갑니다.

해결 팁은 단순합니다.

• 먼저 공식적으로 arm64 이미지를 제공하는지 확인합니다.
• 같은 역할의 대체 소프트웨어를 찾습니다.
• x86 전용 워크로드는 과감히 다른 노드로 분리합니다.

2. 스토리지 병목과 안정성

처음엔 microSD로도 되겠지 싶었는데, 로그와 업데이트, 컨테이너 쓰기 작업이 쌓이니까 금방 신경 쓰이더라고요. 드디어 됐다 싶다가도 I/O가 흔들리면 체감이 확 옵니다. 라즈베리 파이 5 홈랩 구축에서는 저장장치 품질이 성능만큼 중요합니다.

그래서 저는 운영 기준을 이렇게 바꿨습니다.

• 부팅 매체와 데이터 매체를 가능하면 분리
• 쓰기 많은 서비스는 별도 스토리지 고려
• SMART 확인 가능한 장치를 선호

3. 발열과 장시간 부하

라즈베리 파이 5는 성능이 올라간 만큼 발열 관리도 같이 봐야 합니다. 짧게 테스트할 때는 괜찮아도, 백업이나 업데이트처럼 부하가 길게 가면 차이가 납니다. 팬, 케이스, 통풍 구조를 너무 가볍게 보면 나중에 후회하더라고요.

4. 커뮤니티 포팅 특유의 변수

이건 정말 중요합니다. Proxmox ARM64는 공식 지원 범위보다 커뮤니티 정보 의존도가 큰 편이라서, 검색했을 때 나오는 글이 작성 시점마다 다릅니다. 어떤 글은 잘 되는데, 내 환경에서는 안 되기도 합니다. 저도 처음엔 이게 뭔가 싶었는데, 결국 핵심은 버전보다도 현재 커널, 패키지 상태, 네트워크/스토리지 구성을 같이 보는 거였습니다.

dmesg | tail -n 50
journalctl -xe
systemctl --failed
df -h

문제 생기면 꼭 위 네 가지는 같이 보세요. 특히 `journalctl`과 `dmesg`를 같이 보면 실마리가 빨리 잡힙니다.

로그 확인, 서비스 실패, 스토리지 상태 점검 등 실제 트러블슈팅 흐름을 보여주는 이미지입니다.

검증: 1년 운영 후 무엇이 남았나

성능 수치를 화려하게 적고 싶지만, 홈랩은 벤치마크 숫자보다 운영 감각이 더 중요하더라고요. 제가 얻은 결론은 이렇습니다.

• 경량 서비스 위주의 분산 운영에는 충분히 재미있고 실용적입니다.
• ARM 서버 특성상 호환성 점검이 습관이 됩니다.
• 장애 대응, 백업, 네트워크 분리 같은 기본기가 훨씬 단단해집니다.
• 무거운 VM 중심 환경을 기대하면 아쉬울 수 있습니다.

특히 좋았던 건 서비스를 작게 쪼개는 습관이 생겼다는 점입니다. 예전엔 한 VM 안에 이것저것 몰아넣곤 했는데, ARM 홈랩에서는 그렇게 하면 금방 관리가 복잡해집니다. 그래서 역할별 분리, 로그 분리, 백업 분리를 자연스럽게 하게 되더라고요. 이건 x86 환경으로 돌아가도 그대로 도움이 됐습니다.

그리고 Proxmox ARM64를 만져보면, “가상화 플랫폼은 단순히 설치해서 쓰는 게 아니라 하드웨어 제약과 운영 철학까지 같이 보는 거구나” 하는 감각이 생깁니다. 이건 숫자로 표현하기 어렵지만 정말 큰 수확이었습니다.

CPU, 메모리, 네트워크, 컨테이너 상태가 안정적으로 보이는 운영 결과 이미지입니다.

정리: Proxmox ARM64 홈랩을 추천할 사람, 말릴 사람

여기서 정리해보겠습니다. 혹시 이런 경험 있으신가요? 시작할 땐 “작고 조용한 서버 하나면 다 되겠지” 싶은데, 막상 운영해보면 내가 원하는 게 성능인지, 안정성인지, 학습인지 헷갈릴 때가 있습니다. Proxmox ARM64 + 라즈베리 파이 5 조합은 그 질문에 답하게 해주는 환경이었습니다.

이런 분께 추천합니다

• 홈랩 구축 자체가 재미있는 분
• ARM 아키텍처 제약을 배우고 싶은 분
• LXC 중심 경량 서비스를 나눠 운영하고 싶은 분
• 전력과 소음을 중요하게 보는 분

이런 분께는 x86이 더 낫습니다

• 여러 개의 무거운 VM을 안정적으로 돌려야 하는 분
• amd64 전용 이미지 의존성이 큰 분
• 트러블슈팅 시간을 줄이고 바로 결과가 필요한 분

제가 배운 가장 큰 교훈은 하나였습니다. 홈랩은 '최고 사양'보다 '운영을 계속하게 만드는 구조'가 더 중요하다는 점입니다. 라즈베리 파이 5 기반 ARM 서버는 분명 제약이 있지만, 그 제약 덕분에 오히려 운영 기본기를 더 제대로 배우게 되더라고요.

다음 글에서는 이 ARM 홈랩 위에 모니터링 스택을 어떻게 얹었는지, 그리고 어떤 서비스는 컨테이너로 두고 어떤 서비스는 분리했는지 더 자세히 다뤄볼 예정입니다. 이전 글에서 다룬 홈 네트워크 분리 전략과 함께 보시면 흐름이 더 잘 잡히실 겁니다.

장점, 한계, 추천 사용 시나리오를 한 장으로 정리한 요약 인포그래픽 이미지입니다.

자주 묻는 질문

Q. 라즈베리 파이 5에 Proxmox를 공식 지원하나요?

제가 확인하고 운영 방향을 잡을 때 기준으로는, x86_64 중심의 공식 흐름을 먼저 보는 게 맞았고, ARM64는 커뮤니티 포팅 성격을 염두에 두는 편이 안전했습니다. 그래서 실험/학습 목적이라면 좋지만, 무조건 공식 지원 장비처럼 기대하면 실망할 수 있습니다.

Q. Proxmox ARM64 홈랩에서 VM보다 컨테이너가 더 나은가요?

대체로 그렇습니다. 물론 워크로드에 따라 다르지만, 제가 직접 운영해보니 LXC 중심이 훨씬 가볍고 관리도 수월했습니다.

Q. 홈랩 구축 입문자도 바로 시작해도 될까요?

가능은 합니다. 다만 첫 홈랩이라면 x86 미니 PC가 더 수월할 수 있고, ARM 서버는 배움의 밀도가 높은 대신 변수도 많습니다. 본인이 “조금 돌아가더라도 배우면서 가겠다” 쪽이면 재미있게 하실 수 있습니다.

마무리

Proxmox ARM64는 만능 해법은 아니었습니다. 하지만 라즈베리 파이 5로 만든 홈랩 구축 경험은, 단순히 서버 한 대 굴린 것 이상을 남겨줬습니다. 아키텍처 차이, 이미지 호환성, 스토리지 안정성, 백업 습관, 장애 대응. 이런 것들이 전부 한 번에 묶여서 들어오거든요. 저도 처음엔 헷갈렸는데, 지나고 보니 그 과정 자체가 가장 큰 자산이었습니다.

한 줄로 정리하면 이렇습니다. “ARM 홈랩은 불편해서 배운다. 그리고 그 배움이 의외로 오래 간다.” 혹시 지금 라즈베리 파이 5 기반 ARM 서버를 고민 중이시라면, 너무 큰 기대보다는 분명한 목표 하나를 잡고 시작해보세요. 그게 DNS든, 프록시든, 모니터링이든 상관없습니다. 작게 시작하면 생각보다 오래, 그리고 꽤 재미있게 갑니다. 🎉