쿠버네티스란 무엇인가, 왜 요즘 더 중요해졌을까

요즘 백엔드나 인프라 쪽 이야기를 하다 보면 쿠버네티스를 빼놓기 어렵다.
단순히 “컨테이너 오케스트레이션 도구”라고 설명하기에는, 실제로 사용하는 범위와 영향력이 꽤 넓어졌다.

이 글은 쿠버네티스를 처음 접하는 사람이나,
도커까지는 써봤지만 그 다음 단계에서 막힌 개발자를 대상으로 한다.
개념을 최대한 차분하게 정리하고, 왜 이 기술이 등장했고 어떤 문제를 해결하려는지부터 짚어본다.

쿠버네티스는 어떤 문제를 해결하려고 나왔을까

컨테이너 기술이 본격적으로 쓰이기 시작하면서, 애플리케이션 배포는 훨씬 가벼워졌다.
하지만 컨테이너 개수가 늘어나기 시작하면 다른 문제가 생긴다.

컨테이너 하나, 두 개를 수동으로 관리할 때는 큰 문제가 아니다.
하지만 수십, 수백 개의 컨테이너를 운영하는 순간부터는 자동화가 필수가 된다.

쿠버네티스는 바로 이 지점을 해결하기 위해 등장했다.

쿠버네티스는 “컨테이너를 어떻게 운영할 것인가”에 대한 표준적인 해답에 가깝다.

조금 단순화해서 말하면 다음과 같다.

도커가 “컨테이너를 만드는 도구”라면,
쿠버네티스는 “그 컨테이너들을 운영하는 관리자”에 가깝다.

실제로 써보면, 개발자가 일일이 서버 상태를 신경 쓰기보다는
“이 애플리케이션은 이런 상태로 유지되어야 한다”라고 선언하는 방식에 가깝다.

쿠버네티스를 이해하는 데 가장 중요한 개념 중 하나가 선언형 구조다.

예를 들어 다음과 같은 요구사항이 있다고 가정해보자.

전통적인 방식이라면,

하지만 쿠버네티스에서는 이렇게 생각한다.

“웹 서버 컨테이너는 항상 3개가 떠 있어야 한다”

이 상태를 선언해두면,
쿠버네티스가 알아서 현재 상태와 원하는 상태를 비교하고 맞춰준다.

실제로 운영해보면 이 방식 덕분에
“지금 왜 이 컨테이너가 떠 있지?” 같은 고민을 훨씬 덜 하게 된다.

쿠버네티스는 크게 두 영역으로 나뉜다.

개발자가 직접 다루는 부분은 대부분 Control Plane을 통해 이루어진다.
명령을 내리면, 내부적으로 스케줄링·상태 관리·복구 작업이 자동으로 진행된다.

이 구조 덕분에 쿠버네티스는 특정 클라우드나 서버 환경에 종속되지 않는다.

개념만 보면 다소 복잡해 보일 수 있지만,
어느 정도 익숙해지면 장점이 분명하다.

특히 운영 단계에서의 안정성은 직접 써봐야 체감되는 부분이다.

⚠️ 쿠버네티스가 만능은 아니다.

이런 경우에는 오히려 설정과 학습 비용이 부담이 될 수 있다.
실제로는 도커 컴포즈만으로도 충분한 경우도 많다.

쿠버네티스는 “필요해지는 순간”에 도입하는 것이 가장 좋다.

이 글에서는 쿠버네티스를 깊게 파기보다는,
왜 등장했고 어떤 문제를 풀기 위한 도구인지에 초점을 맞췄다.

다음 글에서는

쿠버네티스를 막연히 어렵게 느끼고 있었다면,
이 글이 전체 그림을 그리는 데 도움이 되었으면 한다.