GPU VRAM 할당량과 실제 사용량의 차이: D3D12 메모리 상주 메커니즘, PCIe 공유 메모리 페이징 및 스터터링 분석

개요: 현대 PC 게임의 그래픽 메모리(VRAM) 용량 위기

게임 엔진이 Direct3D 12 및 Vulkan과 같은 저오버헤드 로우레벨 그래픽 API로 완전히 전환됨에 따라, 그래픽 카드 전용 메모리(VRAM) 소모량은 PC 게이밍 환경에서 가장 뜨거운 성능 병목 요소로 떠올랐습니다. 4K급 고해상도 텍스처, 정밀한 지오메트리 메시, 레이 트레이싱 BVH(Bounding Volume Hierarchy) 가속 구조체, 프레임 생성(Frame Generation) 중간 버퍼, 시간성 업스케일러(DLSS/FSR/TSR) 렌더 타깃 등은 GPU의 물리 메모리에 전례 없는 부하를 가하고 있습니다.

동시에 MSI Afterburner, RTSS, 윈도우 작업 관리자 등 하드웨어 모니터링 툴이 표기하는 수치에 대해 게이머들 사이에 광범위한 혼란과 오해가 발생하고 있습니다. 12GB 그래픽 카드에서 'VRAM 11.5GB 사용 중'이라는 오버레이를 보고 시스템이 곧 다운될 것이라 불안해하거나, 반대로 8GB 그래픽 카드로 평균 프레임은 양호하게 유지되다가도 시점을 빠르게 회전할 때 1% 로우 프레임이 100 FPS에서 8 FPS로 폭락하며 극심한 화면 끊김(스터터링)을 겪는 사례가 빈번합니다.

**VRAM 사전 할당량(Allocation / 캐시 확보 공간)**과 **동적 실제 사용량(Utilization / 워킹셋)**의 본질적인 기술 차이를 이해하고, Direct3D 12의 메모리 상주 관리(Residency) 및 PCIe 시스템 RAM 페이징(Paging) 메커니즘을 파악하는 것은 게임 프레임 불안정을 근본적으로 진단하고 해결하는 핵심 열쇠입니다.

VRAM 할당량과 실제 사용량: 모니터링 수치의 기술적 분리

성능 모니터링에서 발생하는 가장 큰 오판은 게임 엔진이 OS로부터 미리 확보해 둔 캐시 공간과 현재 프레임 렌더링에 실시간으로 쓰이는 데이터 부피를 동일시하는 데서 비롯됩니다:

1. 사전 할당 메모리(Committed / Allocated VRAM): 언리얼 엔진 5(Unreal Engine 5)나 RE 엔진과 같은 최신 엔진은 고속 GDDR 메모리에 대해 매우 공격적인 캐싱 전략을 펼칩니다. 렌더링 도중 빈번하게 운영체제에 메모리 할당 시스템 콜을 호출하여 오버헤드가 발생하는 것을 방지하기 위해, 엔진은 실행 초기나 로딩 단계에서 ID3D12Heap 등을 통해 방대한 크기의 메모리 힙을 일괄 선점합니다. 8GB나 16GB 그래픽 카드를 감지하면 엔진은 물리 VRAM의 80%~90%를 통째로 캐시 버퍼로 선점할 수 있습니다. 모니터링 툴은 이 예약된 전체 공간을 'VRAM 사용량'으로 표기하지만, 실제로는 그중 30%~40%의 메모리 페이지가 빈 캐시 슬롯으로 대기 중인 상태일 수 있습니다.
2. 동적 실제 사용량(Actual In-Use / Dynamic Working Set): 이 수치는 셰이더 코어, 래스터라이저, 레이 트레이싱 연산 장치가 현재 프레임을 그리기 위해 반드시 읽고 써야 하는 텍스처 밉맵, 정점 버퍼, 뎁스 버퍼, 렌더 타깃의 순수 실측 크기를 의미합니다. 오버레이에 11GB 할당으로 표시되더라도, 해당 장면에서 렌더 파이프라인이 실제로 요구하는 워킹셋은 6.2GB에 불과할 수 있습니다.
3. 탄력적 할당 한계의 함정: 게임 엔진의 메모리 풀 할당 알고리즘은 장착된 GPU의 물리 VRAM 크기에 맞춰 유동적으로 조절됩니다. 24GB VRAM을 가진 RTX 4090에서는 동일 장면에서 18GB를 사전 할당하고, 12GB VRAM인 RTX 4070에서는 10.5GB로 할당을 제한하여 렌더링할 수 있습니다. 두 그래픽 카드가 출력하는 시각적 디테일은 완전히 동일합니다. 높은 할당 수치 자체는 결함이 아니며, 최신 그래픽 엔진의 표준적인 캐싱 설계입니다.

Direct3D 12 메모리 상주 메커니즘과 페이지 퇴출 파이프라인

Direct3D 11 시절에는 그래픽 드라이버가 내부적으로 VRAM과 시스템 메모리 사이의 데이터 이동을 자동으로 처리했습니다. 그러나 Direct3D 12에서는 물리 메모리의 상주 관리(Residency Management) 책임이 전적으로 게임 애플리케이션 개발자에게 위임되었습니다:

[GPU 명령 큐: 현재 활성 프레임 렌더링]
          │
          ▼
[ID3D12Pageable: 리소스의 물리 메모리 상주 여부 확인]
          │
          ├─────────────────────────────────────────┐
          │                                         │
          ▼                                         ▼
[로컬 고속 GDDR VRAM에 상주 중]           [페이지 퇴출: 물리 VRAM 용량 한계 초과]
(대역폭: 504 ~ 1,008 GB/s)                (윈도우 OS가 미사용 페이지를 시스템 RAM으로 이동)
(지연 시간: 나노초 수준, 즉각 액세스)                     │
                                                          ▼
                                           [PCIe 버스 전송 병목 현상 발생]
                                           (PCIe 4.0 x16 이론상 대역폭은 약 31.5 GB/s 불과)
                                           (GPU 파이프라인 연산 중단 / 심각한 스터터링 유발)

ID3D12Pageable 인터페이스와 MakeResident 호출

D3D12에서 물리 메모리를 점유하는 모든 리소스는 ID3D12Pageable 인터페이스를 구현합니다. GPU가 텍스처나 버퍼를 참조하여 드로우 콜을 실행하기 전에:

• 게임 엔진은 반드시 MakeResident를 명시적으로 호출하여 해당 메모리 페이지가 로컬 VRAM에 물리적으로 배치되어 있음을 보장해야 합니다.
• 전체 데이터 요구량이 그래픽 카드의 물리 VRAM 용량을 초과하면, Direct3D 런타임은 Evict 호출을 통해 퇴출(Eviction) 프로세스를 강제 집행합니다.
• 최근 사용 빈도가 낮은 원거리 텍스처나 보조 버퍼가 초고속 GDDR에서 밀려나, 메인보드의 PCIe 버스를 통해 일반 시스템 RAM(DDR4/DDR5)으로 스왑(Paging)됩니다.

PCIe 버스 페이징 대참사: VRAM 부족이 프레임 드랍을 일으키는 이유

게임에 필요한 실제 워킹셋 데이터가 물리 VRAM 용량을 넘어 시스템 RAM과 VRAM 사이를 쉴 새 없이 오가기 시작하면(Overcommitment Paging), 성능은 완만하게 떨어지는 것이 아니라 순간적인 화면 멈춤과 거친 스터터링으로 무너집니다:

1. 대역폭의 극단적 격차:
   • 최신 전용 VRAM(GDDR6/GDDR6X)은 192-bit~384-bit의 넓은 버스를 통해 초당 504 GB/s~1,008 GB/s의 압도적인 대역폭을 뿜어냅니다.
   • 듀얼 채널 DDR5 6000MHz 시스템 메모리의 전송 대역폭은 약 80 GB/s~96 GB/s 수준입니다.
   • 둘을 연결하는 통로인 메인보드 PCIe 4.0 x16 슬롯의 이론상 최대 대역폭은 단 31.5 GB/s에 불과합니다.
2. GPU 파이프라인 정지(Pipeline Stall): GPU 셰이더 코어가 시스템 RAM으로 쫓겨난 텍스처 데이터를 읽으려 할 때, 수천 개의 연산 코어가 느린 PCIe 전송이 끝날 때까지 아무런 계산도 하지 못하고 완전히 멈춰 서게 됩니다. 평소 10밀리초 만에 렌더링되던 한 프레임이 90밀리초 이상 지체되면서, 게이머에게는 순간적으로 마우스가 먹통이 되거나 화면이 딱딱 끊기는 끔찍한 조작감으로 전달됩니다.
3. 레이 트레이싱 BVH의 치명적 결함: 광선 교차 연산은 전역 BVH 구조체에 대한 즉각적인 접근을 요구합니다. VRAM이 부족하여 레이 트레이싱 지오메트리 트리가 시스템 RAM으로 넘어가면 프레임이 회복 불가능할 정도로 붕괴하며, D3D 장치 손실(Device Lost) 오류로 게임이 튕기는 원인이 됩니다.

진단 매트릭스: 무해한 캐시 확보와 치명적인 VRAM 오버플로우 구별법

모니터링 데이터가 안전한 캐시 사전 확보인지, 아니면 즉각 조치가 필요한 시스템 RAM 페이징인지 판별하려면 다음 기준표를 참조하십시오:

그래픽 카드 업그레이드를 고민하거나 까다로운 그래픽 옵션을 조율할 때, 365Finds의 전문 하드웨어 분석 보고서를 참고하면 겉핥기식 수치에 얽매이지 않고 실제 시스템 병목을 정확히 파악할 수 있습니다. 겉으로 드러난 할당량과 실제 렌더링 작업 세트를 명확히 구분하는 것이야말로 끊김 없는 부드러운 게이밍 환경을 구축하는 첫걸음입니다.

참고 자료

• Memory Management in Direct3D 12 - Win32 apps | Microsoft Learn
• Residency - Win32 apps | Microsoft Learn
• DXGI Overview - Win32 apps | Microsoft Learn
• Steam Support :: Hardware and System Requirements