베어메탈 vs Docker vs 쿠버네티스, 직접 다 해보고 정리한 장단점 (2편)

[1편](OS·하드웨어 변천사)에서는 라즈베리파이부터 물리 PC까지, CentOS 7부터 Ubuntu까지 홈서버를 갈아엎어 온 과정을 정리했습니다.

그 과정에서 가장 힘들었던 건 OS나 하드웨어를 바꿀 때마다 서비스 환경을 처음부터 다시 구축해야 한다는 점이었어요.

이 반복 작업에서 벗어나려고 Docker로, 다시 Kubernetes로 넘어갔습니다.

이번 글에서는 베어메탈(물리 서버에 직접 설치) → Docker → Kubernetes를 실제로 다 거쳐보면서 느낀 장단점을 정리합니다.

세 방식 모두 "정답"은 없고, 상황에 따라 맞는 게 다릅니다. 각각을 직접 써본 입장에서 솔직하게 비교해볼게요.

1. 베어메탈 (물리 서버에 직접 설치)

OS 위에 서비스를 직접 설치하는, 가장 전통적인 방식입니다. 메일 서버면 메일 서버, 웹 서버면 웹 서버를 OS에 그대로 깔아서 운영하는 거죠.

장점

• 구조가 단순하고 직관적입니다. 추상화 계층이 없으니 "지금 이 서버에서 뭐가 돌고 있는지" 파악하기 쉽습니다.

• 성능 손실이 거의 없습니다. 하드웨어 자원을 그대로 다 쓰기 때문에 오버헤드가 가장 적습니다.

• 리눅스 기본기를 익히기에 좋습니다. 패키지 설치, 서비스 등록, 포트 설정 같은 걸 직접 만지게 되니까요.

단점

• 환경이 OS에 종속됩니다. 1편에서 겪은 문제가 바로 이것인데요, OS를 바꾸면 그 위에 깔았던 걸 전부 다시 설치하고 설정해야 합니다.

• 의존성 충돌이 골치 아픕니다. A 서비스는 라이브러리 1.0이 필요한데 B 서비스는 2.0이 필요하면, 한 OS 위에서 둘을 같이 돌리기가 까다로워집니다.

• 서비스가 늘어날수록 관리가 복잡해지고, 하나를 잘못 건드리면 다른 서비스에 영향이 가기 쉽습니다.

이럴 때 적합: 서비스가 한두 개로 단순하고, 성능을 최대한 끌어내야 하거나, 리눅스 자체를 깊게 공부하고 싶을 때.

2. Docker (컨테이너)

서비스를 "컨테이너"라는 격리된 상자에 담아 실행하는 방식입니다. 각 서비스가 자기만의 환경(라이브러리, 설정)을 컨테이너 안에 통째로 들고 있어서, OS와 분리됩니다.

장점

• 환경 재구축이 극적으로 편해집니다. 이게 제가 Docker로 넘어간 가장 큰 이유예요.
  설정을 파일(Dockerfile, docker-compose)로 정의해두면, OS나 하드웨어가 바뀌어도 그 파일만 가지고 거의 똑같이 환경을 되살릴 수 있습니다.

• 의존성 충돌이 사라집니다. 각 컨테이너가 독립된 환경을 가지므로, A는 라이브러리 1.0, B는 2.0을 써도 서로 간섭하지 않습니다.

• 격리성이 좋습니다. 한 컨테이너가 문제를 일으켜도 다른 컨테이너나 호스트 OS에 영향이 적습니다.

• 베어메탈보다 오버헤드가 적은 편입니다. 가상머신처럼 OS 전체를 통째로 띄우는 게 아니라 프로세스 단위로 격리하기 때문입니다.

단점

• 컨테이너 개념을 새로 배워야 합니다. 이미지, 컨테이너, 볼륨, 네트워크 같은 개념에 익숙해지는 데 시간이 걸립니다.

• 여러 컨테이너를 묶어서 관리하기 시작하면 한계가 옵니다. 컨테이너가 몇 개 안 될 때는 docker-compose로 충분하지만,
  서비스가 많아지고 "자동 복구", "부하 분산", "여러 서버에 걸친 배포" 같은 요구가 생기면 Docker 단독으로는 벅차집니다.

• 영구 데이터(볼륨) 관리에 신경 써야 합니다. 컨테이너는 기본적으로 일회성이라, 데이터를 어디에 어떻게 보관할지 명확히 설계해야 합니다.

이럴 때 적합: 여러 서비스를 깔끔하게 격리해서 운영하고 싶고, OS가 바뀌어도 환경을 빠르게 복원하고 싶을 때.
대부분의 개인 홈서버에는 사실 이 정도면 충분합니다.

3. Kubernetes (쿠버네티스, K8s)

여러 컨테이너를 자동으로 배포·관리·복구해주는 오케스트레이션 도구입니다.

Docker가 "컨테이너 하나하나를 다루는 것"이라면, Kubernetes는 "수많은 컨테이너를 묶어서 자동으로 운영하는 것"에 가깝습니다.

저는 Kubernetes 환경에서 메일 서비스, 블로그 서비스, Zabbix(모니터링), Jupyter Notebook 등을 구성해 운영하고 있습니다.

장점

• 자동화 수준이 차원이 다릅니다. 컨테이너가 죽으면 알아서 다시 띄우고(self-healing), 원하는 상태(desired state)를 선언해두면 시스템이 그 상태를 유지하려고 스스로 동작합니다.

• 확장성이 뛰어납니다. 부하가 늘면 컨테이너 수를 늘리고, 여러 서버(노드)에 걸쳐 서비스를 분산하는 것도 체계적으로 관리됩니다.

• 선언적 관리가 가능합니다. "이런 서비스를 이만큼 띄워라"를 YAML로 정의해두면 되니, 구성이 코드로 남아 재현성과 이력 관리가 좋습니다.

• 실무·취업 관점에서 공부 가치가 큽니다. 현업에서 컨테이너 오케스트레이션의 사실상 표준이라, 배워두면 활용도가 높습니다.
  제가 Docker에서 멈추지 않고 Kubernetes까지 간 결정적인 이유도 공부에 가장 적합하다고 판단했기 때문입니다.

단점

• 학습 곡선이 가파릅니다. Pod, Service, Deployment, Ingress, ConfigMap, PV/PVC 등 익혀야 할 개념이 많습니다. 솔직히 처음엔 용어부터 벽처럼 느껴집니다.

• 개인 홈서버 규모에는 과한 경우가 많습니다. 자동 복구·부하 분산 같은 강점은 서비스 규모가 클 때 빛나는데, 집에서 서비스 몇 개 돌리는 정도라면 그 강점을 다 누리기 어렵습니다. 한마디로 "닭 잡는 데 소 잡는 칼"이 될 수 있어요.

• 자원을 더 먹습니다. 클러스터를 운영하기 위한 구성 요소들이 돌아가야 해서, 같은 하드웨어라면 베어메탈이나 단순 Docker보다 여유 자원이 줄어듭니다.

• 트러블슈팅 난이도가 높습니다. 문제가 생겼을 때 어느 계층에서 터진 건지 추적하는 게 베어메탈보다 훨씬 복잡합니다.

이럴 때 적합: 컨테이너 오케스트레이션을 제대로 공부하고 싶거나, 여러 서비스를 자동화된 방식으로 안정적으로 운영하고 싶을 때,
그리고 학습 자체가 목적일 때 특히 가치가 큽니다.

한눈에 비교

그래서 무엇을 선택해야 할까?

직접 셋 다 거쳐본 입장에서 정리하면 이렇습니다.

• 서비스가 한두 개이고 단순하게 쓰고 싶다면 → 베어메탈도 충분합니다. 괜히 복잡하게 갈 필요 없어요.

• 여러 서비스를 깔끔하게 운영하고 싶고, 환경 복원이 편했으면 한다면 → Docker가 가성비 최고입니다. 개인 홈서버 대부분은 여기가 정답입니다.

• 자동화·확장을 제대로 경험하고 싶거나, 무엇보다 공부가 목적이라면 → Kubernetes로 가세요. 규모 대비 과하다는 건 알지만, 배우는 가치는 분명합니다.

저는 마지막 이유, 즉 "공부에 가장 적합하다"는 판단 때문에 Kubernetes까지 왔습니다.

홈서버는 어차피 실험하고 배우는 공간이니, 당장의 효율보다 학습 가치를 우선한 선택이었어요.

결국 정답은 "내가 이 서버로 뭘 하고 싶은가"에 달려 있다고 생각합니다.

단순 운영이 목적이면 굳이 무거운 도구로 갈 필요 없고, 배움이 목적이면 한 단계 더 들어가 보는 것도 충분히 가치 있습니다.

마치며

두 편에 걸쳐 라즈베리파이부터 Kubernetes까지, 5년간의 홈서버 여정을 정리해봤습니다.

매번 갈아엎느라 고생도 많았지만, 그때마다 한 단계씩 배운 게 쌓여서 지금의 구성에 이르렀네요.

혹시 비슷한 고민을 하고 계신 분이라면, 처음부터 완벽한 구성을 목표로 하기보다 일단 시작하고 필요할 때마다 발전시켜 나가는 것을 추천드립니다.

저도 그렇게 왔으니까요.

긴 글 읽어주셔서 감사합니다. 궁금하신 사항은 편한 방법으로 문의주세요!