특히 배포가 1년에 몇 번 없고, 트래픽 변동도 거의 없으며, 구조가 단순한 이른바 ‘얌전한 서비스’를 운영하는 동료들이 이런 고민을 많이 토로합니다. 겉으로는 “우리도 최신 기술 도입해야지!”라고 외치지만, 속으로는 ‘지금 VM(가상 머신)으로도 아무 문제 없이 평화로운데, 굳이 왜 사서 고생을 해야 하지?’라는 강한 의구심이 드는 것이죠. 이번에 프로젝트를 진행하면서도 컨테이너 환경으로 구성해야 하지 않는가? 하는 질문을 많이 받았습니다.

PI 단계에서는 구체적인 아키텍처와 서비스를 고려하지 않고 최신 기술을 적용하려는 경향이 많습니다. 자사 프로젝트에서도 처음 PI 단계에서는 컨테이너 환경의 마이크로 서비스로 계획을 했었으나 구체화 단계에서 VM OS 환경으로 구축을 진행했습니다.

배포가 많지 않고 운영 복잡성이 없는 서비스라면 VM OS 구성이 훨씬 더 현명하고 안정적인 선택입니다.

오늘 글에서는 제가 실제 현업에서 두 환경을 모두 밑바닥부터 운영하며 뚝배기(?)가 깨져본 생생한 경험담을 바탕으로, VM과 컨테이너의 장단점을 아주 적나라하게 비교해 드리겠습니다. 유행에 휩쓸려 후회하지 않고, 내 서비스에 딱 맞는 정답을 찾는 기준이 될 것입니다.

1. 내가 컨테이너 붐에 휩쓸려 삽질했던 이야기

몇 년 전, 회사에서 비교적 규모가 작고 안정적인 사내 관리용 인트라넷 시스템의 인프라를 이전할 기회가 있었습니다. 당시 업계는 그야말로 ‘컨테이너 광풍’이 불고 있었습니다. 테크 컨퍼런스에 가면 온통 쿠버네티스 이야기뿐이었고, VM을 쓰는 사람은 마치 구시대의 유물처럼 취급받던 시절이었죠.

저 역시 “이 트렌디한 기술을 내 이력서에 넣고 말겠다”는 사심(?)과 “컨테이너로 바꾸면 자원 효율성도 좋아지고 관리도 편해지겠지”라는 막연한 환상을 품고 이 프로젝트를 도커 컨테이너 기반으로 전환하기 시작했습니다.

그때는 몰랐습니다. 그 결정이 지옥의 시작이었음을요.

첫 번째 난관: 배포는 없는데, 인프라 공부만 한 달

기존 VM 환경에서는 CentOS 위에 Nginx와 Tomcat을 올리고, 배포할 때 젠킨스로 빌드된 war 파일만 지정된 경로에 던져주면 끝이었습니다. 배포가 한 달에 한 번 있을까 말까 한 서비스였기에 아주 평화로웠죠.

그런데 컨테이너로 바꾸려니 신경 써야 할 게 한두 개가 아니었습니다.

Dockerfile을 어떻게 작성해야 이미지 용량을 줄일 수 있지?
멀티 스테이지 빌드는 또 뭐야?
컨테이너가 꺼지면 로그 파일이 다 날아가네? 호스트랑 볼륨 마운트는 어떻게 설정하지?
컨테이너끼리 통신하려면 도커 네트워크 브리지를 어떻게 잡아야 하지?

배포가 잦지 않은 서비스인데, 배포 환경을 만들기 위해 몇 배의 시간을 쏟아야 했습니다. 배보다 배꼽이 더 커진 상황이었죠.

두 번째 난관: 새벽 3시에 터진 장애, 그리고 미궁 속으로

컨테이너 환경으로 바꾼 지 2주째 되던 날, 서비스가 먹통이 되었습니다. VM 시절에는 문제가 생기면 익숙하게 SSH로 접속해서 top 명령어를 치고, systemctl status를 보거나 /var/log 밑에 있는 로그를 뒤지면 10분 만에 원인이 나왔습니다.

하지만 컨테이너 환경은 달랐습니다. 컨테이너 내부로 들어가 보려 해도 가볍게 만든답시고 alpine 이미지를 써서 curl도 없고, netstat도 없고, vi 에디터조차 실행되지 않았습니다. 로그를 보려 하니 컨테이너는 이미 죽어버려서 내부 로그를 볼 수도 없었죠.

결국 컨테이너 오케스트레이션 툴의 네트워크 라우팅 꼬임과 컨테이너 메모리 제한(OOM Killer) 때문이라는 것을 알아내는 데 꼬박 이틀이 걸렸습니다. 그때 뼈저리게 깨달았습니다. “아, 다루기 쉬운 장난감 하나 고치려다, 엔진 구조도 모르는 슈퍼카를 사버렸구나.”

2. 그렇다면 왜 사람들은 컨테이너에 열광할까?

제가 삽질한 경험담을 털어놓았지만, 그렇다고 컨테이너가 나쁜 기술이라는 뜻은 결코 아닙니다. 컨테이너는 현대 소프트웨어 아키텍처에서 신의 축복과도 같은 존재임은 틀림없습니다. 다만 ‘어떤 서비스인가’에 따라 그 가치가 달라질 뿐입니다.

가상 머신(VM)과 컨테이너의 본질적인 차이를 이해하면, 왜 사람들이 그토록 컨테이너를 외치는지 알 수 있습니다.

1) 무거운 OS의 유무 (Hypervisor vs Container Engine)

VM (가상 머신): 하드웨어 위에 하이퍼바이저를 두고, 그 위에 Guest OS를 통째로 올립니다. 윈도우 호스트 위에 가상 리눅스를 띄우는 식이죠. 따라서 아무리 작은 애플리케이션을 돌려도 OS 자체를 구동하기 위한 수 GB의 메모리와 CPU 오버헤드가 발생합니다.
컨테이너: 호스트 OS의 커널(Kernel)을 공유하면서, 프로세스 수준에서 완벽하게 공간을 격리합니다. 쉽게 말해 OS를 또 만드는 게 아니라, 하나의 OS 안에서 다른 방을 써서 격리하는 것입니다. OS가 없으니 용량이 몇 십 MB 수준으로 가볍습니다.

2) 기동 속도의 차이

VM을 켜는 것은 컴퓨터를 새로 부팅하는 것과 같습니다. 부팅 시퀀스를 거쳐야 하므로 최소 수십 초에서 수 분이 걸립니다. 반면 컨테이너는 이미 켜져 있는 OS 위에서 프로세스를 하나 실행하는 것에 불과하므로 0.1초, 길어야 수 초 안에 켜집니다.

트래픽이 급증할 때 서버를 순식간에 10대, 100대로 늘려야 하는(Auto Scaling) 대규모 서비스에서는 이 기동 속도의 차이가 곧 서비스의 생존과 직결됩니다.

3) “내 컴퓨터에선 잘 되는데요?”의 완벽한 해결

개발을 하다 보면 가장 짜증 나는 순간이 있습니다. 개발자 로컬 PC에서는 아주 잘 돌아가는데, 스테이징 서버나 운영 서버에만 올리면 엉뚱한 에러가 나는 경우입니다. 99%는 OS 버전 차이, 깔려있는 자바나 파이썬 패키지 버전 불일치, 환경 변수 누락 때문입니다.

컨테이너는 애플리케이션뿐만 아니라 실행에 필요한 라이브러리, 환경 설정까지 통째로 패키징하여 ‘이미지’로 만듭니다. 이 이미지는 전 세계 어떤 서버에 올리든 정확히 똑같이 작동합니다. 환경 일관성 측면에서는 타의 추종을 불허합니다.

3. 배포가 적고 단순한 서비스에서 VM이 압승하는 이유

다시 질문으로 돌아와 보겠습니다. “배포가 많지 않고 운영 복잡성이 없는 서비스라면 VM OS 구성이 좋지 않나요?”

제 대답은 “네, 백번 천번 맞습니다. 무조건 VM으로 가세요.” 입니다. 그 구체적인 이유를 세 가지로 정리해 드립니다.

1) 기술적 복잡성과 관리 비용(Hidden Cost)의 차이

컨테이너를 도입한다는 것은 단순히 docker run 명령어를 배우는 것으로 끝나지 않습니다. 컨테이너 환경을 제대로 유지보수하려면 다음과 같은 ‘숨겨진 기술 스택’을 모두 감당해야 합니다.

컨테이너 생명 주기 관리: 컨테이너가 예기치 않게 죽었을 때 어떻게 살릴 것인가?
상태 저장(Stateful)의 한계: 컨테이너는 기본적으로 휘발성입니다. 데이터베이스(DB)나 사용자가 업로드한 이미지 파일을 저장하려면 외부 스토리지(AWS EBS, S3, NFS 등)와 복잡하게 연동해야 합니다. VM은 그냥 로컬 디스크에 저장하면 끝날 일입니다.
네트워크 아키텍처: 포트 포워딩, 컨테이너 간 사설 IP 통신, 로드 밸런서 연동 등 네트워크 복잡도가 안드로메다로 갑니다.

배포를 1년에 몇 번 하지 않는 서비스라면, 이 거대한 인프라를 유지하고 관리하기 위해 공부하고 삽질하는 시간이 너무나 아깝습니다. 그 시간에 서비스 기능을 하나 더 개발하는 게 이득입니다.

2) 직관적이고 편안한 트러블슈팅

운영자 입장에서 가장 마음이 편할 때는 ‘내가 제어할 수 있는 범위 안에 모든 것이 있을 때’입니다.

VM 환경은 직관적입니다.

서비스에 문제가 생겼다? SSH로 서버에 들어간다.
top이나 htop으로 CPU/메모리를 많이 먹는 프로세스를 확인한다.
시스템 로그나 애플리케이션 로그 파일(tail -f app.log)을 실시간으로 확인한다.
필요하면 설정 파일을 수정하고 프로세스를 재시작(systemctl restart Nginx)한다.

하지만 컨테이너 환경, 특히 쿠버네티스 같은 오케스트레이션 환경에서는 장애가 나면 어디서부터 손을 대야 할지 막막합니다. 포드가 죽었는지, 노드가 죽었는지, 인그레스 설정이 꼬였는지 파악하기 위해 수많은 추상화 레이어를 거쳐야 합니다. 모니터링 시스템(Prometheus, Grafana 등)을 따로 구축해놓지 않았다면 장님 코끼리 만지는 격이 됩니다.

3) 검증된 안정성과 예측 가능성

VM 기술은 이미 수십 년간 다듬어질 대로 다듬어진 기술입니다. 전 세계 수많은 기업이 VM 환경에서 금융 시스템, 이커머스, 공공 기관 서비스를 안정적으로 돌려왔습니다. 보안 패치, OS 업데이트, 백업 및 복구 프로세스가 아주 명확하게 정립되어 있습니다.

예측 불가능한 변수가 적다는 것, 그것이 바로 배포가 적고 안정적인 서비스를 지향하는 조직에게 가장 중요한 미덕입니다.

4. 내 서비스에 맞는 인프라 선택 가이드 (체크리스트)

아직도 마음 한구석에 “그래도 남들 다 컨테이너 쓴다는데…” 하는 찝찝함이 남아있으신가요? 그렇다면 제가 만든 간단한 체크리스트를 통해 냉정하게 자가 진단을 해보시기 바랍니다.

다음 중 3개 이상 해당된다면 묻지도 따지지도 말고 VM으로 가세요!

현재 서비스의 배포 주기가 최소 2주~한 달 이상이거나, 수개월에 한 번이다.
트래픽의 급격한 변화가 거의 없고, 평소 사용량이 일정하게 유지된다.
인프라를 전담해서 관리할 전임 엔지니어가 없거나 부족하다 (개발자가 인프라까지 겸업해야 한다).
서비스의 구조가 단일 애플리케이션과 DB로 구성된 단순한 모놀리식(Monolithic) 형태다.
데이터베이스나 파일 저장소 등 상태(State)를 유지해야 하는 시스템이 서비스의 핵심이다.
장애가 발생했을 때 빠르게 SSH로 들어가서 직접 해결하는 방식을 선호한다.

반면, 이럴 때는 무조건 컨테이너 도입을 검토하셔야 합니다.

하루에도 수십 번씩 마이크로서비스 단위로 잦은 배포와 롤백이 일어나는 경우
특정 이벤트(예: 선착순 세일, 수강신청 등) 때 트래픽이 수십 배 폭증하여 실시간 오토스케일링이 필수적인 경우
개발팀 규모가 커서 수십 명의 개발자가 각자 독립된 개발 환경을 신속하게 구성해야 하는 경우
서비스 아키텍처가 수십 개의 마이크로서비스(MSA)로 쪼개져 있어 중앙 제어가 필요한 경우

5. 시니어 엔지니어의 한마디: 기술의 본질은 ‘비즈니스의 해결’

우리가 기술을 배우고 도입하는 궁극적인 이유는 무엇일까요? 트렌디해 보이기 위해서도 아니고, 이력서를 화려하게 채우기 위해서도 아닙니다. 가장 적은 비용과 노력으로 서비스를 안정적으로 고객에게 전달하는 것, 즉 ‘비즈니스 문제를 해결하는 것’이 본질입니다.

배포가 많지 않고 운영 복잡성이 없는 서비스에 컨테이너와 쿠버네티스를 도입하는 것은, 동네 골목길에서 장을 보러 가는데 덤프트럭을 몰고 나가는 것과 같습니다. 힘은 엄청나게 좋고 짐은 많이 실을 수 있겠지만, 좁은 골목길을 빠져나가느라 진땀을 빼야 하고 주차할 곳도 없어서 결국 스트레스만 받게 될 것입니다. 골목길 장보기에는 가벼운 경차나 자전거(VM)가 최고의 선택입니다.

최신 기술 유행에 주눅 들지 마세요. 내 서비스의 특성을 정확히 파악하고, 그에 가장 단순하고 효율적인 도구를 선택하는 엔지니어가 진짜 실력 있는 엔지니어입니다. 현재 VM 환경에서 서비스가 아무 문제 없이 평화롭게 잘 돌아가고 있다면, 여러분은 이미 최고의 인프라를 운영하고 계신 겁니다.

서비스의 특성을 고려한 인프라 아키텍처 설계와 구성… 이것이 실력입니다.

전문가의 인사이트 : 함께 읽어 보세요.

ExaCC NetBackup RMAN 연동 및 4가지 대안

참조 및 출처 URL:

https://research.ibm.com/publications/a-comparative-study-of-containers-and-virtual-machines-in-big-data-environment

VM vs Container, 무조건 유행을 따라야 할까?

VM vs Container, 무조건 유행을 따라야 할까?