Incus 7로 홈서버 정리하기: 컨테이너와 VM 사이의 빈칸을 채우는 도구

결론 요약

1. Incus는 시스템 컨테이너와 가상 머신을 같은 스토리지·네트워크·프로젝트 모델로 관리해, Docker보다 완전한 OS가 필요하고 Proxmox보다 가벼운 환경에 잘 맞습니다.
2. 장기 운영 홈서버는 7.0 LTS를 기본으로 삼고, 7.2 같은 월간 기능 릴리스는 보안 수정과 새 기능이 필요한 시험 노드에서 먼저 검증하는 편이 안전합니다.
3. 도입 전에는 비특권 컨테이너, 프로젝트 제한, 스냅샷과 외부 백업, 실제 복구 리허설까지 한 묶음으로 설계해야 합니다.

Docker Compose 파일이 열 개를 넘어가고, 테스트용 리눅스 배포판 때문에 가상 머신도 두세 대 생기면 홈서버가 애매한 지점에 도착합니다. 애플리케이션은 컨테이너가 편하지만 VPN 게이트웨이, 빌드 머신, 별도 init가 필요한 실험 환경은 온전한 운영체제가 필요합니다. 그렇다고 모든 작업을 가상 머신으로 만들면 메모리와 디스크가 빠르게 불어나죠.

이 틈을 공략하는 도구가 Incus입니다. Incus는 LXD에서 갈라져 나온 커뮤니티 주도 오픈소스 프로젝트로, 리눅스 시스템 컨테이너와 애플리케이션 컨테이너, QEMU 기반 가상 머신을 하나의 API와 CLI로 다룹니다. 2026년 4월에는 7.0 LTS가 나왔고, 6월의 7.2 기능 릴리스에는 인스턴스별 SELinux 격리와 여러 보안 수정이 포함됐습니다. 이번 글에서는 설치 명령을 길게 나열하기보다, Incus가 홈서버의 어느 자리에 맞고 어떻게 운영해야 덜 고생하는지 살펴보겠습니다.

Incus 홈서버는 Docker·Proxmox와 무엇이 다른가

Docker의 기본 단위는 애플리케이션 프로세스입니다. 이미지에는 서비스 실행에 필요한 파일만 넣고, 한 컨테이너에 한 역할을 배치하는 구성이 자연스럽습니다. 반면 Incus의 시스템 컨테이너는 부팅 가능한 리눅스 사용자 공간 전체를 제공합니다. SSH로 들어가 패키지를 설치하고 systemd 서비스를 여러 개 띄워도 됩니다. 커널은 호스트와 공유하므로 완전한 가상 머신보다 가볍습니다.

Incus 가상 머신은 게스트가 자기 커널을 가집니다. 커널 모듈을 시험하거나 다른 보안 경계를 원할 때, 혹은 시스템 컨테이너에서 실행하기 곤란한 작업에 적합합니다. 흥미로운 점은 두 종류를 별도 도구로 나누지 않고 동일한 프로필, 프로젝트, 관리 네트워크, 스토리지 풀 위에 올릴 수 있다는 것입니다. incus list 한 번으로 컨테이너와 VM의 상태를 함께 보고, 원격 API도 같은 방식으로 호출합니다.

Proxmox VE는 웹 UI, 클러스터, 백업 제품까지 갖춘 완성형 가상화 플랫폼입니다. 여러 노드와 운영자를 관리하거나 GUI 중심 운영을 원한다면 강점이 분명합니다. Incus는 리눅스 호스트 위에 더 얇게 올라가며 API와 CLI 중심입니다. 어느 쪽이 무조건 낫다기보다 범위가 다릅니다. 미니 PC 한두 대에서 개발용 OS, 네트워크 서비스, 임시 빌드 환경을 코드처럼 다루고 싶다면 Incus가 매력적이고, 데이터센터형 통합 운영 화면이 우선이면 Proxmox가 편합니다.

Docker를 없애야 한다는 뜻은 아니다

Incus와 Docker는 함께 쓸 수 있습니다. 예를 들어 외부 공개 서비스는 하나의 Incus 시스템 컨테이너 안에 Docker Compose로 묶고, 데이터베이스는 별도 인스턴스, 의심스러운 실험은 VM으로 격리할 수 있습니다. 이렇게 하면 호스트에 흩어진 포트와 패키지를 줄이면서도 Compose 생태계를 그대로 활용할 수 있습니다.

다만 중첩 컨테이너에는 보안과 파일 시스템 제약이 생길 수 있습니다. 무작정 privileged 권한을 켜기보다 필요한 커널 기능과 장치만 프로필로 전달해야 합니다. 편의를 위해 경계를 지워버리면 Incus를 한 겹 더 둔 이유가 사라집니다.

Incus 7.0 LTS와 7.2, 어떤 버전을 선택할까

Incus는 장기 지원 릴리스와 월간 기능 릴리스를 구분합니다. 7.0은 2026년 4월 30일 공개된 LTS 계열이고, 7.1과 7.2 같은 기능 릴리스는 다음 기능 릴리스가 나올 때까지 짧게 지원됩니다. 24시간 돌아가는 가족 사진, DNS, 홈 자동화 같은 서비스라면 LTS가 기본 선택입니다. 새 기능이 꼭 필요하거나 월 단위 업그레이드를 감당할 시험 노드라면 기능 릴리스를 고려할 수 있습니다.

7.2에서 가장 먼저 볼 부분은 화려한 기능보다 보안 수정입니다. 공식 릴리스 노트는 악성 이미지의 심볼릭 링크를 통한 호스트 파일 읽기·쓰기, 제한 프로젝트 우회, 백업 압축 인자 주입 등 여덟 건의 문제를 열거합니다. 그중 여러 건이 critical 등급입니다. 외부 이미지를 가져오거나 여러 사용자에게 프로젝트를 나눠준 서버라면 “지금도 잘 돌아간다”는 이유로 업데이트를 미루기 어렵습니다.

새 기능 가운데 인스턴스별 SELinux 통합도 의미가 큽니다. 컨테이너와 VM마다 MCS 레벨을 자동 할당해 같은 호스트의 인스턴스끼리 추가로 구분하고, 계산된 컨텍스트를 재시작 뒤에도 유지합니다. 또 incus info는 기본 출력에서 개인 키와 인증서, 토큰 같은 민감한 값을 가리고, 필요할 때만 --show-sensitive로 표시합니다. 운영 로그를 이슈나 메신저에 붙여 넣는 과정에서 비밀 정보가 새는 사고를 줄이는 작은 변화입니다.

여기서 주의할 점이 있습니다. 7.2의 보안 수정이 중요하다고 해서 모든 7.0 LTS 사용자가 기능 릴리스로 곧장 이동해야 한다는 뜻은 아닙니다. 사용 중인 배포판이 제공하는 LTS 보안 백포트와 패키지 버전을 먼저 확인해야 합니다. 버전 문자열 하나보다 해당 CVE 수정이 실제 패키지에 반영됐는지가 판단 기준입니다.

시스템 컨테이너와 VM을 나누는 실전 기준

홈서버에서는 성능보다 장애 범위를 기준으로 배치하면 결정이 쉬워집니다. 커널을 호스트와 공유해도 되고 빠른 복제와 낮은 메모리 사용량이 중요한 개발 환경, 웹 서비스, 모니터링 도구는 시스템 컨테이너가 어울립니다. 게스트 커널, 강한 격리, 특수 커널 모듈, 커널 패닉 시험이 필요한 작업은 VM으로 보냅니다.

처음에는 다음처럼 세 묶음만 만들어도 충분합니다.

• core 프로젝트: DNS, 리버스 프록시, 인증처럼 다른 서비스가 의존하는 인스턴스
• apps 프로젝트: 미디어, 문서, 자동화처럼 사용자가 직접 쓰는 서비스
• lab 프로젝트: 빌드, 새 배포판, 외부 이미지처럼 언제든 지울 수 있는 실험 환경

프로젝트는 단순 폴더가 아닙니다. 이미지, 프로필, 인스턴스, 스토리지 접근과 제한을 분리하는 경계입니다. lab에는 CPU·메모리·디스크 제한을 걸고 운영 스토리지 풀 접근을 허용하지 않는 식으로 피해 반경을 줄일 수 있습니다. Incus 7.0에는 프로젝트별 스토리지 풀 접근을 허용 목록으로 제한하는 설정도 들어갔습니다.

프로필은 반복 설정을 줄이는 설계도다

프로필에는 CPU와 메모리 상한, 루트 디스크, 네트워크 장치, 공통 cloud-init 설정을 담을 수 있습니다. 예를 들어 small-service, docker-host, isolated-lab 프로필을 만들고 인스턴스에 조합하면 새 서버를 만들 때마다 권한과 NIC 설정을 손으로 복사하지 않아도 됩니다.

처음부터 거대한 범용 프로필 하나를 만들지는 마세요. 모든 인스턴스에 GPU, USB, 호스트 경로가 노출되는 결과로 이어지기 쉽습니다. 공통 기반 프로필은 작게 유지하고, 장치 전달처럼 위험도가 높은 설정은 별도 프로필로 분리하는 편이 감사하기도 쉽습니다.

Incus 백업은 스냅샷과 외부 복구본을 구분해야 한다

Incus는 인스턴스 스냅샷, 백업 내보내기, 서버 간 이동을 지원합니다. 스냅샷은 업데이트 직전 되돌리기에 빠르지만 같은 디스크와 스토리지 풀에 남아 있으면 디스크 고장이나 호스트 분실에는 도움이 되지 않습니다. 백업 파일을 다른 NAS나 오브젝트 스토리지로 복사하고, 데이터베이스처럼 애플리케이션 일관성이 중요한 서비스는 별도의 논리 백업도 가져야 합니다.

권장 순서는 단순합니다. 변경 전 인스턴스를 정지하거나 애플리케이션을 quiesce하고 스냅샷을 만든 뒤, 백업을 외부 저장소로 내보냅니다. 그다음 비핵심 인스턴스부터 업데이트하고 로그, 네트워크, 마운트, 재부팅을 확인합니다. 마지막으로 별도 시험 프로젝트에 백업을 가져와 실제 부팅해 봅니다. 백업 파일이 존재하는 것과 복구 가능한 것은 전혀 다른 상태입니다.

LXD에서 옮기는 경우 공식 lxd-to-incus 도구가 사전 충돌을 확인하고 제자리 마이그레이션을 지원하지만, 이것도 백업을 대신하지 않습니다. 특히 클러스터, 외부 스토리지, 커스텀 네트워크가 있다면 공식 호환 범위를 확인하고 한 노드의 복제 환경에서 먼저 연습해야 합니다.

결론: 홈서버의 단위를 ‘서비스’에서 ‘격리된 환경’으로

Incus의 장점은 컨테이너가 VM보다 빠르다는 단순 비교에 있지 않습니다. 가벼운 리눅스 환경과 완전한 가상 머신을 같은 운영 문법으로 다루면서, 프로젝트와 프로필로 경계를 반복 적용할 수 있다는 점이 핵심입니다. Docker Compose가 애플리케이션 묶음을 정리해 줬다면 Incus는 그 묶음이 살아가는 운영체제와 네트워크의 경계를 정리해 줍니다.

처음부터 기존 홈서버를 전부 옮길 필요는 없습니다. 버려도 되는 개발 환경 하나를 시스템 컨테이너로 만들고, 복제·스냅샷·복구를 한 차례 경험해 보세요. 그다음 VM이 필요한 작업과 Docker 호스트를 분리하면 자신의 환경에 맞는 경계가 보입니다. 홈서버는 서비스를 많이 올리는 것보다, 문제가 생겼을 때 어디까지 멈추는지 예측할 수 있을 때 비로소 편안해집니다.

참고한 공식 자료

• Incus 7.2 릴리스 노트
• Incus 소개와 컨테이너·가상 머신 구조
• LXD에서 Incus로 마이그레이션하는 공식 가이드