메모리를 더 구매하는 이유가 항상 용량 부족은 아닙니다. 작은 데이터를 반복해서 읽는 작업은 용량보다 대역폭이 많이 필요하고, 큰 데이터를 보관하되 드물게 읽는 서비스는 그 반대입니다. 클라우드가 vCPU 수에 비례하는 메모리 용량만 제공하면 사용자는 필요한 자원 조합 대신 이미 정해진 VM 크기 중 하나를 선택해야 합니다.

UC San Diego, 상하이교통대학교와 Samsung Semiconductor 연구진의 RamRyder는 메모리 채널을 소프트웨어가 할당할 수 있는 단위로 드러냅니다[1]. 하드웨어의 기본 인터리빙에만 맡기지 않고, VM의 페이지가 어떤 채널에 놓이는지 제어하는 방식입니다. 하드웨어가 허용하는 범위에서 용량과 대역폭 요구를 나누고 VM 간 간섭을 줄이는 것이 목표입니다.

OSDI 2026 논문의 구현은 CXL 메모리를 직접 연결한 단일 호스트에 해당합니다. 여러 서버가 스위치를 통해 사용하는 CXL 풀의 실증도, GPU HBM의 대역폭을 할당하는 기술도 아닙니다. AI 인프라에서는 캐시, 그래프 처리, 메모리 집약 작업과 서비스를 받치는 CPU 측 자원에 우선 적용할 수 있는 연구입니다. 다른 메모리 영역으로 확대하려면 그 영역의 연결과 격리 수단을 별도로 확인해야 합니다.

남는 용량과 남는 처리 능력의 차이

메모리 채널에는 저장할 수 있는 양과 단위 시간에 처리할 수 있는 요청량이 함께 존재합니다. 물리적으로 연결된 자원이지만 같은 비율로 소비되지는 않습니다. 차가운 데이터를 많이 보관하는 VM은 용량을 채우면서도 대역폭을 거의 쓰지 않을 수 있고, 작은 작업 집합을 계속 훑는 VM은 반대일 수 있습니다. 두 작업을 함께 배치하려면 한쪽의 요청이 다른 쪽의 지연을 악화시키지 않는다는 조건이 필요합니다.

서버의 기본 채널 인터리빙은 물리 주소를 소켓의 여러 채널에 나눠 메모리 병렬성을 높입니다. 소켓 전체를 쓰는 큰 작업에는 유리하지만, 같은 소켓의 여러 VM도 같은 채널에서 경쟁하게 됩니다. 주소 범위를 서로 다르게 할당했다는 사실만으로 요청을 처리하는 자원까지 분리되지는 않습니다. 활성 코어가 많은 VM이 더 많은 메모리 요청을 만들면 작은 VM의 접근이 늦어질 수 있습니다.

이 때문에 실제 용량 요구보다 더 많은 하드웨어를 예약할 이유가 생깁니다. 비어 있는 메모리를 남겨 두는 것이 단순한 과잉 할당이 아니라 민감한 서비스의 대역폭을 보존하기 위한 선택일 수 있습니다. 접근 빈도를 보지 않고 남는 바이트만 회수하면, 그 예약이 제공하던 격리가 깨질 수 있습니다. 메모리 공유 정책은 점유량과 접근 요구를 함께 다뤄야 합니다.

가상화 소프트웨어가 관리하는 채널

RamRyder는 부팅 시 메모리 설정을 바꿔 소프트웨어가 채널별 물리 주소 영역을 식별할 수 있게 합니다. 이후 그 영역을 DAX 매핑으로 관리하도록 예약합니다. 소켓의 전체 메모리를 항상 하나의 인터리빙 영역처럼 취급하는 대신, 각 채널에 속한 메모리를 선택해 할당할 수 있게 만드는 준비 단계입니다.

실행 중에는 세 부분이 함께 동작합니다. 호스트의 자원 관리자는 영역을 할당하고 VM의 수요를 관측합니다. 수정된 QEMU는 선택한 영역을 게스트 주소 공간에 연결하고, 수정된 게스트 커널은 전달받은 채널 구조에 따라 페이지를 배치합니다. CXL 장치를 꽂는 것만으로 이 기능을 얻는 것은 아니며, 가상화 계층 전체가 같은 구조를 이해해야 합니다.

논문은 채널 단위 NUMA 노드와 기존 서버 단위 NUMA 구성을 구분합니다. 게스트는 자신에게 주어진 채널 안에서 페이지를 분산하면서도 DIMM과 CXL처럼 더 큰 메모리 계층의 차이를 유지합니다. 애플리케이션이 채널 하나하나를 직접 관리할 필요는 없지만, 그 판단을 대신할 커널 기능은 필요합니다.

따라서 범용 하드웨어에서 구현했다는 설명을 수정하지 않은 게스트 이미지에서도 동작한다는 뜻으로 읽어서는 안 됩니다. BIOS 설정, 물리 메모리 예약, 하이퍼바이저와 커널 변경이 전제입니다. 관리형 VM 이미지를 직접 제공하는 운영자와 고객 커널을 바꿀 수 없는 클라우드는 서로 다른 도입 조건을 갖습니다.

로컬 DIMM 채널과 CXL 연결 메모리를 구분한 개념적 서버 도판입니다. RamRyder는 게스트 페이지를 뒷받침하는 물리 영역을 제어하며, 채널 소유와 자원 역할은 코드로 합성한 설명으로 표시합니다. 일반 재질 이미지이며 실제 제품 사진이나 시험 장비 배치도·제조 도면이 아닙니다. 이 글을 위해 새로 만든 도판입니다.

기본 보장 자원과 탄력 자원의 구분

평가 구성에서 초기 DIMM 채널은 VM의 기본 용량에 비례해 할당됩니다. 이 채널은 상대적으로 격리된 자원을 제공하고, CXL은 실행 중 추가할 용량과 대역폭에 사용됩니다. 논문이 탄력 부분을 best effort로 설명한다는 점은 중요합니다. 기본 예약과 같은 수준의 보장을 제공한다고 임의로 확대하면 안 됩니다.

추가 대역폭은 적게 필요하고 용량만 많이 필요하면, 더 적은 CXL 채널에 차가운 데이터를 많이 둘 수 있습니다. 반대로 용량 증가는 작지만 대역폭이 더 필요하면, 여러 채널에 메모리를 나눠 놓을 수 있습니다. 바이트 수와 참여 채널 수가 별도 제어 변수가 되지만, 실제 장치 용량과 연결 능력의 제약까지 없어지지는 않습니다.

여기서 채널은 PCIe 링크 자체가 아니라 DRAM 채널을 뜻합니다. CXL 장치 내부의 DDR 채널도 포함됩니다. 시험에 사용한 장치는 해당 자원을 단일 채널로 다룰 수 있었지만, 내부 채널이 여러 개인 다른 제품이 같은 제어 기능을 제공한다고 보장할 수는 없습니다. CXL 버전이 같다는 사실만으로 할당 단위가 같다고 판단해서는 안 됩니다.

이 연구는 메모리 수요를 더 정확히 표현하는 방법을 제시하지만, 모든 속성을 완전히 독립시키지는 않습니다. 공유 링크, 컨트롤러와 채널 단위의 제한이 남고, 애플리케이션이 충분한 동시 요청을 만들어야 추가 대역폭도 쓸 수 있습니다. 자원 접근을 허용한 것과 그 자원을 실제로 활용하는 것은 다른 단계입니다.

채널 추가보다 중요한 기존 페이지의 위치

채널을 늘리는 것은 메모리 요청을 더 병렬로 처리할 기회를 만드는 일입니다. 기존 페이지는 옮기지 않으면 이전 채널에 그대로 남습니다. 새 할당이 많은 작업은 이후 페이지를 새 채널에 놓을 수 있지만, 오래 유지되는 작업 집합은 재배치해야 접근이 분산됩니다.

RamRyder는 용량과 대역폭 요구에 다른 배치 정책을 사용합니다. 용량 확대가 목적이면 자주 접근하는 페이지를 DIMM에 남기고 차가운 페이지를 CXL에 둘 수 있습니다. 대역폭 확대가 목적이면 각 계층의 처리 능력에 맞춰 페이지를 나눠 놓습니다. 뜨거운 일부 데이터의 접근 지연을 줄이는 것과 스트리밍 작업의 총처리량을 높이는 것은 같은 최적화가 아닙니다.

정책이 실제 접근 패턴과 맞는지도 확인해야 합니다. 읽지 않는 페이지를 여러 채널에 분산해도 요청이 몰린 작은 영역은 빨라지지 않습니다. 반대로 지연에 민감한 페이지를 느린 계층으로 옮기면 총대역폭이 늘어도 서비스는 나빠질 수 있습니다. 성공 기준은 활성 채널의 개수가 아니라 애플리케이션 진행 속도나 응답시간 목표여야 합니다.

메모리 채널 밖에서도 필요한 격리

채널이 분리돼도 다른 공유 자원의 경쟁은 남습니다. RamRyder는 평가한 AMD 시스템에서 VM의 vCPU를 서로 다른 코어 복합체(CCX)에 배치해 마지막 단계 캐시도 분리합니다. 채널을 나눠 얻은 이점이 캐시 간섭으로 다시 사라지지 않도록 한 구성입니다.

논문은 채널 격리와 캐시 격리를 각각 적용한 실험도 제시합니다. 이런 비교가 없으면 VM 성능 개선을 모두 채널 할당기의 효과로 해석하기 쉽지만, 실제로는 CPU 배치도 바뀌었습니다. 다른 프로세서로 옮길 때는 그 장치의 캐시와 코어 구조에서 다시 확인해야 합니다.

작은 VM에서는 할당 단위가 문제가 됩니다. 채널 하나가 한 고객의 요구보다 클 수 있어, 여러 작은 VM이 같은 채널을 공유하면 활용률은 높아지지만 전용 채널의 단순한 격리는 약해집니다. 논문은 공유와 스로틀링을 함께 사용하는 가능성을 논의하며, 채널 분할만으로 모든 크기의 VM을 똑같이 격리한다고 주장하지 않습니다.

운영자가 제공할 상품이 전용 채널인지, 여유 자원의 공유인지, 여러 제어 기법으로 지키는 서비스 목표인지 정해야 합니다. 이들을 모두 하나의 탄력 메모리 보장으로 설명하면 간섭이 발생했을 때 무엇을 제공하기로 했는지조차 불분명해집니다.

대역폭이 늘어나기까지 필요한 시간

동적 할당에서는 새 채널의 메모리를 게스트에 연결하고 토폴로지를 갱신한 뒤, 필요한 페이지를 재배치하고 기존 할당에서 같은 양의 용량을 회수합니다. 최종 용량을 유지하면서 대역폭만 바꾸려면 설정값 하나를 수정하는 것보다 많은 일이 필요합니다. 추가한 채널에 실제 데이터가 있어야 요청도 그쪽으로 갈 수 있습니다.

논문의 10 GB 읽기 전용 시험에서는 CXL 채널을 추가한 뒤 대역폭이 38 GB/s에서 68 GB/s로 올라가는 데 2.2초가 걸렸습니다. 같은 시험에서 채널 회수는 1.1초였습니다. 작업 집합의 크기, 접근 패턴과 이동에 쓸 대역폭에 따라 달라지는 값이므로, 모든 VM의 자원 변경이 이 시간 안에 끝난다는 보장은 아닙니다.

원문의 10 GB 읽기 전용 시험에서 CXL 채널 추가 전후의 측정값입니다. 대역폭은 38 GB/s에서 68 GB/s로 늘었으며 전환에는 2.2초가 걸렸습니다. 보고된 두 값과 전환 시간만 표시하고 중간 측정값을 만들지 않았습니다. 이 글을 위해 새로 만든 도판입니다.

수요를 알아내는 데도 시간이 듭니다. 설명된 방식은 최소 1초의 관측 주기가 필요하고, 그 이후에도 페이지 재배치가 남을 수 있습니다. 짧은 버스트는 대응하기 전에 끝날 수 있으므로 즉시 모든 대역폭을 제공해야 하는 부하보다 지속적인 수요 변화에 더 적합합니다.

지연에 민감한 서비스는 빠른 버스트를 감당할 기본 대역폭을 예약하고, 더 오래 지속되는 변화에 탄력 자원을 쓰는 편이 합리적입니다. 그렇지 않으면 제어기가 과부하를 정확히 감지하더라도 문제를 일으킨 요청은 이미 늦어집니다. 예측으로 미리 자원을 준비하는 것은 개선 방향이지 이 논문에서 이미 검증한 결과는 아닙니다.

실제 장비 시험과 트레이스 계산의 구분

하드웨어 평가는 AMD EPYC Zen 5 서버와 Samsung CXL 2.0 장치를 사용합니다. VM 네 개에 DIMM 채널을 나누고 메모리 마이크로벤치마크, Redis, Memcached, STREAM과 그래프 처리를 실행해 간섭과 애플리케이션 성능을 비교합니다. 특정 할당 조건에서 제어 기법이 작동하는지 확인하는 시험입니다.

이상적인 비교 대상은 하드웨어를 독점하는 경우이며, 일반 공유와 하드웨어 스로틀링 구성도 함께 비교합니다. 결과가 독점 환경에 가까웠다는 것은 그 시험에서 격리와 배치가 효과적이었다는 근거입니다. 임의의 애플리케이션, 프로세서와 CXL 장치에 같은 성능을 보장한다는 뜻은 아닙니다.

클러스터 활용률 분석은 별도의 근거입니다. 클라우드 트레이스에서 각 시점의 용량·대역폭 합계가 자원 한도 안에 들어가는 작업 쌍을 찾고, 일부 쌍은 부하 생성기로 재현합니다. 이는 상호 보완적인 작업을 배치할 여지를 보여 주지만, 실제 클라우드 전체에 배포해 관측한 성과는 아닙니다.

요약에 등장하는 활용률 개선에도 백분위 조건이 있습니다. 평가 본문은 평균 용량 활용률의 개선을 P30, 평균 대역폭 활용률의 개선을 P90에서 설명합니다. 이를 모든 서버의 평균 활용률이 같은 비율로 올랐다는 하나의 결론으로 합치지 않았습니다. 실제 스케줄러는 미래 수요를 모르는 상태에서 적합한 작업을 찾아야 하며, 다른 자원의 제약과 이동 비용도 부담해야 합니다.

관리형 AI 플랫폼의 도입 조건

먼저 VM별 용량 점유와 대역폭 수요, 지연 민감도를 분리해 측정해야 합니다. 용량이 큰 캐시와 대역폭을 많이 쓰는 전처리 작업이 메모리에서는 잘 맞더라도 CPU, 캐시와 입출력에서는 충돌할 수 있습니다. 서버 평균 활용률만 높이는 대신 높은 백분위 응답시간을 포함한 애플리케이션 목표로 통합 배치를 평가해야 합니다.

그다음에는 하드웨어를 제어할 수 있는지 확인해야 합니다. 펌웨어가 채널별 영역을 드러내는지, 게스트와 하이퍼바이저가 기존 메모리 관리 가정을 깨지 않고 이를 표현하는지, CXL 장치가 필요한 할당 단위를 제공하는지가 중요합니다. 이 조건이 맞아야 논문의 구현을 재현하고 성능 비교를 시작할 수 있습니다.

마지막으로 최종 상태만이 아니라 전환 과정을 시험해야 합니다. 실제 작업 집합을 유지한 채 대역폭을 늘리고 줄이면서 페이지 폴트와 이동의 영향을 측정하고, 관측 주기보다 짧은 부하도 넣어야 합니다. 변경 중에도 서비스 목표를 지키려면 기본 자원을 얼마나 남겨야 하는지 확인하는 단계입니다.

RamRyder는 토폴로지와 페이지 배치가 함께 제어될 때 메모리 대역폭을 명시적인 소프트웨어 자원으로 다룰 수 있음을 보여 줍니다. 메모리의 모든 제약이 사라진다는 것이 아니라, 이전에 묶여 있던 일부 수요를 나눌 수 있다는 의미입니다. 그 이점을 얻으려면 채널 단위, 게스트 소프트웨어 변경과 페이지 이동 시간을 함께 받아들여야 합니다.

출처와 저작권 안내

이 글은 OSDI 2026 최종 논문[1]을 바탕으로 작성한 독립적인 편집 분석입니다. 하드웨어 측정과 트레이스 결과의 범위를 구분했으며 도입 판단은 Silicon & Systems의 해석입니다. 원문 저자의 소속은 UC San Diego, 상하이교통대학교와 Samsung Semiconductor입니다. 원문의 문장·표·도판을 옮기지 않고 본문과 설명 그림을 새로 만들었습니다. 원 논문의 저작권은 해당 권리자에게 있으며(© 2026), 프로시딩 발행 기관은 USENIX Association입니다.