왜 지금 CXL 3.0인가
H100·B200 한 장에 HBM 192GB가 붙는 시대에도, AI 서버 전체로 보면 메모리는 여전히 부족합니다. LLM 추론은 KV cache로 DRAM을 게걸스럽게 먹고, 학습은 옵티마이저 상태로 host 메모리를 빨아들입니다. 동시에 한 노드 안에서 CPU 옆 DDR5 슬롯은 채널 수와 DPC(DIMM-per-channel) 제약으로 더 늘리기 어렵습니다.
이 균열에 CXL 3.0이 들어옵니다. 2022년 8월 컨소시엄이 공개한 스펙은 단순한 PCIe 확장이 아니라, 노드 간 메모리 풀(pool)과 공유(sharing), fabric 라우팅을 정식 지원합니다. 2026년 들어 Intel Granite Rapids, AMD Turin이 풀링 시나리오를 본격적으로 받아들이면서, 기존 'PoC 데모' 단계에서 'TCO 모델 안에 들어오는 옵션'으로 위상이 바뀌고 있습니다.
HBM이 다이 옆에서 풀어내지 못하는 영역 — 노드·랙 단위로 묶이는 거대한 working set — 에 대한 답으로 CXL이 본격 호명되는 시점이라는 뜻입니다.
CXL 3.0의 기술 실체
CXL은 한 장의 PCIe 위에서 세 개의 프로토콜을 다중화합니다. CXL.io는 기존 PCIe 트래픽(configuration, DMA), CXL.cache는 디바이스가 호스트 캐시 라인을 코히어런트하게 가져오는 채널, CXL.mem은 호스트가 디바이스 메모리를 자신의 주소 공간으로 매핑하는 채널입니다.
3.0에서 추가·강화된 포인트는 다음과 같습니다.
- PHY 64GT/s — PCIe 6.0 PAM4 + FEC + flit 모드. 같은 lane 수 기준 CXL 2.0 대비 대역폭 2배.
- Multi-headed device — 하나의 메모리 모듈을 최대 16개 호스트가 직접 연결. 풀링 효율을 한 단계 끌어올린 핵심.
- Port-based routing(PBR) — fabric 안에서 패킷이 헤드 노드뿐 아니라 여러 스위치를 거쳐 라우팅 가능. 사실상 datacenter-scale fabric으로 확장.
- Peer-to-peer — GPU·NIC·메모리 디바이스끼리 호스트를 거치지 않고 직접 통신. 호스트 CPU 병목을 우회.
- Memory sharing — 풀링이 '한 번에 한 호스트만'이라면, sharing은 동일 영역을 여러 호스트가 동시에 보고 하드웨어 코히어런스를 유지하는 모델.
디바이스 분류는 type-1(accelerator with cache, 예: SmartNIC), type-2(accelerator with memory, 예: GPU 일부), type-3(memory expander)로 나뉩니다. 시장에서 가장 빨리 자리 잡은 것은 단연 type-3입니다. 96GB·256GB·512GB DDR5 기반 모듈이 E3.S·AIC·EDSFF 같은 form factor 별로 등장하고 있고, 이쪽이 본격적으로 매출을 만드는 첫 영역입니다.
왜 어려운가 — latency, 스위치 silicon, SW 스택
CXL 3.0의 진짜 어려움은 'PHY가 빨라졌다'가 아닙니다. 시스템 레벨로 올라갈수록 매듭이 많습니다.
첫째, latency budget. 로컬 DDR5 access가 약 80–100ns, CXL.mem 1-hop attach가 공개 발표 자료 기준 170–250ns 대로 보고됩니다. 스위치를 한 단 더 거치면 +50–80ns. fabric으로 가면 NUMA보다 한 계층 더 먼 메모리가 됩니다. OS와 hypervisor가 이 계층을 인식하지 못하면, hot 데이터가 엉뚱하게 CXL 메모리에 떨어져 워크로드 latency가 망가집니다.
둘째, switch silicon 복잡도. CXL 3.0 fabric switch는 PCIe 6.0 SerDes + flit-mode 라우팅 + 코히어런스 디렉토리 + 다중 호스트 권한 격리를 모두 한 칩에 담아야 합니다. PAM4 64GT/s 자체가 SI/PI 측면에서 까다롭고, FEC가 들어가면서 cut-through 라우팅 설계가 어려워집니다. 결과적으로 die size·전력·열까지 모두 부담이 되는 구조입니다.
셋째, 소프트웨어 스택. Linux는 5.x부터 CXL 1.1/2.0 hot-plug와 NUMA 노드 매핑을 점진적으로 받아들였지만, 3.0의 sharing·peer-to-peer·fabric 토폴로지를 다 활용하려면 kernel·hypervisor·런타임(KVM, Kubernetes의 메모리 어드미션, DB 엔진의 page placement)까지 손봐야 합니다. 하드웨어가 먼저 가고 SW가 따라오는 전형적인 패턴입니다.
넷째, 보안/멀티테넌시. 여러 호스트가 메모리 영역을 공유하면 IOMMU만으로는 부족하고, 하드웨어 keying·메모리 암호화(TEE-IO와 결합)가 사실상 필수 요건이 됩니다. 이 마지막 매듭이 풀려야 클라우드 인스턴스 단위에서 sharing이 켜질 수 있습니다.
누가 잘하고 있나 — 컨트롤러·스위치·CPU
- Astera Labs — Leo CXL controller 시리즈로 type-3 메모리 컨트롤러 시장을 선점. 하이퍼스케일러 deploy 보고가 가장 자주 나오는 회사.
- Marvell — Structera 라인으로 CXL 메모리 + accelerator 통합 컨트롤러를 밀고 있고, near-memory compute로 확장 중.
- Microchip — SMC 2000 시리즈로 type-3 컨트롤러 대중화에 기여.
- Samsung — CMM-D(CXL Memory Module-DRAM) 256GB·512GB 모듈, CMM-H 하이브리드(NAND+DRAM), CMM-DC compute-near-memory까지 라인업이 가장 폭넓음. 자체 컨트롤러 IP 보유.
- SK하이닉스 — 96GB DDR5 기반 CXL 모듈을 일찌감치 발표, 메모리 풀링 SW를 묶은 시스템 데모를 진행. 컨트롤러는 자체+파트너 조합.
- Intel — Sapphire Rapids부터 CXL 1.1, Granite Rapids/Sierra Forest에서 2.0+, 차기 Diamond Rapids가 3.0 본격 지원으로 알려져 있음(보도 기반).
- AMD — Genoa부터 CXL 1.1+, Turin에서 풀링 시나리오 강화. 차세대 Venice가 3.0/3.1로 갈 것으로 보도되고 있음.
- Nvidia — 자체 NVLink·NVSwitch가 강력해 CXL 의존도는 상대적으로 낮지만, 호스트-측 메모리 풀에서는 호환을 받아들이는 방향.
회사별 차이의 본질은 단순 PHY가 아니라 컨트롤러의 latency 최적화 + tier-aware SW 스택의 성숙도입니다. PHY는 표준이라 차이가 좁혀지지만, 풀·sharing 시나리오에서 실제 워크로드가 도는 데까지는 한 단계 더 필요합니다.
Korea 시각 — 모듈은 강하지만 silicon은?
CXL은 한국 메모리 산업에 두 얼굴입니다. 한쪽으로는 DDR5/HBM 의존도 외에 세 번째 메모리 매출 카테고리가 열리는 기회. 다른 쪽으로는 컨트롤러·스위치 silicon 부재라는 구조적 약점이 다시 노출되는 자리입니다.
Samsung과 SK하이닉스는 모듈 사업자로서는 글로벌 톱이지만, 그 안에 들어가는 컨트롤러 칩은 Astera·Marvell·Microchip·자체 ASIC의 조합입니다. 자체 컨트롤러 IP 보유 측면에서 Samsung이 더 적극적이고, SK하이닉스는 협력 파트너 폭을 넓히는 모델을 가져갑니다. 모듈 + 컨트롤러를 한 회사가 통합하면 마진율이 올라가지만, 동시에 사이클 리스크도 같이 떠안는 구조입니다.
스위치 silicon으로 가면 한국 fabless의 그림자는 더 짙습니다. fabric switch는 PCIe 6.0 SerDes IP + 대용량 코히어런스 디렉토리 + 멀티-호스트 보안까지 묶어야 하는데, 국내 스타트업·연구소 단위 시도는 있지만 양산 트랙으로 올라온 사례는 아직 제한적입니다.
장기적으로 한국이 가져갈 수 있는 포지션은 두 가지입니다. (1) 모듈 + 컨트롤러 in-house 통합으로 Samsung·SK가 상위 부가가치를 흡수하는 시나리오. (2) K-CXL 형태의 IP 컨소시엄으로 fabless·시스템 회사가 함께 컨트롤러/스위치 IP 풀을 만드는 시나리오. 정부 사업으로 일부 진행되고 있으나, 하이퍼스케일러 채택으로 이어지려면 SW 스택과 reference design까지 묶어 수출하는 그림이 필요합니다.
Watch points — 다음 6–12개월
다음 6–12개월 안에 CXL 3.0의 채택 곡선을 결정할 milestone:
- Intel Diamond Rapids · AMD Venice의 CXL 3.x 공식 지원 범위 발표. 풀링/sharing 중 어디까지 ON-by-default로 들어가는지가 채택 속도를 좌우.
- 하이퍼스케일러의 첫 fabric-grade deploy. Meta·MS·Google이 작은 cluster에서 CXL 풀을 실제 production traffic에 노출하는지가 핵심 시그널.
- Samsung CMM-D 차세대 모듈(512GB+ 또는 컴퓨트 통합형) 양산 일정과 SK하이닉스 후속 라인업.
- CXL 3.1 보안(TEE-IO 결합) 인증 진행 — 멀티테넌트 환경에서 sharing이 도입되려면 사실상 prerequisite.
- Linux mainline의 fabric·sharing 인식 NUMA 정책 안정화. kernel 6.x 후반에서 7.x로 넘어가는 흐름을 주목.
빠른 정리 / FAQ
- CXL 3.0 ≠ PCIe 6.0? PHY는 공유하지만 프로토콜·코히어런스·fabric 의미론이 별개입니다. 같은 케이블이라도 모드가 다릅니다.
- HBM을 대체하나? 아닙니다. HBM은 다이 옆 ultra-low latency, CXL은 노드·랙 단위의 메모리 풀입니다. 계층이 다르고 보완 관계입니다.
- 언제 일반 기업 서버에 보이나? 클라우드 인스턴스에는 2026~2027 사이 type-3 풀부터 표면적으로 등장할 가능성. sharing·fabric 시나리오는 더 늦게.
- 한국 엔지니어가 준비할 것은? kernel/NUMA 동작 이해, CXL.mem latency 측정 방법, tier-aware page placement(예: Linux DAMON, weighted interleave)에 대한 감을 잡아두면 첫 deploy 때 가장 빠르게 흡수할 수 있습니다.