램 64GB가 필요한 사람은 따로 있습니다 — 32GB에서 올릴지 판정

Q: 로컬 LLM 때문에 고민입니다

16 vs 32 글의 그 절이 그대로 적용됩니다 — GPU 로 돌릴 거면 늘릴 것은 램이 아니라 VRAM입니다. 64GB 가 답이 되는 것은 CPU 추론으로 큰 모델을 상시 돌리는 계획이 있을 때이고, 그 속도의 한계는 GPU 없이 돌리기에 적어 뒀습니다.

Q: 128GB는요

위 ✅ 표의 작업이 직업의 중심인 경우의 이야기입니다 — 해석 규모, VM 수, 모델 크기가 숫자로 정해져 있고 그 합이 64를 넘는다는 계산이 서면 그때 가는 칸입니다. 계산 없이 갈 칸은 아닙니다.

16GB냐 32GB냐는 답이 거의 정해진 질문이 됐는데, 32GB 다음 칸은 커뮤니티마다 답이 갈립니다. "64는 오버다"와 "요즘 개발은 64부터다"가 같은 게시판에 공존합니다.

갈리는 이유는 간단합니다 — 64GB가 값을 하는 작업이 따로 있고, 그 작업을 하는 사람과 안 하는 사람이 서로 자기 기준으로 말하기 때문입니다.

결론부터

주 용도	판정
웹 개발 + 도커 + IDE	32GB로 대개 충분합니다
크롬 탭 수십 개 + 사무	32GB — 64는 체감이 없습니다
GPU 없이 CPU로 큰 모델 상시 사용	✅ 64GB 자리입니다
가상머신 여러 대 동시 가동	✅ 64GB 자리
영상 편집·3D·해석처럼 램을 지정해 먹는 작업	✅ 64GB가 값을 합니다
게임 성능	아닙니다 — 램 용량은 그 병목이 아닙니다

16 vs 32 글의 결론과 같은 원리입니다 — 남는 램은 성능이 되지 않습니다. 64GB는 "동시에 잡아두는 양"이 실제로 32GB를 넘는 작업에서만 값을 합니다.

먼저 — 지금 32GB가 정말 모자란지 확인

올리기 전에, 내 작업이 실제로 압박을 받는지 봅니다. 여기서 흔한 착시가 하나 있습니다.

램 사용량이 높은 것은 압박의 증거가 아닙니다. 운영체제는 남는 램을 파일 캐시로 채워 두는 게 정상 동작이라, 램이 클수록 "많이 쓰는 것처럼" 보입니다. 볼 것은 사용률이 아니라 모자랄 때 나오는 신호입니다.

작업을 평소처럼 잔뜩 벌려 놓고 작업 관리자(성능 → 메모리)에서:

커밋된 메모리가 물리 램을 크게 넘어서는가
압축 메모리가 수 GB 씩 쌓이는가 — 램이 모자라 눌러 담고 있다는 신호입니다
창을 오갈 때 한 박자 멈추는 체감이 있는가 — 디스크로 내려갔던 것을 다시 올리는 시간입니다

이 신호들이 없다면, 지금 용량에서 64GB로 올려도 아무것도 빨라지지 않습니다. WSL2가 램을 차지하는 문제처럼 용량이 아니라 배분이 원인인 경우도 있으니, 신호의 출처를 먼저 확인하는 게 순서입니다.

64GB가 값을 하는 작업의 공통점

위 표의 ✅ 줄들은 공통점이 있습니다 — 프로그램이 램을 명시적으로 크게 잡습니다.

가상머신 — VM 마다 램을 지정해 뗴어 줍니다. 8GB 짜리 서너 대면 그것만 수십 GB 입니다
CPU 추론 — 모델 전체가 램에 올라가야 합니다. 30B 급 모델을 CPU 로 돌리면 그 무게가 통째로 램 몫입니다
해석·렌더링·영상 — 작업 파일과 중간 결과가 램에 상주합니다. "로드율 100%"를 실제로 보는 직군입니다

반대로 웹 개발의 도커, IDE, 브라우저는 수백 MB~수 GB 단위로 먹는 것들이라, 아무리 겹쳐도 32GB 안에서 도는 경우가 대부분입니다. 커뮤니티에서 "도커까지 빡세게 굴려도 32로 된다"는 경험담과 "개발은 64부터"라는 말이 갈리는 지점이 — 후자는 대개 VM·데이터 작업이 섞인 경우입니다.

올리기로 했다면 — 구매의 구조

2개 슬롯이면 32GB×2 로 교체입니다 — 듀얼채널을 유지하는 구성이고, 기존 16GB×2 는 빼게 됩니다
4슬롯에 2개 추가(16×2 + 32×2 등)는 동작해도 속도·안정성에서 섞임 변수가 생깁니다 — XMP 적용이 같이 걸리는 자리라, 같은 제품 4개 또는 32×2 교체가 깔끔합니다
노트북이면 먼저 확인 — 온보드 램은 못 늘립니다. 슬롯 여부부터입니다

자주 묻는 질문

크롬 탭을 많이 열어 두는데 64GB가 낫지 않나요

탭 수십 개 수준이면 32GB 안에서 돕니다. 브라우저는 안 보는 탭을 알아서 재우기도 해서, 탭 때문에 64GB로 가는 계산은 대개 안 맞습니다.

램이 남으면 그래도 뭔가에 쓰이지 않나요

파일 캐시로 쓰입니다 — 한 번 읽은 것을 다시 읽을 때 빨라지는 효과는 있습니다. 다만 그건 "남는 램의 덤"이지 64GB를 살 이유가 되는 크기의 효과는 아닙니다.

로컬 LLM 때문에 고민입니다

16 vs 32 글의 그 절이 그대로 적용됩니다 — GPU 로 돌릴 거면 늘릴 것은 램이 아니라 VRAM입니다. 64GB 가 답이 되는 것은 CPU 추론으로 큰 모델을 상시 돌리는 계획이 있을 때이고, 그 속도의 한계는 GPU 없이 돌리기에 적어 뒀습니다.

미리 64GB로 사두면 나중에 편하지 않나요

"나중에 필요해질 작업"이 구체적으로 있다면 처음부터 32GB×2 구성이 슬롯 면에서 깔끔합니다. 막연한 대비라면 — 램은 필요해진 시점에 그때 규격으로 사는 편이 대개 계산이 맞습니다. 미래 대비 웃돈의 문제는 공유기 글에서 한 이야기와 같은 구조입니다.

128GB는요

위 ✅ 표의 작업이 직업의 중심인 경우의 이야기입니다 — 해석 규모, VM 수, 모델 크기가 숫자로 정해져 있고 그 합이 64를 넘는다는 계산이 서면 그때 가는 칸입니다. 계산 없이 갈 칸은 아닙니다.

정리

64GB는 "동시에 잡아두는 양"이 32GB를 실제로 넘는 작업의 물건입니다 — VM·CPU 추론·해석·영상이 그 목록입니다
올리기 전에 압박 신호를 확인하세요 — 사용률 높은 건 정상, 커밋 초과·압축 수 GB·전환 시 멈칫이 진짜 신호입니다
웹 개발 + 도커 + 브라우저는 32GB에서 대부분 돕니다
간다면 32GB×2 교체가 깔끔합니다 — 기존 램과 섞는 구성은 변수가 붙습니다
노트북은 슬롯 확인이 먼저입니다

용량 판정의 앞 단계는 16GB vs 32GB, 램이 늘 부족해 보이는 다른 원인은 WSL2 메모리에 있습니다.

기준이나 동작이 실제와 다르면 알려주세요. 확인 후 갱신합니다.