12.0 가상화와 클라우드 — 하드웨어는 사라지지 않고 나뉜다
가상 머신도, 컨테이너도, 클라우드의 관리형 서비스도 물리 하드웨어를 없애지 않는다. 코어와 메모리와 디스크는 항상 실재하고, 이 챕터가 다루는 모든 기술은 그 실재하는 자원을 여럿이 안전하게 나눠 쓰도록 격리하고, 나눠 쓴 만큼 계량하는 방법일 뿐이다. 이 인트로는 그 격리와 계량이 구체적으로 어느 계층에서, 얼마의 책임과 함께 이뤄지는지에 대한 질문을 세우고 챕터 12의 두 문서로 안내한다.
학습 목표
- 하이퍼바이저·컨테이너·클라우드 관리형 서비스를 "하드웨어를 나누는 방법"이라는 공통 관점으로 설명한다.
- "가볍다", "서버가 없다", "관리형이라 안전하다" 같은 익숙한 표현에서 확인해야 할 계약을 식별한다.
- 격리 계층(어디서 나누는가)과 책임 경계(어디까지 넘기는가)라는 두 축으로 챕터 12의 두 문서를 구분한다.
출발점: 컨테이너 탈출 경고와 예상 밖의 클라우드 청구서
한 회사가 여러 고객의 워크로드를 한 Kubernetes 클러스터에서 컨테이너로 운영한다. 어느 날 보안 벤더가 "호스트 커널의 권한 상승 취약점을 이용한 컨테이너 탈출(escape) 가능성"을 경고한다. 한 엔지니어가 "VM을 썼으면 이런 걱정이 없었을 것"이라 말하자, 다른 엔지니어는 "namespace로 격리했으니 컨테이너도 문제없다"고 반박한다. 같은 주에 다른 팀은 트래픽이 들쭉날쭉한 API를 "요청이 없으면 비용도 0"이라는 기대로 서버리스로 옮겼는데, 정작 꾸준히 트래픽이 있는 시간대가 길어 청구서가 오히려 늘었다.
두 사건은 서로 다른 오해에서 시작하지만 뿌리는 같다. "격리됐다"와 "관리형이다"라는 말을 실제 메커니즘 없이 결론으로 받아들인 것. 컨테이너의 namespace가 정확히 무엇을 나누고 무엇을 나누지 않는지 모르면 탈출 경고의 심각성을 판단할 수 없고, 서버리스의 과금이 실제로 무엇(호출 수, 실행 시간, 메모리)에 비례하는지 모르면 "요청이 없으면 공짜"라는 말이 자신의 워크로드에 적용되는지 알 수 없다.
하드웨어를 나누는 두 가지 질문
이 챕터가 다루는 모든 기술 — 하이퍼바이저, 컨테이너, IaaS, 서버리스 — 은 다음 두 질문에 대한 서로 다른 답이다.
격리를 어느 계층에서 사는가? 하드웨어 전체를 게스트 수만큼 다시 만들어 커널부터 격리할 것인가, 아니면 커널은 하나만 두고 그 안에서 프로세스가 보는 것과 쓸 수 있는 양만 나눌 것인가. 앞의 답은 신뢰 경계가 작아지는 대신(하이퍼바이저만 신뢰하면 된다) 자원과 시작 시간을 더 쓰고, 뒤의 답은 자원과 시작 시간을 아끼는 대신 신뢰 경계가 호스트 커널 전체로 넓어진다.
책임을 어디까지 넘기는가? 물리 서버부터 애플리케이션 코드까지 이어지는 스택에서, 어디까지를 직접 운영하고 어디부터를 벤더에게 맡길 것인가. 더 많이 넘길수록 운영 부담은 줄지만 통제권과 커스터마이징의 여지도 함께 줄고, "넘겼다"고 믿은 책임의 일부(데이터 분류, 접근 제어 설정)는 실제로는 넘어가지 않는다.
이 두 질문은 독립적이다. 신뢰 경계를 하이퍼바이저 수준으로 좁혀도 그 VM의 운영을 전부 직접 관리할 수 있고(IaaS의 self-managed VM), 반대로 격리는 컨테이너 수준으로 가볍게 두면서 운영 책임 대부분을 벤더에게 넘길 수도 있다(관리형 컨테이너 플랫폼). 다음 표는 각 질문에서 익숙한 표현이 감추는 것을 정리한다.
| 익숙한 표현 | 확인해야 할 계약 |
|---|---|
| "컨테이너는 VM보다 가볍다" | 가벼운 이유가 커널을 공유하기 때문이라면, 그 공유가 신뢰 경계를 어디까지 넓히는가 |
| "namespace로 격리했으니 안전하다" | namespace가 나누는 것은 시야일 뿐, 커널 자체(공격 표면)는 나누지 못한다 |
| "클라우드는 서버가 없다(serverless)" | 물리 서버가 없는 게 아니라 프로비저닝과 유휴 비용의 책임이 벤더로 넘어간 것이다 |
| "오토스케일링을 켜면 비용이 자동으로 준다" | 절감 폭은 워크로드가 얼마나 스파이크형인지에 달려 있고, 균일한 부하에는 절감할 유휴 용량 자체가 없다 |
| "관리형 서비스니까 안전·안정하다" | 벤더 책임과 고객 책임의 경계가 어디인지, 그 경계 안쪽(설정)은 여전히 누구 몫인지 |
| "서버리스는 안 쓰면 공짜다" | 과금이 실제로 비례하는 축(호출 수, 실행 시간, 메모리)이 무엇이고 손익분기점이 어디인지 |
이 챕터에서 세울 두 가지 모델
12.1 가상화와 컨테이너
격리를 어느 계층에서 사는가?
8.1과 8.2가 세운 태스크·페이지 테이블 모델 위에, 하이퍼바이저가 CPU·메모리·I/O 가상화로 하드웨어 전체를 어떻게 복제하는지, 컨테이너가 namespace·cgroup·런타임·이미지로 커널 하나를 어떻게 여럿으로 보이게 하는지를 다룬다. 두 접근을 커널 공유 여부·공격 표면·오버헤드로 정면 비교하면 "컨테이너는 VM보다 안전한가"라는 질문에 예/아니오가 아니라 신뢰 경계의 크기로 답할 수 있다.
12.2 클라우드 컴퓨팅
책임을 어디까지 넘기는가?
IaaS·PaaS·SaaS가 스택의 어느 높이까지 벤더에게 관리를 맡기는지, 탄력성과 오토스케일링이 유휴 비용과 반응 지연을 어떻게 교환하는지, 관리형 서비스의 책임 공유 모델이 벤더와 고객의 경계를 어디에 긋는지, 서버리스가 콜드 스타트·상태 비저장·과금 단위로 이 경계를 극단까지 밀어붙이면 무엇을 얻고 잃는지를 다룬다. 실행 가능한 비용 모델 스크립트로 서버리스와 예약 인스턴스의 손익분기점을 직접 계산해 본다.
두 문서는 서로 다른 축이지만 배치 결정에서는 함께 쓰인다. 신뢰할 수 없는 코드를 실행해야 하는지(12.1의 격리 축)와 운영 부담을 어디까지 넘기고 싶은지(12.2의 책임 축)를 함께 답해야 VM·컨테이너·서버리스 중 하나를 근거 있게 고를 수 있다.
이 챕터를 읽는 방법
- "가볍다/무겁다"를 "무엇을 공유하는가"로 번역한다. 오버헤드가 낮다는 말은 대개 무언가(커널, 운영 책임)를 공유하거나 넘겼다는 뜻이고, 그 대가로 무엇을 포기했는지가 항상 짝을 이룬다.
- 비용 주장은 과금 축으로 분해한다. "저렴하다"는 결론이 아니라 호출 수·실행 시간·메모리·유휴 시간 같은 구체적인 축 위에서 확인해야 할 계산이다.
- "관리형"이라는 말에서 경계를 구체적으로 확인한다. 벤더가 관리하는 층과 고객이 여전히 설정해야 하는 층을 나누지 않으면, 장애가 났을 때 누구 책임인지도 알 수 없다.
- 격리와 책임은 다른 질문임을 유지한다. 하나의 축만 보고 기술을 고르면 나머지 축의 비용을 나중에야 발견한다.
정리
- 하이퍼바이저·컨테이너·클라우드 서비스는 전부 물리 하드웨어를 나눠 쓰게 하는 방법이며, 하드웨어 자체를 없애지 않는다.
- "격리를 어느 계층에서 사는가"(하드웨어 재현 대 커널 공유)와 "책임을 어디까지 넘기는가"(직접 운영 대 관리형 대 서버리스)는 서로 다른 축이고, 배치 결정에는 둘 다 필요하다.
- 12.1은 하이퍼바이저와 컨테이너의 격리 메커니즘을 커널 공유·공격 표면·오버헤드로 비교하고, 12.2는 클라우드 서비스 모델의 책임 경계와 탄력성·서버리스의 비용 모델을 다룬다.
확인 문제
1. "컨테이너는 커널 수준에서 격리되니 VM만큼 안전하다"는 동료의 주장에서, 이 문서가 세운 관점으로 지적할 빈틈은 무엇인가?
정답과 해설
namespace가 나누는 것은 커널 자원에 대한 시야이지 커널 자체가 아니다. 모든 컨테이너는 여전히 하나의 호스트 커널을 공유하므로, 그 커널의 권한 상승 취약점 하나가 여러 컨테이너와 호스트에 동시에 영향을 줄 수 있다. VM은 게스트마다 독립된 커널을 두어 신뢰 경계를 하이퍼바이저 자체로 좁힌다. "격리됐다"는 말은 이분법이 아니라 신뢰 경계의 크기 문제이며, 구체적인 메커니즘은 12.1에서 다룬다.
2. 트래픽이 하루 종일 거의 일정한 서비스를 "비용 절감"을 이유로 서버리스로 옮기려 한다. 이 결정을 검증하려면 무엇을 먼저 계산해야 하는가?
정답과 해설
서버리스의 이점(유휴 비용 0)은 트래픽이 스파이크형일 때 커지고, 균일한 부하에는 애초에 절감할 유휴 용량이 없다. "비용 절감"을 근거로 삼으려면 벤더의 과금 축(호출 수, 실행 시간, 메모리)으로 예상 월 비용을 계산하고 현재의 고정 용량 비용과 비교한 손익분기점부터 확인해야 한다. 이 계산의 실행 가능한 예시는 12.2에서 다룬다.
참고 자료
- Peter Mell, Timothy Grance, "The NIST Definition of Cloud Computing," NIST Special Publication 800-145 (2011) — 이 챕터 전체가 기대는 클라우드의 필수 특성과 서비스 모델의 표준 정의.
- Gerald J. Popek, Robert P. Goldberg, "Formal Requirements for Virtualizable Third Generation Architectures," Communications of the ACM 17(7), 1974 — 가상화가 형식적으로 무엇을 요구하는지 정의한 원 논문. 12.1에서 상세히 다룬다.
- Linux man-pages, namespaces(7) — 컨테이너 격리가 실제로 나누는 것과 나누지 않는 것을 확인하는 1차 자료.