M3 맥북 Docker Desktop 메모리 4GB vs 8GB 할당 성능 비교

컨테이너 세 개 띄웠는데 갑자기 OOM Kill이 날아왔어요. 로그 확인해보니 Docker VM이 메모리를 다 잡아먹고 있었죠. M3 맥북 사용자라면 한 번쯤 겪어봤을 장면이에요.

Apple Silicon 기반 맥북 사용자가 급격히 늘면서 Docker Desktop 메모리 설정이 개발 워크플로우의 핵심 변수가 됐어요. 기본값인 4GB로 쓸지, 8GB로 올릴지 — 이 선택이 실제 개발 경험에 얼마나 영향을 주는지 데이터 기반으로 파고들어 볼게요.

핵심 요약

• Docker Desktop 기본 메모리는 4GB이며, M3 맥북 환경에서 컨테이너 세 개 이상을 동시에 올리면 OOM Kill이 빈번하게 발생해요.
• 8GB 할당 시 멀티 컨테이너 환경에서 기동 시간이 평균 40% 단축되고, 스왑 사용 빈도가 눈에 띄게 줄어요.
• M3 MacBook Pro 기준 전체 RAM 18GB 이상이라면, 8GB 할당이 호스트 성능 저하 없이 안정적으로 유지돼요.
• 로컬 Kubernetes 클러스터(minikube, kind)를 돌린다면 8GB는 사실상 최소 권장 수치에 가까워요.

지금 이게 문제가 된 이유

Apple Silicon이 등장한 건 2020년이지만, Docker가 ARM 네이티브 지원을 본격적으로 안정화한 건 2022–2023년부터예요. M3 칩이 나온 2023년 말을 기점으로 macOS 기반 컨테이너 개발 환경이 확 달라졌죠.

Docker Desktop은 macOS 위에서 경량 Linux VM(LinuxKit 기반)을 띄운 뒤 그 안에서 컨테이너를 실행해요. 즉, Docker 컨테이너가 macOS 커널을 직접 쓰는 게 아니라 VM 레이어를 하나 더 거치는 구조예요. 이 VM에 메모리를 얼마나 줄지가 Docker Desktop 설정의 핵심이에요.

기본값은 4GB. 그런데 요즘 흔한 개발 스택을 보면 이 숫자가 얼마나 빠듯한지 금방 보여요.

• Node.js 앱 + PostgreSQL + Redis: 약 2.5–3.5GB
• Spring Boot + MySQL + Nginx: 약 2.8–4.2GB
• Python FastAPI + MongoDB + Celery Worker: 약 3.0–4.5GB

세 서비스만 올려도 4GB 한계에 닿는 경우가 많아요. 컨테이너가 갑자기 죽는 이유 중 상당수가 바로 이 VM 메모리 부족, OOM Kill이에요. 컨테이너 프로세스 자체의 문제가 아니라 VM 레이어에서 메모리가 부족해 강제 종료하는 거예요.

Colima 같은 대안 런타임도 기본 메모리 설정이 2–4GB 수준이고, 튜닝하지 않으면 볼륨 마운트 속도 저하나 예기치 않은 컨테이너 종료 문제가 생기는 건 마찬가지예요.

4GB vs 8GB: 체감 성능 실제로 어떻게 다른가?

멀티 컨테이너 기동 속도

docker compose up으로 서비스 4–5개를 동시에 올릴 때 차이가 가장 두드러져요.

4GB 환경에서는 VM이 메모리 압박을 받으면 스왑을 쓰기 시작해요. M3 맥북의 내장 SSD가 빠른 편이긴 하지만, 스왑이 발생하는 순간 기동 시간이 두 배 이상 늘어나는 경우가 잦아요. 8GB 환경에서는 스왑 없이 RAM 안에서 처리가 끝나기 때문에 기동이 훨씬 빠르죠.

Reddit r/docker, Docker 공식 포럼에서 공유된 사례들을 보면, M2/M3 맥북에서 4→8GB로 올린 후 compose up 속도가 30–50% 빨라졌다는 경험담이 반복적으로 등장해요.

OOM Kill 발생 빈도

컨테이너가 “나만 죽는” 현상, 개발하다 보면 진짜 황당하죠. Docker의 OOM Killer는 VM 내 메모리가 한계에 달하면 가장 많은 메모리를 쓰는 프로세스를 골라 종료해요. 4GB 환경에서 무거운 JVM 기반 앱(Spring Boot 등)을 올리면, 이 앱이 1–1.5GB씩 먹으면서 다른 컨테이너를 밀어내요.

8GB로 올리면 이 현상이 거의 사라져요. VM에 여유 공간이 생기니까요.

비교 표: 4GB vs 8GB 핵심 지표

로컬 Kubernetes 환경에서의 차이

minikube나 kind를 써봤다면 알겠지만, 이 도구들은 VM 안에 Kubernetes 컨트롤 플레인을 올려요. 4GB 환경에서 minikube를 기본 설정으로 실행하면, kube-apiserver + etcd + coredns만으로도 1.5–2GB를 소모해요. 거기에 실제 앱 파드까지 올리면 4GB는 순식간에 한계에 도달하죠.

Docker Desktop 공식 문서도 Kubernetes 기능 활성화 시 최소 6GB 이상을 권장하고 있어요. 8GB는 이 경우 사실상 시작점에 가까워요.

어떤 상황에서 무엇을 선택해야 할까?

상황 1 — 단일 서비스 + DB 조합 개발자

프론트엔드 앱 하나에 PostgreSQL 정도만 올린다면 4GB로 충분해요. 이 구성의 실제 메모리 사용량은 1.5–2.5GB 선이거든요. 굳이 8GB를 줄 필요가 없어요. 권장 설정: 4GB 유지, 스왑 1–2GB 설정.

상황 2 — 풀스택 MSA 환경 개발자

백엔드 서버 여러 개 + DB + 캐시 + 메시지 큐까지 올린다면 4GB는 매일 OOM Kill을 겪는 환경이에요. 8GB로 올리는 게 맞아요. M3 MacBook Pro 18GB 모델 이상이라면, 8GB를 Docker에 줘도 호스트에 10GB가 남아서 IDE와 브라우저가 무리 없이 돌아가요.

상황 3 — 로컬 Kubernetes + CI 환경 시뮬레이션

minikube, kind, k3d 같은 로컬 쿠버네티스를 쓴다면 8GB는 최소 기준이고, 여유 있으면 10–12GB까지 고려해볼 만해요. 단, M3 MacBook Air 8GB 모델에서 이걸 시도하면 호스트가 버벅거려요. 이 경우엔 Colima + 리소스 제한 조합이 더 현실적이에요.

정리: 메모리 숫자보다 중요한 건 워크로드 파악

핵심만 짚으면 이렇게 돼요.

• 4GB: 단순한 로컬 개발, 서비스 1–2개 수준이면 충분해요
• 8GB: 풀스택, MSA, 로컬 쿠버네티스 — 이게 기본이 되어야 하는 환경들이에요
• 컨테이너를 세 개 이상 동시에 올린다면 8GB 설정이 일상의 마찰을 줄여줘요. 결론은 그만큼 단순해요.
• Docker Desktop은 Apple Silicon 최적화를 계속 강화하고 있고, VirtioFS 개선과 메모리 동적 회수 기능 업데이트가 예고돼 있어요. 이 기능이 안정화되면 고정 할당의 필요성이 낮아질 수 있어요.

메모리 숫자를 바꾸기 전에, 지금 내 docker stats 출력을 먼저 확인해보세요. 실제로 얼마나 쓰고 있는지 보고 결정하면, 어떤 설정이 맞는지 바로 보여요.

지금 가장 자주 쓰는 컨테이너 조합을 기준으로 숫자를 맞추면, 설정 한 번으로 하루 수십 번의 작은 마찰이 사라질 수 있어요.

참고자료

1. [환경구축] 1. Docker 설치하기 (맥북 M4 기준)
2. Colima 도커 개발환경 파일 동기화·볼륨·리소스 튜닝 팁
3. Docker 컨테이너가 나만 죽는 이유와 해결방안

Photo by Jarrod Erbe on Unsplash