Memory Bandwidth란? CPU와 메모리 사이에서 한 번에 전달할 수 있는 데이터량 쉽게 이해하기

CPU가 아무리 빨라도 필요한 데이터가 메모리에서 천천히 들어오면 계산을 이어가기 어렵습니다. 문제는 계산 능력이 아니라 데이터를 공급하는 속도일 수 있습니다. 이처럼 CPU와 메모리 사이에서 일정 시간 동안 얼마나 많은 데이터를 전달할 수 있는지를 Memory Bandwidth(메모리 대역폭)라고 합니다. 보통 GB/s처럼 초당 전송량으로 봅니다.

공장 생산 1,000개/초
재료 공급 100개/초
→ 실제는 공급 속도에 묶임

Latency와 Bandwidth

Memory Latency는 데이터 하나를 요청해 처음 도착하기까지 걸리는 시간입니다. Memory Bandwidth는 일정 시간 동안 총 얼마나 많이 보낼 수 있는가입니다. 택배 배송 1일(Latency)과 하루 몇 개를 실을 수 있는가(Bandwidth)는 다릅니다. 도착 시간이 같아도 도로 폭이 다르면 총량이 달라집니다.

Bandwidth Bound · Prefetch의 한계

10GB 배열을 순회해 더하는 것처럼 계산은 단순한데 Memory 이동이 크면 Memory Bandwidth Bound입니다. CPU Bound는 계산 장치가 한계이고, Bandwidth Bound는 데이터 공급이 한계입니다. CPU 사용률이 높아도 Stall·Miss·IPC를 함께 봐야 합니다. Prefetching·Out-of-Order는 Latency를 숨기는 데 도움이 되지만, 통로가 이미 포화되면 Prefetch를 더 해도 Bandwidth가 늘지 않고 Demand Load와 경쟁할 수 있습니다.

Latency: 미리 주문해 기다림을 숨김
Bandwidth: 하루 트럭 10대면 주문만 늘려도 총량은 그대로

Channel · 용량 · 이론값

Bandwidth는 Memory 종류·속도·Channel 수·컨트롤러·접근 패턴에 영향받습니다. Dual Channel처럼 통로가 늘면 더 높은 Bandwidth를 확보할 수 있고, RAM 슬롯 구성이 이에 맞춰야 합니다. 용량(GB)은 창고 크기, Bandwidth는 도로 폭입니다. Clock이 높으면 다른 조건이 같을 때 Bandwidth에 도움이 될 수 있지만 Timing·애플리케이션도 봐야 합니다. 사양상 Theoretical과 실제 Effective Bandwidth는 다를 수 있습니다.

공유 Bandwidth · Thread 포화

여러 Core가 같은 Memory System을 공유합니다. Core를 늘리면 처음엔 처리량이 오르다 통로 최대에서 멈출 수 있습니다 — Resource Contention. Thread를 더 늘려도 처리량이 안 오르고 Cache 경쟁·Context Switching만 늘 수 있습니다. 웹·DB·백업이 동시에 대량 Memory를 쓰면 경쟁이 나고, 무거운 Worker를 분리하는 Bulkhead도 도움이 됩니다. 대형 서버에서는 Local/Remote Memory 접근 비용이 다른 NUMA도 관련됩니다.

Cache · 재사용 · Zero-Copy

Cache Hit가 많으면 Main Memory 왕복이 줄어 Bandwidth 부담도 줄습니다. Miss가 늘면 Memory Traffic이 늘니다. 데이터 재사용·Tiling·구조체 크기 축소·필요한 필드만 모아 두는 SoA/AoS 선택은 이동량을 줄입니다. 불필요한 복사를 줄이는 Zero-Copy도 CPU와 Bandwidth를 아낍니다. CDN은 Origin의 데이터 이동 부담을 줄이는 쪽과 연결됩니다.

Arithmetic Intensity · GPU

Arithmetic Intensity는 데이터 한 번 가져와 계산을 얼마나 많이 하는가입니다. 낮으면 Memory Bound, 높으면 Compute Bound 경향이 강해집니다. Roofline Model은 계산 vs Bandwidth 중 무엇에 막히는지 보는 분석 틀입니다. GPU·AI는 대량 병렬이라 Bandwidth가 특히 중요하고, FLOPS만 보면 안 됩니다. SIMD로 계산을 빠르게 하면 Bottleneck이 Memory로 이동할 수 있습니다(Bottleneck Shift).

홈페이지에서는?

단순 홈페이지에서는 이미지·DB·JS·네트워크가 먼저입니다. RAM을 빠르게 바꿔도 API·DB 병목이면 체감이 거의 없을 수 있습니다. 이미지·영상·ML·대량 분석처럼 Memory를 많이 쓰는 작업에서 중요해집니다. 측정 시 작은 데이터는 Cache만 볼 수 있으니 Main Memory를 건드리는 크기로 보고, 모니터링으로 병목을 확인합니다. SEO 전용 개념은 아닙니다.

자주 묻는 질문

정리

Memory Bandwidth = CPU↔메모리 통로의 초당 처리량 한계입니다. Latency는 「하나 얼마나 빨리」, Bandwidth는 「한꺼번에 얼마나」입니다. 큰 배열·이미지·영상·AI처럼 데이터 이동이 많으면 Bandwidth Bound가 됩니다. Cache Locality·재사용·복사 감소·적절한 Thread 수를 함께 봅니다. 그런데 Core가 많을 때 모든 RAM에 같은 속도로 접근할 수 있을까요? 대형 서버에서는 CPU와 가까운 메모리와 먼 메모리의 접근 비용이 다를 수 있습니다. 이처럼 메모리 위치에 따라 접근 시간이 동일하지 않은 구조를 NUMA(Non-Uniform Memory Access)라고 합니다.