홈랩 아키텍처 설계: Ubuntu Desktop vs Server, 무엇을 선택해야 할까?

TL;DR (요약 로그)

1. 홈랩을 구성하는 4개의 노드(스토리지, AI 연산, 모니터링, 로그 수집) OS로 Ubuntu Server LTS를 채택했습니다.
2. 서버 환경(브리지, VLAN, 고정 IP)에서는 NetworkManager보다 systemd-networkd 렌더러가 훨씬 예측 가능하고 안정적입니다.
3. 불필요한 GUI 데몬이 없어야 자원 오버헤드와 보안 취약점(Attack Surface)을 최소화할 수 있습니다.

root@hwaserbit:~# cat /etc/os-release | grep PRETTY_NAME
PRETTY_NAME="Ubuntu 24.04 LTS"

1. Init System: 홈랩 하드웨어 롤(Role) 정의

안정적인 홈랩(Home Lab) 인프라를 구축하기 위한 첫걸음은, 각 물리/가상 노드의 역할(Role)을 명확히 정의하고 그에 맞는 운영체제(OS)를 베이스로 까는 것입니다.

현재 제가 설계하고 구축 중인 홈랩의 하드웨어와 역할은 다음과 같습니다.

노드(하드웨어)	핵심 역할 (Role)	요구사항
TOPTON Intel 8505 i226-V 2.5G 6 lans	Pfsense + Gateway	높은 RAM 용량, 저전력
ODROID-H4 PLUS	스토리지	저전력, 안정성
i5-13600k + A770 16GB	AI 연산 + 고성능 프로젝트	높은 RAM, VRAM 용량, 높은 연산 성능 및 최신 GPU 기술, 전성비

각 노드는 목적이 다르지만, 공통적인 특징이 있습니다. 모두 모니터 없이 원격으로 제어되는 헤드리스(Headless) 운영을 전제로 하며, 복잡한 네트워크(브리지, VLAN)와 하드웨어 가속(HWA)을 사용한다는 점입니다.

이러한 요구사항을 분석한 결과, 모든 노드의 기반 OS로 Ubuntu Server LTS를 채택했습니다. 왜 Desktop 버전이 아닌 Server 버전을 선택했는지, 인프라 운영 관점에서 그 이유를 3가지로 분석했습니다.

2. 네트워크 렌더러의 차이: 안정성 vs 편의성

Ubuntu Desktop과 Server의 가장 치명적인 차이는 바로 기본 네트워크 렌더러(Renderer)에 있습니다. 두 OS 모두 겉으로는 netplan을 사용하여 네트워크를 설정하지만, 그 설정값을 실제로 시스템에 적용하는 백엔드 엔진이 다릅니다.

Ubuntu Desktop (NetworkManager): Wi-Fi 연결, 잦은 IP 변경 등 동적이고 모바일 친화적인 환경에 맞춰져 있습니다. GUI 환경에서 클릭 몇 번으로 설정하기는 편하지만, 서버급의 복잡한 라우팅이나 브리지 설정 시 돌발 변수가 발생할 확률이 높습니다.

Ubuntu Server (systemd-networkd): 오직 서버(Headless) 환경을 위해 디자인되었습니다. 브리지(Bridge), VLAN, 고정 IP 라우팅을 선언적인(Declarative) 방식으로 완벽하게 통제하며, 재부팅 시에도 100% 예측 가능한 상태를 보장합니다.

H4 PLUS나 13600k 노드처럼 다수의 가상화 컨테이너, 가상환경(docker, KVM)가 브리지 네트워크를 물고 통신해야 하는 환경에서는, 변동성이 큰 NetworkManager 대신 systemd-networkd를 사용하는 것이 시스템 장애를 예방하는 첫 번째 방어선입니다.

# 현재 적용된 렌더러 확인 방법
netplan get | grep renderer

# 결과
renderer: networkd

---

3. 자원 오버헤드와 공격 표면(Attack Surface) 최소화

서버 인프라 설계의 핵심은 “꼭 필요한 것만 남기고 전부 제거한다”는 원칙입니다.

Desktop 버전을 설치하면 gnome-shell, gdm3 같은 무거운 GUI 데몬뿐만 아니라 파일 인덱서(tracker), 프린터 서비스(cups), 블루투스 데몬 등 서버 구동에 전혀 쓸모없는 백그라운드 프로세스들이 상시 실행됩니다.

이는 단순히 RAM이나 CPU를 낭비하는 오버헤드의 문제를 넘어섭니다.

업데이트 폭발: GUI 관련 패키지들이 얽혀 있어 패키지 업데이트 주기가 잦아지고, 업데이트 시 예기치 않은 의존성 충돌로 서버가 다운될 위험이 커집니다.

보안 취약점 증가: 백그라운드에서 도는 포트와 데몬이 많아질수록 외부 공격자가 침투할 수 있는 표면적(Attack Surface)이 넓어집니다.

H4 PLUS에서 NFS와 SMB, webdav등 을 돌리고, 13600k에서 A770 GPU로 AI 연산/추론과 인코딩 연산을 수행하는 데 GUI는 전혀 필요하지 않습니다. 철저하게 통제된 CLI 환경에서 컨테이너 기반으로 서비스를 올리는 것이 압도적으로 안전합니다.

---

4. 패키지 의존성 측면에서의 접근: GUI 비활성화 vs Server에 GUI 추가

초기 인프라 설계 시 흔히 범하는 오류 중 하나는 “설치가 편한 Desktop 버전을 깐 뒤, systemctl set-default multi-user.target 명령어로 GUI 데몬만 비활성화해서 쓰자”는 접근입니다.

하지만 이는 시스템 엔지니어링 관점에서 매우 위험한 안티 패턴(Anti-pattern)입니다. 눈에 보이는 GUI 프로세스만 멈췄을 뿐, 수백 개의 Desktop 패키지와 무거운 의존성 툴킷들은 여전히 시스템에 남아있기 때문입니다. 추후 커널이나 하드웨어 드라이버(특히 GPU 드라이버)를 업데이트할 때 이 잔여 패키지들이 얽히면서 원인 모를 부팅 불량(Kernel Panic)을 일으킬 확률이 매우 높습니다.

그렇다면 반대로, “Server 버전을 뼈대로 설치한 뒤 필요할 때만 GUI(Desktop Environment)를 패키지로 설치하는 것”은 어떨까요?

결론부터 말씀드리면, 첫 번째 방법보다는 훨씬 낫지만 이 역시 권장하지 않습니다. 최소한의 베이스 위에 필요한 의존성만 추가하므로 시스템이 덜 오염되는 것은 사실입니다. (만약 정말 GUI가 불가피하다면, --no-install-recommends 옵션으로 xfce 같은 경량 데스크탑만 올리는 것이 타협안입니다.)

하지만 현재 구성하는 홈랩처럼 자원을 극한으로 최적화해야 하는 환경에서는 이마저도 불필요한 타협입니다. 그 이유는 다음과 같습니다.

1. 대체재의 존재: 현대의 인프라 관리는 SSH(CLI) 기반의 터미널 환경과 Portainer, Cockpit, Proxmox VE 같은 강력한 Web UI로 100% 대체 가능합니다. 서버 로컬에 직접 GUI를 띄워야 할 기술적 이유가 거의 없습니다.
2. 잠재적 위험: 아무리 가벼운 GUI를 올려도 결국 X11이나 Wayland 같은 디스플레이 서버와 관련 패키지들이 깔리게 됩니다. 이는 결국 업데이트 주기를 짧게 만들고, 프린터(CUPS)나 네트워크 탐색(Avahi) 같은 불필요한 백그라운드 서비스(데몬)를 활성화시켜 시스템의 보안 취약점(Attack Surface)을 대폭 넓히는 결과로 이어집니다.
3. 전용 클라이언트 PC 운용: 제 홈랩 아키텍처에는 원격 접속 및 인프라 관리를 전담하는 별도의 Windows 클라이언트(미니 PC)가 이미 구성되어 있습니다. 자원 오버헤드 최소화, 보안성 확보, 유지보수의 효율성을 종합적으로 고려할 때, 득보다 실이 많은 GUI 환경을 서버 노드에까지 추가로 구성할 당위성이 확보되지 않습니다.

결국 애초에 군더더기 없이 최소 패키지만 설치되는 Ubuntu Server 버전을 선택하고, 철저히 헤드리스(Headless) 상태를 유지하는 것만이 시스템의 안정성을 챙기고 관리자가 모든 것을 통제할 수 있는 가장 정석적인 방법입니다.

---

5. 네트워크 렌더러의 차이: 하드웨어 마이그레이션과 트러블슈팅

우분투 서버를 처음 설치할 때, 인스톨러 화면에서 기본 네트워크 장치를 자동으로 찾아주는 것을 보고 “아, 서버도 나중에 랜카드를 추가로 꽂으면 알아서 동적으로 잡아주겠구나”라고 예상했습니다.

당시 추가로 장착할 NIC(네트워크 카드)가 다른 PC에서 사용 중이었기 때문에, 부품을 적출하고 서버에 이식하는 하드웨어 마이그레이션 작업이 필요했습니다. 작업 동선을 줄이기 위해 우선 OS 뼈대부터 설치를 마무리하고, 나중에 NIC를 추가 장착한 뒤 설정 파일에서 고정 IP만 할당해 줄 계획이었죠.

그런데 막상 NIC를 추가 장착하고 부팅해보니, 설정 파일을 열어봐도 새로 장착한 랜카드 정보가 전혀 반영되어 있지 않았습니다. 결국 터미널에서 명령어로 일일이 새로운 장치명(Logical name)을 조회하고 나서야 수동으로 네트워크 설정을 잡아줄 수 있었습니다.

이 해프닝을 통해 두 렌더러의 결정적인 차이를 몸소 깨달았습니다. 데스크탑의 NetworkManager는 USB를 꽂듯 랜카드 같은 하드웨어도 ‘플러그 앤 플레이(Plug & Play)’처럼 즉각적으로 인식하고 동적으로 반응합니다. 반면, 서버의 systemd-networkd는 OS 설치가 끝난 이후에는 관리자가 직접 설정 파일에 명시하지 않는 한, 새로운 장치가 추가되어도 임의로 네트워크 구성을 변경하지 않습니다.

분명 동적으로 반응하는 데스크탑 방식이 사용자 경험(UX) 측면에서는 훨씬 편리합니다. 하지만 서버 인프라 관점에서는 관리자가 의도하지 않은 장치나 네트워크의 자동 변경이 일어나는 것 자체가 치명적인 장애의 원인이 될 수 있습니다. 렌더러의 동작 방식만 봐도, 두 운영체제가 각기 다른 사용 환경과 ‘안정성’의 기준에 맞춰 얼마나 철저하게 다르게 설계되었는지 확실히 체감할 수 있었습니다.

• Ubuntu Desktop (NetworkManager): Wi-Fi 신호나 랜 케이블 연결 상태를 실시간으로 감시하며 동적으로 반응합니다. 사용하기는 편리하지만, 복잡한 브리지 설정을 적용하면 NetworkManager가 개입해 기존 설정과 충돌을 일으켜 접속 불량이 발생하기 쉽습니다.
• Ubuntu Server (systemd-networkd): 부팅 시 설정 파일(Netplan)에 명시된 상태만을 정적으로 밀어붙입니다. 동적인 편의성은 없지만, 관리자가 의도한 그대로(선언적) 네트워크가 구성됩니다.

13600k 노드는 고성능으로 추후 가상머신을 운용할 가능성이 있습니다. 이를 운영을 위해서는 필연적으로 브리지 네트워크 설정이 필요합니다. 과거의 경험 때문에 아직 브리지 설정을 다시 올리는 것이 조금 조심스럽긴 하지만, 변동성이 큰 NetworkManager 대신 예측 가능한 systemd-networkd를 사용하는 현재의 Server 아키텍처가 예기치 못한 네트워크 장애를 막는 가장 확실한 기반이 될 것입니다.

---

6. 서버 엔지니어의 생명줄: 안전한 네트워크 변경

원격(Headless)으로 서버를 관리할 때 가장 무서운 순간은 네트워크 설정을 바꿨다가 연결이 끊겨버리는 ‘셀프 격리’ 상황입니다. Ubuntu Server 환경에서는 systemd-networkd와 궁합이 좋은 Netplan의 강력한 롤백 기능을 통해 이를 방어할 수 있습니다.

# 네트워크 설정 테스트 (120초 내에 승인하지 않으면 자동 원상복구)
root@hwaserbit:~# netplan try --timeout 120

만약 Desktop 버전을 사용하면서 /etc/netplan/*.yaml을 수정했다면, GUI 설정(NetworkManager)과 충돌이 발생해 설정이 아예 무시되거나 원인 모를 접속 불량이 발생했을 것입니다.

저는 이러한 소프트웨어적 방어선 외에도, 모든 노드에 관리 전용 NIC(물리 랜포트)를 별도의 고정 IP로 할당하는 ‘백도어(Backdoor)’ 정책을 설계했습니다. 최악의 경우에도 PiKVM을 통해 콘솔에 직접 붙어 하드 롤백을 수행할 수 있는 ‘최후의 안전벨트’까지 마련해 두었습니다.

---

7. 결론: 편의성 대신 완벽한 통제권을 선택

홈랩(HomeLab) 구축은 단순히 남는 하드웨어에 OS를 설치하는 것을 넘어, 서비스 목적에 맞는 아키텍처를 스스로 설계하고 검증하는 과정입니다. 리눅스를 처음 접할 때는 직관적인 GUI의 Desktop 버전이 매력적일 수 있지만, 시스템 엔지니어링 관점에서는 초기 편의성과 인프라 통제권 사이의 트레이드오프(Trade-off)를 냉정하게 따져봐야 합니다.

이번 설계에서 GUI를 덜어내고 Ubuntu Server LTS를 채택함으로써 확보한 핵심 가치는 다음과 같습니다.

1. 예측 가능성(Predictability): NetworkManager의 이벤트 기반 변동성 대신 systemd-networkd의 정적인 안정성 확보
2. 자원 최적화(Resource Optimization): 불필요한 데몬을 제거하여 스토리지 및 AI 연산에 컴퓨팅 자원 집중
3. 보안성(Security): 불필요한 패키지 및 포트 오픈을 차단하여 시스템의 공격 표면(Attack Surface) 최소화

가장 밑바탕이 되는 OS 아키텍처를 단단하고 가볍게 구축하는 것은 향후 발생할 수 있는 수많은 장애 포인트를 사전에 제거하는 정석적인 접근입니다. 이제 뼈대가 완성된 만큼, 이 위에서 펼쳐질 다양한 가상화 서비스와 트러블슈팅 여정을 계속해서 기록해 나가겠습니다.

Reference

• Ubuntu Server Guide: Network Configuration
• Netplan Official Documentation
• Systemd Networkd vs NetworkManager (Arch Wiki)

root@hwaserbit:~# uptime -p
up 5 days, 23 hours, 49 minutes
root@hwaserbit:~# reboot