Ansible로 Proxmox 환경 1년 자동화 회고: 효율과 함정

안녕하세요, 13년차 서버실 지킴이입니다. 인프라 엔지니어로 일하다 보면 반복적인 작업에 지칠 때가 많죠. 특히 홈랩(Homelab)을 운영하는 저 같은 경우는 작은 규모라도 손이 많이 가는 일들이 부지기수입니다. 새로운 가상 머신(Virtual Machine, VM)을 만들고, 네트워크를 설정하고, 백업을 돌리는 일들은 매번 마우스 클릭과 타이핑의 연속이었거든요. ‘이걸 좀 더 효율적으로 할 수 없을까?’ 하는 고민은 늘 저를 따라다녔습니다. 그러다 1년 전, 제 Proxmox(프록스목스) 환경에 Ansible(앤서블)을 도입하기로 결심했고, 지금까지 정말 많은 것을 배우고 경험했습니다.

오늘은 제가 지난 1년간 Ansible Proxmox 자동화를 구축하고 운영하면서 느꼈던 효율성과, 예상치 못했던 함정들, 그리고 그 해결 과정까지 솔직하게 풀어보려고 합니다. 혹시 저처럼 수동 작업의 굴레에서 벗어나고 싶은 인프라 엔지니어 분들이 계시다면, 이 글이 작은 힌트가 되기를 바랍니다.

Proxmox와 Ansible이 어떻게 연동되어 홈랩 인프라를 자동화하는지 보여주는 추상적인 아키텍처 다이어그램입니다. Ansible 컨트롤러가 SSH를 통해 Proxmox 노드와 통신하며, Proxmox API를 활용하여 VM, LXC 컨테이너, 스토리지, 네트워크 등의 리소스를 관리하는 모습을 나타냅니다.

Ansible과 Proxmox, 왜 찰떡궁합일까요?

먼저, 두 기술의 핵심 개념을 짧게 짚고 넘어가죠.

• Ansible (앤서블): 에이전트리스(Agentless) 방식의 IT 자동화 도구입니다. 관리 대상 서버에 별도의 에이전트(Agent)를 설치할 필요 없이 SSH(Secure Shell) 연결을 통해 명령을 실행하고 작업을 수행하더라고요. YAML(야믈) 기반의 플레이북(Playbook)으로 인프라의 상태를 코드화(Infrastructure as Code, IaC)할 수 있다는 게 가장 큰 장점입니다.
• Proxmox VE (프록스목스 가상 환경): 오픈소스 기반의 강력한 가상화 플랫폼입니다. 리눅스 컨테이너(LXC)와 KVM(Kernel-based Virtual Machine) 기반의 가상 머신을 모두 지원하며, 웹 기반 UI를 통해 쉽게 관리할 수 있죠. 엔터프라이즈급 기능을 홈랩에서도 무료로 활용할 수 있다는 점에서 인기가 많습니다.

Ansible은 Proxmox가 제공하는 풍부한 API(Application Programming Interface)를 활용해 VM 생성, 네트워크 설정, 스냅샷 관리 등 거의 모든 작업을 자동화할 수 있더라고요. Ansible Proxmox 모듈 덕분에 복잡한 API 호출 없이도 YAML 플레이북으로 직관적인 작업이 가능합니다. 말 그대로 인프라를 코드로 관리하는 거죠.

1년 간의 Ansible Proxmox 자동화, 실전 구현 경험

처음엔 저도 ‘이게 진짜 될까?’ 싶었거든요. 그런데 막상 해보니 생각보다 강력하더라고요. 기본적인 VM 생성부터 복잡한 네트워크 설정, 백업 관리까지 Ansible 플레이북 하나로 뚝딱 해결되는 걸 보고 감탄했습니다.

기본적인 VM 생성 플레이북

가장 많이 사용하는 작업이죠. 새로운 VM을 만들고, OS 이미지를 마운트하고, 기본적인 리소스(CPU, RAM, 디스크)를 할당하는 플레이북입니다. 저는 주로 community.general.proxmox 컬렉션의 모듈들을 활용했습니다.

# vm_create.yml
---
- name: Proxmox에 새로운 VM 생성 및 설정
  hosts: proxmox_host
  gather_facts: no
  vars:
    vm_id: 101
    vm_name: my-test-vm
    vm_memory: 2048 # MB
    vm_cores: 2
    vm_disk_size: 30 # GB
    vm_iso: local:iso/ubuntu-22.04-live-server-amd64.iso # Proxmox ISO 스토리지 경로
    vm_bridge: vmbr0
    vm_ip: 192.168.1.101/24
    vm_gw: 192.168.1.1
    vm_dns: 8.8.8.8

  tasks:
    - name: VM 생성
      community.general.proxmox_kvm:
        api_host: "{{ inventory_hostname }}"
        api_user: root@pam
        api_password: "{{ proxmox_root_password }}" # ansible vault로 관리
        vmid: "{{ vm_id }}"
        name: "{{ vm_name }}"
        memory: "{{ vm_memory }}"
        cores: "{{ vm_cores }}"
        scsihw: virtio-scsi-pci
        bootdisk: scsi0
        iso: "{{ vm_iso }}"
        net:
          - name: net0
            model: virtio
            bridge: "{{ vm_bridge }}"
        state: present
      register: create_vm_result

    - name: 디스크 추가 (VM 생성 시 디스크 옵션이 없는 경우)
      community.general.proxmox_disk:
        api_host: "{{ inventory_hostname }}"
        api_user: root@pam
        api_password: "{{ proxmox_root_password }}"
        vmid: "{{ vm_id }}"
        disk: scsi0
        size: "{{ vm_disk_size }}G"
        storage: local-lvm # Proxmox 스토리지 이름
        format: qcow2
        state: present
      when: create_vm_result.changed # VM이 새로 생성되었을 때만 디스크 추가

    - name: VM 부팅
      community.general.proxmox_kvm:
        api_host: "{{ inventory_hostname }}"
        api_user: root@pam
        api_password: "{{ proxmox_root_password }}"
        vmid: "{{ vm_id }}"
        state: started
      when: create_vm_result.changed

위 플레이북은 특정 Proxmox 호스트(proxmox_host)에 새로운 VM을 만들고 시작하는 예시입니다. proxmox_root_password 같은 민감 정보는 나중에 설명할 Ansible Vault(볼트)로 암호화해서 관리하는 게 좋습니다. 그리고 VM 생성 시 디스크 옵션을 한 번에 주기 어려운 모듈 버전도 있어서, 저는 디스크 추가 태스크를 따로 분리하기도 했어요.

네트워크 설정 자동화 (Bridge, VLAN)

Proxmox 노드의 네트워크 인터페이스 설정도 Ansible로 자동화하더라고요. 특히 브릿지(Bridge)나 VLAN(Virtual Local Area Network) 태그를 적용할 때 정말 유용했습니다.

# network_config.yml
---
- name: Proxmox 노드 네트워크 설정
  hosts: proxmox_host
  become: yes
  tasks:
    - name: 네트워크 인터페이스 백업
      ansible.builtin.copy:
        src: /etc/network/interfaces
        dest: /etc/network/interfaces.bak_{{ ansible_date_time.iso8601_basic_short }}
        remote_src: yes

    - name: 새로운 네트워크 설정 적용
      ansible.builtin.template:
        src: interfaces.j2
        dest: /etc/network/interfaces
        owner: root
        group: root
        mode: '0644'
      notify: 네트워크 서비스 재시작

  handlers:
    - name: 네트워크 서비스 재시작
      ansible.builtin.systemd:
        name: networking
        state: restarted

# templates/interfaces.j2
# /etc/network/interfaces - Proxmox Host Network Configuration

auto lo
iface lo inet loopback

auto vmbr0
iface vmbr0 inet static
  address {{ vmbr0_ip }}
  netmask {{ vmbr0_netmask }}
  gateway {{ vmbr0_gateway }}
  bridge-ports {{ physical_nic }}
  bridge-stp off
  bridge-fd 0

# VLAN 10 for Management
auto vmbr0.10
iface vmbr0.10 inet static
  address {{ vmbr0_10_ip }}
  netmask {{ vmbr0_10_netmask }}
  vlan-raw-device vmbr0

template 모듈을 사용해서 Jinja2 템플릿 파일(interfaces.j2)로 Proxmox 호스트의 /etc/network/interfaces 파일을 관리했습니다. 이렇게 하면 네트워크 구성이 코드화되어 버전 관리도 쉽고, 여러 노드에 동일한 설정을 적용하기도 편리하죠. notify 핸들러를 사용해서 변경 사항 적용 후 네트워크 서비스를 자동으로 재시작하도록 했습니다.

백업 및 스냅샷 관리

데이터는 소중하니까요. 자동화된 백업과 스냅샷 관리는 필수입니다. 특히 홈랩에서는 실수로 날려버리는 경우가 많아서 꼭 필요하더라고요.

# backup_snapshot.yml
---
- name: Proxmox VM 백업 및 스냅샷 관리
  hosts: proxmox_host
  gather_facts: no
  vars:
    vmid_to_manage: 101
    backup_storage: backup_pool # Proxmox 백업 스토리지 이름

  tasks:
    - name: VM 스냅샷 생성
      community.general.proxmox_snap:
        api_host: "{{ inventory_hostname }}"
        api_user: root@pam
        api_password: "{{ proxmox_root_password }}"
        vmid: "{{ vmid_to_manage }}"
        snapname: "daily-snapshot-{{ ansible_date_time.iso8601_basic_short }}"
        description: "Daily snapshot by Ansible"
        state: present

    - name: VM 백업 실행 (shell 명령 사용)
      ansible.builtin.shell: |
        vzdump {{ vmid_to_manage }} \
          --storage {{ backup_storage }} \
          --compress zstd \
          --mode stop
      register: backup_result
      async: 3600
      poll: 60

proxmox_snap 모듈로 특정 VM의 스냅샷을 생성했습니다. 백업의 경우, Proxmox 환경에 따라 직접 vzdump 유틸리티를 호출하는 방식도 많이 사용합니다. 이렇게 하면 더 세밀한 제어가 가능하더라고요. async: 3600과 poll: 60을 사용해서 백업이 완료될 때까지 Ansible이 기다려줍니다.

Ansible 플레이북이 성공적으로 실행되어 Proxmox 환경에 VM이 생성되고 네트워크 설정이 적용되는 과정을 보여주는 터미널 화면입니다. 각 태스크의 성공 여부와 변경 사항이 녹색으로 표시되어 자동화가 잘 작동하고 있음을 나타냅니다.

⚠️ 삽질 대잔치! Proxmox Ansible 자동화의 함정과 해결책

자동화가 늘 쉬웠던 건 아닙니다. 저도 꽤 많은 삽질을 했거든요. 특히 Proxmox는 업데이트 주기가 빠르고, Ansible 모듈도 계속 발전하다 보니 버전 호환성이나 예상치 못한 동작으로 골머리를 앓기도 했습니다.

모듈 버전 호환성 문제

초기에는 community.general 컬렉션의 proxmox 모듈이 자주 업데이트되면서, 특정 옵션이 사라지거나 이름이 바뀌는 경우가 많았습니다. 제가 작성했던 플레이북이 갑자기 에러를 뿜어낼 때마다 당황했죠.

• 해결책: `ansible-galaxy collection install community.general:==X.Y.Z` 명령으로 특정 버전의 컬렉션을 설치하고 고정했습니다. 프로덕션 환경이라면 더더욱 버전을 명확히 관리하는 것이 중요하더라고요.

인증 방식의 복잡함

Proxmox API에 접근하려면 인증이 필요합니다. 처음엔 root 계정의 비밀번호를 직접 플레이북에 넣었는데, 보안상 너무 위험하다는 걸 깨달았죠.

• 해결책: Proxmox의 API 토큰(API Token) 기능을 활용했습니다. 특정 사용자에게만 권한을 부여한 API 토큰을 발급받아 사용하고, 이 토큰 정보는 Ansible Vault (앤서블 볼트)로 암호화해서 관리했습니다. ansible-vault encrypt_string 'MY_PROXMOX_API_TOKEN' --name 'proxmox_api_token' 같은 명령어로 쉽게 암호화할 수 있습니다.

네트워크 인터페이스 이름 충돌

VM을 생성할 때 네트워크 인터페이스를 여러 개 추가하다 보면, Proxmox 내부적으로 할당되는 인터페이스 이름(예: net0, net1) 때문에 예상치 못한 문제가 발생하기도 했습니다. 특히 net 배열 인덱스를 잘못 지정하면 원하는 브릿지에 연결이 안 되는 경우가 있었어요.

• 해결책: 플레이북 내에서 net 옵션을 사용할 때 인덱스 순서를 명확히 하고, Proxmox 웹 UI에서 VM 생성 후 실제 할당된 인터페이스 이름과 비교하며 디버깅했습니다. 그리고 네트워크 설정 변경 후 Proxmox 호스트 재부팅이 필요한 경우도 있어서, reboot 모듈을 활용하기도 했습니다.

비동기 작업 처리

VM 생성이나 백업 같은 작업은 시간이 오래 걸릴 수 있습니다. Ansible은 기본적으로 동기(Synchronous) 방식으로 동작하기 때문에, Proxmox에서 작업이 완료되기 전에 Ansible 태스크가 타임아웃(Timeout)되거나 다음 태스크로 넘어가 버리는 문제가 있었습니다.

• 해결책: async와 poll 옵션을 활용했습니다. 예를 들어, async: 300은 해당 태스크를 백그라운드에서 최대 300초(5분) 동안 실행하고, poll: 10은 10초마다 작업 완료 여부를 확인하는 방식입니다. 이렇게 하면 Ansible이 Proxmox의 비동기 작업을 기다려줍니다.

Ansible 자동화로 생성 및 설정된 Proxmox VM들의 리스트를 Proxmox 웹 UI에서 보여주는 화면입니다. 플레이북으로 지정된 이름과 ID, 그리고 현재 상태(Running)가 명확하게 표시되어 자동화가 잘 작동하고 있음을 나타냅니다.

🎉 1년 간의 성과와 얻은 교훈 (검증 및 결과)

지난 1년간 Ansible과 Proxmox를 함께 사용하면서 얻은 가장 큰 성과는 역시 효율성입니다. 이제는 새로운 서버를 구축하거나 기존 서버 환경을 재구성할 때 클릭 몇 번이 아니라, 플레이북 실행 한 번으로 모든 것이 해결됩니다. 삽질도 많이 했지만, 그만큼 얻은 것도 많아요.

압도적인 효율성 증가

예전에는 새 VM 하나 만드는데 10분 이상 걸렸지만, 이제는 플레이북 실행부터 VM 부팅까지 2~3분이면 충분합니다. 특히 여러 대의 VM을 동시에 배포할 때는 그 효과가 정말 크더라고요. 재현 가능한(Idempotent) 인프라를 구축했다는 점도 중요합니다. 언제든 동일한 상태로 인프라를 복원하거나 재구축할 수 있거든요.

인프라 문서화 효과

플레이북 자체가 인프라의 현재 상태를 설명하는 가장 정확한 문서가 됩니다. 누가 봐도 이 플레이북이 어떤 VM을 어떤 설정으로 만들고 있는지 한눈에 들어오더라고요. 팀원들과의 협업이나 나중에 인프라를 다시 파악할 때 정말 큰 도움이 됩니다.

홈랩 운영의 즐거움

무엇보다 홈랩 운영이 훨씬 즐거워졌습니다. 새로운 기술을 실험하고 싶을 때, 클릭 몇 번으로 환경을 만들고 망가뜨려도 부담이 없거든요. 실패해도 플레이북만 다시 돌리면 그만이니까요. 이게 진짜 홈랩 자동화 경험의 핵심 아닐까요?

Ansible을 활용한 Proxmox 자동화의 주요 장점과 고려해야 할 단점을 비교하여 보여주는 표입니다. 효율성, 재현성, 문서화 등의 장점과 함께 학습 곡선, 복잡성 관리 등의 단점을 요약합니다.

마무리하며: 다음 단계와 독자에게 전하는 말

Ansible과 Proxmox의 조합은 저의 인프라 관리 방식을 완전히 바꿔놓았습니다. 물론 완벽하지는 않았지만, 수동 작업으로 인한 피로감을 줄이고, 더 본질적인 문제 해결에 집중할 수 있게 해주었죠. Ansible 플레이북과 Proxmox 인프라 관리에 대한 경험은 저에게 큰 자산이 되었습니다.

혹시 아직 자동화를 시작하지 않으셨다면, 작은 부분부터라도 꼭 도전해보시길 권합니다. 처음엔 어렵게 느껴질 수 있지만, 한 번 손에 익으면 인프라 관리의 새로운 지평이 열릴 겁니다. Ansible 외에도 Terraform(테라폼) 같은 다른 IaC 도구들도 많으니, 여러분의 환경과 필요에 맞는 도구를 찾아보는 것도 좋은 방법입니다. 저는 다음 단계로 Proxmox 클러스터 관리나 더 복잡한 스토리지 연동 자동화에 도전해볼 생각입니다. 여러분의 자동화 여정도 응원할게요! 궁금한 점이나 공유하고 싶은 경험이 있다면 언제든 댓글로 남겨주세요.