마이그레이션 과정에서 실제로 관찰한 사실을 바탕으로 정리. 착수 전 예상했던 것과, 실제로 격고 나서 확인된 것을 구분해서 기록한다.

1. 결론부터

<table header-row="true"><tr><td></td><td>예상(착수 전)</td><td>실측(마이그레이션 후)</td></tr><tr><td>하이퍼바이저 교체 자체의 메모리 절감</td><td>"있긴 하는데 크지 않을 것"</td><td>예상보다 확실히 체감됨</td></tr><tr><td>가장 큰 이득의 원천</td><td>VM 스펙 재설계(5.6GB→6GB는 사실 큰 차이 아님)</td><td>재설계보다 런타임 안정성(스왕 미사용)이 더 크게 체감됨</td></tr><tr><td>운영 편의성</td><td>Multipass가 CLI라 더 가벼울 것</td><td>가벼운건 맞지만 VMware의 GUI 콘솔/스냅샷 부재가 아쉬움</td></tr></table>

2. Multipass의 장점

2.1 하이퍼바이저 오버헤드가 실제로 낮다

같은 "합계 메모리 할당"(VMware 5.6GB vs Multipass 6GB, 큰 차이 없음)인데도 결과가 다르다. VMware 운영 중 memory_pressure 기준 호스트 여유 메모리 260MB, vmware-vmx 프로세스 3개가 압축 메모리로 각각 3975M/2619M/2513M을 잡아먹고 있었다. Multipass 운영 중은 동일 8GB 호스트에서 워커 노드 available 535~674Mi, swap 사용량 268Ki~8.6Mi(사실상 미사용)로 여유 있게 돌았다.

이 환경은 qemu 드라이버(Apple Hypervisor.framework/HVF 가속)를 쓰는데, VMware처럼 SVGA 3D 에뮬레이션, VMware Tools 데몬, 체크포인트 관리 같은 걸 아예 안 하기 때문으로 보인다.

2.2 CLI 자동화가 훨씬 쉽다

multipass launch/exec/transfer/stop/start/set 만으로 VM 생성부터 파일 전달, 리소스 조정까지 전부 스크립트화 가능했다.

2.3 디스크/메모리 증설이 명령 한 줄

multipass set local.<vm>.disk=14G로 디스크를 늘릴 수 있었다(VM 정지 필요).

3. Multipass의 단점 / 실제로 격은 문제

3.1 디스크 온라인 리사이즈 불가 — 실제 장애 유발

Multipass는 VM이 정지된 상태에서만 디스크를 늘릴 수 있다. 마이그레이션 중 워커 디스크를 6GB로 잡았다가 ArgoCD 이미지 pull 도중 no space left on device로 실패하고, DiskPressure까지 발생해 파드가 무더기로 멈첐다.

3.2 이미지 캐시 손상 이슈

multipass launch 24.04가 첫 시도에서 해시 불일치 에러로 실패했다. 재시도하니 자동 재다운로드되어 해결됨.

3.3 SSH 접속 경험이 기본적으로 다르다

Multipass는 기본 계정이 ubuntu이고, Ubuntu cloud image 기본값이 PasswordAuthentication no라 비밀번호 로그인을 켜려면 별도 override 파일이 필요하다.

3.4 GUI 콘솔 부재

VMware Fusion은 부팅 실패, 네트워크 미기동 등 SSH조차 안 붙는 상황에서 콘솔 GUI로 직접 화면을 볼 수 있다. Multipass는 기본적으로 headless라 이런 저수준 디버깅이 어렵다.