마이그레이션 과정에서 각 단계마다 실측한 메모리 수치를 모아 "정말 좋아졌는가, 좋아졌다면 어떤 의미로 좋아졌는가"를 정리한다. 결론부터: 지표에 따라 결과가 갈린다 — 뻔뚝그려 "좋아졌다"고 하기보다 어떤 지표가 실제로 의미 있는지 구분해서 본다.
<table header-row="true"><tr><td></td><td>VMware (기존)</td><td>Multipass (신규)</td></tr><tr><td>마스터</td><td>2.5GB / 2vCPU</td><td>3GB / 2vCPU</td></tr><tr><td>워커 ×2</td><td>각 1.5GB / 2vCPU</td><td>각 1.5GB / 1vCPU</td></tr><tr><td>합계</td><td>5.6GB</td><td>6GB</td></tr></table>
신규 쪽이 오히려 400MB 더 할당했다. 마이그레이션 계획 단계에서 "여유 있게 잡아달라"는 요청에 따라 의도적으로 VMware 대비 더 넣넣한 스펙으로 잡았기 때문.
<table header-row="true"><tr><td>시점</td><td>호스트 여유 메모리</td></tr><tr><td>VMware 3대 풀가동 중</td><td>~260MB</td></tr><tr><td>VMware 3대 종료 직후</td><td>~3.6GB</td></tr><tr><td>Multipass 3대 + ArgoCD + 앱 전체 풀가동 중</td><td>~64MB</td></tr></table>
이 지표만 보면 신규 쪽이 더 안 좋아 보인다. 이유는 세 가지다: (1) VM에 애초에 400MB를 더 할당했다. (2) 측정 시점이 다르다 — VMware은 "그냥 켜져 있는" 상태, Multipass는 모든 것이 활발히 동작 중인 상태. (3) macOS의 "free" 페이지 수치는 원래 낮게 유지되는 게 정상이다 — 안 쓰는 RAM을 디스크 캐시로 적극 활용하는 구조라 free가 낮다고 곳 압박이 심하다는 뜻이 아니다.
즉, "호스트에 남는 메모리 총량"은 이번 마이그레이션으로 늘어난 게 아니다.
<table header-row="true"><tr><td></td><td>VMware 워커(server2)</td><td>Multipass 워커1</td><td>Multipass 워커2</td></tr><tr><td>used</td><td>941Mi</td><td>777Mi</td><td>916Mi</td></tr><tr><td>available</td><td>511Mi</td><td>674Mi</td><td>535Mi</td></tr><tr><td>swap 사용량</td><td>89Mi/2GB (4.5%)</td><td>0.26Mi (~0%)</td><td>8.6Mi (0.4%)</td></tr></table>
기존 VMware 워커는 평상시 운영 중에도 이미 swap을 4.5% 쓰고 있었다. 이건 K3s-Node-Resource-Planning-Troubleshooting에 기록된 "워커가 랜덤하게 NotReady로 빠지는 OOM 연쇄 장애"의 배경(스왕 압박 → 커널이 멈추어 네트워크 스택까지 응답 불가 → kubelet 하트비트 끓김 → NodeNotReady)와 정확히 일치하는 패턴이다.
신규 워커는 ArgoCD 전체 컴포넌트 + 앱 스택이 도는 상태에서도 swap을 사실상 쓰지 않는다.
아니다. 8GB 호스트 RAM 총량은 그대로다.
같은 양의 워크로드를 돌리는 데 필요한 swap 압박이 4.5% → ~0%로 줄었다. 마이그레이션 전체 과정 동안 OOM이나 노드 다운이 한 번도 없었다. 이게 실질적인 안정성 개선이며, "메모리가 늘었다"보다는 "같은 메모리로 더 안정적으로 도는다"에 가깝다.