[AI Crew]클라우드 네이티브 시대 왜 Kubernetes가 표준이 되었을까?/인공지능사관학교6기

2025. 9. 23. 15:04ㆍ대외활동/인공지능사관학교

728x90

SMALL

클라우드 네이티브 전환과 표준의 필요성

최근 IT 산업의 흐름은 ‘클라우드 네이티브’라는 키워드가 많이 등장하고 있습니다. 더 이상 기업은 자체 서버실에 물리 장비를 들여놓는 방식에 머물지 않고 퍼블릭 클라우드와 하이브리드 환경을 적극적으로 활용하며 서비스를 운영합니다.

하지만 다양한 클라우드 환경에서 서비스를 동일하게 안정적으로 운영하려면 ‘표준화된 관리 체계’가 필요합니다. 이때 등장한 것이 바로 Kubernetes(쿠버네티스)입니다. 단순한 컨테이너 실행 관리 도구를 넘어 오늘날 클라우드 네이티브 시대의 ‘사실상 표준(de facto standard)’이 되었습니다.

Kubernetes가 탄생한 이유와 성장 과정

쿠버네티스의 등장은 컨테이너 기술(Docker)과 깊은 연관이 있습니다. 도커는 애플리케이션을 어디서든 실행할 수 있는 경량화된 단위로 만들어 배포와 실행을 단순하게 했습니다. 그러나 컨테이너가 수십, 수백 개로 늘어나면 이를 운영·관리하는 데에 한계가 드러났습니다.

구글은 내부적으로 Borg라는 시스템을 통해 대규모 컨테이너 오케스트레이션을 이미 경험하고 있었고 그 노하우를 기반으로 2014년 오픈소스로 Kubernetes를 공개했습니다. 이후 CNCF(Cloud Native Computing Foundation)의 지원 아래 빠르게 성장하며 전 세계 개발자와 기업들이 선택하는 핵심 플랫폼으로 자리잡았습니다.

헷갈리는 🚢 Docker vs ☸️ Kubernetes 차이점 정리

1. 개념적 차이

Docker
- 애플리케이션을 컨테이너 단위로 패키징하고 실행하는 도구
- "개별 컨테이너"를 효율적으로 만들고 실행하는 데 초점
Kubernetes
- 여러 컨테이너를 묶어 오케스트레이션(자동화 관리) 하는 플랫폼
- "수많은 컨테이너"를 안정적으로 운영하기 위한 표준

2. 주요 기능 차이

구분	Docker	Kubernetes
역할	컨테이너 생성·실행·이미지 관리	컨테이너 배포·확장·복구·네트워킹 관리
대상 범위	개별 컨테이너 단위	클러스터(수백~수천 개 컨테이너) 단위
자동화	수동 실행이 중심 (docker run, docker stop)	선언적 관리(YAML 기반), 자동 스케일링, 자동 복구
네트워킹	기본 브리지 네트워크 제공	Service, Ingress 등 고도화된 네트워킹 지원
스토리지	단순 볼륨 공유	퍼시스턴트 볼륨(PV), 퍼시스턴트 볼륨 클레임(PVC)으로 데이터 영속성 보장
배포	도커 컴포즈(Docker Compose)로 다중 컨테이너 관리	Helm, ArgoCD 등 CI/CD와 결합해 엔터프라이즈급 배포 가능

3. 운영 관점에서의 차이

Docker: "내 노트북에서 잘 돌아가는가?"를 해결해주는 도구
Kubernetes: "수천 대 서버에서 똑같이 잘 운영되는가?"를 해결해주는 플랫폼

4. 비유로 설명

Docker = 배(Ship)를 만드는 기술 → 하나의 애플리케이션을 컨테이너로 안전하게 포장
Kubernetes = 항구(Port) 운영 시스템 → 수많은 배(컨테이너)를 정해진 항로에 따라 자동으로 관리

5. 함께 쓰일 때의 시너지

Docker로 만든 컨테이너 이미지를 Kubernetes가 실제 운영 환경에서 자동 관리
즉, Docker는 컨테이너화(Containerization), Kubernetes는 운영 자동화(Orchestration)

다음에는 강의에서 배웠던 도커에 대한 내용을 정리해 보겠습니다.

Kubernetes가 사실상 표준이 된 이유

쿠버네티스가 수많은 오케스트레이션 도구 중에서 표준이 될 수 있었던 이유는 명확합니다.

멀티·하이브리드 클라우드 지원: 특정 클라우드 벤더에 종속되지 않고 AWS, NCP, GCP, Azure 등 어디서든 동일하게 동작합니다.
자동화된 운영: Pod, Deployment, ReplicaSet 등을 통해 배포·확장·복구를 자동으로 처리합니다.
선언적 관리: 사용자는 ‘무엇을 원하는지’ YAML로 정의하면 쿠버네티스가 상태를 맞춰주는 방식으로 동작합니다. 이는 IaC(Infra as Code)의 흐름과 맞닿아 있습니다.
커뮤니티와 생태계의 힘: 전 세계 개발자들이 참여해 지속적으로 발전하고 있으며 Helm, Istio, ArgoCD 등 풍부한 에코시스템이 형성되었습니다.

AI 클라우드 및 인프라 반에서 배운 Kubernetes

저는 인공지능사관학교 AI 클라우드 및 인프라 반에서 쿠버네티스를 체계적으로 배웠습니다.

Pod, Service, Ingress 실습: 가장 기본 단위인 Pod에서 시작해 서비스를 외부에 노출하는 방법과 Ingress Controller를 통한 라우팅까지 경험했습니다.
Deployment와 스케일링: YAML 파일을 작성해 배포를 선언하고 kubectl scale 명령어로 손쉽게 확장해보며 자동화된 오케스트레이션의 장점을 실감했습니다.
Multi-node Cluster: 단일 노드 환경을 넘어서 실제로 Master와 Worker 노드를 구성해본 경험은 인상 깊었습니다. 장애가 발생했을 때 새로운 노드로 파드를 재배치하는 과정을 직접 눈으로 확인할 수 있었습니다.
Helm Chart: 반복적인 설정을 패키지화해 배포할 수 있다는 점이 실무에서 얼마나 효율적인지를 체감하게 해주었습니다.

이러한 경험은 단순히 명령어를 외우는 차원을 넘어 실제 서비스가 운영되는 과정을 몸소 이해할 수 있는 기회였습니다. 다만 교육 환경에서는 자원 규모가 제한적이기 때문에 쿠버네티스가 본래 강점을 발휘하는 대규모 분산 환경을 직접 경험하기에는 한계가 있었습니다. 앞으로 좋은 기회가 닿는다면 보다 규모 있는 시스템을 운영하며 쿠버네티스의 진정한 활용 가치를 깊이 이해해 보고 싶습니다.

클라우드 및 인프라 트랙을 선택한 이유

AI 자체의 모델 개발을 배우던 중에 인공지능 서비스를 배포하는 과정에서 안정성의 중요성을 느꼈습니다. 때문에 서비스를 안정적으로 운영하는 인프라에 대해서 배우고 싶다고 생각했고 인공지능사관학교에서 클라우드 및 인프라 반을 선택하게 됐습니다.

AI도 결국 서비스로 돌아간다: 모델을 아무리 잘 만들어도 운영 환경에 배포되지 않으면 서비스가 고객에게까지 닿기는 어렵습니다.
DevOps·MLOps 연결: 모델 운영까지 고려하면 Kubernetes 기반 인프라 지식이 필수입니다.
확장성과 안정성: 실제 대규모 트래픽을 처리하는 기업에서 필요한 역량이 바로 인프라 관리이기 때문에 취업을 준비하는 입장에서 가장 경쟁력 있는 분야라 생각했습니다.

이러한 이유로 AI 클라우드 및 인프라 반을 선택했고 쿠버네티스 학습을 통해 제 커리어의 방향성을 더욱 확고히 할 수 있었습니다.

Kubernetes의 가치

쿠버네티스는 이제 클라우드 인프라 직무에서 ‘기본기’로 자리잡았습니다.
많은 기업의 채용 공고에서 “Kubernetes 경험자 우대”라는 문구를 쉽게 찾아볼 수 있습니다. 이는 단순히 기술 트렌드가 아니라 실제 서비스 운영에서 Kubernetes가 빠질 수 없는 기술임을 보여줍니다.

저는 현재

NCP/NCA와 같은 클라우드 자격증 준비
Docker → Kubernetes 확장 프로젝트 수행
GitHub에 Kubernetes 관련 실습 저장소 정리

를 통해 제 역량을 증명할 수 있는 즉시 투입 가능한 클라우드 인프라 인재로 성장하기 위한 학습 과정을 수행하고 있습니다.

마무리: 클라우드 네이티브 전문가로 성장하기 위해

직접 쿠버네티스를 배우며 느낀 점은 단순합니다. “처음에는 어렵지만, 한 번 이해하면 모든 퍼즐이 맞춰진다.”
YAML 문법에 익숙해지기까지, 복잡한 구조를 이해하기까지 많은 시행착오가 있었지만 결국 이 과정이 저를 성장시켰습니다.

앞으로는

모니터링/로깅(Observability)
보안(Security)
서비스 메쉬(Service Mesh)

등의 영역을 더 보완하며 전문가로 나아가고 싶습니다.

혹시 이 글을 읽는 분들 중 클라우드 네이티브에 관심이 있다면 망설이지 말고 쿠버네티스를 직접 설치해보시길 추천드립니다. 어렵게만 보였던 클라우드 인프라가 쿠버네티스를 통해 훨씬 명확한 그림으로 다가왔으면 좋겠습니다.