Chiplet Architecture가 확산되면 새로운 문제가 생깁니다. Chip을 여러 개로 나누는 것 자체보다 나뉜 Chiplet 사이에서 데이터를 어떤 규칙으로 주고받을 것인가가 더 어려운 문제입니다.

한 회사가 모든 Chiplet을 직접 만든다면 자체 Proprietary Interface를 사용할 수 있습니다. 하지만 CPU Chiplet과 I/O Chiplet, Accelerator Chiplet을 여러 Vendor가 공급하는 Open Ecosystem을 만들려면 공통된 Electrical Interface와 Protocol, Manageability, Test 방법이 필요합니다.

UCIe(Universal Chiplet Interconnect Express): Package 안의 Chiplet 사이를 연결하기 위해 Physical Layer, Die-to-die Link, Protocol Mapping, Manageability와 Test Framework를 정의하는 Open Interconnect Standard입니다.

UCIe의 목표는 단순히 Chiplet 연결속도를 높이는 것이 아닙니다. 서로 다른 Chiplet을 재사용하고 조합할 수 있는 공통 Package-level Ecosystem을 만드는 것입니다.

먼저 한눈에 보면

구분	Proprietary Die-to-die	UCIe
Interface	Vendor별 독자 설계	Open Standard
최적화	특정 제품에 극단적 최적화 가능	Interoperability와 Reuse에 유리
Protocol	Vendor Defined	PCIe·CXL Mapping, Raw Mode 등
Multi-vendor	어렵거나 별도 협업 필요	장기적으로 확대 목표
Manageability	Vendor별	Standard 기능 확대
최신 주요 세대	제품별 상이	UCIe 3.0 최대 64GT/s

UCIe가 있다고 Proprietary Interface가 사라지는 것은 아닙니다. High-performance AI Chip에서는 성능과 Power를 극단적으로 최적화하기 위해 자체 D2D를 계속 사용할 수 있습니다. UCIe의 가치는 Open Standard가 필요한 영역을 점진적으로 넓히는 것에 있습니다.

UCIe가 표준화해야 하는 것은 생각보다 많습니다

Chiplet 사이에는 단순 Data Wire만 있는 것이 아닙니다. Clock을 맞추고 Link를 Training하며 Error가 발생했을 때 복구해야 합니다. Power State를 바꾸고 Firmware를 초기화하며 각 Die의 상태를 관리해야 합니다.

Package 안에서 10개 이상의 Chiplet이 동작한다면 어떤 Chiplet이 어떤 Link에 연결돼 있는지 System Software도 이해해야 합니다. Debug와 Test 방법도 필요합니다.

그래서 UCIe는 단순 PHY Specification이 아니라 Physical Layer에서 Protocol, Manageability와 DFx까지 확장되는 System Standard로 발전하고 있습니다.

UCIe 1.0에서 무엇이 시작됐을까요?

초기 UCIe는 Package 내부 Die-to-die 연결을 위한 공통 Physical Layer와 Protocol Stack을 정의했습니다. 특히 PCIe와 CXL Protocol을 UCIe Link 위에서 사용할 수 있도록 Mapping한 것이 큰 특징이었습니다.

이 방식은 Software Ecosystem을 새로 만들 필요를 줄입니다. 기존 PCIe Device Model과 CXL Memory·Coherency Model을 활용하면서 Physical Transport만 Package 내부 UCIe로 바꿀 수 있기 때문입니다.

또 Vendor-specific Protocol을 위한 Streaming·Raw 계열 Transport도 지원해 UCIe가 특정 Protocol 하나에 묶이지 않도록 설계했습니다.

UCIe 2.0에서 무엇이 달라졌을까요?

UCIe 2.0은 2024년 공개되며 Manageability, Debug, Test와 3D Packaging 지원을 크게 강화했습니다.

Multi-chip System이 복잡해질수록 Link가 동작하는 것만으로는 충분하지 않습니다. Data Center Operator와 System Firmware가 Chiplet Health를 보고 문제를 진단하고 Field에서 관리할 수 있어야 합니다.

UCIe 2.0은 System-in-Package 전체의 Manageability와 DFx 기능을 표준화하는 방향을 추가했습니다. 또한 3D Packaging을 지원해 Horizontal 2.5D Connection뿐 아니라 Die를 수직으로 쌓는 Architecture에도 UCIe Ecosystem을 확장할 수 있도록 했습니다.

UCIe 3.0은 64GT/s까지 올라갔습니다

UCIe 3.0은 2025년 8월 공개됐습니다. 가장 눈에 띄는 변화는 48GT/s와 64GT/s Data Rate 지원으로 UCIe 2.0의 32GT/s보다 최대 Data Rate가 두 배로 증가했다는 점입니다.

AI Chiplet 사이에서는 매우 많은 Data가 이동하기 때문에 D2D Bandwidth가 충분하지 않으면 Compute Die를 나눈 효과가 떨어질 수 있습니다. UCIe 3.0의 64GT/s는 같은 Package Edge와 Pin Area에서 더 높은 Bandwidth Density를 확보하는 데 중요합니다.

하지만 Speed가 높아질수록 Signal Integrity와 Power도 어려워집니다. 따라서 UCIe 3.0은 Data Rate뿐 아니라 Runtime Recalibration과 L2 Optimization 같은 Power Efficiency 기능도 강화합니다.

UCIe 3.0의 Extended Sideband는 왜 중요할까요?

UCIe 3.0은 Sideband Channel Reach를 최대 100mm까지 확장했습니다. Sideband는 Main High-speed Data Path와 별도로 Management와 Initialization, Control Signal을 전달하는 Channel입니다.

Package가 커지고 Chiplet 배치가 복잡해지면 Management Connection도 더 긴 거리를 커버해야 할 수 있습니다. 100mm Sideband Reach는 대형 Multi-chip Package에서 Topology를 더 유연하게 구성할 수 있도록 돕습니다.

또 Priority Sideband Packet과 Early Firmware Download 같은 기능이 추가돼 대규모 SiP에서 Initialization과 System Event 처리를 더 빠르게 할 수 있습니다.

UCIe-S와 UCIe-A는 무엇이 다른가요?

UCIe는 일반적인 Standard Package와 Fine-pitch Advanced Package 환경을 모두 고려합니다.

UCIe-S(Standard): 상대적으로 큰 Bump Pitch와 긴 Reach를 고려한 Package Interface입니다.

UCIe-A(Advanced): Fine-pitch Advanced Packaging을 활용해 더 높은 Bandwidth Density와 낮은 Energy per Bit를 목표로 하는 Interface입니다.

AI Accelerator처럼 Package Cost보다 Performance와 Power Efficiency가 중요한 제품에서는 Advanced Package가 특히 중요합니다. Chiplet 간 거리를 짧게 하고 Fine Pitch를 사용하면 동일한 Bandwidth를 더 적은 Power로 전송할 수 있습니다.

왜 PCIe와 CXL을 UCIe 위에 올릴까요?

PCIe는 Server의 범용 I/O Standard이고 CXL은 CPU, Accelerator, Memory 사이의 Cache-coherent Interconnect입니다. 이미 Operating System과 Driver, Hardware Ecosystem이 매우 큽니다.

새 Chiplet Standard를 만들면서 Software Stack까지 전부 새로 만들면 Adoption Barrier가 높아집니다. UCIe는 PCIe와 CXL Semantics를 Package 내부 Link에서 재사용할 수 있도록 해 기존 Ecosystem을 활용합니다.

예를 들어 I/O Chiplet을 PCIe Device처럼 연결하거나, Memory·Accelerator Chiplet에 CXL Protocol을 사용할 수 있습니다. Physical Transport는 UCIe지만 상위 Layer에서는 익숙한 PCIe·CXL Model을 유지할 수 있습니다.

Raw Mode는 왜 필요한가요?

모든 AI Chiplet Traffic을 PCIe나 CXL로 표현하는 것이 최적은 아닐 수 있습니다. GPU 내부의 매우 특수한 Streaming Data나 Vendor-specific Collective Protocol은 더 단순하고 낮은 Overhead의 Link가 필요할 수 있습니다.

Raw Mode: UCIe Physical·Link Infrastructure를 이용하면서 특정 Vendor나 Application이 정의한 Data Format을 직접 전달할 수 있도록 하는 방식입니다.

UCIe 3.0은 Continuous Transmission Protocol Mapping을 강화해 SoC와 DSP Chiplet 같은 새로운 Use Case에서도 지속적인 Data Flow를 지원할 수 있도록 확장했습니다.

즉 UCIe는 Open Protocol만 강제하는 Standard가 아니라 Common Physical Infrastructure 위에 다양한 Protocol을 수용하는 Framework입니다.

UCIe와 CXL은 경쟁기술이 아닙니다

UCIe와 CXL이 모두 Interconnect라서 비슷해 보이지만 Layer가 다릅니다.

UCIe는 Package 안에서 Die와 Die를 물리적으로 연결하는 D2D Standard입니다. CXL은 Processor, Memory와 Accelerator 사이의 Memory·Cache Coherency와 Protocol Semantics를 정의하는 System Interconnect입니다.

따라서 CXL Traffic을 UCIe 위에서 전달할 수 있습니다. 쉽게 말하면 UCIe가 Package 안의 고속도로라면 CXL은 그 위에서 Memory Resource를 어떻게 사용할지 정의하는 Traffic Rule에 가깝습니다.

UCIe와 UALink도 역할이 다릅니다

UALink는 GPU·XPU 같은 Accelerator를 Rack 또는 Pod 수준에서 연결하는 Scale-up Interconnect입니다. UCIe는 Package 내부 Chiplet 연결입니다.

다만 두 기술은 장기적으로 이어질 수 있습니다. 2026년 공개된 UALink Chiplet Specification은 UCIe 3.0과의 Compliance를 포함해 UALink Technology를 Chiplet 기반 SoC에 통합할 수 있도록 정의하고 있습니다.

즉 미래 AI Accelerator에서는 Package 내부는 UCIe, Accelerator Scale-up은 UALink, Rack 밖 Scale-out은 Ethernet처럼 여러 Layer가 연결될 수 있습니다.

3D Packaging에서 UCIe는 어떻게 쓰일까요?

3D Integration에서는 Die 사이 거리가 극도로 짧아지고 Interconnect Density가 크게 증가할 수 있습니다. Hybrid Bonding을 사용하면 수 µm 수준 Pitch로 수많은 Connection을 만들 수 있습니다.

UCIe 2.0부터 3D Packaging Support가 강화된 이유는 Chiplet Architecture가 단순히 Die를 옆으로 배치하는 2.5D에서 수직 Integration으로 발전하고 있기 때문입니다.

3D D2D Interface는 매우 높은 Bandwidth와 낮은 Energy per Bit를 제공할 수 있지만 Thermal과 Test, Mechanical Alignment가 더 어려워집니다. UCIe가 3D 환경에서도 Manageability와 Test를 표준화하면 Multi-die System 개발의 Complexity를 줄일 수 있습니다.

정말 다른 회사 Chiplet을 마음대로 섞을 수 있을까요?

장기적인 Vision은 그렇지만 현실은 더 복잡합니다. Electrical Interface가 호환돼도 Chiplet의 Power, Thermal Limit, Security, Firmware, Mechanical Height와 Package Design이 맞아야 합니다.

또 HBM과 High-performance Logic은 고객별로 매우 세밀하게 최적화됩니다. Multi-vendor Chiplet을 사용하면서 생기는 Integration Risk가 Performance 이점을 상쇄할 수 있습니다.

따라서 초기 UCIe 시장은 “Marketplace에서 Chiplet을 골라 조립”하는 형태보다 동일 Vendor의 Modular Design, Hyperscaler Custom Design, 특정 Partner 간 Integration에서 먼저 확대될 가능성이 높습니다.

UCIe가 EDA·IP 업체에 중요한 이유

UCIe PHY와 Controller를 처음부터 직접 설계하는 것은 쉽지 않습니다. 64GT/s D2D PHY와 Protocol Controller, Verification Environment가 필요합니다.

Synopsys, Cadence 같은 업체는 UCIe Controller IP, PHY IP와 Verification IP를 제공할 수 있습니다. Chiplet을 설계하는 Fabless가 늘어날수록 검증된 D2D IP를 구매하는 경제성이 높아질 수 있습니다.

Multi-die Design Tool도 중요합니다. Logic Die만 Place & Route하는 것이 아니라 Package Routing, Thermal, Power Integrity, Signal Integrity를 하나의 Workflow에서 분석해야 하기 때문입니다.

Foundry와 Packaging 업체에도 UCIe가 중요합니다

Open Chiplet Ecosystem이 커지려면 Foundry가 여러 Vendor Die를 Package에서 안정적으로 연결할 수 있어야 합니다. UCIe Compliance와 Advanced Packaging Design Rule, Test Infrastructure가 Foundry Service의 일부가 됩니다.

TSMC, Intel Foundry, Samsung Foundry 같은 업체가 Advanced Packaging을 강화하는 이유도 단순 Package Revenue뿐 아니라 고객의 Multi-die System 전체를 Platform 안에 묶을 수 있기 때문입니다.

UCIe가 확산되면 Foundry는 Wafer 공급자에서 Chiplet Integration Platform Provider로 역할이 확대될 수 있습니다.

Test와 Compliance는 왜 커질까요?

Open Standard의 가장 큰 가치 중 하나는 Interoperability입니다. 하지만 실제로 서로 다른 Vendor의 Chiplet이 연결되려면 Specification을 읽는 것만으로 충분하지 않습니다.

PHY Electrical Margin, Link Training, Protocol Behavior, Error Handling, Manageability를 Test해야 합니다. UCIe Consortium은 Compliance와 Interoperability Ecosystem을 함께 확대하고 있습니다.

Data Rate가 64GT/s로 올라가면 Test Equipment와 Probe, Package-level Signal Measurement도 어려워집니다. 따라서 UCIe는 High-speed Test와 Verification Market에도 새로운 Demand를 만들 수 있습니다.

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

첫 번째는 UCIe 3.0 IP Design Win입니다. Specification 발표보다 실제 CPU·AI Accelerator에서 64GT/s UCIe PHY가 Tape-out되는지가 중요합니다.

두 번째는 UCIe가 Proprietary D2D를 얼마나 대체하거나 보완하는지입니다. High-end AI에서 Proprietary Interface가 계속 강할 수 있으므로 Open Standard의 실제 Share를 확인해야 합니다.

세 번째는 Advanced Packaging과 3D Integration입니다. UCIe가 Fine-pitch 2.5D와 3D에서 사용될수록 Foundry·Packaging·Hybrid Bonding과 Test Content가 늘 수 있습니다.

네 번째는 Multi-vendor Interoperability입니다. 실제로 다른 Vendor의 Chiplet이 한 Package에서 상용화되기 시작하면 UCIe Ecosystem의 경제적 의미가 크게 달라질 수 있습니다.

UCIe의 리스크는 무엇일까요?

가장 큰 리스크는 Open Standard가 Performance에서 Proprietary Interface를 따라가지 못할 가능성입니다. AI Accelerator는 Bandwidth와 Latency, Power가 매우 민감하기 때문에 최고성능 Segment에서는 Vendor-specific Link가 계속 우세할 수 있습니다.

또 Multi-vendor Chiplet의 Commercial Model도 아직 성숙하지 않았습니다. 누가 Package Yield를 보증하는지, Chiplet Warranty와 Firmware Responsibility를 어떻게 나눌지 같은 공급망 문제도 해결해야 합니다.

따라서 UCIe의 성공을 Specification Version만으로 판단하기보다 실제 Product Adoption과 Ecosystem Responsibility Model이 만들어지는지를 봐야 합니다.

핵심 정리

질문	답
UCIe란?	Package 내부 Chiplet을 연결하기 위한 Open Die-to-die Interconnect Standard입니다
최신 주요 세대는?	UCIe 3.0이 48GT/s와 64GT/s를 지원합니다
UCIe 2.0의 변화는?	Manageability, Debug·Test와 3D Packaging 지원이 강화됐습니다
PCIe·CXL과 관계는?	UCIe Link 위에 PCIe와 CXL Protocol을 Mapping할 수 있습니다
UALink와 차이는?	UCIe는 Package 내부, UALink는 Accelerator Scale-up Network입니다
Multi-vendor Chiplet이 바로 가능한가?	Electrical Standard 외에도 Thermal·Firmware·Security·Supply Chain 통합이 필요해 점진적일 가능성이 높습니다
투자포인트는?	UCIe PHY·Controller IP, EDA, Advanced Packaging, Compliance Test와 실제 Product Adoption입니다

UCIe의 진짜 의미는 Data Rate 64GT/s라는 숫자보다 Chiplet을 표준화된 System Building Block으로 만들려는 시도에 있습니다. Monolithic Chip 시대에는 하나의 회사가 Chip 전체를 설계했지만, Chiplet 시대에는 Package 안에서도 Ecosystem이 만들어질 가능성이 있습니다.

그 변화가 현실화되면 Semiconductor 경쟁의 단위는 “누가 가장 좋은 Chip을 만드는가”에서 누가 가장 좋은 Chiplet과 Integration Platform을 제공하는가로 넓어집니다. UCIe는 바로 그 Open Chiplet Ecosystem의 기반이 될 수 있는 Interconnect Layer입니다.

13. CXL이란? AI 서버의 메모리 구조를 바꾸는 차세대 인터커넥트

Server Memory는 오랫동안 CPU Socket에 직접 연결된 DDR DRAM을 중심으로 설계돼 왔습니다. CPU가 지원하는 Memory Channel과 DIMM Slot 안에서 Capacity와 Bandwidth를 구성하고, 더 많은 Memory가 필요하면 더 큰 DIMM을 사용하거나 CPU Socket 자체를 추가하는 방식이 일반적이었습니다.

문제는 AI와 In-memory Database, Analytics처럼 Memory Demand가 빠르게 증가하면서 이 구조의 한계가 커지고 있다는 점입니다. CPU Core 수와 Accelerator 성능은 계속 증가하지만 CPU Package에 넣을 수 있는 Memory Channel과 Pin 수, Board Routing은 무한정 늘릴 수 없습니다. 필요한 것은 Memory를 CPU Socket의 고정된 부품에서 더 유연하게 확장하고 공유할 수 있는 Resource로 바꾸는 방법입니다.

CXL(Compute Express Link): PCIe Physical Layer를 기반으로 Processor, Accelerator와 Memory Device 사이에 Cache Coherency와 Memory Semantics를 제공하는 Open Interconnect Standard입니다.

CXL의 핵심은 새로운 Cable 하나가 아닙니다. PCIe가 가지고 있던 고속 I/O 생태계 위에 Memory와 Cache를 다루는 기능을 추가해 Server Architecture를 바꾸려는 기술입니다.

먼저 한눈에 보면

구분	PCIe	CXL
기본 성격	범용 High-speed I/O	Coherent Memory·Accelerator Interconnect
Physical Layer	PCIe PHY	PCIe PHY 활용
주요 대상	SSD, NIC, GPU 등	Accelerator, Memory Expander, Memory Pool
Memory Semantics	기본 목적 아님	CXL.mem 지원
Cache Coherency	일반 PCIe Device Model	CXL.cache 지원
대표 AI 활용	GPU·NIC·SSD 연결	Memory Expansion·Pooling·Disaggregation

즉 CXL은 PCIe를 버리는 기술이 아닙니다. PCIe의 Physical Infrastructure를 재사용하면서 그 위에 Coherency와 Memory Protocol을 추가하는 구조입니다.

PCIe만으로는 왜 부족할까요?

PCIe는 이미 Server에서 매우 성공적인 Interconnect입니다. GPU, NIC, SSD와 Accelerator를 CPU에 연결하는 데 사용됩니다. 하지만 일반 PCIe Device를 CPU Memory처럼 Load·Store하고 Cache Coherency까지 유지하려면 Software와 Device Architecture가 복잡해질 수 있습니다.

CXL은 이 문제를 줄이기 위해 CPU와 Device가 Memory와 Cache 상태를 일관되게 유지할 수 있는 Protocol을 정의합니다. Host가 CXL Memory Device의 Memory를 System Memory Hierarchy 안에서 활용할 수 있고, Accelerator가 Host Memory를 더 자연스럽게 공유할 수도 있습니다.

이 때문에 CXL은 단순 I/O Bandwidth보다 Memory Resource를 어떻게 System Architecture에 통합할 것인가가 핵심입니다.

CXL.io, CXL.cache, CXL.mem은 무엇이 다른가요?

CXL.io: Device Discovery, Configuration, Interrupt와 일반 I/O 기능을 담당하는 PCIe 기반 Protocol입니다.

CXL.cache: Accelerator 같은 Device가 Host Memory를 Cache-coherent하게 접근할 수 있도록 하는 Protocol입니다.

CXL.mem: Host가 CXL Device에 연결된 Memory를 Memory Semantic으로 접근할 수 있도록 하는 Protocol입니다.

CXL Device가 어떤 기능을 사용하느냐에 따라 필요한 Protocol 조합이 달라집니다. Memory Expansion에서는 CXL.mem이 핵심이고, Accelerator가 Host Memory를 공유하는 경우 CXL.cache가 중요합니다.

CXL Type 1, Type 2, Type 3 Device를 이해하면 구조가 쉬워집니다

Type 1 Device: Local Memory가 없는 Accelerator 중심 Device로 CXL.cache와 CXL.io를 사용해 Host Memory에 Coherent하게 접근합니다.

Type 2 Device: Accelerator와 Local Memory를 함께 가진 Device로 CXL.cache와 CXL.mem을 모두 활용할 수 있습니다.

Type 3 Device: Memory Expansion에 초점을 맞춘 Device로 CXL.mem을 통해 Host에 추가 Memory Capacity를 제공합니다.

AI Infrastructure에서 가장 쉽게 떠올릴 수 있는 제품은 Type 3 CXL Memory Expander입니다. CPU의 DDR Channel 밖에 DDR5 Memory를 추가하고 CXL Link를 통해 System Memory Tier로 활용합니다.

왜 CPU Memory Channel은 무한정 늘릴 수 없을까요?

CPU에 DDR Channel을 추가하려면 Package Pin이 필요하고 Board에 더 많은 DIMM Slot과 Routing이 필요합니다. Memory Channel은 고속 Signal이기 때문에 Signal Integrity와 Power도 관리해야 합니다.

CPU Core 수가 계속 늘어도 Memory Channel을 같은 비율로 늘리기는 어렵습니다. 그러면 Core당 사용할 수 있는 Memory Capacity와 Bandwidth가 부족해지는 문제가 발생할 수 있습니다.

더 큰 DIMM을 사용하면 Capacity는 늘릴 수 있지만 Cost가 높아질 수 있고 Memory Bandwidth는 Channel 수에 의해 제한될 수 있습니다. CPU Socket을 추가하면 Memory Channel도 늘어나지만 필요하지 않은 CPU Cost와 Power까지 함께 증가할 수 있습니다.

CXL Memory는 CPU를 추가하지 않고 PCIe/CXL I/O를 이용해 Memory Capacity와 일부 Bandwidth를 추가하는 방법을 제공합니다.

CXL 1.x는 Direct-attached Device에서 시작했습니다

CXL 초기 세대는 Host와 Device를 직접 연결하고 Cache·Memory Coherency를 제공하는 기반을 만드는 데 집중했습니다. CPU에 CXL Memory Expander를 직접 연결하거나 Accelerator와 Coherent Memory를 구성하는 방식입니다.

이 단계에서는 CXL이 기존 DDR을 대체하기보다 CPU 주변에 새로운 Memory Tier를 추가하는 기술로 이해하는 것이 쉽습니다. Local DDR은 가장 낮은 Latency의 Main Memory로 유지되고 CXL Memory가 추가 Capacity를 제공합니다.

하지만 CXL의 장기적인 의미는 Direct-attached Memory에서 끝나지 않습니다. 2.0부터 Switch와 Pooling이 들어오면서 Memory를 여러 Host가 공유 가능한 Resource로 바꾸기 시작합니다.

CXL 2.0부터 Memory Pooling이 중요해졌습니다

CXL 2.0은 Switching과 Memory Pooling을 중요한 Usage Model로 추가했습니다. CXL Switch를 통해 여러 Host와 여러 Memory Device를 연결하고, Fabric Manager가 특정 Memory Resource를 Host에 할당하거나 회수할 수 있습니다.

기존 Server에서는 Memory가 특정 CPU Socket에 물리적으로 고정돼 있습니다. CXL Pooling에서는 Memory Resource를 Pool에 두고 Workload에 따라 Host에 동적으로 배분할 수 있습니다.

이 구조가 실용화되면 Server마다 Peak Workload를 대비해 과도한 DRAM을 설치하는 Stranded Memory 문제를 줄일 가능성이 있습니다. 즉 CXL은 Memory Capacity를 늘리는 기술이면서 동시에 Memory Utilization을 높이는 기술이기도 합니다.

CXL 3.x에서는 Fabric과 Sharing이 확대됐습니다

CXL 3.x는 Data Rate를 64GT/s로 높이고 Multi-level Switching, Fabric Topology와 Memory Sharing Capability를 강화했습니다.

CXL 2.0 Pooling이 주로 Memory Resource를 특정 Host에 할당하는 방향이었다면 CXL 3.x는 여러 Host가 더 복잡한 Fabric에서 Resource를 연결하고 공유하는 Architecture로 발전합니다.

이 변화는 CXL을 단순 Memory Expansion Interface에서 Rack-scale Resource Fabric으로 확장시키는 기반이 됩니다. CPU, GPU, Memory Expander와 Switch를 여러 Level에서 연결하고 Data Center Operator가 Resource를 더 유연하게 구성할 수 있습니다.

CXL 4.0은 128GT/s로 다시 두 배 빨라졌습니다

CXL 4.0은 2025년 11월 공개됐으며 PCIe 7.0 Physical Layer를 기반으로 Data Rate를 64GT/s에서 128GT/s로 두 배 높였습니다. CXL 3.x의 256B Flit 구조와 FEC·CRC Architecture를 유지하면서 Bandwidth를 확대합니다.

또 Native x2 Width를 도입해 Fan-out을 늘리고, 최대 4개의 Retimer를 지원해 Channel Reach를 확장했습니다. Type 1·2 Accelerator Connection에서는 여러 Device Port를 논리적으로 묶는 Bundled Ports도 추가됐습니다.

CXL 4.0의 의미는 단순 Speed Upgrade가 아닙니다. Rack-scale Memory와 Accelerator Fabric이 커질수록 Port Count, Reach와 RAS가 중요해지기 때문에 더 큰 Fabric을 실제로 운영하기 위한 System 기능이 강화된 것입니다.

CXL 세대를 한눈에 보면

세대	주요 Data Rate	핵심 변화
CXL 1.x	PCIe 5 기반	Direct-attached Coherent Device, Memory Expansion 기반
CXL 2.0	32GT/s	Switching, Memory Pooling, Fabric Manager
CXL 3.x	64GT/s	Multi-level Fabric, Memory Sharing, 확장된 Coherency
CXL 4.0	128GT/s	Bundled Ports, Native x2, 최대 4 Retimer, Memory RAS 강화

이 표에서 중요한 것은 세대가 올라갈수록 단순 Bandwidth뿐 아니라 Resource Disaggregation Capability가 커진다는 점입니다.

CXL Memory는 HBM을 대체할까요?

대체하기 어렵습니다. HBM과 CXL Memory는 해결하려는 문제가 다릅니다.

HBM은 GPU Package 바로 옆에서 수 TB/s에서 수십 TB/s급 Memory Bandwidth를 제공하는 최고성능 Memory Tier입니다. NVIDIA Rubin GPU는 HBM4를 통해 최대 22TB/s Memory Bandwidth를 제공합니다. CXL Memory는 PCIe/CXL Link와 Controller, 경우에 따라 Switch를 거치기 때문에 Latency와 Bandwidth에서 HBM보다 불리합니다.

따라서 HBM은 Hot Data와 Compute-critical Data에 사용되고, CXL Memory는 큰 Capacity가 필요한 Warm Data와 KV Cache, In-memory Data, Recommendation Table 같은 Workload에 사용될 수 있습니다.

즉 두 Memory는 경쟁보다 Memory Hierarchy 안에서 서로 다른 Tier를 담당하는 관계에 가깝습니다.

CXL은 DDR도 완전히 대체하지 않습니다

CPU Local DDR은 매우 낮은 Latency와 높은 안정성을 제공합니다. CXL Memory는 추가 Controller와 Link를 거치므로 Access Latency가 더 높을 수 있습니다.

따라서 현실적인 Server Architecture에서는 Local DDR을 Base Memory로 유지하면서 CXL Memory를 Capacity Tier로 추가하는 형태가 먼저 확대될 가능성이 높습니다.

OS와 Application은 자주 사용하는 Page를 Local DRAM에 두고 상대적으로 Latency에 덜 민감한 Data를 CXL Memory에 배치할 수 있습니다. 이를 Memory Tiering이라고 합니다.

Memory Tiering Software가 왜 중요할까요?

Hardware가 CXL Memory를 연결했다고 Application이 자동으로 최적성능을 내는 것은 아닙니다. Local DDR과 CXL Memory는 Latency와 Bandwidth가 다릅니다.

Hot Page가 CXL Memory에 남아 있으면 CPU가 더 느린 Memory를 반복적으로 접근해 Performance가 떨어질 수 있습니다. 반대로 거의 사용하지 않는 Data를 비싼 Local DRAM에 계속 두면 CXL의 Capacity Advantage를 활용하지 못합니다.

OS의 NUMA Policy, Page Migration, Memory Tiering Runtime과 Application Awareness가 중요합니다. CXL의 장기적인 성공은 Hardware보다 Heterogeneous Memory를 Software가 얼마나 자연스럽게 관리할 수 있느냐에 크게 좌우될 수 있습니다.

AI Inference와 CXL이 연결되는 이유

Training에서는 HBM Bandwidth가 가장 중요한 경우가 많습니다. 반면 LLM Inference에서는 Context Length와 동시 사용자 수가 늘어날수록 KV Cache가 큰 Memory Capacity를 요구할 수 있습니다.

모든 KV Cache를 HBM에 넣으면 GPU당 HBM Capacity가 제한되고 HBM Cost도 높습니다. 일부 Data를 CXL-attached DRAM으로 이동시켜 Capacity Tier를 구성하면 HBM을 Compute-critical Data에 더 집중해서 사용할 가능성이 있습니다.

Recommendation System과 Embedding Table, Database, Analytics도 큰 DRAM Capacity를 요구하기 때문에 CXL의 후보 Workload입니다.

다만 모든 Inference Workload가 CXL로 빨라지는 것은 아닙니다. Data Placement와 Access Pattern에 따라 CXL Latency가 성능을 떨어뜨릴 수도 있으므로 실제 Benchmark와 Software Optimization이 중요합니다.

2026년에는 CXL이 실제 Product 단계로 이동하고 있습니다

CXL은 오랫동안 “미래 Memory Architecture”라는 평가를 받았지만 Product Ecosystem이 구체화되고 있습니다.

Astera Labs의 Leo CXL Smart Memory Controller는 CXL 1.1/2.0 기반 Memory Expansion과 Pooling을 Production으로 제공하며 Controller당 최대 2TB DDR5 Memory를 지원합니다. Astera는 Microsoft Azure M-series Virtual Machine에서 Leo 기반 CXL-attached Memory Evaluation을 공개해 Cloud Deployment 단계로 진입하고 있습니다.

Samsung의 MD310 CMM-D는 CXL 3.2와 PCIe Gen6를 지원하며 256GB Capacity와 Server-to-memory 최대 72GB/s Bandwidth를 제시합니다. SK hynix도 2026년 HPE Discover에서 CXL 2.0+ 128GB와 CXL 3.2 기반 256GB CMM-DDR5를 전시하고 Pooled Memory System을 시연했습니다.

즉 Specification과 Demo를 넘어 Memory Controller, Module, Switch와 Cloud Evaluation이 동시에 진행되는 단계입니다.

CXL Switch가 등장하면 시장구조가 달라집니다

Direct-attached Memory에서는 Host당 CXL Controller와 Module이 핵심입니다. Memory Pooling이 커지면 CXL Switch가 새로운 Semiconductor Category로 추가됩니다.

Marvell은 2026년 Structera S 30260을 발표했습니다. 이 Chip은 PCIe 6/CXL 3.x 기반 260-lane Switch로 16개 또는 32개의 CPU·GPU와 최대 48TB Shared Memory, 최대 4TB/s Aggregate Bandwidth를 목표로 하며 2026년 3분기 Sampling 예정입니다. 기존 CXL 2.0 Structera S 20256은 Production 단계입니다.

이런 제품은 CXL이 Memory Module 하나의 시장에서 Rack-level Fabric Silicon Market으로 확대되는 사례입니다.

CXL이 DRAM 수요를 무조건 늘리는 기술은 아닙니다

CXL Memory Expansion은 기존 Server에 추가 DRAM을 설치하기 쉽게 만들기 때문에 새로운 DRAM Demand를 만들 수 있습니다. Capacity가 부족해 처리하지 못했던 Workload가 더 많은 Memory를 사용하는 효과도 있을 수 있습니다.

하지만 Memory Pooling은 반대로 Stranded Memory를 줄여 동일한 Workload를 더 적은 총 DRAM Capacity로 운영하게 할 수도 있습니다. Server마다 Peak Capacity를 설치하는 대신 Pool을 공유하면 Overprovisioning이 줄어들기 때문입니다.

따라서 CXL을 “DRAM 수요 증가 = 무조건 수혜”로 단순화하기보다 Memory의 사용효율과 배치방식을 바꾸는 Technology로 보는 것이 정확합니다.

CXL과 Retimer·Cable은 왜 함께 커질까요?

PCIe 5·6·7 세대로 Data Rate가 올라갈수록 Electrical Reach는 어려워집니다. CXL Memory가 Board 바로 옆이 아니라 다른 Tray나 Rack으로 이동하면 Signal Conditioning이 필요합니다.

Retimer는 약해진 Signal을 다시 복구해 Reach를 늘리고, AEC는 Retimer·DSP를 Cable 안에 넣어 수 m 거리까지 Copper Connectivity를 확장합니다. 더 긴 거리가 필요하면 Optical CXL을 사용할 가능성이 있습니다.

즉 CXL Adoption이 커지면 Memory Controller와 Switch만 아니라 Retimer, AEC, Optical Connectivity까지 새로운 Content가 생길 수 있습니다.

CXL의 Security와 RAS가 중요한 이유

Memory는 Application의 핵심 Data를 담고 있습니다. Memory Pool을 여러 Host가 공유하면 Access Control과 Isolation이 매우 중요해집니다.

또 Local DIMM 하나의 장애보다 Shared CXL Switch나 Memory Pool의 장애가 더 큰 Failure Domain을 만들 수 있습니다. 따라서 Error Reporting, Patrol Scrub, Memory Sparing, Poison Handling과 Fabric-level RAS가 중요합니다.

CXL 4.0에서 Memory RAS 기능이 강화된 이유도 Rack-scale Memory가 실제 Production에 들어가려면 Performance뿐 아니라 장애를 격리하고 서비스 상태를 유지하는 능력이 필요하기 때문입니다.

주요 기업은 어느 Layer에 있을까요?

Memory 업체에서는 Samsung, SK hynix, Micron이 CXL Memory Module과 DRAM Capacity를 공급합니다. Astera Labs는 Leo Memory Controller와 Aries Retimer를 제공하며, Marvell은 Structera Memory Controller·Switch와 Alaska Retimer까지 CXL Portfolio를 확대하고 있습니다.

CPU와 Server Platform 업체는 CXL Host Support를 제공해야 하며 Cloud 업체는 실제 Workload에서 Memory Tiering과 Pooling의 경제성을 검증합니다. EDA·IP 업체는 CXL Controller와 PHY, Verification IP를 공급할 수 있습니다.

즉 CXL Value Chain은 DRAM + Controller + Switch + Retimer + Server Software로 구성됩니다.

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

첫 번째는 CXL Memory Module의 실제 Volume입니다. 제품 발표보다 Server Qualification과 Cloud Production Deployment가 중요합니다.

두 번째는 CXL 3.x Switch Design Win입니다. Direct-attached Expansion에서 Pooling으로 시장이 이동하면 Switch Silicon Content가 새롭게 커질 수 있습니다.

세 번째는 Software입니다. CXL Memory를 장착한 뒤 실제 Application 성능과 TCO가 개선되는지, OS Tiering이 성숙하는지를 봐야 합니다.

네 번째는 CXL 4.0 Silicon Timeline입니다. Specification은 128GT/s까지 올라갔지만 2026년 실제 시장의 주력 Hardware는 CXL 2.0과 3.x가 중심입니다. Specification과 Production 사이의 시차를 구분해야 합니다.

핵심 정리

질문	답
CXL이란?	PCIe PHY 위에서 Cache Coherency와 Memory Semantics를 제공하는 Open Interconnect입니다
PCIe와 차이는?	PCIe의 I/O 기능에 Memory·Cache Protocol을 추가해 Resource Sharing을 지원합니다
대표 기능은?	Memory Expansion, Pooling, Sharing, Accelerator Coherency입니다
HBM을 대체하나요?	아닙니다. HBM은 최고속 Tier, CXL은 Capacity·Flexibility Tier에 가깝습니다
CXL 4.0은 무엇이 달라졌나요?	128GT/s, Bundled Ports, Native x2, 최대 4 Retimer와 RAS가 강화됐습니다
2026년 시장은 어디까지 왔나요?	CXL 2.0 Production과 CXL 3.x Module·Switch가 상용화로 이동하는 단계입니다
투자포인트는?	Controller, Switch, DRAM Module, Retimer, Software와 실제 Cloud Deployment입니다

CXL의 핵심은 단순히 Memory를 하나 더 꽂는 데 있지 않습니다. 지금까지 CPU Socket에 물리적으로 고정돼 있던 Memory를 확장하고 공유하고 필요에 따라 재배치할 수 있는 Infrastructure Resource로 바꾸는 것이 더 큰 변화입니다.

이 변화가 성공하면 Server의 경계도 달라질 수 있습니다. CPU와 Memory가 반드시 같은 Motherboard에 있어야 한다는 전제가 약해지고, Compute와 Memory를 서로 독립적으로 확장하는 Architecture가 가능해집니다. CXL은 바로 그 Memory Infrastructure 변화의 기반 Protocol입니다.