좌충우돌 홈서버 제작 블로그

UPS 설치 (bx 1200mi)

dae-ya — Sun, 12 Apr 2026 20:26:09 +0900

UPS란 정전 시 일정 시간 동안 서버가 꺼지지 않게 버텨주는 일종의 보조배터리이다.

순간적으로 발생하는 순간정전시 서버가 꺼지지 않고 버티게 해 줄 수도 있고

긴 시간동안의 정전 시 UPS의 전력이 일정 % 아래로 내려갈 시 서버와 통신하여 서버를 안전하게 끌 수도 있다.

요즘 하드웨어 값이 비싸서 UPS의 구매를 할 필요성을 느끼고 있었다.

NAS용 하드가 4테라에 20만 원이 넘어가니 2개가 동시에 베드섹터가 생긴다면 40만 원을 손해 보는 것이다.

단순히 서비스 운용 문제 예방 뿐만 아니라 하드에 가장 큰 대미지를 주는 정전을 막기 위한 투자이다.

그래서 천천히 알아보던 중 집에 돌아오니 서버가 꺼져있던 것을 발견했고 바로 UPS를 알아보았다.

서버가 단순히 시놀로지같은 기성제품이거나 자작 서버여도 파워가 5만 원 이하의 파워이면 상관이 없지만

SF750같이 작고 비싼 제품은 꽤 고려할 사항이 많았다.

고려할 사항은 바로 유사정형파와 순수정형파 문제이다.

유사정현파: 계단식 파형

순수정현파: 부드러운 곡선 파형

순수정현파는 모든 장비에 사용가능하지만 장비들이 꽤 비싸다.

유사정현파 장비들은 값이 싸지만 민감한 장비에 사용하면 노이즈와 오작동을 일으킬 수 있다.

이번에 구매한 APC bx 1200mi 제품은 유사정현파 장비이다.

유사정현파가 SF750같이 고급장비에 입력되면 단순하게 노이즈만 발생하는게 아니라 최악의 경우 SF750이 고장 날 수도 있다.

하지만 그래도 구매를 한 이유는 가격이 싸기 때문에 구매를 했다.

그리고 정전 발생 후 1분뒤 바로 서버를 안정적으로 끄게 설정을 할 예정이기 때문에 SF750 파워에 큰 대미지를 일으키지 않을 것으로 생각했다.

UPS와 서버는 USB로 통신을 한다.

서버(USB A타입)-----UPS(USB B타입)

그래서 일정 % 이하나 정전 발생 일정 시간이 지나면 서버가 알아서 꺼지게 할 수 있는 것이다.

Proxmox 서버는 APC UPS를 공식적으로 지원한다.

다만 Proxmox 호스트가 VM을 통제 할 권한과 통신을 해야 하므로 qemu-guest-agent가 각 VM에 설치되어 있고 실행 중 이어야 한다.

UPS 설정을 위해서는 apcupsd를 설치해야 한다.

apt update && apt install apcupsd -y
#apcupsd 설치

nano /etc/apcupsd/apcupsd.conf
#ups 설정파일 편집

아래 내용으로 설정파일을 편집한다.

UPSCABLE usb

UPSTYPE usb

DEVICE (DEVICE 이후 비워두기)

TIMEOUT 60 (정전 감지 이후 60초 후 종료 프로세스 시작, 0으로 설정시 배터리 다 닳을 때까지 버팀)

systemctl enable apcupsd
systemctl restart apcupsd
#apcupsd 활성화 및 재시작

apcaccess status
#ups 상태 확인

그리고 UPS 플러그를 콘센트에서 뺐을 때 인버터 소리와 같이 삑삑 하는 소리를 들을 수 있다.

이 삑삑 소리는 apctest명령으로 끌 수 있다.

systemctl stop apcupsd
#apcupsd 멈춤

apctest

텍스트 메뉴 출력되면 Change alarm behavior에 해당 하는 번호를 입력한다.

알람을 비활성화 하는 Disable 번호를 입력한다.

Q를 눌러 메뉴를 벗어난다.

systemctl start apcupsd
#apcupsd 시작

설정을 마치면 이제 정전이 되더라도 서버가 안정적으로 버틸 수 있는 환경이 만들어졌다.

Docker Security Scanner Update

dae-ya — Mon, 30 Mar 2026 14:19:02 +0900

바이브코딩으로 만든 DSS가 업데이트 됐습니다.

Trivy 업데이트로 인해 스캔 결과가 대시보드에 뜨지 않던 문제가 해결되었습니다

Postgres DB 취약점 해결을 위해 zlib 취약점을 apt upgrade를 root 권한으로 실행하여 해결한 후 다시 일반 사용자 권한으로 전환했습니다.

services:
  # PostgreSQL 데이터베이스
  db:
    image: dokkaeb1/scanner-db:latest
    container_name: scanner-db
    restart: always
    environment:
      POSTGRES_DB: ${POSTGRES_DB}
      POSTGRES_USER: ${POSTGRES_USER}
      POSTGRES_PASSWORD: ${POSTGRES_PASSWORD}
      TZ: Asia/Seoul
    volumes:
      - postgres_data:/var/lib/postgresql/data
    healthcheck:
      test: [ "CMD-SHELL", "pg_isready -U ${POSTGRES_USER}" ]
      interval: 10s
      timeout: 5s
      retries: 5
    logging:
      driver: "json-file"
      options:
        max-size: "5m"
        max-file: "3"

  # FastAPI 백엔드
  backend:
    image: dokkaeb1/scanner-backend:latest
    container_name: scanner-backend
    restart: always
    environment:
      DATABASE_URL: ${DATABASE_URL}
      TZ: Asia/Seoul
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock
      - trivy_cache:/root/.cache/trivy
    depends_on:
      db:
        condition: service_healthy
    logging:
      driver: "json-file"
      options:
        max-size: "10m"
        max-file: "5"

  # Next.js 프론트엔드
  frontend:
    image: dokkaeb1/scanner-frontend:latest
    container_name: scanner-frontend
    restart: always
    environment:
      NEXT_PUBLIC_API_URL: http://backend:8000
      NODE_ENV: production
      TZ: Asia/Seoul
    ports:
      - "3000:3000"
    depends_on:
      - backend
    logging:
      driver: "json-file"
      options:
        max-size: "10m"
        max-file: "3"

volumes:
  postgres_data:
  trivy_cache:

docker-compose.yml 파일이 수정됐습니다

NanoKVM Pice 설치, 설정 및 사용 후기

dae-ya — Sun, 8 Mar 2026 02:27:19 +0900

서버를 새로 설치하다 보니 바이오스 세팅을 건드려야 하는 일이 많았다.

하지만 집에는 모니터가 주 컴퓨터에 연결되어 있는 상태라 바이오스 세팅을 위해 서버를 가져와서

기존 모니터의 선을 뽑아 서버 컴퓨터에 연결하는 매우 매우 귀찮은 방법을 이용하고 있었다. 이렇게 바이오스를 5번 넘게 들어가니 진짜 하고 싶은 세팅을 포기하고 싶을 정도로 하기가 싫어졌다.

그래서 여러 방법을 강구했다.

1. 캡처보드 구매

2. KVM 스위치 구매

3. KVM over IP 구매

1번은 서버에 키보드 마우스를 연결해야하는연결해야 하는 과정이 남아있으며, 주 컴퓨터에 캡처보드 설치 후 선을 연결해야 하는

과정이 남아있어 모니터 연결과 다를 게 없었다.

2번은 서버와 모니터까지와 선을 연결하고 있어야 하며 1번과 동일하게 키보드 마우스를 연결해야 한다.

3번은 웹페이지로 화면을 보며 모니터 마우스 역할까지 하므로 현재 상태에 가장 맞는 방법이라고 생각했다.

KVM over IP는 간단한 SBC를 이용하여 물리적으로는 서버 주변 또는 서버 안에 장착되며 HDMI, USB로 서버와 연결되어

화면과, 키보드 마우스의 역할을 하고 관리자는 KVM에 연결된 랜선을 통해 웹으로 접속하여 관리를 하는 기기이다.

기업에서 많은 서버들을 관리하기 위해 쓰고 있으며 서버용 기기답게 가격도 홈랩 기준으로 사악하다.

하지만 늘 그렇듯 사람들은 정답을 찾아냈는데 SBC를 이용하는 KVM이다 보니 SBC의 대표적인

라즈베리파이를 이용하여 구현하는 것이다.

관련해서 내용을 알아보니 라즈베리에 카메라를 달기 위한 슬롯에 HDMI 입력을 받을 수 있는 보드를 붙이고 키보드 마우스 역할을

라즈베리파이 C타입으로 구현을 한 것이다. PiKVM으로 잘 알려진 방법이다.

처음엔 라즈베리파이도 가지고 있으므로 PiKVM을 사용하려고 했지만 다양한 단점이 있었다.

1. 현재 가지고 있는 라즈베리파이 케이스와의 호환성

2. 생각보다 높은 각 부품의 가격

3. 내장되지 않아 작지만 추가 공간 필요

그래서 PiKVM은 제외하고 알아보았고 생각보다 많은 제품이 있다는 것을 알게 되었지만 눈에 들어온 건 NanoKVM이다.

NanoKVM은 많은 장점을 가지고 있었다.

1. 다양한 버전 (Lite, Full, Pcie, Pro 등)

2. 낮은 가격

3. tailscale 내장

4. 오픈소스

5. 다양한 후기

물론 장점만 있던 건 아니다. 단점도 있었다.

1. 국내 미정발로 인한 AS문제

2. 제조국으로 인한 불안

3. 보안 이슈

특히 제일 중요한 건 보안 이슈였는 데 사용된 소스를 깃헙에 오픈했고 알아보았을 때 중국 DNS를 쓰는 걸로 알았지만 사용한 현재

로그를 확인하니 8.8.4.4 구글 DNS를 사용하는 것으로 밝혀졌다.

또한 최근 내장 마이크 사건이 붉어진 적이 있는데 꽤 크게 번졌다.

https://news.hada.io/topic?id=24886

중국산 NanoKVM에서 숨겨진 마이크를 발견한 과정 | GeekNews

중국 Sipeed가 개발한 NanoKVM은 원격으로 PC나 서버를 제어할 수 있는 초소형 하드웨어 KVM 스위치로, 저가와 오픈소스 공개 약속으로 주목을 받았음장치는 HDMI·USB-C·이더넷 포트를 갖추고 브라우저

news.hada.io

하지만 관련 사건을 실시간으로 퍼지는 것을 보고 있던 나는 꽤 이상하게 와전되는 걸 알 수 있었다.

간단하게 말하면 마이크는 있는 게 맞았고 비활성화되어있지만 활성화시킬 수 있었다.

하지만 가격을 줄이기 위해 쓴 기본 SBC보드에 이미 마이크가 달려있었고 NanoKVM에서 보드에 설치한 게 아니다.

(NanoKVM 상품 페이지에 안 쓰여있는 건 NanoKVM 쪽 잘못)

활성화시키면 녹음도 가능하지만 NanoKVM 터미널을 사용해야 하므로 직접 NanoKVM을 외부로 노출시키지 않는 한 문제가 될 수 없다. (직접 노출은 서버의 SSH를 외부노출 시키는 것과 같음)

그래서 서버 커뮤니티에서도 녹음이 되는 것을 확인했지만 터미널 접근 할 방법이 사실상 없어 상관없다고 결론짓는 분위기였다.

그래서 NanoKVM Pcie 버전을 구매했고 가장 간단하게 PoE 없고, 무선도 없는 버전을 구매했다. (구매 당시 6만 원)

설치 후 Proxmox Shell도 웹으로 잘 보이고 입력도 잘 되는 것을 볼 수 있었다.

충분히 만족스러웠지만 추가 설정이 필요했다.

1. mdns 해제

2. 고정 ip

3. 방화벽설정 및 ntp 서버 수정

1. mdns는 내부 네트워크에 멀티캐스팅을 하여 자신을 알리기 때문에 트래픽이 증가한다.

설정-장치-mdns 해제했다.

2. 매번 접속 시 ip가 바뀌면 찾기 힘들기 때문에 고정 ip를 부여했고 일반 우분투나 페도라 같은 방법과 다른 방법으로 설정했다.

https://wiki.sipeed.com/hardware/en/kvm/NanoKVM/network/static_ip.html

Static IP - Sipeed Wiki

Static IP 2026-02-09 By default, NanoKVM obtains its IP address via DHCP, which means the IP address may change. If you want to always access NanoKVM using the same IP address, you can set a static IP. Here are two methods to set a static IP: Setting Stati

wiki.sipeed.com

공식 문서를 참고하여 구성했다

nano /boot/eth.nodhcp
# eth.nodhcp 생성 및 수정

192.168.10.xxx/24 192.168.10.1
# ip 주소/서브넷마스크 게이트웨이

/etc/init.d/S30eth restart
# 고정 IP 인식을 위한 재시작

3. 아무리 오픈소스이지만 보안은 중요하므로 방화벽을 사용해 아웃바운드는 모두 다 차단했다.

업데이트 확인이 불가능하지만 업데이트 파일을 업로드하는 기능도 있으므로 큰 상관이 없다고 생각했다.

OPNsense에서 Firewall-Rules-LAN으로 이동한다.

+를 이용해 규칙을 추가한다.

Action: Block

Interface: LAN

Direction: in (outbound이지만 방화벽 입장에서는 in이기 때문에 in으로 설정
Direction of the traffic. Traffic IN is coming into the firewall interface, while traffic OUT is going out of the firewall interface. In visual terms: [Source] -> IN -> [Firewall] -> OUT -> [Destination]. The default policy is to filter inbound traffic, which means the policy applies to the interface on which the traffic is originally received by the firewall from the source. This is more efficient from a traffic processing perspective. In most cases, the default policy will be the most appropriate.)

Protocol: any
Source: Single host or Network 선택 후 NanoKVM IP 입력

Destination: any

이렇게 되면 모든 아웃바운드가 차단된다.

하지만 시간동기화도 차단되므로 NTP서버를 외부가 아닌 OPNsense로 바꿔야 한다.

기본적으로 OPNsense는 자체적으로 NTP 서버 서비스가 실행 중이므로 NanoKVM에서 오는 요청은 허용해야 한다.

OPNsense에서 Firewall-Rules-LAN으로 이동하여 규칙을 하나 더 추가한다.

Action: Pass

Interface: LAN

Direction: in

Protocol: UDP

Source: Single host or Network 선택 후 NanoKVM IP 입력

Destination: This Firewall

Destination port range: NTP

으로 설정하고 추가 규칙이 없다는 가정 하 Pass 규칙이 1번 Block 규칙이 2번으로 설정되야 한다.

그럼 NanoKVM에 NTP서버가 바뀌었다고 알려줘야 한다.

nano /etc/ntp.conf

내용에 4개 server들이 있는데 #으로 주석처리 한 다음

server OPNsense주소 iburst 를 입력한다.

그다음 reboot으로 재시작한다.

그럼 OPNsense log를 보면 게이트웨이를 통과하지 못하여 인터넷 통신이 불가한 걸 볼 수 있다.

12~14세대 vGPU Proxmox에서 설정, 우분투 적용

dae-ya — Thu, 5 Mar 2026 14:54:13 +0900

vGPU란 하나의 GPU를 가상으로 쪼개 각 vm에 할당하여 하드웨어 가속을 할 수 있게 하는 기술이다.

이걸 통해 윈도우 VM에 하드웨어 가속으로 편집을 할 수 있고 리눅스 VM에서 트랜스코딩용으로 쓸 수 있다.

CPU를 통해 이러한 작업을 하면 과도한 사양을 쓰기 때문에 서버가 과부하 될 수 있다.

이런 좋은 기술을 쓰기 위해 여러 문제와 세팅을 하며 설정을 완료 할 수 있었다.

인텔 5세대이상 10세대 이하에서는 GVT-g라는 기술로 vGPU를 지원했다.

소프트웨어적으로 그래픽을 쪼개는 기술이며 리눅스 커널에 드라이버가 이미 포함되어 있어 세팅이 간편하다.

Proxmox GRUB 설정에 i915.enable_gvt=1을 추가하면 된다.

그럼 VM 하드웨어에서 Mapped Device를 선택하여 VRAM 크기만 지정하면 된다.

하지만 12세대 이상 14세대 이하(11세대 미포함) CPU는 GVT-g 기술 지원이 끊겼고 기업용 서버 기술이던 SR-IOV를 소비자용 CPU에 넣으면서 여러 설정을 바꿔야 한다.

소프트웨어적으로 분리를 하는 것이 아니라 하드웨어 자체에서 그래픽을 물리적으로 나눈다.

이때 리눅스 커널에서는 공식적으로 이 기능을 지원하지 않는다.

그래서 사용자가 직접 커스텀 패치를(DKMS)를 빌드하여 올려야 한다.

다행히도 커스텀 드라이버를 다운받을 수 있게 Github에 올려주신 고마운 분이 계신다.

https://github.com/strongtz/i915-sriov-dkms?tab=readme-ov-file

GitHub - strongtz/i915-sriov-dkms: dkms module of Linux i915 driver with SR-IOV support

dkms module of Linux i915 driver with SR-IOV support - strongtz/i915-sriov-dkms

github.com

먼저 Proxmox 패키지를 업데이트 하고 커널 버전에 맞게 수정하기 위한 패키지를 다운로드한다.

apt update && apt install pve-headers-$(uname -r) git dkms build-essential -y
git clone https://github.com/strongtz/i915-sriov-dkms.git
cd i915-sriov-dkms
dkms add .
dkms install -m i915-sriov-dkms -v $(cat VERSION) --force

install를 통해 i915 드라이버를 리눅스 커널 시스템에 등록한다.

nano /etc/default/grub

GRUB 부트로더를 수정하여 GRUB_CMDLINE_LINUX_DEFAULT 항목에 아래 파라미터를 추가한다.

intel_iommu=on iommu=pt i915.enable_guc=3 i915.max_vfs=7
# 가상 그래픽을 7개로 나눈 상태 개수 수정시 max_vfs 값을 수정하면 된다.
# 인텔 내장 그래픽 아키텍처는 슬롯이 8개까지만 가질수 있고 
# 그중 한개는 무조건 Proxmox 본체가 가져야한다.
# 그래서 7개가 가상으로 분리가 된다. 7개까지가 최대이며 줄일수는 있지만 8개 이상으로 늘릴수는 없다.

저장하고 나오며 GRUB에 수정한 내용을 인식시켜야 한다.

update-grub
update-initramfs -u
# 리눅스는 재부팅시 initramfs라는 작은 임시 운영체제 파일 시스템을 램에 올린다. 
# 이 값을 업데이트 해야 GRUB 수정값을 인식 할 수 있다.
reboot

재부팅 이후 가상 그래픽을 7개로 쪼개는 명령어를 입력해야 한다.

echo 7 > /sys/class/drm/card0/device/sriov_numvfs
# 이전 과정에서 개수를 수정했다면 이 명령어도 수정해야한다.
lspci | grep VGA

lspci 명령 결과에서 7개 장치가 나오면 성공이다.

VM에 vGPU을 할당하기 위해 주의해야 할 점이 있다.

hardware-add-pci device에서 설정하며 raw device에서 00:02.0이 아닌 00:02.1~7까지 선택하면 된다.

또한 PCI-express는 체크하며 ROM-bar를 반드시 체크 해제해야 한다. vGPU는 물리적 ROM이 없기 때문에 ROM-bar를 켜두면

부팅 시 오류가 발생한다.

모든 설정을 완료하고 나서 먼저 윈도우 VM에 vGPU를 할당, 드라이버 설치하여 테스트를 해봤을 때 정상적으로 작동을 했다.

그래서 실 사용 중인 우분투 VM에 바로 윈도우 VM과 동일하게 설치를 진행했다.

하지만 /dev/dir 디렉터리에 renderD128이 존재하지 않고 card0만 있었다.

이러면 vGPU가 정상적으로 인식되지 않았다는 뜻이었다.

무엇이 문제인지 확인하기 위해 우분투 쉘에서 로그를 확인해 보기로 했다.

dmesg | grep -iE "i915|xe|drm"

로그를 확인했더니 아래와 같은 로그가 남아있었다.

[ 3.850143] i915 0000:01:00.0: [drm] *ERROR* Device is non-operational; MMIO access returns 0xFFFFFFFF!
[ 3.850705] i915 0000:01:00.0: Device initialization failed (-5)

왜 이런 오류가 나는지 확인해 봤다.

우분투 커널에는 기본적으로 있는 i915 드라이버는 인텔 12세대 이상 쪼개진 내장그래픽을 완벽하게 동작하게 하지 못하므로 순정 드라이버가 vGPU를 일반 그래픽 방법처럼 접근하려다가 거부당하고 커널 패닉이 된 상태이다.

즉 드라이버가 제대로 인식을 못한 상황이라 Proxmox처럼 커스텀 드라이버를 설치하면 된다.

sudo apt update && sudo apt install git dkms build-essential linux-headers-$(uname -r) -y

그래서 Proxmox와 동일하게 명령어를 입력했다.

하지만 dkms install를 했더니 오류가 떴다.

Error! The ... dkms.conf for module i915-sriov-dkms includes a BUILD_EXCLUSIVE directive which does not match this kernel/arch/config.
This indicates that it should not be built.

이거 또한 알아보았다.

현재 사용 중인 우분투의 버전은 24.04 LTS 버전이다.

커널을 6.8 버전을 쓰고 있다.

하지만 Github에 올라온 드라이버는 6.12 이상부터 지원이므로 우분투 커널버전에 맞춰 드라이버를 다운그레이드하여 받으면 됐다.

2025.07.22 버전으로 다운그레이드 하여 다운을 했다.

git clone https://github.com/strongtz/i915-sriov-dkms.git
cd i915-sriov-dkms
git checkout 2025.07.22 # 버전 다운그레이드
sudo dkms add .
sudo dkms install -m i915-sriov-dkms -v 2025.07.22 --force

마지막 명령어처럼 07.22 버전을 강제로 설치했고 잘 설치됐다.

그래서 작업이 잘 완료됐는지 확인하기 위해 모듈을 확인해 봤다.

sudo modprobe i915

하지만 또 오류가 생겼다

modprobe: ERROR: could not insert 'i915': Key was rejected by service

키가 거부되었다고 나와 검색해 보니 커스텀 드라이버를 보안상 허용시킬 수 없어서 나타난 오류라고 확인했다.

즉 보안부팅 때문에 생긴 오류이므로 보안 부팅을 꺼주기로 했다.

다행히 보안부팅을 끄는 과정은 굉장히 쉬웠다 일반 PC 바이오스 설정처럼 우분투 VM 부팅 시 ESC를 눌러 옵션을 설정한다

Device Manager-Secure boot configuration을 진입하면 Attempt secure boot 체크 표시를 해제한다.

바이오스와 같이 F10을 눌러 저장하고 나오면 모듈이 잘 작동하는 것을 알 수 있다.

하지만 재부팅 시 우분투가 순정 드라이버를 꺼내 올 수 있으니 이 드라이버를 쓰라고 고정해야 한다.

echo "i915" | sudo tee -a /etc/modules
sudo update-initramfs -u

마지막 명령을 입력하지 않으면 다시 순정 드라이버를 쓰므로 꼭 입력해야 한다.

그다음으로 잘 작동하는지 보기 위해 다음 명령어를 입력해 확인해 보면 된다.

ls -l /dev/dri

그럼 renderD128이 잘 나오는 걸 볼 수 있다.

서버 변경 및 후기

dae-ya — Wed, 4 Mar 2026 16:06:53 +0900

서버를 변경하고 싶은 마음은 예전부터 있었다.

N100 미니 PC에 만족하지 못하고 있었고 하드를 연결하기 힘들다는 단점 그리고 부족한 코어 수 때문에 원하는 작업이 힘들고

중국제 미니 PC이기 때문에 vGPU 작업에 필요한 바이오스 설정이 없기 때문에 vGPU 설정도 힘들었다.

그래서 서버를 바꿨다.

완제품 서버가 아니라 자작으로 만들고 싶었다.

비용은 많이 들겠지만 원하는 케이스를 쓸 수 있다는 장점이 너무나 끌렸다.

그래서 약 6개월 동안 천천히 부품을 모았다.

CPU: 13500

CPU 쿨러: 녹투아 L9i 17xx

RAM: Klevv 3200 16기가*2

메인보드: 기가바이트 h610m k d4

파워: 시소닉 SF750

랜카드: i266v 듀얼랜

HBA카드: L9i-9211 8i

추가 팬: NF-A12x25, NF-A4x10

HDD: WD RED PLUS 4TB*2

SSD: 500기가 nvme, 850 evo ssd

케이스: Beverly NAS case

일단 h610 보드중에 저 보드는 가장 싼 보드이다 13500이 감당하기 힘들 수 있지만 PL2 값을 65w으로 내렸고 전원부 방열판이 없기 때문에 플라워형 쿨러가 전원부까지 같이 쿨링을 해준다.

케이스는 굉장히 마음에 들지만 여러 문제가 있다.

- 도장이 허술하다. 나사를 조였다가 풀면 도장이 벗겨진다.

- 사용설명서가 없다. 어느 나사를 써야하는지 많은 지식이 없으면 꽤 고생할 수 있다.

- 부품 호환성이 별로다. 물론 작은 케이스인 만큼 부품 호환성을 타는 건 맞지만 SFX 파워에 u-atx 메인보드는 보기 힘들다.

하지만 모든 단점을 상쇄하는 장점인 예쁘다가 있다.

서버를 변경한지 2개월 정도 지난 지금 아직도 만족 중이다.

- 많은 CPU 코어를 통한 이미지 업스케일링 도커 구현

- 넉넉한 램 용량으로 인한 추가 VM 및 기존 VM 램 용량 증설

- vGPU를 통한 각 VM에 하드웨어 가속 가능 (추후 기술 예정)

- 성능 향상을 했지만 저소음 부품을 통한 소음 저하

- 확장성 향상

물론 나쁜 점도 있다.

- 늘어난 전기세

- 가끔씩 생기는 파워 고주파음

- 미니 PC보다 큰 부피

하지만 말하고 싶은 건 사고 싶은 케이스가 딱히 있지 않으면 케이스는 적당히 큰 걸 쓰는 게 좋다.

또한 서버 변경으로 인해 많은 점이 변경되었는데 이거 또한 추후 서술 하겠다.

OMV에서 Unraid os 변경기

dae-ya — Sun, 15 Feb 2026 00:04:11 +0900

2년 넘게 OMV를 쓰고 있었다.

proxmox에서 간단하게 운영이 가능했으며 고급기능이 필요하지 않아 적당하게 사용이 가능했다.

하지만 추후 서술할 하드웨어 변경기 때문에 많은 문제가 생겼다.

가장 큰 이유는 HDD를 2개 구매 후 2개를 나중에 추가할 예정이기 때문에 하드 추가가 자유로워야 하지만

RAID 5,6는 구성 시 하드가 모두 있어야 한다는 단점이 있고 하드의 용량과 종류가 모두 같아야 한다는 단점도 있다.

그래서 원래 쓰던 OMV의 RAID나 TrueNAS의 ZFS로 구성은 힘들 것 같아 많은 확인을 해보았다.

여러 가지 선택지가 있었다.

1. 시놀로지 SHR

2. Unraid

3. snapraid+mergerfs

1번은 SHR을 쓰려면 시놀로지 또는 헤놀로지를 써야 한다는 단점이 있다.

2번은 OS가 유료이다.

그래서 처음에는 익숙한 OMV에 snapraid+mergerfs의 조합으로 사용해보았다.

OMV 8 기준 omv-extras 플러그인과 apt로 구성이 가능했다.

하지만 구성한 지 2시간 만에 후회했다.

OMV에서 snapraid+mergerfs은 불편함을 가지고 있었다.

하드 스핀다운 사용 시 mergerfs가 풀려버려 공유폴더가 다 사용불가 해진다.

SMB, NFS 설정 변경 시 mergerfs가 풀린다. 이로 인해 Web UI에서 mergerfs pool를 재시작해야 한다.

이 두 개만으로 바로 후회했다.

이제 선택지가 2개가 남았는데 헤놀로지는 사용할 생각이 없고 하드웨어는 조립까지 다 완성이 된 상태이므로 실질적으로는 Unraid 밖에 남지 않았다.

일단 30일 무료 체험이 가능하기 때문에 구성해보기로 결심했다.

Unraid는 특이하게 부트 디스크를 USB로 구성한다.(설치 디스크 X)

즉 USB가 없으면 부팅 자체가 불가하다.

또한 USB의 UUID가 결제 때 필요하므로 이름 없는 USB나 밀알 같은 UUID가 제대로 없는 USB는 사용하면 안 된다.

USB 2.0으로 연결해도 속도가 충분하고 발열이 적다.

추천하는 제품은 샌디스크 z43 제품이다.

USB 자체가 작아 좁은 공간에 설치가 가능하고 스틱형 USB는 툭 치면 부러질 수 있지만 z43 제품은 가능성이 낮다.

하지만 그래도 외부에 USB를 설치하는 걸 불안하다면 아래와 같은 제품으로 메인보드 9핀에 바로 꽂을 수 있다.

설치 과정은 간단했고 Unraid 무료 체험 이후 구매를 하고 싶을 정도로 매우 만족했다.

pool 구성시 오류가 없으며 Docker 지원하여 Apps에서 다운을 받아 실행 가능하며 vm도 지원한다(하이퍼바이저 타입 2)

또한 Web UI에서 Pool 내용을 볼 수 있다는 점도 컸다.

현재까지는 매우 만족 중이고 Proxmox를 버리고 주 OS로 갈까라는 생각이 들 정도로 편하고 쉽게 구성이 가능하다.

가장 중요한 Unraid의 가격은 3가지로 이루어져 있다.

Starter: 49달러에 총 6개 HDD or SDD까지 가능, 1년 업데이트 지원

Unleashed: 109달러에 무제한 디바이스, 1년 업데이트 지원

Lifetime: 249달러에 무제한 디바이스, 무제한 업데이트 지원

처음 보면 좀 부담되는 가격이다.

하지만 하드 4개 정도밖에 안 되고 1년 이후에도 업데이트만 안될 뿐 사용이 가능하며 업데이트가 필요할 때 낮은 가격으로 1년 지원을 다시 받을 수 있어 49달러라는 가격은 충분히 메리트 있다고 본다.

만약 하드 용량이 제각각이거나 아니면 하드를 차근차근 구매 및 변경을 할 예정이면 Unraid 추천한다.

Docker Scanner Service

dae-ya — Mon, 19 Jan 2026 11:37:33 +0900

바이브 코딩으로 여러 프로젝트를 만들어보았지만 다른 더 좋은 프로젝트가 많거나 완성도가 별로였던 프로젝트가 많았다.

하지만 이번 프로젝트는 서버에 적용해서 써봐도 괜찮다고 생각하여 공유해보려고 한다.

Antigravity로 gemini3와 Sonnet 4.5를 이용해서 만들어보았다.

이 프로젝트는 서버 내의 도커 이미지를 가져와 trivy(CVE, 보안 취약점 정밀 분석 엔진)로 분석한 다음 취약점을 webui로 보여주는 기능을 한다.

주요 기능

-자동 취약점 스캔(매일 00시)

-실시간 대시보드(한국어 UI)

-CVE 상세 정보 제공

-수정 정보 자동 표시

-심각도별 필터링

-Docker Hub 이미지 지원

기술 스택

- Backend: FastAPI, PostgreSQL, Trivy

- Frontend: Next.js 16, React 19

- 라이선스: Apache 2.0

권장사양

- RAM: 최소 2GB (권장 4GB)

- 디스크: 1GB (Trivy DB 포함)

- Docker 엔진 필수

프로젝트는 docker compose로 다운가능하다.

docker-compose.yml을 생성하여 아래 내용을 복사 붙여 넣기 하면 된다.

services:
  # PostgreSQL 데이터베이스
  db:
    image: postgres:17-alpine
    container_name: scanner-db
    restart: always
    environment:
      POSTGRES_DB: ${POSTGRES_DB}
      POSTGRES_USER: ${POSTGRES_USER}
      POSTGRES_PASSWORD: ${POSTGRES_PASSWORD}
      TZ: Asia/Seoul
    volumes:
      - postgres_data:/var/lib/postgresql/data
    healthcheck:
      test: [ "CMD-SHELL", "pg_isready -U ${POSTGRES_USER}" ]
      interval: 10s
      timeout: 5s
      retries: 5
    logging:
      driver: "json-file"
      options:
        max-size: "5m"
        max-file: "3"

  # FastAPI 백엔드
  backend:
    image: dokkaeb1/scanner-backend:latest
    container_name: scanner-backend
    restart: always
    environment:
      DATABASE_URL: ${DATABASE_URL}
      TZ: Asia/Seoul
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock
      - trivy_cache:/root/.cache/trivy
    depends_on:
      db:
        condition: service_healthy
    logging:
      driver: "json-file"
      options:
        max-size: "10m"
        max-file: "5"

  # Next.js 프론트엔드
  frontend:
    image: dokkaeb1/scanner-frontend:latest
    container_name: scanner-frontend
    restart: always
    environment:
      NEXT_PUBLIC_API_URL: http://backend:8000
      NODE_ENV: production
      TZ: Asia/Seoul
    ports:
      - "3000:3000"
    depends_on:
      - backend
    logging:
      driver: "json-file"
      options:
        max-size: "10m"
        max-file: "3"

volumes:
  postgres_data:
  trivy_cache:

추가로. env파일도 필요한데 아래 내용을 붙여 넣고 필요한 대로 수정하면 된다.

POSTGRES_DB=scannerdb
POSTGRES_USER=scanner
POSTGRES_PASSWORD=your_secure_password
DATABASE_URL=postgresql://scanner:your_secure_password@db:5432/scannerdb

webui가 지원되므로 3000번 포트로 접속하면 된다.

프로젝트에 2026-01-19 기준 특징이 있는데

백엔드에서 취약점이 2개

SQL에서 취약점이 12개

총 14개가 기본으로 있다는 점이다.

백엔드에서는 Trivy 엔진 자체 취약점이 있고

postgreSQL에는 아직 업데이트가 되지 않은 취약점이 12개가 있어서 14개의 취약점은 수정이 불가능하다.

이미지 선택, 해제 기능도 있으므로 원하는 이미지만 볼 수 있다.

Npm+Adguard를 이용해 포트를 포함한 로컬 dns 환경 구축

dae-ya — Wed, 17 Dec 2025 13:13:49 +0900

이전 블로그의 글을 보면 내부망용 dns용으로 Adguard를 쓴다고 얘기했었다.

이때 단순히 Adguard의 DNS 변경탭에서 Domain Name을 지정하고 서버 ip를 입력해도 하나의 서버(ip) 안에서 포트 번호만 다르 실행 중인 여러 서비스들을 Domain Name으로 구분할 수 없다.

예를 들어 192.168.0.10:1000에는 A라는 웹 서비스를, 192.168.0.10:2000에는 B라는 웹 서비스를 운영 중이라면, Adguard의 DNS 변경으로는 서비스를 구분하지 못하고 example.com:1000, example.com:2000 같이 꼭 뒤에 포트를 붙여 구분해야 한다.

ip숫자를 외우지 않기 위해 dns를 쓰지만 포트 번호는 외워야 한다는 점이 귀찮아진다.

Npm+Adguard를 통해 그 점을 막을 수 있다.

간단한 원리를 설명하자면 Adguard로 들어온 Domain을 npm의 ip로 지정하고 npm은 리버스 프록시의 역할을 하여 다시 Domain을 읽어 포트를 포함한 서비스에 보내주는 것이다.

물론 이 전 과정이 내부에서만 통신하기 때문에

설정은 매우 간단하다.

Adguard에 접속하여 필터-DNS 변경에서 자신이 설정하고 싶은 Domain Name 앞에 *를 붙여 와일드카드 방식으로 작동하게 하면 된다. (ex. *. example.com)

주로 실제 있는 도메인보다는 내부망이라는 느낌을 주는 단어로 설정하는 것을 추천한다.

아래의 ip주소에는 npm의 주소를 입력하면 된다.

이렇게 설정 시 Adguard에서는 새로운 서비스가 추가되어도 추가 설정할 필요가 없다.

하지만 npm은 새로운 서비스가 추가될 때마다 계속하여 추가 설정을 해야 한다.

npm에서는 Hosts에서 New proxy Host로 추가하면 된다.

이렇게 추가를 하게 되면 접속이 가능한 걸 알 수 있다.

접속이 불가한 상황은 2가지로 나눌 수 있는데

첫 번째는 자동으로 검색창으로 넘어가는 상황

이때는 http:// 또는 https:// 각자의 설정에 따라 붙여주면 된다.

두 번째는 서비스에서 도메인접근을 막는 경우이다.

CUPS나 OPNSENSE 등은 보안상의 이유로 막는다.

그래서 따로 설정을 해서 바꿀 수는 있지만 보안상의 이유로 추천은 하지 않는다.

또한 사용하는 기기에서 dns를 Adguard로 바꾸거나 라우터에서 dns를 내부 dns로 바꿔야 한다.

하지만 이러한 단점을 상쇄할 너무나 큰 편리함이 있기 때문에 보안적인 설정이 잘 되어있다면 이러한 설정을 하는 것을 추천한다.

Wireguard를 통해 외부에서 홈 네트워크 접속하기

dae-ya — Sun, 23 Nov 2025 21:58:35 +0900

외부에서 홈서버나 다른 기기에 네트워크로 접근을 하려면 포트포워딩을 통해 포트를 열거나 터널링을 통해 인터넷에 서버를 열어놓아야 한다.

포트포워딩을 통해 직접 서버에 접근을 할 수 있게 해 놓으면 보안이 취약해지고 ssh서버에 접근하기 위해 22번 포트를 열어놓으면 해킹을 당할 수도 있다. 그렇다고 터널링을 통해 인터넷에 서버를 열어놓으면 해킹의 위협이 당연하게 높아진다.

이것을 해결하고자 사람들은 vpn을 사용해 내부망으로 바로 접속하여 보안을 지키면서 서버에 접근을 한다.

대표적인 vpn 오픈소스는 2가지가 있다.

OpenVPN

Wireguard

-tailscale은 Wireguard기반이며 내부망에 바로 접속이 가능한 vpn보다는 각 기기를 이어주는 방법에 가깝기 때문에 제외했다

-PPTP/L2TP 방식은 이미 구형방식이라 보안성이 낮아 제외했다.

OpenVPN은 강력한 보안을 지원하지만 설정이 복잡하고 인증서 갱신이 필요하며 속도가 느리다

Wireguard는 설정이 간편하고 최신 암호화를 지원하며 속도가 빠르다 하지만 기업환경에서는 아직은 이르다는 평이 있다.

그래서 홈 네트워크에는 Wireguard가 가장 좋다고 생각한다.

Wireguard 서버를 만드는 방법은 다양하게 있지만 iptime의 최신 공유기를 쓰고있다면, iptime 공유기에서 설정하는 것을 가장 추천한다.

iptime 공유기에서 Wireguard 서버 생성하기

iptime web ui를 보면 vpn 설정 탭을 볼 수 있다.

Wireguard 서버 설정을 들어간다.

아래의 설정과 같이 설정을 하면 된다.

NAT를 켜야 내부망과 통신이 가능하다.

만약 NAT 꺼짐으로 놓으면 인터넷 접속 IP가 서버의 IP로 변경될 뿐 내부망의 통신은 불가 하다.

인터페이스 주소는 개인이 마음대로 입력하면 된다.

사용자 추가도 간단하다.

피어 추가를 누른 다음 자동 피어 추가에서 이름만 입력하면 피어 추가가 완료된다.

아래에 쓰여있듯 클라이언트 기기에서 Wireguard를 설치한 다음 추가된 다음 자동 생성되는 QR코드를 찍기만 하면 피어 추가가 완료된다.

클라이언트 기기에서 Wireguard를 활성화하면 vpn이 자동으로 실행된다.

여러 방법으로 Wireguard 서버를 구성해 보았지만 공유기에서 Wireguard를 구성하는 것이 가장 간편하다고 생각한다.

proxmox에서 NAS OS vm 생성 시 주의해야 할 점

dae-ya — Sun, 23 Nov 2025 19:47:07 +0900

proxmox를 사용하면서 생성하게 될 vm 중에 가장 대표적인 것이 NAS OS라고 생각한다.
OMV나 TrueNas 등이 있을텐데 이러한 OS들을 vm으로 생성 시 유의해야 할 점이 있다.
먼저 HDD나 SSD를 NAS VM으로 패스스루 하여 인식을 시켜야 SMB나 FTP서버를 만들 수 있을 텐데
그렇게 되면 문제가 생겨버린다.

생기는 문제

HDD를 패스스루 하게 되면 S.M.A.R.T. 기능을 사용할 수 없다.

이유

vm은 실제 하드디스크가 아니라 proxmox가 만든 가상 디스크를 보기 때문에 이러한 문제가 생긴다.
하드디스크를 가상의 장치로 포장하여 vm으로 전달하고 또한 하드웨어 제어 및 상태 점검 신호는 vm으로 전달하지 않기 때문에 vm은 하드디스크의 건강상태를 알 수 있는 정보를 받지 못한다.

해결법?

이 문제를 해결할 수 있는 방법은 HDD를 연결한 SATA 컨트롤러를 vm으로 패스스루 하는 것이다.
SATA 컨트롤러를 패스스루하면 S.M.A.R.T. 기능을 사용할 수 있게 되고 하드의 건강상태를 확인할 수 있게 된다.

이러한 해결법으로 생기는 문제

위의 방법이 무조건 해결되는 방법이 아니다.
자작 NAS를 사용하는 사람들은 아주 고급 사용자가 아닌 이상 일반 데스크톱용 부품들을 사용할 것이다.
이렇게 되면 SATA 컨트롤러가 묶여있는 IOMMU 그룹이 통째로 vm에 패스스루 된다.
예를 들어 SATA 컨트롤러, LAN, USB 컨트롤러가 IOMMU 그룹으로 묶여있다고 가정하면 SATA 컨트롤러를 패스스루 시 나머지 LAN, USB 컨트롤러까지 같이 패스스루 된다.

문제 해결법

그럼 이 문제를 어떻게 해결해야 하냐면
첫 번째, IOMMU 그룹이 잘 분리되어있는 메인보드를 구매한다.
일반 H, A, B, Z, X보드에서 IOMMU 그룹이 잘 분리되어 있는 메인보드를 구매 후 패스스루 하면 되지만 거의 이러한 메인보드를 보기 힘들 정도로 구하기가 쉽지 않다.
그래서 서버용 메인보드를 구매해야 하는데, 이러한 경우 모든 부품값보다 메인보드 값이 더 나가는 경우를 볼 수 있다.
(ex.W790, W680)

두 번째, HBA카드를 구매해 패스스루 한다.
HBA카드란 서버를 스토리지 장치에 연결하여 데이터 입출력을 처리하는 장치로 정확한 의미는 아니지만 일종의 SATA 컨트롤러의 역할을 한다.

HBA카드의 한 종류인 LSI 9300-8i

PCIE에 연결하여 패스스루 한다면 S.M.A.R.T. 기능을 사용가능하며 IOMMU 그룹가 분리되어 다른 문제가 생기지 않는다.

중고로 구매한다면 2~3만 원대로 구매가 가능해서 서버용 메인보드보다 아주 좋은 해결 방법이 될 것이다.

proxmox에서 NAS OS를 설치할 예정이라면 HBA카드 구매를 추천한다.