<잇(IT)터뷰 전체 영상 보기>
잇(IT)터뷰 전체 내용은 ▼아래 영상▼에서 확인해 주세요!
◼ 게스트 : (노트LM 활용)
◼ 진행자 : 고우성 PD / 토크아이티 (wsko@talkit.tv, https://talkit.tv/)
영상 목차
◼ 아래 각 목차를 클릭하시면 해당 내용을 영상으로 바로 보실 수 있습니다.
✔ Dependency Hell과 Docker의 등장
✔ 컨테이너 오케스트레이션 전쟁
✔ Red Hat의 신의 한 수와 Docker의 실수
✔ CRI 표준과 Kubernetes의 승리
<잇(IT)터뷰 – 핵심 내용 파악하기>
‘잇(IT)터뷰 – 핵심 내용 파악하기’는 영상의 핵심 내용을 정리한 글입니다.
|
이번 잇(IT)터뷰는 Docker와 Kubernetes의 치열한 경쟁사를 다룹니다. 2013년 Docker가 “Dependency Hell”을 해결하며 컨테이너 혁명을 시작한 이후, 2014년 Google이 Kubernetes를 오픈소스화하면서 컨테이너 오케스트레이션 전쟁이 벌어졌습니다.
Red Hat의 전략적 선택, Docker의 결정적 실수, 그리고 커뮤니티의 기술적 대응을 통해 Kubernetes가 최종 승자가 된 과정을 살펴봅니다. 현재 Docker와 Kubernetes는 각자의 역할을 분담하며 공존하고 있습니다.
1. Dependency Hell과 Docker의 혁명
“내 컴퓨터에서는 되는데요?” – 이 문구는 개발자들의 악몽인 Dependency Hell(의존성 지옥)을 상징한다. 개발 환경에서 완벽히 작동하던 애플리케이션이 프로덕션 서버에서 실패하는 현상이다.
한 기업은 40개 이상의 Linux 버전을 지원하면서 각각에 대해 빌드, 테스트, 버그 수정을 반복해야 했고 막대한 리소스가 낭비되었다.
2013년 Docker의 등장은 이 문제를 해결했다. “나무를 옮길 때 주변 흙을 함께 떠서 옮기면 어디서든 자랄 수 있다”는 비유처럼, Docker 컨테이너는 애플리케이션과 모든 의존성을 하나로 묶어 어떤 환경에서든 일관되게 실행되도록 보장했다.
“Build once, run anywhere”라는 약속으로 Docker는 폭발적으로 성장하며 컨테이너화의 산업 표준이 되었다.
2. 컨테이너 오케스트레이션 전쟁의 시작
Docker가 하나의 컨테이너 실행 문제를 해결하자 새로운 문제가 등장했다. 수백, 수천 개의 컨테이너를 어떻게 관리할 것인가? 이것이 컨테이너 오케스트레이션의 필요성이다.
2014년, Google이 10년 이상 내부적으로 사용해온 Kubernetes를 오픈소스로 공개했다.
2015년에는 Kubernetes 1.0이 출시되고 CNCF에 기증되었으며, Docker도 자체 오케스트레이션 도구인 Docker Swarm을 출시하며 정면 대응했다.
Docker의 단순함 vs Kubernetes의 강력함, Docker Swarm vs Kubernetes의 치열한 경쟁 구도가 형성되었다.
3. Red Hat의 신의 한 수와 Docker의 결정적 실수
승부를 가른 첫 번째 전환점은 Red Hat의 전략적 선택이었다. 엔터프라이즈 Linux 거대 기업 Red Hat은 자체 오케스트레이터를 개발하는 대신, 자사의 플래그십 플랫폼 OpenShift를 Kubernetes 기반으로 완전히 재구축했다.
이 결정으로 Kubernetes는 즉시 엔터프라이즈 시장에서 강력한 입지를 확보했고, Docker 독점에 도전할 수 있는 주요 동맹을 얻었다.
이에 대응하여 Docker는 치명적인 실수를 범했다. “Red Hat OS를 사용한다면 무료 Docker를 사용할 수 없다. 유료 버전을 구매해야 한다”는 최후통첩을 발표한 것이다.
이는 시장 지배력을 이용한 적대적 시도로 받아들여졌고, 오픈소스 원칙에 대한 배신으로 인식되면서 커뮤니티는 Docker 생태계를 떠나기 시작했다.
4. CRI 표준과 Kubernetes의 최종 승리
커뮤니티의 대응은 기술적으로 매우 영리한 2단계 반격이었다.
1단계로, Google과 Red Hat이 주도하여 Container Runtime Interface(CRI) 표준을 만들었다. 이제 Kubernetes는 Docker뿐만 아니라 CRI를 준수하는 어떤 런타임과도 작동할 수 있게 되었다.
2단계로, containerd와 CRI-O 같은 새로운 런타임이 개발되어 비대한 Docker Engine을 완전히 우회하고 컨테이너를 직접 실행할 수 있게 되었다. “시어머니” 비유가 이를 잘 설명한다. 이전에는 Kubernetes(아내)가 컨테이너(남편)와 대화하려면 Docker Engine(참견하는 시어머니)를 거쳐야 했다. CRI와 새로운 런타임은 Kubernetes가 직접 소통할 수 있게 했다.
최종적으로 Kubernetes는 Docker 런타임 지원을 공식 중단했다. 비효율적인 중개자가 제거되고, Kubernetes가 왕좌에 확고히 자리잡았다.
5. 현재 Docker와 Kubernetes의 공존
Docker는 죽지 않았다. 역할이 전문화되었을 뿐이다.
이미지 빌드 영역에서는 Docker가 여전히 업계 표준이다. 개발자들이 애플리케이션을 컨테이너 이미지로 패키징하는 주요 도구로 사용된다.
컨테이너 실행 영역에서는 containerd와 CRI-O 같은 더 가벼운 CRI 호환 대안이 담당한다.
결국 Docker로 상자를 만들고, Kubernetes로 상자를 관리하고 실행한다.
◼ 전체 잇(IT)터뷰 내용은 ▶영상으로 바로 가기(클릭)◀에서 확인하실 수 있습니다.
|
◼ 콘텐츠 & 웨비나 문의 : marketing@talkit.tv, 02-565-0012
Copyright ⓒ 토크아이티 All rights reserved. 무단 전재 및 재배포 금지.