가상머신·컨테이너·하이퍼바이저

프로세스·스레드·CPU 스케줄링, 가상메모리의 페이지·프레임·오프셋, 시스템 프로그래밍의 보호된 호출 경로가 선수 설명이다.

0. 한 대의 컴퓨터에 여러 실행세계를 만드는 이유

한 서버에서 서로 다른 운영체제와 응용을 함께 실행하거나, 같은 응용을 수십 개의 독립된 단위로 빠르게 배포하려면 물리 중앙처리장치(Central Processing Unit, CPU)·메모리·장치를 그대로 한 사용자에게만 묶어 두기 어렵다. 그렇다고 단순히 여러 프로그램을 동시에 실행하는 것만으로는 각 프로그램이 어떤 자원을 보고, 얼마나 사용할 수 있으며, 어디까지 서로의 실패를 막아 주는지 설명할 수 없다.

가상화는 이 사이에 관리 가능한 논리경계를 만든다. 가상머신은 가상 하드웨어와 독립된 게스트 운영체제를 경계로 삼고, 컨테이너는 하나의 커널을 공유하는 프로세스에 서로 다른 자원 보기를 제공하고, 설정에 따라 사용량을 통제한다. 둘 다 격리와 공유를 제공하지만 격리하는 층, 시작비용, 운영책임과 실패영향이 다르다.

이 절에서는 제품 이름보다 어디에서 자원 요청을 가로채고, 어떤 상태를 따로 보관하며, 무엇을 공유하는가를 읽는다. 이 구조를 이해하면 새로운 하이퍼바이저나 컨테이너 도구가 등장해도 가상머신·컨테이너의 선택축과 실패조건을 다시 만들 수 있다.

가상화: 물리자원과 논리자원 사이에 통제 가능한 매핑을 둔다

가상화(virtualization)는 물리 CPU·메모리·저장장치·네트워크 또는 운영체제 실행환경을 하나 이상의 논리자원으로 보이게 하고, 그 논리자원을 물리자원에 매핑·중재하여 분리·격리·공유하는 기술이다. 논리 CPU 하나가 항상 물리 코어 하나와 일대일로 대응하거나, 가상 디스크 하나가 물리 디스크 하나를 뜻하는 것은 아니다. 현재의 배치와 정책에 따라 대응관계가 달라질 수 있다.

가상화 계층은 네 가지 일을 한다.

1. 추상화: 서로 다른 물리장치의 세부 차이를 일정한 논리 인터페이스 뒤에 둔다.
2. 다중화: 한 물리자원을 여러 논리자원이 시간 또는 공간으로 나누어 사용하게 한다.
3. 격리: 한 논리환경의 주소·권한·장애가 다른 환경과 관리계층에 바로 닿지 않게 경계를 둔다.
4. 중재: 자원 요청을 허용·거부·예약·제한하고 실제 물리자원에 연결한다.

추상화라고 해서 모두 가상화는 아니다. 파일 인터페이스가 저장장치 세부를 숨기는 것은 추상화지만, 여러 독립 실행환경에 별도 CPU·메모리·장치 모습을 제공하고 사용량과 권한을 중재할 때 가상화의 핵심이 드러난다. 가상화의 목적도 이용률 상승 하나가 아니다. 격리, 배포와 복구 단위, 운영 표준화, 다른 운영체제의 공존을 얻는 대신 추가 계층의 성능비용·관리복잡성·공통 장애점을 감수한다.

전체에서 어디인가: 하드웨어 경계와 커널 경계

상자 안의 대상과 화살표의 조건을 함께 읽으세요. 좁은 화면에서는 같은 관계를 세로로 재배치한 도식을 보여 줍니다.

VM-A와 VM-B는 각자의 응용과 게스트 OS를 가지며 가상 CPU·메모리·장치 요청을 하이퍼바이저가 중재한다. 하이퍼바이저와 물리자원은 공통 의존성이다. 원문 초기 개요의 응용 A/B는 실행환경의 예이며 여기서 각 VM의 응용 집합으로 묶었다. 가상 하드웨어는 각 게스트가 보는 인터페이스이며 물리 코어·디스크와 영구 일대일 대응이 아니다.

상자 안의 대상과 화살표의 조건을 함께 읽으세요. 좁은 화면에서는 같은 관계를 세로로 재배치한 도식을 보여 줍니다.

컨테이너는 별도의 게스트 커널이 없는 격리된 프로세스 집합이다. 두 환경의 자원 보기·한도는 다르지만 시스템콜을 처리하는 커널은 같다. namespace는 보기를 나누고 cgroup은 사용량을 통제하며 권한·보안정책도 함께 검사한다. 공유 커널은 공통 신뢰경계이며 격리만 설정했다고 완전한 보안을 보장하지 않는다.

프로세스는 실행 중인 프로그램 단위다. 첫 번째 도식의 VM 실행환경은 자기 운영체제와 가상 하드웨어를 가지고, 두 번째 도식의 컨테이너 실행환경은 별도 커널을 두지 않은 채 호스트 커널이 실행하는 프로세스로 구성된다. 이 차이 때문에 VM은 서로 다른 운영체제를 함께 실행하기 쉽고 커널 경계가 분리되는 반면, 컨테이너는 중복 커널을 줄여 시작과 배포가 가볍지만 공유 커널이 공통 신뢰경계가 된다. 다음 절부터 VM 실행환경과 중재층, 컨테이너 실행환경에 정식 이름을 붙여 작동원리를 설명한다.

먼저 알아둘 것

CPU는 명령을 실행하고, 가상메모리는 프로세스 주소를 물리 메모리 위치와 연결한다. 프로그램은 시스템콜과 입출력(Input/Output, I/O) 경로를 통해 운영체제의 보호된 커널·장치에 접근하며, 파일은 이름을 가진 데이터 단위이고 블록은 저장장치가 읽고 쓰는 고정 크기 단위다. 신뢰경계는 신뢰수준이 다른 주체가 만나는 지점이며, 가상화는 이 다섯 기반을 추상화해 CPU·메모리·장치·프로세스의 격리 경계로 연결한다.

1. 하이퍼바이저와 VM: 가상 하드웨어 위에 독립 운영체제를 둔다

하이퍼바이저(hypervisor)는 물리 CPU·메모리·장치를 가상 하드웨어로 추상화하고 접근을 중재해 여러 가상머신에 제공하는 소프트웨어 또는 펌웨어 계층이다. 가상머신(Virtual Machine, VM)은 하이퍼바이저가 제공하는 가상 하드웨어 위에서 독립된 게스트 운영체제와 응용을 실행하는 격리된 계산환경이다. 게스트 운영체제(Operating System, OS)는 VM 안에서 실행되는 운영체제이고, 호스트는 하이퍼바이저와 VM을 수용하는 물리 시스템이다.

가상머신 모니터(Virtual Machine Monitor, VMM)는 게스트의 가상 CPU 상태와 메모리·장치 접근을 관리하는 논리 기능을 가리키며 하이퍼바이저의 동의어로도 사용된다. 문헌과 제품에 따라 두 용어의 범위가 조금씩 다르므로 답안에서는 물리자원 중재와 VM 실행상태 관리계층이라는 역할을 먼저 정의한다.

구체적인 구현 예로 Linux KVM에서는 사용자 공간의 VMM이 /dev/kvm 장치 파일을 열고 입출력 제어 호출(ioctl)을 순서대로 보내 VM, 가상 CPU와 장치를 생성·제어한다. 이는 하이퍼바이저가 해야 할 일을 이해하기 위한 한 구현 사례이지 모든 하이퍼바이저가 같은 파일과 호출을 사용한다는 뜻은 아니다.

VM마다 가상 CPU의 레지스터와 실행상태, 메모리 매핑, 가상장치 상태가 따로 관리된다. 한 VM이 중단되었다가 다시 실행될 수 있는 이유도 이 논리상태를 보존·복원하기 때문이다. 다만 VM의 격리는 자동으로 완전한 보안을 보장하지 않는다. 하이퍼바이저, VM의 생성·설정·중지 명령을 처리하는 관리면, 공유 장치와 네트워크가 모든 VM이 의존하는 공통 경계다.

Type 1과 Type 2: 하이퍼바이저가 놓인 위치를 본다

이 분류는 배치 위치를 이해하는 공통 모형이지 모든 구현을 두 상자에 완벽히 넣는 법칙은 아니다. 실제 제품은 전용 관리 VM, 펌웨어 기능, 호스트 커널 모듈을 함께 사용할 수 있다. 시험에서는 제품 이름보다 누가 장치 드라이버와 자원정책을 소유하는가, 어떤 계층이 공통 장애점인가를 설명한다.

CPU 가상화: 게스트 스케줄러와 하이퍼바이저 스케줄러가 이어진다

VM에 보이는 CPU 실행단위를 가상 CPU(virtual CPU, vCPU)라고 한다. vCPU 하나는 물리 코어 하나의 영구 소유권이 아니라, 하이퍼바이저가 물리 CPU 시간에 배치하는 실행상태와 스케줄링 단위다.

상자 안의 대상과 화살표의 조건을 함께 읽으세요. 좁은 화면에서는 같은 관계를 세로로 재배치한 도식을 보여 줍니다.

게스트 OS는 응용 스레드를 vCPU 0·1의 실행상태에 배치하고, 호스트 하이퍼바이저는 준비된 vCPU 대기열에서 물리 코어 0·1의 실행시간을 배분·선점·이동한다. 같은 종류의 vCPU와 코어는 두 개씩 묶어 표시했으며 고정 일대일 연결을 뜻하지 않는다. 게스트의 준비 스레드도 해당 vCPU가 물리시간을 받지 못하면 진행하지 못한다. 대기열 용량이나 서비스율 수치는 원문에 없으므로 새로 가정하지 않는다.

첫 번째 스케줄링은 게스트 운영체제가 프로세스 안의 실행흐름인 스레드를 vCPU에 배치하는 과정이고, 두 번째는 하이퍼바이저가 실행 가능한 vCPU를 물리 CPU에 배치하는 과정이다. 게스트에서 실행 가능 상태인 스레드도 그 vCPU가 물리 CPU를 받지 못하면 실제로 진행하지 못한다. vCPU 총수와 동시 부하가 물리 CPU 능력을 넘으면 준비 대기, 응답지연과 시간 변동이 커질 수 있다.

하드웨어 가상화 지원이 있는 시스템에서는 많은 일반 명령이 물리 CPU에서 직접 실행된다. 게스트가 호스트 전체 상태를 바꿀 수 있는 민감한 동작을 하거나 하이퍼바이저가 가로채도록 설정한 사건이 발생하면 제어가 하이퍼바이저로 안전하게 넘어간다. 하이퍼바이저는 권한과 가상상태를 확인하고 동작을 모의 실행하거나 상태를 갱신한 뒤 게스트를 재개한다. 모든 명령을 소프트웨어로 한 줄씩 해석하는 것이 아니며, 직접 실행된다고 해서 게스트가 호스트 권한을 얻는 것도 아니다.

실패는 두 층을 함께 보아야 한다. 게스트는 CPU가 충분하다고 생각하지만 하이퍼바이저 대기열이 길 수 있고, 자주 선점된 vCPU가 잠금을 쥐고 있으면 다른 vCPU의 작업도 기다린다. 평균 CPU 사용률만 보지 말고 vCPU 대기시간, 물리 CPU 포화, 문맥전환·이동, 서비스 응답시간과 처리량을 같은 시간축에서 확인한다.

2. 메모리와 I/O 가상화: 주소와 장치 접근을 두 경계에서 중재한다

두 단계 주소변환: 게스트가 보는 물리주소도 아직 논리주소다

게스트 응용은 게스트 가상주소를 사용한다. 게스트 운영체제의 주소 대응표인 페이지 테이블은 이를 VM에 배정된 것처럼 보이는 게스트 물리주소로 바꾸고, 하이퍼바이저가 관리하는 두 번째 매핑은 게스트 물리주소를 실제 기계 물리주소로 바꾼다.

상자 안의 대상과 화살표의 조건을 함께 읽으세요. 좁은 화면에서는 같은 관계를 세로로 재배치한 도식을 보여 줍니다.

4KiB 페이지에서 오프셋 0x123은 두 단계 모두 유지된다. 1단계는 게스트 권한을, 2단계는 VM 할당·격리 권한을 검사한다. 최종주소는 실제 물리 메모리 위치이며 두 단계가 모두 허용한 접근만 완료된다. 같은 숫자를 사용해도 VM-A와 VM-B의 두 번째 매핑 문맥은 다르다.

현행 프로세서는 두 단계 탐색을 하드웨어로 결합하고 최근 최종 변환을 빠른 변환기록에 저장할 수 있다. 첫 단계의 부재나 권한 위반은 보통 게스트 운영체제가 처리하고, 두 번째 단계에서 VM에 배정되지 않은 메모리 접근이 발견되면 하이퍼바이저가 개입한다. 두 단계 중 하나라도 쓰기·실행을 허용하지 않으면 접근은 성공하면 안 된다.

이 구조는 VM마다 같은 게스트 물리주소 숫자를 사용해도 서로 다른 기계 메모리에 연결할 수 있게 한다. 반대로 오래된 변환기록을 잘못 재사용하거나 VM 할당범위를 넘는 매핑을 만들면 다른 VM 또는 관리계층의 메모리에 닿는 심각한 격리 실패가 된다. 메모리를 실제보다 많이 약속하는 오버커밋, 회수와 교환은 다음 절의 자원풀 설계에서 다루며, 여기서는 할당되지 않은 주소는 변환되지 않는다는 경계를 잡는다.

예를 들어 페이지 크기 4KiB에서 VM-A와 VM-B의 게스트 가상주소가 모두 0x4123이고, 각 게스트의 1단계 표가 이를 게스트 물리주소 0x2123으로 바꾼다고 하자. VM-A의 2단계는 게스트 프레임 2를 기계 프레임 100으로, VM-B는 기계 프레임 200으로 연결한다. 그러면 최종주소는 각각 100×4096+0x123=0x64123, 200×4096+0x123=0xC8123으로 달라진다. 오프셋 0x123은 두 단계 내내 유지되지만 VM별 매핑 문맥은 다르다.

VM-A 게스트의 1단계 표가 쓰기를 허용해도 2단계 매핑이 읽기 전용이면 그 쓰기는 완료되지 않고 하이퍼바이저 처리경로로 넘어간다. 하이퍼바이저가 명시적으로 복구 가능한 조건으로 판정해 매핑을 바꾸고 재시도하지 않는 한 해당 접근은 거부된다. 같은 숫자의 게스트 주소가 곧 같은 기계 메모리나 접근권한을 뜻하지 않는다는 것이 이 예의 결론이다.

표기를 실제 숫자로 풀면 0x는 16진수 표시이고, 0x4123=4×4096+0x123이므로 페이지 번호 4·오프셋 0x123이다. 1단계가 페이지 4를 게스트 프레임 2로, 2단계가 그 프레임을 기계 프레임 100으로 바꾼 것이 VM-A의 경로다. VM-A의 2단계 매핑만 기계 프레임 101로 바꾸면 최종주소는 무엇인가? 자체 조건 변경 연습이므로 먼저 계산·판정을 적는다.

단계 풀이와 잘못된 추론 교정 보기

101×4096+0x123=0x65123이다. VM-B 주소는 0xC8123 그대로다. 둘이 같은 가상주소를 쓴다는 이유로 VM-B도 함께 바뀐다고 답했다면, VM별 두 번째 매핑을 구별하지 않은 것이므로 위 두 경로를 다시 따라간다.

복습: 두 단계 주소변환과 VM별 문맥. 오프셋을 고정한 채 각 VM의 프레임 매핑만 따라가면 교정된다.

I/O 가상화: 호환성·성능·격리·이동성의 절충

VM 안의 응용이 파일이나 네트워크를 요청하면 먼저 게스트 운영체제의 시스템콜과 장치 드라이버를 지난다. 하이퍼바이저가 모든 시스템콜을 직접 처리하는 것은 아니다. 게스트 드라이버가 가상장치에 보낸 요청이 하이퍼바이저의 장치 중재를 거쳐 실제 저장장치·네트워크로 전달된다.

가상 디스크는 물리 디스크 한 개의 복사본일 필요가 없다. 파일, 여러 물리 저장공간을 하나처럼 묶은 논리 볼륨, 원격 블록장치처럼 여러 물리 저장경로 위에 만들어질 수 있다. 가상 네트워크 인터페이스도 가상 스위치·정책·물리 인터페이스를 거쳐 외부로 나간다. 따라서 VM 안의 지연만으로 원인을 정하지 말고 게스트 대기열, 하이퍼바이저 중재, 호스트 저장·네트워크 대기열과 실제 장치 상태를 끝까지 추적한다.

빠른 방식이 언제나 정답도 아니다. 직접할당은 높은 성능을 얻는 대신 VM 이동과 장치 공유를 어렵게 할 수 있고, 모의실행은 호환성을 얻는 대신 중재비용이 커질 수 있다. 실행할 업무인 워크로드의 지연·처리량 목표, 신뢰경계, 장애복구와 이동 요구를 같은 축에 놓고 선택한다.

3. 컨테이너: 커널은 공유하고 프로세스의 보기와 한도를 나눈다

컨테이너(container)는 호스트 운영체제 커널을 공유하면서 격리된 자원 보기를 제공받고 사용량 통제를 설정할 수 있는 하나 이상의 프로세스 실행단위다. 운영체제 수준 격리는 커널이 프로세스마다 보이는 식별자·파일시스템·네트워크 등의 범위를 나누고 CPU·메모리·I/O 사용을 통제하여 서로 다른 실행환경처럼 보이게 하는 구조다.

컨테이너 안에서 보이는 프로세스 번호 1이 호스트 전체의 첫 프로세스라는 뜻은 아니다. 컨테이너가 별도 호스트 이름과 네트워크 인터페이스를 보더라도 실제 처리는 같은 호스트 커널이 수행한다. 따라서 컨테이너에는 일반적으로 별도의 게스트 커널이 없고, 호스트 커널과 호환되는 응용 실행파일과 라이브러리를 실행한다.

공유 커널은 시작시간과 메모리 중복을 줄이는 데 유리하지만 가장 중요한 공통 신뢰경계다. 컨테이너 프로세스가 커널 취약점이나 과도한 권한을 이용해 경계를 넘으면 같은 호스트의 다른 컨테이너와 호스트에 영향을 줄 수 있다. 이름공간과 제어그룹만 설정했다는 사실을 완전한 보안의 증명으로 쓰지 않는다.

namespace와 cgroup: 무엇이 보이는가와 얼마나 쓰는가를 나눈다

이름공간(namespace)은 프로세스가 보는 커널 자원과 식별자 범위를 분리하는 기능이다. Linux에서는 프로세스 식별자(Process Identifier, PID), 파일시스템을 특정 경로에 연결하는 마운트, 네트워크, 프로세스 간 통신, 호스트 이름, 사용자 식별자 등의 보기를 나눌 수 있다. 모든 컨테이너가 모든 종류의 이름공간을 반드시 사용하는 것은 아니며, 어떤 보기를 공유하도록 설정했는지가 실제 경계를 결정한다.

제어그룹(control group, cgroup)은 프로세스 집합을 계층적으로 조직하고 CPU·메모리·I/O 같은 자원의 사용량을 측정·배분·제한하는 Linux 커널 기능이다. CPU 가중치와 상한, 메모리 한도, I/O 배분을 지정할 수 있지만, cgroup 자체가 파일·네트워크·권한 보기를 숨기는 기능은 아니다.

공유 호스트 커널은 컨테이너 프로세스의 시스템콜을 받아 다음 네 책임을 함께 적용하고 물리 CPU·메모리·파일·블록·네트워크 접근을 중재한다. 위 공유 커널 구조를 재사용한다.

컨테이너 시스템콜은 별도 게스트 커널을 거치지 않고 공유 호스트 커널에 도달한다. 커널은 프로세스의 이름공간, 사용자·권한, 자원한도와 보안정책을 함께 검사해야 한다. CPU 한도를 두어도 과도한 파일권한이나 호스트 장치 접근을 막지는 못하고, 이름공간을 나누어도 메모리 한도가 없으면 한 컨테이너의 급증이 호스트 전체를 압박할 수 있으므로 두 기능과 최소권한을 함께 쓴다.

보기의 격리와 실제 한도 설정은 별도 확인사항이다. 컨테이너가 생성되었다고 CPU·메모리의 유한한 상한이 자동으로 생기는 것은 아니다. Linux cgroup v2의 cpu.max 기본값 max 100000에서 max는 그 그룹 자체의 CPU 상한이 없다는 뜻이며, 상위 그룹의 제한이나 호스트 경합까지 없다는 뜻은 아니다. 이름공간 격리가 있어도 필요한 자원 제어기가 활성화되었는지와 실제 한도값을 확인한다. 이는 앞의 정의와 뒤의 cgroup 자원한도 부재 실패 사례를 연결하는 설정 전제다.

CPU 한도와 가중치를 숫자로 구별한다. Linux cgroup v2의 CPU 인터페이스에서 fair-class 스케줄러 프로세스에 적용되는 cpu.max 값이 50000 100000이면 단위는 마이크로초이고, 100ms 주기당 그룹 전체가 사용할 CPU 시간의 상한은 50ms다. 비율 50000/100000=0.5는 한 코어 시간의 절반에 해당하는 사용 예산이지, 전용 반 코어나 응답시간의 최소보장이 아니다. 같은 부모 아래 다른 상한 없이 계속 CPU를 요구하는 두 그룹의 cpu.weight가 100과 200이면 배분 기준 비율은 100/300=1/3, 200/300=2/3다. 한쪽이 CPU를 쓰지 않으면 가중치는 남은 자원을 놀리도록 강제하지 않는다. 실제 실행량은 호스트 부하·상위 제한·실행 가능한 스레드 수에도 영향을 받으므로 이 비율만으로 처리량을 보증하지 않는다.

이미지·런타임·컨테이너: 설계도, 실행도구, 실행상태를 구분한다

오픈 컨테이너 이니셔티브(Open Container Initiative, OCI)는 컨테이너 이미지 형식과 런타임 동작의 공개 사양을 관리하는 조직이다. OCI라는 이름은 특정 컨테이너 제품이나 실행 중 컨테이너 자체를 뜻하지 않는다.

이미지 구성목록·설정·파일 층을 풀고 마운트하면 루트 파일시스템과 실행설정이 된다. 이 준비 작업과 실제 실행은 구별한다. OCI 저수준 런타임이 직접 소비하는 것은 이미지 저장소의 이미지가 아니라 파일시스템 번들(bundle)이다. 번들은 실행 설정을 담은 config.json과, 설정에 루트 경로가 지정된 경우 그 루트 파일시스템을 포함한다. 이미지 내려받기·검증·해체는 상위 관리도구가 맡을 수 있고, 저수준 런타임은 준비된 번들의 설정으로 namespace·cgroup·프로세스와 생명주기를 관리한다. 위의 역할 비교표를 재사용하여 배포 템플릿과 실행도구·현재 인스턴스의 수명을 구분한다.

이미지를 삭제하지 않아도 컨테이너만 중지·삭제할 수 있고, 같은 이미지에서 만든 두 컨테이너의 실행상태는 서로 다르다. 컨테이너의 쓰기층은 실행 인스턴스와 함께 사라질 수 있으므로 업무 데이터의 영속성을 자동으로 가정하지 않는다. 장기 보존 데이터는 컨테이너 수명과 분리되고 백업·접근통제가 명시된 저장공간인 외부 볼륨이나 데이터 서비스에 두고, 이미지에는 실행에 필요한 읽기 전용 구성과 프로그램을 담는 경계를 우선한다.

이미지 내용이 불변이라는 말과 태그가 고정이라는 말은 다르다. OCI Distribution 사양의 정의에서 태그(tag)는 이미지 구성목록을 가리키는 사람이 읽을 수 있는 이름이다. 예를 들어 api:latest가 처음에는 내용 A를 가리키다가 이후 내용 B를 가리키도록 갱신될 수 있다. 이미 A로 생성된 실행 인스턴스의 파일과 프로세스가 태그 변경만으로 B로 교체되지는 않는다. 재배포할 때 같은 내용을 식별하려면 사용한 다이제스트(digest)를 기록·검증한다. 다이제스트는 내용의 바이트를 식별하는 해시이며, 같은 이름의 태그와 역할이 다르다. 내용 일치 확인은 취약점 부재나 실행권한의 안전성 보증까지 포함하지 않는다.

4. VM과 컨테이너 선택: 밀도 하나가 아니라 신뢰경계와 운영책임을 본다

같은 축으로 비교한다

컨테이너가 항상 VM보다 빠르거나, VM이 언제나 더 안전하다고 단정하지 않는다. 실제 성능은 시스템콜·I/O 비율, 메모리 지역성, 자원경합과 설정에 달려 있고, 격리는 구현·권한·패치·관리면 보호에 달려 있다. 다만 별도 게스트 커널을 가지는 VM과 공유 커널을 쓰는 컨테이너의 신뢰경계 차이는 선택의 출발점이다.

실패는 공유계층과 운영책임에서 시작한다

운영책임도 격리계층마다 다르다. VM에서는 하이퍼바이저 운영자가 게스트 OS 패치까지 자동으로 책임지는 것이 아니고, 컨테이너에서는 이미지 담당자가 호스트 커널을 갱신하는 것이 아니다. 하이퍼바이저/호스트, 게스트 OS, 컨테이너 런타임, 이미지와 응용, 데이터와 백업의 소유자·패치기한·장애연락과 복구절차를 명시한다.

VM 안의 컨테이너: 둘 중 하나만 고를 필요는 없다

아래 결합 구조 도식과 원래 여섯 질문이 선택의 운영비용·상태·인력까지 확인한다.

서로 신뢰하지 않는 고객이나 보안등급을 나눌 때는 VM을 큰 격리경계로 두고, 같은 고객·등급 안의 서비스를 컨테이너로 패키징할 수 있다. 이 구조는 VM의 게스트 커널 비용과 컨테이너 운영계층을 모두 가지므로 무조건 더 좋은 것은 아니다. VM 수, 게스트 패치, 이미지 수, 런타임·관측과 네트워크 정책이 함께 늘어난다.

선택은 여섯 질문으로 좁힌다.

1. 서로 다른 OS·커널 또는 특수 장치가 필요한가.
2. 실행주체가 서로 신뢰하는가, 법적·보안상 분리수준은 얼마인가.
3. 시작시간·배포빈도·실행밀도 중 무엇이 중요한가.
4. CPU·메모리·I/O 병목과 성능변동을 어느 정도 허용하는가.
5. 상태는 실행단위 안에 남는가, 외부 데이터 서비스로 분리되는가.
6. 하이퍼바이저·게스트·커널·런타임·이미지를 운영할 인력과 증적이 있는가.

큰 설계문제 전에 한 조건씩 바꿔 보자. 같은 Linux 커널을 공유하는 사내 API 컨테이너 두 개에 메모리 한도만 설정했는데, 한 프로세스가 호스트의 민감한 파일을 읽을 수 있다고 하자. 메모리 한도를 더 낮추면 이 파일 접근 문제가 해결되는가? 사용량 한도는 파일 권한이나 노출된 마운트를 바꾸지 않으므로 해결되지 않는다. 실제 접근권한과 마운트·보안정책을 점검해야 하며 namespace·cgroup의 책임 표로 돌아가 구별한다. 새 응용이 반드시 다른 OS의 커널 서비스를 필요로 한다면 같은 커널 위에서 이미지 파일만 교체해 해결할 수 있는가? 컨테이너 이미지는 별도 커널을 만들어 주지 않으므로 필요한 게스트 OS를 지원하는 VM 경계를 검토한다. 먼저 바뀐 요구가 사용량인지·보기/권한인지·커널인지 분류한 뒤 구조를 고르는 연습이다.

가상화의 핵심 학습 논점

가상화를 설명할 때는 제품 종류를 나열하는 데 그치지 않고 다음 네 논점을 연결한다.

1. 정의·목적·범위: 물리자원과 논리자원의 매핑·중재·격리·공유, 하드웨어 수준과 운영체제 수준의 경계
2. 구조·작동원리: 하이퍼바이저와 VM의 CPU 스케줄링·두 단계 메모리 변환·I/O 중재, 컨테이너의 namespace·cgroup·공유 커널
3. 실패·통제: 자원경합, 하이퍼바이저·공유 커널 공통위험, 과도한 권한, 이미지·관리면·관측 실패와 통제
4. 비교·선택·적용: VM·컨테이너 동일축 비교, 단독 또는 결합 구조와 요구별 결론

다음 절에서는 자원풀·배치·오버커밋으로 이어가고, 회복성 설계에서는 고가용성·재해복구를 다룬다. 여러 컨테이너를 배치·확장·복구하는 오케스트레이션과 Kubernetes의 상세 구성은 클라우드 네이티브 분야에서 이어서 공부한다.

5. 기출 후보와 시험 답안 전환

기출은 문항 단위로 연결하되 아직 승인하지 않는다

표는 기존 기출 장부의 문항 식별자·연도·배점과 요구를 사람이 검토할 수 있게 요약한 것이다. 각 문항의 공식 원문 대조, 공식 범위와의 연결, 현재 답안 목차와의 연결은 아직 승인되지 않았다. 따라서 본문의 자체 제작 10점·25점 문제는 기출 원문이나 모범답안을 복제한 것이 아니다.

자동 매핑 오염과 전문영역을 격리한다

자동 군집명이나 자동 현행성 라벨을 승인근거로 사용하지 않는다. 직접 문항은 원문·요구동사·배점·기술상태를 확인한 뒤 직접, 보조, 레거시 현대화, 격리 중 하나로 사람이 승인해야 한다.

시험에서는 어떻게 묻는가: 10점

다음은 이 절의 본문만으로 풀 수 있게 만든 자체 제작 문제다.

하이퍼바이저와 가상머신을 정의하고, CPU·메모리·입출력 가상화의 작동원리와 주요 실패통제를 설명하시오.

정의에서는 하이퍼바이저와 VM을 바꾸어 쓰면 안 된다. 작동원리는 가상 CPU 스케줄링, 게스트 가상주소에서 기계 물리주소까지의 두 단계 변환, 장치 모의실행·가상화 인지형 I/O·직접할당의 경로를 요구한다. 실패통제는 성능저하만이 아니라 격리·관리면·공통 장애를 포함해야 한다.

답안 목차·풀이·교정 근거 보기

10점 답안 목차

1. 정의와 구조
   • 하이퍼바이저, VM, 게스트 OS, Type 1·Type 2 경계
2. 자원별 작동원리
   • 게스트 스케줄링과 vCPU–물리 CPU 스케줄링
   • 게스트 가상→게스트 물리→기계 물리 주소변환
   • 장치 모의실행·가상화 인지형 I/O·직접할당
3. 실패조건과 통제
   • CPU·메모리·I/O 경합, 관리면·격리 실패, 관측
4. 적용 결론
   • 호환성·성능·격리·운영·이동 요구에 따른 선택

10점 답안 도식

응용은 게스트 OS를 통해 가상 CPU·메모리·장치를 요청하고 하이퍼바이저가 이를 중재한다. CPU는 두 스케줄링 주체, 메모리는 기존 VM별 두 단계 실제주소 도식, I/O는 기존 세 방식 비교로 각 경로를 확인한다. 게스트 드라이버 뒤 모의실행·인지형 I/O·직접할당을 통해 물리장치에 닿으며 격리·할당·권한·대기시간·실패상태를 관측한다. VM과 하이퍼바이저를 같은 노드로 합치지 않는다.

10점 모범답안

하이퍼바이저는 물리 CPU·메모리·장치 접근을 중재하여 여러 VM에 가상 하드웨어를 제공하는 계층이고, VM은 그 가상 하드웨어 위에서 독립된 게스트 운영체제와 응용을 실행하는 격리된 계산환경이다. Type 1은 하드웨어 위에서 자원을 직접 관리하고, Type 2는 일반 호스트 운영체제의 장치·서비스를 이용하는 호스트 운영체제 이용형 구조다. 실제 구현은 혼합될 수 있으므로 공통 관리계층과 장치 소유자를 함께 표시한다.

CPU 가상화에서는 게스트 운영체제가 스레드를 vCPU에 배치하고 하이퍼바이저가 실행 가능한 vCPU를 물리 CPU 시간에 다시 배치한다. 많은 일반 명령은 하드웨어에서 직접 실행되지만, 호스트 전체 상태에 영향을 줄 수 있는 민감한 사건은 하이퍼바이저로 제어가 넘어가 권한과 가상상태를 검사한 뒤 처리된다. vCPU는 물리 코어의 영구 소유권이 아니므로 동시 부하가 물리능력을 넘으면 대기와 응답시간 변동이 커진다.

메모리는 게스트 페이지 테이블이 게스트 가상주소를 게스트 물리주소로 바꾸고, 하이퍼바이저의 두 번째 매핑이 이를 기계 물리주소로 바꾼다. 두 단계 권한이 모두 허용해야 접근할 수 있으며 VM 범위를 넘는 매핑과 오래된 변환 재사용을 막아야 한다. I/O는 게스트 시스템콜과 드라이버를 거친 뒤 장치 모의실행, 전용 드라이버와 공유 대기열을 쓰는 가상화 인지형 방식, 물리장치 직접할당 중 하나로 연결한다. 호환성은 모의실행, 낮은 중재비용은 직접할당에 유리할 수 있으나 이동성과 격리비용이 달라진다.

통제는 vCPU 대기·메모리 압박·I/O 지연과 서비스 응답시간을 같은 시간축으로 관측하고 최소보장·상한·예비분을 둔다. 관리면을 분리하고 최소권한·강한 인증·패치·감사로그를 적용하며, 장치 직접할당은 하드웨어 주소범위와 복구 가능성을 검증한다. 최종 선택은 호환성·성능·격리·운영책임·이동 요구를 함께 만족하는지를 기준으로 결정한다.

시험에서는 어떻게 묻는가: 25점

다음 역시 기출을 복제하지 않은 자체 제작 문제다.

기존 운영체제에 묶인 레거시 시스템, 외부 고객 코드를 실행하는 분석 서비스, 응용 프로그래밍 인터페이스(Application Programming Interface, API)를 빠르게 배포하는 사내 서비스를 하나의 물리 인프라에서 운영하려 한다. VM과 컨테이너의 작동원리·동일축 비교를 바탕으로 결합 가상화 구조를 설계하고, 자원경합·보안·운영 실패 및 검증방안을 설명하시오.

이 문제는 VM이냐 컨테이너냐라는 한 줄 선택을 요구하지 않는다. 신뢰경계와 OS 요구로 큰 격리단위를 정하고, 그 안의 배포단위를 결정한 뒤 CPU·메모리·I/O 경로, 컨테이너 공유 커널, 운영책임과 검증을 하나의 구조로 연결해야 한다. 외부 고객 코드와 사내 코드의 신뢰수준을 같게 두거나, 모든 상태를 컨테이너 쓰기층에 두면 요구를 놓친다.

답안 목차·풀이·교정 근거 보기

25점 답안 목차

1. 요구·경계와 가상화 정의
   • OS 다양성, 외부/내부 신뢰경계, 배포·상태·성능 목표
2. VM·컨테이너 구조와 동일축 비교
   • 가상화 층, 커널, 실행단위, 밀도, 격리, 성능, 운영책임
3. 결합 목표구조
   • 레거시·외부 고객별 VM, VM 내부 API 컨테이너, 데이터 외부화
4. 작동원리
   • vCPU 이중 스케줄링, 두 단계 메모리, I/O 중재
   • namespace·cgroup·공유 커널, 이미지·런타임·컨테이너
5. 실패·보안·운영 통제
   • 자원경합, 관리면·커널 경계, 권한·이미지·패치·관측
6. 검증과 결론
   • 부하·경계이탈·장애·복구 시험과 요구별 선택근거

25점 답안 도식

상자 안의 대상과 화살표의 조건을 함께 읽으세요. 좁은 화면에서는 같은 관계를 세로로 재배치한 도식을 보여 줍니다.

레거시 VM은 전용 게스트 OS, 외부 고객-A VM은 별도 신뢰경계, 사내 서비스 VM은 게스트 커널을 공유하는 API-A·API-B 컨테이너를 둔다. 세 VM의 가상 CPU·메모리·I/O는 공통 하이퍼바이저가 중재한다. 사내 VM 내부 namespace·cgroup 경계는 VM 간 경계와 다르다. 관리면 최소권한·패치·감사·이미지 검증, 서비스 지연/vCPU 대기/메모리 압박/I/O 지연 관측 및 경계이탈·호스트 장애·재생성·데이터 복원 시험은 아래 원문 완성 답안의 별도 통제다. 영속 데이터의 외부화도 그 답안을 보존하며 이 실행구조 그림에서 저장 토폴로지를 새로 가정하지 않는다.

25점 모범답안

가상화는 물리 CPU·메모리·저장·네트워크 또는 운영체제 실행환경을 논리자원으로 보이게 하고 이를 물리자원에 매핑·중재하여 분리·격리·공유하는 기술이다. 본 사례의 핵심 요구는 서로 다른 게스트 OS를 유지하는 레거시 호환성, 외부 고객 코드와 내부 코드의 신뢰경계, API의 빠른 배포, 물리자원 공유와 상태 보존이다. 따라서 실행밀도 하나가 아니라 OS·신뢰·상태·성능·운영책임을 먼저 분류한다.

목표구조는 하이퍼바이저 위에 레거시 전용 VM, 외부 고객 또는 보안등급별 VM, 사내 서비스 VM을 둔다. 레거시 VM은 필요한 게스트 OS와 응용을 함께 격리한다. 외부 고객 코드는 내부 서비스와 커널을 공유시키지 않고 고객 또는 신뢰등급별 VM 경계에 둔다. 사내 API는 같은 게스트 커널을 신뢰할 수 있는 범위에서 컨테이너로 배포한다. 영속 데이터는 컨테이너 쓰기층에 의존하지 않고 수명·백업·접근통제가 정해진 외부 볼륨이나 데이터 서비스로 분리한다.

VM 경계에서 하이퍼바이저는 게스트 운영체제에 가상 CPU·메모리·장치를 제공한다. 게스트 운영체제가 스레드를 vCPU에 배치하고 하이퍼바이저가 vCPU를 물리 CPU에 다시 배치하므로, vCPU 수가 많다는 사실을 물리 성능 보장으로 해석하지 않는다. 메모리는 게스트 가상주소를 게스트 물리주소로 바꾸는 1단계와 이를 기계 물리주소로 바꾸는 2단계를 거치며 두 권한검사를 모두 통과해야 한다. I/O는 호환성이 중요한 장치 모의실행, 전용 드라이버와 공유 대기열을 쓰는 가상화 인지형 방식, 낮은 중재비용을 위한 직접할당을 호환성·성능·격리·이동성으로 선택한다.

컨테이너 경계에서는 호스트가 아니라 해당 VM의 게스트 커널을 여러 API 컨테이너가 공유한다. namespace가 프로세스·마운트·네트워크·사용자 등의 보기를 나누고 cgroup이 CPU·메모리·I/O의 계측·가중치·상한을 제공한다. 이미지는 파일시스템 층과 실행설정을 담은 불변 템플릿, 런타임은 이미지에서 실행환경과 생명주기를 만드는 도구, 컨테이너는 현재 실행되는 프로세스와 격리·자원상태다. 따라서 이미지를 검증했다고 실행권한과 호스트 마운트가 자동으로 안전해지는 것은 아니며 최소권한·자원한도·보안정책을 함께 둔다.

주요 실패는 물리능력을 넘는 vCPU·메모리·I/O 약속, 하이퍼바이저와 관리면 침해, 공유 커널 경계이탈, 특권 컨테이너와 호스트 경로 노출, 오래된 이미지와 비밀정보 포함, 계층별 패치책임 누락이다. 중요 VM에는 최소보장과 예비분을 두고 외부 고객 VM을 다른 내부 서비스와 분산한다. 관리면을 업무망과 분리하고 강한 인증·최소권한·감사로그를 적용하며 하이퍼바이저·게스트·커널·런타임·이미지별 소유자와 패치기한을 지정한다. 이미지 출처·내용 식별과 취약점을 확인하고 비밀정보는 실행 시 외부에서 전달한다.

검증은 정상 평균부하뿐 아니라 동시 최대부하와 한 물리호스트의 가용자원 감소를 포함한다. 서비스 응답시간·처리량·오류와 vCPU 대기, 물리 CPU 포화, 메모리 압박, 게스트·호스트 I/O 지연, 컨테이너 자원제한·종료를 공통 시간축과 워크로드 식별자로 연결한다. 외부 컨테이너가 다른 VM·호스트 자원에 접근할 수 없는지, 특권·마운트·장치 설정이 거부되는지 시험하고 VM 재시작·컨테이너 재생성·데이터 복원 절차를 검증한다. 이 구조는 VM으로 OS와 큰 신뢰경계를 분리하고 컨테이너로 신뢰영역 내부의 배포단위를 가볍게 하므로 요구에 부합하지만, 두 운영계층의 비용을 지표와 책임으로 계속 통제해야 한다.

근거와 현행성

가상화·전가상화·VM·게스트 경계와 통합의 이점·위험은 미국 국립표준기술연구소(NIST)의 SP 800-125, Guide to Security for Full Virtualization Technologies의 Executive Summary와 §2를 대조했다. 하이퍼바이저의 CPU·메모리·장치 중재, Type 1·Type 2 위치축과 기준기능은 NIST SP 800-125A Revision 1, Security Recommendations for Server-based Hypervisor Platforms의 Executive Summary, §1.1과 Appendix A를 대조했다. 두 문서는 전가상화와 서버 하이퍼바이저에 한정된 안정적 구조 근거이며 특정 제품의 성능수치나 모든 데스크톱·임베디드·컨테이너 가상화의 동일 구현원리로 일반화하지 않는다.

VM과 컨테이너의 커널 경계, 이미지·런타임·컨테이너의 역할, namespace·cgroup, 공유 커널 위험과 통제는 NIST SP 800-190, Application Container Security Guide의 §§2.1–2.3, §3.5.2, §4와 Appendix D를 대조했다. 이 문서는 2017-09 최종본이므로 안정적인 구조·위험 경계만 사용했고 당시 제품·운영체제 예시는 현행 제품 사실로 옮기지 않았다.

저수준 컨테이너 실행구성과 생명주기의 규격 범위는 Open Container Initiative의 Runtime Specification v1.3.0을 확인했다. Linux namespace의 자원 보기 분리는 Linux man-pages 6.19의 namespaces(7)의 DESCRIPTION(physical PDF p. 3779), cgroup v2의 프로세스 계층과 자원 배분·제한은 Linux Kernel Documentation의 Control Group v2, /dev/kvm과 파일 기술자·ioctl 제어 흐름은 Linux KVM API 문서를 2026-09-01 기준으로 대조했다. 이 세 Linux 자료는 구현 사례이며 다른 운영체제·런타임·하이퍼바이저의 필수 내부구조로 일반화하지 않는다.

NIST 자료는 출처표시를 하고 표시된 제3자 자료는 별도 권리검토가 필요하다. OCI 사양 저장소는 Apache License 2.0을 표시하며, Linux 커널 문서는 대응 원본 파일의 정확한 소프트웨어 패키지 데이터 교환(SPDX) 라이선스 식별자를 사람 검토 전 확정하지 않았다. 모든 표·도식·답안은 원문 문장·표·그림·화면을 복제하거나 따라 그리지 않고 교재용으로 독자 구성했다. OCI와 Linux의 수시 갱신 자료는 2026-12-01까지 또는 새 버전·문서변경 시 먼저 재검토하고, NIST 문서는 개정·철회 시 재검토한다. 실제 기출 여부와 대표성은 공식 문항 원문을 별도로 확인해야 한다.

30초 정리

1. 가상화는 물리자원을 논리자원으로 매핑·중재해 분리·격리·공유하는 기술이다.
2. VM은 가상 하드웨어와 독립 게스트 OS를 가지며, 하이퍼바이저가 vCPU 스케줄링·두 단계 메모리 변환·I/O를 중재한다.
3. 컨테이너는 공유 커널 위의 프로세스이며 namespace는 자원 보기, cgroup은 사용량 계측·배분·한도를 담당한다.
4. 이미지는 불변 배포 템플릿, 런타임은 실행환경을 만드는 도구, 컨테이너는 현재 실행상태다.
5. VM과 컨테이너는 커널·격리·OS 다양성·밀도·성능·패치·상태·운영책임을 같은 축으로 비교한다.
6. 서로 다른 OS나 큰 신뢰경계는 VM, 같은 신뢰영역의 빠른 배포는 컨테이너가 유리하며 둘을 결합할 수 있다.
7. 자원경합·관리면·공유 커널·과도한 권한·이미지·관측 사각지대를 부하·경계이탈·복구 시험으로 검증한다.

다시 읽을 때는 논리자원 → VM의 하드웨어 경계 / 컨테이너의 커널 경계 → 공유계층의 실패 → 요구별 결합 순서만 먼저 떠올린다. 다음 절에서는 이 논리자원을 컴퓨트·스토리지·네트워크 자원풀로 묶고 배치·오버커밋하는 구조를 배운다.

추가 확인 문제: 자원 예산과 배포 식별을 읽는다. 다음은 자체 연습이다. (1) Linux cgroup v2의 fair-class CPU 제어가 적용되는 그룹에 cpu.max가 25000 100000으로 설정되어 있다. 주기당 CPU 시간 상한과 한 코어 시간 대비 비율을 계산하고, 이것만으로 최소 처리량을 보장할 수 있는지 답하라. (2) api:latest가 A에서 B로 바뀌었다. A로 생성되어 실행 중인 컨테이너가 자동으로 B가 되는가? 재배포 시 A와 동일한 이미지 내용을 지정·검증하려면 무엇을 기록해야 하는가? 실제 호스트 조작은 필요하지 않다.

CPU 한도와 이미지 식별 풀이 보기

(1) 100ms 주기당 그룹 전체의 CPU 시간 상한은 25ms이고 비율은 25000/100000=0.25다. 최대 사용 예산이므로 전용 코어 할당이나 최소 처리량 보장이 아니다. 다른 그룹과의 경합, 상위 한도, 실행 가능한 작업과 서비스 지연을 함께 확인해야 한다.

(2) 태그 변경만으로 기존 컨테이너가 B로 바뀌지는 않는다. A를 식별하는 구성목록의 다이제스트와 필요한 플랫폼 조건을 기록하고 내려받은 내용의 다이제스트를 검증한다. 같은 바이트를 확인하는 것과 이미지의 보안·호스트 커널 호환성·실행권한을 확인하는 것은 별도다.