Cloud Modernization 27

Bare Metal과 Virtual Machine: 가상화 선택 기준 마스터하기

VM이 그냥 서버 하나처럼 보이면 Hypervisor, 오버헤드, 격리, 확장성의 trade-off가 보이지 않는다.

근거 · 교안 p121-p125

Bare Metal과 Virtual Machine을 가상화 선택 기준으로 비교하기 ?? ???

1장: 서버인가, 자원 분배 시스템인가?

1장. 서버인가, 자원 분배 시스템인가?

솔라는 모니터에 떠 있는 문장에서 시선을 떼지 못했다. 클라우드 서비스 기술 문서의 한 구절이었다.

‘Virtual Machine(VM)은 하나의 물리 서버 위에 Hypervisor를 통해 생성된 가상의 서버 인스턴스이고, Bare Metal은 가상화 없이 직접 OS를 설치해 사용하는 물리 서버다.’

분명 모든 단어를 아는데도 문장이 머릿속에서 겉돌았다. ‘가상의 서버 인스턴스’라니. 솔라가 며칠 전 실습으로 만들어 본 VM은 그냥 평범한 리눅스 서버였다. 터미널로 접속해서 명령어를 입력하고, 코드를 배포하고, 웹 서버를 실행시켰다. 물리 서버를 다룰 때와 경험상 큰 차이가 없었다.

“그냥 버튼 누르면 뚝딱 하고 서버 한 대가 더 생기는 거잖아. 편리한 서버 생성기 같은 건가?”

혼잣말을 해봐도 개운하지 않았다. ‘Hypervisor’라는 낯선 관리자가 있다는 것 말고는, 이 정의가 왜 중요한지, 왜 Bare Metal과 VM을 굳이 나눠서 생각해야 하는지 와닿지 않았다. 쓰는 사람 입장에서는 그냥 똑같은 서버일 뿐인데.

답답한 마음에 솔라는 스케치북에 무언가 그리고 있는 언니 루나에게 다가갔다.

“언니, 잠깐 뭐 좀 물어봐도 돼?”

루나는 그리고 있던 복잡한 다이어그램에서 눈을 들어 솔라를 보았다.

“VM이랑 베어메탈 서버 말이야. 정의를 보면 ‘하이퍼바이저’라는 게 있고 없고 차이라는데, 사실 잘 모르겠어. 내가 VM을 만들어 써보니까 그냥 서버 한 대 쓰는 거랑 똑같던데. 이게 왜 그렇게 중요한 차이야?”

솔라는 방금까지 머리를 어지럽히던 문장을 쏟아냈다. 쓰는 경험이 같다면, 그 둘을 나누는 기준은 그저 학술적인 분류 아닐까?

루나는 잠시 생각하더니, 스케치북의 새 페이지를 펼쳤다. 연필을 들어 큰 네모 하나를 쓱 그렸다.

“그렇게 보일 수 있어. 쓰는 사람의 경험을 거의 똑같이 만들었으니까. 잘 만든 가상화 기술이지.”

루나는 말을 잠시 끊고, 네모 안을 가리켰다.

“이 네모가 물리적인 서버, 즉 하드웨어라고 생각해 봐. CPU, 메모리, 디스크가 여기 다 들어있어. 베어메탈 서버는 이 위에 바로 운영체제(OS)를 설치하지.”

루나는 하드웨어를 뜻하는 큰 네모 안에 ‘OS’라고 적힌 또 다른 네모를 꽉 차게 그렸다. 그리고 그 OS 상자 위에 ‘Application’이라고 작게 썼다.

“이 그림처럼, OS가 모든 하드웨어 자원을 직접 제어하고, 애플리케이션은 그 OS가 제공하는 자원을 전부 쓸 수 있어. 집 한 채를 통째로 쓰는 것과 비슷해. 다른 세입자 없이.”

솔라는 고개를 끄덕였다. 익숙한 그림이었다. 자신의 노트북도, 예전에 다루던 물리 서버도 저런 구조였다.

“그럼 VM은?”

루나는 옆 페이지에 다시 한번 커다란 네모를 그렸다. 똑같은 크기의 ‘하드웨어’ 상자였다. 하지만 다음 단계가 달랐다. 루나는 하드웨어 상자 바로 위에 OS를 그리는 대신, ‘Hypervisor’라고 적힌 얇은 층을 먼저 그렸다.

그리고 그 하이퍼바이저 층 위에, 아까보다 훨씬 작은 네모들을 여러 개 그렸다. 각각의 작은 네모 안에 ‘OS’와 ‘Application’을 따로 그려 넣었다. 마치 아파트의 각 세대처럼 보였다.

“이게 VM 환경이야. 하드웨어와 OS 사이에 하이퍼바이저라는 관리인이 먼저 자리를 잡고 있어.”

솔라는 두 그림을 번갈아 보았다. 차이가 한눈에 들어왔다. 왼쪽 그림은 OS가 하드웨어에 직접 닿아있었지만, 오른쪽 그림은 하이퍼바이저라는 낯선 층이 길을 막고 있었다. VM 안의 OS들은 모두 그 하이퍼바이저를 통해서만 하드웨어에 닿을 수 있는 구조였다.

“아…!”

솔라의 입에서 짧은 탄성이 터져 나왔다.

“그러니까 베어메탈은 OS가 하드웨어의 ‘주인’인데, VM 환경에서 OS는 주인이 아니네. 하이퍼바이저라는 건물주나 관리인한테 자원을 ‘할당’받는 세입자 같은 거구나.”

솔라는 오른쪽 그림에서 하이퍼바이저를 손가락으로 콕 찍었다.

“내가 VM에 접속해서 뭔가를 실행하면, 내 OS는 하이퍼바이저한테 가서 ‘CPU 좀 쓸게요’, ‘메모리 좀 주세요’ 하고 요청해야 하는 거네. 베어메탈처럼 직접 하드웨어를 주무를 수 있는 게 아니라.”

그 순간, ‘가상의 서버 인스턴스’라는 말이 전혀 다른 의미로 다가왔다. VM은 독립된 서버가 아니라, 하나의 거대한 물리 서버를 잘게 쪼개어 나눠 쓰는 ‘분할된 자원 공간’이었다. 쓰는 경험이 비슷했던 건, 하이퍼바이저가 너무 일을 잘해서 세입자가 마치 집주인인 것처럼 착각하게 만들었기 때문이었다.

“정확해. VM은 독립된 서버라기보다는, 하이퍼바이저가 중재하고 분배하는 자원 위에서 돌아가는 시스템인 거지.”

루나의 말에 솔라는 자신의 처음 생각을 떠올렸다. ‘그냥 서버 하나 더 생긴 것뿐이잖아.’ 완전히 틀린 생각이었다. 서버의 모습을 하고 있지만, 그 본질은 자원을 나눠 쓰는 방식에 있었다.

새로운 관점이 열리자, 곧바로 새로운 질문이 떠올랐다.

“그런데… 이렇게 중간에 관리인이 끼어 있으면, 뭔가 대가가 있지 않을까? 집주인이랑 직접 계약하는 거랑, 부동산 중개인을 끼는 게 다르듯이. 하이퍼바이저가 자원을 나눠주는 과정에서 뭔가 일이 생길 것 같은데. 직접 쓰는 것보다 느려진다거나…”

솔라의 시선은 다시 하이퍼바이저라는 얇은 층에 머물렀다. 방금 전까지는 그저 낯선 단어였지만, 이제는 모든 문제의 실마리를 쥔 핵심처럼 보였다.

2장: Hypervisor의 숨겨진 역할: 자원 중재의 대가

솔라의 마지막 질문이 맴돌고 있는 공기를 가르듯, 루나는 스케치북을 덮었다. “하이퍼바이저가 자원을 나눠주는 과정에서 뭔가 일이 생길 것 같은데…”라는 솔라의 예리한 직감은, 이전의 그림만으로는 완전히 설명할 수 없는 영역이었다. 그 대가가 무엇인지 보여주려면, 정적인 그림이 아닌 동적인 시뮬레이션이 필요했다.

루나는 책상 위를 정리하더니, 여러 색의 포스트잇과 펜 한 자루를 가져왔다. 그리고는 전날 그렸던 ‘하드웨어’ 상자를 책상 위에 다시 그리는 대신, 책상 중앙의 넓은 공간을 손으로 가리켰다.

“좋아, 직접 그 ‘대가’가 어떻게 발생하는지 체험해 보자. 이 책상 전체가 물리 서버의 자원이야. CPU 시간, 메모리 공간 같은 것들. 그리고 나는 하이퍼바이저.”

루나는 책상 한가운데에 의자를 놓고 앉았다. 솔라는 의도를 파악하고 미소를 지었다.

“그럼 나는 VM인가?”

“응. 너는 여러 개의 VM이야. 이 포스트잇에 VM이 처리해야 할 작업을 적어서 나한테 줘. 예를 들면 ‘CPU 1초 사용’이나 ‘메모리 1GB 할당 요청’처럼. 그럼 내가 하이퍼바이저로서 그 요청을 처리해서 실제 자원, 즉 이 책상 위에 배분해 줄게.”

솔라는 재미있겠다는 표정으로 파란색 포스트잇에 ‘VM-1: 웹 요청 처리 (CPU 0.1초)’라고 적어 루나에게 건넸다. 단순한 작업이니 금방 처리될 거라고 생각했다.

하지만 루나는 포스트잇을 받자마자 책상(하드웨어)에 놓지 않았다. 대신 옆에 놓인 작은 수첩을 펼쳐 무언가를 기록했다. ‘VM-1, 0.1초 CPU 요청 접수, 대기열 없음, 즉시 처리 가능.’ 그리고 나서야 포스트잇을 책상 한쪽에 내려놓았다.

솔라가 의아한 표정으로 물었다.

“언니, 지금 뭐 한 거야? 그냥 받아서 책상에 놓으면 되는 거 아냐? 왜 수첩에 뭘 적어?”

“이게 하이퍼바이저의 일이니까. 나는 그냥 요청을 전달하는 우체부가 아니야. 어떤 VM이 어떤 자원을 얼마나 요청했는지, 현재 사용 가능한 자원은 얼마나 있는지, 다른 VM의 요청과 겹치지는 않는지 전부 확인하고 스케줄링해야 해. 이 수첩 기록이 바로 그 관리 작업, 즉 ‘중재’의 과정이야.”

그 순간, 솔라의 머릿속에서 ‘관리인의 대가’라는 말이 구체적인 모습으로 그려졌다. 하이퍼바이저가 하는 모든 확인과 기록, 그 자체가 시간과 자원을 소모하는 일이었다. 베어메탈 서버였다면 OS가 하드웨어에 직접 명령을 내리면 끝날 일이었다. 하지만 VM은 하이퍼바이저라는 관리인을 거쳐야만 했고, 관리인은 자신의 일을 하기 위한 시간이 필요했다.

“아… 그 관리 작업 자체가 비용이구나. 그걸 ‘오버헤드’라고 부르는 건가?”

“바로 그거야.”

솔라는 이번엔 다른 실험을 해보기로 했다. 노란색 포스트잇에는 ‘VM-2: 단순 DB 조회 (CPU 0.2초)’라고 쓰고, 동시에 빨간색 포스트잇에는 ‘VM-3: 대용량 동영상 인코딩 (CPU 30초)’이라고 과장해서 썼다. 그리고 두 장을 동시에 루나에게 내밀었다.

루나는 두 포스트잇을 보더니, 자신의 수첩에 두 요청을 기록했다. 그리고는 빨간색 포스트잇(VM-3)을 먼저 집어 들고 책상 위에 올려놓은 뒤, 마치 그 작업이 처리되는 동안 다른 일을 할 수 없다는 듯이 꼼짝도 하지 않았다. 솔라가 내민 노란색 포스트잇은 손에 든 채였다.

“어, 잠깐만. VM-2의 요청은 엄청 간단한 거잖아. 먼저 처리해주면 안 돼?”

솔라는 답답한 마음에 소리쳤다. 하지만 루나는 고개를 저었다.

“안타깝지만 그럴 수 없어. 하이퍼바이저의 스케줄링 정책에 따라, 이미 VM-3에 CPU 자원을 할당하기 시작했거든. VM-2의 요청은 아주 짧은 작업이지만, VM-3이 자원을 점유하고 있는 동안에는 순서를 기다려야 해.”

솔라는 눈앞의 광경을 보고 할 말을 잃었다. 분명 자신의 VM-2는 아무 잘못도 하지 않았다. 그저 운 나쁘게도 자원을 많이 쓰는 다른 VM과 같은 물리 서버에 있었을 뿐이다. 그런데 그 때문에 간단한 작업조차 지연되고 있었다. 터미널에 명령어를 입력했는데 한참 동안 응답이 없는 상황이 눈앞에 그려졌다.

그제야 솔라는 모든 것을 깨달았다. 하이퍼바이저의 존재는 단순히 오버헤드만을 의미하는 게 아니었다. 하나의 물리 자원을 여러 VM이 ‘공유’하기 때문에, 다른 VM의 작업량이 나의 VM 성능에 직접적인 영향을 미칠 수 있다는 것. 이것이 바로 ‘자원 공유로 인한 성능 편차’의 실체였다.

“이제 알겠어… VM의 성능은 내가 얼마나 쓰느냐 뿐만 아니라, ‘이웃’이 누구냐에 따라서도 달라지는 거구나. 하이퍼바이저는 단순한 생성 도구가 아니라, 이 모든 트래픽을 관리하고 조율하는 ‘자원 중재자’였네. 그리고 그 중재 과정에서 오버헤드와 성능 편차가 생기는 거고.”

솔라는 책상 위에 놓인 각양각색의 포스트잇들을 바라보았다. 이제 그것들은 단순한 작업 요청이 아니라, 보이지 않는 자원 경쟁을 벌이는 치열한 현장처럼 보였다.

문득 새로운 의문이 고개를 들었다. 이 시끄러운 이웃 문제는 단점만 있는 걸까? 하이퍼바이저가 이렇게 철저하게 VM들을 관리하고 중재한다는 건, 반대로 생각하면 VM들이 서로의 영역을 침범하지 못하도록 막아준다는 뜻도 되지 않을까? 이 ‘중재’가 성능에는 손해를 주지만, 다른 어딘가에서는 이득을 주고 있을지도 모른다는 생각이 들었다.

3장: 트레이드오프의 근원: 직접 vs. 중재된 접근

솔라의 책상 위는 전보다 더 복잡해져 있었다. 어제 루나와 함께 그렸던 두 개의 다이어그램—베어메탈과 VM의 아키텍처—옆에, 새로 꺼낸 노트가 펼쳐져 있었다. 노트에는 ‘장점’과 ‘단점’으로 나뉜 어설픈 표가 그려져 있었다. 솔라는 인터넷에서 찾은 기술 문서의 내용을 옮겨 적고 있었다.

[베어메탈]

장점: 최고 성능 (가상화 오버헤드 없음), 높은 보안성 (단일 사용자), 하드웨어 설정 자유도 높음
단점: 낮은 자원 효율성, 느린 확장

[Virtual Machine]

장점: 유연한 자원 사용, 빠른 확장
단점: 성능 손실 (오버헤드), 자원 공유로 인한 성능 편차, 하이퍼바이저 취약점 존재 가능

표를 완성했지만 솔라의 표정은 개운치 않았다. 어제 하이퍼바이저를 ‘자원 중재자’로 이해하면서 성능 오버헤드와 성능 편차는 왜 생기는지 확실히 알게 되었다. 하지만 나머지는 여전히 뜬구름 잡는 소리 같았다.

“성능 문제는 알겠는데… 베어메탈이 왜 더 안전하다는 거지? 서버 하나를 통째로 쓰니까 해킹당하면 더 위험한 거 아냐? 그리고 VM은 왜 갑자기 ‘하이퍼바이저 취약점’이라는 단점이 튀어나오는 거야?”

어제 마지막에 떠올랐던 의문—중재가 성능에는 손해지만 다른 곳에 이득을 주지 않을까 하는 생각—이 이 표와 충돌하는 것처럼 느껴졌다. 목록을 그저 외워야만 하는 걸까. 이 장점과 단점들이 대체 어디서부터 왔는지, 그 뿌리를 알 수 없어 답답했다.

그때, 솔라의 혼잣말을 들은 루나가 다가와 노트에 적힌 표를 조용히 들여다보았다. 그리고는 표가 아닌, 그 옆에 놓인 두 개의 아키텍처 다이어그램을 손가락으로 톡톡 두드렸다.

“솔라, 그 목록에서 잠시 눈을 떼 봐. 그리고 이 두 그림의 결정적인 차이, 딱 하나에만 집중해 봐. 애플리케이션이 하드웨어의 자원을 쓰기까지 거치는 ‘경로’의 차이.”

루나의 말에 솔라는 고개를 들어 다이어그램을 다시 보았다. 왼쪽의 베어메탈 그림은 [Application -> OS -> Hardware]로 이어지는 직선적인 구조였다. 오른쪽 VM 그림은 [Application -> Guest OS -> Hypervisor -> Hardware]로, 중간에 하이퍼바이저라는 단계가 하나 더 있었다.

“경로의 차이라… 베어메탈은 OS가 하드웨어에 직접 명령을 내리는 ‘직접 접근’ 방식이고, VM은 하이퍼바이저를 거쳐서 명령을 내리는 ‘중재된 접근’ 방식이네.”

솔라는 두 접근 방식의 이름을 나직이 읊조렸다. 그 순간, 머릿속에서 흩어져 있던 퍼즐 조각들이 하나의 그림으로 맞춰지기 시작했다. 장점과 단점 목록 전체를 관통하는 단 하나의 핵심 원리가 보였다.

“아…! 알겠다! 이 모든 장단점이 결국 ‘직접이냐, 중재냐’ 이 차이 하나에서 전부 파생되는 거였어!”

솔라는 흥분하며 펜을 다시 집어 들었다.

“성능부터 봐봐. ‘직접 접근’은 중간에 끼어드는 녀석이 없으니 당연히 빠르고, 그래서 베어메탈이 최고 성능을 내는 거야. 반대로 ‘중재된 접근’은 하이퍼바이저라는 관리인을 거쳐야 하니까, 그 관리비가 바로 오버헤드, 즉 성능 손실인 거고!”

어제 포스트잇으로 했던 실험의 결과가 자연스럽게 연결되었다. 그렇다면 보안은?

“보안도 마찬가지네! 베어메탈은 집 한 채를 통째로 쓰는 거니까, 현관문 하나만 뚫리면 집 전체가 털리는 구조야. OS에 보안 구멍이 생기면 하드웨어까지 직접적인 영향을 받지. 하지만 VM은 달라!”

솔라는 VM 아키텍처 다이어그램에서 하이퍼바이저 층을 힘주어 동그라미 쳤다.

“하이퍼바이저는 아파트 경비실 같은 거네. 한 세대(VM)에 도둑이 들어도, 경비실(하이퍼바이저)이 다른 세대로 넘어가지 못하게 막아주는 거야. 이게 바로 ‘격리’구나! 그래서 한 VM이 이상해져도 다른 VM이나 물리 서버 전체는 안전할 수 있는 거고. 물론… 경비실 자체가 털리면 아파트 전체가 위험해지니까, 그게 바로 ‘하이퍼바이저 취약점’이라는 단점으로 나타나는 거였어.”

‘베어메탈이 더 안전하다’는 말은 ‘다른 세입자가 없어서 안전하다’는 뜻이었고, ‘VM의 보안’은 ‘하이퍼바이저가 지켜줘서 안전하다’는 뜻이었다. 완전히 다른 맥락의 이야기였던 것이다.

이제 확장성도 명확해졌다.

“집 한 채를 더 지으려면(베어메탈) 땅 파고 기초 공사부터 해야 하니 느리지만, 아파트 빈방에 세입자를 새로 들이는 건(VM) 계약서만 쓰면 되니까 훨씬 빠르지. 하이퍼바이저가 있으니 자원을 유연하게 쪼개고 합치는 게 쉬워지는 거고.”

솔라는 방금 자신이 채웠던 장단점 표를 바라보았다. 더 이상 암기해야 할 목록이 아니었다. ‘직접 접근’과 ‘중재된 접근’이라는 두 가지 프레임 위에서 논리적으로 도출되는 당연한 결과물이었다.

“결국 하이퍼바이저라는 ‘중재자’의 존재가 양날의 검이었네. 성능과 직접 제어권을 포기하는 대가로, 격리, 유연성, 효율성을 얻는 것. 이 트레이드오프를 이해하는 게 핵심이었어.”

모든 것이 명확해지자, 솔라의 머릿속에는 마지막 질문이 떠올랐다. 이제 이 지식을 어떻게 써먹어야 할까?

“언니, 그럼 실제 서비스를 만들 때는 이 트레이드오프를 어떻게 적용해야 해? 예를 들어 어떤 서비스는 베어메탈을 쓰고, 어떤 서비스는 VM을 써야 할까?”

루나는 기다렸다는 듯이 솔라의 노트 빈 곳에 두 가지 시나리오를 짧게 적어주었다.

시나리오 A: 1밀리초의 지연도 용납할 수 없는 초고속 금융 거래 시스템

시나리오 B: 수백 개의 소규모 프로젝트 팀이 각자 독립적인 테스트 환경을 필요로 하는 대규모 소프트웨어 회사

솔라는 두 시나리오와 베어메탈, VM의 아키텍처 다이어그램을 번갈아 보았다. 더 이상 망설일 필요가 없었다. 답은 명확했다.

“A는 무조건 베어메탈이야. 성능이 가장 중요하니까, 하이퍼바이저라는 아주 작은 오버헤드조차 허용하면 안 돼. 자원에 대한 ‘직접 접근’이 필수적이야.”

솔라는 시나리오 A 옆에 ‘베어메탈’이라고 쓰고, 그 이유로 ‘최고 성능, 직접 접근’이라고 덧붙였다.

“그리고 B는 VM이 정답이지. 수백 개 팀에 물리 서버를 하나씩 줄 수는 없잖아. 하나의 거대한 서버를 하이퍼바이저로 잘게 쪼개서, 각 팀에 독립적이고 ‘격리된’ 환경을 ‘유연하게’ 제공하는 게 핵심이니까.”

시나리오 B 옆에는 ‘VM’이라고 적고 ‘격리, 유연성, 비용 효율’이라고 명시했다. 이제 솔라는 단순히 ‘VM이 좋다’나 ‘베어메탈이 빠르다’가 아니라, 어떤 상황에서 왜 그 선택이 타당한지를 ‘자원 접근 방식’의 차이라는 근본 원리로 설명할 수 있게 되었다. 그것은 단순한 지식을 넘어선, 실용적인 선택의 기준이었다.