DevOps
홈서버를 시작하며 알게 된 것들: 남는 PC에서 나만의 인프라까지
남는 PC 한 대로 시작한 홈서버. Docker, 네트워크, 스토리지, 백업을 직접 구성하며 작은 서버 한 대가 개인 인프라로 발전하는 과정을 정리했습니다.
홈서버를 시작하며 알게 된 것들: 남는 PC에서 나만의 인프라까지
개발을 하다 보면 한 번쯤 이런 생각을 하게 됩니다.
“이걸 내 컴퓨터 말고 계속 켜져 있는 곳에서 돌릴 수 없을까?”
처음에는 클라우드가 가장 먼저 떠오릅니다. AWS EC2나 Lightsail 같은 서비스를 사용하면 몇 분 만에 서버 하나를 만들 수 있고, 직접 하드웨어를 관리할 필요도 없습니다.
그런데 집에 사용하지 않는 PC가 한 대 있다면 이야기가 조금 달라집니다.
“이걸 서버로 쓰면 되지 않을까?”
홈서버(Home Server)는 보통 여기에서 시작합니다.
저 역시 홈서버를 거창한 인프라 프로젝트로 생각하기보다는, 남는 하드웨어를 활용해서 내가 직접 운영하는 작은 서버 환경을 만들어 보는 것에 더 가깝다고 생각합니다.
하지만 직접 만들어 보면 재미있는 일이 생깁니다. 처음에는 애플리케이션 하나를 실행하는 것으로 시작했는데 Docker를 설치하고, 도메인을 연결하고, 스토리지와 백업을 고민하다 보면 어느 순간 작은 데이터센터를 운영하는 것과 비슷한 문제들을 만나게 됩니다.
이 글에서는 홈서버가 무엇인지부터 시작해 실제로 어떤 구조로 만들 수 있는지, 그리고 운영하면서 무엇을 고민해야 하는지 차근차근 정리해 보겠습니다.
홈서버가 필요한 이유
홈서버는 말 그대로 집에서 직접 운영하는 서버입니다.
특별한 서버 장비가 반드시 필요한 것은 아닙니다. 오래된 노트북도 가능하고, 사용하지 않는 데스크톱이나 미니 PC도 충분합니다.
중요한 것은 하드웨어보다 그 위에서 무엇을 실행하느냐입니다.
예를 들어 홈서버에서는 다음과 같은 서비스를 운영할 수 있습니다.
- 개인 웹사이트와 API
- 개발 및 테스트 서버
- Git 저장소
- 사진과 파일 저장소
- 미디어 서버
- 데이터베이스
- Home Assistant 같은 홈 자동화 서비스
- 개인 VPN
- 모니터링 시스템
- CI/CD Runner
물론 대부분은 클라우드에서도 할 수 있습니다.
그럼에도 홈서버를 만드는 가장 큰 이유는 서버를 구성하는 전체 과정을 직접 통제할 수 있다는 점입니다.
클라우드에서는 버튼 몇 번으로 만들어지는 네트워크와 스토리지도 홈서버에서는 직접 고민해야 합니다.
IP는 어떻게 할 것인지, 외부에서는 어떻게 접근할 것인지, 디스크가 고장 나면 어떻게 할 것인지, 서비스가 죽으면 어떻게 알아낼 것인지까지 생각해야 합니다.
귀찮은 부분이지만, 동시에 홈서버의 가장 재미있는 부분이기도 합니다.
첫 번째 구성: 그냥 Linux 한 대
가장 단순한 홈서버 구조는 생각보다 별것 없습니다.
Internet
│
Home Router
│
└── Home Server
└── Linux
└── Application
PC 한 대에 Ubuntu Server나 Debian 같은 Linux 배포판을 설치하고 SSH를 활성화합니다.
그리고 필요한 애플리케이션을 직접 설치합니다.
예를 들어 Node.js 애플리케이션이라면 대략 이런 모습이 됩니다.
sudo apt update
sudo apt install nodejs npm
git clone <repository>
cd <project>
npm install
npm run start
이것만으로도 서버는 완성입니다.
같은 네트워크에 있는 다른 컴퓨터에서
http://192.168.0.10:3000
처럼 접속할 수 있다면 이미 훌륭한 홈서버입니다.
처음부터 Kubernetes나 복잡한 클러스터를 구성할 필요는 없습니다.
오히려 처음에는 한 대의 Linux 서버를 안정적으로 운영하는 경험을 해보는 것이 좋습니다.
서비스가 늘어나면서 Docker가 필요해졌다
문제는 실행하고 싶은 서비스가 늘어나면서 시작됩니다.
Node.js 애플리케이션도 있고 PostgreSQL도 필요하고 Redis도 필요하다고 해보겠습니다.
각 프로그램을 호스트에 직접 설치하면 서버 상태가 점점 복잡해집니다.
Ubuntu
├── Node.js 22
├── PostgreSQL
├── Redis
├── Nginx
├── Python
└── 각종 systemd service
여기서 버전 충돌이나 의존성 문제가 발생하기 시작합니다.
그래서 홈서버에서도 Docker가 꽤 유용합니다.
Home Server
│
└── Docker
├── nginx
├── application
├── postgres
├── redis
└── monitoring
각 서비스를 컨테이너로 분리하면 애플리케이션이 사용하는 환경과 호스트 OS의 환경을 어느 정도 분리할 수 있습니다.
Docker Compose를 사용하면 구성도 코드로 관리할 수 있습니다.
services:
app:
image: my-app:latest
restart: unless-stopped
ports:
- "3000:3000"
db:
image: postgres
restart: unless-stopped
volumes:
- postgres-data:/var/lib/postgresql/data
volumes:
postgres-data:
여기서 중요한 변화가 하나 있습니다.
“서버에 무엇을 설치했는가”에서 “어떤 서비스를 선언했는가”로 관리 방식이 바뀐다는 점입니다.
서버를 다시 설치해야 하는 상황에서도 Compose 파일과 데이터를 가지고 있다면 이전 환경을 비교적 쉽게 복구할 수 있습니다.
외부에서 접속하고 싶다면
LAN 내부에서만 사용한다면 구성이 간단하지만 외부에서 홈서버에 접근하려는 순간 네트워크 문제가 등장합니다.
Internet
│
Public IP
│
Router
│
NAT / Firewall
│
Home Server
여기에서 생각해야 할 것이 많습니다.
먼저 ISP에서 공인 IP를 제공하는지 확인해야 합니다. 공유기가 인터넷 쪽에서 받은 주소가 사설 주소이거나 CGNAT 환경이라면 일반적인 포트 포워딩만으로 외부에서 직접 접근하기 어려울 수 있습니다.
공인 IP를 사용할 수 있더라도 주소가 바뀔 수 있습니다.
이때는 DDNS(Dynamic DNS)를 이용해 변경되는 IP와 도메인을 연결하는 방법을 사용할 수 있습니다.
하지만 외부 접속이 필요하다는 이유만으로 관리용 포트를 인터넷에 바로 노출하는 것은 피하는 편이 좋습니다.
SSH나 관리 페이지가 필요하다면 WireGuard, Tailscale 같은 VPN 계층을 두는 방식도 고려할 수 있습니다.
홈서버를 인터넷에 공개하는 순간부터 이 서버는 더 이상 집 안에서만 존재하는 장비가 아닙니다.
자동화된 스캐닝과 로그인 시도에 노출될 수 있기 때문에 방화벽, 인증, 업데이트를 실제 운영 환경처럼 생각해야 합니다.
Reverse Proxy를 두기
서비스가 하나라면 포트 번호만 기억해도 됩니다.
하지만 서비스가 늘어나면 이런 주소가 만들어집니다.
192.168.0.10:3000
192.168.0.10:8080
192.168.0.10:9000
192.168.0.10:9090
어느 포트가 어느 서비스인지 기억하기 어려워집니다.
그래서 앞단에 Reverse Proxy를 둘 수 있습니다.
┌── blog
Internet ── Proxy ── api
├── dashboard
└── monitoring
예를 들어 다음처럼 서비스별 도메인을 나눌 수 있습니다.
blog.example.com
api.example.com
monitor.example.com
Nginx, Caddy, Traefik 같은 소프트웨어가 이 역할을 할 수 있습니다.
Reverse Proxy를 두면 단순히 주소가 예뻐지는 것뿐만 아니라 TLS 인증서와 외부 요청이 들어오는 지점을 한곳에서 관리할 수 있다는 장점도 있습니다.
홈서버에서 가장 중요한 것은 CPU가 아니었다
홈서버를 처음 알아볼 때는 CPU와 RAM부터 비교하기 쉽습니다.
물론 성능도 중요합니다.
하지만 실제로 서비스를 오래 운영하려고 하면 더 중요한 문제가 나타납니다.
바로 데이터입니다.
애플리케이션 컨테이너는 다시 만들 수 있습니다.
하지만 PostgreSQL 데이터, 사진, 문서 같은 데이터는 사라지면 다시 만들 수 없습니다.
그래서 다음 두 가지를 구분해서 생각하는 것이 좋습니다.
Reproducible
├── Docker image
├── source code
└── configuration
Irreplaceable
├── database
├── photos
├── documents
└── user-generated data
재생성 가능한 것은 다시 만들면 됩니다.
재생성할 수 없는 것은 백업해야 합니다.
RAID는 백업이 아니다
홈서버에서 스토리지를 구성하다 보면 RAID 이야기를 만나게 됩니다.
여러 디스크에 데이터를 분산하거나 복제하면 디스크 하나가 고장 나더라도 서비스를 계속 운영할 수 있는 구성을 만들 수 있습니다.
하지만 RAID가 있다고 해서 백업이 필요 없는 것은 아닙니다.
예를 들어 실수로 파일을 삭제했다면 RAID는 그 삭제 작업까지 그대로 반영합니다.
랜섬웨어나 애플리케이션 오류로 데이터가 손상되는 경우도 마찬가지입니다.
그래서 저는 다음 세 가지를 별개의 문제로 보는 것이 이해하기 쉽다고 생각합니다.
Availability ≠ Backup ≠ Archive
디스크 장애에도 서비스를 유지하는 것과, 과거 데이터를 복원하는 것은 다른 문제입니다.
중요한 데이터라면 서버 내부 복제뿐 아니라 서버와 물리적으로 분리된 백업도 고려해야 합니다.
그리고 백업에서 가장 쉽게 놓치는 것이 하나 있습니다.
백업 파일이 존재하는 것과 실제로 복원할 수 있는 것은 다릅니다.
따라서 중요한 데이터는 가끔 직접 복원해 보면서 백업이 정상적으로 동작하는지 확인하는 것이 좋습니다.
운영하기 시작하면 모니터링이 필요해진다
처음에는 서버에 SSH로 접속해서 확인하면 됩니다.
top
df -h
docker ps
하지만 서비스가 많아지면 매번 확인하기 어렵습니다.
그때부터 모니터링을 붙이고 싶어집니다.
확인하고 싶은 대상도 자연스럽게 늘어납니다.
CPU
Memory
Disk
Temperature
Network
Container status
HTTP response
Database
Prometheus와 Grafana 같은 도구를 사용할 수도 있고, 처음에는 더 단순한 uptime monitoring 도구만 사용해도 충분합니다.
중요한 것은 화려한 대시보드가 아닙니다.
문제가 발생했을 때 내가 알 수 있는가?
이 질문에 답할 수 있는 최소한의 모니터링부터 만드는 것이 좋습니다.
홈서버의 구조가 조금씩 달라졌다
이 과정을 거치면 처음의 단순한 서버는 대략 이런 모습으로 발전합니다.
Internet
│
Router / Firewall
│
VPN / HTTPS Access
│
Reverse Proxy
│
┌────────────────┼────────────────┐
│ │ │
Web App API Dashboard
│ │
└────────┬───────┘
│
Database
│
Storage
│
Backup
Monitoring / Logs
처음부터 이 구조를 목표로 만들 필요는 없습니다.
필요가 생길 때 하나씩 추가하는 편이 훨씬 재미있고, 각각의 기술이 왜 필요한지도 이해하기 쉽습니다.
Kubernetes도 설치해야 할까?
홈서버 이야기를 하다 보면 Kubernetes까지 관심이 가기 쉽습니다.
물론 홈랩(Home Lab)을 학습 환경으로 사용한다면 좋은 선택이 될 수 있습니다.
특히 여러 노드를 운영하거나 Kubernetes 자체를 공부하는 것이 목적이라면 k3s 같은 가벼운 배포판으로 클러스터를 만들어 보는 것도 재미있는 프로젝트입니다.
하지만 단순히 몇 개의 서비스를 안정적으로 실행하는 것이 목적이라면 Docker Compose만으로 충분한 경우가 많습니다.
서비스를 운영하는 것이 목적
↓
Docker Compose
Kubernetes를 배우는 것이 목적
↓
k3s / Kubernetes
도구를 먼저 선택하고 문제를 끼워 맞추기보다는 내가 해결하려는 문제가 무엇인지 먼저 정하는 것이 좋습니다.
전기요금도 서버 스펙이다
클라우드에서는 시간당 인스턴스 가격을 확인하지만 홈서버에서는 소비전력이 비용이 됩니다.
24시간 켜져 있기 때문입니다.
평균 소비전력이 P(W)라면 한 달 전력 사용량은 대략 다음처럼 계산할 수 있습니다.
월 사용량(kWh)
= P × 24 × 30 ÷ 1000
예를 들어 평균 20W를 소비한다면,
20 × 24 × 30 ÷ 1000
= 14.4 kWh/month
가 됩니다.
따라서 홈서버용 하드웨어를 선택할 때는 최고 성능뿐 아니라 idle power consumption도 중요한 스펙입니다.
사용률이 낮은 서버라면 대부분의 시간을 idle 상태로 보내기 때문입니다.
경우에 따라서는 기존 고성능 데스크톱을 24시간 켜두는 것보다 저전력 미니 PC를 사용하는 편이 장기적인 운영비와 소음 측면에서 더 적합할 수도 있습니다.
홈서버는 클라우드를 대체하는가?
꼭 그렇지는 않습니다.
오히려 둘의 성격이 다릅니다.
클라우드는 하드웨어 장애, 네트워크, 전력 같은 물리 인프라를 서비스 제공자가 상당 부분 관리합니다.
홈서버에서는 그 책임이 나에게 돌아옵니다.
인터넷이 끊길 수도 있고 정전이 발생할 수도 있으며 SSD가 갑자기 고장 날 수도 있습니다.
반대로 홈서버에서는 하드웨어와 데이터, 네트워크 구조를 직접 다룰 수 있습니다.
그래서 모든 것을 홈서버로 옮기기보다는 목적에 따라 나누는 방식도 괜찮습니다.
Home Server
├── Personal services
├── Development environment
├── Media
├── Storage
└── Experiments
Cloud
├── Public production service
├── Highly available workload
└── External backup
둘 중 하나를 선택해야 하는 문제라기보다 각각 잘하는 일을 맡기는 것입니다.
직접 운영해 봐야 보이는 것들
홈서버의 가장 재미있는 점은 여러 기술이 하나의 시스템 안에서 연결된다는 것입니다.
Linux를 설치하는 것에서 시작했는데 어느 순간 Docker를 배우고 있습니다.
외부에서 접속하려다 DNS와 NAT를 공부하고, HTTPS를 적용하면서 TLS를 만나게 됩니다.
디스크를 추가하다가 파일 시스템과 RAID를 공부하고, 데이터를 지키려다 백업 전략을 고민하게 됩니다.
서비스가 많아지면 모니터링과 로그가 필요해집니다.
결국 다음과 같은 기술들이 하나의 흐름으로 이어집니다.
Linux
↓
Docker
↓
Networking
↓
DNS / TLS
↓
Storage
↓
Backup
↓
Monitoring
↓
Automation
문서로 각각 공부할 때는 서로 다른 기술처럼 보이지만, 직접 서버 하나를 운영하면 왜 이 기술들이 필요한지 자연스럽게 연결됩니다.
마무리
홈서버를 시작하기 위해 랙 서버나 NAS, 여러 대의 미니 PC가 반드시 필요한 것은 아닙니다.
사용하지 않는 PC 한 대와 Linux만 있어도 충분합니다.
처음에는 SSH로 접속해서 애플리케이션 하나를 실행해 보고, 필요해지면 Docker를 붙이고, 외부 접속이 필요하면 네트워크를 공부하면 됩니다.
데이터가 중요해지면 백업을 만들고, 서비스가 많아지면 모니터링을 추가하면 됩니다.
그렇게 하나씩 문제를 해결하다 보면 어느 순간 단순히 “집에 있는 컴퓨터 한 대”가 아니라 내가 직접 설계하고 운영하는 작은 인프라가 만들어져 있습니다.
그리고 개인적으로 홈서버의 가치는 서버 자체보다 이 과정에 있다고 생각합니다.
클라우드에서는 API 한 번으로 만들어지던 것들이 실제로 어떤 문제를 해결하고 있었는지 직접 경험할 수 있기 때문입니다.
작게 시작해도 괜찮습니다.
남는 PC 한 대에 Linux를 설치하고 SSH로 접속해 보는 것.
홈서버는 그것만으로 이미 시작입니다.
Tags