[태그:] proxmox

작성일자

I1. Proxmox 첫 설치 – 막혔던 포인트 전부 기록

홈서버를 하기로 마음먹고 가장 먼저 부딪힌 건 서비스도, 설정도 아닌 설치 자체였다.
Proxmox라는 이름은 이미 수없이 봤고, NAS 운영기나 홈랩 글에서도 자주 등장했다.
그래서 처음엔 이걸 “조금 낯선 리눅스 설치” 정도로 생각했다.

지금 돌이켜보면, 이 판단부터가 첫 착각이었다.

ESXi면 된다는 말들이 전혀 도움이 되지 않았던 이유

설치를 고민하던 초반, 검색 결과의 상당수는 이렇게 말하고 있었다.

“ESXi 쓰면 됩니다.”
“ESXi에 DSM 올리면 끝이에요.”

문제는 이 말들이 전부 과거형이었다는 점이다.

VMware를 인수한 Broadcom 이후,
ESXi 무료 배포판은 사실상 신규 제공이 중단됐다.

  • 공식 사이트: 계정 없이는 접근 불가
  • 라이선스: 무료 → 평가판 → 유료 전환
  • 과거 블로그의 다운로드 링크: 대부분 폐쇄 또는 404

즉, 기술적인 문제가 아니라 정책 변경으로 접근 자체가 막힌 상태였다.
이 시점에서 ESXi는 더 이상 “선택지”가 아니었다.

이 경험은 이후 프로젝트 전반을 관통하는 하나의 원칙을 만들었다.

무엇이든, 지금 이 시점에 실제로 가용한지부터 확인해야 한다.

그동안의 삽질기행을 돌아보면,
“예전에는 됐던 방법”을 그대로 믿고 시작했다가
시간만 날린 경우가 한두 번이 아니었다.

Proxmox 설치 USB, 여기서부터 순탄하지 않았다

ESXi를 접고 선택한 것이 Proxmox였다.
공식 ISO를 받아 USB를 만드는 과정 자체는 평범했다.Partition scheme : GPT Target system : UEFI (non-CSM) File system : FAT32

문제는 부팅이 되지 않았다는 것이다.

  • BIOS에서는 USB가 보이는데
  • 선택하면 바로 튕김
  • 설치 화면 자체가 뜨지 않음

ISO 문제인가, USB 문제인가, 하드웨어 호환 문제인가
여러 가능성을 의심했지만, 실제 원인은 따로 있었다.

이건 단순한 실수가 아니라
UEFI + Secure Boot 설정 충돌 문제였고,
이 부분은 다음 글(I2)에서 따로 다룰 정도로 깊게 빠졌다.

설치 화면에 들어가서도 멈칫했던 순간

Secure Boot를 끄고 나서야 설치 화면에 진입했다.
이후 과정은 비교적 빠르게 흘러갔지만,
한 지점에서 손이 멈췄다.

“이 디스크의 모든 데이터가 삭제됩니다.”

이 미니PC에는 이미 테스트용으로 쓰던 SSD가 장착돼 있었다.
“나중에 스토리지로 활용할 수 있지 않을까?”라는 미련이 남았다.

하지만 결국 선택지는 명확했다.

  • OS 디스크는 Proxmox 전용
  • 데이터는 VM이나 외장 스토리지로 분리

이 결정이 이후 모든 구조의 기준점이 됐다.

네트워크 설정, 아무 생각 없이 넘긴 대가

설치 중 네트워크 설정 화면이 나온다.

  • DHCP (자동)
  • 수동 설정

당시엔 네트워크에 대한 이해가 거의 없었다.
그래서 아무 고민 없이 DHCP 그대로 진행했다.IP Address : 자동 Gateway : 자동 DNS : 자동

이 선택이 나중에
**“설치는 끝났는데 웹 UI가 안 열리는 상황”**으로 이어진다.
이건 I3의 핵심 사건이다.

설치 완료 후, 진짜 시작된 문제

설치가 끝나고 재부팅하자 이런 문구가 나타났다.You can now connect to the Proxmox VE web interface: https://xxx.xxx.xxx.xxx:8006/

이걸 보는 순간, 모든 게 끝난 줄 알았다.
하지만 브라우저에 주소를 입력한 결과는 정반대였다.

  • 접속 불가
  • 타임아웃
  • 핑조차 안 감

이때 깨달았다.

Proxmox는 설치가 끝난 시점부터가 시작이라는 걸.

이 첫 설치에서 얻은 교훈

이 글은 성공담이 아니다.
출발선에서의 기록이다.

  • 서버 OS는 “설치된다”와 “쓸 수 있다”가 전혀 다르다
  • 네트워크를 모르면, 화면 하나 못 연다
  • 무엇보다도
    지금 가용한 기술인지 확인하지 않으면, 시작부터 잘못된다

그래서 Proxmox를 선택했다.
완벽해서가 아니라,
지금 이 시점에 공식적으로 내려받을 수 있고,
무료로, 실제로 쓸 수 있었기 때문이다.

다음 글에서는
이 설치 과정에서 가장 많은 시간을 잡아먹었던
UEFI / Secure Boot 삽질을 정리한다.

다음 편 바로 이어서 갈 준비돼 있어.
I2로 갈지, I3로 바로 넘어갈지 말만 해.

작성일자

H4. 미니PC에 서버를 올릴 때, 내가 조심하게 된 이유들

미니PC로 서버를 꾸리고 나서 한동안은 정말 별문제 없었다.
설치도 잘 끝났고, 서비스도 정상적으로 돌아갔다.
CPU 사용률도 낮았고, 메모리도 여유 있었고, 로그에도 이상은 없었다.

그런데 이상하게 마음이 편하지 않았다.
문제가 터진 건 아닌데,
언제 한 번은 이유 없이 멈출 것 같은 느낌이 계속 들었다.

이 글은 “문제가 생겼다”의 기록이 아니라,
왜 그런 불안이 생겼고, 그걸 어떻게 이해하게 됐는지에 대한 정리다.

1) CPU는 멀쩡한데, 왜 전체가 멍해질까

처음엔 당연히 CPU를 의심했다.
N100 미니PC에 Proxmox, VM 여러 개, DSM까지 올려놨으니
“이건 분명 과부하겠지”라는 생각이 먼저 들었다.

그래서 가장 먼저 본 게 CPU 사용률이었다.
그런데 이상하게도, 늘 여유 있었다.

서비스가 느릴 때도
웹이 굼뜰 때도
DSM 반응이 늦을 때도
CPU는 태평했다.

그때 처음으로 이런 생각이 들었다.

“이건 힘이 부족해서가 아니라,
어딘가를 기다리느라 멈춰 있는 상태 아닐까?”

그 이후부터 시스템을 볼 때
CPU보다 디스크 반응과 체감 지연을 더 보게 됐다.
그리고 미니PC 환경에서는
성능 부족보다 ‘대기’가 먼저 문제로 나타난다는 걸 체감하게 됐다.

2) 스토리지를 늘렸는데, 왜 마음은 더 바빠졌을까

저장 공간을 늘리면 당연히 안정될 줄 알았다.
공간 여유는 곧 마음의 여유라고 믿었다.

하지만 외장 스토리지를 붙인 뒤부터
오히려 서버 상태를 더 자주 확인하게 됐다.

  • 지금도 잘 붙어 있나
  • 재부팅하면 바로 인식될까
  • 이 상태가 정상인 게 맞나

문제는 대부분 항상 발생하지 않았다는 점이다.
아주 가끔, 한 번씩만 이상했다.
그래서 더 신경이 쓰였다.

그때 깨달았다.

외장 스토리지는
단순히 용량을 늘려주는 장치가 아니라,
운영자가 관리해야 할 조건을 하나 더 추가하는 선택이라는 걸.

3) 문제는 발열이 아니라, ‘전원이 들어오는 방식’이었다

한동안 시스템이 애매하게 불안정하다고 느낀 적이 있었다.
완전히 꺼지지는 않는데,
가끔 설명하기 어려운 멈춤이나 반응 지연이 나타났다.

처음엔 발열을 의심했다.
미니PC는 작고 조용하다 보니,
열이 쌓이고 있는 걸 내가 과소평가한 게 아닐까 싶었다.

그런데 온도가 특별히 높지 않은 상황에서도
비슷한 증상이 반복됐다.
그제서야 방향이 조금씩 어긋나고 있다는 걸 느꼈다.

나중에 알고 보니 문제는 발열이 아니었다.
이 미니PC는 PD 전원 입력과 어댑터 전원 입력을 모두 지원하는 구조였고,
중고로 들인 기기라 PD 전원부가 이미 정상적으로 동작하지 않는 상태였다.

전원이 아예 안 들어오는 게 아니라,
“들어오긴 하는데 안정적이지 않은 상태”였다.

그걸 처음엔 몰랐다.
그래서 성능 문제나 I/O 문제로 착각했고,
한참을 돌아가고 나서야 원인을 이해하게 됐다.

이 경험을 통해 분명히 알게 된 게 있다.

미니PC에서는
전원이 들어온다는 사실보다
어떤 경로로, 얼마나 안정적으로 들어오는지가 더 중요하다

작은 시스템일수록
전원부 하나의 이상이
전체 불안정으로 확대될 수 있다는 걸 몸으로 알게 됐다.

4) 서버는 멀쩡한데, 서비스가 죽어 있었다

한동안 가장 헷갈렸던 경험이 있다.
서비스가 안 된다는 이야기를 들었는데,
정작 서버에 들어가 보면 멀쩡한 상태였다.

CPU도 정상, 디스크도 정상, VM도 살아 있었다.

나중에 알고 보니 문제는 서버가 아니었다.
당시 사용하던 ipTIME 공유기가
전원 어댑터 불량으로 혼자서 죽는 경우가 있었다.
(알고 보니 꽤 유명한 고질병이었다.)

문제는 이게 아주 조용히 일어났다는 점이다.

  • 서버는 계속 돌아가고 있었고
  • 나는 아무것도 모르고 있었고
  • 아이들이 “와이파이 안 돼”라고 말해줄 때마다
    공유기를 껐다 켰다

그 과정에서
DDNS도 잠시 iptime.org에서 tplinkdns.com으로 바뀌었다.

이 경험을 통해 확실히 인식하게 됐다.

“서버가 살아 있다는 것과
서비스가 정상이라는 건 전혀 다른 문제구나”

미니PC 서버에서 가장 무서운 장애는
크게 터지는 문제가 아니라,
조용히 죽어 있는데 아무도 모르는 상태였다.

(지금 생각해보면,
그때 아이들이 최고의 모니터링 시스템이었다.)

5) 네트워크는 ‘되면 끝’이 아니었다

처음엔 네트워크가 되기만 하면 충분하다고 생각했다.
실제로 잘 됐고, 그동안은 큰 문제도 없었다.

하지만 한 번 꼬이고 나니
“왜 안 되는지”보다
“어디부터 봐야 하는지”를 모르는 상태가 훨씬 무서웠다.

그 이후로 네트워크는
자동 설정에 맡기는 영역이 아니라,
내가 이해한 만큼만 단순하게 유지해야 하는 영역이 됐다.

6) 그래서 내린 결론

이 모든 경험을 거치고 나서 얻은 결론은 단순하다.

미니PC에 서버를 올릴 때
조심해야 할 건 사양이 아니라 변수였다.

  • CPU보다 먼저 체감되는 I/O
  • 확장이 곧 안정은 아닌 스토리지 구성
  • 발열이 아니라 전원 경로에서 시작된 불안정
  • 서버보다 먼저 죽을 수 있는 네트워크 장비
  • 그리고 “죽은 줄 모르는 상태”가 가장 위험한 운영 방식

미니PC 서버는
성능 싸움이 아니라 운영 감각 싸움이었다.

솔직히 말하면,
이 정도까지 고민하게 될 줄은 몰랐다.
그냥 파일 좀 올려두려던 시작이었으니까.

하지만 한 가지는 분명하다.
이 과정을 거치고 나니,
미니PC는 더 이상 불안한 장난감이 아니라
내가 이해하고 통제할 수 있는 서버가 됐다.

reboot system boot 6.8.12-5-pve Thu Feb 20 21:10 – 19:12 (98+22:02) reboot system boot 6.8.12-5-pve Thu Feb 6 14:28 – 19:12 (113+04:44) reboot system boot 6.8.12-5-pve Tue Jan 21 00:07 – 19:12 (129+19:05)

위 로그는 last reboot으로 본 서버의 연속 가동일이다. 빈약한 하드웨어가 무리될까 멈춰둔거긴 한데 사실 판단의 근거가 없다. 앞으로의 공부와 경험이 후에 시스템 중단의 판단 기준이 되거나, 보조될 시스템을 구축해야겠지

작성일자

H3. SSD / HDD 구성과 DSM을 고려한 스토리지 판단

스토리지 구성은 처음부터 가장 신중하게 접근한 영역이었다.
CPU나 RAM은 부족하면 체감으로 드러나지만, 스토리지는 한 번 구조를 잘못 잡으면 나중에 되돌리기 어렵다. 특히 Proxmox 위에 DSM을 올리는 구조에서는 더 그랬다.

내부 SSD는 ‘시스템 디스크’로만 쓰기로 했다

미니PC 내부에는 NVMe SSD 하나만 사용했다.
용량을 크게 가져가지도 않았다. 처음부터 내부 디스크에 데이터를 쌓을 생각이 없었기 때문이다.

내부 SSD의 역할은 명확했다.

  • Proxmox OS
  • VM / LXC 디스크
  • 로그와 임시 파일

이 이상은 맡기지 않았다.
OS와 데이터가 섞이면, 장애가 날 때 항상 둘 다 위험해진다. 성능 문제가 아니라 구조의 문제였다.

DSM 이전, Nextcloud를 먼저 써봤다

DSM을 올리기 전, 잠시 Nextcloud를 직접 구축해서 사용해봤다.
지금 생각하면 네트워크 초보가 할 선택이었는지는 애매하지만, 당시에는 “직접 서비스 하나쯤은 굴려봐야겠다”는 생각이 더 컸다.

Nextcloud는 생각보다 많은 걸 요구했다.

  • 웹 서버 설정
  • 인증서 처리
  • 스토리지 경로와 권한
  • 내부망 / 외부망 구분
  • 문제 발생 시 책임 범위

기능 자체보다 더 어려웠던 건,
어디까지를 내가 관리해야 하는지 알 수 없다는 점이었다.

이 경험을 통해 질문이 하나 생겼다.

NAS란 서버일까,
아니면 관리 범위가 정해진 가전일까?

DSM VM은 ‘상용 NAS 체험’에 가까웠다

그래서 DSM을 Proxmox 위에 VM으로 올렸다.
목적은 명확했다.

  • 상용 NAS는 어떤 철학으로 운영되는지
  • 사용자가 만져야 할 영역과
  • 만지지 않아야 할 영역이 어디까지인지

DSM은 틀이 분명했다.
할 수 있는 건 많지만, 정해진 방식 안에서만 허용된다. Nextcloud에서 느꼈던 불안함과는 다른 종류의 안정감이었다.

이 시점의 계획은 꽤 정석적이었다.

  • DSM VM으로 충분히 사용해본다
  • 익숙해지면
  • 소형 시놀로지를 하나 추가한다
  • 그 장비를 백업 전용 NAS로 쓴다

교과서적인 NAS 확장 시나리오였다.

TerraMaster 외장 스토리지를 선택한 이유

하지만 1년 가까이 Proxmox와 DSM을 운영하면서 판단이 조금씩 바뀌었다.
장애를 몇 번 겪고, 복구 과정을 직접 지나오면서 깨달은 건 이것이었다.

백업의 핵심은
장비가 아니라 경로와 책임의 분리다.

그래서 내부 디스크를 늘리는 대신,
TerraMaster 외장 스토리지를 추가했다.

이 외장 스토리지는 NAS처럼 모든 걸 떠맡는 장비가 아니다.
의도적으로 디스크 박스(DAS) 역할에 충실한 제품을 골랐다.

  • Proxmox에서는 직접 접근하지 않고
  • DSM에서만 볼륨으로 사용
  • 데이터 영역을 물리적으로 분리

확장을 고려하긴 했지만, 목적은 서비스 확장이 아니라 백업 구조 확장이었다.

백업 경로를 바꾼 결정의 배경

원래 생각했던 “소형 시놀로지 추가” 계획을 완전히 버린 건 아니다.
다만 지금 시점에서는 보류했다.

  • 지금 구조를 최소 1년 이상 더 운영해보고
  • 업데이트, 장애, 복구를 충분히 겪은 뒤
  • 그때도 필요하다고 느껴지면 결정해도 늦지 않다고 판단했다

경험이 쌓이면서,
지금의 나에게 가장 중요한 건 장비 추가가 아니라
내가 이해하고 통제할 수 있는 범위 안에서의 안정성이었다.

이 시점의 결론

지금의 스토리지 구성은 화려하지 않다.
성능도, 확장성도 최신 NAS 구성에 비하면 평범하다.

하지만 1년 동안 실제로 운영해보니 이 구조는 분명했다.

  • 문제가 생기면 원인을 추적할 수 있고
  • 복구 경로가 머릿속에 그려지며
  • “이게 날아가면 끝”이라는 불안에서 벗어날 수 있다

이 판단은 이론이 아니라 운영 경험에서 나온 결과다.

다음 글에서는
이 모든 스토리지와 서비스 구성을 바탕으로
미니PC에 서버를 올릴 때 반드시 조심해야 할 점들을 정리해보려고 한다.
(H.4로 이어진다)

작성일자

H2. RAM 16GB 선택 이유와 실제 체감

미니PC를 주문하기 직전까지 가장 오래 고민했던 부품이 RAM이었다.
CPU는 이미 N100으로 정해져 있었고, 스토리지는 나중에라도 교체가 가능했지만, RAM만큼은 처음 선택이 거의 끝까지 간다고 봐도 됐다.

왜 16GB였나

처음엔 8GB도 후보였다.
N100이라는 CPU 자체가 고성능은 아니고, “가벼운 홈서버”를 목표로 한다면 8GB면 충분하다는 글도 많았다.
하지만 나는 Proxmox 위에 여러 VM을 동시에 올릴 계획이었고, 그 구조에서 RAM은 단순한 여유가 아니라 안정성 그 자체에 가깝다.

  • Proxmox 자체가 기본으로 잡아먹는 메모리
  • DSM VM (생각보다 메모리 욕심이 큼)
  • Nginx Proxy Manager
  • 테스트용 리눅스 VM
  • 가끔 켜두는 Windows VM

이걸 전부 동시에 띄워두는 순간, 8GB는 “돌아가긴 함” 수준일 가능성이 높았다.
나는 돌아가다 멈추는 서버보다, 항상 여유 있는 서버를 원했다.

그래서 처음부터 16GB로 갔다.

실제 사용하면서 느낀 점

결론부터 말하면, 16GB는 과하지 않았다. 딱 적절했다.

Proxmox 대시보드를 보면, 평상시 메모리 사용량은 대략 이렇다.

  • Proxmox 호스트: 1~1.5GB
  • DSM VM: 4~6GB (캐시 포함)
  • NPM + 기타 경량 서비스: 1GB 내외
  • 여유 메모리: 항상 4~6GB 이상 남음

중요한 건 이 남는 메모리 덕분에 아무 일도 안 일어난다는 점이다.
스왑이 도는 소리도 없고, 갑자기 느려지는 순간도 없다.
서비스 하나를 더 띄워도 “괜찮을까?”를 먼저 고민하지 않게 된다.

RAM이 체감에 영향을 주는 순간들

흥미로운 건, CPU 사용률이 낮은데도 체감이 불안해질 때가 있다는 점이다.
이럴 때 원인을 보면 대부분 메모리 압박이었다.

  • DSM에서 대용량 파일 복사
  • 동시에 여러 클라이언트가 접속
  • 백그라운드에서 인덱싱이나 썸네일 작업

이런 작업들은 CPU보다 RAM을 먼저 잡아먹는다.
16GB에서는 “조용히 지나가는 작업”이었지만,
만약 8GB였다면 분명히 체감 지연이나 스왑이 발생했을 거라고 느꼈다.

만약 다시 선택한다면?

지금 시점에서 다시 선택해도 16GB를 고른다.
N100이라는 CPU 한계는 명확하지만, RAM은 그 한계를 최대한 늦춰준다.

다만 한 가지는 분명하다.

  • 16GB는 여유
  • 32GB는 이 급의 미니PC에선 과함

CPU가 먼저 병목이 되는 구조에서 RAM만 늘리는 건 체감 향상이 거의 없다.
16GB는 “이 시스템이 할 수 있는 만큼을 안정적으로 하게 해주는 선”이었다.

정리하자면,
N100 미니PC + Proxmox 환경에서 RAM 16GB는 사치가 아니라 보험에 가깝다.
서버를 ‘가끔 만지는 장난감’이 아니라, ‘항상 켜두는 기반’으로 쓰고 싶다면, 이 선택은 충분히 납득 가능한 선택이었다.

작성일자

H1. N100 미니PC로 홈서버가 가능한 이유

(스펙보다 중요한 것)

홈서버를 꾸린다고 했을 때, 가장 먼저 떠오르는 질문은 늘 같다.
“그 사양으로 뭐가 되겠어?”

내가 선택한 건 인텔 N100 CPU가 들어간 미니PC였다.
데스크탑 기준으로 보면 저전력, 저성능 축에 속하고, 서버라는 단어와는 거리가 멀어 보이는 물건이다.
하지만 1년을 굴려본 지금, 결론부터 말하면 이렇다.

N100은 ‘서버용 CPU’가 아니라 ‘홈서버에 최적화된 CPU’였다.

서버는 늘 최대 성능을 쓰지 않는다

홈서버를 실제로 돌려보면, CPU가 풀로드로 달리는 순간은 거의 없다.
파일 서버, 사진 백업, 간단한 웹 서비스, 리버스 프록시, 노트 서버, 가벼운 미디어 스트리밍.
이런 작업들은 대부분 짧고 간헐적이다.

N100의 특징은 바로 여기서 드러난다.

  • 아이들 상태에서는 소비전력이 극히 낮고
  • 요청이 들어올 때만 짧게 클럭을 끌어올리며
  • 다시 조용히 내려간다

24시간 켜두는 장비에 이보다 더 중요한 특성은 없었다.
“빠르냐”보다 **“쓸데없이 낭비하지 않느냐”**가 훨씬 중요했다.

코어 수보다 중요한 건 ‘용도 분리’

N100은 4코어 4스레드다.
이 숫자만 놓고 보면 VM 여러 개를 돌리기엔 부족해 보인다.

하지만 Proxmox 위에서 직접 써보니 체감은 달랐다.

  • 무거운 작업은 애초에 올리지 않고
  • 서비스별로 역할을 명확히 나누고
  • LXC와 VM을 섞어 쓰는 구조로 가져가니

CPU가 병목이 되는 상황은 거의 나오지 않았다.

중요한 건 **“얼마나 많은 걸 얹느냐”가 아니라
“무엇을 얹지 않느냐”**였다.

소음, 발열, 공간 — 집 안 서버의 현실

집 안에 두는 서버는 데이터센터 기준으로 판단하면 안 된다.

  • 팬 소음이 크면 실패
  • 발열이 높으면 실패
  • 공간을 많이 차지하면 실패

N100 미니PC는 이 세 가지를 모두 피했다.

책장 한 칸, 공유기 옆, 콘센트 하나.
이 정도 존재감으로 1년을 버텼다는 점은 꽤 결정적이었다.

서버가 생활 공간을 침범하지 않는 것,
이게 홈서버에서는 스펙만큼이나 중요한 조건이었다.

결국 남는 질문 하나

1년을 쓰고 나니, 처음의 질문은 이렇게 바뀌었다.

“이 정도면 충분하지 않나?”

N100으로 대규모 서비스를 돌릴 생각이었다면 당연히 틀린 선택이었을 것이다.
하지만 내가 원했던 건

  • 내 데이터
  • 내 서비스
  • 내가 관리 가능한 범위

그 이상도, 이하도 아니었다.

N100은 그 경계를 정확히 지켜주는 CPU였다.

다음 글에서는
왜 RAM을 16GB로 선택했는지,
그리고 실제로 얼마나 남고 모자랐는지를 정리해보려 한다