⚠️ 작성자 알림 (2026-08-10) — 본 글의 실험은 설계가 부실하여 결과 해석에 한계가 있음을 밝힙니다. 현재 마비노기는 DXVK가 게임사에서 공식 채택되어 적용되고 있습니다. 아래 내용은 이러한 배경을 감안하여 참고 바랍니다.
해석 범위 보완 (2026-10-13) — 아래 수치는 당시 제 환경에서 수집한 짧은 측정 기록의 비교입니다. 성능 차이는 관측했지만, 번역·동기화·컴파일 중 어떤 작업이 원인이었는지는 확인하지 못했습니다. 당시 결과를 다른 하드웨어나 현재 공식 적용 환경에 일반화하지 않습니다.
커뮤니티에서 DXVK를 적용하면 게임 프레임이나 스터터링(Stuttering)이 개선된다는 후기를 접했습니다. 이런 후기는 직접 비교해 볼 계기가 되었지만, 다른 타이틀이나 환경의 결과를 제 환경에 그대로 적용할 수는 없습니다.
최근 제가 즐겨하는 마비노기에서도 DXVK를 적용했을 때 체감 성능이 향상되었다는 흥미로운 후기들을 여럿 접하게 되었습니다.
다만 제가 이해하기로 플레이오네 엔진의 핵심 병목은 GPU의 처리 성능이라기보다는 엔진 구조에서 비롯되는 CPU 측의 Single-thread bottleneck에 더 가깝다고 생각했습니다. 따라서 Graphics API 교체만으로 근본적인 성능 개선을 기대하기는 어려울 것이라 판단했습니다.
때문에, 단순히 체감적인 부분에 머무르지 않고 객관적인 현상을 파악하고자, 직접 모니터링 로그를 수집하여 두 환경의 실측 데이터를 비교 및 분석해 보았습니다.
1. 테스트 환경 및 방법론
보다 정확하고 재현 가능한 비교를 위해 Frame time과 Presentation path를 로그로 남겼습니다.
- 측정 도구: Intel PresentMon
- 시나리오: 마비노기 던바튼 5채널 광장(오브젝트·캐릭터 밀도가 높은 구간), 백그라운드는 모니터링 툴만 존재, i5-14500HX + RTX 4060 laptop
- 절차: Native DX9과 DXVK 적용 상태에서 동일 위치에서 시작해 동일 동선으로 이동하도록 맞춰 기록
동선은 맞췄지만 온라인 광장의 캐릭터·이펙트 변화까지 동일하게 통제하지는 못했습니다. 본문에는 반복 측정에 따른 분산, 측정 순서의 영향, 캐시·워밍업 상태, 게임·DXVK·드라이버의 정확한 버전이 충분히 기록되어 있지 않습니다. 따라서 아래 비교로 차이의 재현성이나 원인별 기여도를 판단하기는 어렵습니다.
2. 벤치마크 결과 (실측 데이터)
Intel PresentMon을 활용하여 Native DX9 상태와 DXVK 적용 상태에서 각각 30초씩 측정 후 추출한 실측 CSV 데이터의 비교 결과입니다.
이 측정 기록에서는 순정 상태 대비 Average FPS는 약 29% 하락, 5% Low FPS는 약 21% 하락, 1% Low FPS는 약 42% 하락했습니다. Low FPS의 하락은 느린 프레임 구간을 더 살펴볼 단서입니다. 다만 이 수치만으로 체감 끊김의 정도나 특정 작업이 지연을 일으켰는지는 판단할 수 없습니다.
3. 결과 해석: 가능한 원인과 확인 범위
아래는 관측된 성능 차이를 설명할 수 있는 원인 후보입니다. PresentMon으로 비교한 FPS와 프레임 타임만으로는 CPU·GPU의 병목 위치나 특정 작업의 비용을 분리할 수 없습니다. 따라서 다음 설명은 측정으로 확인된 원인이 아니라 추가 프로파일링으로 검토할 가설입니다.
Graphics Pipeline 관점에서의 비교
한 프레임을 화면에 렌더링하기 위해서는 애플리케이션이 Graphics API에 명령(Draw call 등)을 쌓고 → Driver와 Runtime이 이 명령들을 GPU 큐(Queue)로 넘긴 후 → GPU가 최종적으로 명령을 실행하는 반복적인 과정이 필요합니다. 여기서 핵심은 단순히 “GPU 성능이 높다”가 아니라, CPU 측에서 매 Frame마다 API 및 Driver와 Sync(동기화)를 맞추고 Command Buffer를 빌드하는 과정이 Frame budget(프레임을 그려내는 데 할당된 시간)을 얼마나 소모하느냐입니다.
- Native DX9 경로: Windows 환경에서 제공하는 D3D9 → DX9 User-mode driver stack → Kernel scheduler → GPU로 이어지는, 수십 년간 튜닝되어 온 기존 경로를 그대로 거칩니다.
- DXVK 경로: 게임 클라이언트가 뱉어내는 동일한 D3D9 계열의 API 호출을 받은 직후, 이 **D3D9 명령어들을 Vulkan API call & submit으로 번역하는 Translation layer(번역 계층)**가 중간에 삽입됩니다.
번역 경로가 추가되면 CPU 비용의 구성이 달라질 수 있습니다. 다만 처리 단계가 늘었다는 사실만으로 총비용이 증가한다고 단정할 수는 없습니다. 경로별 최적화와 동기화 방식까지 포함한 실제 비용을 비교해야 합니다.
아래는 두 처리 경로를 Logical blocks로 단순화하여 도식화한 다이어그램입니다 (실제 구현 및 Threading 모델은 드라이버 및 운영체제 버전마다 상이합니다).
flowchart LR subgraph nat["순정 Native DX9"] direction TB n1["엔진 / 게임 로직"] --> n2["D3D9 API"] n2 --> n3["DX9 Runtime · User driver"] n3 --> n4["Kernel scheduler / GPU"] end subgraph dxvk["DXVK"] direction TB v1["엔진 / 게임 로직"] --> v2["D3D9 API"] v2 --> v3["DXVK Translation · Vulkan build"] v3 --> v4["Vulkan Driver"] v4 --> v5["Kernel scheduler / GPU"] end
이 글에서는 PresentMon 기록에서 산출한 FPS와 프레임 타임 분포를 비교했습니다. 이 비교는 성능 차이를 보여주지만, 지연이 번역·컴파일·동기화 중 어디서 발생했는지를 설명하지는 않습니다. 전체 입력부터 화면 출력까지의 지연을 별도로 검증한 측정으로도 해석하지 않습니다.
① Main thread & Translation overhead
검토할 후보 중 하나는 API 호출·제출 경로의 CPU 비용과 동기화 대기입니다. 서로 다른 그래픽 경로를 사용할 때 이 비용이 어떻게 달라졌는지를 확인할 필요가 있습니다.
게임 로직과 번역·제출 작업이 제한된 CPU 실행 시간을 공유한다면 프레임 지연에 기여할 가능성이 있습니다. 다만 이번 기록만으로는 플레이오네 엔진의 메인 스레드가 한계에 도달했다거나, 씬 처리·스크립트·물리 연산 중 어떤 작업과 자원 경쟁이 발생했다고 확인할 수 없습니다. 이를 구분하려면 스레드별 실행 시간과 호출 스택을 함께 살펴봐야 합니다.
② 셰이더·파이프라인 컴파일 지연 가설
1% Low FPS 하락을 설명할 후보 중 하나는 셰이더 변환·파이프라인 컴파일 지연입니다.
새로운 셰이더나 파이프라인이 필요한 구간에서 관련 작업이 프레임 지연에 기여했을 가능성을 검토할 수 있습니다. 하지만 새로운 Draw call마다 컴파일이 발생했다고 볼 근거는 없으며, 당시 두 경로의 캐시 상태도 충분히 기록하지 못했습니다. 프레임 타임 스파이크를 관측한 사실과 그 원인이 컴파일이라는 주장은 구분해야 합니다.
이 가설을 검토하려면 캐시가 비어 있는 실행과 워밍업한 실행을 구분해 반복 측정하고, 컴파일 관련 이벤트·호출 스택을 프레임 타임과 대조해야 합니다. 이 글에서는 캐시 구축 후의 개선 여부나 컴파일 지연의 불가피성을 확인하지 못했습니다.
③ 1% Low Frame에 대한 시스템 수준 가설
측정된 1% Low FPS의 급격한 하락과 프레임 타임 스파이크가 어떤 단일 병목에서만 비롯되는지는, PresentMon 수준의 로그만으로는 좁히기 어렵고 GPU·CPU 타임라인을 포함한 심층 프로파일링이 추가로 필요합니다. 그럼에도 불구하고, 시스템 아키텍처 관점에서 다음과 같은 복합적 원인 후보를 가설 형태로 정리해 볼 수 있습니다.
- DXVK 번역 및 셰이더 컴파일 경로(②와 연계): 새로운 Draw call이 유입될 때 SPIR-V 변환·파이프라인 컴파일이 끼어들면서, 그 처리가 특정 구간에서 단일 논리 스레드(또는 이에 긴밀히 동기화된 경로)에 부하를 집중시켰을 가능성. (②에서 서술한 Micro-stuttering 메커니즘과 같은 축입니다.)
- 레거시 엔진 로직과 현대 그래픽 스택의 상호작용: 과거에 고정된 D3D9 시대의 상태 전이·드로 순서가, Vulkan 측 드라이버·IR 최적화가 가정하는 사용 패턴과 어긋나 번역·제출 경로에서 오히려 최적화 여지를 줄이는 형태로 동작했을 가능성.
- OS·런타임 차원의 스케줄링·동기화 비용: 번역 계층이 끼어들면서 DXVK·드라이버·커널 사이에 추가 스레드·펜스·큐 동기가 늘고, 그에 따른 컨텍스트 스위칭이나 대기 구간이 CPU 예산을 더 압박했을 가능성.
- 드라이버·벤더별 경로 의존성: 본 테스트는 NVIDIA 드라이버 + 해당 노트북 GPU 조합에 한정됩니다. 동일한 SPIR-V·파이프라인 부하라도, 드라이버 버전·내부 최적화·게임 프로파일 유무에 따라 지연 분포가 달라질 수 있으며, “특정 클라이언트가 생성하는 IR을 항상 최적으로 처리하지 못한다”는 식의 환경 의존적 가설로만 두는 것이 타당합니다.
위 항목들은 상호 배타적이지 않고 동시에 기여했을 수 있으며, 실제 기여도는 추후 프로파일링으로만 줄일 수 있습니다.
4. 결론
관측한 사실은 2절의 짧은 측정 기록에서 DXVK 적용 상태의 평균·Low FPS가 순정 상태보다 낮았다는 점입니다. 3절의 ①·②·③은 모두 가능한 원인에 관한 가설이며, 실측으로 확인한 병목이나 작업 내용이 아닙니다.
추가 검증이 필요한 부분은 이 차이가 반복 측정에서도 재현되는지, 캐시·장면·측정 순서의 영향이 어느 정도인지, 번역·동기화·컴파일 작업이 실제 프레임 지연에 기여했는지입니다. 후속 WPA 분석에서도 스레드 활동의 동시 관측만으로 특정 작업의 인과관계를 확정할 수는 없습니다.
당시 제 환경과 시나리오의 기록에서는 Native DX9의 Average 및 Low FPS 지표가 더 높았습니다. 다만 반복 측정의 분산을 제시하지 못했으므로 장기적인 안정성이나 일반적인 우열까지 판단하지는 않습니다.
이 기록은 제 측정 조건에서 기대했던 성능 향상을 관측하지 못했다는 경험을 보여줍니다. 다른 하드웨어·버전·공식 적용 환경에서도 같은 결과가 나온다는 결론이나, 엔진과 DXVK의 구조적 호환성 문제를 주장할 근거로 삼기에는 부족합니다.
이 글은 당시 수동 적용 환경의 성능 측정 기록이며, 클라이언트 변경의 허용 여부나 제재 정책을 검증한 자료는 아닙니다.