Container,Kubernetes
[발표자료 다운로드] 왜 쿠버네티스를 알아야 하나? 쿠버네티스의 작동원리부터 운영까지
쿠버네티스(Kubernetes)를 배우려면 리눅스와 네트워크 기초부터 컨테이너 개념, Pod와 Service 같은 리소스까지 넓은 배경지식이 한꺼번에 필요합니다. 이 학습 절벽(Learning Cliff) 을 낮추려고 만든 발표 자료를 공개합니다. 9개 장 61쪽, 발표자 노트 기준 약 69분 분량이며, 특정 벤더에 기대지 않은 중립적인 관점으로 정리했습니다.
2026년 08월 27일
CNF 백서 구독하기🔔
새로운 백서가 발간되면 가장 먼저 안내드려요!
CNF가 전하는 최신 백서와 클라우드 인사이트를 가장 빠르게 만나보실 수 있습니다.
진심으로 구독 부탁드립니다 🙏
발표 영상으로 먼저 보기
자료의 앞부분을 영상으로 먼저 확인하실 수 있습니다.
이 자료가 답하는 다섯 가지 질문
쿠버네티스를 처음 검토하는 실무자와 관리자가 반드시 답을 가져야 할 질문에 순서대로 답합니다.
- 쿠버네티스란 정확히 무엇이고, 왜 “클라우드의 커널”이라 부르는가
- 컨테이너는 가상화와 무엇이 다르며, 왜 지금 컨테이너화해야 하는가
- 불변 인프라(Immutable Infrastructure)는 기존 운영과 무엇이 다른가
- 오토스케일링과 자가 치유는 어떤 원리로 동작하는가
- 도입은 어떤 단계를 밟아야 하고, 조직은 무엇을 준비해야 하는가
쿠버네티스는 클라우드의 커널이다
쿠버네티스를 한마디로 설명할 때 가장 잘 통하는 비유가 커널입니다. 리눅스 커널이 프로세스·메모리·장치를 관리하며 하드웨어를 추상화하듯, 쿠버네티스는 컨테이너 스케줄링·리소스 관리·네트워크·스토리지를 다루며 클라우드를 추상화합니다. 자료의 이 장표는 커널의 기능과 쿠버네티스의 기능을 좌우로 나란히 놓아 일대일로 대응시킵니다.
▲ Kubernetes = 클라우드의 커널(OS) (발표자료 7쪽)
쿠버네티스 자체는 컨테이너화된 애플리케이션을 자동으로 배포·스케일·관리하는 오픈소스 소프트웨어입니다. Go 언어로 작성되었고 Apache 2.0 라이선스이며, 특정 벤더가 아니라 CNCF(Cloud Native Computing Foundation)가 중립적으로 관리합니다. 쿠버네티스는 CNCF 최초의 졸업(Graduated) 프로젝트이기도 합니다. 이 프로젝트가 어떻게 시작해 표준이 되었는지는 쿠버네티스의 탄생과 진화에서 따로 다룹니다.
컨테이너가 가벼운 이유는 커널을 공유하기 때문입니다. 가상 머신은 인스턴스마다 게스트 OS를 통째로 반복하지만, 컨테이너는 호스트 커널을 공유해 게스트 OS가 없습니다. 그래서 낮은 오버헤드, 어디서나 실행, 일관된 런타임이라는 세 가지를 함께 얻습니다.
▲ 가상화 기술 vs 컨테이너 기술 (발표자료 8쪽)
같은 하드웨어에서 집적도가 2.5배 높다
“가볍다”는 말은 숫자로 확인해야 설득이 됩니다. 자료에는 두 가지 실측 비교가 실려 있습니다.
첫째는 기동 시간입니다. 가상 환경은 게스트 OS를 부팅해야 하므로 분 단위가 걸리지만, 컨테이너는 별도 OS가 없어 초 단위로 뜹니다.
둘째는 집적도입니다. 동일한 하드웨어(4Core / 16GB)에서 Red Hat Virtualization 기반 가상화는 톰캣 인스턴스 16개를 올렸지만, 컨테이너 환경은 40개를 올렸습니다. 같은 하드웨어에서 집적도가 2.5배 높다는 실측 결과입니다.
▲ 가상화와 컨테이너 집적도 비교 — 2.5배 (발표자료 22쪽)
불변 인프라 — 고치지 말고 교체하라
이 자료에서 가장 중요한 패러다임은 불변 인프라입니다. 필요성을 이해하려면 반대 현상인 Configuration Drift를 먼저 알아야 합니다. 같은 상태로 배포된 서버들도 손으로 고친 임시 수정과 패치가 쌓이면 시간이 갈수록 제각각이 됩니다. 결국 아무도 정확한 상태를 모르고 똑같이 다시 만들 수도 없는 눈덩이 서버가 되어, 장애를 재현할 수도 추적할 수도 없게 됩니다.
불변 인프라의 원칙은 단순합니다. 배포된 서버는 절대 변경하지 않고, 업데이트가 필요하면 덮어쓰는 대신 버리고 새로 만든다. 이 태도 차이를 가장 잘 보여주는 비유가 Pets vs Cattle입니다. 과거에는 서버를 애완동물처럼 다뤘습니다 — 이름을 붙이고, 아프면 정성껏 치료하고, 대체 불가능한 존재로 여겼습니다. 불변 인프라는 서버를 가축처럼 다룹니다 — 번호로 관리하고, 문제가 생기면 고치지 않고 교체합니다. 쿠버네티스의 Pod가 정확히 이 방식입니다.
▲ Pets vs Cattle — 서버를 대하는 두 태도 (발표자료 29쪽)
배포 파이프라인에서도 차이가 분명합니다. Mutable 방식은 환경마다 실행 중인 서버를 다시 구성해 상태가 달라지지만, Immutable 방식은 이미지를 한 번만 빌드해 스테이징과 프로덕션에 동일하게 배포합니다. 핵심 차이는 변경의 대상입니다 — 서버를 바꾸느냐, 이미지를 교체하느냐.
▲ Mutable vs Immutable 배포 파이프라인 (발표자료 33쪽)
도입은 한 번에 하지 않고 네 단계로 나눈다
쿠버네티스 도입은 한 번에 전환하는 일이 아니라 단계적으로 성숙도를 높여가는 여정입니다. 자료는 로드맵을 도입 검토 → 시범 운영 → 본격 확산 → 내재화의 네 단계로 제시합니다. 각 단계를 건너뛰지 않는 것이 중요합니다.
▲ Kubernetes 도입 로드맵 4단계 (발표자료 47쪽)
함께 준비할 실행 단계도 네 가지입니다 — 컨테이너 특성에 맞는 대상 선정, 요구에 맞는 플랫폼 선정, 성공을 판단할 메트릭 정의, 자동화와 변화에 대응하는 조직 문화 정렬입니다. 도입은 기술만의 변화가 아니어서, 인프라·개발·조직 세 축이 함께 움직여야 성공합니다. 비용 관점의 비교는 쿠버네티스 도입 전략 — 로드맵과 TCO 비교에서 다룹니다.
Reconciliation Loop — 원하는 상태를 유지하는 원리
쿠버네티스의 자동화가 실제로 어떻게 동작하는지는 Reconciliation Loop 하나로 설명됩니다. 컨트롤러는 원하는 상태(desired) 와 현재 상태(actual) 두 값을 가지고, 관찰·비교·조정을 끝없이 반복합니다.
동작은 세 단계입니다. 원하는 컨테이너 수가 5개인데 현재 2개라면, 현재 상태를 관찰하고(Observe), 원하는 상태와 비교해 3개가 부족함을 계산하고(Analyze), 3개를 새로 생성해 5개로 맞춥니다(Act).
▲ 컨테이너 수 조정 — Observe → Analyze → Act (발표자료 58쪽)
자가 치유(Self-Healing)도 같은 원리입니다. 무상태(Stateless) 애플리케이션은 동일 복제본으로 즉시 교체하고, 상태를 가진(Stateful) 애플리케이션은 영구 볼륨과 함께 동적으로 복구합니다. 안쪽을 더 들여다보면 Deployment Controller가 ReplicaSet을, ReplicaSet Controller가 Pod를 만드는 식으로 여러 컨트롤러가 단계적으로 협력합니다. 이 루프가 만들어내는 상태 변화를 관측하는 방법은 Prometheus가 쿠버네티스 메트릭의 표준이 된 이유에서 이어집니다.
핵심 정리 — 이것만 기억하세요
자료 전체는 네 문장으로 요약됩니다.
- 컨테이너는 이식성과 일관성을 준다 — 커널을 공유해 가볍고, 어디서나 동일하게 실행된다.
- 불변 인프라는 고치지 말고 교체하는 것이다 — 변경하지 않으므로 Configuration Drift가 생기지 않는다.
- 쿠버네티스는 오케스트레이션 표준이자 자가 조정 시스템이다 — 선언한 상태를 스스로 유지한다.
- 오픈 거버넌스와 표준 인터페이스가 종속을 없앤다 — CNCF 인증 배포판 60종 이상이 그 증거다.
자주 묻는 질문
쿠버네티스란 무엇인가요?
쿠버네티스는 컨테이너화된 애플리케이션을 자동으로 배포·스케일·관리하는 오픈소스 소프트웨어입니다. Go 언어로 작성되었고 Apache 2.0 라이선스이며, 특정 벤더가 아니라 CNCF(Cloud Native Computing Foundation)가 중립적으로 관리합니다. 쿠버네티스는 CNCF 최초의 졸업(Graduated) 프로젝트입니다.
컨테이너와 가상 머신은 무엇이 다른가요?
가상 머신은 인스턴스마다 게스트 OS를 통째로 반복하지만, 컨테이너는 호스트 커널을 공유해 게스트 OS가 없습니다. 그래서 가상 환경은 기동에 분 단위가 걸리는 반면 컨테이너는 초 단위로 뜨고, 동일한 하드웨어(4Core / 16GB)에서 측정한 집적도는 가상화가 톰캣 16개, 컨테이너가 40개로 2.5배 차이가 났습니다.
불변 인프라(Immutable Infrastructure)란 무엇인가요?
불변 인프라는 배포된 서버를 절대 변경하지 않고, 업데이트가 필요하면 덮어쓰는 대신 버리고 새로 만드는 방식입니다. 서버를 애완동물처럼 고쳐 쓰는 대신 가축처럼 교체하기 때문에, 손으로 고친 수정이 쌓여 서버가 제각각이 되는 Configuration Drift가 발생하지 않습니다.
Reconciliation Loop는 어떻게 동작하나요?
컨트롤러가 원하는 상태(desired)와 현재 상태(actual)를 비교해 차이를 없애는 과정을 무한히 반복합니다. 원하는 컨테이너 수가 5개인데 현재 2개라면, 현재 상태를 관찰하고(Observe), 3개가 부족함을 계산하고(Analyze), 3개를 새로 생성해 5개로 맞춥니다(Act).
쿠버네티스는 어떤 팀에게 필요한가요?
하루에 여러 번 배포하거나, 이벤트성 부하에 대응해야 하거나, 잦은 설정 변경 이력을 관리해야 하거나, 복잡한 작업 절차를 단순화하려 하거나, 명확한 배포 정책과 롤백이 필요한 팀입니다. 변화가 빠르고 자동화가 절실한 팀일수록 효과가 큽니다.
참고 리소스
이 자료를 읽고 더 깊이 들어가실 때 함께 보시면 좋은 글입니다.
개념부터 도입까지
- 쿠버네티스(Kubernetes) 란 무엇인가 — 개념과 도입 이유
- 쿠버네티스의 탄생과 진화 — 구글 보그에서 AI 운영체제까지
- 쿠버네티스 도입 전략 — 로드맵과 TCO 비교
- 쿠버네티스 프로덕션 도입 사례와 운영 교훈
운영·아키텍처
- 쿠버네티스 네트워킹과 CNI — Calico·Cilium·Flannel 비교
- Prometheus 가 쿠버네티스 메트릭의 표준이 된 이유
- 쿠버네티스 Private 컨테이너 레지스트리 구축 방법
전자책 — 클라우드 네이티브와 컨테이너
- 1.2.3 불변 인프라(Immutable Infrastructure) 개념 이해
- 2.1.3 컨테이너화의 필요성 및 장점
- 3.1 쿠버네티스의 시작
- 3.2 쿠버네티스와 클라우드 네이티브
- 3.3 컨테이너 기반 배포와 쿠버네티스
- 3.4.2 쿠버네티스의 선언적 API와 자동화
함께 받는 자료







