CNF 블로그

CNF 블로그에서 최신 정보와 유용한 팁을 만나보세요. 다양한 콘텐츠와 전문 지식을 통해 더 나은 경험을 제공합니다.

목차 (Agenda)

Container,Kubernetes

[발표자료 다운로드] 왜 쿠버네티스를 알아야 하나? 쿠버네티스의 작동원리부터 운영까지

쿠버네티스(Kubernetes)를 배우려면 리눅스와 네트워크 기초부터 컨테이너 개념, Pod와 Service 같은 리소스까지 넓은 배경지식이 한꺼번에 필요합니다. 이 학습 절벽(Learning Cliff) 을 낮추려고 만든 발표 자료를 공개합니다. 9개 장 61쪽, 발표자 노트 기준 약 69분 분량이며, 특정 벤더에 기대지 않은 중립적인 관점으로 정리했습니다.

2026년 08월 27일

발표자료 다운로드

아래 버튼에서 전체 61쪽 PDF를 받으실 수 있습니다. 발표자료 다운로드 후 사내 교육이나 도입 검토 자료로 그대로 쓰셔도 됩니다.

CNF 백서 구독하기🔔

새로운 백서가 발간되면 가장 먼저 안내드려요!

CNF가 전하는 최신 백서와 클라우드 인사이트를 가장 빠르게 만나보실 수 있습니다.

진심으로 구독 부탁드립니다 🙏

발표 영상으로 먼저 보기

자료의 앞부분을 영상으로 먼저 확인하실 수 있습니다.

쿠버네티스가 처음이라면

쿠버네티스 (Kubernetes) 란 무엇인가 — 개념과 도입 이유

이 발표자료는 개념부터 도입 로드맵까지를 61쪽으로 빠르게 훑습니다.

쿠버네티스가 정확히 무엇이고 왜 필요한지 차근히 짚고 싶다면, 개념을 정리한 대표 가이드에서 이어 보실 수 있습니다.

이 자료가 답하는 다섯 가지 질문

쿠버네티스를 처음 검토하는 실무자와 관리자가 반드시 답을 가져야 할 질문에 순서대로 답합니다.

  • 쿠버네티스란 정확히 무엇이고, 왜 “클라우드의 커널”이라 부르는가
  • 컨테이너는 가상화와 무엇이 다르며, 왜 지금 컨테이너화해야 하는가
  • 불변 인프라(Immutable Infrastructure)는 기존 운영과 무엇이 다른가
  • 오토스케일링과 자가 치유는 어떤 원리로 동작하는가
  • 도입은 어떤 단계를 밟아야 하고, 조직은 무엇을 준비해야 하는가

쿠버네티스는 클라우드의 커널이다

쿠버네티스를 한마디로 설명할 때 가장 잘 통하는 비유가 커널입니다. 리눅스 커널이 프로세스·메모리·장치를 관리하며 하드웨어를 추상화하듯, 쿠버네티스는 컨테이너 스케줄링·리소스 관리·네트워크·스토리지를 다루며 클라우드를 추상화합니다. 자료의 이 장표는 커널의 기능과 쿠버네티스의 기능을 좌우로 나란히 놓아 일대일로 대응시킵니다.

Kubernetes = 클라우드의 커널(OS)

▲ Kubernetes = 클라우드의 커널(OS) (발표자료 7쪽)

쿠버네티스 자체는 컨테이너화된 애플리케이션을 자동으로 배포·스케일·관리하는 오픈소스 소프트웨어입니다. Go 언어로 작성되었고 Apache 2.0 라이선스이며, 특정 벤더가 아니라 CNCF(Cloud Native Computing Foundation)가 중립적으로 관리합니다. 쿠버네티스는 CNCF 최초의 졸업(Graduated) 프로젝트이기도 합니다. 이 프로젝트가 어떻게 시작해 표준이 되었는지는 쿠버네티스의 탄생과 진화에서 따로 다룹니다.

컨테이너가 가벼운 이유는 커널을 공유하기 때문입니다. 가상 머신은 인스턴스마다 게스트 OS를 통째로 반복하지만, 컨테이너는 호스트 커널을 공유해 게스트 OS가 없습니다. 그래서 낮은 오버헤드, 어디서나 실행, 일관된 런타임이라는 세 가지를 함께 얻습니다.

가상화 기술 vs 컨테이너 기술

▲ 가상화 기술 vs 컨테이너 기술 (발표자료 8쪽)

같은 하드웨어에서 집적도가 2.5배 높다

“가볍다”는 말은 숫자로 확인해야 설득이 됩니다. 자료에는 두 가지 실측 비교가 실려 있습니다.

첫째는 기동 시간입니다. 가상 환경은 게스트 OS를 부팅해야 하므로 분 단위가 걸리지만, 컨테이너는 별도 OS가 없어 초 단위로 뜹니다.

둘째는 집적도입니다. 동일한 하드웨어(4Core / 16GB)에서 Red Hat Virtualization 기반 가상화는 톰캣 인스턴스 16개를 올렸지만, 컨테이너 환경은 40개를 올렸습니다. 같은 하드웨어에서 집적도가 2.5배 높다는 실측 결과입니다.

가상화와 컨테이너 집적도 비교 — 2.5배

▲ 가상화와 컨테이너 집적도 비교 — 2.5배 (발표자료 22쪽)

불변 인프라 — 고치지 말고 교체하라

이 자료에서 가장 중요한 패러다임은 불변 인프라입니다. 필요성을 이해하려면 반대 현상인 Configuration Drift를 먼저 알아야 합니다. 같은 상태로 배포된 서버들도 손으로 고친 임시 수정과 패치가 쌓이면 시간이 갈수록 제각각이 됩니다. 결국 아무도 정확한 상태를 모르고 똑같이 다시 만들 수도 없는 눈덩이 서버가 되어, 장애를 재현할 수도 추적할 수도 없게 됩니다.

불변 인프라의 원칙은 단순합니다. 배포된 서버는 절대 변경하지 않고, 업데이트가 필요하면 덮어쓰는 대신 버리고 새로 만든다. 이 태도 차이를 가장 잘 보여주는 비유가 Pets vs Cattle입니다. 과거에는 서버를 애완동물처럼 다뤘습니다 — 이름을 붙이고, 아프면 정성껏 치료하고, 대체 불가능한 존재로 여겼습니다. 불변 인프라는 서버를 가축처럼 다룹니다 — 번호로 관리하고, 문제가 생기면 고치지 않고 교체합니다. 쿠버네티스의 Pod가 정확히 이 방식입니다.

Pets vs Cattle — 서버를 대하는 두 태도

▲ Pets vs Cattle — 서버를 대하는 두 태도 (발표자료 29쪽)

배포 파이프라인에서도 차이가 분명합니다. Mutable 방식은 환경마다 실행 중인 서버를 다시 구성해 상태가 달라지지만, Immutable 방식은 이미지를 한 번만 빌드해 스테이징과 프로덕션에 동일하게 배포합니다. 핵심 차이는 변경의 대상입니다 — 서버를 바꾸느냐, 이미지를 교체하느냐.

Mutable vs Immutable 배포 파이프라인

▲ Mutable vs Immutable 배포 파이프라인 (발표자료 33쪽)

도입은 한 번에 하지 않고 네 단계로 나눈다

쿠버네티스 도입은 한 번에 전환하는 일이 아니라 단계적으로 성숙도를 높여가는 여정입니다. 자료는 로드맵을 도입 검토 → 시범 운영 → 본격 확산 → 내재화의 네 단계로 제시합니다. 각 단계를 건너뛰지 않는 것이 중요합니다.

Kubernetes 도입 로드맵 4단계

▲ Kubernetes 도입 로드맵 4단계 (발표자료 47쪽)

함께 준비할 실행 단계도 네 가지입니다 — 컨테이너 특성에 맞는 대상 선정, 요구에 맞는 플랫폼 선정, 성공을 판단할 메트릭 정의, 자동화와 변화에 대응하는 조직 문화 정렬입니다. 도입은 기술만의 변화가 아니어서, 인프라·개발·조직 세 축이 함께 움직여야 성공합니다. 비용 관점의 비교는 쿠버네티스 도입 전략 — 로드맵과 TCO 비교에서 다룹니다.

Reconciliation Loop — 원하는 상태를 유지하는 원리

쿠버네티스의 자동화가 실제로 어떻게 동작하는지는 Reconciliation Loop 하나로 설명됩니다. 컨트롤러는 원하는 상태(desired)현재 상태(actual) 두 값을 가지고, 관찰·비교·조정을 끝없이 반복합니다.

동작은 세 단계입니다. 원하는 컨테이너 수가 5개인데 현재 2개라면, 현재 상태를 관찰하고(Observe), 원하는 상태와 비교해 3개가 부족함을 계산하고(Analyze), 3개를 새로 생성해 5개로 맞춥니다(Act).

컨테이너 수 조정 — Observe → Analyze → Act

▲ 컨테이너 수 조정 — Observe → Analyze → Act (발표자료 58쪽)

자가 치유(Self-Healing)도 같은 원리입니다. 무상태(Stateless) 애플리케이션은 동일 복제본으로 즉시 교체하고, 상태를 가진(Stateful) 애플리케이션은 영구 볼륨과 함께 동적으로 복구합니다. 안쪽을 더 들여다보면 Deployment Controller가 ReplicaSet을, ReplicaSet Controller가 Pod를 만드는 식으로 여러 컨트롤러가 단계적으로 협력합니다. 이 루프가 만들어내는 상태 변화를 관측하는 방법은 Prometheus가 쿠버네티스 메트릭의 표준이 된 이유에서 이어집니다.

핵심 정리 — 이것만 기억하세요

자료 전체는 네 문장으로 요약됩니다.

  1. 컨테이너는 이식성과 일관성을 준다 — 커널을 공유해 가볍고, 어디서나 동일하게 실행된다.
  2. 불변 인프라는 고치지 말고 교체하는 것이다 — 변경하지 않으므로 Configuration Drift가 생기지 않는다.
  3. 쿠버네티스는 오케스트레이션 표준이자 자가 조정 시스템이다 — 선언한 상태를 스스로 유지한다.
  4. 오픈 거버넌스와 표준 인터페이스가 종속을 없앤다 — 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).

쿠버네티스는 어떤 팀에게 필요한가요?

하루에 여러 번 배포하거나, 이벤트성 부하에 대응해야 하거나, 잦은 설정 변경 이력을 관리해야 하거나, 복잡한 작업 절차를 단순화하려 하거나, 명확한 배포 정책과 롤백이 필요한 팀입니다. 변화가 빠르고 자동화가 절실한 팀일수록 효과가 큽니다.

자료 다운로드

지금까지 살펴본 내용 전체가 담긴 61쪽 PDF입니다. 발표자료 다운로드는 아래 버튼에서 바로 하실 수 있습니다.

Share This Story, Choose Your Platform!

Go to Top