Quartz 4

1. 쿠버네티스의 유래와 핵심 철학

11 min read

1. 쿠버네티스의 유래와 핵심 철학

쿠버네티스를 ‘컨테이너를 관리하는 도구’라고만 알고 있다면, 수많은 개념 앞에서 길을 잃기 쉽습니다. 쿠버네티스를 제대로 이해하려면, 이 도구가 어떤 고민 끝에 탄생했고, 어떤 철학을 기반으로 움직이는지 먼저 알아야 합니다.

프롤로그: 쿠버네티스는 구글의 비밀 병기, ‘보그(Borg)‘로부터 왔다

쿠버네티스는 2014년에 갑자기 등장한 기술이 아닙니다. 그 뿌리는 10년 이상 구글 내부에서 대규모 컨테이너를 운영해 온 ‘보그(Borg)‘라는 시스템에 있습니다.

보그의 탄생과 진화

  • 과거의 구글: 구글은 검색, Gmail, 지도 등 수많은 서비스를 운영해야 했습니다. 이 서비스들을 수만 대의 서버에 효율적으로 배포하고 관리하는 것은 거대한 도전이었습니다.

  • 보그의 해법: 구글은 이 문제를 해결하기 위해 보그를 만들었습니다. 보그는 거대한 서버 클러스터를 하나의 거대한 컴퓨터처럼 보이게 만들고, 개발자들이 서버 걱정 없이 자신의 애플리케이션(컨테이너)을 그 위에 던져놓기만 하면 알아서 실행하고 관리해주는 시스템이었습니다. 구글은 매주 수십억 개의 컨테이너를 시작하며 이 시스템을 검증했습니다.

쿠버네티스의 등장

  • 보그에서 쿠버네티스로: 구글은 보그를 운영하며 얻은 10년 이상의 경험과 노하우를 바탕으로, 보그의 핵심 개념과 철학을 새롭게 재설계한 시스템을 오픈소스로 공개했습니다. 이것이 바로 ‘쿠버네티스(Kubernetes)‘입니다.

  • 이름의 의미: 쿠버네티스(Kubernetes)는 그리스어로 ‘조타수’ 또는 ‘항해사’를 뜻하며, 컨테이너라는 화물을 싣고 안전하게 항해하는 배의 조타수 역할을 한다는 의미입니다. 흔히 ‘K8s’로 줄여 쓰는데, K와 s 사이에 8개의 문자(ubernete)가 있기 때문입니다. 로고의 선박 조타 바퀴도 이 의미를 담고 있습니다.

보그와 쿠버네티스의 차이

쿠버네티스는 보그의 후계자이지만 완전히 같지는 않습니다:

  • 단순화: 보그의 복잡성을 줄이고, 더 이해하기 쉽고 사용하기 편한 구조로 재설계했습니다.
  • 개방성: 구글 내부가 아닌 외부 환경에서도 사용할 수 있도록 클라우드 중립적으로 만들어졌습니다.
  • 확장성: 플러그인과 커스텀 리소스를 통해 누구나 기능을 확장할 수 있는 열린 생태계를 지향합니다.

핵심 포인트: 쿠버네티스는 이론만으로 만들어진 학술적인 도구가 아닙니다. 세계 최대 규모의 트래픽을 다루는 구글의 실전 경험과 운영 노하우가 녹아있는, 태생부터 ‘실전용’인 시스템이라는 점이 중요합니다. 쿠버네티스의 다소 복잡해 보이는 설계는 바로 이 대규모 운영 환경에서의 안정성과 자동화를 위해 탄생한 것입니다.

쿠버네티스의 핵심 철학: “어떻게”가 아닌 “무엇을”

쿠버네티스의 동작 방식을 관통하는 가장 중요한 철학은 **‘선언적 관리(Declarative Management)‘**입니다.

명령형 vs 선언적

  • 명령형 관리 (Imperative): “서버 A에 접속해서, 앱 버전 1.1을 내리고, 버전 1.2를 실행해. 그리고 서버 B에도 똑같이 해.” 처럼, 어떻게(How) 할지 하나하나 명령하는 방식입니다.

  • 선언적 관리 (Declarative): “나는 앱 버전 1.2가 3개 실행되는 상태를 원해.” 와 같이, 무엇을(What) 원하는지 최종 목표 상태를 선언하는 방식입니다.

마치 택시를 탈 때, 기사님에게 “좌회전, 직진, 우회전…”이라고 지시하는 대신 “서울역으로 가주세요”라고 목적지만 말하는 것과 같습니다.

선언적 관리의 진짜 힘: 멱등성

선언적 관리의 진짜 이점은 **멱등성(Idempotency)**에 있습니다:

  • 같은 선언을 여러 번 적용해도 결과는 항상 같습니다.
  • 서버가 죽어서 재시작하든, 네트워크가 끊겼다 다시 연결되든, 쿠버네티스는 선언된 상태를 향해 스스로 수렴합니다.
  • 배포 스크립트를 실행할 때마다 “이미 실행 중인가? 아닌가?”를 확인할 필요가 없습니다. 그냥 원하는 상태를 선언하면 됩니다.

이는 마치 온도 조절기에 “23도”를 설정해두면, 현재 온도가 몇 도든 상관없이 자동으로 23도를 유지하는 것과 같습니다.

컨트롤 루프: 쿠버네티스의 심장

쿠버네티스는 우리가 YAML 파일 등으로 ‘원하는 상태’를 선언하면, ‘컨트롤 루프(Control Loop)’ 라는 메커니즘을 통해 현재 상태를 끊임없이 감시하고, 원하는 상태와 다를 경우 알아서 조치를 취합니다.

컨트롤 루프의 동작 원리

  1. 관찰(Observe): 현재 상태는 어떤가? (예: 앱 v1.2가 2개 실행 중)
  2. 비교(Compare): 원하는 상태와 같은가? (예: 목표는 3개인데, 1개가 부족하네)
  3. 실행(Act): 차이를 없애기 위한 조치를 취한다. (예: 앱 v1.2 컨테이너를 하나 더 실행!)
  4. (1번으로 돌아가 무한 반복, 보통 몇 초마다)

실전 시나리오: 자동 복구

예를 들어, 서버 장애로 컨테이너 하나가 갑자기 죽으면?

[장애 발생 전]
- 현재 상태: Pod 3개 실행 중
- 원하는 상태: Pod 3개
- 결과: ✓ 일치 (아무 조치 없음)

[장애 발생!]
- 현재 상태: Pod 2개 실행 중 (1개 죽음)
- 원하는 상태: Pod 3개
- 비교: ✗ 1개 부족!
- 실행: 새 Pod 자동 생성
- 결과: 몇 초 내에 자동 복구 완료!

→ 사람이 개입하지 않아도, 새벽 3시에 장애가 나도, 쿠버네티스가 알아서 복구합니다!

다른 자동화 기능들도 같은 원리

이 ‘선언적’ 철학과 ‘컨트롤 루프’ 메커니즘이 바로 쿠버네티스의 다음 기능들의 근간입니다:

  • 자동 복구(Self-healing): 컨테이너가 죽으면 자동으로 재시작
  • 오토 스케일링(Auto-scaling): CPU 사용률이 높아지면 자동으로 Pod 개수 증가
  • 롤링 업데이트(Rolling Update): 무중단으로 새 버전 배포
  • 자동 배치(Auto-placement): 리소스 상황을 고려해 최적의 서버에 배치

우리는 그저 원하는 상태를 선언했을 뿐인데, 쿠버네티스가 밤낮으로 그 상태를 유지하기 위해 노력하는 것입니다.

핵심 포인트: 쿠버네티스와 소통할 때는 ‘어떻게’를 지시하려 하지 말고, ‘내가 원하는 최종 그림은 이것이다’ 라고 명확히 선언하는 방식으로 접근해야 합니다. 이것이 쿠버네티스를 쿠버네티스답게 사용하는 첫걸음입니다.

정리

쿠버네티스를 이해하는 핵심은 다음 세 가지입니다:

  1. 실전에서 검증된 시스템: 구글의 10년 이상 대규모 운영 경험이 녹아있는 실전용 도구
  2. 선언적 관리: “어떻게”가 아닌 “무엇을” 원하는지만 말하면 됨
  3. 컨트롤 루프: 끊임없이 현재 상태를 감시하고 원하는 상태로 수렴시키는 자동화 메커니즘

이 세 가지 철학을 마음에 새기고 나면, 앞으로 배울 Pod, Service, Deployment 같은 개념들이 왜 그렇게 설계되었는지, 왜 그렇게 동작하는지 자연스럽게 이해할 수 있습니다.

다음 아티클

작성일: 2025-10-30

그래프 뷰