프라이빗 클라우드 솔루션 지도:
컨테이너와 오픈소스

Oct 24. 2025

안녕하세요.

지난 화에서 우리는 VMware와 Nutanix라는, VM(가상 머신) 기반 프라이빗 클라우드 시장의 두 강자를 살펴보았습니다. 이들은 익숙하고 안정적인 방식으로 기업의 데이터센터를 현대화하는 길을 제시합니다.

하지만 클라우드의 진정한 힘은 단순히 서버를 가상화하는 것을 넘어, 애플리케이션을 개발하고 배포하는 방식 자체를 바꾸는 데 있습니다. 여기서 VM과는 완전히 다른, 더 가볍고 빠르며 유연한 기술인 컨테이너(Container)와 쿠버네티스(Kubernetes)가 등장합니다.

많은 기업들이 이 기술의 필요성은 알지만, 그 복잡성과 생소함 때문에 도입을 주저합니다.

실제로 레드햇코리아의 김경상 대표는 "OpenShift는 결국 컨테이너 기반 프라이빗 클라우드를 구현해주는 플랫폼인데, 이를 설명하는 데 있어 가장 큰 어려움은 고객이 '컨테이너' 자체를 잘 이해하지 못한다는 점"이라고 말한 바 있습니다.

이번 화에서는 이 어렵지만 강력한 기술들의 개념을 먼저 명확히 짚고, 이를 기반으로 프라이빗 클라우드를 구현하는 두 가지 솔루션, Red Hat OpenShift와 OpenStack을 탐험해 보겠습니다.

모든 것의 시작: 컨테이너와 쿠버네티스, 무엇이 다른가?

1. 컨테이너: "제 컴퓨터에서는 잘 됐는데요?"를 없애는 기술

개발자라면 누구나 한 번쯤 겪어봤을 악몽이 있습니다. 내 PC에서는 완벽하게 작동하던 프로그램이 동료의 PC나 실제 서버에서는 오류를 뿜어내는 상황이죠. 원인은 간단합니다. 각 컴퓨터마다 설치된 라이브러리, 프레임워크 버전, 심지어 운영체제의 설정까지 미묘하게 다르기 때문입니다.

컨테이너는 바로 이 문제를 해결하기 위해 태어났습니다. 해외로 물건을 보낼 때 내용물이 무엇이든 규격화된 컨테이너 박스에 담아 보내는 것처럼, 컨테이너 기술은 애플리케이션과 그것이 실행되는 데 필요한 모든 것을 하나의 '이미지'로 패키징합니다. 여기에는 애플리케이션 코드는 물론, 그것을 실행하는 데 필요한 라이브러리, 설정 파일, 환경 변수까지 모두 포함됩니다.

이 '컨테이너 이미지'만 있으면, 개발자 PC든, 테스트 서버든, 실제 운영 클라우드 서버든 어디서나 동일하게 작동하는 것을 보장합니다. 환경에 대해 걱정할 필요가 없어지는 것이죠.

VM과 컨테이너, 무엇이 다른가?

VM(가상 머신)과 컨테이너는 비슷해 보이지만, 근본적으로 다른 접근 방식을 취합니다.

VM이 운영체제(OS)까지 통째로 포함하는 무거운 '집'이라면, 컨테이너는 OS는 호스트와 공유하고 애플리케이션만 가볍게 격리하는 '방'에 가깝습니다.

예를 들어볼까요? VM 하나를 띄우려면 OS 전체를 부팅해야 하므로 수 분이 걸립니다.

하지만 컨테이너는 이미 실행 중인 OS 위에서 프로세스만 격리하는 방식이기 때문에, 시작하는 데 불과 몇 초밖에 걸리지 않습니다. 메모리 사용량도 훨씬 적죠. 그래서 같은 서버 위에서 VM은 몇 개만 띄울 수 있지만, 컨테이너는 수십, 수백 개를 동시에 실행할 수 있습니다.

[다이어그램 1: VM vs 컨테이너 아키텍처 비교]

위 다이어그램에서 볼 수 있듯이, VM은 각각 독립된 Guest OS를 포함하여 하이퍼바이저 위에서 실행됩니다. 반면 컨테이너는 호스트 OS를 공유하며, 컨테이너 엔진(Docker 등)을 통해 애플리케이션과 필요한 라이브러리만 격리합니다. 이 구조적 차이가 컨테이너를 훨씬 가볍고 빠르게 만드는 핵심입니다.

2. 쿠버네티스: 컨테이너를 지휘하는 오케스트라 지휘자

컨테이너 기술로 애플리케이션을 쉽게 포장할 수 있게 되었습니다. 하지만 현대적인 웹 서비스는 수십, 수백 개의 컨테이너로 이루어집니다.

예를 들어, 쇼핑몰 하나를 운영한다고 생각해 보세요. 상품 목록을 보여주는 컨테이너, 장바구니를 관리하는 컨테이너, 결제를 처리하는 컨테이너, 사용자 인증을 담당하는 컨테이너 등이 각각 독립적으로 실행됩니다.

문제는 이 많은 컨테이너들을 사람이 일일이 관리하는 것은 불가능하다는 점입니다.

어떤 서버에 여유 공간이 있는지 확인하고, 컨테이너를 배치하고, 특정 컨테이너가 죽으면 다시 살리고, 트래픽이 몰리면 컨테이너를 더 띄우고... 이 모든 일을 사람이 한다면 24시간이 모자랄 겁니다.

이 복잡한 문제를 해결하는 것이 바로 쿠버네티스(Kubernetes)입니다.

쿠버네티스는 수많은 컨테이너를 자동으로 관리하는 시스템입니다. 마치 수백 명의 연주자로 이루어진 오케스트라를 지휘하는 '지휘자'와 같다고 해서 '컨테이너 오케스트레이션(Orchestration)' 플랫폼이라고도 불립니다.

쿠버네티스는 이름이 너무 길어서 보통 'K8s'(K와 s 사이에 8글자가 있다는 의미)라는 약어로 불립니다.

K8s가 자동으로 처리하는 일들을 구체적으로 살펴볼까요?

스케줄링(Scheduling)
클러스터 내 여러 서버 중 어디에 여유 공간이 있는지 파악하여, 새로운 컨테이너를 가장 적절한 서버에 자동으로 배치합니다.

자가 치유(Self-healing)
특정 컨테이너에 문제가 생겨 멈추거나 응답하지 않으면, 자동으로 다시 시작시키거나 새로운 컨테이너로 교체합니다. 밤새 장애 알림을 받고 일어나 수동으로 재시작할 필요가 없어지는 것이죠.

자동 확장(Auto-scaling)
사용자가 갑자기 몰리면 컨테이너 수를 자동으로 늘리고, 트래픽이 줄어들면 다시 줄여 비용을 최적화합니다. 예를 들어, 평소에는 컨테이너 5개로 서비스하다가 블랙프라이데이 같은 이벤트 때는 50개로 늘렸다가, 이벤트가 끝나면 다시 5개로 줄이는 것을 자동으로 처리합니다.

[다이어그램 2: 쿠버네티스 컨테이너 오케스트레이션]

위 다이어그램은 쿠버네티스가 여러 서버(Node)에 분산된 수많은 컨테이너를 어떻게 관리하는지 보여줍니다. Control Plane이 지휘자처럼 전체를 조율하며, 각 Node에서 실행 중인 컨테이너들을 모니터링합니다. 만약 특정 컨테이너에 오류가 발생하면 자동으로 재시작하고, 여유 공간이 있는 Node에 새로운 컨테이너를 배치합니다.

Red Hat OpenShift: 기업을 위한 완성형 쿠버네티스

쿠버네티스는 매우 강력하지만, 오픈소스 그 자체는 마치 자동차 엔진과 같습니다.

아무리 성능 좋은 엔진이라도, 그것만으로는 도로를 달릴 수 없죠. 핸들, 브레이크, 에어백, 내비게이션 등 수많은 부품이 필요합니다.

쿠버네티스도 마찬가지입니다. 기업 환경에서 안정적으로 사용하려면 보안 정책, 모니터링 시스템, 네트워킹 구성, 로깅, 개발자 도구, CI/CD 파이프라인 등 수많은 추가 구성 요소를 직접 찾아서 조립하고 테스트해야 합니다. 각 구성 요소 간의 호환성을 맞추고, 버전을 관리하고, 문제가 생기면 해결하는 것은 엄청난 기술적 부담입니다.

Red Hat OpenShift는 바로 이 지점에서 가치를 제공합니다.

오픈소스 쿠버네티스라는 강력한 엔진에, Red Hat이 수년간 검증한 보안 체계, 모니터링 도구, CI/CD 파이프라인, 개발자용 웹 콘솔과 CLI 툴킷 등을 모두 통합하여 '완성된 자동차' 형태로 제공하는 엔터프라이즈 플랫폼입니다.

OpenShift의 가장 큰 강점은 어디서나 동일한 환경을 제공한다는 점입니다. 온프레미스 데이터센터든, AWS든, Azure든, GCP든 어디에 설치하든 동일한 OpenShift 환경이 구축됩니다. 개발자는 자신의 로컬 환경에서 테스트한 컨테이너를 어떤 클라우드에 배포하든 동일하게 작동한다는 확신을 가질 수 있고, 운영팀은 하나의 도구로 모든 환경을 관리할 수 있습니다. 이는 하이브리드/멀티 클라우드 전략을 구사하는 기업에게 매우 강력한 장점입니다.

하지만 OpenShift를 제대로 활용하려면 고려해야 할 사항들이 있습니다.

우선, 단순히 기술을 도입하는 것을 넘어 개발팀과 운영팀이 함께 움직이는 DevOps 문화가 조직에 정착되어 있어야 합니다. 컨테이너와 쿠버네티스라는 기술 자체가 애플리케이션을 자주, 빠르게 배포하는 것을 전제로 설계되었기 때문입니다. 또한 컨테이너, 쿠버네티스, 마이크로서비스 아키텍처에 대한 팀의 기술적 이해도가 필요합니다.

어떤 기업에 적합한가?

OpenShift는 애플리케이션 중심의 클라우드 네이티브 환경을 구축하려는 기업에게 적합합니다. 특히 DevOps 문화가 이미 성숙한 조직이나, 여러 퍼블릭 클라우드와 프라이빗 환경 간 일관된 운영 체계를 유지하려는 대기업, 금융권, 공공 플랫폼 기업들이 주로 선택합니다.

OpenStack: 우리만의 클라우드를 만드는 오픈소스 레고

VMware가 기성품 가구라면, OpenStack은 이케아(IKEA) 가구와 같습니다. 모든 부품이 분리되어 제공되고, 우리는 설명서를 보며 우리만의 클라우드를 직접 조립해야 합니다.

OpenStack은 컴퓨팅(Nova), 스토리지(Cinder, Swift), 네트워킹(Neutron), 이미지 관리(Glance) 등 클라우드 인프라를 구성하는 각 기능을 독립적인 모듈로 제공하는 오픈소스 프로젝트입니다. 이 모듈들을 조합하면 AWS나 Azure 같은 퍼블릭 클라우드와 유사한 IaaS(Infrastructure as a Service) 환경을 온프레미스에 직접 구축할 수 있습니다.

OpenStack의 가장 큰 장점은 '기술 독립성'입니다.

특정 벤더에 종속되지 않고, 우리가 원하는 하드웨어 위에, 우리가 원하는 방식으로 클라우드를 만들 수 있습니다. 이론적으로는 가장 유연하고 비용 효율적인 구조를 설계할 수 있죠. 실제로 국내외 주요 통신사들(SK텔레콤, KT, LG유플러스 등)은 자사의 클라우드 서비스를 OpenStack 기반으로 구축했습니다. 수십만 명의 고객을 수용해야 하는 통신사 입장에서는, 특정 벤더의 솔루션을 쓰기보다 직접 인프라를 완전히 통제하는 것이 더 합리적인 선택이었던 것이죠.

하지만 그 자유에는 혹독한 대가가 따릅니다.

OpenStack은 구축과 운영의 복잡성이 극도로 높습니다.

수십 개의 모듈 간 호환성을 맞추고, 지속적으로 업그레이드하며, 장애가 발생했을 때 어느 모듈이 문제인지 찾아 해결하는 모든 책임을 우리가 져야 합니다. 각 모듈의 업데이트 주기도 다르고, 버전 간 의존성도 복잡합니다.

이를 감당할 수 있는 고도의 기술 내재화 역량이 없다면, OpenStack은 기대했던 유연성을 제공하기는커녕 오히려 조직의 발목을 잡는 짐이 될 수 있습니다. 실제로 많은 기업들이 OpenStack 도입을 시도했다가, 운영 부담을 감당하지 못하고 상용 솔루션으로 다시 돌아가는 경우를 종종 볼 수 있습니다.

어떤 기업에 적합한가?

OpenStack은 자체 클라우드 인프라를 운영할 수 있는 고도의 기술 역량을 보유한 조직에게 적합합니다. 대규모 통신사, 대형 포털, 인프라 R&D가 가능한 연구 기관처럼 인프라 전문 인력을 충분히 확보하고 있으며, 벤더 종속에서 완전히 벗어나 기술적 독립을 추구하는 소수의 조직에게는 여전히 매력적인 선택지입니다.

마무리하며: 안정적 진화인가, 근본적 혁신인가

VMware와 Nutanix가 '안정적인 진화'를 위한 선택지라면, OpenShift와 OpenStack은 '근본적인 혁신'과 '기술 독립'을 위한, 훨씬 더 대담한 선택지입니다.

이것으로 프라이빗 클라우드 솔루션의 큰 지도를 모두 살펴보았습니다.

VM 기반의 VMware와 Nutanix, 컨테이너 기반의 OpenShift, 오픈소스 IaaS인 OpenStack까지. 중요한 것은 어느 솔루션이 절대적으로 우월한 것이 아니라는 점입니다.

우리 조직의 현재 기술 수준, 문화적 성숙도, 그리고 미래의 비전이 어디를 향하고 있는지에 따라 최적의 선택은 달라집니다.

하지만 프라이빗 클라우드만으로는 충분하지 않습니다. 앞서 6화에서 살펴봤듯이, 많은 기업들이 다시 프라이빗으로 돌아오고 있지만, 그것이 퍼블릭 클라우드를 완전히 버린다는 의미는 아닙니다. 오히려 프라이빗과 퍼블릭을 함께 사용하는 하이브리드 클라우드가 새로운 표준이 되어가고 있습니다.