임베디드 스터디 - 가상머신과 컨테이너, RTOS vs GPOS

하이퍼바이저(Hypervisor)

• 하나의 물리 하드웨어 위에서 여러 OS를 동시에 실행할 수 있게 해주는 소프트웨어 계층
• 각 Guest OS는 자신이 하드웨어를 독점하고 있다고 믿으며 동작하도록 설계되어 있음
• 하이퍼바이저의 핵심 역할 : 여러 OS가 요청하는 하드웨어 자원을 안전하게 중재·분배

Trap-and-Emulate

• Guest OS가 HLT, CLI 같은 특권 명령어(Privileged Instruction)을 실행하려 하면

Guest OS가 특권 명령어 실행 시도
        ↓
CPU가 자동으로 트랩 발생
        ↓
하이퍼바이저가 가로챔
        ↓
해당 명령을 안전하게 에뮬레이션하여 결과만 반환

타입1 vs 타입2 하이퍼바이저

타입1 (베어메탈)          타입2 (호스트형)

[Guest OS]               [Guest OS]
[Hypervisor]             [Hypervisor App]
[Hardware]               [Host OS]
                         [Hardware]

• 타입2가 느린 이유 : Guest OS 요청이 하이퍼바이저 앱 → Host OS → 하드웨어 순으로 처리되어 레이어가 많음

	타입1	타입2
Host OS	없음	있음
성능	빠름	느림
예시	VMware ESXi, Xen	VMware Workstation, VirtualBox
용도	서버, 고신뢰성 환경	개발자 로컬 환경

KVM(Kernel-based Virtual Machine)

• Linux 커널 안에 하이퍼바이저 기능이 모듈로 내장된 형태

형태 : Host OS(Linux)가 존재              → 타입2처럼 보임
동작 : 커널 모듈이므로 하드웨어 직접 접근  → 타입1처럼 동작
공식 분류 : 타입 1

• “타입1의 성능 + 타입2의 편의성”을 동시에 갖는다고 볼 수 있음

VM vs 컨테이너(Docker)

• 컨테이너는 Guest OS 커널을 따로 갖지 않고 Host OS 커널을 공유

VM                          컨테이너

[App]                       [App A] [App B]
[Guest OS (커널 포함)]       [Container Runtime]
[Hypervisor]                [Host OS 커널 (공유)]
[Hardware]                  [Hardware]

• 컨테이너가 가벼운 이유 : OS 커널을 따로 포함하지 않기 때문

Linux 커널에서 컨테이너 격리를 담당하는 두 기능:

• namespace : 프로세스·네트워크·파일시스템 등의 격리된 뷰 제공
• cgroup : CPU·메모리 등 자원 사용량 제한

	VM	컨테이너
커널	Guest OS마다 개별 보유	Host OS 커널 공유
격리 수준	완전한 OS 수준	프로세스·네트워크·파일시스템
이미지 크기	GB 단위	MB 단위
기동 속도	수십 초	수 초 이내

RTOS vs GPOS

• GPOS(Linux 등)는 처리량 최대화를 목표로 설계 → 특정 태스크가 정확히 언제 실행될지 보장 불가
• RTOS는 데드라인 보장을 목표로 설계 → 데드라인 미스 없음

GPOS 스케줄러 : 전체 처리량 최대화 → 실행 시점 예측 불가
RTOS 스케줄러 : 우선순위 기반 선점 → 실행 시점 보장

	RTOS	GPOS
설계 목표	데드라인 보장	처리량 최대화
응답 시간	수 μs~ms, 예측 가능	수 ms~수백ms, 예측 불가
스케줄링	우선순위 기반, 선점 보장	공정성 중심 (CFS)
예시	FreeRTOS, VxWorks, QNX	Linux, Windows

실무 역할 분담 (위성 OBC 예시)

물리 하드웨어
    ├── RTOS  → 자세 제어, 센서 샘플링  (타이밍 critical)
    └── Linux → 데이터 로깅, 통신 스택  (처리량 중심)