이제 나도 클라우드 네이티브 전문가: 쿠버네티스 구축부터 운영 완전 정복

컨테이너와 쿠버네티스의 등장은 단순히 기존의 애플리케이션 배포 및 관리 방식을 개선하는 것을 넘어, 클라우드 컴퓨팅이라는 거대한 기술 패러다임 자체의 진화 방향에 매우 깊은 영향을 미치고 있습니다. 이 두 기술의 강력한 시너지는 과거에는 상상하기 어려웠던 새로운 애플리케이션 아키텍처와 운영 모델을 가능하게 하며, 우리가 기술과 상호작용하는 방식 자체를 변화시키고 있습니다. 앞으로 펼쳐질 클라우드 컴퓨팅의 미래는 쿠버네티스와 컨테이너라는 굳건한 기반 위에서 더욱 다채롭고 혁신적인 모습으로 그려질 것입니다.

최근 몇 년간 클라우드 컴퓨팅 분야에서 가장 뜨거운 화두 중 하나는 단연 ‘서버리스(Serverless) 컴퓨팅’ 또는 ‘함수 기반 서비스(Function-as-a-Service, FaaS)’일 것입니다. 서버리스 컴퓨팅은 이름 그대로, 개발자가 애플리케이션을 실행하기 위한 서버의 존재 자체를 거의 또는 전혀 신경 쓰지 않고, 오직 비즈니스 로직을 담은 짧은 코드 조각(일반적으로 ‘함수(function)’라고 불림) 작성에만 집중할 수 있도록 하는 혁신적인 클라우드 실행 모델입니다.

이 패러다임 하에서, 개발자가 작성한 함수 코드는 특정 이벤트(예: HTTP API 요청, 데이터베이스 변경, 파일 업로드, 메시지 큐에 메시지 도착 등)가 발생했을 때만 동적으로 실행되고, 실행이 완료되면 즉시 종료됩니다. 가장 중요한 특징 중 하나는 사용한 만큼만 비용을 지불(pay-per-use)한다는 점입니다. 즉, 함수가 실제로 실행된 시간과 사용한 컴퓨팅 자원(메모리 등)에 대해서만 과금되므로, 유휴 시간 동안에는 비용이 거의 발생하지 않아 매우 경제적일 수 있습니다. 또한, 인프라 프로비저닝, 운영체제 및 런타임 환경 관리, 보안 패치 적용, 그리고 트래픽 변화에 따른 자동 확장(auto-scaling) 등 모든 운영상의 부담은 전적으로 클라우드 제공업체가 알아서 처리해 줍니다. 이는 개발자들이 인프라 관리에 대한 고민 없이 오롯이 핵심 비즈니스 가치 창출에만 몰두할 수 있게 하여 개발 생산성을 극대화하고, 운영 효율성을 크게 높이는 매우 매력적인 모델입니다.

하지만, 이러한 서버리스 컴퓨팅의 눈부신 장점에도 불구하고, 초기에는 몇 가지 중요한 한계점과 우려가 존재했습니다. 가장 대표적인 것이 바로 특정 클라우드 제공업체(Cloud Service Provider, CSP)의 독점적인 서비스에 대한 종속성(vendor lock-in) 문제였습니다. AWS Lambda, Azure Functions, Google Cloud Functions와 같은 주요 퍼블릭 클라우드 제공업체들은 각자 고유한 방식으로 서버리스 플랫폼을 제공했으며, 이는 개발자들이 특정 CSP의 API와 서비스 생태계에 깊이 의존하게 만들었습니다. 한번 특정 CSP의 서버리스 플랫폼을 사용하여 애플리케이션을 구축하면, 다른 CSP의 플랫폼으로 이전하거나 온프레미스 환경에서 동일한 방식으로 실행하는 것이 매우 어렵거나 거의 불가능했습니다. 이는 기업의 기술 선택 유연성을 제한하고, 장기적으로 비용 협상력을 약화시키는 요인이 될 수 있었습니다.

바로 이러한 서버리스 컴퓨팅의 벤더 종속성 문제를 해결하고, 서버리스의 강력한 이점을 어떤 환경에서든 누릴 수 있도록 하는 데 있어 쿠버네티스가 핵심적인 역할을 하기 시작했습니다. 최근에는 쿠버네티스를 기반으로 하는 다양한 오픈소스 서버리스 프레임워크와 플랫폼들이 활발하게 등장하고 발전하면서, 이러한 이상이 현실로 다가오고 있습니다.

대표적인 예가 바로 Knative(케이네이티브)입니다. Knative는 구글을 중심으로 IBM, Pivotal(현 VMware), Red Hat 등 여러 기업이 협력하여 개발한 오픈소스 프로젝트로, 쿠버네티스 클러스터 위에 구축되어 컨테이너화된 애플리케이션을 서버리스 워크로드로 매우 손쉽게 배포하고 실행할 수 있는 표준화된 방법을 제공합니다. Knative는 크게 세 가지 주요 컴포넌트로 구성됩니다.

• Serving: HTTP 요청에 따라 컨테이너를 실행하고, 트래픽 기반 자동 확장(스케일 투 제로 포함), 버전 관리 및 점진적 롤아웃(예: 블루/그린 배포, 카나리 배포)과 같은 기능을 제공합니다.
• Eventing: 다양한 이벤트 소스(예: 메시지 큐, GitHub 웹훅, Cron 작업 등)로부터 이벤트를 수신하고, 이를 특정 Knative 서비스나 다른 대상으로 라우팅하여 이벤트 기반 아키텍처를 구축할 수 있도록 지원합니다.
• Building (현재는 Tekton으로 분리): 소스 코드로부터 컨테이너 이미지를 빌드하는 과정을 자동화하는 기능을 제공했으나, 현재는 CI/CD 파이프라인 구축을 위한 별도의 CNCF 프로젝트인 Tekton으로 그 역할이 많이 이관되었습니다.

Knative를 사용하면, 개발자는 복잡한 쿠버네티스 오브젝트(예: 디플로이먼트, 서비스, 인그레스, HPA 등)를 직접 다루지 않고도, 간단한 Knative 서비스 명세를 통해 서버리스 애플리케이션을 정의하고 배포할 수 있습니다. 가장 주목할 만한 기능 중 하나는 ‘스케일 투 제로(Scale-to-Zero)’입니다. Knative Serving은 특정 서비스에 대한 요청이 일정 시간 동안 전혀 없을 경우, 해당 서비스를 실행하는 파드의 수를 0으로 자동으로 줄여 시스템 자원을 전혀 사용하지 않도록 합니다. 그러다가 첫 번째 요청이 들어오면, 매우 빠르게(cold start 시간은 애플리케이션 특성에 따라 다를 수 있음) 새로운 파드를 가동시켜 요청에 응답하고, 이후 트래픽 양에 따라 자동으로 파드 수를 늘리거나 줄이는 고도의 탄력적이고 비용 효율적인 운영이 가능해집니다.

Knative 외에도, OpenFaaS(오픈파스), Kubeless(큐브리스), Fission(피션) 등 다양한 오픈소스 서버리스 프레임워크들이 쿠버네티스를 기반으로 자체적인 서버리스 환경을 구축하고 운영할 수 있는 기능을 제공하고 있습니다. 이러한 도구들은 각기 다른 특징과 장점을 가지고 있지만, 공통적으로 쿠버네티스라는 표준화된 컨테이너 오케스트레이션 플랫폼 위에서 서버리스의 핵심 가치를 구현하려 한다는 점에서 중요한 의미를 지닙니다.

이처럼, 쿠버네티스는 서버리스라는 혁신적인 컴퓨팅 패러다임을 특정 클라우드 제공업체의 폐쇄적인 울타리를 넘어, 기업의 자체 데이터센터(온프레미스)를 포함한 어떤 환경에서든 일관된 방식으로 구현하고 활용할 수 있는 개방적이고 유연한 기반을 제공함으로써, 서버리스 기술의 대중화와 발전을 이끌고 있습니다. 이는 기업에게 진정한 의미의 기술 선택의 자유를 부여하고, 벤더 종속성에 대한 우려 없이 서버리스의 강력한 이점을 누릴 수 있는 새로운 가능성을 열어주고 있습니다. 쿠버네티스와 서버리스의 이러한 아름다운 결합은 앞으로 더욱 다양한 형태로 발전하며 클라우드 네이티브 컴퓨팅의 미래를 만들어갈 것입니다.

최근 몇 년 사이, IT 인프라와 애플리케이션 배포 전략에서 가장 주목받는 변화 중 하나는 바로 컴퓨팅의 중심이 전통적인 중앙 집중형 클라우드 데이터센터에서 점차 데이터가 실제로 생성되고 소비되는 물리적인 ‘엣지(edge)’로 이동하고 있다는 점입니다.

다음과 같은 다양한 현대 기술 및 서비스의 발전을 견인하는 핵심 동력으로 부상하고 있습니다.

• 사물인터넷(Internet of Things, IoT): 공장의 센서, 스마트 홈 기기, 웨어러블 디바이스 등 수십억 개의 연결된 장치들이 실시간으로 방대한 양의 데이터를 생성하고 있으며, 이 데이터를 엣지에서 즉시 처리해야 할 필요성이 커지고 있습니다.
• 자율주행 자동차(Autonomous Vehicles): 차량 주변 환경을 인지하고, 장애물을 피하며, 경로를 결정하는 등 수많은 센서 데이터를 실시간으로 분석하고 즉각적인 판단을 내려야 하므로, 매우 낮은 지연 시간(ultra-low latency) 처리가 가능한 엣지 컴퓨팅이 필수적입니다.
• 스마트 팩토리(Smart Factories): 생산 라인의 로봇 제어, 품질 검사, 예지 보전 등을 위해 공장 내부에 설치된 센서와 기계로부터 발생하는 데이터를 현장에서 바로 분석하고 대응해야 합니다.
• 증강현실(Augmented Reality, AR) / 가상현실(Virtual Reality, VR): 사용자에게 몰입감 있는 경험을 제공하기 위해서는 사용자의 움직임이나 주변 환경 변화에 대한 매우 빠른 응답 속도가 필요하며, 이는 엣지에서의 컴퓨팅 처리를 통해 효과적으로 달성될 수 있습니다.
• 콘텐츠 전송 네트워크(Content Delivery Network, CDN)의 진화: 단순한 정적 콘텐츠 캐싱을 넘어, 사용자에게 더 가까운 엣지 로케이션에서 동적인 콘텐츠 처리나 개인화된 서비스 로직을 실행하려는 요구가 늘고 있습니다.

이처럼 다양한 분야에서 엣지 컴퓨팅이 각광받는 이유는, 모든 데이터를 중앙 집중형 클라우드 데이터센터로 전송하여 처리하는 기존 방식이 다음과 같은 본질적인 한계를 가지고 있기 때문입니다.

• 네트워크 지연 시간(Latency): 데이터가 엣지에서 중앙 클라우드까지 왕복하는 데 걸리는 시간은 실시간 반응이 중요한 애플리케이션(예: 자율주행, 로봇 제어, AR/VR)에는 너무 길 수 있습니다.
• 네트워크 대역폭 비용(Bandwidth Costs): 방대한 양의 데이터를 지속적으로 중앙 클라우드로 전송하는 것은 상당한 네트워크 대역폭을 소모하며, 이는 곧 높은 비용으로 이어질 수 있습니다.
• 데이터 프라이버시 및 보안(Data Privacy and Security): 민감한 개인 정보나 기업의 핵심 데이터를 외부 네트워크를 통해 중앙 클라우드로 전송하는 것은 보안상의 위험을 수반하거나, 특정 지역의 데이터 주권 규제를 위반할 수 있습니다.
• 연결 안정성(Connectivity Reliability): 엣지 환경은 네트워크 연결이 불안정하거나 간헐적으로 끊어질 수 있는 경우가 많습니다. 중앙 클라우드에 전적으로 의존하는 애플리케이션은 이러한 상황에서 서비스 제공에 차질을 빚을 수 있습니다.

하지만, 전 세계에 흩어져 있는 수많은, 그리고 종종 매우 다양한 종류의 엣지 디바이스(예: 소형 센서, 산업용 PC, 네트워크 게이트웨이, 소형 서버 랙 등) 위에 분산되어 실행되는 애플리케이션들을 어떻게 하면 효율적으로 배포하고, 중앙에서 일관되게 관리하며, 필요에 따라 신속하게 업데이트할 수 있을까요? 이는 엣지 컴퓨팅 시대를 열어가는 데 있어 매우 중요한 기술적 과제입니다. 바로 여기서 쿠버네티스의 역할이 다시 한번 중요하게 부각됩니다. 쿠버네티스가 제공하는 표준화된 애플리케이션 배포, 자동화된 관리, 그리고 강력한 생태계는 엣지 환경에서도 그 가치를 발휘할 수 있기 때문입니다.

물론, 전통적인 데이터센터 환경을 위해 설계된 표준 쿠버네티스는 상대적으로 많은 컴퓨팅 자원(CPU, 메모리 등)을 필요로 하고, 설치 및 구성 과정도 다소 복잡할 수 있습니다. 이는 리소스가 매우 제한적이고, 운영 인력이 부족하며, 네트워크 환경도 열악할 수 있는 엣지 환경의 특성에는 그대로 적용하기 어려운 측면이 있었습니다. 마치 대형 트럭이 좁은 골목길을 통과하기 어려운 것과 같습니다.

이에 대응하여, 최근 몇 년 사이에는 엣지 컴퓨팅 환경의 고유한 제약 조건과 요구사항을 고려하여 매우 가볍고(lightweight), 설치가 간편하며(easy to install), 자원 효율적으로(resource-efficient) 작동하도록 특별히 최적화된 쿠버네티스 배포판(distribution) 또는 관련 플랫폼들이 활발하게 등장하고 있습니다. 이러한 ‘경량 쿠버네티스(Lightweight Kubernetes)’ 솔루션들은 쿠버네티스의 핵심적인 기능과 API 호환성은 유지하면서도, 엣지 환경에 필요한 특수한 기능들을 추가적으로 제공합니다. 대표적인 예가 바로 K3s(케이쓰리에스)와 KubeEdge(큐브엣지)입니다.

K3s는 CNCF(Cloud Native Computing Foundation)로부터 공식적으로 인증받은 경량 쿠버네티스 배포판으로, Rancher Labs(현재 SUSE의 일부)에 의해 개발되었습니다. 이름의 ‘3’은 쿠버네티스(Kubernetes, k8s)보다 “5만큼 작다”는 의미를 유머러스하게 표현한 것이라고 합니다. K3s의 주요 특징은 다음과 같습니다.
단일 바이너리 실행 파일: 모든 필수 컴포넌트(API 서버, 스케줄러, 컨트롤러 매니저, Kubelet, 컨테이너 런타임 등)가 수십 MB 크기의 단일 바이너리 파일 안에 포함되어 있어, curl 명령 한 줄로 매우 빠르고 간단하게 설치할 수 있습니다.
매우 낮은 메모리 사용량: 최소 512MB의 RAM만으로도 실행이 가능할 정도로 매우 가볍게 설계되어, 라즈베리 파이(Raspberry Pi)와 같은 소형 임베디드 시스템이나 리소스가 제한된 엣지 디바이스에도 적합합니다.
SQLite 기본 지원: 전통적인 쿠버네티스가 상태 저장소로 사용하는 etcd 대신, 기본적으로 내장된 경량 데이터베이스인 SQLite를 사용하여 단일 노드 클러스터를 쉽게 구성할 수 있습니다. (물론, 외부 etcd나 다른 데이터베이스와 연동하는 것도 가능합니다.)
CNCF 인증 및 API 호환성: 가볍지만 쿠버네티스의 핵심 API와 완벽하게 호환되므로, 표준 쿠버네티스용으로 개발된 애플리케이션과 도구들을 거의 변경 없이 K3s 환경에서도 사용할 수 있습니다.
이러한 특징 덕분에 K3s는 개발 및 테스트 환경, CI/CD 파이프라인, 그리고 특히 리소스가 제한적인 IoT 및 엣지 컴퓨팅 환경에서 쿠버네티스를 도입하는 데 매우 매력적인 선택지가 되고 있습니다.

KubeEdge는 CNCF의 인큐베이팅 프로젝트로, 클라우드 네이티브 기술을 엣지 환경으로 확장하는 것을 목표로 하는 오픈소스 플랫폼입니다. KubeEdge는 클라우드 측의 중앙 관리(마스터 노드 역할)와 엣지 측의 자율 실행(워커 노드 역할)을 분리하고, 이 둘 사이의 통신을 최적화하는 아키텍처를 가지고 있습니다. 주요 특징은 다음과 같습니다.

• 클라우드-엣지 협업 아키텍처: 클라우드에는 표준 쿠버네티스 컨트롤 플레인과 KubeEdge의 ‘클라우드 코어(CloudCore)’ 컴포넌트가 위치하고, 각 엣지 노드에는 ‘엣지 코어(EdgeCore)’라는 경량 에이전트가 실행됩니다. 이를 통해 중앙에서 엣지 애플리케이션을 배포하고 관리할 수 있습니다.
• 엣지 자율성(Edge Autonomy): 엣지 노드가 클라우드와의 네트워크 연결이 일시적으로 끊어지거나 불안정한 상황에서도, 로컬에 캐시된 메타데이터를 기반으로 기존에 실행 중이던 애플리케이션을 계속 운영하고, 로컬에서 발생하는 이벤트를 처리하는 등 자율적으로 작동할 수 있도록 지원합니다.
• 경량 엣지 에이전트: 엣지 노드에서 실행되는 EdgeCore는 매우 적은 리소스를 소모하도록 설계되었습니다.
• 다양한 엣지 프로토콜 지원: MQTT, Bluetooth, Zigbee 등 다양한 IoT 디바이스 프로토콜을 지원하여, 엣지 디바이스로부터 데이터를 수집하고 제어하는 것을 용이하게 합니다.
• 엣지 애플리케이션 관리: 컨테이너화된 애플리케이션뿐만 아니라, 엣지 환경에서 실행되는 기존의 비컨테이너화된 애플리케이션(예: 장치 드라이버)도 관리할 수 있는 기능을 제공합니다.KubeEdge는 특히 산업 IoT, 스마트 시티, 커넥티드 카 등 대규모 분산 엣지 환경에서 애플리케이션과 디바이스를 효과적으로 관리하고, 클라우드와 엣지 간의 원활한 데이터 흐름을 구축하는 데 중점을 두고 있습니다.

이러한 K3s, KubeEdge와 같은 경량 쿠버네티스 솔루션들은, 컨테이너 기술과 쿠버네티스가 제공하는 표준화된 애플리케이션 패키징, 선언적 배포 및 관리, 자동화된 운영의 강력한 이점들을 전통적인 데이터센터의 경계를 넘어 광활한 엣지 환경까지 확장하는 데 결정적인 역할을 하고 있습니다. 이를 통해 기업들은 전 세계에 흩어져 있는 수천, 수만 개의 다양한 엣지 디바이스 위에서 실행되는 애플리케이션들을 중앙에서 일관되고 효율적인 방식으로 배포, 업데이트, 모니터링하고 관리할 수 있는 새로운 길을 열어가고 있습니다. 이는 곧 엣지 컴퓨팅 시대의 본격적인 개화를 앞당기고, 이전에는 상상하기 어려웠던 혁신적인 엣지 기반 서비스들이 등장하는 중요한 기술적 기반이 될 것입니다

과거 전통적인 IT 환경에서 애플리케이션을 개발하고 배포하는 과정은 종종 개발자와 인프라 운영팀 간의 길고 복잡한 줄다리기와 같았습니다. 개발자는 자신이 만든 애플리케이션이 특정 버전의 운영체제, 특정 라이브러리, 그리고 특정 하드웨어 구성 위에서 최적으로 작동하도록 심혈을 기울여 개발했지만, 실제 운영 환경은 개발 환경과 미묘하게 다르거나, 인프라팀의 정책이나 가용 자원에 따라 원하는 대로 구성되지 못하는 경우가 비일비재했습니다.

개발자들은 애플리케이션을 배포하기 위해 하부 인프라스트럭처(서버의 종류와 사양, 네트워크 구성, 스토리지 연결 방식, 로드 밸런서 설정 등)의 세부적인 구성과 작동 방식에 대해 상당한 수준의 지식을 가지고 있어야 했으며, 인프라팀과 끊임없이 소통하고 긴밀하게 협의하며 수많은 수동적인 설정 및 배포 작업을 수행해야 했습니다. “어떤 서버에 몇 개의 인스턴스를 배포해야 할까요?”, “이 애플리케이션은 특정 버전의 자바 런타임이 필요한데, 해당 서버에 설치되어 있나요?”, “방화벽에서 특정 포트를 열어주실 수 있나요?”, “로드 밸런서 설정은 어떻게 해야 트래픽이 제대로 분산될까요?” 와 같은 질문과 요청이 끝없이 오고 갔습니다.

이러한 인프라 중심적인 접근 방식은 다음과 같은 여러 가지 문제점을 야기했습니다.

• 개발 속도 저해: 개발자가 애플리케이션 로직 개발 외에 인프라 관련 문제 해결에 많은 시간을 할애해야 했고, 배포 과정 자체도 여러 단계와 승인 절차를 거치면서 지연되는 경우가 많았습니다.
• 혁신 장애물: 새로운 기술이나 아키텍처를 도입하려고 해도 기존 인프라와의 호환성 문제나 운영팀의 관리 부담 등으로 인해 쉽게 시도하기 어려웠습니다.
• 개발자와 운영팀 간의 마찰: 서로 다른 목표와 우선순위를 가진 두 팀 간에 오해와 갈등이 발생하기 쉬웠고, 이는 전체적인 생산성 저하로 이어졌습니다.
• 낮은 자원 활용률: 각 애플리케이션마다 특정 서버 자원을 고정적으로 할당하는 경우가 많아, 실제 사용량과 관계없이 유휴 자원이 발생하는 비효율이 존재했습니다.

하지만 컨테이너 기술과 이를 효과적으로 오케스트레이션하는 쿠버네티스의 등장은 이러한 전통적인 인프라 중심의 패러다임을 근본적으로 바꾸고, ‘애플리케이션 중심의 인프라 관리’라는 새로운 시대로의 전환을 강력하게 이끌고 있습니다. 쿠버네티스는 마치 마법사처럼, 그 밑에 깔린 복잡다단한 물리적 또는 가상 인프라의 세부 사항들을 효과적으로 추상화하여 개발자로부터 숨겨줍니다. 개발자는 더 이상 자신이 만든 애플리케이션이 어떤 종류의 서버에서, 어떤 운영체제 위에서, 어떤 네트워크 구성을 가지고 실행될 것인지에 대해 깊이 고민할 필요가 없어졌습니다.

대신, 쿠버네티스는 개발자에게 애플리케이션 실행에 필요한 자원(예: CPU 코어 수, 메모리 할당량, 필요한 디스크 공간, 개방할 네트워크 포트 등)과 애플리케이션의 ‘원하는 상태'(예: 몇 개의 복제본으로 실행할 것인지, 어떤 업데이트 전략을 사용할 것인지, 외부 서비스와 어떻게 연결될 것인지 등)를 YAML과 같은 표준화된 형식의 선언적 명세 파일을 통해 기술할 수 있는 일관되고 강력한 인터페이스를 제공합니다. 개발자는 이 명세 파일에 자신의 애플리케이션이 어떻게 실행되기를 원하는지만 정의하면, 쿠버네티스가 나머지 모든 복잡한 작업, 즉 적절한 서버에 컨테이너를 배치하고(스케줄링), 필요한 네트워크를 설정하며, 스토리지를 연결하고, 로드 밸런싱을 구성하며, 장애 발생 시 자동으로 복구하는 등의 모든 인프라 관련 작업을 알아서 처리해 줍니다.

이제 개발자들은 더 이상 다음과 같은 낮은 수준의 인프라 관련 고민에 귀중한 시간과 에너지를 낭비할 필요 없이, 오롯이 자신들의 핵심 역량인 애플리케이션의 비즈니스 로직을 설계하고, 창의적인 기능을 구현하며, 사용자에게 더 나은 가치를 제공하는 데 집중할 수 있게 되었습니다.

결론적으로, 컨테이너와 쿠버네티스의 강력한 조합은 단순히 현재의 IT 운영 문제를 해결하는 것을 넘어, 서버리스, 엣지 컴퓨팅과 같은 새로운 컴퓨팅 패러다임을 현실로 만들고, 개발자들이 인프라의 복잡성에서 벗어나 애플리케이션 가치 창출에 더욱 집중할 수 있도록 하는 등 클라우드 컴퓨팅 기술의 미래를 근본적으로 변화시키고 이끌어가는 핵심 동력이 되고 있습니다. 앞으로 쿠버네티스 생태계는 더욱 확장되고 발전하면서, 우리가 상상하지 못했던 더 많은 혁신적인 기술과 서비스들이 등장하는 기반이 될 것이라 기대해도 좋을 것입니다. 다음 절에서는 이러한 쿠버네티스가 자랑하는 강력한 자동화 기능이 어떤 내부적인 원리에 의해 가능한 것인지, 그 지능의 핵심을 더 깊이 파헤쳐 보도록 하겠습니다.