Memory Pooling이란? 여러 AI 서버가 메모리를 나눠 쓰는 방법

Data Center에는 많은 DRAM이 설치돼 있지만 그 Memory가 항상 효율적으로 사용되는 것은 아닙니다. Server마다 Peak Workload를 대비해 충분한 Memory를 설치해두지만 모든 Server가 같은 순간에 최대 Capacity를 사용하는 것은 아닙니다. 어떤 Server에는 수백 GB의 Memory가 남는데 바로 옆 Server는 Memory가 부족해 새로운 DIMM이나 Server를 추가해야 하는 상황이 발생할 수 있습니다.

Stranded Memory: 특정 Server나 CPU Socket에 물리적으로 묶여 있어 사용률이 낮아도 다른 Server가 활용하기 어려운 Memory Capacity를 의미합니다.

Memory Pooling: 여러 Host가 공통 Memory Resource Pool에 연결되고 Workload에 따라 필요한 Memory Capacity를 Host별로 동적으로 할당하거나 회수할 수 있도록 하는 Architecture입니다.

Pooling의 목표는 Memory를 무조건 더 많이 설치하는 것이 아닙니다. 이미 설치된 DRAM을 더 높은 Utilization으로 사용하는 것입니다.

먼저 Expansion과 Pooling을 구분해야 합니다

구분	Memory Expansion	Memory Pooling
Host	주로 1개	여러 Host
Memory 관계	특정 Host의 Capacity 추가	Pool에서 여러 Host에 동적 할당
핵심 목표	한 Server의 Memory 부족 해결	Data Center 전체 Utilization 개선
주요 Component	CXL Memory Controller	CXL Switch + Fabric Manager + Memory Device
Software 난도	상대적으로 낮음	Allocation·Topology 관리가 더 복잡

Memory Expansion이 “내 Server의 RAM을 더 늘리는 것”이라면 Pooling은 “여러 Server가 공통 Memory 창고를 이용하는 것”에 가깝습니다.

왜 Server마다 Peak Memory를 설치하는 것이 비효율적일까요?

Server A와 B가 각각 최대 2TB Memory를 필요로 할 수 있다고 생각해보겠습니다. 하지만 A가 Peak일 때 B는 500GB만 사용하고, B가 Peak일 때 A는 800GB만 사용할 수 있습니다.

기존 Architecture에서는 둘 다 2TB를 설치해 총 4TB를 준비해야 합니다. 실제 동시 사용량은 훨씬 적어도 Memory가 CPU Socket에 고정돼 있기 때문입니다.

Memory Pooling에서는 각 Server의 Base Memory를 유지하면서 Peak Capacity 일부를 Shared Pool에서 제공합니다. 그러면 전체 설치 Capacity를 줄이거나 같은 총 DRAM으로 더 많은 Workload를 수용할 가능성이 생깁니다.

이 경제성이 Hyperscaler에게 중요한 이유는 DRAM이 Data Center Semiconductor 비용과 Power에서 큰 비중을 차지하기 때문입니다.

CXL 2.0이 Pooling을 실제 Architecture로 만들었습니다

CXL 2.0은 Switching과 Memory Pooling을 공식적으로 지원합니다. 여러 Host와 여러 CXL Memory Device를 Switch에 연결하고 Fabric Manager가 Resource를 Host에 Bind하거나 Unbind할 수 있습니다.

예를 들어 CXL Memory Device 하나가 여러 Logical Device로 나뉘어 있을 수 있습니다. Fabric Manager는 Logical Device A를 Host 1에, B를 Host 2에 할당하고 Workload가 끝나면 다시 회수해 다른 Host에 재배치할 수 있습니다.

중요한 것은 Memory Chip을 물리적으로 옮기는 것이 아니라 주소공간과 Resource Ownership을 Software와 Fabric으로 재구성한다는 것입니다.

Fabric Manager는 무엇을 하나요?

Fabric Manager: CXL Fabric에서 Device Discovery, Resource Allocation, Logical Device Binding·Unbinding, Policy와 Topology 관리를 담당하는 Control-plane 기능입니다.

CXL Switch가 실제 Data를 전달하는 Data Plane이라면 Fabric Manager는 어떤 Host가 어떤 Memory를 사용할지 결정하는 Control Plane입니다.

Memory Pooling이 커질수록 이 역할이 중요합니다. 수십 개 Host와 수십 TB Memory가 연결된 Rack에서 운영자가 수동으로 Memory를 할당할 수는 없습니다. Workload Scheduler와 Fabric Manager가 연동해 Resource를 자동으로 배치해야 합니다.

Pooling과 Sharing은 같은 개념이 아닙니다

Memory Pooling: 공통 Resource Pool에서 Memory Capacity를 Host에 할당하는 것이 핵심입니다. 특정 Memory Region은 한 시점에 특정 Host에 귀속되는 구조가 일반적입니다.

Memory Sharing: 여러 Host나 Accelerator가 동일한 Memory Region을 동시에 접근하고 Data를 공유할 수 있는 Architecture입니다.

CXL 3.x는 Sharing Capability를 확대해 더 복잡한 Multi-host Memory Architecture를 지원합니다. Sharing이 성숙하면 여러 Accelerator가 같은 Data Set을 각자 복사하지 않고 공동으로 사용할 수 있는 새로운 Use Case도 가능해집니다.

하지만 Sharing은 Cache Coherency와 Security, Synchronization이 훨씬 어려워져 Pooling보다 높은 System Complexity를 요구합니다.

AI Inference에서 Pooling이 주목받는 이유

LLM Inference는 Training과 다른 Memory Profile을 가질 수 있습니다. Model Weight뿐 아니라 KV Cache가 큰 Capacity를 요구하고, Context Length와 동시 사용자 수가 늘어날수록 Memory Demand가 변동합니다.

모든 Inference Server에 Peak KV Cache를 대비한 Local DRAM이나 HBM을 설치하면 많은 Memory가 Idle 상태로 남을 수 있습니다. Shared CXL Memory Pool을 사용하면 Workload에 따라 필요한 Capacity를 더 유연하게 배분할 수 있습니다.

특히 Disaggregated Inference에서 Prefill과 Decode Resource가 분리되거나 여러 GPU가 다른 Memory Demand를 갖는 경우 Pooling의 경제적 가치가 커질 수 있습니다.

다만 KV Cache Access가 Latency에 민감한 경우 CXL Pool이 항상 최적은 아닙니다. 실제 Workload에서 Hot Data와 Cold Data를 구분해야 합니다.

Recommendation과 Database에도 적합할 수 있습니다

Recommendation System은 매우 큰 Embedding Table을 Memory에 보관할 수 있습니다. 모든 Data가 GPU HBM이나 CPU Local DRAM의 가장 낮은 Latency를 필요로 하지 않는다면 CXL Memory를 Capacity Tier로 활용할 수 있습니다.

In-memory Database와 Analytics도 Memory Capacity가 중요합니다. Database Instance마다 Peak Capacity를 개별 Provision하는 대신 Pool을 이용하면 Memory Utilization을 높일 여지가 있습니다.

따라서 CXL Pooling은 AI 전용기술이 아니라 Memory-intensive Cloud Workload 전반에 적용될 수 있는 Infrastructure Architecture입니다.

Pool이 멀어질수록 Latency가 커집니다

Pooling의 가장 큰 Trade-off는 Latency입니다. Local DDR은 CPU Memory Controller에 직접 연결돼 있지만 CXL Pool Memory는 CXL Controller와 Switch를 통과합니다.

Switch가 여러 단계로 늘어나거나 Cable Reach가 길어지면 Latency가 더 증가합니다. 따라서 모든 Memory를 하나의 거대한 Pool에 두는 것이 항상 좋은 것은 아닙니다.

현실적인 Architecture는 Local DRAM을 Low-latency Tier로 두고 CXL Pool을 Capacity Tier로 사용하는 방식입니다. Software가 Access Frequency와 Page Hotness를 분석해 Data를 적절한 Tier에 배치해야 합니다.

NUMA가 더 복잡해집니다

NUMA(Non-Uniform Memory Access): Processor 위치에 따라 Memory Access Latency와 Bandwidth가 달라지는 Architecture입니다.

Multi-socket Server에서도 이미 Local Socket Memory와 Remote Socket Memory의 Latency가 다릅니다. CXL Pooling이 추가되면 Direct-attached CXL, Switch-attached CXL, 다른 Rack의 Memory처럼 더 많은 Latency Tier가 생길 수 있습니다.

Application이 이 차이를 모르고 Random하게 Memory를 사용하면 Capacity는 늘었는데 Performance는 오히려 떨어질 수 있습니다. CXL Pooling의 성공에는 Topology-aware Memory Management가 필수적입니다.

Software Scheduler와 Memory Fabric이 연결돼야 합니다

Cloud Data Center에서는 Kubernetes나 VM Scheduler가 Compute Resource를 할당합니다. Memory Pooling이 실제 효율을 높이려면 Scheduler가 “어느 Rack에 얼마나 CXL Memory가 남아 있는가”를 알고 Workload를 배치할 수 있어야 합니다.

또 Workload가 종료되면 Memory를 안전하게 초기화하고 다른 Tenant에 재할당해야 합니다. Security와 Data Remanence 문제도 해결해야 합니다.

즉 Pooling의 경제성은 CXL Switch Hardware만으로 만들어지는 것이 아니라 Cloud Orchestration Software와 Fabric Manager의 통합에서 나옵니다.

2026년에는 Rack-scale Pooling Silicon이 구체화되고 있습니다

Marvell은 2026년 Structera S 30260을 발표했습니다. 이 Device는 PCIe 6/CXL 3.x 기반 260 lanes를 제공하고 16개 또는 32개 CPU·GPU와 최대 48TB Shared Memory, 최대 4TB/s Aggregate Bandwidth를 목표로 합니다.

기존 Structera S 20256 CXL 2.0 Switch는 Production 단계이고 30260은 2026년 3분기 Sampling 예정입니다.

이 변화는 Memory Pooling이 소규모 Demo에서 벗어나 Rack-level Product Architecture로 이동하고 있다는 신호입니다. 다만 Sampling과 실제 Hyperscaler Volume Deployment는 구분해야 합니다.

Samsung과 SK hynix도 Pooling을 전제로 Memory Module을 발전시키고 있습니다

Samsung MD310은 CXL 3.2와 PCIe Gen6를 지원하며 Open PCIe/CXL Fabric Architecture에서 여러 Host가 Pooled Memory를 동적으로 공유하고 할당할 수 있는 방향을 제시합니다.

SK hynix는 2026년 HPE Discover에서 CXL 3.2 기반 256GB CMM-DDR5와 Liqid의 CXL Pooled Memory Server를 함께 전시했습니다. 이는 Memory Vendor도 단순 Module 판매보다 Pooling Ecosystem을 실제 Server Solution과 연결하고 있음을 보여줍니다.

Memory 업체에게 중요한 질문은 “CXL DIMM을 몇 개 파느냐”뿐 아니라 Pooling이 DRAM의 사용방식과 Demand Pattern을 어떻게 바꾸느냐입니다.

Pooling은 DRAM 수요를 줄일 수도 있습니다

이 부분은 투자 관점에서 매우 중요합니다.

Pooling의 목적은 Stranded Memory를 줄이는 것입니다. Server마다 2TB씩 설치하던 환경을 Shared Pool로 바꾸면서 전체 설치 DRAM을 줄일 수 있다면 Unit당 DRAM Demand는 감소할 수 있습니다.

반대로 Memory를 더 쉽게 확장할 수 있게 되면서 기존에는 Cost 때문에 실행하지 못한 Large-memory Workload가 늘어날 수도 있습니다. AI Inference와 Database가 더 큰 Memory를 사용하면 총 DRAM Demand가 증가할 가능성도 있습니다.

따라서 Pooling은 Memory 업체에 단순한 “수요 증가 기술”이 아니라 Memory Utilization과 Price Elasticity를 동시에 바꾸는 기술입니다.

Pooling의 진짜 경제성은 TCO에서 결정됩니다

CXL Switch와 Controller, Cable을 추가하면 Hardware Cost와 Power가 생깁니다. Software Complexity와 운영비용도 늘어납니다.

따라서 Pooling이 성공하려면 절감되는 DRAM Overprovisioning, CPU Socket Cost와 Server 수가 추가 Fabric Cost보다 커야 합니다.

고가의 대용량 DRAM을 많이 사용하는 Workload에서는 경제성이 좋을 수 있지만 Memory가 저렴하거나 Access Latency가 매우 중요한 Workload에서는 이점이 작을 수 있습니다.

결국 CXL Pooling Adoption은 Benchmark 숫자보다 실제 Data Center의 Total Cost of Ownership에서 결정됩니다.

Failure Domain도 커집니다

Local Memory는 Server 장애가 해당 Node에 주로 국한됩니다. Shared Memory Pool에서 Switch나 Memory Shelf가 장애를 일으키면 여러 Host가 영향을 받을 수 있습니다.

따라서 Switch Redundancy, Error Isolation, Hot-plug, Memory Sparing, Fabric Manager High Availability가 중요합니다. Resource Sharing의 효율이 커질수록 Shared Infrastructure의 Reliability 요구도 높아집니다.

AI Job은 수천 GPU가 함께 동작하기 때문에 Memory Fabric 장애가 GPU Utilization을 크게 떨어뜨릴 수 있습니다. Pooling은 Capacity Technology인 동시에 RAS Architecture이기도 합니다.

투자 관점에서 무엇을 봐야 할까요?

첫 번째는 CXL Switch와 Controller의 Design Win입니다. Module Demo보다 실제 Server·Rack Platform에 Switch가 들어가는지가 중요합니다.

두 번째는 Pool Size와 Utilization입니다. 몇 TB Memory를 공유하는지보다 실제 Stranded Memory를 얼마나 줄이고 TCO를 얼마나 개선하는지 확인해야 합니다.

세 번째는 Software Maturity입니다. OS Tiering, Fabric Manager, Cloud Scheduler와 Monitoring이 안정적으로 통합돼야 대규모 Production이 가능합니다.

네 번째는 DRAM Demand Effect입니다. Pooling이 Capacity Growth를 자극하는지, Overprovisioning을 줄이는지 Workload별로 나눠 봐야 합니다.

핵심 정리

질문	답
Memory Pooling이란?	여러 Host가 공통 CXL Memory Pool에서 Capacity를 동적으로 할당받는 Architecture입니다
Expansion과 차이는?	Expansion은 한 Host의 Memory를 늘리고 Pooling은 여러 Host의 Utilization을 최적화합니다
Sharing과 차이는?	Pooling은 Allocation 중심이고 Sharing은 같은 Memory Region의 동시 접근까지 포함합니다
왜 AI에 중요할까요?	Inference·KV Cache·Embedding처럼 Capacity Demand가 변동하는 Workload를 유연하게 운영할 수 있습니다
가장 큰 과제는?	Latency, NUMA, Software, Security와 Failure Domain입니다
DRAM 수요는 무조건 늘까요?	아닙니다. Capacity 확대와 Overprovisioning 절감 효과가 동시에 존재합니다
투자포인트는?	CXL Switch·Controller Design Win, 실제 Pool Utilization, Software와 TCO입니다

Memory Pooling의 본질은 더 많은 Memory를 사는 데 있지 않습니다. Memory를 Server마다 소유하는 방식에서 Data Center 전체가 공유하고 배분하는 방식으로 바꾸는 것입니다.

이 변화가 경제성을 증명하면 Memory도 CPU와 GPU처럼 Scheduler가 할당하는 Composable Resource가 될 수 있습니다. CXL은 그 Resource Pool을 실제 Hardware에서 가능하게 만드는 기반기술이고, Memory Pooling은 CXL이 Server Architecture를 바꾸는 가장 중요한 Use Case 중 하나입니다.