13년차의 서버실

서버, 인프라, 홈랩 기술 블로그

[태그:] 홈랩 전원 관리

  • [HomeLabs] Wake-on-LAN 안정적 사용을 위한 홈랩 체크리스트: 설정부터 보안까지

    [HomeLabs] Wake-on-LAN 안정적 사용을 위한 홈랩 체크리스트: 설정부터 보안까지

    홈랩 운영자라면 한 번쯤 겪는 그 상황

    새벽 2시에 갑자기 집 서버에 접속해야 하는데, 아뿔싸 — 전원이 꺼져 있는 거예요. 외출 중이라 물리적으로 전원 버튼을 누를 수도 없고. 혹시 이런 경험 있으신가요? 저는 홈랩 초창기에 이 상황을 몇 번 겪고 나서 “이건 뭔가 대책이 필요하다”는 생각이 들었습니다.

    처음엔 그냥 서버를 24시간 켜두는 방식으로 운영했는데, 전기세 청구서 보고 나서 생각이 확 바뀌더라고요 ㅎㅎ. 그래서 알게 된 게 바로 Wake-on-LAN(WoL, 네트워크를 통한 원격 부팅)이에요. 개념 자체는 단순한데, 막상 홈랩에서 안정적으로 쓰려면 체크해야 할 게 생각보다 많더라고요. BIOS 설정부터 OS, 네트워크 구성, 그리고 보안까지요.

    오늘은 제가 13년 동안 인프라를 운영하면서 직접 정리한 Wake-on-LAN 체크리스트를 공유해 드릴게요. WoL 설정을 처음 시도하시는 분이든, 가끔 안 되서 답답하셨던 분이든 도움이 되실 겁니다.

    Wake-on-LAN 홈랩 전체 구성도 - 원격 기기에서 Magic Packet을 보내 서버를 원격 부팅하는 흐름

    스마트폰이나 외부 PC에서 Magic Packet을 보내 집 서버를 깨우는 전체 흐름

    Wake-on-LAN이 뭔가요? (쉽게 말해서)

    쉽게 말해, 특수한 네트워크 패킷을 보내서 꺼져 있는 컴퓨터를 원격으로 켜는 기술이에요. 1990년대 말에 AMD와 IBM이 만든 규격인데, 지금도 거의 모든 유선 랜카드에 탑재되어 있습니다.

    동작 원리는 이렇습니다. 컴퓨터가 꺼져 있어도 메인보드에는 대기 전력(Standby Power)이 공급되고, 랜카드는 이 대기 전력으로 네트워크 패킷을 계속 감시하고 있거든요. 여기서 Magic Packet(매직 패킷)이라고 부르는 특수한 UDP 패킷이 수신되면 컴퓨터 전원을 켜는 신호를 메인보드에 전달하는 방식이에요.

    Magic Packet 구조는 간단합니다:

    • 앞부분: 0xFF 6바이트 (싱크 스트림)
    • 뒷부분: 대상 컴퓨터의 MAC 주소를 16번 반복 (총 96바이트)
    • 합계: 102바이트짜리 UDP 패킷 (보통 포트 9번 사용)

    이 패킷을 받은 랜카드가 “아, 나한테 온 신호구나” 하고 전원을 켜는 거죠. 참 간단하면서도 영리한 방식이에요.

    단, 중요한 전제가 하나 있어요. WoL은 기본적으로 같은 네트워크 서브넷(Subnet) 안에서만 동작합니다. 인터넷 너머 외부에서 쓰려면 추가 설정이 필요한데, 이건 보안 섹션에서 다룰게요.

    ✅ BIOS/UEFI 설정 체크리스트

    WoL의 첫 번째 관문이에요. 소프트웨어 설정을 아무리 잘 해도 BIOS에서 막혀 있으면 절대 안 됩니다. 저도 처음에 이 부분을 건드리지 않아서 며칠을 삽질했거든요 ㅠㅠ.

    확인해야 할 BIOS 항목

    1. Wake on LAN / Wake on PCI(E) 옵션 → Enabled로 설정
    2. ErP (Energy Related Products) / EuP 옵션 → Disabled로 설정
      ⚠️ 이게 Enabled 되어 있으면 대기 전력 자체를 차단해버려서 WoL이 동작 안 해요. 에너지 절약 기능인데, WoL이랑 같이 쓰면 충돌합니다.
    3. PME (Power Management Event) 옵션 → Enabled로 설정
    4. Deep Sleep / S4, S5 Wake Support 옵션 → 활성화 여부 확인

    💡 팁: 메인보드 제조사마다 옵션 이름이 조금씩 달라요. “Wake on LAN”이 안 보이면 “PME”나 “PCIe Power On” 같은 이름으로 찾아보세요.

    BIOS 설정을 저장하고 나서 반드시 완전 종료(Shutdown) 후 다시 부팅해야 적용됩니다. 재시작(Restart)은 안 돼요.

    ✅ 운영체제(OS) 설정 체크리스트

    BIOS 설정이 끝났다면 이제 OS 레벨에서 WoL을 활성화해야 합니다. Linux를 기준으로 설명할게요.

    현재 WoL 상태 확인

    ethtool 명령어로 랜카드의 WoL 지원 여부와 현재 상태를 확인할 수 있어요.

    # ethtool 설치 (없는 경우)
    sudo apt install ethtool
    
    # 네트워크 인터페이스 이름 확인
    ip link show
    
    # WoL 상태 확인 (인터페이스 이름에 맞게 변경)
    sudo ethtool enp3s0

    출력 결과에서 아래 부분을 확인하세요:

    Supports Wake-on: pumbg   # 지원하는 WoL 모드 (g = Magic Packet)
    Wake-on: d               # 현재 상태 (d = disabled, g = enabled)

    Wake-on: d면 꺼져 있는 거예요. 아래 명령어로 활성화합니다.

    # WoL Magic Packet 활성화
    sudo ethtool -s enp3s0 wol g
    
    # 다시 확인
    sudo ethtool enp3s0 | grep Wake-on

    재부팅 후에도 유지되게 설정하기

    근데 여기서 함정이 있어요. 위 명령어로 활성화해도 재부팅하면 다시 꺼집니다. 영구 적용을 위해서 몇 가지 방법이 있는데, systemd 서비스로 등록하는 게 가장 깔끔하더라고요.

    # /etc/systemd/system/wol.service 파일 생성
    sudo nano /etc/systemd/system/wol.service
    [Unit]
    Description=Enable Wake-on-LAN
    After=network.target
    
    [Service]
    Type=oneshot
    ExecStart=/sbin/ethtool -s enp3s0 wol g
    RemainAfterExit=yes
    
    [Install]
    WantedBy=multi-user.target
    # 서비스 등록 및 활성화
    sudo systemctl enable wol.service
    sudo systemctl start wol.service
    
    # 상태 확인
    sudo systemctl status wol.service

    💡 Ubuntu/Debian의 경우 /etc/network/interfaces에 post-up /sbin/ethtool -s enp3s0 wol g를 추가하는 방법도 있어요. NetworkManager를 쓰는 환경이라면 nmcli로 설정하는 게 더 잘 맞을 수도 있고요.

    BIOS Wake-on-LAN 활성화 설정 및 Linux ethtool WoL 설정 구성도

    BIOS에서 Wake-on-LAN 활성화 후 OS ethtool 설정까지 이어지는 구성 흐름도

    ✅ 네트워크 설정 체크리스트

    이 부분이 WoL에서 제일 많은 삽질 포인트예요. 네트워크 설정이 맞지 않으면 Magic Packet 자체가 대상 컴퓨터에 도달하지 못합니다.

    1. MAC 주소 메모해두기

    WoL은 MAC 주소 기반으로 동작하기 때문에, 대상 컴퓨터의 유선 랜카드 MAC 주소를 미리 메모해두는 게 필수예요. 와이파이(Wi-Fi)는 WoL을 지원하지 않는 경우가 대부분이라 꼭 유선 연결을 사용해야 합니다.

    # MAC 주소 확인
    ip link show enp3s0
    # 또는
    cat /sys/class/net/enp3s0/address

    2. 라우터에서 정적 IP 또는 DHCP 고정 설정

    WoL 자체는 MAC 주소 기반이라 IP가 바뀌어도 작동은 하지만, 나중에 원격 접속할 때 IP가 바뀌어 있으면 또 다른 문제가 생기거든요. 라우터의 DHCP 설정에서 MAC 주소를 기반으로 IP를 고정(DHCP Reservation)해두는 걸 추천합니다.

    3. Directed Broadcast 또는 유니캐스트 설정

    Magic Packet을 보낼 때 목적지 주소를 어떻게 설정하느냐가 중요합니다.

    방식 목적지 주소 특징
    Broadcast 255.255.255.255 같은 서브넷 전체에 전송, 간편하지만 보안에 덜 좋음
    Directed Broadcast 192.168.1.255 (예시) 특정 서브넷에만 전송, 더 권장되는 방식
    Unicast 대상 IP 직접 지정 같은 서브넷 내에서 ARP 캐시 활용, 정확하게 전달

    같은 홈 네트워크 안이라면 보통 Broadcast 방식으로도 잘 되는데, 라우터 설정에 따라 Broadcast를 차단하는 경우도 있어요. 그럴 때는 Directed Broadcast를 써보세요.

    4. 스위치 사용 시 VLAN 확인

    홈랩에서 관리형 스위치(Managed Switch)를 쓰고 VLAN을 나눠놓은 경우, Magic Packet이 VLAN 경계를 넘지 못해서 WoL이 안 되는 상황이 생깁니다. 저도 이거 때문에 한참 헤맸거든요. WoL 대상 서버와 Magic Packet을 보내는 장치가 같은 VLAN에 있어야 해요.

    ✅ Magic Packet 전송 테스트

    설정이 끝났으면 실제로 작동하는지 테스트해봐야죠. 같은 네트워크 내 다른 컴퓨터나 스마트폰에서 Magic Packet을 보내보세요.

    Linux에서 보내기

    # wakeonlan 패키지 설치
    sudo apt install wakeonlan
    
    # Magic Packet 전송 (MAC 주소 형식: xx:xx:xx:xx:xx:xx)
    wakeonlan AA:BB:CC:DD:EE:FF
    
    # 특정 IP로 전송하고 싶을 때
    wakeonlan -i 192.168.1.255 AA:BB:CC:DD:EE:FF

    Python으로 직접 만들어보기

    import socket
    import struct
    
    def send_wol(mac_address):
        # MAC 주소 파싱
        mac_bytes = bytes.fromhex(mac_address.replace(':', '').replace('-', ''))
        
        # Magic Packet 구성: 0xFF * 6 + MAC * 16
        magic_packet = b'\xff' * 6 + mac_bytes * 16
        
        # UDP로 전송
        with socket.socket(socket.AF_INET, socket.SOCK_DGRAM) as s:
            s.setsockopt(socket.SOL_SOCKET, socket.SO_BROADCAST, 1)
            s.sendto(magic_packet, ('255.255.255.255', 9))
        print(f"Magic Packet sent to {mac_address}")
    
    # 사용 예시
    send_wol('AA:BB:CC:DD:EE:FF')

    스마트폰에서는 “Wake on LAN” 앱들이 여럿 있으니 하나 받아서 써보시면 됩니다. 테스트할 때는 서버를 완전히 끄고 (Shutdown), 30초 정도 기다린 다음에 Magic Packet을 전송해보세요.

    Wake-on-LAN 원격 부팅 성공 모니터링 대시보드 - Magic Packet 전송 후 서버 온라인 상태 확인

    Magic Packet 전송 후 서버가 응답하는지 ping으로 확인하는 모니터링 화면 예시

    ⚠️ 보안 체크리스트: 이거 꼭 챙기세요

    WoL 설정할 때 보안을 소홀히 하는 경우가 많아요. 특히 인터넷 외부에서도 WoL을 쓰고 싶어서 포트 포워딩(Port Forwarding)을 열어두는 분들이 있는데, 이건 진짜 위험합니다.

    ❌ 이렇게 하면 안 됩니다: 포트 포워딩으로 WoL 개방

    라우터에서 UDP 포트 9번을 인터넷에 직접 개방하면, 전 세계 누구나 여러분의 서버에 Magic Packet을 보낼 수 있게 됩니다. MAC 주소는 대부분 변경이 가능하고, 네트워크를 통해 수집될 수도 있어요. 보안상 아주 좋지 않은 방식입니다.

    ✅ 이렇게 하세요: VPN 경유 WoL

    외부에서 WoL을 써야 한다면, VPN(Virtual Private Network, 가상 사설망)을 통해 홈 네트워크에 먼저 접속한 다음 Magic Packet을 전송하는 방식이 정석이에요. 홈랩에서는 WireGuard나 OpenVPN을 많이 쓰는데, 라우터나 항상 켜두는 소형 기기(예: Raspberry Pi)에 VPN 서버를 올려두면 됩니다.

    # VPN 접속 후 Magic Packet 전송 (예시)
    # VPN 터널이 연결된 상태에서 같은 서브넷으로 전송
    wakeonlan -i 192.168.1.255 AA:BB:CC:DD:EE:FF

    이 방식이면 VPN 인증을 통과한 사람만 WoL을 사용할 수 있어서 훨씬 안전합니다.

    WoL 보안 체크리스트 요약

    • ✅ UDP 9번 포트를 인터넷에 직접 노출하지 않기
    • ✅ VPN을 통한 홈 네트워크 접근 후 WoL 사용
    • ✅ 라우터 방화벽에서 외부→내부 UDP 9 트래픽 차단 확인
    • ✅ 홈랩 네트워크에 접근 가능한 VPN 계정 최소화
    • ✅ 불필요할 때는 BIOS에서 WoL 비활성화 고려

    ⚠️ 트러블슈팅: 안 될 때 확인할 것들

    설정 다 했는데 안 된다고요? 저도 그랬어요. 아래 체크리스트 순서대로 확인해보세요.

    1. BIOS ErP/EuP 설정 확인: 가장 흔한 원인이에요. Enabled 되어 있으면 Disabled로 바꾸세요.
    2. 완전 종료(Shutdown) 확인: Windows의 “빠른 시작” 기능이 활성화되어 있으면 완전한 S5(전원 꺼짐) 상태가 아닐 수 있어요. 빠른 시작을 비활성화하거나, shutdown /s /t 0 명령어로 완전 종료하세요.
    3. ethtool 상태 재확인: 재부팅 후 WoL이 다시 disabled 상태로 돌아가지는 않았는지 확인하세요.
    4. 방화벽 확인: 서버의 소프트웨어 방화벽이 완전히 꺼진 상태에서도 안 되는지 테스트해보세요 (BIOS 레벨에서 처리되기 때문에 보통은 무관하지만, 일부 환경에서는 영향을 미칠 수 있어요).
    5. 케이블 및 스위치 확인: 전원이 꺼진 상태에서도 랜 포트의 LED가 깜빡이고 있어야 해요. LED가 전혀 안 켜진다면 대기 전력이 공급이 안 되는 것일 수 있어요.
    6. VLAN 경계 확인: 관리형 스위치를 사용 중이라면 Magic Packet 발송 장치와 대상 서버가 같은 VLAN에 있는지 확인하세요.
    7. 전원 어댑터 확인: 일부 전원 멀티탭이나 스마트 플러그가 완전 차단 방식이면 대기 전력 자체가 공급 안 될 수 있어요.

    BIOS → OS → 네트워크 → 보안 순서로 점검하는 Wake-on-LAN 체크리스트 전체 흐름

    🎉 마무리: WoL 안정적으로 쓰기 위한 최종 체크리스트

    여기까지 따라오셨다면 이제 WoL이 제대로 작동하고 있을 거예요. 마지막으로 전체 체크리스트를 한눈에 정리해 드릴게요.

    BIOS/UEFI

    • ☐ Wake on LAN / PME 옵션 → Enabled
    • ☐ ErP/EuP 옵션 → Disabled
    • ☐ 설정 후 완전 종료(Shutdown) 후 재부팅

    운영체제

    • ☐ ethtool로 WoL 지원 확인 (Supports Wake-on에 g 포함 여부)
    • ☐ ethtool -s [인터페이스] wol g로 활성화
    • ☐ systemd 서비스 또는 네트워크 설정으로 영구 적용
    • ☐ Windows 사용 시 “빠른 시작” 비활성화

    네트워크

    • ☐ 유선 랜 연결 확인 (Wi-Fi는 미지원)
    • ☐ MAC 주소 메모 및 보관
    • ☐ 라우터에서 DHCP IP 고정(Reservation)
    • ☐ 관리형 스위치 사용 시 VLAN 동일 여부 확인

    보안

    • ☐ UDP 9번 포트 인터넷 직접 노출 금지
    • ☐ 외부 접근 필요 시 VPN 경유 설정
    • ☐ 라우터 방화벽에서 외부 WoL 트래픽 차단

    WoL을 제대로 구축해두면 홈랩 전원 관리가 정말 편해져요. 필요할 때만 켜고, 쓰고 나면 끄는 운영이 가능해지니까 전기세도 아낄 수 있고요. 저는 이걸 구축한 이후로 홈랩 서버를 “필요할 때 깨우는” 방식으로 바꿨는데, 운영 비용이 눈에 띄게 줄었습니다.

    다음 글에서는 VPN을 통한 외부 원격 접근 환경 구축을 다룰 예정이에요. WoL과 VPN을 조합하면 완전한 원격 홈랩 환경을 만들 수 있거든요. 기대해 주세요!

  • [HomeLabs] Proxmox UPS 연동: NUT 설정으로 홈랩 자동 종료 구성하기

    [HomeLabs] Proxmox UPS 연동: NUT 설정으로 홈랩 자동 종료 구성하기

    Proxmox UPS 연동: NUT 설정으로 홈랩 자동 종료 구성하기

    홈랩을 오래 굴리다 보면 한 번쯤은 정전이나 순간 전압 강하 때문에 식은땀이 나는 순간이 오더라고요. 특히 Proxmox UPS 연동을 안 해둔 상태에서 갑자기 전원이 나가면, 가상머신(VM, Virtual Machine)이나 컨테이너(CT, Container)가 비정상 종료되면서 파일시스템이 꼬이거나, 다음 부팅 때 예상치 못한 복구 작업이 걸릴 수 있어요. 저도 처음엔 “UPS만 꽂아두면 되는 거 아닌가?” 싶었는데, 실제로 써보니까 무정전 전원 장치와 하이퍼바이저(Hypervisor, 가상화 호스트) 사이의 신호 전달이 제대로 돼야 비로소 의미가 있더라고요.

    이번 글에서는 제가 홈랩에서 정리해둔 방식 기준으로, Proxmox VE와 UPS를 연동해서 Proxmox 자동 종료까지 연결하는 흐름을 설명드리겠습니다. 중심은 NUT(Network UPS Tools, 네트워크 UPS 관리 도구) 설정이고요. 단순 설치 명령만 나열하지 않고, 왜 그렇게 해야 하는지, 어디서 자주 막히는지, 그리고 실제 검증은 어떻게 하는지까지 같이 보겠습니다.

    Proxmox 서버, UPS, 네트워크 스위치, NAS가 어떻게 연결되는지 한눈에 보여주는 전체 구성도입니다.

    1. 왜 Proxmox VE와 UPS 연동이 중요한가

    쉽게 말해 UPS는 배터리만 달린 멀티탭이 아니에요. 전원 이상이 생겼을 때 “지금 배터리로 버티는 중이니 정리하고 내려가세요”라는 신호를 서버에 줄 수 있어야 제대로 된 구성이 됩니다. 여기서 중요한 포인트! 그냥 전원만 유지한다고 끝이 아니고, 언제 종료를 시작할지를 운영자가 정해줘야 하거든요.

    • 전원 순간 끊김 대응: 짧은 정전에는 서비스 지속
    • 배터리 한계 대응: 오래 가는 정전이면 안전 종료 수행
    • 스토리지 보호: ZFS 같은 파일시스템도 강제 전원 차단은 반갑지 않아요
    • 무인 운영 안정성: 집 비울 때도 자동으로 처리 가능

    제가 직접 해보니, UPS를 달아두고도 자동 종료를 안 걸어두면 반쯤만 구성한 셈이었어요. 배터리는 버티는데 결국 배터리가 다 닳으면 더 난감해지거든요. 그래서 홈랩 전원 관리는 “버틴다”보다 “정해진 조건에서 질서 있게 내려간다”에 초점을 두는 게 맞습니다.

    2. NUT 설정, 쉽게 말해 어떤 구조인가

    NUT(Network UPS Tools)는 UPS 상태를 읽고, 그 상태를 다른 시스템에 전달하고, 필요하면 종료 액션까지 연결하는 도구 모음이에요. 처음엔 이게 뭔가 싶었는데, 역할을 나눠서 보면 생각보다 단순합니다.

    구성 요소 역할 홈랩에서 보통 어디에 두나
    driver UPS와 직접 통신 USB로 연결된 Proxmox 호스트 또는 별도 관리 서버
    upsd 상태를 네트워크로 제공 driver가 있는 같은 장비
    upsmon 상태를 감시하고 종료 조건 처리 Proxmox 호스트, 필요하면 다른 서버에도

    보통 홈랩에서는 두 가지 패턴이 많아요.

    1. 단일 노드형: UPS를 Proxmox 서버에 USB로 직접 연결하고, 그 서버에서 NUT를 모두 처리
    2. 중앙 관리형: NAS나 별도 리눅스 장비가 UPS를 읽고, Proxmox는 네트워크 클라이언트로 감시

    저는 처음에 단일 노드형으로 시작했어요. 가장 단순하고, 장애 포인트가 적어서 입문에는 좋더라고요. 클러스터(Cluster)나 장비가 늘어나면 중앙 관리형이 더 편할 수 있습니다.

    3. Proxmox UPS 연동 전에 먼저 확인할 것들

    설정 들어가기 전에 아래는 꼭 체크해보세요. 이 단계 건너뛰면 뒤에서 삽질 좀 합니다.

    • UPS가 USB HID(Human Interface Device) 또는 NUT 지원 드라이버로 인식 가능한지
    • UPS 연결 대상이 Proxmox 호스트인지: VM 안에 USB 패스스루로 넣어두면 종료 타이밍이 꼬일 수 있어요
    • 전원 종료 정책이 명확한지: 배터리 잔량 기준인지, 런타임 기준인지, on battery 지속 시간 기준인지
    • 스토리지 구조 파악: 로컬 디스크인지, NAS/iSCSI인지에 따라 종료 순서가 달라질 수 있어요

    특히 홈랩 전원 관리에서 많이 놓치는 게 네트워크 장비예요. UPS는 서버만 물려 있고 스위치나 공유기는 일반 멀티탭에 꽂혀 있으면, 정전 때 네트워크가 먼저 죽어버립니다. 그러면 NUT 서버와 클라이언트 통신이 끊겨서 상태 전달이 애매해질 수 있어요. 가능하면 최소한 UPS 상태 전달에 필요한 네트워크 장비는 같이 보호하는 편이 낫습니다.

    Proxmox UPS 연동에서 NUT 설정 흐름을 보여주는 구성도

    UPS 드라이버, upsd, upsmon이 어떤 순서로 동작하는지 보여주는 설정 흐름도입니다.

    4. 실전 구현: Proxmox VE에서 NUT 설치와 기본 설정

    이제 실제로 해보겠습니다. 아래 예시는 UPS를 Proxmox 호스트에 USB로 직접 연결하는 가장 흔한 방식이에요. 제품별 드라이버 이름은 다를 수 있으니, 모델별로 NUT 호환 드라이버를 확인해두는 게 좋습니다. 여기서는 대표적으로 많이 쓰는 USB HID 계열 기준으로 적겠습니다.

    4-1. 패키지 설치

    apt update
    apt install nut

    설치 후엔 NUT 동작 모드를 지정해요.

    grep -v '^#' /etc/nut/nut.conf
    MODE=standalone

    standalone은 이 장비가 직접 UPS를 읽고 감시까지 하는 형태예요. 만약 별도 NUT 서버가 있고 Proxmox는 감시만 할 거라면 netclient 구성을 생각해볼 수 있습니다.

    4-2. UPS 장치 정의

    /etc/nut/ups.conf에 UPS를 정의합니다.

    [homelab-ups]
      driver = usbhid-ups
      port = auto
      desc = "HomeLab UPS"

    여기서 driver는 장치별로 다를 수 있어요. 처음엔 저도 무조건 usbhid-ups면 될 줄 알았는데, 모델에 따라 다른 드라이버가 맞는 경우도 있더라고요. 인식이 안 되면 이 지점부터 다시 봐야 합니다.

    4-3. 접근 계정 설정

    /etc/nut/upsd.users에 모니터링 계정을 만들어요.

    [monuser]
      password = strong-password-here
      upsmon master

    단일 서버 기준이라면 upsmon master 권한으로 충분한 경우가 많아요.

    4-4. upsd 리스닝 주소 확인

    /etc/nut/upsd.conf는 기본적으로 로컬호스트만 열어도 돼요. 다른 장비에서도 상태를 볼 거라면 내부망 IP를 추가하세요.

    LISTEN 127.0.0.1 3493
    LISTEN 192.168.0.10 3493

    외부에 열 필요는 없어요. 이 포트는 내부망에서만 관리하는 걸 권장합니다.

    4-5. upsmon 연결 설정

    /etc/nut/upsmon.conf에서 감시 대상을 지정합니다.

    MONITOR homelab-ups@localhost 1 monuser strong-password-here master
    MINSUPPLIES 1
    SHUTDOWNCMD "/sbin/shutdown -h +0"
    POLLFREQ 5
    POLLFREQALERT 5
    HOSTSYNC 15
    DEADTIME 15
    POWERDOWNFLAG /etc/killpower

    여기서 많이 보는 항목 몇 개만 짚어볼게요.

    • MONITOR: 어떤 UPS를 어떤 계정으로 감시할지
    • SHUTDOWNCMD: 종료 시 실제 실행할 명령
    • HOSTSYNC: 클라이언트 종료 대기 관련 타이밍
    • POWERDOWNFLAG: 전원 차단 단계와 연계되는 플래그 파일

    설정 후 서비스 재시작해요.

    systemctl restart nut-server
    systemctl restart nut-monitor

    4-6. 상태 확인

    upsc homelab-ups@localhost

    정상이라면 배터리 상태, 입력 전압, UPS 상태 같은 정보가 출력돼요. 이게 안 나오면 뒤 단계로 가지 마세요. 여기서 멈추고 드라이버, 권한, USB 인식부터 다시 확인하는 게 맞습니다.

    5. Proxmox 자동 종료를 어디까지 할 것인가

    여기서부터가 운영 포인트예요. 그냥 호스트만 꺼버리면 끝이냐? 사실 그렇진 않습니다. Proxmox는 그 위에 VM과 CT가 올라가 있으니까요. 제가 실제로 써보니까 가장 깔끔했던 건 게스트 종료 시간을 평소에 정리해두는 것이었어요.

    1. 중요 서비스가 올라간 VM은 Guest Agent(QEMU Guest Agent 등)를 가능하면 활성화
    2. 종료 우선순위가 중요한 VM은 Proxmox 시작/종료 순서 옵션을 미리 설정
    3. NAS 의존 서비스가 있다면 스토리지 종료 순서를 마지막까지 고려
    4. UPS 이벤트가 왔을 때 호스트가 너무 빨리 내려가지 않도록 약간의 여유를 둠

    실무적으로는 “배터리 모드 진입 즉시 종료”보다, “배터리 모드가 일정 시간 지속되면 종료”가 더 덜 민감해요. 순간 정전은 생각보다 자주 오고, 그때마다 전체 홈랩이 내려가면 운영 피로도가 높아지거든요.

    만약 더 세밀하게 제어하고 싶다면, NUT 알림 이벤트를 받아 후처리 스크립트를 거는 방식도 있어요. 예를 들면 배터리 모드 진입 시 로그를 남기고, 실제 저전력 상태(Low Battery)일 때만 종료하도록 설계하는 식입니다.

    NOTIFYCMD /usr/sbin/upssched
    NOTIFYFLAG ONBATT SYSLOG+EXEC
    NOTIFYFLAG LOWBATT SYSLOG+EXEC
    NOTIFYFLAG ONLINE SYSLOG+EXEC

    이 부분은 환경마다 편차가 있어서, 처음부터 복잡하게 들어가기보다 기본 종료 동작이 안정적으로 되는지 먼저 확인한 뒤 확장하는 걸 추천드립니다.

    Proxmox 자동 종료와 UPS 이벤트 흐름을 표현한 운영 화면 이미지

    가상머신 종료 순서와 UPS 상태 이벤트가 연결되는 운영 관점을 시각화한 이미지입니다.

    6. ⚠️ 트러블슈팅: 실제로 자주 막히는 지점들

    이 섹션이 아마 제일 도움 되실 겁니다. 저도 처음엔 설정 파일 몇 줄 넣으면 끝날 줄 알았는데, 생각보다 함정이 많더라고요.

    6-1. upsc가 응답하지 않는 경우

    가장 먼저 볼 건 세 가지예요.

    • UPS가 운영체제에서 USB 장치로 보이는지
    • ups.conf의 드라이버가 맞는지
    • nut-server와 nut-monitor가 정상 실행 중인지
    systemctl status nut-server
    systemctl status nut-monitor
    journalctl -u nut-server -n 50
    journalctl -u nut-monitor -n 50

    로그를 보면 의외로 힌트가 바로 나와요. 드라이버 초기화 실패, 권한 오류, 장치 점유 실패 같은 메시지가 보이면 방향이 잡혀요.

    6-2. USB는 잡히는데 상태값이 이상한 경우

    이건 UPS 자체 호환성이나 드라이버 매핑 문제일 때가 있어요. 특히 일부 장비는 기본 정보만 주고, 세부 값은 제한적으로 주는 경우가 있더라고요. 이럴 땐 배터리 퍼센트 숫자 하나에만 의존하지 말고, ONBATT(배터리 모드), LOWBATT(저전력) 같은 상태 이벤트 위주로 설계하는 게 더 안정적이었어요.

    6-3. 정전 테스트가 무서워서 검증을 못 하는 경우

    이거 공감하실 겁니다. 저도 처음엔 멀티탭을 뽑았다가 뭔가 잘못될까 봐 망설였거든요. 근데 검증 없이 운영하면 더 위험해요. 다만 순서를 나눠서 테스트하면 부담이 줄어듭니다.

    1. 상태 조회 테스트: upsc로 현재 값 확인
    2. 이벤트 테스트: UPS 입력 전원을 잠깐 빼서 ONBATT 전환 확인
    3. 복귀 테스트: 전원 복구 후 ONLINE 복귀 확인
    4. 종료 테스트: 실제 종료 조건은 낮은 부하 시간대에만 검증

    6-4. 네트워크형 NUT 구성에서 클라이언트가 못 붙는 경우

    이건 보통 LISTEN 주소나 방화벽(Firewall) 쪽 문제예요. 그리고 내부 DNS 이름보다 처음엔 IP로 먼저 붙여보는 것이 troubleshooting에는 낫습니다. 이름 해석 문제인지, 포트 문제인지 분리하기 쉬워지거든요.

    6-5. 호스트는 꺼졌는데 게스트가 지저분하게 죽는 경우

    이건 UPS 문제가 아니라 Proxmox 종료 순서 문제일 가능성이 커요. Guest Agent 설치 여부, VM shutdown timeout, 시작/종료 순서 설정을 다시 보세요. 결국 Proxmox UPS 연동은 UPS만 붙인다고 끝나는 게 아니라, 게스트 운영 정책까지 묶여야 완성돼요.

    7. 검증 방법: 완성 후 꼭 확인할 체크리스트

    설정 끝났다고 바로 안심하시면 안 돼요. 실제로 써보니까 검증 체크리스트 하나 만들어두는 게 진짜 편하더라고요.

    1. upsc homelab-ups@localhost가 정상 응답하는지 확인
    2. UPS 전원을 잠깐 빼서 상태가 OL에서 배터리 모드로 바뀌는지 확인
    3. 시스템 로그에 ONBATT 이벤트가 기록되는지 확인
    4. 전원 복귀 후 ONLINE 이벤트가 찍히는지 확인
    5. 테스트용 VM이 정상 shutdown 되는지 확인
    6. 호스트 종료 명령이 실제로 실행 가능한 상태인지 확인
    journalctl -f

    실시간 로그를 보면서 테스트하면 전환 흐름이 명확하게 보여요. 드디어 됐다! 싶은 순간이 여기서 오더라고요. 눈으로 상태 변화를 확인하면 훨씬 안심돼요.

    Proxmox UPS 연동 결과와 NUT 상태 검증을 보여주는 터미널 이미지

    UPS 상태값, 이벤트 로그, 종료 검증 포인트를 한 화면에서 확인하는 결과 예시입니다.

    8. 베스트 프랙티스 정리와 운영 팁

    이제 핵심만 압축해서 정리해보겠습니다. 아래는 제가 현재도 지키는 기준이에요.

    항목 권장 방식 이유
    UPS 연결 위치 가능하면 Proxmox 호스트 직접 연결 구조 단순, 장애 포인트 감소
    종료 트리거 즉시 종료보다 지속 조건 기반 순간 정전에 덜 민감
    감시 범위 호스트 + 핵심 네트워크 장비 고려 상태 전달 경로 유지
    게스트 종료 사전 종료 순서 정리 비정상 종료 방지
    검증 주기 정기적인 짧은 테스트 설정 드리프트 조기 발견

    추가로 몇 가지 팁을 더 드리면요.

    • USB 케이블 접촉 불량은 생각보다 흔해요
    • NUT 설정을 바꾼 뒤에는 서비스 재시작과 상태 조회를 세트로 하세요
    • 로그 확인 습관을 들이면 문제를 절반은 줄일 수 있어요
    • 클러스터 환경이라면 어느 노드가 UPS 마스터 역할을 할지 먼저 정하는 게 좋습니다

    혹시 이런 경험 있으신가요? 정전은 거의 없는데, 막상 한 번 터지면 제일 아픈 타이밍에 오더라고요. 그래서 무정전 전원 장치는 장비 구매보다 운영 설계가 더 중요해요. 저도 처음엔 UPS 하나 달면 끝인 줄 알았는데, 결국 중요한 건 홈랩 전원 관리 시나리오 전체를 미리 정리하는 거였어요.

    9. 자주 묻는 질문과 마무리

    FAQ

    • Q. UPS를 샀는데 바로 안전 종료가 되나요?
      A. 아니에요. 전원 공급은 되더라도, 상태 전달과 종료 정책이 설정되지 않으면 자동 종료는 동작하지 않습니다.
    • Q. NUT 말고 다른 방법도 있나요?
      A. 있어요. 다만 여러 장비에 상태를 배포하거나 표준적인 구성을 원하면 NUT가 많이 쓰입니다.
    • Q. 배터리 퍼센트 기준과 시간 기준 중 뭐가 더 낫나요?
      A. 환경마다 달라요. 저는 상태 이벤트와 지속 시간을 같이 보는 쪽이 더 안정적이었어요.

    정리하면, Proxmox UPS 연동의 핵심은 단순해요. UPS를 연결하고, NUT로 상태를 읽고, 적절한 조건에서 Proxmox 자동 종료가 되도록 만드는 것. 그런데 실제 운영에서는 이 단순한 흐름 사이사이에 종료 순서, 네트워크 생존성, 로그 검증 같은 디테일이 숨어 있더라고요.

    이번 글은 troubleshooting 중심으로 정리해봤고요. 다음 글에서는 NUT 서버를 별도로 두고 여러 장비가 하나의 UPS 상태를 공유하는 구조도 다뤄볼 예정입니다. 이전에 다룬 스토리지/가상머신 백업 글과 같이 보시면, 홈랩 안정성이 훨씬 탄탄해질 겁니다.

    Proxmox UPS 연동 베스트 프랙티스와 트러블슈팅 요약 인포그래픽

    설정 포인트, 검증 순서, 자주 발생하는 문제를 한 장으로 정리한 요약 이미지입니다.

    처음엔 헷갈려도 한 번만 제대로 잡아두면 진짜 편해요. 저처럼 미리 한 번 삽질해두시면, 나중에 정전이 와도 훨씬 덜 당황하게 되실 겁니다.