가상화(Virtualization)

✅ 물리적인 하드웨어 리소스(CPU, GPU, RAM, HDD/SDD, 네트워크 장치)를 논리적으로 분할하여 여러 가상 시스템을 생성하고 관리하는 기술. 이를 통해 하나의 물리적 컴퓨터(호트스)에서 여러개의 독립된 가상 컴퓨터(게스트)를 실행. 가상화는 서버, 스토리지, 네트워크 등 다양한 IT 자원을 효율적으로 사용할 수 있게 해주어, 여러 유형의 가상화를 통해 다양한 목적 달성

1. 가상머신(VM) : 하이퍼바이저를 이용하여 리소스 전체를 가상화

2. 컨테이너 : OS수준에서 프로세스(app)을 컨테이너 형태로 격리

하이퍼바이저(Hypervisor) vs 컨테이너(Container)

목	하이퍼바이저(Hypervisor)	컨테이너(Container)
개념	물리 머신에서 여러 개의 운영체제(OS)를 실행할 수 있도록 가상 머신(VM)을 생성하는 기술	단일 OS 내에서 가볍게 격리된 애플리케이션 실행 환경을 제공하는 기술
가상화 방식	하드웨어 레벨 가상화 (Bare Metal 또는 Hosted)	OS 레벨 가상화
구성 요소	Hypervisor (VMware ESXi, Hyper-V, KVM 등) + Guest OS	컨테이너 엔진 (Docker, Podman, LXC 등) + 컨테이너
운영체제	각 VM이 독립적인 OS를 실행	모든 컨테이너가 같은 OS 커널을 공유
리소스 사용량	VM별 OS가 필요하므로 상대적으로 무겁고, 리소스 소모가 많음	OS를 공유하므로 경량화되어 빠르게 실행됨
배포 속도	VM 생성 및 부팅 시간이 필요하여 느림	컨테이너는 몇 초 내로 실행 가능
격리성	완전한 OS 단위의 격리 (보안이 강함)	프로세스 단위의 격리 (보안 측면에서 추가 조치 필요)
확장성	VM 개수만큼 자원이 필요해 확장에 한계 있음	가벼워서 빠르게 확장 가능
대표 솔루션	VMware vSphere, Microsoft Hyper-V, KVM, Xen 등	Docker, Kubernetes, Podman, LXC 등

하이퍼바이저(Hypervisor)

✅ 하나의 컴퓨터에서 하나의 OS만 운영 하는 방식의 비효율을 해결. 물리적 자원인 하드웨어를 효율적으로 활용하기 위해서 하드웨어 공간 위에 가상의 머신을 만드는 기술
EX)

• Windows PC에서 Linux VM을 실행하여 개발 환경 구축
• 회사 내부에서 개발팀과 운영팀이 각각 VM을 사용하여 테스트
• AWS EC2 인스턴스는 실제로 하이퍼바이저 위에서 돌아가는 가상 머신이며, 여러 고객이 같은 물리 서버를 공유

1. 하나의 물리적 서버 위에 존재하는 베이스가 되는 기존의 환경을 Host OS
2. 그 위에 존재하는 다수의 독립적으로 가상의 머신으로 분할된 Guest OS

• 각각의 Guest는 하이퍼바이저에 의해 생성되고 관리되며 시스템 자원을 할당받는다. Guest는 Host나 다른 Guest와 상호 간섭하지 않고 분리된 환경에서 구동한다.
• 하이퍼바이저를 활용하면 하드웨어가 여러 개 인 것처럼 하나의 서버를 여러명이 나눠 쓸 수 있고, 컴퓨터 한 대에서 서로 다른 OS를 동시에 사용 가능
• 하지만, 가상머신으로 무언가를 하려면 반드시 하이퍼바이저를 거쳐야 하기 때문 속도 저하가 불가피하다.

클라우드 서비스의 하이퍼바이저 예시

1. AWS EC2 -> Xen, KVM
2. Microsoft Azure -> Hyper-V
3. Google Cloud Compute Engine -> KVM
4. VMware Cloud -> VMware ESXi

이런 클라우드 서비스는 내가 사용하는 가상머신(VM)이 다른 사용자들의 VM과 같은 물리 서버에서 동작할 수 있음(멀티 테넌시) 하지만 각 VM은 완전히 격리되어 있기 때문에 다른 사용자의 영향을 받지 않음

컨테이너(Container)

✅ 호스트의 OS기능을 그대로 사용하면서 프로세스를 격리해 독립된 환경을 만드는 기술이다. 하이퍼바이저와 달리 가상의 OS를 만드는 것이 아닌, 베이스 환경(호스트)을 공유하면서 필요한 프로세스만 격리하는 방식

• 커널을 공유하기 때문에 호스트 OS의 기능을 모두 사용 가능
• 컨테이너란 OS 상에 논리적인 영역(컨테이너)을 구축하고, 애플리케이션이 작동하는데 필요한 요소들을 모아 별도의 서버처럼 동작하는 것. 리눅스가 아닌 환경에서 리눅스에 애플리케이션을 작동하기 위함

예시

사용자 환경 :

macOS

Docker 컨테이너 실행 :

docker run -it ubuntu -> 가능 ✅(리눅스 컨테이너 실행ok)
docker run -it mcr.microsoft.com/windows -> 불가능 ❌(윈도우 컨테이너는 실행 no)

이유 :

👉 Docker 컨테이너는 호스트 OS의 커널을 공유하기 때문에, macOS 자체에서 Windows 컨테이너를 직접 실행할 수 없음
👉 하지만 Docker Desktop이 내부적으로 macOS에서 리눅스 가상 머신을 돌려서 리눅스 컨테이너는 실행할 수 있음
👉 Windows 컨테이너는 호스트 OS가 Windows일 때만 실행 가능
👉 하이퍼바이저는 OS를 가상화하여 완전히 다른 OS도 실행 가능
👉 컨테이너는 호스트 OS의 커널을 공유하므로 다른 OS 실행이 불가능

실행 환경	리눅스 컨테이너 실행 가능 여부	윈도우 컨테이너 실행 가능 여부	방법
Linux OS (Ubuntu, CentOS 등)	✅ 가능	❌ 불가능	Native 실행
Windows OS (기본 상태)	❌ 불가능	✅ 가능	Native 실행 (Windows 컨테이너)
Windows OS + WSL2/Docker	✅ 가능	✅ 가능	WSL2 사용
macOS	✅ 가능	❌ 불가능	Docker Desktop (내부적으로 Linux VM 실행)

장점

1. 소프트웨어를 실행하기 위한 독립적인 실행 환경 제공

• 여러 개의 소프트웨어를 각 컨테이너에서 개별적으로 실행 가능 -> 충돌 없이 운동 가능

2. 가벼운 리소스 사용(Lightweight)

• VM보다 훨씬 적은 자원 사용 -> 수십~수백 개의 컨테이너 실행 가능

3. 빠른 실행 속도

• 호스트 OS의 커널을 공유하므로, 별도 OS 부팅 없이 즉시 실행 가능

단점

1. 컨테이너 관리가 어려움

• 컨테이너가 많아질수록 관리 복잡도 증가 -> Kubernetes 같은 오케스트레이션 툴 필요

2. 호스트 OS 종속성 존재

• 컨테이너가 호스트 OS의 커널을 공유하므로, 모든 OS에서 완벽한 호환이 되지 않을 수 있음

3. GUI 소프트웨어 개발에 부적합

• Docker는 CLI기반이라 GUI 앱 실행이 어려움

✅ 결론: VM과 컨테이너, 언제 사용할까?

• VM(하이퍼바이저)는 강력한 보안 격리와 OS 다양성이 필요한 환경에서 유리
  • 엔터프라이즈 데이터센터, 보안이 중요한 금융권, 레거시 애플리케이션 유지
• 컨테이너는 클라우드 네이티브, DevOps, 빠른 배포 및 확장이 필요한 환경에서 필수적
  • 스타트업, 마이크로서비스 아키텍처, 클라우드 네이티브 애플리케이션

최근 IT 업계에서는 컨테이너(Kubernetes 기반)가 하이퍼바이저보다 더 많이 사용되며, 기존 VM 환경도 점점 컨테이너 기반으로 전환하는 추세입니다. 하지만 VM이 완전히 사라지지는 않으며, 컨테이너와 함께 하이브리드 환경으로 운영되는 경우가 많다.

🚀 만약 최신 트렌드를 따라가고 싶다면?
👉 컨테이너(Kubernetes + Docker)를 중심 가즈앙!!

궁금점

1. macOS에서 Linux 컨테이너는 실행 가능한 이유

macOS는 기본적으로 Darwin 커널을 사용하지만, 리눅스와 유사한 POSIX 호환 환경을 제공. 하지만 엄밀히 따지면 macOS는 Linux 커널이 아니므로, 직접적으로 Linux 컨테이너를 실행할 수 없다. 그러나 Docker Desktop을 사용하면 macOS에서도 Linux 컨테이너를 실행할 수 있는데, 이는 내부적으로 경량 Linux VM을 실행하기 때문이다.
🔹 macOS에서 Linux 컨테이너 실행 과정
1. Docker Desktop은 내부적으로 경량 가상 머신(VM, 보통 HyperKit 또는 QEMU 기반)을 실행
2. 이 VM 안에 Linux 커널이 포함되어 있음
3. 결국 macOS 위에서 리눅스 컨테이너를 실행하는 것이 아니라, 리눅스 VM 안에서 실행하는 것
4. 사용자는 이를 직접 느끼지 못하고 Docker 명령어를 그대로 사용할 수 있음

2. 컨테이너는 다른 OS 실행이 불가능할까?

컨테이너는 VM과 다르게 가상의 OS를 만들지 않고, Host OS의 커널을 공유합니다. 즉, 컨테이너 내부에서는 별도의 커널을 실행하는 것이 아니라 호스트 OS의 커널을 그대로 사용한다.
❌ 윈도우에서 리눅스 컨테이너 실행이 어려운 이유
컨테이너는 Host OS의 커널을 공유하기 때문에, 호환되지 않는 OS 커널에서는 실행이 어렵다.
Linux 커널에서 실행되는 컨테이너
• ✅ Ubuntu, Debian, Alpine 같은 Linux 기반 컨테이너 실행 가능
• ❌ Windows 컨테이너는 실행 불가능 (Linux와 Windows는 서로 다른 커널을 사용)
Windows 커널에서 실행되는 컨테이너
• ✅ Windows 기반 컨테이너 실행 가능
• ❌ Linux 기반 컨테이너 실행 불가능

3. 물리적 하드웨어 사용 방식은 동일한가?

둘 다 물리적 하드웨어를 사용하지만, 사용하는 방식이 다릅니다.

1.하이퍼바이저 (VM 기반 가상화)

• 하이퍼바이저가 물리 하드웨어(CPU, RAM, Storage)를 가상화하여 여러 VM이 나눠서 사용
• VM 내부에서는 하드웨어가 독립적으로 보임
• 예: 16GB RAM을 가진 Host 머신에서 VM 1개당 4GB씩 할당 가능

2.컨테이너

• 호스트 OS의 커널을 그대로 사용하고, 애플리케이션 프로세스만 격리
• 물리적인 하드웨어 자원을 컨테이너끼리 공유
• 예: 컨테이너가 많아지면 메모리를 자동으로 공유하고, CPU도 필요할 때만 사용

4. 컨테이너에서 애플리케이션 프로세스 격리?

컨테이너는 하나의 호스트 OS의 커널을 공유하면서, 각 애플리케이션을 독립된 환경에서 실행하는 것을 의미 즉, 컨테이너는 VM처럼 완전한 OS를 만들지 않고, 단순히 애플리케이션 실행 환경을 분리

🔹 예시

1.리눅스에서 3개의 컨테이너를 실행한다고 가정. 하지만 이 세 개의 컨테이너는 리눅스 OS의 커널을 공유하며, 서로 독립적인 환경처럼 동작

• 컨테이너 1: Nginx 웹 서버 실행
• 컨테이너 2: MySQL 데이터베이스 실행
• 컨테이너 3: Python 애플리케이션 실행
  각 컨테이너 내부에서는 마치 독립적인 시스템처럼 Ngix, MySQL이 실행되는 것처럼 보이지만, 사실 이 모든 프로세스는 호스트 OS의 커널 위에서 실행되며, 커널의 네임스페이스(namespace) 기능을 이용해 격리된 것

5. OS 수준에서 하드웨어를 공유한다는 뜻

구분	하이퍼바이저(VM)	컨테이너
하드웨어 접근 방식	하이퍼바이저가 물리적 하드웨어를 가상화하여 VM에 "할당"	컨테이너가 호스트 OS의 하드웨어를 "공유"
CPU/RAM 사용 방식	VM 생성 시 정해진 자원을 고정적으로 할당 (ex. 4GB RAM, 2 vCPU)	컨테이너는 필요할 때만 리소스를 사용하고, OS가 동적으로 관리
커널 (Kernel)	각 VM이 독립적인 OS 커널을 실행	호스트 OS의 커널을 공유
격리 수준	완전한 OS 단위의 격리 (강력한 보안)	애플리케이션 수준에서 프로세스 단위의 격리 (경량 & 빠름)
디스크/스토리지	가상 하드웨어(Virtual Disk)를 생성하여 VM에 할당	호스트 OS의 파일 시스템을 컨테이너끼리 공유
성능 오버헤드	하드웨어 가상화로 인해 오버헤드가 큼	가상화 오버헤드가 거의 없음 (Native 실행)

🔹 예제

• Host Machine이 16GB RAM, 8-core CPU를 가진 리눅스 서버라고 가정
• 하이퍼바이저(VM)는 VM마다 각각 4GB RAM, 2-core CPU를 할당하여 실행
• 반면, 컨테이너는 필요할 때만 RAM/CPU를 사용하고, 컨테이너 간에 자원을 동적으로 공유