관리 포트(SSH, 웹 관리자)를 인터넷에 직접 여는 대신, WireGuard VPN이나 Cloudflare Tunnel로 접근하면 포트를 열지 않고도 안전하게 접속할 수 있습니다. 관리 인터페이스는 가능한 한 공개하지 마세요.
7. 하드닝 체크리스트
항목
효과
SSH 키 인증 + 비밀번호 차단
무차별 대입 원천 차단
방화벽(필요 포트만)
공격 표면 축소
fail2ban
반복 공격 IP 자동 밴
자동 보안 업데이트
알려진 취약점 방어
최소 권한·서비스 정리
피해 범위 축소
VPN/터널로 접근
관리 포트 비공개
8. 정리
보안은 한 방이 아니라 겹겹이 쌓는 기본기입니다. SSH 키, 방화벽, fail2ban, 자동 업데이트, 최소 권한 — 이 다섯 가지만 해도 자동화된 공격의 대부분을 막습니다. 서버를 새로 올릴 때마다 이 체크리스트를 돌리는 습관을 들이세요. 이 글은 본인 소유 서버의 방어 목적에 한합니다.
LVM(Logical Volume Manager)은 새롭지도, 화려하지도 않습니다. 그런데 운영해보면 오래 살아남은 이유가 보이더라고요. 지난 6개월 동안 홈랩과 소규모 내부 서비스에서 VM 이미지, 컨테이너 볼륨, 로그, 백업 데이터를 나눠 운영하면서 얻은 결론은 단순했습니다. LVM은 스토리지 문제를 자동으로 해결하는 기술이 아니라, 운영자가 디스크 변경을 덜 위험하게 수행하도록 도와주는 계층입니다.
처음에는 저도 “요즘은 ZFS, btrfs, Ceph도 있는데 굳이 이걸?”이라고 생각했습니다. 하지만 단일 Linux 서버에서 디스크를 추가하고, 특정 서비스의 공간만 늘리고, 마운트 경로를 유지하면서 용량 계획을 바꾸는 일은 생각보다 자주 생깁니다. 단순 파티션만 쓰면 재파티셔닝이나 데이터 이동이 부담스럽고, 분산 스토리지는 과한 경우가 많습니다. 이 중간 지점에서 꽤 실용적이었습니다.
이 글은 명령어 모음이 아닙니다. 13년 가까이 서버를 만지면서 느낀 기준으로, 어디까지를 볼륨 관리에 맡기고 어디서부터 파일시스템, 백업, RAID, 모니터링의 문제로 봐야 하는지 정리했습니다. 특히 “LV는 커졌는데 df는 그대로인 상황”, “스냅샷을 백업처럼 오래 들고 있다가 위험해지는 상황”, “iostat 숫자를 어떻게 해석해야 하는지”처럼 실제 운영에서 자주 부딪히는 실패 모드를 중심으로 썼습니다.
홈랩 서버에서 물리 디스크, PV, VG, LV, 파일시스템, 마운트 경로가 어떤 계층으로 연결되는지 한눈에 보는 개요 이미지입니다.
2. 스토리지 관리에서 먼저 잡아야 할 책임 경계
처음 배울 때는 보통 PV, VG, LV 개념부터 외웁니다. 틀린 접근은 아니지만, 운영에서는 용어보다 책임 경계를 먼저 잡는 편이 훨씬 안전했습니다.
PV(Physical Volume)는 LVM에 편입한 실제 디스크나 파티션입니다. VG(Volume Group)는 여러 PV를 묶은 저장소 풀이고, LV(Logical Volume)는 그 풀에서 잘라낸 논리 디스크입니다. 여기에 ext4, XFS 같은 파일시스템을 만들고, 마지막으로 특정 경로에 마운트합니다. 장애 분석은 이 순서를 거꾸로 따라가면 덜 헷갈립니다.
가장 중요한 오해는 이것입니다. LVM은 백업도 아니고, RAID도 아니고, 고가용성 솔루션도 아닙니다. 디스크 하나가 죽었을 때 데이터를 보존하려면 RAID, 복제, 검증된 백업이 필요합니다. 이 선을 넘겨 기대하면 사고가 납니다.
가장 많이 반복한 작업은 새 디스크를 추가하고 기존 데이터 LV를 확장하는 일이었습니다. 아래 예시는 /dev/sdb를 새 디스크로 가정합니다. 실제 서버에서는 장치명이 바뀔 수 있으니, 명령어를 그대로 붙여넣기 전에 반드시 lsblk, blkid, findmnt로 확인해야 합니다. 저는 작업 전후 출력까지 운영 메모에 남깁니다.
# 0) 현재 디스크, 파일시스템, 마운트 상태 확인
lsblk -o NAME,SIZE,TYPE,FSTYPE,MOUNTPOINTS,MODEL
sudo blkid
findmnt -o TARGET,SOURCE,FSTYPE,OPTIONS
# 1) 현재 상태를 작업 로그에 남기기
sudo pvs -o pv_name,vg_name,pv_size,pv_free
sudo vgs -o vg_name,vg_size,vg_free,vg_extent_size
sudo lvs -a -o lv_name,vg_name,lv_size,segtype,devices
# 2) 새 디스크를 PV로 초기화
# 주의: /dev/sdb 안의 기존 데이터는 LVM 메타데이터로 덮일 수 있습니다.
sudo pvcreate /dev/sdb
# 3) 기존 VG에 새 PV 추가
sudo vgextend vg_data /dev/sdb
# 4) LV와 파일시스템을 함께 확장
# -r은 fsadm을 통해 파일시스템 확장까지 시도합니다.
sudo lvextend -r -L +100G /dev/vg_data/lv_app
# 5) 작업 후 계층별로 확인
sudo lvs -a -o lv_name,lv_size,data_percent,metadata_percent,segtype,devices
sudo vgs -o vg_name,vg_size,vg_free
df -hT /srv/app
lvextend -r은 실수를 줄여주는 좋은 옵션입니다. 다만 “항상 알아서 된다”는 뜻은 아닙니다. 파일시스템 종류, 마운트 상태, 관련 도구 설치 여부에 따라 실패할 수 있거든요. 그래서 저는 확장 후 lvs와 df -hT를 꼭 같이 봅니다. 하나는 볼륨 계층, 다른 하나는 서비스가 실제로 체감하는 파일시스템 계층입니다.
새 디스크를 PV로 만들고 VG에 붙인 뒤 LV와 파일시스템을 확장하는 흐름을 단계별로 보여주는 이미지입니다.
4. 이름 규칙은 장애 대응 속도입니다
6개월 동안 가장 크게 체감한 것은 기능 자체보다 명명 규칙과 마운트 규칙의 중요성이었습니다. 급한 상황에서 lv01, data2, newdisk 같은 이름을 보면 손이 멈춥니다. 이 볼륨이 VM용인지, 로그용인지, 백업용인지 바로 알 수 없기 때문입니다.
저는 VG에는 물리적 성격이나 서버 내 역할을, LV에는 서비스 역할을 넣었습니다. 예를 들면 vg_ssd, vg_bulk, lv_vm, lv_log, lv_backup처럼 구분했습니다. SSD와 HDD를 같은 VG에 섞는 것도 가능하지만, 특별한 이유가 없으면 피합니다. 성능 병목을 추적할 때 판단이 흐려지더라고요.
결정 지점
제가 택한 기준
이유
VG 구성
성능 특성이 비슷한 디스크끼리 묶기
SSD/HDD 혼합 풀은 병목 분석과 기대 성능 예측이 어려움
LV 분리
VM, 로그, 백업, 애플리케이션 데이터를 분리
한 서비스의 폭주가 다른 서비스 공간을 잠식하는 일을 줄임
마운트 경로
/srv/vm, /srv/log, /srv/backup처럼 역할 기반 사용
로그와 모니터링 화면에서 의미가 바로 드러남
확장 단위
필요분보다 약간 여유를 두되, VG 전체를 한 번에 소진하지 않기
다음 장애나 임시 스냅샷을 위한 완충 공간이 필요함
5. Linux 성능보다 먼저 확인한 문제: LV는 커졌는데 df는 그대로
한 번은 로그 디렉터리 공간이 꽉 차서 급하게 LV를 늘렸습니다. lvs로 보면 분명히 커졌는데 애플리케이션은 계속 쓰기 오류를 냈습니다. 원인은 단순했습니다. LV 확장만 끝났고 파일시스템 확장이 끝나지 않았던 겁니다. 알고 나면 간단한데, 장애 중에는 이런 기본이 제일 잘 미끄러집니다.
# 문제 상황 진단 루틴
findmnt /srv/app
lsblk -o NAME,SIZE,FSTYPE,MOUNTPOINTS
df -hT /srv/app
sudo lvs -a -o lv_path,lv_size,segtype,devices
sudo vgs -o vg_name,vg_size,vg_free
# ext4라면 디바이스 기준으로 확장
# 온라인 확장이 가능한 상태라면 마운트 중에도 수행할 수 있습니다.
sudo resize2fs /dev/vg_data/lv_app
# XFS라면 마운트 포인트 기준으로 확장
# XFS는 축소를 지원하지 않는다는 점도 용량 설계 때 고려해야 합니다.
sudo xfs_growfs /srv/app
df -hT /srv/app
sudo lvs -o lv_path,lv_size
판단 기준은 명확합니다. lvs의 LV 크기는 늘었는데 df -hT의 파일시스템 크기가 그대로라면 파일시스템 확장이 빠진 것입니다. ext4는 resize2fs, XFS는 xfs_growfs를 확인합니다. 특히 XFS는 확장할 때 디바이스 경로가 아니라 마운트 포인트를 넘긴다는 점이 초반에 헷갈리기 쉽습니다.
여기서 더 중요한 교훈은 XFS의 축소 불가입니다. ext4는 오프라인 축소가 가능하지만, XFS는 일반적으로 축소를 지원하지 않습니다. 그래서 XFS 기반 LV를 크게 잡아버리면 나중에 줄여서 다른 곳에 나누기가 어렵습니다. 로그나 백업처럼 증가 방향이 뚜렷한 데이터에는 XFS가 편했지만, 크기 변경을 자주 실험하는 볼륨에는 더 신중하게 접근했습니다.
6. 성능 최적화: LVM 오버헤드보다 I/O 패턴이 먼저 보였습니다
LVM을 쓰면 성능이 크게 떨어진다는 식의 이야기를 종종 봅니다. 제 운영 경험에서는 그렇게 단순하지 않았습니다. 기본적인 linear LV 구성에서는 볼륨 계층 자체보다 디스크 종류, 파일시스템, 동시 작업, 백업 시간대, VM 이미지 포맷, 로그 쓰기 패턴이 더 자주 병목을 만들었습니다. 물론 thin provisioning, snapshot, RAID 타입 LV를 쓰면 관찰해야 할 지표도 늘어납니다.
성능을 볼 때는 단일 숫자를 절대적인 기준으로 삼지 않았습니다. await, %util, r/s, w/s, aqu-sz를 같이 보고, 애플리케이션 로그의 지연 시점과 맞춰봤습니다. 중요한 건 “평소보다 얼마나 달라졌는가”입니다. 정상 상태 기준선이 없으면 장애 시점의 숫자가 큰지 작은지 판단하기 어렵습니다.
# 디스크별 확장 지표를 1초 간격으로 확인
# await: I/O 요청 평균 대기 시간
# %util: 장치가 바쁘게 처리한 시간 비율
# aqu-sz: 평균 큐 길이
iostat -x 1
# 특정 프로세스가 실제로 I/O를 만드는지 확인
sudo iotop -oPa
# CPU 병목과 I/O 대기 구분
sar -u 1 5
sar -d 1 5
# 메모리 부족으로 swap이 개입하는지 확인
free -h
swapon --show
vmstat 1
# LV가 어느 물리 디스크를 쓰는지 확인
sudo lvs -a -o lv_name,lv_size,segtype,devices
%util이 높다고 바로 디스크 고장이나 볼륨 관리 문제로 단정하지는 않았습니다. 야간 백업, 압축 작업, 로그 로테이션, 컨테이너 이미지 정리 작업이 겹치면 일시적으로 지표가 튈 수 있거든요. 반대로 await가 평소보다 길어지고, 큐가 쌓이고, 애플리케이션 응답 지연이 같은 시간대에 나타나면 I/O 병목 가능성이 높습니다. 이때 lvs -o +devices로 해당 LV가 어느 물리 디스크를 쓰는지 확인하면 원인 범위를 빨리 줄일 수 있습니다.
제가 적용한 최적화는 거창하지 않았습니다. VM 이미지와 백업 데이터를 같은 LV에 몰아넣지 않았고, 대량 백업은 서비스 피크 시간과 분리했습니다. 로그가 많은 서비스는 별도 LV로 빼서 폭주 시 영향 범위를 제한했습니다. SSD와 HDD를 같은 VG에 섞지 않았습니다. 이 네 가지가 튜닝 옵션을 만지는 것보다 체감 효과가 컸습니다.
LVM 용량 상태와 디스크 I/O 지표를 함께 보며 병목을 판단하는 운영 대시보드 예시입니다.
7. Snapshot은 보험이 아니라 짧은 안전핀입니다
LVM snapshot은 패키지 업그레이드나 설정 변경 전에 마음을 편하게 해줍니다. 저도 몇 번 도움을 받았습니다. 하지만 스냅샷을 오래 들고 있는 순간부터 성격이 바뀝니다. 임시 보호 장치가 아니라 운영 리스크가 됩니다.
전통적인 snapshot은 원본 볼륨 변경분을 추적합니다. 변경량이 많아질수록 스냅샷 공간을 더 압박하고, 공간이 부족하면 스냅샷이 무효화될 수 있습니다. 그래서 저는 스냅샷을 “작업 전후 몇 시간 안에 제거할 대상”으로만 봅니다. 장기 보관은 백업 시스템의 일입니다.
# 작업 전 스냅샷 생성
sudo lvcreate -L 20G -s -n lv_app_prechange /dev/vg_data/lv_app
# 스냅샷 상태 확인
# data_percent가 계속 증가하는지 봅니다.
sudo lvs -a -o lv_name,origin,lv_size,data_percent,metadata_percent,lv_attr
# 작업이 성공했고 롤백 필요가 없으면 즉시 제거
sudo lvremove /dev/vg_data/lv_app_prechange
# 롤백이 필요하면 merge 검토
# 대상 LV가 활성 상태이면 다음 활성화 시점이나 재부팅 시점에 병합될 수 있습니다.
sudo lvconvert --merge /dev/vg_data/lv_app_prechange
스냅샷을 쓸 때 제 규칙은 세 가지입니다. 첫째, 생성 전 vgs로 VG 여유 공간을 확인합니다. 둘째, 생성 후 data_percent를 모니터링합니다. 셋째, 작업이 끝나면 바로 삭제합니다. 스냅샷이 있다는 사실이 백업 검증을 대신해주지는 않습니다.
8. Thin Provisioning은 편하지만 감시 없이는 쓰지 않습니다
LVM thin provisioning은 실제 물리 공간보다 큰 논리 볼륨을 미리 만들어두는 방식입니다. VM을 많이 만들거나 개발 환경처럼 사용량이 천천히 늘어나는 곳에서는 매력적입니다. 하지만 공짜는 아닙니다. thin pool의 data 영역이나 metadata 영역이 부족해지면 일반 LV보다 장애 양상이 더 까다로워질 수 있습니다.
저는 홈랩에서 thin LV를 테스트해봤지만, 중요한 데이터에는 보수적으로 접근했습니다. thin을 쓰려면 최소한 data_percent, metadata_percent를 정기적으로 보고, 임계치에 도달하기 전에 알림이 와야 합니다. 모니터링 없이 thin을 쓰는 건 “언젠가 정리하겠지”라는 마음으로 운영하는 셈이라서, 결국 언젠가는 문제가 됩니다.
# thin pool과 thin LV 상태 확인
sudo lvs -a -o lv_name,lv_size,segtype,data_percent,metadata_percent,lv_attr,devices
# thin pool 자동 확장 설정 위치 확인
sudo grep -n 'thin_pool_autoextend' /etc/lvm/lvm.conf
# lvm.conf에서 검토할 대표 파라미터
# thin_pool_autoextend_threshold: 자동 확장을 시작할 사용률 기준
# thin_pool_autoextend_percent: 자동 확장 시 늘릴 비율
# 설정 변경 후에는 배포판의 lvm 서비스 구성과 dmeventd 동작을 함께 확인해야 합니다.
중요한 점은 파라미터 이름을 아는 것보다 운영 조건을 정하는 것입니다. thin pool 자동 확장을 켜더라도 VG에 남은 공간이 없다면 확장할 수 없습니다. 즉, thin provisioning은 공간 계획을 없애는 기술이 아니라 공간 계획을 더 자주 확인해야 하는 기술에 가깝습니다.
9. 운영 회고: 이런 경우엔 쓰고, 이런 경우엔 다른 선택을 봅니다
6개월간 운영하며 세운 기준은 꽤 분명해졌습니다. 단일 서버에서 데이터 파티션을 자주 조정하고, 서비스별로 공간을 분리하고, 디스크 추가가 종종 발생한다면 LVM은 여전히 좋은 선택입니다. 반대로 여러 서버에 걸친 자동 복제, 장애 조치, 데이터 무결성 검증, 스냅샷 기반 장기 보관까지 기대한다면 이것만으로는 부족합니다.
장애나 용량 이슈가 생기면 감으로 명령어를 치기보다 같은 순서로 확인하는 편이 안전했습니다. 아래 루틴은 제가 실제로 자주 쓰는 확인 순서입니다. 핵심은 “서비스 경로에서 시작해서 물리 디스크까지 내려가는 것”입니다.
# 1) 서비스가 쓰는 경로가 어디에 붙어 있는지 확인
findmnt /srv/app
df -hT /srv/app
# 2) 블록 디바이스 계층 확인
lsblk -o NAME,SIZE,TYPE,FSTYPE,MOUNTPOINTS
# 3) LVM 계층 확인
sudo pvs -o pv_name,vg_name,pv_size,pv_free,pv_used
sudo vgs -o vg_name,vg_size,vg_free,lv_count,pv_count
sudo lvs -a -o lv_path,lv_size,segtype,data_percent,metadata_percent,devices
# 4) 커널 로그에서 디스크 오류 확인
sudo dmesg -T | grep -Ei 'error|fail|reset|timeout|I/O'
# 5) I/O 병목 여부 확인
iostat -x 1
sudo iotop -oPa
이 루틴을 정해두면 장애 상황에서 불필요한 추측이 줄어듭니다. 예를 들어 df는 가득 찼는데 vgs에 여유 공간이 있다면 LV 확장으로 해결할 수 있습니다. 반대로 VG 자체가 꽉 찼다면 디스크 추가, 데이터 정리, 백업 이동 중 하나를 선택해야 합니다. dmesg에 I/O 오류가 보인다면 용량 문제가 아니라 물리 디스크나 컨트롤러 문제일 수 있습니다.
11. 자주 묻는 질문
LVM을 쓰면 성능이 많이 떨어지나요?
일반적인 linear LV 구성에서는 LVM 계층 자체보다 디스크 성능, I/O 패턴, 파일시스템, 백업 작업, 애플리케이션 쓰기 방식이 더 크게 체감되는 경우가 많았습니다. 다만 snapshot, thin provisioning, RAID 타입 LV를 쓰면 관리해야 할 지표가 늘어납니다. iostat -x 1, iotop -oPa, lvs -o +devices를 같이 보세요.
운영 중에도 LV 확장이 가능한가요?
가능한 경우가 많습니다. ext4와 XFS는 온라인 확장을 지원하는 대표적인 파일시스템입니다. 다만 축소는 별개 문제입니다. 특히 XFS는 일반적으로 축소를 지원하지 않으므로 처음부터 너무 크게 잡는 결정을 조심해야 합니다. 확장 전에는 장치명, 마운트 경로, 백업 상태를 확인하세요.
LVM snapshot만 있으면 백업은 없어도 되나요?
아니요. 스냅샷은 짧은 작업 보호 장치이고, 백업은 장애 후 복구 전략입니다. 원본 디스크 장애, 실수로 인한 삭제, 장기 보관, 별도 서버 복구까지 생각하면 스냅샷만으로는 부족합니다. 저는 스냅샷을 만들면 제거 예정 시간까지 같이 기록합니다.
SSD와 HDD를 같은 VG에 묶어도 되나요?
기술적으로는 가능합니다. 하지만 저는 특별한 이유가 없으면 분리합니다. 성능 특성이 다른 디스크를 한 VG에 섞으면 특정 LV가 어느 디스크를 쓰는지 계속 확인해야 하고, 병목 원인을 설명하기 어려워집니다. 빠른 저장소와 대용량 저장소는 VG부터 분리하는 편이 운영이 편했습니다.
마무리: 오래됐지만, 기준을 세우면 여전히 강합니다
제 결론은 꽤 실용적인 쪽입니다. 단일 Linux 서버, 홈랩, 소규모 내부 서비스처럼 스토리지 구성이 계속 조금씩 바뀌는 환경이라면 LVM은 아직 충분히 쓸모 있습니다. 특히 서비스별 LV 분리, 경로 유지 확장, 짧은 작업 전 스냅샷, 디스크 추가 대응에서는 단순 파티션보다 운영 부담이 적었습니다.
다만 기대할 것과 기대하지 말 것을 분명히 해야 합니다. LVM은 유연성, 백업은 생존 전략, RAID나 복제는 장애 대응 설계입니다. 저는 작은 서버라면 LVM + 정기 백업 + 용량/I/O 모니터링부터 시작하겠습니다. 여러 서버의 고가용성이 필요해지는 순간에는 LVM 단독 구성을 고집하지 않고 RAID, 원격 복제, 분산 스토리지, 복구 테스트까지 함께 설계하는 쪽을 택하겠습니다.
관련 글로는 Linux 파일시스템 선택 기준, iostat 해석법, 백업 복구 테스트 절차를 함께 연결하면 독자가 다음 단계로 이동하기 좋습니다.
홈랩에 서버가 몇 대만 넘어가도 “하나하나 SSH 접속해서 똑같은 설정” 반복이 지옥이 됩니다. 저는 그래서 Ansible을 씁니다. 제어 노드 한 대에서 여러 서버를 동시에, 일관되게 설정하는 자동화 도구죠. 홈랩에 Ansible 학습 환경을 꾸리고 쓰는 법을 입문자 눈높이로 정리합니다.
1. Ansible이 좋은 이유
에이전트 불필요: 관리 대상에 뭘 설치할 필요 없이 SSH만 되면 됩니다.
멱등성(idempotent): 같은 플레이북을 몇 번 돌려도 결과가 같습니다(이미 된 건 건너뜀).
YAML: 사람이 읽는 선언형 문법이라 진입장벽이 낮습니다.
2. 홈랩 학습 토폴로지
저는 제어 노드 1대 + 관리 대상 여러 대로 학습 랩을 구성했습니다.
역할
설명
제어 노드(control)
Ansible 설치, 여기서 명령 실행
관리 대상(node1~3)
SSH로 제어받는 서버들
Proxmox에서 cloud-init 템플릿으로 노드 몇 대를 찍어내면 학습 환경이 몇 분 만에 완성됩니다.
3. 설치와 인벤토리
# 제어 노드에 설치
sudo apt install -y ansible
# SSH 키를 관리 대상에 배포(비밀번호 없이 접속)
ssh-copy-id user@node1
이 한 번으로 모든 webservers에 nginx가 설치·실행됩니다. 다시 돌려도 “이미 됨”으로 건너뛰는 게 멱등성입니다.
5. 실전에서 자주 쓰는 모듈
모듈
용도
apt/dnf
패키지 관리
copy/template
파일·설정 배포(변수 치환)
service/systemd
서비스 제어
user
계정 관리
lineinfile
설정 파일 한 줄 수정
6. 홈랩에서의 활용
초기 세팅 표준화: 새 VM마다 계정·SSH·방화벽·패키지를 플레이북 하나로.
일괄 업데이트: apt upgrade를 전 서버에 동시에.
설정 드리프트 방지: 플레이북이 곧 “원하는 상태” 문서이자 복구 수단.
7. 정리
Ansible은 인벤토리(누구를) + 플레이북(무엇을), 이 두 가지가 전부입니다. 에이전트 없이 SSH만으로, 멱등하게, 여러 서버를 한 번에 — 홈랩이 2~3대만 넘어가도 체감 효과가 큽니다. cloud-init으로 노드를 찍고 Ansible로 설정하는 조합이면, 서버를 “손으로” 만지는 일이 확 줄어듭니다.
Proxmox는 웹 UI가 훌륭하지만, 반복 작업이나 자동화는 결국 CLI가 답입니다. VM은 qm, 컨테이너는 pct — 이 두 명령만 익히면 클릭 수십 번을 한 줄로 끝낼 수 있습니다. 제가 홈랩을 운영·실습하며 실제로 가장 많이 쓰는 명령을 정리합니다.
1. qm(VM) vs pct(LXC) — 쌍둥이 명령
두 명령은 구조가 거의 같습니다. 대상만 VM이냐 컨테이너냐의 차이죠.
작업
VM (qm)
LXC (pct)
목록
qm list
pct list
시작/정지
qm start/stop ID
pct start/stop ID
설정변경
qm set ID ...
pct set ID ...
설정보기
qm config ID
pct config ID
2. 설정 변경 — 클릭 대신 한 줄
CPU·메모리·디스크를 명령으로 바꿉니다. 실제로 DevStack VM을 세팅할 때 이렇게 했습니다.
# 메모리·코어 변경
qm set 200 --memory 12288 --cores 6
# CPU 타입을 host로 (가상화 기능 노출 — 중첩가상화/명령어셋)
qm set 200 --cpu host
# 디스크 확장(온라인, 무중단)
qm resize 200 scsi0 +37G
# LXC도 동일
pct set 113 --memory 2048 --cores 2
3. 컨테이너 안에서 명령 실행 — pct exec
pct exec는 LXC 내부에 SSH 없이 바로 명령을 넣습니다. 홈랩 자동화의 핵심입니다.
# 컨테이너 113 안에서 명령 실행
pct exec 113 -- bash -lc "docker compose up -d"
# 호스트에서 여러 컨테이너 상태 한 번에
for id in 100 112 113; do echo -n "$id: "; pct status $id; done
# 위험 작업 전 스냅샷
qm snapshot 200 before_test
qm rollback 200 before_test # 되돌리기
# 템플릿에서 새 VM 풀 클론 (cloud-init 템플릿 활용)
qm clone 9000 201 --full --name node1
스냅샷 한 줄이면 몇 초 만에 되돌릴 수 있어, 실습·업그레이드 전에 습관처럼 찍습니다.
5. 원격에서 한 번에 — SSH + pct 조합
저는 작업 PC에서 Proxmox 호스트를 거쳐 컨테이너까지 한 줄로 조작합니다.
# 작업PC → Proxmox 호스트 → LXC 113 내부 명령
ssh root@proxmox-host "pct exec 113 -- bash -lc 'uptime'"
이 패턴으로 여러 호스트·컨테이너를 스크립트로 묶어 자동화할 수 있습니다.
6. 자주 쓰는 조회 명령
pvesm status # 스토리지 용량/상태
qm config 200 | grep -E "cpu|memory|net" # 특정 설정만
pct config 113 | grep features # LXC 기능 플래그
pvesh get /nodes/$(hostname)/status # 노드 상태(API)
7. 정리
qm(VM)·pct(LXC)는 구조가 같아 한 번 익히면 양쪽에 다 씁니다. set으로 설정, exec로 내부 실행, snapshot/clone으로 안전망 — 이 세 가지가 홈랩 자동화의 기본기입니다. 웹 UI로 배우되, 반복이 보이면 CLI로 넘기세요. 그게 홈랩을 “운영”하는 단계로 가는 길입니다.
strace는 애플리케이션이 리눅스 커널에 보낸 요청과 그 결과를 그대로 보여주는 추적 도구입니다. 파일을 열었는지, 소켓 연결을 시도했는지, 권한 때문에 거절됐는지, 어떤 호출에서 기다리고 있는지를 애플리케이션 로그보다 한 단계 아래에서 확인합니다.
제가 strace를 꺼내는 순간은 대체로 비슷합니다. 프로세스는 살아 있고 CPU도 튀지 않는데 응답이 없거나, 로그에는 failed 한 줄만 남았거나, 컨테이너 안에서는 파일이 있다고 믿었는데 실제 프로세스는 다른 경로를 보고 있을 때입니다. 이런 문제는 프레임워크 로그만 붙잡고 있으면 오래 돌아갑니다. 커널 입장에서 보면 대개 ENOENT, EACCES, ECONNREFUSED, ETIMEDOUT, futex 대기 같은 단서로 쪼개집니다.
다만 strace는 만능 관찰기가 아닙니다. 시스템 콜 경계는 잘 보여주지만, 애플리케이션 내부 변수나 비즈니스 로직의 분기까지 알려주지는 않습니다. 그래서 저는 장애 대응 때 순서를 이렇게 잡습니다. 먼저 애플리케이션 로그와 메트릭으로 증상을 좁히고, 파일·권한·네트워크·프로세스 대기처럼 운영체제 경계가 의심될 때 strace를 붙입니다. 이 순서를 지키면 출력의 바다에서 헤매는 시간이 확 줄어듭니다.
strace는 사용자 공간(User Space)의 애플리케이션과 커널(Kernel) 사이에서 오가는 시스템 콜 흐름을 추적합니다. 그래서 “내 코드가 뭘 하려고 했는가”보다 “커널에 실제로 어떤 요청이 도착했는가”를 확인하는 데 강합니다.
strace 개념: 시스템 콜을 로그처럼 읽는 법
리눅스 애플리케이션은 파일, 네트워크, 프로세스, 시간, 메모리 같은 자원을 직접 만지지 않습니다. openat(), read(), write(), connect(), statx(), clone(), execve(), futex() 같은 시스템 콜을 통해 커널에 요청합니다. strace는 그 요청의 인자와 반환값을 보여줍니다.
출력 한 줄은 보통 아래처럼 읽습니다.
openat(AT_FDCWD, "/etc/myapp/config.yml", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
왼쪽은 호출 이름과 인자, 오른쪽은 반환값입니다. = -1은 실패, ENOENT는 파일이 없다는 뜻입니다. 이 한 줄만으로도 “설정 로딩 실패”가 코드 문제인지, 배포 경로 문제인지, 마운트 문제인지 조사 방향이 달라집니다.
증상
먼저 볼 시스템 콜
해석 기준
다음 액션
설정 파일을 못 읽음
openat, newfstatat, access
ENOENT면 경로·마운트, EACCES면 권한·보안 정책
pwdx PID, systemd WorkingDirectory, 컨테이너 볼륨 확인
외부 API 연결 실패
socket, connect, getsockopt
ECONNREFUSED는 대상 포트 거부, ETIMEDOUT은 경로·방화벽 가능성
ss -tnp, 라우팅, 보안 그룹, 프록시 설정 확인
프로세스가 멈춘 듯 보임
read, poll, epoll_wait, futex
I/O 대기인지 이벤트 대기인지 락 대기인지 분리
top -H, 스레드 덤프, FD 상태 같이 확인
자식 프로세스에서만 실패
clone, fork, execve
부모만 추적하면 핵심 흐름이 안 보일 수 있음
-f 또는 -ff로 PID별 로그 분리
라이브러리 로딩 실패
openat, mmap, execve
.so 탐색 경로가 예상과 다른지 확인
LD_LIBRARY_PATH, ldconfig -p, 컨테이너 이미지 확인
실전 구현: 기본 명령어보다 필터링이 먼저입니다
설치는 간단합니다. 운영 서버에 새 패키지를 설치해야 한다면 변경 절차를 따라야 하지만, 대부분의 배포판에서는 표준 패키지로 제공합니다.
# Debian/Ubuntu 계열
sudo apt update
sudo apt install -y strace
# RHEL/CentOS/Fedora 계열
sudo dnf install -y strace
# 설치 확인
strace -V
가장 단순한 실행은 명령 앞에 strace를 붙이는 방식입니다.
strace ls /tmp
하지만 실무에서는 이렇게 전체를 보는 일이 많지 않습니다. 출력이 너무 많고, 동적 라이브러리 로딩이나 로케일 파일 접근처럼 지금 문제와 무관한 줄이 섞입니다. 처음부터 범위를 좁히는 편이 낫습니다.
# 파일 관련 시스템 콜만 추적
strace -e trace=file ls /etc/nginx
# 네트워크 관련 시스템 콜만 추적
strace -e trace=network curl -I https://example.com
# 프로세스 실행 흐름 확인
strace -e trace=process bash -lc 'echo hello'
# 시간 정보와 각 호출 소요 시간 표시
strace -tt -T -e trace=file ls /etc
# 실패한 시스템 콜만 보고 싶을 때
strace -e trace=file -e status=failed ls /does-not-exist
-e trace=file은 파일 관련 호출 그룹만 표시합니다. -e trace=network는 소켓과 연결 흐름을 좁혀 보여줍니다. -tt는 시각을 마이크로초 단위까지 자세히 표시하고, -T는 각 시스템 콜에 걸린 시간을 꺾쇠괄호로 붙입니다. -e status=failed는 실패한 호출만 추려서 볼 때 유용합니다. strace 버전이나 배포판에 따라 지원 옵션이 다를 수 있으니, 현장 서버에서는 strace -h로 한 번 확인하는 습관이 좋습니다.
운영 환경에서는 전체 추적보다 trace=file, trace=network, status=failed처럼 질문을 좁히는 방식이 훨씬 빠릅니다.
이미 실행 중인 프로세스에 붙어서 Linux 디버깅하기
실제 장애에서는 새 명령을 실행하는 것보다 이미 떠 있는 프로세스를 봐야 할 때가 많습니다. 이때는 -p로 PID에 붙습니다.
# PID 확인
pgrep -af 'nginx|gunicorn|java|node'
# 실행 중인 프로세스에 연결
sudo strace -p 12345
# 자식 프로세스까지 따라가며 파일에 저장
sudo strace -f -tt -T -s 256 -o /tmp/app.strace.log -p 12345
# PID별로 로그 파일을 나누고 싶을 때
sudo strace -ff -tt -T -s 256 -o /tmp/app.strace -p 12345
-f는 fork, clone, vfork로 생기는 자식 프로세스까지 추적합니다. 웹 서버, 워커, 큐 컨슈머, CGI 계열처럼 실행 흐름이 자식 프로세스로 넘어가는 구조에서는 거의 필수입니다. -ff는 PID별로 로그를 분리합니다. 한 파일에 모든 프로세스 로그가 섞이면 시간순으로 따라가기는 쉽지만, 특정 워커만 분석할 때는 분리 로그가 더 편합니다.
-s 256은 문자열 출력 길이를 늘립니다. 기본 출력 길이로는 긴 파일 경로나 HTTP 헤더 일부가 잘려서 원인을 놓칠 수 있습니다. 분석용이면 -s 256 또는 -s 1024 정도로 늘리고, 민감정보가 섞일 수 있는 환경에서는 저장 위치와 공유 범위를 조심해야 합니다. strace 로그에는 파일 경로, 환경 변수 일부, 소켓 주소, 토큰처럼 보안상 민감한 값이 드러날 수 있습니다.
운영 서버에 붙일 때는 짧게, 좁게, 파일로 남기는 쪽을 권합니다. strace는 ptrace 기반으로 대상 프로세스를 관찰하므로 오버헤드가 생길 수 있습니다. 특히 초당 시스템 콜이 많은 프로세스에 전체 추적을 오래 걸면 지연이 커질 수 있습니다. 수치를 단정할 수는 없지만, 장애 중인 서비스에 무심코 전체 추적을 오래 붙이는 건 피하는 편이 안전합니다.
재현 가능한 시나리오 1: 설정 파일을 못 찾는 애플리케이션 분석
먼저 가장 흔한 파일 경로 문제를 작게 재현해보겠습니다. 일부러 없는 설정 파일을 열고, strace에서 실제 접근 경로와 에러 코드를 확인합니다.
# app.py
from pathlib import Path
config_path = Path("/etc/myapp/config.yml")
print(config_path.read_text())
python3 app.py
# 파일 관련 시스템 콜만 추적
strace -e trace=file -s 256 python3 app.py
출력에서 이런 줄을 찾습니다.
openat(AT_FDCWD, "/etc/myapp/config.yml", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
openat: 파일을 열려고 했습니다.
"/etc/myapp/config.yml": 애플리케이션이 실제로 접근한 경로입니다.
O_RDONLY: 읽기 전용으로 열려고 했습니다.
-1 ENOENT: 호출이 실패했고, 커널은 파일이 없다고 답했습니다.
여기서 중요한 건 “설정 파일이 없다”가 아니라 “해당 프로세스의 파일 시스템 네임스페이스에서 그 경로가 없다”입니다. 호스트에는 파일이 있어도 컨테이너 안에는 없을 수 있고, systemd 서비스의 WorkingDirectory가 달라 상대 경로가 다르게 해석될 수 있습니다. Kubernetes라면 ConfigMap/Secret 마운트 경로와 컨테이너 이미지를 같이 봐야 합니다.
EACCES라면 방향이 바뀝니다. 파일 존재 여부보다 소유자, 그룹, 모드, 디렉터리 실행 권한, SELinux/AppArmor 정책을 봐야 합니다. 디렉터리 중간 경로에 실행 권한이 없어도 파일 접근은 실패합니다.
# 파일과 상위 디렉터리 권한을 함께 확인
namei -l /etc/myapp/config.yml
# systemd 서비스의 작업 디렉터리와 실행 사용자 확인
systemctl cat myapp.service
systemctl show myapp.service -p User -p Group -p WorkingDirectory
재현 가능한 시나리오 2: 연결 거부와 타임아웃을 구분하기
네트워크 장애에서 strace가 빛나는 지점은 connect()의 반환값입니다. “안 붙는다”는 말은 너무 넓습니다. 대상이 즉시 거부하는지, 네트워크 경로에서 시간이 빠지는지, DNS 이전 단계인지에 따라 담당 영역이 달라집니다.
# 로컬에서 열려 있지 않은 포트에 연결 시도
strace -tt -T -e trace=network curl -v --connect-timeout 3 http://127.0.0.1:9/
# DNS 해석까지 포함해 파일/네트워크 흐름을 함께 확인
strace -tt -T -e trace=file,network -s 256 curl -v --connect-timeout 3 https://example.com/
ECONNREFUSED는 대상 호스트까지 도달했지만 해당 포트가 거부했다는 쪽에 가깝습니다. 서비스가 안 떠 있거나, 다른 포트에 떠 있거나, 로컬 방화벽이 즉시 거부하는 식입니다. 반대로 ETIMEDOUT은 응답이 돌아오지 않는 흐름이라 라우팅, 보안 그룹, 방화벽 드롭, 네트워크 ACL을 의심합니다. 둘을 구분하지 않고 “네트워크 문제”라고 뭉개면 담당자도, 조사 순서도 흐려집니다.
futex는 멀티스레드 애플리케이션에서 흔합니다. 많이 보인다는 사실만으로 장애라고 판단하면 안 됩니다. 중요한 건 맥락입니다. 요청 처리가 멈춘 상태에서 특정 스레드가 계속 futex 대기에 머물고, CPU 사용률은 낮고, 처리량이 떨어졌다면 락 경합이나 데드락 가능성을 봅니다. 이때 strace만으로 결론을 내리지 말고 스레드 단위 관찰을 같이 해야 합니다.
# 스레드별 CPU/상태 확인
top -H -p 12345
# 프로세스의 스레드 목록 확인
ps -L -p 12345 -o pid,tid,stat,comm
# Java라면 스레드 덤프와 함께 비교
jstack 12345 > /tmp/jstack.12345.txt
컨테이너에서는 strace가 안 붙는 경우
컨테이너 안에서 strace를 쓰려면 패키지가 없거나, ptrace 권한이 막혀 있거나, seccomp 프로파일 때문에 제한될 수 있습니다. 운영 정책이 허용한다면 디버그 컨테이너나 임시 권한 부여를 사용합니다.
# Docker에서 재현 환경을 만들 때의 예시
# 운영에 그대로 적용하기 전에 보안 정책을 반드시 확인하세요.
docker run --rm -it --cap-add SYS_PTRACE --security-opt seccomp=unconfined ubuntu:latest bash
Kubernetes에서는 노드 접근, ephemeral container, 보안 컨텍스트, 배포 조직의 운영 기준을 같이 봐야 합니다. 여기서 중요한 판단은 “운영 파드에 도구를 설치할지”가 아니라 “동일 증상을 낮은 위험으로 관찰할 방법이 있는지”입니다.
검증과 결과 해석: 에러 코드, 반복, 대기 시간을 분리해서 봅니다
strace 로그를 받을 때 저는 세 갈래로 읽습니다. 첫째, 실패 코드를 봅니다. 둘째, 같은 호출이 반복되는지 봅니다. 셋째, -T 기준으로 특정 호출이 오래 걸리는지 봅니다.
실패 코드: ENOENT, EACCES, EPERM, ECONNREFUSED, ETIMEDOUT, EROFS 같은 반환값을 우선 확인합니다.
반복 패턴: 같은 경로, 같은 포트, 같은 FD에 대한 호출이 짧은 간격으로 반복되는지 봅니다.
대기 지점: -T 출력에서 connect, read, poll, epoll_wait, futex 뒤에 시간이 길게 붙는지 봅니다.
파일 문제는 openat()의 경로와 반환값이 거의 출발점입니다. ENOENT면 경로, 마운트, 작업 디렉터리, 배포 산출물을 봅니다. EACCES면 권한, 상위 디렉터리 실행 권한, SELinux/AppArmor, 컨테이너 사용자 UID를 봅니다. EROFS가 보이면 읽기 전용 파일 시스템이나 컨테이너 마운트 옵션 쪽입니다.
네트워크 문제는 connect() 반환값으로 먼저 나눕니다. ECONNREFUSED는 상대가 거부한 상황에 가깝고, ETIMEDOUT은 응답이 돌아오지 않는 상황에 가깝습니다. DNS 문제는 connect() 이전의 /etc/resolv.conf, /etc/hosts, NSS 관련 파일 접근 흐름에서 힌트가 나올 수 있습니다.
# strace 로그에서 자주 보는 실패만 빠르게 훑기
grep -E 'ENOENT|EACCES|EPERM|ECONNREFUSED|ETIMEDOUT|EROFS' /tmp/app.strace.log | head -100
# 특정 설정 파일 접근 여부 확인
grep '/etc/myapp/config.yml' /tmp/app.strace.log
# 오래 걸린 호출 후보를 눈으로 보기 쉽게 추리기
grep -E '<[0-9]+\.[0-9]+>' /tmp/app.strace.log | head -50
해석은 감이 아니라 분류입니다. 에러 코드로 범주를 나누고, 반복 패턴으로 재현성을 보고, 대기 시간으로 병목 후보를 좁히면 strace 로그가 훨씬 덜 거칠게 느껴집니다.
언제 strace를 쓰고, 언제 다른 도구를 먼저 써야 할까
strace는 강력하지만 모든 문제의 첫 번째 도구는 아닙니다. 시스템 콜 경계의 증거가 필요할 때 가장 좋고, 애플리케이션 내부 상태나 장기 성능 분석이 필요할 때는 다른 도구가 더 맞습니다.
상황
추천 도구
이유
파일 경로·권한·라이브러리 탐색이 의심됨
strace
실제 접근 경로와 커널 반환값을 바로 확인 가능
어떤 포트로 연결하는지, 거부인지 타임아웃인지 확인
strace + ss
호출 결과와 소켓 상태를 함께 확인
열린 파일과 소켓 목록이 궁금함
lsof, ss
추적보다 현재 상태 스냅샷이 빠름
CPU 병목이나 함수별 비용 분석
perf, 언어별 profiler
strace는 사용자 공간 함수 비용을 설명하지 못함
n
메모리 누수·GC·힙 상태 분석
런타임별 도구
시스템 콜 로그만으로는 힙 구조를 알 수 없음
락 경합·데드락 의심
strace + 스레드 덤프
futex 대기만으로는 원인 스레드를 특정하기 어려움
제가 쓰는 기준은 단순합니다. “커널에 무엇을 요청했는지”가 질문이면 strace가 맞습니다. “코드 내부에서 왜 그 요청을 했는지”가 질문이면 로그, 디버거, 프로파일러, 스레드 덤프가 필요합니다.
자주 묻는 질문
strace를 운영 서버에서 써도 괜찮나요?
가능은 하지만 짧게 쓰는 쪽을 권합니다. -e trace=...로 범위를 줄이고, -o로 파일에 저장하고, 필요한 순간에만 붙이세요. 초당 시스템 콜이 많은 프로세스에 전체 추적을 오래 거는 방식은 피하는 편이 안전합니다.
애플리케이션 로그와 strace 중 무엇을 먼저 봐야 하나요?
대부분은 애플리케이션 로그가 먼저입니다. 로그에서 파일, 권한, 네트워크, 외부 프로세스 실행, 대기 상태가 의심될 때 strace로 내려가면 좋습니다. 처음부터 strace를 보면 단서보다 소음이 많을 수 있습니다.
컨테이너에서도 쓸 수 있나요?
쓸 수 있습니다. 다만 컨테이너 이미지에 strace가 없을 수 있고, SYS_PTRACE capability, seccomp, AppArmor, Kubernetes 보안 정책에 막힐 수 있습니다. 운영 파드에 직접 설치하기보다 디버그 컨테이너나 재현 환경을 먼저 고려하세요.
strace 로그에 민감정보가 남나요?
남을 수 있습니다. 파일 경로, 실행 인자, 소켓 주소, 일부 문자열 버퍼가 출력될 수 있습니다. -s 값을 크게 잡을수록 더 많은 문자열이 보입니다. 공유 전에는 토큰, 인증 헤더, 고객 데이터가 섞였는지 확인해야 합니다.
마무리: 장애 유형별로 이렇게 꺼내면 됩니다
strace는 “리눅스에서 애플리케이션이 실제로 무엇을 요청했는가”를 확인하는 도구입니다. 로그가 애매할 때, 커널의 반환값을 보면 문제가 갑자기 작아지는 순간이 있습니다.
파일 경로나 권한이 의심되면strace -e trace=file -s 256로 시작하세요. 네트워크 연결 문제가 의심되면strace -tt -T -e trace=network로 connect() 반환값을 보세요. 실행 중인 서비스가 멈춘 듯 보이면sudo strace -f -tt -T -s 256 -o /tmp/app.strace.log -p PID 조합이 출발점으로 좋습니다. 자식 프로세스가 많으면-ff로 PID별 로그를 분리하세요.
반대로 CPU 병목, 메모리 누수, 애플리케이션 내부 락 원인까지 strace 하나로 끝내려 하면 돌아갑니다. 그때는 perf, lsof, ss, 스레드 덤프, 언어별 프로파일러와 함께 봐야 합니다. 실무에서 중요한 건 도구 이름이 아니라 관찰 순서입니다. strace는 그 순서에서 “운영체제는 뭐라고 답했나”를 확인하는 가장 직접적인 렌즈입니다.
strace는 로그가 말해주지 않는 커널 레벨의 단서를 보여주는 실무형 디버깅 도구입니다. 짧게 붙이고, 질문을 좁히고, 반환값으로 다음 조사를 결정하세요.
OpenStack을 공부하다 보면 결국 openstack 명령어와 친해져야 합니다. Horizon(웹 대시보드)도 좋지만, 실무·자동화는 CLI가 기본이거든요. DevStack 실습에서 실제로 쓴 명령들을 바탕으로, 입문자가 꼭 알아야 할 openstack CLI를 정리합니다.
1. 인증부터 — openrc
모든 명령은 인증 토큰이 필요합니다. DevStack은 openrc 스크립트를 주는데, 이걸 source하면 환경변수로 로그인 정보가 들어갑니다.
# 관리자(admin) 자격으로 환경 설정
source /opt/stack/devstack/openrc admin admin
# 토큰 확인(로그인 됐나)
openstack token issue -f value -c id | head -c 20; echo
자원(server·network·image·flavor·subnet…)만 바꾸면 되니, list/create/show/delete 네 동작으로 대부분을 합니다.
3. 상태 점검 3종 세트
클라우드가 정상인지 볼 때 제가 가장 먼저 치는 명령들입니다.
# 카탈로그에 서비스가 다 떴나
openstack service list
# 컴퓨트 노드(하이퍼바이저)가 살아있나
openstack hypervisor list
# 컴퓨트 서비스 상태(up/down)
openstack compute service list
실제로 DevStack 디버깅 때 hypervisor list가 비어 있어서 “컴퓨트 미등록”을 바로 알아챘습니다. CLI가 문제를 가장 빨리 보여줍니다.
4. 인스턴스 하나 띄우는 전체 흐름
이미지·플레이버·네트워크를 조합해 VM을 만듭니다.
# 재료 확인
openstack image list # OS 이미지
openstack flavor list # 사양(vCPU/RAM/디스크)
openstack network list # 네트워크
# 인스턴스 생성 (이미지+플레이버+네트워크)
openstack server create myvm \
--image cirros --flavor m1.nano --network testnet --wait
# 결과 확인
openstack server list
openstack console log show myvm # 부팅 로그(진짜 떴나)
--wait는 생성이 끝날 때까지 기다려 줍니다. 실패하면 openstack server show myvm -f value -c fault로 원인을 봅니다(저는 이걸로 “No valid host”를 확인했습니다).
5. 출력 다루기 — 자동화의 시작
CLI의 진짜 힘은 출력을 가공할 수 있다는 점입니다.
# 특정 값만 뽑기 (스크립트에 유용)
NET_ID=$(openstack network create testnet -f value -c id)
# 표 형식 / JSON 형식
openstack server list -f table
openstack server list -f json
-f value -c <컬럼>으로 ID만 뽑아 변수에 담으면, 그대로 쉘 스크립트 자동화로 이어집니다.
6. 정리
openstack CLI는 ①openrc로 인증 → ②자원 동작 패턴 → ③-f value -c로 값 추출 이 세 가지만 잡으면 끝입니다. 웹 대시보드로 감을 잡되, 반복·자동화는 CLI로 가세요. 클라우드 엔지니어의 실력은 결국 이 명령어들이 손에 붙는 데서 나옵니다.
APT에서 Flatpak으로 옮긴다는 표현은 조금 위험합니다. Debian, Ubuntu 계열에서 APT는 여전히 운영체제 패키지 관리의 기준축입니다. 커널, systemd, OpenSSH, 네트워크 도구, 드라이버, 서버 데몬, 보안 업데이트 흐름은 배포판 저장소 정책 위에서 돌아갑니다. Flatpak은 이 자리를 대체하기보다, 데스크톱 애플리케이션을 배포판 릴리스 주기에서 분리하는 선택지에 가깝습니다.
제가 13년 정도 Linux 서버와 데스크톱을 같이 운영하면서 얻은 기준은 단순합니다. 시스템을 구성하는 패키지는 APT, 사용자가 실행하는 독립형 GUI 앱은 Flatpak 후보로 봅니다. 이 기준을 세우면 “무엇을 옮길지”보다 “무엇을 절대 옮기지 말아야 할지”가 먼저 보입니다. 실제 마이그레이션에서 사고를 줄이는 건 과감한 전환이 아니라 경계 설정이더라고요.
무작정 “기존 앱을 전부 Flatpak으로 바꾸자”로 가면 생각보다 빨리 꼬입니다. 같은 앱을 배포판 패키지와 Flatpak으로 동시에 설치하면 설정 경로, 실행 파일, MIME 연결, 포털 권한, 자동 실행 항목이 서로 다른 층에서 움직입니다. 사용자는 같은 아이콘을 눌렀다고 생각하지만 실제로는 다른 패키징 채널의 앱이 실행될 수 있습니다. 이때 “설정이 사라졌다”가 아니라 다른 설정 디렉터리를 보고 있는 것인 경우가 많습니다.
APT는 운영체제와 서비스 계층, Flatpak은 사용자 앱 계층으로 나뉘는 구조를 보여주는 다이어그램이 잘 맞습니다.
APT와 Flatpak의 차이는 설치 방식보다 운영 책임입니다
APT는 배포판 저장소의 패키지를 시스템 경로에 설치하고, 의존성까지 배포판 기준으로 맞춥니다. 패키지는 대체로 /usr/bin, /usr/lib, /etc, /var 같은 경로와 강하게 연결됩니다. 운영 입장에서는 이 점이 꽤 든든합니다. 보안 업데이트, 서비스 재시작, 설정 파일 관리, 로그 위치가 배포판 관례를 따르거든요.
Flatpak은 앱과 런타임을 별도로 관리하고, 앱을 샌드박스 안에서 실행합니다. 사용자 설정은 대체로 ~/.var/app/앱ID/ 아래에 쌓입니다. 앱은 flatpak run 앱ID 형태로 실행하며, 파일 접근은 Flatpak 권한과 데스크톱 포털(xdg-desktop-portal)의 영향을 받습니다. 그래서 Flatpak은 “최신 GUI 앱을 깔기 쉬운 도구”이면서 동시에 “파일 접근과 시스템 통합을 명시적으로 다뤄야 하는 도구”입니다.
이 표에서 핵심은 “Flatpak이 더 좋다”가 아닙니다. Flatpak은 앱 경계를 명확하게 만들지만, 그만큼 경계 밖 리소스를 쓰려면 권한을 열어야 합니다. 반대로 배포판 패키지는 시스템과 자연스럽게 붙지만, 앱별 격리나 배포판 버전 독립성은 약합니다. 도구의 우열보다 책임 범위가 다릅니다.
Linux 마이그레이션 전에는 설치 목록보다 출처를 먼저 확인하세요
제가 현장에서 제일 먼저 보는 건 패키지 이름이 아니라 어느 채널에서 설치됐는지입니다. 같은 Firefox, 같은 GIMP라도 배포판 패키지, Snap, Flatpak, 수동 압축 해제본이 섞여 있으면 문제를 재현하기 어렵습니다. 특히 Ubuntu 계열은 일부 데스크톱 앱이 apt 명령으로 설치되는 것처럼 보여도 실제로는 다른 패키징 채널로 연결되는 경우가 있어 실행 경로 확인이 중요합니다.
# 현재 APT 설치 상태를 파일로 남깁니다.
apt list --installed > apt-installed.txt
apt-mark showmanual > apt-manual.txt
# Flatpak 앱과 런타임을 분리해서 확인합니다.
flatpak list --app > flatpak-apps.txt 2>/dev/null || true
flatpak list --runtime > flatpak-runtimes.txt 2>/dev/null || true
# 특정 앱의 APT 출처와 버전 후보를 봅니다.
apt policy gimp
apt-cache show gimp | sed -n '1,80p'
# 실행 경로와 데스크톱 런처를 확인합니다.
command -v gimp
which -a gimp
ls /usr/share/applications | grep -i gimp || true
ls ~/.local/share/applications | grep -i gimp || true
ls /var/lib/flatpak/exports/share/applications | grep -i gimp 2>/dev/null || true
ls ~/.local/share/flatpak/exports/share/applications | grep -i gimp 2>/dev/null || true
apt policy에서 Installed는 현재 설치된 버전, Candidate는 저장소 기준으로 설치 또는 업그레이드될 후보입니다. Candidate: (none)에 가깝거나 배포판 저장소의 앱이 업무에 필요한 기능보다 늦게 따라온다면 Flatpak 전환 후보로 표시합니다. 다만 후보가 오래됐다는 이유만으로 서버 도구까지 옮기면 안 됩니다. 서버 도구는 최신 기능보다 재현성과 배포판 보안 흐름이 더 중요한 경우가 많습니다.
실행 경로도 꼭 봐야 합니다. 터미널에서 command -v gimp가 /usr/bin/gimp를 가리키는데 런처는 Flatpak 데스크톱 파일을 가리키는 상황이 생길 수 있습니다. 이러면 터미널에서 실행한 앱과 메뉴에서 실행한 앱이 서로 다른 설정을 씁니다. 버그처럼 보이지만 실제 원인은 런처와 PATH의 불일치입니다.
Flatpak 설치와 Flathub remote는 시스템 단위와 사용자 단위를 구분하세요
Flatpak 자체는 보통 배포판 패키지 관리자로 설치합니다. 여기서 이미 역할 분리가 시작됩니다. 기반 도구는 배포판 패키지로 받고, GUI 앱 배포 채널만 Flatpak remote로 분리하는 방식입니다. 데스크톱 한 대만 쓰면 별 차이가 없어 보이지만, 가족 PC, 홈랩 워크스테이션, 공용 장비처럼 사용자가 여러 명이면 설치 범위가 중요해집니다.
# Debian/Ubuntu 계열에서 Flatpak 기반 도구 설치
sudo apt update
sudo apt install flatpak
# 시스템 전체에 Flathub remote 추가
sudo flatpak remote-add --if-not-exists flathub https://flathub.org/repo/flathub.flatpakrepo
# 현재 등록된 remote와 설치 범위 확인
flatpak remotes --show-details
flatpak remotes --user --show-details
flatpak remotes --system --show-details
# 앱 목록 확인
flatpak list --app
flatpak list --app --columns=application,name,version,branch,installation
sudo flatpak remote-add는 시스템 설치 범위에 remote를 추가합니다. 반대로 사용자 단위로만 쓰고 싶다면 flatpak remote-add --user --if-not-exists flathub https://flathub.org/repo/flathub.flatpakrepo 형태를 씁니다. 개인 노트북이라면 둘 중 하나로 통일하는 편이 낫습니다. 같은 remote가 사용자 범위와 시스템 범위에 동시에 들어가면 나중에 앱이 어디에 설치됐는지 헷갈립니다.
설치 위치도 달라집니다. 시스템 범위 Flatpak은 보통 /var/lib/flatpak 아래에 있고, 사용자 범위 설치는 ~/.local/share/flatpak 아래에 있습니다. 백업이나 디스크 정리를 할 때 이 차이가 바로 영향을 줍니다. 용량이 부족한 데스크톱이라면 앱뿐 아니라 런타임도 같이 쌓인다는 점을 염두에 두셔야 합니다. 정확한 용량은 설치한 앱과 런타임에 따라 달라지므로, 추측하지 말고 아래처럼 직접 확인하는 게 좋습니다.
# Flatpak 설치 공간 확인
sudo du -sh /var/lib/flatpak 2>/dev/null || true
du -sh ~/.local/share/flatpak 2>/dev/null || true
# 사용하지 않는 런타임 정리 후보 확인 및 제거
flatpak uninstall --unused
# Flatpak 앱, 런타임, 설치 범위를 함께 확인
flatpak list --columns=application,name,type,branch,installation
Flathub remote, 런타임, 앱, 사용자/시스템 설치 범위가 어떻게 이어지는지 보여주는 구성도가 있으면 좋습니다.
APT 앱을 Flatpak으로 옮기는 절차: 한 번에 하나씩, 되돌릴 수 있게
실전에서는 앱 하나를 골라 전환하고 하루 정도 써본 뒤 다음 앱으로 넘어가는 방식이 안전합니다. GIMP 같은 GUI 앱은 좋은 시험 대상입니다. 시스템 서비스가 아니고, 파일 접근 권한 문제가 드러나기 쉽고, 설정 디렉터리 차이도 확인하기 좋기 때문입니다. 이거 진짜 번거로워 보여도, 나중에 문제를 좁히는 데 큰 도움이 됩니다.
배포판 패키지 설치 여부, 버전, 실행 경로, 데스크톱 파일을 확인합니다.
기존 설정 디렉터리를 백업합니다. 바로 삭제하지 않습니다.
Flatpak 앱 ID를 확인하고 설치합니다.
실행, 파일 열기, 저장, 플러그인, 기본 앱 연결을 테스트합니다.
문제가 없으면 기존 패키지를 제거하되, 설정 purge는 며칠 뒤에 판단합니다.
# 1. APT 상태 확인
apt policy gimp
command -v gimp
which -a gimp
# 2. 기존 사용자 설정 백업 예시
mkdir -p ~/migration-backup/gimp
cp -a ~/.config/GIMP ~/migration-backup/gimp/ 2>/dev/null || true
cp -a ~/.gimp-* ~/migration-backup/gimp/ 2>/dev/null || true
# 3. Flatpak 앱 검색 및 설치
flatpak search gimp
flatpak install flathub org.gimp.GIMP
# 4. 실행 및 정보 확인
flatpak run org.gimp.GIMP
flatpak info org.gimp.GIMP
flatpak info --show-permissions org.gimp.GIMP
# 5. APT 패키지 제거. 마이그레이션 직후에는 purge보다 remove를 권합니다.
sudo apt remove gimp
sudo apt autoremove
flatpak search에서는 이름보다 Application ID를 확인해야 합니다. org.gimp.GIMP 같은 ID가 이후 실행, 권한 확인, 제거, override, 업데이트에서 계속 쓰입니다. 이름은 사람이 읽는 라벨이고, 운영할 때 필요한 키는 앱 ID입니다.
sudo apt remove는 시스템 패키지를 제거하지만 사용자 홈 디렉터리 설정은 대체로 남깁니다. sudo apt purge는 패키지의 시스템 설정까지 제거하는 데 쓰지만, 사용자 홈 아래 설정까지 항상 정리해주는 만능 청소 도구는 아닙니다. 저는 마이그레이션 당일에는 purge를 피합니다. 되돌릴 일이 생겼을 때 기존 설정이 남아 있으면 복구가 훨씬 빠릅니다.
설정 이전은 앱마다 다릅니다. 기존 설정을 Flatpak 경로로 그대로 복사하면 될 때도 있지만, 버전 차이나 플러그인 경로 차이 때문에 오히려 문제를 만들 수 있습니다. 특히 IDE, 브라우저, 그래픽 도구는 “설정 폴더 전체 복사”보다 내보내기/가져오기 기능을 우선 쓰는 편이 낫습니다.
가장 자주 본 실패 모드: 파일이 안 보이는 건 권한 모델 차이입니다
Flatpak 전환 후 가장 흔한 문제는 “파일이 안 보인다”입니다. 배포판 패키지로 설치한 앱은 홈 디렉터리를 자연스럽게 읽는 경우가 많지만, Flatpak 앱은 샌드박스와 포털을 거칩니다. 그래서 다운로드 폴더는 보이는데 ~/projects, 외장 디스크, NAS 마운트, 숨김 디렉터리는 안 보이는 상황이 생깁니다. 근본 원인은 앱 버그가 아니라 파일시스템 권한이 앱에 부여되지 않았거나, 포털 파일 선택기를 통해 전달된 파일만 접근 가능한 상태인 경우가 많습니다.
# 현재 권한 확인
flatpak info --show-permissions org.gimp.GIMP
# 현재 적용된 사용자 override 확인
flatpak override --user --show org.gimp.GIMP
# 특정 프로젝트 디렉터리만 읽기/쓰기 허용
flatpak override --user --filesystem="$HOME/projects" org.gimp.GIMP
# 읽기 전용으로만 허용하고 싶을 때
flatpak override --user --filesystem="$HOME/reference:ro" org.gimp.GIMP
# 홈 전체 접근을 허용하는 예시. 편하지만 격리 이점은 줄어듭니다.
flatpak override --user --filesystem=home org.gimp.GIMP
# override 초기화
flatpak override --user --reset org.gimp.GIMP
권한을 줄 때는 넓게 열기 전에 좁게 열어보는 편이 좋습니다. 이미지 편집 앱이 ~/projects/design만 필요하다면 해당 디렉터리만 허용합니다. 문서 편집기처럼 여러 작업 폴더를 오가야 한다면 xdg-documents, 특정 마운트 경로, 또는 홈 접근을 검토합니다. 다만 메신저, 뷰어, 단순 유틸리티에 홈 전체 권한을 주는 건 Flatpak을 쓰는 이유를 스스로 줄이는 선택입니다.
개발 도구는 더 까다롭습니다. Flatpak IDE가 프로젝트는 보지만 시스템의 /usr/bin/python, Docker 소켓, SDK 경로, SSH agent, GPG agent를 기대대로 못 볼 수 있습니다. 이 경우 Flatpak이 나쁘다기보다 개발 환경 자체가 호스트 시스템과 강하게 결합돼 있기 때문입니다. IDE를 Flatpak으로 옮길 때는 “편집만 하는가, 빌드와 디버깅까지 하는가”를 기준으로 판단하세요. 빌드, 컨테이너, 디바이스 접근이 많다면 배포판 패키지, 공식 tarball, 또는 전용 툴박스 환경이 더 안정적일 수 있습니다.
전환 후 검증: 실행되는지보다 어느 쪽이 실행되는지 보세요
마이그레이션 검증은 앱이 켜지는 순간 끝나지 않습니다. 실제로 문제는 그 다음에 옵니다. 파일 더블클릭은 기존 앱으로 열리고, 메뉴 런처는 Flatpak을 띄우고, 터미널에서는 예전 바이너리가 실행되는 식입니다. 사용자는 같은 앱을 쓴다고 느끼지만, 시스템은 서로 다른 실행 단위를 다루고 있습니다.
# Flatpak 앱 목록과 설치 범위
flatpak list --app --columns=application,name,version,branch,installation
# Flatpak 업데이트
flatpak update
# APT 쪽 동일 패키지 잔존 여부
apt list --installed 2>/dev/null | grep -i '^gimp/' || true
apt policy gimp
# 실행 경로 확인
command -v gimp || true
which -a gimp || true
# 데스크톱 파일 중복 확인
find /usr/share/applications ~/.local/share/applications /var/lib/flatpak/exports/share/applications ~/.local/share/flatpak/exports/share/applications \
-iname '*gimp*.desktop' 2>/dev/null -print
# MIME 연결 확인 예시
xdg-mime query default image/png
xdg-mime query default image/jpeg
flatpak list --app에 앱이 있고 flatpak run 앱ID로 정상 실행되면 Flatpak 설치는 된 겁니다. 하지만 apt list --installed에도 같은 앱이 남아 있으면 중복 설치 상태입니다. 이 자체가 항상 장애는 아니지만, 기본 앱 연결과 런처가 섞이면 사용성이 나빠집니다. 장기 운영에서는 하나로 정리하는 편이 낫습니다.
업데이트 루틴도 분리해야 합니다. sudo apt upgrade는 APT 패키지를 갱신하고, flatpak update는 Flatpak 앱과 런타임을 갱신합니다. 둘 중 하나만 자동화하면 절반만 관리하는 셈입니다. 저는 데스크톱 장비에서는 주기적으로 둘 다 실행하고, 오래 안 쓰는 런타임은 flatpak uninstall --unused로 정리합니다.
APT 잔존 패키지, Flatpak 앱 목록, MIME 연결, 업데이트 상태를 한 화면에서 점검하는 대시보드형 이미지가 어울립니다.
APT와 Flatpak을 같이 쓸 때의 패키지 관리 전략
저는 데스크톱 Linux를 운영할 때 패키지를 세 부류로 나눕니다. 첫째, OS와 서비스에 붙은 패키지는 배포판 기본 관리 체계에 남깁니다. 둘째, 독립형 GUI 앱은 Flatpak 후보로 둡니다. 셋째, 개발 도구와 브라우저처럼 시스템 연동이 많은 앱은 테스트 후 결정합니다. 이 셋을 구분하지 않으면 패키지 관리가 취향 싸움처럼 흐릅니다.
현실적인 운영 예시는 이렇습니다. Ubuntu 데스크톱에서 SSH, Git, 빌드 도구, Docker 엔진은 APT로 유지합니다. GIMP, Inkscape, VLC, 일부 메신저는 Flatpak으로 둡니다. VS Code나 JetBrains IDE처럼 프로젝트 빌드와 컨테이너 연동이 많은 도구는 Flatpak으로 먼저 시험 설치한 뒤, 터미널 통합과 SDK 탐지가 불편하면 배포판 저장소나 공식 패키지로 돌아갑니다. 이 접근이 지저분해 보일 수 있지만, 실제 운영에서는 훨씬 덜 고장 납니다.
자동화할 때는 두 세계를 분리해서 써야 합니다. APT는 apt-mark showmanual과 패키지 목록으로 관리하고, Flatpak은 앱 ID 목록으로 관리합니다. 아래처럼 간단한 목록 파일을 만들면 새 장비 세팅이 편해집니다. 관련 글을 운영한다면 “Ubuntu 초기 세팅 체크리스트”나 “Linux 백업 전략” 같은 내부 링크로 이어주기 좋습니다.
# flatpak-apps.txt 예시
org.gimp.GIMP
org.inkscape.Inkscape
org.videolan.VLC
# 목록 파일 기반 설치
while read -r app; do
[ -z "$app" ] && continue
flatpak install -y flathub "$app"
done < flatpak-apps.txt
# 현재 설치된 Flatpak 앱 ID만 추출
flatpak list --app --columns=application > flatpak-apps-current.txt
자주 묻는 질문
Flatpak으로 바꾸면 APT는 안 써도 되나요?
아닙니다. Debian/Ubuntu 계열에서는 APT가 시스템 패키지 관리의 중심입니다. Flatpak은 주로 데스크톱 GUI 앱을 배포판 릴리스 주기와 분리해 관리하기 위한 보조 축으로 보는 게 맞습니다.
같은 앱을 APT와 Flatpak으로 같이 설치해도 되나요?
짧은 테스트 기간에는 괜찮습니다. 다만 장기간 유지하는 건 추천하지 않습니다. 실행 경로, 설정 디렉터리, 파일 연결, 런처 항목이 섞이면 문제를 추적하기 어려워집니다. 테스트가 끝나면 한쪽으로 정리하세요.
Flatpak 앱이 느리거나 무겁다고 봐야 하나요?
앱과 런타임 구성에 따라 다르므로 일반화하면 안 됩니다. 다만 런타임이 별도로 설치되고 업데이트되기 때문에 디스크 사용량과 업데이트 대상이 늘 수 있습니다. 실제 판단은 du -sh /var/lib/flatpak ~/.local/share/flatpak, flatpak list --runtime으로 확인하는 게 정확합니다.
마이그레이션 순서는 어떻게 잡는 게 좋나요?
시스템 핵심 패키지가 아닌 독립형 GUI 앱부터 시작하세요. 앱별로 설치, 실행, 파일 열기/저장, 권한, 기본 앱 연결, 업데이트를 확인한 뒤 다음 앱으로 넘어가는 방식이 안전합니다.
권한 관리는 CLI만 써야 하나요?
아닙니다. CLI에서는 flatpak info --show-permissions와 flatpak override를 쓰고, GUI로는 Flatseal 같은 도구를 쓸 수 있습니다. 다만 자동화나 문서화가 필요하면 CLI 명령을 남겨두는 편이 재현성이 좋습니다.
제가 권하는 최종 기준
서버 운영, 시스템 구성, 드라이버, 입력기, 네트워크 도구, 서비스 데몬은 APT를 유지하세요. 이 영역은 배포판의 보안 업데이트와 서비스 관리 흐름을 타는 편이 안정적입니다. 반대로 그래픽 편집기, 미디어 플레이어, 메신저, 독립형 데스크톱 앱은 Flatpak으로 먼저 테스트할 가치가 있습니다. 최신 버전과 앱별 격리의 이점이 실제 사용성으로 이어질 가능성이 큽니다.
브라우저와 개발 IDE는 중간 지대입니다. 브라우저는 인증서, 패스키, 외부 앱 호출, 다운로드 경로를 확인해야 합니다. IDE는 프로젝트 디렉터리, SDK, Docker, SSH/GPG agent, 터미널 통합까지 봐야 합니다. 이 항목에서 문제가 생기면 Flatpak을 고집하지 말고 배포판 패키지나 공식 패키지로 남기는 게 더 실용적입니다.
제가 쓰는 한 줄 기준은 이렇습니다. 운영체제와 서비스는 APT, 독립형 데스크톱 앱은 Flatpak, 호스트와 깊게 엮인 개발 도구는 별도 검증. 이 기준만 잡아도 “설치했는데 왜 설정이 없지?”, “왜 터미널과 런처 결과가 다르지?”, “왜 프로젝트 폴더가 안 보이지?” 같은 시간을 꽤 줄일 수 있습니다.
서버 패키지, GUI 앱, 브라우저, 개발 도구별로 APT와 Flatpak 선택 기준을 나눈 인포그래픽이 마무리에 잘 맞습니다.
마이그레이션은 도구 교체가 아니라 운영 모델 변경입니다. APT는 시스템의 기준선을 안정적으로 잡고, Flatpak은 사용자 앱 레이어를 더 유연하게 만듭니다. 둘을 섞어 쓰는 것이 타협처럼 보일 수 있지만, Linux 데스크톱을 오래 굴려보면 그게 가장 덜 피곤한 전략인 경우가 많습니다.
지난 편까지 DevStack을 홈랩에 올리며 CPU·Neutron·Glance·Placement에서 연달아 부딪히고 하나씩 해결했습니다. 이번 편은 그 여정의 솔직한 후기와 교훈입니다. 결과를 미화하지 않고, 홈랩에서 DevStack에 도전할 분께 실질적인 지도를 남기려 합니다.
1. 어디까지 됐고, 무엇이 남았나
정직하게 말하면 “완벽한 원클릭 성공”은 아니었습니다.
✅ 코어 서비스 전부 기동(Keystone·Glance·Nova·Neutron·Cinder·Placement)
✅ geneve 테넌트 네트워크 생성 성공, 하이퍼바이저 등록, 이미지 업로드, 플레이버 확인
❌ 인스턴스 최종 부팅은 placement 자원 클래스 누락으로 막힘 — 여러 번의 부분 설치가 누적돼 생긴 불일치가 근본 원인
즉 OpenStack의 뼈대는 다 세웠지만, 마지막 조립이 어긋난 상태였습니다. 그리고 그 어긋남의 원인까지 정확히 짚었다는 게 이 도전의 진짜 소득입니다.
2. 가장 큰 교훈 — “깨끗한 상태에서 한 번에”
이번 삽질의 뿌리는 하나였습니다: 중간에 실패한 설치 위에 계속 재시도한 것. DevStack은 실행 때마다 여러 서비스의 DB를 다시 만들고 마무리 단계를 수행하는데, 앞 단계에서 죽으면 뒷 단계가 통째로 생략됩니다. 그 위에 또 돌리면 서로 다른 실행의 잔재가 뒤섞여 새로운 증상이 끝없이 나옵니다.
다음엔 실패하면 미련 없이 ./clean.sh로 초기화하고, 모든 수정을 local.conf에 미리 반영한 뒤 깨끗한 상태에서 한 번에 완주시키겠습니다.
3. 홈랩 DevStack 체크리스트 (다음 도전용)
항목
이유
OS는 Ubuntu (22.04/24.04)
DevStack 공식 지원
VM CPU 타입 = host
x86-64-v2 미노출 시 NumPy 크래시
RAM 12GB+ / 디스크 40GB+
올인원 최소선
local.conf에 geneve 명시
테넌트 네트워크 할당 실패 방지
실패 시 clean.sh 후 재시작
부분 설치 누적 방지(가장 중요)
완주 후에도 서비스 재시작 점검
엔드포인트/동기화 지연 대응
4. DevStack에 대한 현실 감각
DevStack은 “개발/학습용”입니다. 운영용이 아니고, 재부팅하면 상태가 깨지기도 합니다. 공부하고 부수고 다시 까는 용도로 쓰세요.
무겁습니다. 올인원도 12~16GB를 먹고, 설치에 수십 분이 걸립니다. 홈랩에선 “쓸 때만 켜는 랩”이 현실적입니다.
그럼에도 배움은 큽니다. 이 과정에서 CPU 가상화(x86-64-v2), Neutron의 geneve, placement의 자원 모델, 서비스 간 의존성을 에러를 통해 몸으로 익혔습니다. 매끄러운 성공보다 이 삽질에서 더 많이 배웠습니다.
5. 마치며
“튜토리얼대로 했는데 왜 안 되지?”는 홈랩의 일상입니다. 이번 DevStack 도전도 7번 넘게 깨졌지만, 각 실패의 원인을 파고드는 과정 자체가 클라우드 인프라를 이해하는 가장 빠른 길이었습니다. 다음엔 clean.sh 원샷으로 완주시키고, 실제 인스턴스를 띄워 SSH로 접속하는 순간까지 이어가는 후속편으로 돌아오겠습니다. 홈랩에서 프라이빗 클라우드에 도전하는 분들, 깨져도 그게 정상입니다. 원인을 하나씩 잡으면 됩니다.
지난 편에서 CPU 함정을 넘었습니다. 하지만 그건 시작이었습니다. DevStack이 완주할 때까지 Neutron → Glance → Nova/Placement에서 연달아 막혔거든요. 이번 편은 그 실제 에러들과 원인, 그리고 관통하는 하나의 패턴을 정리합니다. 같은 벽을 만난 분께 지도가 되길 바랍니다.
벽 2. 테넌트 네트워크 생성 실패 (503)
다시 돌리자 이번엔 네트워크 생성에서 죽었습니다.
HttpException: 503: No project network is available for allocation.
서비스·네트워크·이미지가 다 됐는데 인스턴스가 ERROR. 이유는 “No valid host was found”. 하이퍼바이저는 up인데 왜? nova-compute 로그가 진짜 원인을 보여줬습니다.
400 Bad Request: Unknown resource class in inventory ...
No such resource class MEMORY_MB.
즉 placement DB에 표준 자원 클래스(MEMORY_MB·VCPU·DISK_GB)가 로드되지 않아서, nova-compute가 자원 인벤토리를 placement에 등록하지 못했습니다. 인벤토리가 없으니 스케줄러가 “쓸 수 있는 호스트 없음”으로 판단한 거죠.
관통하는 하나의 패턴
벽 3·4·5를 보면 공통점이 보입니다.
서비스 프로세스는 떠 있는데, 그 뒤에 와야 할 “초기화·동기화·등록”이 안 끝나 있다.
geneve 풀 동기화, glance 엔드포인트, placement 자원 클래스 — 전부 stack.sh가 끝까지 완주하며 해줬어야 할 마무리 단계입니다. 제 경우 stack.sh가 중간에 여러 번 죽으면서 이 마무리들이 제각각 미완성으로 남았고, 그래서 재시도할 때마다 “부분적으로만 살아있는” 상태가 겹쳐 새 증상이 계속 튀어나온 겁니다.
여기서 배운 교훈: DevStack은 “깨끗한 상태에서 한 번에 완주”가 생명입니다. 중간 실패 후 그 위에 계속 재시도하면, 서로 다른 실행의 잔재가 섞여 디버깅이 미궁에 빠집니다. 다음 편에서 이 교훈과 현실적인 후기를 정리하겠습니다.
Proxmox ZFS 스냅샷을 제대로 쓰면 패치 실패, 설정 실수, 배포 사고에서 돌아오는 시간이 확 줄어듭니다. 이거 진짜 편하더라고요. 다만 스냅샷을 백업처럼 믿는 순간 위험해집니다. 같은 ZFS 풀 안에 있는 스냅샷은 디스크 장애, 풀 손상, 관리자 계정 탈취, 랜섬웨어가 root 권한을 잡은 상황에서는 같이 위험해질 수 있습니다.
운영 기준은 단순하게 잡는 편이 좋습니다. 스냅샷은 빠른 롤백용, 복제는 장애 대응 시간 단축용, 백업은 생존용입니다. 이 셋을 섞어서 생각하면 정책이 애매해지고, 장애가 났을 때 ‘이 데이터가 어디까지 살아 있지?’부터 다시 헤매게 됩니다.
예를 들어 VM 100번에서 패키지 업데이트를 하기 전이라면 Proxmox VM 스냅샷이 가장 빠릅니다. 파일 서버 데이터셋이라면 ZFS 스냅샷과 원격 zfs send/zfs receive가 더 어울립니다. 장기 보관, 삭제 사고, 법적 보존, 랜섬웨어 대응까지 생각한다면 Proxmox Backup Server(PBS)나 별도 백업 저장소가 필요합니다.
Proxmox 노드, ZFS 풀, 로컬 스냅샷, 원격 복제 서버가 어떻게 이어지는지 보여주는 전체 구조도입니다.
2. 스냅샷, 복제, 백업의 책임 경계부터 정하세요
도구부터 고르면 대개 과하게 복잡해집니다. 먼저 장애 유형을 놓고 어떤 보호 계층이 맡을지 정해야 합니다. 이 기준이 잡혀 있으면 나중에 복구 리허설을 할 때도 훨씬 덜 흔들립니다.
상황
우선 선택
쓰면 좋은 이유
쓰지 말아야 할 때
패키지 업데이트, 설정 변경, 방화벽 룰 수정
Proxmox VM 스냅샷
롤백이 빠르고 UI/CLI에서 상태 확인이 쉽습니다.
며칠 이상 오래 보관할 목적이면 부적합합니다.
파일 서버에서 실수 삭제를 되돌리고 싶음
ZFS 데이터셋 스냅샷
파일 단위 복구 흐름을 만들기 좋습니다.
풀 자체 장애까지 커버한다고 보면 안 됩니다.
다른 Proxmox 노드에서 빠르게 VM을 다시 띄우고 싶음
Proxmox 내장 Replication
클러스터 안에서 RTO를 줄이는 데 실용적입니다.
장기 백업, 오프사이트 보관, 랜섬웨어 대응의 대체재는 아닙니다.
ZFS 데이터셋을 다른 서버에 보관하고 싶음
zfs send/zfs receive
스냅샷 단위로 증분 전송할 수 있습니다.
수신 대상 관리와 공통 스냅샷 보존 정책이 없으면 쉽게 꼬입니다.
삭제, 암호화 사고, 장기 보관까지 대비
PBS 또는 별도 백업 저장소
보관 정책, 검증, 격리를 설계하기 좋습니다.
즉시 롤백만 필요한 작업 전 보호에는 과할 수 있습니다.
현장에서 쓰기 좋은 결론은 이렇습니다. 작업 전에는 VM 스냅샷, 매일 데이터셋은 ZFS 스냅샷, 중요 데이터는 원격 복제, 최종 생존선은 별도 백업으로 나눕니다. 한 도구에 모든 책임을 몰아주지 않는 게 핵심입니다.
3. 사전 점검: 풀 상태가 나쁘면 스냅샷도 좋은 답이 아닙니다
스냅샷이나 복제 전에 풀 건강부터 봐야 합니다. 복제가 실패했는데 원인을 따라가 보면 네트워크나 SSH가 아니라 원본 풀의 checksum error인 경우도 있습니다. 복제는 원본 상태를 마법처럼 고쳐주지 않습니다. 나쁜 블록과 꼬인 상태도 운영 이슈로 그대로 따라옵니다.
# 1) ZFS 풀 상태와 오류 카운터 확인
zpool status -v
# 2) 풀 용량과 조각화 경향 확인
zpool list -o name,size,alloc,free,cap,frag,health
# 3) 데이터셋, zvol, 마운트 지점 확인
zfs list -o name,type,used,avail,refer,usedbysnapshots,mountpoint
# 4) 스냅샷 목록을 생성일 기준으로 확인
zfs list -t snapshot -o name,creation,used,refer -s creation
# 5) Proxmox VM 디스크 매핑 확인
qm config 100
pvesm status
zpool status에서 봐야 할 것은 state: ONLINE 하나가 아닙니다. READ, WRITE, CKSUM 카운터가 증가하는지, scan 결과에 unrepaired error가 있는지, 특정 디스크만 반복해서 오류를 내는지까지 봐야 합니다. 오류가 보이면 스냅샷 정책보다 디스크 교체, 케이블 확인, scrub 결과 분석이 먼저입니다.
용량도 중요합니다. ZFS는 여유 공간이 너무 낮아지면 성능과 운영 안정성이 같이 나빠집니다. 여기서 임의의 만능 퍼센트를 외우기보다, cap이 계속 올라가고 오래된 스냅샷의 usedbysnapshots가 크게 잡힌다면 보관 정책을 바로 손봐야 합니다.
4. Proxmox ZFS 스냅샷: 작업 전에는 빠르게 만들고 빠르게 지우기
운영에서 가장 많이 쓰는 패턴은 ‘작업 직전 스냅샷’입니다. 스냅샷 이름에는 목적과 날짜를 넣는 편이 좋습니다. 장애 상황에서는 멋진 네이밍보다 pre-upgrade-2026-09-30처럼 바로 읽히는 이름이 이깁니다.
4-1. VM 단위 스냅샷: Proxmox가 디스크와 메타데이터를 같이 관리하게 하기
# VM 100번에 작업 전 스냅샷 생성: 메모리 상태는 저장하지 않음
qm snapshot 100 pre-upgrade-2026-09-30 --description 'before package upgrade' --vmstate 0
# 스냅샷 트리 확인
qm listsnapshot 100
# 문제가 있으면 해당 스냅샷으로 롤백
qm rollback 100 pre-upgrade-2026-09-30
# 검증이 끝난 뒤 불필요한 스냅샷 삭제
qm delsnapshot 100 pre-upgrade-2026-09-30
--vmstate 0은 메모리 상태를 포함하지 않습니다. 대부분의 패키지 업데이트, 설정 파일 변경, 서비스 재시작 전에는 이 편이 부담이 적습니다. 반대로 실행 중인 애플리케이션 상태까지 그대로 붙잡아야 하는 테스트라면 --vmstate 1을 고려할 수 있지만, 스냅샷 생성 시간과 저장 공간 부담이 커질 수 있습니다.
DB 서버라면 한 가지를 더 봐야 합니다. VM 스냅샷은 스토리지 관점의 시점 보존에 가깝습니다. 애플리케이션 일관성이 필요하면 게스트 안에서 DB flush, backup lock, 애플리케이션 자체 덤프, qemu-guest-agent 기반 freeze/thaw 같은 절차를 같이 설계해야 합니다. ‘스냅샷이 있으니 DB도 무조건 깨끗하다’는 가정은 위험합니다.
4-2. ZFS 레벨 스냅샷: 데이터셋 정책을 직접 통제할 때
# 단일 zvol 스냅샷
zfs snapshot rpool/data/vm-100-disk-0@pre-change-2026-09-30
# 하위 데이터셋까지 같은 이름으로 재귀 스냅샷 생성
zfs snapshot -r tank/projects@daily-2026-09-30
# 스냅샷별 공간 점유 확인
zfs list -t snapshot -o name,used,refer,creation -s creation
# 삭제 전 대상 목록만 먼저 확인
zfs list -t snapshot -r tank/projects
# 불필요한 스냅샷 삭제
zfs destroy tank/projects@daily-2026-09-30
ZFS 레벨에서 직접 찍은 스냅샷은 Proxmox UI의 VM 스냅샷과 운영 경험이 다릅니다. 특히 VM 디스크가 zvol이면 파일처럼 열어서 복원하는 흐름이 아닙니다. VM 전체 롤백은 Proxmox 스냅샷이 낫고, 파일 서버나 애플리케이션 데이터셋처럼 ZFS 계층을 직접 다루는 대상은 ZFS 스냅샷이 낫습니다.
작업 전 스냅샷 생성, 변경 적용, 검증, 롤백 여부 판단 흐름을 보여주는 운영 절차 이미지입니다.
5. 보관 정책: 많이 만드는 것보다 제때 지우는 게 어렵습니다
스냅샷이 공간을 거의 안 쓴다는 말은 반만 맞습니다. 생성 직후에는 작아 보이지만, 원본 데이터가 바뀌면 오래된 스냅샷이 예전 블록을 계속 붙잡습니다. 파일을 지웠는데 용량이 안 돌아오는 대표 원인이 이겁니다.
기본 보관 구조는 운영 성격별로 달라야 합니다. 자주 바뀌는 VM 디스크는 짧게, 파일 서버는 조금 길게, 장기 보관은 스냅샷이 아니라 백업 정책으로 넘깁니다. 그래야 ZFS 백업과 스냅샷이 서로 역할을 침범하지 않습니다.
대상
스냅샷 주기
보관 감각
주의점
패치 전 VM
작업 직전 수동
검증 후 즉시 삭제
남겨두면 VM 디스크 변경분이 계속 누적됩니다.
파일 서버 데이터셋
일 단위 또는 업무 주기 기준
삭제 사고를 발견할 수 있는 기간만
사용자가 큰 파일을 자주 바꾸면 스냅샷 사용량이 빠르게 늘 수 있습니다.
DB 데이터셋
애플리케이션 일관성 절차와 함께
복구 리허설로 검증한 기간만
스토리지 스냅샷만으로 논리적 복구를 대체하지 마세요.
장기 보존 데이터
백업 정책에서 관리
PBS, 오프사이트, 불변 백업 등으로 분리
로컬 스냅샷을 장기 보관소로 쓰면 풀 용량 관리가 어려워집니다.
간단한 환경에서는 아래처럼 이름 규칙을 고정해두는 것만으로도 사고가 줄어듭니다. 자동 삭제는 편하지만, 처음부터 과감하게 지우는 스크립트를 돌리지 말고 목록 출력부터 검증하세요. 작은 습관인데 나중에 정말 큰 차이를 만듭니다.
# 예시: tank/projects에 날짜 기반 스냅샷 생성
SNAP_NAME='daily-'$(date +%F)
zfs snapshot -r tank/projects@${SNAP_NAME}
# 스냅샷 공간 점유 상위 항목 확인
zfs list -t snapshot -o name,used,creation -s used | tail -n 20
# 특정 접두어의 스냅샷만 확인
zfs list -H -t snapshot -o name -r tank/projects | grep '@daily-'
6. 원격 ZFS 복제: send/receive는 공통 스냅샷이 생명입니다
ZFS 백업을 ZFS답게 만들고 싶다면 zfs send/zfs receive를 이해해야 합니다. 최초에는 전체 스트림을 보내고, 이후에는 양쪽에 공통으로 남아 있는 스냅샷을 기준으로 증분을 보냅니다. 실패의 절반은 이 공통 기준 스냅샷을 지워서 생깁니다.
# 원본 서버: 최초 기준 스냅샷 생성
zfs snapshot -r tank/projects@base-2026-09-30
# 백업 서버: 수신 부모 데이터셋 준비
ssh backup-server 'zfs create -p backup/replica'
# 최초 전체 전송: -R은 하위 데이터셋과 스냅샷 관계를 함께 보냄
zfs send -R tank/projects@base-2026-09-30 | ssh backup-server 'zfs receive -u backup/replica/projects'
# 다음 스냅샷 생성
zfs snapshot -r tank/projects@inc-2026-09-30
# 증분 전송: 양쪽에 base 스냅샷이 있어야 함
zfs send -R -i tank/projects@base-2026-09-30 tank/projects@inc-2026-09-30 | ssh backup-server 'zfs receive -u backup/replica/projects'
# 원본/대상 스냅샷 비교
zfs list -H -t snapshot -o name -r tank/projects
ssh backup-server 'zfs list -H -t snapshot -o name -r backup/replica/projects'
-R은 복제 스트림을 만들 때 유용합니다. 하위 데이터셋, 스냅샷 관계, 일부 속성을 함께 다루기 때문입니다. -i는 지정한 이전 스냅샷 이후 변경분만 보냅니다. 중간 스냅샷까지 포함한 증분 체인을 보내야 하는 상황에서는 -I가 더 적합할 수 있습니다. 수신 쪽의 -u는 receive 후 자동 마운트를 막아 백업 서버의 경로가 의도치 않게 올라오는 사고를 줄입니다.
복제본에는 가능하면 사람이 쓰지 못하게 하세요. 수신 대상 데이터셋이 수정되면 다음 증분 receive가 실패할 수 있습니다. 백업 서버에서 복제 루트를 읽기 전용으로 두고, 복구 테스트가 필요할 때는 clone이나 별도 restore 위치를 쓰는 흐름이 안전합니다.
# 백업 서버: 복제본을 읽기 전용으로 설정
ssh backup-server 'zfs set readonly=on backup/replica/projects'
# 읽기 전용 속성 확인
ssh backup-server 'zfs get readonly backup/replica/projects'
# 복구 테스트용 클론 생성 예시
ssh backup-server 'zfs clone backup/replica/projects@inc-2026-09-30 backup/restore-test/projects-2026-09-30'
# 테스트 후 클론 제거
ssh backup-server 'zfs destroy backup/restore-test/projects-2026-09-30'
7. Proxmox 내장 Replication: 빠른 재가동용이지 장기 백업은 아닙니다
Proxmox의 ZFS 기반 Replication은 클러스터 노드 간 VM 디스크를 주기적으로 복제하는 기능입니다. 장점은 Proxmox가 VM 단위로 작업을 관리해준다는 점입니다. 한계도 분명합니다. 일반적으로 같은 클러스터 안의 다른 노드가 대상이고, 스토리지 구성과 VM 배치 정책의 영향을 많이 받습니다.
# VM 100의 복제 작업을 pve2 노드 대상으로 생성
# 작업 ID 100-0은 예시이며, 실제 환경에서는 기존 작업 ID와 충돌하지 않게 확인합니다.
pvesr create-local-job 100-0 pve2 --schedule '*/15' --rate 50
# 복제 작업 목록과 상태 확인
pvesr list
pvesr status
# 작업 중지/재개
pvesr disable 100-0
pvesr enable 100-0
# 스케줄 변경 예시
pvesr update 100-0 --schedule '*/30'
--schedule은 반복 주기를 정합니다. */15는 15분 간격 예시입니다. --rate는 복제 대역폭을 제한할 때 씁니다. 운영 시간대에 복제가 스토리지와 네트워크를 압박한다면 제한을 거는 편이 낫습니다. 다만 제한을 너무 낮게 잡으면 변경량을 따라가지 못해 다음 주기까지 밀릴 수 있습니다.
Proxmox Replication에서 자주 보는 실패 원인은 세 가지입니다. 첫째, 대상 노드에 같은 스토리지 ID의 ZFS 스토리지가 없거나 VM 디스크가 복제 가능한 ZFS 스토리지에 있지 않은 경우입니다. 둘째, 이전 스냅샷이나 작업 상태가 꼬여 공통 기준을 못 찾는 경우입니다. 셋째, 네트워크, SSH, 노드 상태 문제로 작업이 중간에 끊기는 경우입니다. 이때는 pvesr status만 보지 말고 Proxmox task log와 양쪽 노드의 zfs list -t snapshot을 같이 봐야 합니다.
8. 흔한 실패 모드와 근본 원인
장애 대응 문서는 ‘명령어 모음’보다 ‘왜 실패했는지’를 빠르게 좁혀주는 쪽이 더 쓸모 있습니다. 아래 표는 실제 점검 때 우선순위로 보기 좋은 항목입니다.
증상
가능한 근본 원인
확인 명령
권장 대응
파일을 지웠는데 풀 용량이 안 줄어듦
오래된 스냅샷이 삭제 전 블록을 계속 참조
zfs list -o name,usedbysnapshots
보관 정책을 확인하고 불필요한 스냅샷부터 정리합니다.
증분 send가 실패함
원본 또는 대상에서 기준 스냅샷 삭제
zfs list -t snapshot
남아 있는 공통 스냅샷부터 다시 증분하거나 새 기준으로 전체 전송합니다.
receive 대상이 수정되었다는 오류
백업 서버 복제본에 직접 쓰기 발생
zfs get readonly
복제본은 readonly로 두고 테스트는 clone에서 합니다.
VM 스냅샷 후 앱 데이터가 이상함
게스트 내부 애플리케이션 일관성 절차 부재
DB 로그, qemu-guest-agent 상태
DB dump, freeze/thaw, 앱별 백업 절차를 병행합니다.
Proxmox Replication이 반복 실패
스토리지 ID 불일치, 대상 노드 ZFS 미구성, 이전 작업 상태 꼬임
pvesm status, pvesr status
스토리지 구성을 맞추고 task log에서 정확한 실패 지점을 확인합니다.
재현 가능한 시나리오: 기준 스냅샷을 지운 뒤 증분 복제가 깨지는 경우
# 원본에서 기준 스냅샷을 실수로 삭제한 상황
zfs destroy tank/projects@base-2026-09-30
# 이후 이 명령은 기준 스냅샷을 찾지 못해 실패합니다.
zfs send -R -i tank/projects@base-2026-09-30 tank/projects@inc-2026-09-30 | ssh backup-server 'zfs receive -u backup/replica/projects'
# 양쪽에 남아 있는 공통 스냅샷 확인
zfs list -H -t snapshot -o name -r tank/projects
ssh backup-server 'zfs list -H -t snapshot -o name -r backup/replica/projects'
이 상황에서 zfs receive -F를 습관처럼 붙이는 건 조심해야 합니다. -F는 대상 쪽 상태를 송신 스트림에 맞추기 위해 롤백 성격의 동작을 할 수 있습니다. 대상에만 있던 스냅샷이나 변경을 잃을 수 있으니, 적용 전에는 대상 서버의 스냅샷 목록과 필요한 복구 지점을 반드시 확인해야 합니다.
9. 검증 체크리스트: 성공 메시지보다 복구 가능성이 중요합니다
Proxmox ZFS 스냅샷과 복제는 생성보다 검증이 더 중요합니다. ‘명령어가 0으로 끝났다’와 ‘장애 때 복구할 수 있다’는 다른 이야기입니다. 복구 리허설을 한 번 해보면 빈틈이 생각보다 빨리 드러납니다.
zpool status -v에서 풀 상태와 오류 카운터를 확인합니다.
zfs list -t snapshot으로 원본과 대상의 스냅샷 이름이 맞는지 비교합니다.
zfs list -o usedbysnapshots로 오래된 스냅샷이 공간을 붙잡고 있는지 봅니다.
zfs get readonly로 백업 복제본이 쓰기 방지되어 있는지 확인합니다.
테스트 데이터셋을 clone하거나 별도 위치에 receive해서 실제 파일을 열어봅니다.
VM이라면 qm config로 디스크 매핑을 확인하고 테스트 부팅 절차를 문서화합니다.
Proxmox Replication은 pvesr status와 task log를 함께 봅니다.
# 원본 상태 점검
zpool status -v
zfs list -o name,used,avail,refer,usedbysnapshots -r tank/projects
# 원본 스냅샷 확인
zfs list -t snapshot -o name,creation,used,refer -r tank/projects
# 백업 서버 스냅샷 확인
ssh backup-server 'zfs list -t snapshot -o name,creation,used,refer -r backup/replica/projects'
# 복제본 읽기 전용 여부 확인
ssh backup-server 'zfs get readonly backup/replica/projects'
# Proxmox 복제 상태 확인
pvesr status
원본과 백업 서버의 스냅샷 목록, 풀 상태, 복제 상태를 한눈에 점검하는 대시보드 느낌의 이미지입니다.
10. ZFS 베스트 프랙티스: 성능과 안정성을 가르는 결정 포인트
ZFS 스냅샷 자체는 보통 빠르게 만들어지지만, 운영 비용은 뒤에서 발생합니다. 변경이 많은 VM 디스크에 스냅샷을 오래 붙잡아두면 쓰기 패턴, 공간 회수, 복제량에 영향을 줍니다. 그래서 성능 튜닝보다 먼저 ‘무엇을 얼마나 오래 잡아둘지’를 정하는 게 우선입니다.
결정 포인트
선택 기준
운영 영향
VM 스냅샷에 메모리 포함 여부
실행 상태까지 되돌려야 하면 포함, 일반 패치 전이면 제외
포함 시 생성 시간과 저장 공간 부담이 커질 수 있습니다.
스냅샷 보관 기간
삭제 사고를 발견하는 데 걸리는 시간 기준
길수록 복구 지점은 늘지만 풀 공간 회수가 늦어집니다.
zfs send -i와 -I
두 지점 사이 변경만 필요하면 -i, 중간 스냅샷 체인까지 보내려면 -I
수신 측 스냅샷 구조와 보관 정책이 달라질 수 있습니다.
zfs receive -u
백업 서버에서 자동 마운트를 피하고 싶을 때 사용
복제본이 운영 경로에 갑자기 나타나는 사고를 줄입니다.
복제 대역폭 제한
업무 시간대 I/O 영향이 있으면 제한
너무 낮으면 변경량을 따라가지 못해 지연이 누적됩니다.
백업 복제본 readonly
복제 대상에 사람이 직접 접근할 가능성이 있으면 활성화
다음 증분 receive 실패 가능성을 줄입니다.
또 하나, VM 디스크의 volblocksize나 데이터셋의 recordsize 같은 값은 생성 후 쉽게 바꾸는 튜닝 항목이 아닙니다. 이미 운영 중인 VM에 숫자만 보고 적용하면 기대와 다른 결과가 나올 수 있습니다. 새 스토리지를 설계할 때 워크로드 단위로 검토하고, 기존 환경에서는 스냅샷·복제 정책을 먼저 안정화하는 편이 더 현실적입니다.
11. Proxmox 재해 복구를 위한 최종 운영 체크리스트
Proxmox ZFS 환경을 인수하거나 새로 설계할 때 마지막으로 남기기 좋은 체크리스트입니다. 이 정도만 지켜도 ‘스냅샷은 있는데 복구는 못 하는’ 상황을 꽤 줄일 수 있습니다. 관련 글로는 Proxmox Backup Server 구성법, ZFS scrub 운영 주기, Proxmox HA 설계 가이드를 함께 연결해두면 내부 링크 흐름도 자연스럽습니다.
작업 전 VM 스냅샷은 짧게 가져갑니다. 검증이 끝나면 삭제합니다.
중요 데이터셋은 ZFS 스냅샷 이름 규칙을 고정합니다. 예: daily-YYYY-MM-DD, pre-migration-YYYY-MM-DD.
원격 복제는 공통 기준 스냅샷을 절대 함부로 지우지 않습니다. 보관 정책에 ‘복제 기준 스냅샷 보호’를 포함합니다.
Proxmox Replication은 빠른 재가동용으로 씁니다. 장기 보관과 랜섬웨어 대응은 별도 백업으로 분리합니다.
월 1회 이상 복구 리허설을 합니다. 파일 열기, VM 설정 확인, 테스트 부팅까지 해봐야 진짜 체크입니다.
12. FAQ: 운영자가 자주 헷갈리는 질문
Q1. Proxmox ZFS 스냅샷만 있으면 백업은 없어도 되나요?
아니요. 스냅샷은 같은 풀 안의 시점 보존입니다. 풀 장애, 노드 분실, 관리자 실수, 악성 코드가 root 권한을 잡은 상황까지 대비하려면 별도 위치의 백업이 필요합니다.
Q2. VM 스냅샷과 ZFS 스냅샷 중 무엇을 써야 하나요?
VM 전체를 롤백할 목적이면 Proxmox VM 스냅샷을 우선합니다. 특정 파일 서버 데이터셋, 프로젝트 데이터셋처럼 ZFS 계층에서 복구 단위를 관리하고 싶다면 ZFS 스냅샷이 낫습니다.
Q3. Proxmox Replication과 zfs send/receive 중 무엇이 더 좋나요?
목적이 다릅니다. 클러스터 안에서 VM을 빨리 다시 띄우는 게 목표라면 Proxmox Replication이 편합니다. 독립 백업 서버에 데이터셋을 보관하고 복구 경로를 직접 통제하려면 zfs send/receive가 좋습니다. 중요한 운영 환경에서는 둘 중 하나만 고르기보다 역할을 나눠 같이 씁니다.
Q4. 스냅샷을 오래 보관하면 왜 문제가 되나요?
오래된 스냅샷은 과거 블록을 계속 참조합니다. 원본에서 파일을 삭제하거나 덮어써도 스냅샷이 잡고 있으면 공간이 즉시 반환되지 않습니다. 그래서 스냅샷 정책에는 생성 주기뿐 아니라 삭제 기준이 반드시 있어야 합니다.
Q5. 추천 조합은 무엇인가요?
홈랩이나 소규모 사무실이라면 작업 전 VM 스냅샷 + 중요 데이터셋 일일 ZFS 스냅샷 + 주기적 원격 복제 + 별도 백업을 권합니다. Proxmox 클러스터라면 여기에 내장 Replication을 더해 장애 시 재가동 시간을 줄이세요. 대신 Replication을 백업으로 착각하지 않는 선을 분명히 그어야 합니다.
이 체크리스트의 핵심은 도구를 많이 쓰는 게 아닙니다. 되돌릴 지점, 복제할 위치, 검증할 절차를 운영자가 실제로 반복할 수 있게 만드는 것입니다. 스냅샷은 빠르게 만들고, 복제는 기준을 지키고, 백업은 원본과 분리하세요. 그 세 줄이 Proxmox ZFS 데이터 보호 전략의 뼈대입니다.
![[Linux] LVM 스토리지 관리: 6개월 운영 경험과 성능 최적화 회고](https://blog.pswq.net/wp-content/uploads/2026/10/lvm-storage-management-6-month-retrospective-thumbnail.jpg)
![[Linux] strace 활용: 리눅스 애플리케이션 시스템 콜 추적 및 디버깅 심층 분석](https://blog.pswq.net/wp-content/uploads/2026/10/strace-deep-dive-system-call-tracing-thumbnail.jpg)
![[Linux] APT 패키지 관리와 Flatpak 전환 전략](https://blog.pswq.net/wp-content/uploads/2026/10/apt-to-flatpak-migration-considerations-thumbnail.jpg)
![[Proxmox] Proxmox ZFS 스냅샷·복제 전략 체크리스트](https://blog.pswq.net/wp-content/uploads/2026/10/proxmox-zfs-snapshot-replication-checklist-thumbnail.jpg)
