[DevOps] 쿠버네티스가 왜 필요한데? Docker Compose로는 부족한 순간

지금까지 Docker로 컨테이너를 만들고, Compose로 여러 개를 묶고, CI/CD로 자동 배포까지 했다. 여기까지만 해도 웬만한 개인 프로젝트나 소규모 서비스는 충분히 굴러간다.

그런데 여기저기서 쿠버네티스(Kubernetes, 줄여서 K8s)라는 말이 계속 들린다. "이거 안 하면 뒤처지나?" 싶기도 하다. 오늘은 명령어 하나 안 배운다. 대신 쿠버네티스가 왜 생겼고, 언제 필요한지를 확실히 잡는다. 이게 잡혀야 다음 글부터 나오는 개념들이 겉돌지 않는다.

---

먼저: 쿠버네티스가 뭔데?

한 줄로 말하면, 컨테이너를 대신 관리해주는 시스템(컨테이너 오케스트레이션 도구)이다.

"오케스트레이션(orchestration)"이라는 말이 핵심이다. 오케스트라 지휘자를 떠올리면 된다. 연주자(컨테이너)가 수십, 수백 명일 때 지휘자 없이 각자 알아서 연주하면 엉망이 된다. 지휘자가 전체를 보고 조율해야 한다. 쿠버네티스가 바로 그 지휘자다. "컨테이너 수십 개를 사람 대신 알아서 관리해주는 것"이다.

근데 이 설명만으론 감이 안 온다. 그래서 Compose로 안 되는 순간들을 하나씩 보자.

---

Compose로는 부족한 순간들

1. 서버 한 대로는 감당이 안 될 때

Docker Compose는 기본적으로 서버 한 대 안에서 컨테이너들을 관리한다. 트래픽이 몰려서 서버 한 대로 부족해지면? 서버를 여러 대로 늘려야 한다. 그런데 Compose는 "이 컨테이너는 1번 서버에, 저건 2번 서버에" 하는 여러 서버에 걸친 관리를 못 한다.

쿠버네티스는 여러 서버(노드)를 하나의 자원 풀처럼 묶어서 관리한다. "컨테이너 10개 띄워"라고 하면, 어느 서버에 몇 개씩 배치할지 알아서 정한다.

2. 컨테이너가 죽었을 때 자동으로 살려야 할 때

새벽 3시에 컨테이너가 죽었다. Compose 환경이면 누군가 알아채고 다시 띄워야 한다. 자는 사람을 깨워서.

쿠버네티스는 컨테이너가 죽으면 자동으로 다시 띄운다(self-healing). "이 앱은 항상 3개가 떠 있어야 해"라고 선언해두면, 하나가 죽는 순간 알아서 새로 하나를 띄워 3개를 유지한다. 사람이 밤에 안 깨어나도 된다.

3. 트래픽에 따라 개수를 자동으로 조절할 때

낮에는 사용자가 많고 밤에는 적다. 낮엔 컨테이너 10개, 밤엔 2개면 충분하다. Compose로는 이걸 손으로 조절해야 한다.

쿠버네티스는 부하에 따라 컨테이너 개수를 자동으로 늘렸다 줄인다(auto-scaling). CPU 사용량이 올라가면 알아서 컨테이너를 더 띄우고, 한가해지면 줄인다.

4. 무중단 배포가 필요할 때

CI/CD 글 마지막에 "지금 방식은 컨테이너를 껐다 켜서 몇 초 다운타임이 있다"고 했던 거 기억하나? 쿠버네티스는 새 버전을 하나씩 띄우면서 옛 버전을 하나씩 내리는 롤링 업데이트를 기본으로 지원한다. 사용자는 서비스가 멈춘 걸 모른 채 배포가 끝난다. 문제가 생기면 이전 버전으로 되돌리는 것도 명령 하나다.

---

핵심 아이디어: "선언"하면 알아서 맞춰준다

쿠버네티스를 관통하는 철학이 하나 있다. 선언형(declarative)이다.

기존 방식은 "이거 해, 저거 해" 하고 명령하는 거였다. docker run 하고, 죽으면 다시 docker run 하고. 과정을 사람이 일일이 지시한다.

쿠버네티스는 다르다. "원하는 최종 상태"를 선언한다. "이 앱은 항상 3개가 떠 있어야 하고, 각각 메모리는 이만큼, 이 포트로 접근 가능해야 해." 이렇게 목표 상태만 적어두면, 쿠버네티스가 현재 상태를 계속 감시하면서 그 목표에 맞춰준다.

• 2개밖에 없네? → 하나 더 띄운다
• 4개가 됐네? → 하나 줄인다
• 하나가 죽었네? → 새로 띄운다

사람은 "어떻게"가 아니라 "무엇을" 원하는지만 말한다. 방법은 쿠버네티스가 알아서 찾는다. 이게 쿠버네티스가 강력한 이유의 핵심이다.

---

그럼 무조건 써야 하나? (아니다)

여기까지 들으면 대단해 보이지만, 솔직하게 말하면 대부분의 작은 프로젝트엔 과하다.

쿠버네티스는 강력한 만큼 복잡하다. 배울 것도 많고, 클러스터를 운영하는 것 자체가 일이다. 개인 프로젝트나 서버 한두 대로 충분한 서비스에 쿠버네티스를 얹는 건, 자전거 타면 될 거리에 비행기를 띄우는 격이다.

기준을 대충 잡으면 이렇다.

상황	추천
개인 프로젝트, 서버 1대	Docker + Compose로 충분
소규모 서비스, 트래픽 적음	Compose 또는 간단한 배포로 충분
서버 여러 대, 트래픽 많음	쿠버네티스 고려
무중단·자동복구·자동확장 필수	쿠버네티스

그러니 "남들이 쓰니까 나도" 말고, 위에서 본 문제들(여러 서버, 자동 복구, 자동 확장, 무중단)을 실제로 겪고 있는가로 판단하면 된다.

다만 개념을 알아두는 건 다른 얘기다. 실무에서 워낙 표준이 됐고, 이력서에도 자주 요구되니까, 당장 안 쓰더라도 "이게 뭐고 왜 쓰는지"는 알아두면 손해 볼 게 없다.

---

정리

• 쿠버네티스(K8s)는 컨테이너를 대신 관리해주는 오케스트레이션 도구다.
• Docker Compose로는 부족한 순간에 등장한다: 여러 서버 관리, 자동 복구, 자동 확장, 무중단 배포.
• 핵심 철학은 선언형이다. "원하는 상태"만 적어두면 알아서 그 상태를 유지한다.
• 하지만 작은 프로젝트엔 과하다. 실제로 그 복잡함이 필요한 상황인지 먼저 따져보자.

오늘은 "왜"에 집중했다. 이 "왜"가 잡혀 있어야 다음 글이 이해된다. 다음 글에서는 쿠버네티스의 가장 기본 단위인 Pod, 그리고 Deployment와 Service가 뭔지 개념을 잡아본다. "선언하면 알아서 맞춰준다"는 오늘의 이야기가 거기서 실제로 어떻게 동작하는지 보게 될 거다.