---
term: 'Kubernetes'
seoTitle: 'Kubernetes(K8s)란? 개념, 구조, 도입 기준'
headline: 'Kubernetes(K8s)란?'
slug: kubernetes
category: cloud-architecture
shortDefinition: 'Kubernetes는 컨테이너화된 애플리케이션의 배포, 확장, 운영을 여러 머신에 걸쳐 자동화하는 오픈소스 플랫폼입니다.'
relatedTerms:
  - containerization
  - infrastructure-as-a-service
  - microservices-vs-monolith
  - no-ops-development
  - ci-cd
contrastsWith:
  - no-ops-development
faq:
  - question: 'Kubernetes를 쉽게 설명하면 무엇입니까?'
    answer: '컨테이너를 위한 오케스트라 지휘자입니다. 이 앱을 복제본 세 개로, 이만큼의 메모리로 실행해야 한다고 선언하면 Kubernetes가 현실을 그 선언에 계속 맞춥니다. 컨테이너를 머신에 배치하고, 비정상 종료되면 재시작하고, 부하에 따라 확장하고, 정상인 복제본으로 트래픽을 라우팅합니다. 여러 머신의 집합을 프로그래밍 가능한 하나의 풀로 바꾸는 것입니다.'
  - question: 'K8s는 무엇의 약자입니까?'
    answer: '숫자 약어(numeronym)입니다. K 다음에 여덟 글자, 그다음 s가 오는 구조로, internationalization을 i18n으로 줄이는 것과 같은 방식입니다. 이름 자체는 그리스어로, kubernetes는 배를 조종하는 키잡이 또는 조타수를 뜻합니다. 이 생태계의 많은 도구가 항해와 관련된 이름을 갖고 로고가 배의 키인 이유이기도 합니다.'
  - question: 'Kubernetes와 Docker는 같은 것입니까?'
    answer: '아닙니다. 둘은 서로 다른 질문에 답합니다. Docker는 한 머신에서 개별 컨테이너를 빌드하고 실행하며, Kubernetes는 여러 머신에 걸쳐 많은 컨테이너를 오케스트레이션합니다. 둘은 상호 보완적이어서 Docker로 빌드한 이미지가 Kubernetes 클러스터에서 실행됩니다. 1.24 버전부터 Kubernetes는 Docker 자체를 런타임으로 쓰지 않고 표준 컨테이너 런타임이라면 무엇과도 통신하지만, 이미지가 OCI 오픈 표준을 따르므로 Docker로 빌드한 이미지는 이전과 똑같이 동작합니다.'
  - question: '클러스터, 노드, 파드란 무엇입니까?'
    answer: '클러스터는 시스템 전체로, 컨트롤 플레인과 워커 머신으로 구성됩니다. 노드는 그 안의 머신 하나이며 물리 머신일 수도, 가상 머신일 수도 있습니다. 파드는 배포 가능한 최소 단위로, 네트워크 ID와 스토리지를 공유하는 하나 이상의 긴밀하게 결합된 컨테이너입니다. 파드를 직접 실행하는 일은 거의 없습니다. Deployment를 선언하면 Kubernetes가 파드를 대신 관리합니다.'
  - question: 'Kubernetes 컨트롤 플레인이란 무엇입니까?'
    answer: '클러스터의 두뇌입니다. 모든 통신이 거쳐 가는 API 서버, 클러스터의 목표 상태와 실제 상태를 담는 키-값 저장소, 각 파드가 어느 노드에 배치될지 결정하는 스케줄러, 그리고 선언과 현실을 끊임없이 조정(reconcile)하는 컨트롤러로 구성됩니다. 워커 노드는 에이전트, 네트워크 프록시, 그리고 파드를 실제로 실행하는 컨테이너 런타임을 구동합니다.'
  - question: 'Kubernetes는 누가 언제 만들었습니까?'
    answer: '2014년 6월에 오픈소스로 공개되었으며, 세계 최대 기술 기업 중 한 곳이 10년 넘게 쌓은 내부 컨테이너 오케스트레이션 경험에서 태어났습니다. 2015년 7월에 1.0 버전에 도달했고, 같은 시점에 새로 설립된 Cloud Native Computing Foundation(CNCF)에 기부되었습니다. Go로 작성되었으며 이후 세계에서 가장 큰 오픈소스 프로젝트 중 하나가 되었습니다.'
  - question: 'Kubernetes가 과한 선택이 되는 때는 언제입니까?'
    answer: '세간의 평가보다 훨씬 자주 그렇습니다. 예측 가능한 트래픽으로 컨테이너 몇 개를 운영하는 소규모 팀은 클러스터에서 얻는 것이 거의 없는 반면, 가파른 학습 곡선, YAML 난립, 그리고 대규모 집합 문제를 위해 만들어진 운영 규율을 떠안게 됩니다. 한 호스트의 compose 파일, 관리형 컨테이너 플랫폼, PaaS, BaaS 같은 더 단순한 경로가 본격적인 규모 이전의 워크로드 대부분을 감당합니다.'
  - question: '관리형 Kubernetes란 무엇입니까?'
    answer: '업그레이드, 가용성, 상태 저장소 등 컨트롤 플레인을 대신 운영해 주는 클라우드 서비스로, 사용자는 워크로드와 노드 풀만 관리합니다. 가장 어려운 운영 계층을 제거하며, 실제 프로덕션 Kubernetes 대부분이 이 형태로 운영됩니다. 클러스터를 처음부터 끝까지 직접 운영하는 일은 여전히 전담 전문성을 갖춘 플랫폼 팀의 영역입니다. 컨트롤 플레인은 실수를 용납하지 않는 인프라입니다.'
codeLanguages: [javascript, dart, swift, kotlin]
externalAuthorities:
  - name: 'Kubernetes documentation — Overview'
    url: 'https://kubernetes.io/docs/concepts/overview/'
  - name: 'Kubernetes components (kubernetes.io)'
    url: 'https://kubernetes.io/docs/concepts/overview/components/'
  - name: 'Cloud Native Computing Foundation — Kubernetes'
    url: 'https://www.cncf.io/projects/kubernetes/'
  - name: 'Kubernetes (Wikipedia)'
    url: 'https://en.wikipedia.org/wiki/Kubernetes'
cta:
  title: '클러스터 없는 백엔드'
  text: 'Back4app은 대부분의 팀이 Kubernetes에서 실제로 원하는 것, 즉 배포되고 확장되며 자가 복구하는 백엔드 서비스를 클러스터 운영 없이 제공합니다. 관리형 데이터베이스, 인증, API, Cloud Code 함수가 그것입니다. 컨테이너가 꼭 필요하다면 Back4app Containers가 대신 실행합니다.'
  linkText: '무료로 시작하기'
  linkUrl: 'https://www.back4app.com/signup'
author: 'Back4app Engineering'
publishedDate: '2026-10-27'
translationKey: kubernetes
---

**Kubernetes는 컨테이너화된 애플리케이션의 배포, 확장, 운영을 여러 머신에 걸쳐 자동화하는 오픈소스 플랫폼입니다.** 핵심 아이디어는 선언적이라는 점입니다. *이 컨테이너의 복제본 세 개, 이만큼의 메모리, 이 포트로 접근 가능*이라는 목표 상태를 기술하면, 시스템은 요청받지 않아도 재시작하고, 재스케줄링하고, 확장하면서 현실을 그 상태에 맞추기 위해 끊임없이 동작합니다.

## 핵심 요약

| 질문 | 답변 |
| --- | --- |
| 무엇인가 | 여러 머신을 컨테이너를 위한 하나의 풀로 바꾸는 제어 시스템 |
| 핵심 아이디어 | 목표 상태를 선언하면 클러스터가 현실을 거기에 맞춰 영원히 조정 |
| vs. Docker | Docker는 컨테이너를 빌드하고 실행; Kubernetes는 컨테이너 집합을 오케스트레이션 |
| 이름 | 그리스어로 "키잡이"; K8s = K + 여덟 글자 + s |
| 솔직한 단서 | 대규모 집합의 힘에는 대규모 집합의 복잡성이 따르며, 많은 팀에는 둘 다 필요 없음 |

## 매니페스트: Kubernetes와 대화하는 방법

모든 것이 선언입니다. 아래는 최소한의 실제 Deployment로, 주석을 쉬운 말로 달았습니다.

```yaml
apiVersion: apps/v1
kind: Deployment              # "이것을 N개 실행 상태로 유지하라"
metadata:
  name: api
spec:
  replicas: 3                 # 목표 상태: 파드 세 개
  selector:
    matchLabels: { app: api }
  template:                   # 각 파드에 담기는 내용
    metadata:
      labels: { app: api }
    spec:
      containers:
        - name: api
          image: registry.example.com/api:1.4.2
          ports: [{ containerPort: 8080 }]
          resources:
            limits: { memory: "256Mi", cpu: "500m" }
# 적용한 뒤 파드 하나를 죽이면 Kubernetes가 되살립니다. 그것이 곧 이 제품입니다.
```

대비를 위해, 같은 결과(배포되고 확장되며 자가 복구하는 백엔드)를 서비스로 소비하는 모습입니다. 매니페스트, 클러스터, 새벽 3시의 조정 작업은 모두 다른 누군가의 YAML입니다.

**JavaScript:**

```javascript
// JavaScript / Node.js — Back4app JS SDK
// The workload the manifest would have described — already running
const status = await Parse.Cloud.run('healthCheck');
console.log(status); // scheduling, scaling, restarts: the platform's job
```

**Flutter:**

```dart
// Flutter / Dart — Back4app Flutter SDK
final function = ParseCloudFunction('healthCheck');
final response = await function.execute();
if (response.success) {
  print(response.result); // no pods, no manifests, no cluster to run
}
```

**Swift:**

```swift
// iOS / Swift — Back4app Swift SDK
ParseCloud.callFunction("healthCheck") { result in
  if case .success(let status) = result {
    print(status) // no pods, no manifests, no cluster to run
  }
}
```

**Kotlin:**

```kotlin
// Android / Kotlin — Back4app Android SDK
ParseCloud.callFunctionInBackground<String>("healthCheck", hashMapOf()) { status, e ->
  if (e == null) Log.d("Health", status) // no pods, no manifests, no cluster
}
```

## 클러스터 내부

```mermaid
flowchart TB
  accTitle: Kubernetes 클러스터 아키텍처
  accDescr: API 서버, 상태 저장소, 스케줄러, 컨트롤러로 구성된 컨트롤 플레인이 워커 노드를 관리하고, 각 노드는 에이전트, 네트워크 프록시, 파드를 실행하는 컨테이너 런타임을 구동합니다.
  subgraph CP["컨트롤 플레인(두뇌)"]
    a["API 서버"] --- b["상태 저장소"]
    a --- c["스케줄러"]
    a --- d["컨트롤러<br/>(목표 상태 vs. 실제 상태 조정)"]
  end
  subgraph N1["워커 노드"]
    e["에이전트 + 네트워크 프록시"] --> f["파드<br/>(컨테이너)"]
  end
  subgraph N2["워커 노드"]
    g["에이전트 + 네트워크 프록시"] --> h["파드"]
  end
  CP --> N1
  CP --> N2
```

용어를 한 줄씩 정리하면 이렇습니다. **클러스터**는 시스템 전체, **노드**는 머신 하나, **파드**는 배포 가능한 최소 단위(네트워크와 스토리지를 공유하는 하나 이상의 컨테이너)입니다. **Deployment**는 롤링 업데이트와 롤백을 지원하며 복제된 파드를 관리하고, **Service**는 수명이 짧은 파드에 안정적인 주소를 부여하며, **Ingress**는 외부 트래픽을 안으로 라우팅합니다. **ConfigMap과 Secret**은 설정을 담고, **네임스페이스**는 클러스터 하나를 팀별로 분할합니다. 한 단계 더 깊이 들어가려면 [공식 개요 문서](https://kubernetes.io/docs/concepts/overview/)가 정석입니다.

## Kubernetes vs. Docker

| 질문 | Docker | Kubernetes |
| --- | --- | --- |
| 역할 | 컨테이너 빌드, 패키징, 실행 | 여러 머신에 걸친 컨테이너 오케스트레이션 |
| 범위 | 머신 한 대 | 클러스터 |
| 단위 | 컨테이너 | 파드(컨테이너의 묶음) |
| 확장 | 수동 | 선언적이고 자동 |
| 관계 | 이미지를 빌드 | 이미지를 실행(표준 OCI 런타임 경유) |

이 해묵은 혼동에는 날짜가 붙어 있습니다. v1.24(2022년)부터 Kubernetes는 Docker 전용 런타임 심(shim)을 제거하고 표준 컨테이너 런타임과만 통신합니다. 이미지가 OCI 오픈 표준을 따르므로 아무것도 망가지지 않았지만, 역할은 선명해졌습니다. Docker는 조선소이고 Kubernetes는 항만 관리청입니다. 이름은 처음부터 이를 알고 있었습니다. *kubernetes*는 그리스어로 키잡이를 뜻하며, [2014년 6월에 오픈소스로 공개되어 2015년에 1.0에 도달하고 CNCF의 씨앗이 되었습니다](https://www.cncf.io/projects/kubernetes/). 10년에 걸친 대규모 컨테이너 운영 경험을 공공의 자산으로 증류한 결과입니다.

## 일반적인 사용 사례

- **마이크로서비스 집합.** 독립적으로 확장되고 배포되는 수십 개의 서비스. Kubernetes의 형태를 만든 바로 그 워크로드입니다.
- **플랫폼 팀.** 어떤 클라우드에서든 온프레미스에서든 동일하게 실행되는 하나의 기반 위에 내부 플랫폼을 구축합니다.
- **부하가 몰렸다 빠지는 대규모 워크로드.** 배치 작업, 데이터 파이프라인, ML 학습을 공유 용량에 빈 패킹(bin-packing)합니다.
- **멀티 클라우드와 이식성 전략.** [벤더 종속](/glossary/ko/cloud-vendor-lock-in/) 방어의 컴퓨팅 계층입니다. 다만 주변의 관리형 서비스는 여전히 종속을 낳는다는 단서가 붙습니다.
- **자가 복구하는 프로덕션 환경.** "새벽 3시에 머신이 죽었다"가 온콜 호출이 아니라 아무 일도 아니어야 하는 모든 곳입니다.

## Kubernetes를 도입해야 할까? 결정 매트릭스

| Kubernetes를 선택해야 할 때… | 건너뛰어야 할 때… |
| --- | --- |
| 많은 서비스, 많은 팀, 독립적인 확장 | 앱 하나, 팀 하나, 예측 가능한 부하 |
| 플랫폼 팀이 클러스터를 자신의 제품으로 소유 | 운영을 전담하는 사람이 없음 |
| 클라우드 간 이식성이 필수 요건 | 출시 속도가 유일한 요건 |
| 워크로드가 컨테이너화되어 있고 집합 형태 | 백엔드 요구가 표준 CRUD + 인증 |
| 더 단순한 오케스트레이션의 한계를 넘어섰음 | compose 파일이나 관리형 플랫폼으로 아직 충분 |

업계의 조용한 합의는 이렇습니다. Kubernetes를 운영하는 팀 대부분은 그것이 수지를 맞추는 규모에 미치지 못합니다. 대안의 사다리, 즉 compose 파일을 올린 호스트 한 대, 관리형 컨테이너 서비스, PaaS, BaaS가 진짜 대규모 집합 문제 이전의 모든 것을 감당하고, 관리형 Kubernetes가 나머지 대부분을 감당합니다.

## 한계와 트레이드오프

- **학습 곡선은 이 제품의 그림자입니다.** 파드, Service, Ingress, RBAC, 오퍼레이터, Helm. 능숙해지는 데 몇 달 단위가 걸리며, 클러스터는 기다려 주지 않습니다.
- **운영 표면.** 업그레이드, 인증서 교체, 네트워킹 플러그인, 상태 저장소의 건전성은 실수를 용납하지 않습니다. 관리형 컨트롤 플레인이 승리한 이유입니다.
- **YAML 난립.** 대규모의 선언적 설정은 자체 리뷰, 자체 버그, 자체 드리프트를 가진 또 하나의 코드베이스가 됩니다.
- **컨테이너를 오케스트레이션하지 아키텍처를 오케스트레이션하지는 않습니다.** 경계가 허술한 시스템은 Kubernetes 위에서도 같은 시스템이며 이제 분산되었을 뿐입니다. 클러스터는 좋든 나쁘든 설계를 증폭합니다.
- **Kubernetes는 PaaS가 아닙니다.** 설계상 CI/CD도, 기본 데이터베이스도, 앱 수준 서비스도 제공하지 않습니다. 그 위의 플랫폼은 직접 조립해야 하며, 바로 그 작업이 상위 추상화가 제품으로 되파는 것입니다.

## Back4app에서의 Kubernetes

Back4app은 관리형 데이터베이스, 자동 생성되는 REST 및 GraphQL API, 인증, 파일 스토리지, Cloud Code 서버리스 함수를 결합한 오픈소스 Backend as a Service(BaaS) 플랫폼입니다. Kubernetes와의 관계는 솔직한 분업입니다. 대부분의 애플리케이션 팀이 클러스터에서 실제로 원하는 것, 즉 배포되고 확장되며 자가 복구하는 백엔드 서비스가 바로 BaaS 계층이 작성할 매니페스트 없이 제공하는 것입니다. 그리고 진짜로 컨테이너인 워크로드는 [Back4app Containers](https://www.back4app.com/container-as-a-service)가 관리형 서비스로 실행합니다. 이미지를 푸시하면 오케스트레이션을 얻되, 항만을 소유할 필요는 없습니다.