| 일 | 월 | 화 | 수 | 목 | 금 | 토 |
|---|---|---|---|---|---|---|
| 1 | 2 | 3 | ||||
| 4 | 5 | 6 | 7 | 8 | 9 | 10 |
| 11 | 12 | 13 | 14 | 15 | 16 | 17 |
| 18 | 19 | 20 | 21 | 22 | 23 | 24 |
| 25 | 26 | 27 | 28 | 29 | 30 | 31 |
- aws
- 코틀린 코루틴의 정석
- AI
- CKA
- 바이브코딩
- 기록으로 실력을 쌓자
- CKA 기출문제
- 오블완
- kotlin coroutine
- 정보처리기사 실기 기출문제
- Kubernetes
- AWS EKS
- Pinpoint
- 공부
- Java
- 컨텍스트 엔지니어링
- PETERICA
- CloudWatch
- go
- tucker의 go 언어 프로그래밍
- SRE
- minikube
- kotlin
- Linux
- Spring
- MySQL
- golang
- 티스토리챌린지
- LLM
- APM
- Today
- Total
피터의 개발이야기
[AI Infra] 메모리는 용량이 아니라 채널이다 - Memory-bound 워크로드에서 놓치기 쉬운 서버 성능 포인트 본문
[AI Infra] 메모리는 용량이 아니라 채널이다 - Memory-bound 워크로드에서 놓치기 쉬운 서버 성능 포인트
기록하는 백앤드개발자 2026. 1. 29. 15:47
ㅁ 들어가며
점심시간에 크루들과 서버 메모리 구조에 대한 이야기를 나누다가, 생각보다 중요한 인프라 포인트들이 많다는 걸 다시 느꼈다.
우리는 보통 서버 스펙을 볼 때
- CPU 코어 수
- 메모리 용량(GB)
정도만 확인한다.
하지만 Memory-bound 워크로드를 운영하는 입장에서는, 이것보다 더 중요한 요소가 있다.
바로 메모리 채널 구성이다.
결론부터 말하면:
“메모리는 얼마나 많으냐보다, 어떻게 연결되어 있느냐가 더 중요할 수 있다.”
ㅁ CPU 소켓과 메모리 채널
일반적인 서버 CPU 하나(소켓)는 여러 개의 메모리 채널을 가진다.
최근 서버 기준으로는 보통 6~8채널이다.
중요한 포인트는 다음이다.
ㅇ 메모리는 채널 단위로 병렬 접근된다
ㅇ 채널 수 = 실질적인 메모리 대역폭
ㅇ 같은 용량이라도 채널 구성에 따라 성능이 달라진다
예를 들어,
128GB를 8채널에 분산 배치한 서버와
같은 128GB를 4채널만 사용한 서버는
이론적으로 메모리 대역폭이 거의 2배 차이 날 수 있다.
하지만 우리는 보통 “128GB 서버”라고만 인지한다.
DIMM이 어떻게 꽂혀 있는지는 거의 보지 않는다.
ㅁ DIMM 배치와 NUMA 구조에 대한 보충 설명
ㅇ DIMM 배치
DIMM은 그냥 메모리 모듈(RAM 한 장)이다.
서버 메인보드에는 이런 DIMM을 꽂는 슬롯이 여러 개 있고,
이 슬롯들은 메모리 채널(channel) 이라는 그룹으로 묶여 있다.
예를 들어,
CPU가 8채널이면 8개의 고속도로가 있고,
각 채널마다 DIMM 슬롯이 1~2개씩 달려 있다.
중요한 포인트는 CPU가 채널 단위로 병렬 접근이 가능하다는 점이다.
좋은 DIMM 배치는
모든 채널에 골고루 DIMM이 있고,
CPU가 동시에 여러 채널을 사용 가능해야 한다.
ㅇ NUMA = Non-Uniform Memory Access
뜻 그대로 메모리 접근 속도가 균일하지 않은 구조이다.
멀티 소켓 서버를 생각해보면 이해가 쉬워진다.
CPU0 ── RAM0
CPU1 ── RAM1
각 CPU는 자기 옆에 붙은 메모리를 가장 빠르게 접근한다.
하지만,
CPU0이 RAM1을 읽으려면
→ CPU 간 인터커넥트를 타고 넘어가야 합니다.
그래서:
- Local memory (붙어있는 RAM): 빠름
- Remote memory (다른 CPU 쪽 RAM): 느림
이 구조를 NUMA라고 한다.
비유적으로 표현하면,
ㅇ DIMM 배치
DIMM은 “메모리로 가는 차선 수”다 — 여러 차선을 쓰면 빠르고, 한 차선만 쓰면 막힌다.
ㅇ NUMA 구조
NUMA는 “CPU가 자기 집 냉장고를 쓰느냐, 옆집 냉장고를 쓰느냐”의 차이다.
문제는 VM / 컨테이너 환경이다.
ㅁ VM 환경의 구조적 한계
대부분의 개발/운영 환경은 VM 기반이다.
VM에서는 보통 다음만 보인다.
- vCPU
- 메모리 총량
반면 실제 물리 서버의
- 메모리 채널 수
- DIMM 배치
- NUMA 구조
같은 정보는 거의 투명해진다.
결과적으로,
- 슬롯이 절반만 채워진 서버
- 채널 불균형이 있는 서버
위에서 VM을 띄우고, 우리는 그 위에서 성능 튜닝을 한다.
이미 하드웨어 레벨에서 병목이 생긴 상태일 수 있다.
최악의 경우, VM 하나가
- CPU는 node0
- 메모리는 node1
이렇게 엇갈려 배치되면,
CPU → 원격 메모리 → 인터커넥트 → RAM
경로가 된다.
Memory-bound 서비스에서는 이게 치명적이다.
CPU는 놀고 있고, 메모리 접근만 계속 왕복하게 된다.
정리하면:
ㅇ DIMM 배치
메모리를 채널에 어떻게 나눠 꽂았는가
메모리 “대역폭”을 결정
ㅇ NUMA 구조
CPU와 메모리가 어느 노드에 속해 있는가
메모리 “지연시간”을 결정
둘 다 애플리케이션에서는 안 보이지만,
성능에는 직접적인 영향을 준다.
ㅁ CPU-bound vs Memory-bound
여기서 중요한 구분이 나온다.
ㅇ CPU-bound workload
- 연산이 병목
- 메모리 접근 비중이 낮음
- 인프라 차원에서 메모리를 타이트하게 잡아 집적도를 높이기도 함
ㅇ Memory-bound workload
- 메모리 대역폭이 병목
- CPU는 놀고 있는데 메모리가 막힘
- 채널 수와 DIMM 배치가 성능에 직접적인 영향
Memory-bound 서비스에서 채널을 절반만 쓰고 있다면,
CPU 내부 메모리 컨트롤러 단계에서 이미 병목이 시작된다.
이건 애플리케이션 최적화로 해결할 수 있는 문제가 아니다.
ㅁ 실제 운영에서 확인한 사례
같은 “128GB 서버”인데도,
어떤 장비는 6채널
어떤 장비는 4채널
로 구성된 사례를 직접 확인할 수 있다.
스펙상 동일해 보여도, 실제 메모리 대역폭은 다르다.
그래서 인프라 팀에 다음을 명시적으로 요청해야 한다.
- 메모리 풀 채널 구성
- DIMM 균등 배치
“메모리 많이 주세요”가 아니라 “채널을 다 써 주세요”라는 요구다.
Memory-bound 서비스에서는 이 차이가 꽤 크다.
ㅁ DDR4 vs DDR5 이야기
ㅇ DDR5는 단순히 클럭이 올라간 메모리가 아니다.
- 내부 구조가 더 잘게 분리되고
- 병렬성이 강화되었으며
- 채널 활용 방식도 달라졌다
앞으로는 “메모리를 얼마나 쓰느냐”보다 “채널을 어떻게 쓰느냐”가 더 중요해진다.
ㅁ Memory-bound 서비스 운영 체크리스트
ㅇ Memory-bound 워크로드를 다룬다면 최소한 아래는 확인하는 게 좋다.
- 물리 서버 메모리 채널 수
- DIMM 균등 배치 여부
- NUMA 구조
- VM이 어느 노드에 올라가 있는지
- 단순 용량이 아닌 실제 메모리 대역폭
가능하다면 인프라 요구사항에 다음을 포함시키자.
- “메모리 용량”이 아니라
- “메모리 채널 구성”
ㅁ 왜 로컬 LLM은 맥북 M 시리즈에서 유독 잘 돌아 가는가
앞에서 DIMM 배치와 NUMA 구조 이야기를 했는데,
이 관점에서 보면 Apple Silicon(M 시리즈)은 꽤 독특한 구조를 가진다.
기존 서버나 PC는 보통 다음과 같은 형태다.
CPU → 메모리 컨트롤러 → DIMM 슬롯 → RAM
이 구조에서는 자연스럽게
- 채널 불균형
- DIMM 배치 문제
- NUMA로 인한 원격 메모리 접근
같은 병목이 생긴다.
즉, 차선도 복잡하고, 냉장고도 멀리 있는 구조다.
반면 M 시리즈는Unified Memory Architecture(UMA)를 사용한다.
CPU, GPU, Neural Engine이 모두 하나의 메모리 풀을 직접 공유하는 구조다.
DIMM도 없고, NUMA도 없다.
모든 연산 유닛이 동일한 메모리 레이턴시로 접근한다.
비유하면,
집 한가운데 큰 냉장고 하나 두고, 모든 방이 바로 연결된 구조다.
그래서 로컬 LLM 환경에서 다음 같은 체감이 나온다.
- 모델 로딩이 빠르고
- GPU/CPU 간 복사 오버헤드가 없으며
- 대용량 컨텍스트에서도 상대적으로 안정적이다.
이건 단순히 “CPU가 빠르기 때문”이 아니라,
메모리 구조 자체가 다르기 때문이다.
Memory-bound 관점에서 보면 Apple Silicon은
DIMM과 NUMA를 구조적으로 제거해 버린 첫 대중적 플랫폼에 가깝다.
그래서 로컬 LLM, 벡터 검색, 멀티모달 파이프라인 같은 작업이 맥북에서 생각보다 부드럽게 돌아간다.
ㅁ 마무리
우리는 종종 애플리케이션만 바라본다.
하지만 성능의 시작점은 생각보다 훨씬 아래, 하드웨어에 있다.
특히 Memory-bound 시스템에서는 더더욱 그렇다.
다음번 서버 스펙을 볼 때는,
RAM 숫자 옆의 GB만 보지 말고 그 뒤에 숨은 채널 구조도 함께 보자.
작은 차이 같지만, 실제 서비스에서는 꽤 큰 차이가 된다.
이것이 오늘 함께 성장하는 크루의 점심식사에서 얻은 인사이트다.
'AI > AI실험 | 기록' 카테고리의 다른 글
| [AI] 헤커톤 준비 연습장 (1) | 2025.09.25 |
|---|---|
| IntelliJ Continue 1.0.44 버전 문제와 1.0.30 구버전 플러그인 직접 설치 (0) | 2025.09.22 |
| [Cursor] Cursor 단축키 정리 (1) | 2025.08.26 |
| [AI] 컨텍스트 정리 (0) | 2025.08.26 |
| [AI] 복붙해서 쓰는 학습 세션 컨텍스트(교사 모드) (3) | 2025.08.26 |
