클라우드와 가상화의 기술적 탐구
- 클라우드 서비스 모델 (IaaS, PaaS, SaaS): 클라우드가 ‘무엇을’ 제공하는지 서비스 모델별 책임 범위를 통해 알아본다.
- 서버 아키텍처 (베어메탈, VM, 컨테이너): 클라우드가 ‘어떻게’ 동작하는지 그 내부 아키텍처를 기술적으로 분석한다.
- 오픈스택 (OpenStack): 이 모든 것을 직접 구축할 수 있게 해주는 ‘오픈소스 플랫폼’의 기술적 구성과 역사를 살펴본다.
클라우드 기초: IaaS, PaaS, SaaS의 기술적 구분
클라우드 서비스 모델은 사용자와 서비스 제공업체 간의 관리 책임 범위를 기준으로 나뉜다. 이 선택지가 바로 IaaS, PaaS, SaaS다. 여기서 ‘서비스형(as-a-Service)’이라는 개념이 중요하다. 이는 제3의 공급업체가 특정 IT 구성 요소를 관리해주어, 사용자는 더 중요한 비즈니스 로직에 집중할 수 있게 해준다는 의미다.
전통적인 방식: 온프레미스 (On-Premises)
가장 먼저, 전통적인 방식인 온프레미스(On-Premises) 환경이다. 이는 기업이 자체 데이터 센터에 물리적 서버, 네트워크 장비, 스토리지를 직접 구매하여 소유하고 운영하는 방식에 해당한다. 하드웨어 구매부터 설치, 유지보수, 소프트웨어 관리까지 모든 책임을 직접 져야 한다.
IaaS (Infrastructure as a Service): 인프라만 서비스로 사용
IaaS는 클라우드 제공업체가 컴퓨팅(가상 서버), 스토리지, 네트워킹과 같은 가장 기본적인 IT 인프라 구성 요소를 서비스 형태로 제공하는 모델이다. 사용자는 웹 대시보드나 API를 통해 이 인프라에 접근하여 원하는 대로 활용할 수 있다. 하지만 운영체제(OS) 설치, 미들웨어, 런타임, 그리고 애플리케이션 관리는 여전히 사용자의 몫이다.
- 주요 특징:
- 최고의 유연성과 제어권: 사용자는 인프라를 완전히 제어할 수 있다. 원하는 OS를 설치하고, 네트워크를 세밀하게 구성하는 등 거의 모든 것을 맞춤 설정할 수 있다. 이는 클라우드 환경에서 전통적인 IT 환경과 가장 유사한 경험을 제공한다.
- 비용 효율성 (종량제): 막대한 초기 하드웨어 투자 없이, 사용한 만큼만 비용을 지불하는 종량제 모델을 따른다.
- 대표 서비스: Amazon EC2, Microsoft Azure VMs, Google Compute Engine.
 
PaaS (Platform as a Service): 플랫폼을 서비스로 사용
PaaS 환경에서 제공업체는 서버, OS, 데이터베이스, 런타임(예: Node.js, Java 환경) 등 애플리케이션 개발과 실행에 필요한 모든 플랫폼을 관리해 준다. 개발자는 OS 패치나 서버 유지보수 같은 인프라 관리에 대한 걱정 없이 오직 자신의 애플리케이션 코드와 데이터에만 집중하면 된다.
- 주요 특징:
- 개발자 생산성 극대화: 인프라 관리 부담을 제거하여 개발자가 애플리케이션 개발 및 배포에만 집중하게 함으로써 개발 속도를 획기적으로 높인다.
- 관리형 환경: 플랫폼이 미리 구성되어 제공된다. 이는 개발을 단순화하지만, IaaS만큼의 완전한 제어권은 제공하지 않는다.
- 대표 서비스: Heroku, Google App Engine, AWS Elastic Beanstalk.
 
SaaS (Software as a Service): 소프트웨어를 서비스로 사용
SaaS는 인터넷을 통해 제공되는 완성된 소프트웨어 애플리케이션이다. 제공업체가 하드웨어부터 애플리케이션 코드까지 모든 것을 관리하므로, 사용자는 설치, 업데이트, 유지보수에 대해 전혀 신경 쓸 필요가 없다.
- 주요 특징:
- 최고의 편의성: 사용자는 인터넷 브라우저나 앱만 있으면 언제 어디서든 서비스에 접근할 수 있다.
- 구독 기반 모델: 일반적으로 월간 또는 연간 구독료를 지불하고 서비스를 이용한다.
- 대표 서비스: Google Workspace (Gmail, Docs), Dropbox, Salesforce 등 우리가 일상적으로 사용하는 대부분의 웹 서비스.
 
통제권과 편의성 사이의 저울질
이 세 가지 모델에서 가장 중요한 것은 ‘좋고 나쁨’의 문제가 아니라 ‘통제권(Control)과 편의성(Convenience)’ 사이의 기술적 트레이드오프라는 점이다. IaaS는 가장 높은 통제권을 주지만, 그만큼 사용자가 관리해야 할 것도 많다. 반면 SaaS는 가장 높은 편의성을 제공하지만, 사용자가 변경할 수 있는 것은 거의 없다. PaaS는 그 중간에서 균형을 제공한다.
이 관계는 서비스 모델을 선택할 때 핵심적인 고려 사항이 된다. 인프라에 대한 완전한 제어가 필요한 복잡한 시스템을 구축한다면 IaaS가 적합할 것이다. 반면, 빠른 프로토타이핑과 시장 출시가 목표인 스타트업에게는 PaaS가 매력적인 선택지다. 이처럼 프로젝트의 요구사항, 팀의 기술력, 그리고 개발 속도 중 무엇이 더 중요한지에 따라 최적의 모델을 선택해야 한다.
<br>
표 1: 클라우드 서비스 모델 책임 매트릭스
| 관리 영역 | 온프레미스 | IaaS | PaaS | SaaS | 
|---|---|---|---|---|
| 애플리케이션 | 사용자 관리 | 사용자 관리 | 사용자 관리 | 공급업체 관리 | 
| 데이터 | 사용자 관리 | 사용자 관리 | 사용자 관리 | 공급업체 관리 | 
| 런타임 | 사용자 관리 | 사용자 관리 | 공급업체 관리 | 공급업체 관리 | 
| 미들웨어 | 사용자 관리 | 사용자 관리 | 공급업체 관리 | 공급업체 관리 | 
| 운영체제(OS) | 사용자 관리 | 사용자 관리 | 공급업체 관리 | 공급업체 관리 | 
| 가상화 | 사용자 관리 | 공급업체 관리 | 공급업체 관리 | 공급업체 관리 | 
| 서버 | 사용자 관리 | 공급업체 관리 | 공급업체 관리 | 공급업체 관리 | 
| 스토리지 | 사용자 관리 | 공급업체 관리 | 공급업체 관리 | 공급업체 관리 | 
| 네트워킹 | 사용자 관리 | 공급업체 관리 | 공급업체 관리 | 공급업체 관리 | 
<br>
편리함의 숨겨진 대가: 벤더 종속성
PaaS와 SaaS가 제공하는 편리함에는 숨겨진 대가가 따를 수 있다. 바로 **’벤더 종속성(Vendor Lock-in)’**이다. 특정 PaaS 플랫폼의 기능과 구조에 맞춰 애플리케이션을 개발했다면, 다른 클라우드 제공업체로 이전하기가 매우 어려워질 수 있다. 플랫폼에 종속되어 데이터를 옮기는 것조차 복잡한 작업이 될 수 있기 때문이다. IaaS는 상대적으로 이런 종속성이 덜하지만, PaaS나 SaaS를 선택할 때는 이러한 장기적인 트레이드오프를 반드시 고려해야 한다. 초기에 내린 아키텍처 결정이 미래에 큰 비용으로 돌아올 수 있다는 점을 인지하고 있어야 한다.
<br>
표 2: IaaS vs. PaaS vs. SaaS 상황별 최적의 선택 가이드
| 구분 | IaaS | PaaS | SaaS | 
|---|---|---|---|
| 핵심 | 가상화된 IT 인프라 제공 | 개발 및 배포 플랫폼 제공 | 완성된 소프트웨어 제공 | 
| 유연성 | 매우 높음 (OS부터 모든 것 제어) | 중간 (플랫폼 내에서 자유로움) | 매우 낮음 (제공된 기능만 사용) | 
| 관리 부담 | 높음 (OS, 미들웨어 등 직접 관리) | 낮음 (애플리케이션 코드만 관리) | 없음 (모든 것을 공급업체가 관리) | 
| 시장 출시 속도 | 느림 | 빠름 | 즉시 사용 가능 | 
| 추천 대상 | 인프라 완전 제어가 필요한 기업, 레거시 시스템 마이그레이션 | 빠른 애플리케이션 개발 및 배포가 목표인 팀, 스타트업 | 특정 비즈니스 요구에 맞는 기성 솔루션이 필요한 사용자 | 
| 대표 서비스 | AWS EC2, Azure VM, Google Compute Engine | Heroku, AWS Elastic Beanstalk, Google App Engine | Google Workspace, Dropbox, Salesforce | 
<br>
서버의 변신: 베어메탈, VM, 컨테이너의 기술적 분석
지금까지 클라우드 서비스 모델의 종류를 알아봤다. 이제는 그 서비스가 동작하는 기반 인프라의 아키텍처를 들여다볼 차례다. 서버 한 대를 어떻게 활용하는지에 따라 그 모습은 완전히 달라진다. 이 차이를 베어메탈, 가상 머신, 그리고 컨테이너로 나누어 기술적으로 분석했다.
베어메탈: 물리 서버의 직접 사용
베어메탈(Bare Metal)은 가상화 계층 없이 물리적 하드웨어에 운영체제를 직접 설치하여 사용하는 단일 테넌트 전용 서버를 의미한다. 하드웨어 자원을 다른 사용자와 공유하지 않고 온전히 단독으로 사용한다.
- 주요 특징:
- 최고의 성능: 가상화로 인한 오버헤드가 전혀 없기 때문에 하드웨어의 성능을 100% 활용할 수 있다. 이는 매우 빠르고 강력한 성능으로 이어진다.
- 완벽한 격리와 보안: 하드웨어를 다른 누구와도 공유하지 않으므로, 자원과 데이터에 대한 가장 높은 수준의 격리 및 보안을 제공한다.
- 적합한 용도: 대규모 데이터베이스, AI 모델 훈련, 고성능 컴퓨팅(HPC) 등 최고의 성능이 필수적인 워크로드에 이상적이다.
- 단점: 애플리케이션이 서버의 모든 자원을 사용하지 않는다면 낭비가 발생할 수 있다. 또한 확장을 위해서는 새로운 물리 서버를 추가해야 하므로 민첩성이 떨어진다.
 
가상 머신(VM): 하드웨어 가상화
가상 머신(Virtual Machine, VM)은 **하이퍼바이저(Hypervisor)**라는 소프트웨어를 통해 하나의 물리 서버 위에 여러 개의 독립된 가상 컴퓨터를 생성하는 기술이다. 각 VM은 자신만의 독립된 **게스트 운영체제(Guest OS)**를 포함하여 완벽하게 격리된 환경을 제공한다.
- 주요 특징:
- 효율적인 자원 활용: 하나의 물리 서버에서 서로 다른 여러 애플리케이션을 각자의 VM에서 실행함으로써 하드웨어 활용률을 크게 높일 수 있다.
- 강력한 격리: 각 VM은 독립된 OS를 가지므로, 한 VM에서 발생한 문제(크래시, 보안 침해 등)가 다른 VM에 영향을 주지 않는다. 이는 VM의 핵심적인 장점이다.
- 오버헤드: 하이퍼바이저 자체의 오버헤드와 더불어, 모든 VM이 완전한 OS 복사본을 실행하기 때문에 상당한 자원(CPU, 메모리)을 소모한다. 이 때문에 VM은 상대적으로 무겁고, 크기는 기가바이트 단위이며 부팅하는 데 수 분이 걸린다.
 
컨테이너: 운영체제 가상화
컨테이너는 하드웨어가 아닌 운영체제를 가상화하는 기술이다. 호스트 서버의 **OS 커널(Kernel)**을 모든 컨테이너가 공유하며, 각 컨테이너는 애플리케이션 코드와 실행에 필요한 라이브러리, 바이너리 등만 패키징한 격리된 프로세스다. 도커(Docker)는 가장 널리 사용되는 컨테이너화 플랫폼이다.
- 주요 특징:
- 경량성과 속도: 완전한 OS를 포함하지 않기 때문에 컨테이너는 매우 가볍고(메가바이트 단위), 수 초 내에 시작된다. 이는 서버 한 대에 VM보다 훨씬 더 많은 컨테이너를 실행할 수 있게 해준다.
- 뛰어난 이식성: 컨테이너는 애플리케이션 실행에 필요한 모든 것을 패키징한다. 이 패키지는 개발 환경, 테스트 서버, 프로덕션 클라우드 등 어디로 옮겨도 동일하게 실행된다. 이는 현대적인 데브옵스(DevOps)와 CI/CD 파이프라인의 핵심이다.
- 상대적으로 약한 격리: 호스트 OS 커널을 공유한다는 것은, 커널 수준의 보안 취약점이 발생할 경우 해당 호스트의 모든 컨테이너에 영향을 미칠 수 있음을 의미한다. VM만큼의 강력한 격리는 제공하지 못한다.
 
컨테이너의 엔진: cgroups와 namespaces
컨테이너가 OS 커널을 공유하면서도 독립적인 공간처럼 작동할 수 있는 원리는 리눅스 커널의 두 가지 핵심 기능에 있다: 네임스페이스(Namespaces)와 컨트롤 그룹(cgroups).
- **네임스페이스(Namespaces)**는 ‘격리’를 담당한다. 이는 프로세스에게 시스템의 특정 부분을 자신만이 사용하는 것처럼 보이게 하는 기술이다. 예를 들어, PID 네임스페이스는 독립적인 프로세스 ID 공간을, 네트워크 네임스페이스는 독립된 네트워크 인터페이스, IP 주소, 포트 공간을 제공한다. 
- **컨트롤 그룹(cgroups)**은 ‘자원 제어’를 담당한다. 이는 특정 프로세스 그룹(컨테이너)이 사용할 수 있는 시스템 자원(CPU, 메모리 등)의 양을 제한하고 관리하는 기능이다. 이를 통해 하나의 컨테이너가 서버의 모든 자원을 독차지하는 것을 방지한다. 
결국 컨테이너는 리눅스 커널의 이 두 가지 핵심 기능을 활용하여 프로세스를 격리하고 자원을 통제하는 기술이다.
<br>
표 3: 베어메탈 vs. VM vs. 컨테이너 기술 스펙 비교
| 속성 | 베어메탈 | 가상 머신 (VM) | 컨테이너 | 
|---|---|---|---|
| 격리 수준 | 최고 (물리적 격리) | 높음 (하이퍼바이저를 통한 완전한 OS 격리) | 중간 (OS 커널 공유, 프로세스 수준 격리) | 
| 성능/오버헤드 | 최고 성능 / 오버헤드 없음 | 중간 성능 / 하이퍼바이저 및 게스트 OS 오버헤드 존재 | 높은 성능 / 오버헤드 매우 적음 | 
| 크기/자원 점유 | 전체 서버 | 큼 (GB 단위) | 작음 (MB 단위) | 
| 시작 시간 | 수 분 (물리 서버 부팅) | 수 분 (OS 부팅) | 수 초 (프로세스 시작) | 
| 이식성 | 낮음 (하드웨어 종속) | 중간 (VM 이미지 단위 이동) | 매우 높음 (환경에 거의 무관) | 
| OS 의존성 | 없음 | 없음 (각자 독립 OS) | 높음 (호스트 OS 커널 공유) | 
<br>
오픈소스의 힘: OpenStack의 기술적 분석
이제 클라우드 서비스의 종류와 그 기반 기술에 대해 알게 되었다. 마지막으로, 이 모든 것을 직접 구축할 수 있게 해주는 오픈소스 플랫폼, 오픈스택(OpenStack)에 대해 알아본다. 오픈스택은 흩어져 있는 여러 대의 컴퓨터 자원을 모아 하나의 거대한 클라우드로 만들어주는 오픈소스 플랫폼이다.
NASA와 Rackspace의 만남: 클라우드 운영체제의 탄생
이야기는 2010년으로 거슬러 올라간다. 당시 미국 항공우주국(NASA)은 자체 컴퓨팅 플랫폼 ‘네뷸라(Nebula)’를, 호스팅 기업 랙스페이스(Rackspace)는 스토리지 플랫폼 ‘클라우드 파일(Cloud Files)’을 각각 개발하고 있었다. 두 프로젝트는 서로 보완적이었고, 같은 프로그래밍 언어(Python)로 작성되고 있었다. 이들은 각자의 프로젝트를 합쳐 하나의 거대한 오픈소스 프로젝트로 만들기로 결정했고, 이것이 바로 ‘오픈스택’의 탄생이었다. 목표는 명확했다: Amazon Web Services(AWS)와 같은 독점적인 상용 클라우드에 대한 오픈소스 대안을 만들어 클라우드 기술을 민주화하는 것이었다.
클라우드 운영체제와 핵심 구성 요소
오픈스택은 단일 컴퓨터가 아닌 데이터센터 전체를 위한 운영체제처럼 작동한다. 여러 서버, 스토리지, 네트워크 장비들을 하나의 거대한 자원 풀(Pool)로 묶고, 이를 통합된 서비스 형태로 제공한다. 이 시스템은 여러 개의 모듈화된 프로젝트로 구성되어 각자의 역할을 수행한다.
- Nova (Compute): 가상 머신(VM)을 생성, 스케줄링, 관리하는 핵심 컴퓨팅 서비스다.
- Neutron (Networking): 가상 네트워크, 라우터, IP 주소 등을 관리하여 모든 클라우드 구성 요소의 통신을 담당한다.
- Swift (Object Storage) & Cinder (Block Storage): Swift는 대용량 비정형 데이터를 위한 객체 스토리지를, Cinder는 VM에 연결하여 사용하는 블록 스토리지를 제공한다.
- Glance (Image Service): VM을 생성할 때 기반이 되는 OS 이미지(템플릿)를 저장하고 관리한다.
- Keystone (Identity Service): 사용자 인증과 역할 기반의 권한 관리를 통해 클라우드 자원 접근을 통제한다.
- Horizon (Dashboard): 웹 기반 대시보드를 통해 클라우드의 모든 것을 시각적으로 확인하고 제어하는 인터페이스를 제공한다.
오픈스택의 역설: 자유의 대가
오픈스택의 철학에는 흥미로운 기술적 트레이드오프가 존재한다. 바로 **’자유와 복잡성’**이다. 오픈스택의 가장 큰 장점은 오픈소스이기에 특정 벤더에 종속되지 않는 ‘자유’를 준다는 것이다. AWS나 GCP 같은 특정 기업의 플랫폼에 갇히지 않고, 원하는 하드웨어 위에서 자신만의 클라우드를 구축할 수 있다.
하지만 이 자유를 얻기 위해서는 클라우드를 직접 구축하고 운영하는 엄청난 ‘복잡성’이라는 대가를 치러야 한다. 오픈스택은 수많은 구성 요소가 복잡하게 얽혀 있어 초기 구축이 어렵고, 문제 발생 시 유지보수 난이도 또한 매우 높다. 이는 오픈스택이 모든 기업을 위한 만능 해결책이 아니라, 자체 프라이빗 클라우드를 운영할 충분한 기술력과 명확한 비즈니스 요구(예: 데이터 주권, 보안 규제)를 가진 대규모 조직에서 주로 성공적으로 사용되는 이유를 설명해준다.
오늘날 오픈스택의 위치
현재 오픈스택은 프라이빗 및 하이브리드 클라우드를 구축하는 가장 강력한 오픈소스 플랫폼으로 자리매김했다. 특히 통신 업계에서는 네트워크 기능 가상화(NFV)의 핵심 인프라로 널리 사용되고 있다.
또한, 오픈스택은 쿠버네티스와 경쟁하는 대신 협력하는 길을 택했다. 많은 현대적인 클라우드 환경에서는 오픈스택을 IaaS 레이어로 사용하여 VM, 네트워크, 스토리지를 프로비저닝하고, 그 위에 쿠버네티스를 배포하여 컨테이너를 오케스트레이션하는 아키텍처를 채택한다. 이는 현대 인프라가 어떻게 계층적으로, 그리고 협력적으로 구성되는지를 잘 보여준다.
 

답글 남기기