
Intro
안녕하세요. 환이s입니다 👋
이번 글에서는 왜 많은 기업과 서비스 환경에서 Kubernetes를 선택하게 되었는지,
기존 서버 운영 방식과 비교하여 그 이유를 정리해 보려고 합니다.
서비스를 운영하다 보면 트래픽 변화, 서버 장애, 버전 업데이트 등
여러 운영 이슈를 지속적으로 마주하게 됩니다.
특히 하나의 서비스가 아닌 여러 서비스를 동시에 운영하는 환경이라면
서버 자원 관리와 운영 자동화의 중요성은 더욱 커지게 됩니다.
이번 글에서는
기존 서버 운영 방식의 한계와
Kubernetes를 도입했을 때 어떤 점이 달라지는지를
개념 위주로 정리해 보겠습니다.
1. 기존 서버 운영 방식의 한계(한 서버에 한 시스템)
기존 서버 환경에서는
일반적으로 한 서버에 하나의 서비스를 올려서 운영하는 방식을 사용해 왔습니다.
예를 들어,
A, B, C 총 3개의 서비스를 운영하고 있다고 가정해 보겠습니다.

서비스별 트래픽 패턴은 시간대마다 다릅니다.
- 아침에는 A 서비스 트래픽 증가
- 정오에는 B 서비스 트래픽 증가
- 밤에는 C 서비스 트래픽 증가
하지만 문제는
각 서비스가 최대 트래픽을 기준으로 서버 자원을 미리 확보해야 한다는 점입니다.
A 서비스는 아침 시간대를 대비해
다른 시간대에 트래픽이 적더라도
항상 3대의 서버를 고정으로 사용해야 합니다.
B, C 서비스도 마찬가지입니다.
결과적으로 필요한 서버 수는
- A 서비스: 3대
- B 서비스: 3대
- C 서비스: 3대
👉 총 9대의 서버가 필요하게 됩니다.
이 구조에서 운영 부담은 여기서 끝나지 않습니다.

운영 중인 서버에 장애가 발생할 경우를 대비해
각 서비스별로 백업 서버(Spare Server) 를 추가로 운영해야 합니다.
즉,
- 운영 서버: 9대
- 장애 대비 서버: 3대
👉 총 12대의 서버가 필요하게 됩니다.
또한 서비스 버전 업데이트 시에도 문제가 발생합니다.
- 서비스 중단이 가능하면
→ 전체 서버를 내린 뒤 업데이트 - 무중단이 필요하면
→ 서버를 한 대씩 내렸다 올리는 순차 배포
이 방식은
- 서버 자원 활용률 저하
- 운영 복잡도 증가
- 관리 비용 증가
로 이어질 수밖에 없습니다.
2. Kubernetes 환경에서의 서버 운영 방식
Kubernetes 환경에서는
서버 자원을 바라보는 관점 자체가 달라집니다.

서비스별 최대 트래픽이 아니라
전체 서비스의 평균 트래픽을 기준으로 서버 자원을 운영합니다.
A, B, C 서비스의 하루 평균 트래픽을 계산해 보면
실제로 필요한 자원은 약 4대 분량의 서버 자원입니다.
Kubernetes는 Auto Scaling 기능을 통해
- 트래픽이 증가하면 → 자동으로 자원 확장
- 트래픽이 감소하면 → 자원 축소
를 수행합니다.
즉,
- 아침 / 정오 / 밤 시간대와 관계없이
- 필요한 만큼만 서버 자원을 사용
할 수 있게 됩니다.

또한 Kubernetes는 Auto Healing 기능을 제공합니다.
특정 서버에 장애가 발생하더라도
해당 서버에서 실행 중이던 서비스(Pod)는
자동으로 정상 서버로 옮겨져 다시 실행됩니다.
이로 인해
- 서비스별 백업 서버를 따로 둘 필요 없이
- 클러스터 기준으로 여분의 서버 한 대만 있어도
안정적인 운영이 가능합니다.
배포 역시 Deployment를 통해
- 무중단 롤링 업데이트
- 장애 발생 시 자동 복구
- 배포 과정 자동화
가 기본적으로 제공됩니다.
운영자는 이제 서버 단위 관리가 아니라 서비스 단위 관리에 집중할 수 있게 됩니다.
📝 마무리
이번 글에서는
기존 서버 운영 방식의 한계와 Kubernetes를 도입했을 때 어떤 점이 달라지는지를 개념 중심으로 정리해 보았습니다.
Kubernetes를 사용하면
- 서버 자원 사용 효율 극대화
- 트래픽 변화에 따른 자동 확장
- 장애 발생 시 자동 복구
- 무중단 배포 지원
- 운영 자동화를 통한 관리 부담 감소
와 같은 장점을 얻을 수 있습니다.
이러한 이유로 Kubernetes는 현재 현대 인프라 환경의 기본 기술로 자리 잡게 되었습니다.
궁금한 점이나 추가로 다뤄줬으면 하는 내용이 있다면
언제든지 편하게 말씀해 주세요! 🙌😊
위 포스팅 글은 일프로님의 대세는 쿠버네티스(초급~중급편) 강의를 참고했습니다.
'[ Infra ] > Kubernetes' 카테고리의 다른 글
| [Kubernetes] VM vs Container (1) | 2026.02.03 |
|---|