OS까지 쪼개는 가상화
경계를 세우는 순간 따라오는 매핑과 정책
컨테이너, Docker, Kubernetes
1. 하드웨어 가상화는 도대체 무엇을 가상화한 걸까?
하드웨어 가상화라는 단어를 처음 접하면 보통 비슷한 이미지를 떠올리게 됩니다. CPU나 메모리를 교묘하게 속이는 기술 같은 느낌 말입니다. 하지만 이 개념을 파고들다 보면 정작 중요한 질문은 다른 곳에 있다는 것을 알게 됩니다. 대체 무엇을 하드웨어처럼 보이게 만들고 싶었던 걸까?
저도 처음엔 복잡하게 접근했는데, 파고들수록 오히려 단순한 질문으로 좁혀졌습니다. 바로 한 대의 물리 머신 위에 여러 대의 머신이 있는 것처럼 보이게 만드는 구조입니다. 여기서 말하는 머신은 단순한 프로그램 하나가 아니라, OS까지 포함한 실행 환경 전체를 의미했습니다.
결국 하드웨어 가상화라는 말은, 사실상 OS 단위의 경계를 하나 더 만드는 작업에 가까웠습니다. 근데 여기서 저는 한 가지가 걸렸습니다.
OS를 통째로 올리는 건 너무 무겁지 않았을까?
그냥 프로세스만 잘 돌리면 충분했을 텐데, 왜 굳이 이런 선택을 했을까?
그래서 저는 경계를 어디에 그었는지부터 먼저 따라가봤습니다.
2. 하드웨어 가상화를 왜 쓰게 됐을까?
단순히 “필요해서 썼다”는 설명은 큰 도움이 되지 않았습니다. 구체적으로 어떤 불편함이 우리를 OS까지 통째로 가두는 구조로 이끌었는지 들여다볼 필요가 있었습니다. 그 불편함의 장면들을 복기해 보면 세 가지 키워드가 선명해집니다.
(1) 같이 돌리면 같이 망가지는 순간 (Isolation)
서버 한 대에서 여러 서비스를 돌리다 보면, 한쪽의 자원 폭주가 전체 시스템을 흔들어놓는 장면을 흔히 봅니다. 프로세스 수준에서 주의를 기울이는 것만으로는 해결되지 않는 결함들이 존재했습니다. 그래서 아예 운영 단위를 OS 레벨에서 격리해버리는 선택이 매력적으로 다가왔던 겁니다.
(2) 환경이 다르면 생기는 끝없는 변수 (Illusion)
“내 로컬 PC에서는 잘 되는데요”라는 말이 운영 환경에서 통하지 않을 때의 당혹감은 익숙합니다. OS 버전, 라이브러리, 미세한 설정 차이가 결과값을 바꿨습니다. 결국 프로그램만 옮기는 게 아니라, 그 프로그램이 믿고 있는 환경 자체를 복제해 일관된 실행 환경을 만들어낼 필요가 있었습니다.
(3) 하드웨어가 바뀌면 위쪽도 흔들리는 구조 (Indirection)
서버를 교체하거나 스토리지 구성이 바뀔 때마다 상위 서비스가 영향을 받는다면 운영의 유연성은 떨어질 수밖에 없습니다. 인프라와 서비스 사이의 직접적인 연결을 끊어줄 간접화의 층이 절실해진 지점이었습니다.
그런데 여기서 또 막혔습니다. 격리(Isolation)만 잘하면 되는 것 아닐까? 왜 환상(Illusion)과 간접화(Indirection)는 항상 세트처럼 따라다니는 걸까?
3. 왜 Illusion / Isolation / Indirection은 늘 한 세트일까?
이건 철학의 문제라기보다, 구조를 따라가다 보면 자연스럽게 그렇게 보였습니다. 격리를 위해 경계를 긋는 순간, 연쇄적인 반응이 시작되기 때문입니다.
격리를 하려면 명확한 경계(Boundary)를 세워야 합니다.
경계를 세우고 나면, 그 경계 안에서 보이는 자원과 실제 물리 자원을 연결하는 매핑(Mapping)이 필요해집니다. (이 연결을 상위 레이어 관점에서 보면 환상이 되고, 구조 관점에서 보면 간접화가 됩니다.)
매핑이 생겨 자원을 공유하기 시작하면, 이를 공정하게 나누기 위한 정책(Policy)이 필요해집니다.
격리라는 목표를 세우는 순간, 환상과 간접화, 그리고 정책이 따라오는 것은 매우 자연스러운 흐름이었습니다. 이 과정을 거치면 가상화의 정체가 하나의 명료한 문장으로 정리됩니다.
가상화는 결국 경계(Boundary) + 매핑(Mapping) + 정책(Policy)으로 굴러가는 구조였습니다.
4. VM에서 “경계 + 매핑 + 정책”은 어떤 모습이었을까?
이 구조를 구체적인 가상 머신(VM)의 모습에 대입해 보면 더 명확해집니다.
(1) 경계(Boundary): 운영 단위를 OS로 설정
하드웨어 가상화는 격리의 단위를 프로세스가 아닌 머신(OS 포함)으로 잡았습니다. 무겁다는 단점이 있지만, 경계가 매우 선명하고 강력하다는 확실한 이점을 얻었습니다.
(2) 매핑(Mapping): 가상 자원을 현실 자원에 연결
VM 안의 CPU, 메모리, 디스크가 실제로 작동하려면 물리 자원과의 연결이 필요합니다. 가상 디스크가 실제 스토리지의 어디에 위치하는지, 네트워크 패킷이 어떤 물리 스위치로 나가는지를 관리하는 식입니다. 이 매핑(연결)을 유지하는 여러 구성요소가 가상화를 지탱합니다.
(3) 정책(Policy): 공유를 위한 의사결정
자원을 나눠 쓰는 순간 결정해야 할 것들이 폭발합니다. CPU 시간을 어떻게 쪼갤지, 메모리 할당량을 어디까지 허용할지, 특정 VM의 폭주를 어떻게 제한할지 같은 정책들이 시스템의 핵심이 됩니다.
결국 하드웨어 가상화는 단순한 기술이 아니라, 공유를 안전하게 운영하기 위한 제어/관리 계층에 가까웠습니다.
5. VM에서 Container, Kubernetes로 이어지는 흐름: 경계의 이동
VM을 이렇게 구조적으로 이해하고 나면, 컨테이너나 쿠버네티스로 이어지는 역사가 단순히 더 가벼운 기술의 등장이 아님을 깨닫게 됩니다. 핵심은 경계의 위치가 어디로 움직였느냐에 있었습니다.
- Virtual Memory: 경계가 주소 공간(프로세스)에 생겼습니다.
- VM(하드웨어 가상화): 경계를 머신(OS) 전체로 끌어올려 강력한 격리를 얻었습니다.
- Container: 경계를 다시 프로세스(집합) 단위로 내려 효율성을 챙겼습니다.
- Docker: 그 경계를 배포 가능한 패키지로 굳혀 배포 경험을 표준화하고 단순화했습니다.
- Kubernetes: 경계를 개별 서버를 넘어 클러스터 운영 단위로 확장했습니다.
결국 가상화의 역사는 운영 단위를 무엇으로 잡느냐가 이동해 온 과정이었습니다. 기술이 완전히 바뀐 것이 아니라, 경계/매핑/정책이라는 틀을 유지한 채 운영의 단위만 옮겨 다니며 진화해 온 역사였던 셈입니다. 이 흐름을 파악하고 나면 현대 인프라 기술들의 연결 고리가 비로소 매끄럽게 보이기 시작합니다.
6. 요약 및 다음 편 예고
오늘 정리해 본 내용을 다섯 줄로 요약하면 이렇습니다.
- 하드웨어 가상화는 OS(머신) 단위로 경계를 세우는 방식이었습니다.
- 격리를 시작하면 매핑이 필요해지고, 자연스럽게 정책이 따라붙습니다.
- 따라서 가상화는 “경계 + 매핑 + 정책”의 구조로 이해하는 것이 가장 깔끔합니다.
- VM에서 쿠버네티스까지의 발전은 이 경계가 이동해 온 역사입니다.
- 이 패턴을 이해하면 어떤 가상화 기술도 구조적으로 분석할 수 있습니다.
다음 편에서는 이 모든 패턴이 처음으로 가장 선명하게 나타났던 지점을 살펴보려 합니다. 바로 Virtual Memory입니다. 주소 공간이라는 첫 번째 가상화 레이어가 어떤 힌트를 주었는지 함께 따라가 보겠습니다.
다음 편: 가상화의 역사 1편. 첫번째 가상화 레이어 Virtual Memory
'BackEnd · DevOps > Docker' 카테고리의 다른 글
| OS-Level Virtualization - 가상화의 역사 3 (0) | 2026.04.27 |
|---|---|
| Virtual Machine은 도대체 무엇을 가상화했을까? - 가상화의 역사 2 (0) | 2026.04.20 |
| Dockerize로 가상 인프라 구축하기 (0) | 2025.12.23 |