Blog

가상화 엔지니어가 Kubernetes 를 이해하지 못하는 이유는?

가상화 엔지니어가 Kubernetes와 불변 인프라 개념을 이해하고 클라우드 네이티브 운영 방식에 적응하는 데 도움이 되는 가이드입니다.

2025년 04월 25일

가상화 엔지니어에게 클라우드 네이티브가 어려운 이유는?

기존의 가상화(Virtualization) 기술은 물리 서버를 논리적으로 분리하여 여러 개의 가상 머신(VM)으로 운영할 수 있게 해주는 기술입니다. 이러한 방식은 기존 IT 관리자들에게 익숙한 운영 환경을 제공하며, 기존의 서버 관리 방식과 유사하여 별도의 학습 없이도 운영이 가능합니다.

반면, 클라우드 네이티브(Cloud Native)는 애플리케이션을 클라우드 환경에서 최적화하여 개발하고 운영하는 새로운 접근 방식입니다. 이는 마이크로서비스 아키텍처, 컨테이너화, 지속적 통합 및 배포(CI/CD), 자동화된 오케스트레이션 도구(Kubernetes 등)를 포함하며, 기존의 운영 방식과는 근본적으로 다릅니다.

이러한 차이로 인해 클라우드 네이티브를 도입하려는 기업들은 다음과 같은 학습 장벽에 직면하게 됩니다:

기술적 복잡성 증가: 클라우드 네이티브 환경은 다양한 도구와 기술 스택을 요구하며, 이는 기존 IT 관리자들에게 새로운 학습 부담을 줍니다.
문화적 변화 필요: DevOps 문화와 같은 협업 중심의 운영 방식으로의 전환이 필요하며, 이는 조직 내 문화적 저항을 초래할 수 있습니다.
기존 시스템과의 통합 어려움: 레거시 시스템과의 통합은 기술적 복잡성을 증가시키며, 데이터 마이그레이션 및 호환성 문제를 야기할 수 있습니다.

이러한 이유로, 클라우드 네이티브의 도입은 단순한 기술적 전환을 넘어 조직 전체의 변화와 학습을 요구하며, 이는 기업들이 클라우드 네이티브를 도입하는 데 있어 주요한 걸림돌로 작용합니다.

쿠버네티스와 불변 인프라: 개념의 전환

전통적인 VM 환경에서는 서버에 직접 접속하여 패키지를 설치하거나 설정을 변경하는 방식이 일반적입니다. 이러한 방식은 시간이 지남에 따라 서버 간 설정 불일치(Configuration Drift)를 초래하고, 문제 발생 시 원인 파악과 복구가 어려워집니다.

반면, 쿠버네티스는 불변 인프라 개념을 채택하여, 한 번 배포된 인스턴스는 변경하지 않고, 변경이 필요할 경우 새로운 인스턴스를 생성하여 교체합니다. 이러한 방식은 일관성과 재현성을 보장하며, 롤백이 용이하고, 장애 발생 시 자동 복구가 가능합니다 .

가상화 엔지니어들이 자주 묻는 질문들

기존 VM 환경에 익숙한 가상화 엔지니어들은 쿠버네티스의 불변 인프라 개념에 대해 다음과 같은 질문을 자주 합니다.

1. “왜 SSH로 접속해서 설정을 변경하면 안 되나요?”

쿠버네티스에서는 설정 변경을 직접 수행하지 않고, 선언적 구성 파일을 통해 관리합니다. 직접 변경은 다음 배포 시 덮어쓰여질 수 있으며, 이는 시스템의 일관성을 해칠 수 있습니다.

2. “패치나 업데이트를 위해 매번 이미지를 새로 빌드해야 하나요?”

네, 불변 인프라에서는 변경 사항을 반영하기 위해 새로운 이미지를 빌드하고 배포합니다. 이러한 방식은 롤백을 용이하게 하고, 예측 가능한 배포를 가능하게 합니다 .

3. “서버가 살아있는데 서비스가 응답하지 않는 이유는 무엇인가요?”

쿠버네티스에서는 서버의 상태보다 애플리케이션의 상태를 중시합니다. readinessProbe와 livenessProbe를 통해 애플리케이션의 상태를 모니터링하며, 응답이 없을 경우 자동으로 조치를 취합니다.

4. “로그나 설정 파일을 직접 확인할 수 없나요?”

쿠버네티스에서는 로그와 설정 파일을 중앙화된 시스템에서 관리합니다. 직접 접근은 제한되며, kubectl logs나 로깅 시스템을 통해 확인해야 합니다.

5. “롤링 업데이트나 블루/그린 배포를 왜 사용해야 하나요?”

이러한 배포 전략은 무중단 배포를 가능하게 하며, 새로운 버전의 안정성을 확인한 후 트래픽을 전환하여 크를 최소화합니다 .

6. “쿠버네티스에서 애플리케이션을 어떻게 배포하나요?”

애플리케이션은 YAML 형식의 선언적 구성 파일을 통해 배포됩니다. 이 파일에는 파드, 서비스, 디플로이먼트 등의 리소스 정의가 포함됩니다.

7. “쿠버네티스를 사용하면 어떤 이점이 있나요?”

쿠버네티스는 컨테이너화된 애플리케이션의 자동 배포, 확장, 관리를 지원하여 운영 효율성을 높이고, 시스템의 안정성과 확장성을 향상시킵니다.

VM 환경과 쿠버네티스의 운영 방식 비교

항목	전통적인 VM 환경	쿠버네티스 환경
설정 변경	SSH로 직접 변경	선언적 구성 파일로 관리
배포 방식	수동 배포	자동화된 CI/CD 파이프라인
상태 모니터링	서버 중심	애플리케이션 중심
롤백/td>	수동 복구	자동 롤백 지원
로그 관리	서버 내 로그 확인	중앙화된 로깅 시스템 활용

쿠버네티스의 불변 인프라 개념은 기존의 운영 방식을 근본적으로 변화시킵니다. 이러한 전환은 초기에는 익숙하지 않을 수 있으나, 일관성, 안정성, 확장성 측면에서 많은 이점을 제공합니다. 가상화 엔지니어들이 이러한 개념을 이해하고 수용한다면, 더 효율적이고 안정적인 시스템 운영이 가능할 것입니다.

가상화 엔지니어는 이해하기 어려운 Kubernetes 개념들

쿠버네티스(Kubernetes)는 단순히 기존 VM 기반 시스템을 컨테이너로 옮긴 형태가 아니라,개념 자체가 완전히 다릅니다. 이를 제대로 이해하지 못하면 운영자든 개발자든 심각한 오해와 비효율, 오류를 경험하게 됩니다. 이번에는 쿠버네티스가 기존 VM 운영 패러다임과 어떻게 근본적으로 다른지, 그리고 그 차이에서 파생되는 혼란의 실제 사례를 운영자와 개발자의 관점에서 구체적으로 살펴보겠습니다.

1. 운영자가 이해하지 못하는 쿠버네티스의 개념적 충돌

문제 1: “서버에 접속해서 고치면 되잖아요”

VM 방식의 습관: SSH로 접속 → 로그 확인 → 설정 수정 → 재시작
K8s 방식의 충돌: Pod는 휘발성이고, 설정은 외부 선언(ConfigMap)으로 관리.

→ SSH 접속은 존재하지 않거나, 해도 의미 없음. 재시작하면 수정 내용 사라짐.

실제 사례: 운영자가 kubectl exec으로 들어가서 설정 파일 수정 후 “수정 완료” 보고. 다음날 Pod가 재시작되며 변경 내용 증발 → “Kubernetes는 왜 저장을 안 해주는지 모르겠다”고 항의.

문제 2: “이 Pod만 삭제하고 싶었는데 왜 다시 살아나요?”

VM 방식의 습관: 문제가 생긴 인스턴스 하나를 삭제해서 격리함.
K8s 방식의 충돌: Deployment가 .spec.replicas에 따라 Pod 수를 유지하려고 자동 복원.

실제 사례: 특정 Pod가 오류를 일으켜 kubectl delete pod로 삭제 → 몇 초 후 다시 생성 → 운영자는 “문제가 있는 Pod가 복제됐다”고 오해.

문제 3: “이거 고치려면 이미지 새로 빌드해야 하나요?”

VM 방식의 습관: 운영 중인 서버에 접속하여 설정이나 애플리케이션을 바로 수정 후 반영.
K8s 방식의 충돌: 컨테이너 이미지는 불변. 변경이 있으면 새로 빌드 → 레지스트리 → 재배포

실제 사례: 긴급한 설정 수정이 필요했는데 도커 빌드/푸시/배포까지 시간 오래 걸려 “이 방식은 너무 느리다”고 불만.

2. 개발자가 이해하지 못하는 쿠버네티스의 추상화 구조

문제 4: “서비스가 안 돼요. 근데 서버는 살아있어요.”

VM 환경: 서버 중심 모니터링의 한계

VM 기반 시스템에서 흔히 하는 착각은 “서버가 켜져 있으니 서비스도 정상이다”라는 전제입니다. 운영 모니터링 도구들도 CPU, Memory, Disk 사용량 중심으로 동작하기 때문에, 실제로 애플리케이션이 다운되어도 서버 상태만 보면 ‘정상’로 표시됩니다.

실제 사례: 웹 서버가 OutOfMemory로 인해 애플리케이션은 종료됐지만, VM은 정상 상태 유지. 서버 모니터링에서는 문제가 감지되지 않아 고객은 서비스 불능 상태로 수 시간 대기.

Kubernetes는 이 문제를 어떻게 해결하나?

Kubernetes는 Pod의 상태를 단순한 프로세스 생존 여부로 보지 않고, readinessProbe와 livenessProbe를 통해 서비스가 실제로 응답 가능한지를 지속적으로 체크합니다. Pod가 응답하지 않으면 자동으로 트래픽에서 제외하고, 문제가 반복되면 새로 띄워 복구를 시도합니다.

Kubernetes는 ‘서버가 살아있는가’가 아니라 ‘서비스가 응답 가능한가’를 기준으로 판단합니다.

문제 5: “내 코드는 정상인데 왜 배포가 실패하죠?”

VM 환경: 배포 후 모니터링이 아닌, 문제 발생 후 복구 중심의 운영

VM 환경에서는 대부분 빌드가 끝나면 바로 서버에 배포하고, 그 결과를 사후에 확인합니다. 만약 환경 변수 누락, 설정 오류, 포트 충돌 등으로 서비스가 정상적으로 뜨지 않더라도, VM에서는 이를 자동으로 감지하지 못합니다. 운영자가 문제를 수동으로 찾아야 하며, 롤백도 어려운 경우가 많습니다.

실제 사례: 운영 환경에서 Spring Boot 앱 배포 후 DB 연결 정보 누락 → 서비스 중단.이전 상태로 되돌리기 어려워, 긴급 패치와 로그 분석에 몇 시간이 소요됨

Kubernetes는 이 문제를 어떻게 해결하나?

Kubernetes는 애플리케이션이 실제로 정상적으로 기동되고, 외부 요청에 응답할 준비가 되어 있는지를 readinessProbe로 판단합니다. 준비되지 않은 상태에서는 Service가 트래픽을 전달하지 않기 때문에 사용자에게 불안정한 상태가 노출되지 않습니다. 또한 문제가 발생하면 롤백하거나, 이전 버전으로 빠르게 되돌릴 수 있는 구조를 갖추고 있습니다.

Kubernetes는 배포가 끝난 후에도 “서비스가 준비되었는가”를 중심으로 상태를 판단하고, 자동으로 보호합니다.

문제 6: “로그가 없어요. 로그가 어디 있어요?”

VM 방식의 접근: /var/log 또는 tail -f로 직접 확인.
K8s 방식의 충돌: 로그는 kubectl logs, Sidecar, 중앙 로깅 시스템으로 확인해야 함. Pod가 사라지면 로그도 사라짐.

실제 사례: Pod crash 후 kubectl logs 조회했는데 이미 GC 되어 사라짐 → “디버깅이 불가능하다”고 불만.

Immutable Infrastructure 는 무엇일까?

Immutable Infrastructure(불변 인프라)는 오늘날 클라우드 네이티브 환경과 데브옵스 문화에서 점점 더 중요하게 여겨지는 개념입니다.

이 용어가 의미하는 바는 단순히 “변경하지 않는 인프라”라는 수준이 아니라, 인프라 운영의 철학 자체가 과거와는 근본적으로 달라졌다는 것을 나타냅니다.

기존의 전통적인 인프라 운영 방식은 변경이 일상적이었습니다. 서버를 띄우고, 운영 중에 패키지를 설치하거나 보안 패치를 적용하고, 설정을 바꾸며 점진적으로 변경을 축적하는 식이었습니다. 이러한 방식은 시간이 지날수록 시스템 간 일관성을 해치고, 장애 발생 시 원인 분석과 복구를 어렵게 만들었습니다.

반면, 불변 인프라에서는 서버 혹은 인스턴스를 한 번 정의하면 그 상태는 절대 변경되지 않습니다. 새로운 변경이 필요하면 기존 인스턴스를 수정하는 것이 아니라, 새로운 버전의 이미지를 생성하여 그것을 배포하고 기존 인스턴스를 폐기합니다. 이렇게 하면 인프라는 항상 동일한 방식으로 재현 가능하며, 테스트 환경과 운영 환경의 차이로 인한 문제가 크게 줄어듭니다.

특히 이 개념은 컨테이너 기반 환경에서 자연스럽게 적용됩니다. 예를 들어 Docker 이미지는 한 번 빌드되면 고정된 형태로 유지되며, 애플리케이션 실행 시 항상 동일한 환경을 제공합니다. 이를 쿠버네티스 같은 오케스트레이션 도구와 결합하면, 전체 서비스는 배포 단위로서 불변성을 유지하면서도 필요 시 빠르게 롤백하거나 새로운 버전으로 교체할 수 있습니다.

불변 인프라는 또한 CI/CD(지속적 통합 및 지속적 배포)와도 매우 잘 어울립니다. 새로운 코드 변경 사항이 있으면 이미지가 다시 빌드되고, 테스트를 거쳐 배포됩니다. 이 과정에서 운영자는 “어떤 환경에서 무엇이 돌아가고 있는지”에 대한 불확실성을 제거할 수 있으며, 배포 실패 시에도 간단하게 이전 이미지로 롤백함으로써 신속하게 서비스를 안정화할 수 있습니다.

결국 불변 인프라는 단지 인프라를 다루는 방식의 변화가 아니라, 애플리케이션 배포, 운영, 장애 복구, 보안, 테스트에 이르기까지 전반적인 운영 전략의 변화라고 볼 수 있습니다. 변화의 주도권을 사람에서 코드로, 수작업에서 자동화로 옮긴다는 점에서, 불변 인프라는 클라우드 네이티브 환경의 핵심적 기반이자, MSA(Microservice Architecture)를 안정적으로 운영하기 위한 전제조건이 됩니다.

마무리

쿠버네티스(Kubernetes)를 도입하고 운영하는 데 있어, 엔지니어들이 반드시 이해해야 할 가장 핵심적인 개념은 쿠버네티스는 ‘불변 인프라(Immutable Infrastructure)’를 전제로 설계된 플랫폼이라는 사실입니다. 이 개념을 정확히 이해하지 못하면, 쿠버네티스의 동작 원리와 철학을 오해하게 되고, 결국 기존 방식과의 충돌로 인해 운영 상 혼란을 겪게 됩니다.

기존의 VM 환경에서는 운영자나 개발자가 SSH로 서버에 직접 접속해 설정 파일을 수정하거나, 로그를 확인하고, 패키지를 설치하는 방식이 일반적입니다. 이러한 방식은 서버 중심의 운영 철학에 기반하고 있으며, 수동 변경이 반복되면 결국 시스템 간 설정 불일치(Configuration Drift)로 이어지고, 문제 발생 시 재현이나 복구가 어렵다는 치명적인 단점이 존재합니다.

반면, 쿠버네티스는 이러한 문제를 해결하기 위해 모든 구성 요소를 선언적으로 정의하고, 변경이 필요할 때마다 새로 배포함으로써 상태를 유지합니다. 사용자는 클러스터 내부의 상태를 직접 조작하는 것이 아니라, “이 시스템이 어떤 상태여야 한다”는 선언(declaration)을 작성하고, 쿠버네티스는 그 상태에 도달하도록 자동으로 조정(reconcile)하는 방식으로 동작합니다.

예를 들어, 설정을 바꾸고 싶다면 컨테이너 내부를 직접 수정하는 것이 아니라 ConfigMap을 수정하고, 그에 맞춰 Deployment 리소스를 재배포해야 합니다. 문제가 생긴 Pod는 수동으로 접근해 고치는 것이 아니라, 자동으로 감지되고 교체되며, 그 전체 흐름은 CI/CD 또는 GitOps 파이프라인 안에서 관리되어야 합니다. 이처럼 쿠버네티스는 수동 개입보다 자동화된 복구, 배포, 관리를 지향하며, 이는 곧 시스템의 일관성, 안정성, 확장성으로 이어집니다.

따라서 쿠버네티스를 제대로 활용하기 위해서는 단순히 YAML을 작성하는 법이나 kubectl 명령어 사용법만 익히는 것으로는 부족합니다. “애플리케이션을 상태 기반으로 운영하는 방식”, “직접 접속하지 않고 정의로 관리하는 사고 방식”,”모든 변경은 불변 이미지를 통해 이루어진다“는 점을 철저히 이해하고, 기존 서버 기반 운영 마인드에서 서비스 중심, 선언형 운영 모델로의 전환이 선행되어야 합니다.

요약하자면, 쿠버네티스는 단지 컨테이너를 배포하는 도구가 아니라, 현대적인 소프트웨어 운영의 원칙과 철학을 강제하는 플랫폼이며, 이를 수용하는 것이 엔지니어의 가장 중요한 첫걸음입니다.