BoosterX: Windows 백그라운드와 CS2 FPS
목차
Windows의 백그라운드 활동과 FPS를 한 PC에서 네 단계로 비교했습니다. BoosterX 최적화를 순차적으로 적용한 뒤 Windows의 백그라운드 활동이 감소했고, 선택한 CS2 벤치마크의 평균 FPS는 준비된 Clean 시스템 대비 2,23–2,96% 증가했습니다. Advanced Advanced에서 평균 FPS가 가장 높았고, Expert Hardcore에서 P1가 가장 높았으며 기록된 유휴 상태의 활동이 가장 낮았습니다.
측정은 BoosterX 개발자가 수행했습니다. 결과는 명시된 테스트 환경에서 진행한 한 차례의 시리즈에 해당합니다. 계산에는 FPS 실행 8회와 WPR의 전체 5분 구간이 모두 포함되었습니다.
WPR 결과 · CS2 결과 · 방법론 · 원본 데이터 다운로드
확인한 내용
섹션 제목: “ 확인한 내용”목표: Clean → Safe Advanced → Advanced Advanced → Expert Hardcore 순서로 전환할 때, 고정된 CS2 시나리오에서 Windows의 백그라운드 활동과 성능이 어떻게 달라지는지 확인합니다.
WPR과 CapFrameX는 서로 다른 질문에 답합니다. WPR은 로그인 후와 유휴 상태에서 시스템이 작동하는 모습을 보여 줍니다. CapFrameX는 게임 부하 중 프레임 간격을 측정합니다. 백그라운드 CPU 사용량이 몇 배 감소했다고 해서 FPS도 같은 비율로 증가하는 것은 아닙니다.
테스트 환경 및 준비
섹션 제목: “ 테스트 환경 및 준비”| 매개변수 | 테스트 조건 |
|---|---|
| 측정 날짜 | 24년 10월 2026일 |
| CPU | AMD Ryzen 7 7800X3D, 코어 8개 / 스레드 16개 |
| GPU | NVIDIA GeForce RTX 5070, 드라이버 617.42 |
| RAM | 32GB, 2 × 16GB DDR5-6000 |
| 메인보드 / BIOS | ASRock B850 Riptide WiFi / 4.20 |
| Windows | Windows 11 Pro 26H2, 빌드 26300.9711 |
| BoosterX | 2.4.2.4, Debug 빌드; 사용한 바이너리 파일의 해시는 저장되지 않음 |
| CapFrameX | 1.8.6.2 |
| CS2 | CS2 FPS BENCHMARK DUST2, Workshop ID 3240880604 |
| 그래픽 | 1280×960, Low 프리셋, FidelityFX 끔, Reflex 켬, fps_max 0 |
| 기타 설정 | ReBAR, Game Mode 및 HAGS 켬; CapFrameX에서 표시 모드를 Fullscreen Optimized or Borderless로 감지 |
| 전원 | Clean, Safe 및 Advanced: «균형 조정»; Expert Hardcore: PowerX v2.1 |
준비: Windows를 새로 설치하고 모든 업데이트, Steam, Spotify 및 AMD 칩셋 드라이버를 설치했습니다. CS2 파일은 다른 드라이브에서 옮겼습니다. DDU로 비디오 드라이버를 제거한 뒤, NVIDIA 구성 요소를 줄인 사용자 지정 설치 도구를 통해 다시 설치했습니다. 구성 요소의 정확한 목록과 칩셋 드라이버 버전은 별도로 저장되지 않았습니다. 기준 측정 전에는 다른 수동 변경을 하지 않았습니다.
따라서 여기서 Clean은 BoosterX를 적용하기 전의 준비된 시스템을 의미하며, 앱과 드라이버가 이미 설치된 상태입니다. 설치 화면을 처음 마친 직후의 Windows를 뜻하지 않습니다. Clean의 ETL에도 OneDrive와 Edge 구성 요소의 활동이 포함되어 있습니다.
센서 데이터에 따르면 FPS 실행 중 CPU Max 평균 클럭은 약 5035–5043 MHz, GPU는 약 2927–2930 MHz였습니다. 클럭은 변동했으며, CPU/GPU 클럭을 고정한 상태에서 시리즈를 진행하지 않았습니다. CPU Max는 각 코어의 유효 클럭을 측정한 값이 아닙니다. PBO 및 Curve Optimizer 설정은 기록되지 않았습니다.
네 가지 상태는 한 번 설치한 Windows에서 순차적으로 적용했습니다. 각 단계에서 먼저 WPR 사이클을 수행한 다음 FPS 테스트를 진행했습니다. 단계 사이에 Clean 이미지로 되돌리지 않았으므로 변경 사항이 누적되었습니다. 보관된 자료에는 ETL이 없는 Expert Hardcore WPR 미완료 시도가 포함되어 있습니다. 요약에는 그다음에 완료된 기록을 사용했습니다. Expert Hardcore의 FPS 실행 1회는 완료된 WPR 기록 전에, 나머지 1회는 그 후에 수행했습니다.
WPR: 기록을 시작하고 로그인한 뒤 5분, 안정화 5분, 유휴 상태 5분을 측정했습니다. CPU, 디스크, 파일 및 네트워크 활동의 경량 프로필을 기록했습니다. 계산은 ETL에서 각 단계의 시작 및 종료 마커 사이를 직접 추출해 수행했습니다. 각 구간의 길이는 300초에서 0,02초 미만의 차이가 납니다. 8개 ETL 모두 헤더에 이벤트 및 버퍼 손실이 0으로 표시되어 있습니다.
첫 번째 단계는 Windows 부팅 후 약 15–23초에 시작했습니다. 이 테스트에서는 OS 부팅 시간을 측정하지 않았습니다. 요약 지표는 ETL에서 다시 계산했습니다.
CS2: 단계별로 약 105초씩 2회 실행했습니다. 자동화된 맵 시나리오를 사용했습니다. 기준 시점의 대략적인 한 지점에서 단축키를 눌러 CapFrameX 기록을 수동으로 시작했습니다. 프레임 단위로 시작 시점을 동기화하지 않았습니다. 프로세스 이름이 잘못 지정된 파일 2개 infinst.exe도 CS2 테스트에 해당합니다. 아카이브에는 원래 파일 이름과 JSON 내용이 보존되어 있습니다.
정확한 CS2 빌드, 기록 당시 맵 콘텐츠 버전, MSAA 개별 값 및 사전 워밍업 시간은 기록되지 않았습니다. 현재 Workshop 버전의 맵은 사용 당시와 다를 수 있습니다. 이 비교는 해당 맵에만 적용되며, 경쟁전 매치의 FPS를 나타내지 않습니다. 맵 제작자는 로컬 시뮬레이션과 서버에서의 게임 플레이가 다르다고 별도로 명시하고 있습니다.
WPR: Windows 백그라운드 활동
섹션 제목: “ WPR: Windows 백그라운드 활동”| 지표 | Clean | Safe Advanced | Advanced Advanced | Expert Hardcore |
|---|---|---|---|---|
| 로그인 후: 처음 5분 기록 | ||||
| 평균 CPU 사용률, % | 1.488기준 | 0.411Δ −1.077 퍼센트 포인트−72.37% | 0.314Δ −1.174 퍼센트 포인트−78.91% | 0.283Δ −1.205 퍼센트 포인트−80.99% |
| 약 1초 간격의 CPU 최고치, % | 30.60기준 | 14.30Δ −16.30 퍼센트 포인트−53.27% | 11.36Δ −19.24 퍼센트 포인트−62.89% | 6.44Δ −24.16 퍼센트 포인트−78.95% |
| CPU 시간 추정치, 코어·초 | 71.42기준 | 19.73Δ −51.68−72.37% | 15.06Δ −56.35−78.91% | 13.58Δ −57.84−80.98% |
| 컨텍스트 전환 / 초 | 5,781.8기준 | 1,330.6Δ −4,451.2−76.99% | 1,006.3Δ −4,775.4−82.59% | 763.3Δ −5,018.5−86.80% |
| 총 컨텍스트 전환 | 1,734,523기준 | 399,198Δ −1,335,325−76.99% | 301,900Δ −1,432,623−82.59% | 229,000Δ −1,505,523−86.80% |
| Ready 상태로 전환된 스레드 / 초 | 3,692.2기준 | 817.9Δ −2,874.2−77.85% | 614.7Δ −3,077.5−83.35% | 455.7Δ −3,236.5−87.66% |
| 구간 종료 시 프로세스 수 | 148기준 | 96Δ −52−35.14% | 92Δ −56−37.84% | 67Δ −81−54.73% |
| 구간 중 프로세스 시작 횟수 | 113기준 | 27Δ −86−76.11% | 18Δ −95−84.07% | 16Δ −97−85.84% |
| 구간 종료 시 스레드 수 | 2,566기준 | 1,718Δ −848−33.05% | 1,643Δ −923−35.97% | 1,349Δ −1,217−47.43% |
| 구간 중 스레드 시작 횟수 | 2,833기준 | 1,030Δ −1,803−63.64% | 832Δ −2,001−70.63% | 683Δ −2,150−75.89% |
| 프로세스 작업 집합 합계¹, MiB | 5,054.5기준 | 3,283.6Δ −1,770.9−35.04% | 2,954.5Δ −2,099.9−41.55% | 2,234.4Δ −2,820.0−55.79% |
| 프로세스 커밋 합계¹, MiB | 2,589.9기준 | 1,685.1Δ −904.8−34.93% | 1,586.2Δ −1,003.7−38.76% | 1,195.6Δ −1,394.3−53.84% |
| 프로세스 핸들¹ | 66,187기준 | 43,247Δ −22,940−34.66% | 40,520Δ −25,667−38.78% | 30,987Δ −35,200−53.18% |
| DPC / 초 | 981.7기준 | 347.4Δ −634.3−64.61% | 306.4Δ −675.4−68.79% | 204.2Δ −777.5−79.20% |
| 하드웨어 인터럽트(ISR) / 초 | 420.1기준 | 120.4Δ −299.7−71.34% | 102.7Δ −317.4−75.56% | 92.3Δ −327.8−78.03% |
| 구간 중 하드 폴트² | 16,251기준 | 9,661Δ −6,590−40.55% | 6,049Δ −10,202−62.78% | 5,271Δ −10,980−67.57% |
| 디스크 읽기, MiB | 920.36기준 | 295.67Δ −624.69−67.87% | 237.00Δ −683.36−74.25% | 218.96Δ −701.40−76.21% |
| 디스크 쓰기, MiB | 758.41기준 | 123.43Δ −634.98−83.73% | 89.13Δ −669.28−88.25% | 66.27Δ −692.13−91.26% |
| 이 중 WPR 파일 쓰기³, MiB | 591.76기준 | 85.00Δ −506.76−85.64% | 62.00Δ −529.76−89.52% | 42.00Δ −549.76−92.90% |
| 디스크 읽기 작업 | 29,124기준 | 16,718Δ −12,406−42.60% | 13,234Δ −15,890−54.56% | 12,391Δ −16,733−57.45% |
| 디스크 쓰기 작업 | 13,298기준 | 3,118Δ −10,180−76.55% | 2,157Δ −11,141−83.78% | 1,588Δ −11,710−88.06% |
| 구간 길이, 초 | 300.000 | 300.018 | 300.003 | 300.015 |
| 유휴 상태: 주기의 마지막 5분 | ||||
| 평균 CPU 사용률, % | 1.238기준 | 1.694Δ +0.456 퍼센트 포인트+36.86% | 0.337Δ −0.901 퍼센트 포인트−72.77% | 0.183Δ −1.055 퍼센트 포인트−85.25% |
| 약 1초 간격의 CPU 최고치, % | 12.17기준 | 17.74Δ +5.57 퍼센트 포인트+45.79% | 6.47Δ −5.70 퍼센트 포인트−46.86% | 6.25Δ −5.92 퍼센트 포인트−48.64% |
| CPU 시간 추정치, 코어·초 | 59.41기준 | 81.31Δ +21.90+36.86% | 16.18Δ −43.23−72.77% | 8.76Δ −50.64−85.25% |
| 컨텍스트 전환 / 초 | 1,944.9기준 | 2,061.6Δ +116.7+6.00% | 806.9Δ −1,138.0−58.51% | 336.5Δ −1,608.4−82.70% |
| 총 컨텍스트 전환 | 583,440기준 | 618,477Δ +35,037+6.01% | 242,071Δ −341,369−58.51% | 100,967Δ −482,473−82.69% |
| Ready 상태로 전환된 스레드 / 초 | 1,208.0기준 | 1,272.0Δ +64.0+5.30% | 522.9Δ −685.1−56.72% | 200.3Δ −1,007.7−83.42% |
| 구간 종료 시 프로세스 수 | 153기준 | 101Δ −52−33.99% | 90Δ −63−41.18% | 64Δ −89−58.17% |
| 구간 중 프로세스 시작 횟수 | 19기준 | 168Δ +149+784.21% | 6Δ −13−68.42% | 5Δ −14−73.68% |
| 구간 종료 시 스레드 수 | 2,388기준 | 1,678Δ −710−29.73% | 1,412Δ −976−40.87% | 1,189Δ −1,199−50.21% |
| 구간 중 스레드 시작 횟수 | 1,200기준 | 2,321Δ +1,121+93.42% | 541Δ −659−54.92% | 333Δ −867−72.25% |
| 프로세스 작업 집합 합계¹, MiB | 5,150.6기준 | 3,477.7Δ −1,672.9−32.48% | 2,890.6Δ −2,260.0−43.88% | 2,202.8Δ −2,947.8−57.23% |
| 프로세스 커밋 합계¹, MiB | 2,847.4기준 | 1,796.3Δ −1,051.1−36.91% | 1,587.9Δ −1,259.5−44.23% | 1,223.9Δ −1,623.5−57.02% |
| 프로세스 핸들¹ | 68,628기준 | 45,867Δ −22,761−33.17% | 39,888Δ −28,740−41.88% | 30,597Δ −38,031−55.42% |
| DPC / 초 | 1,210.5기준 | 277.5Δ −933.0−77.08% | 216.7Δ −993.7−82.09% | 108.8Δ −1,101.7−91.01% |
| 하드웨어 인터럽트(ISR) / 초 | 922.1기준 | 86.5Δ −835.6−90.62% | 64.3Δ −857.8−93.03% | 46.8Δ −875.3−94.93% |
| 구간 중 하드 폴트² | 636기준 | 5,258Δ +4,622+726.73% | 1,040Δ +404+63.52% | 1,203Δ +567+89.15% |
| 디스크 읽기, MiB | 12.90기준 | 105.32Δ +92.42+716.28% | 81.50Δ +68.60+531.64% | 9.83Δ −3.07−23.78% |
| 디스크 쓰기, MiB | 214.57기준 | 317.84Δ +103.27+48.13% | 86.97Δ −127.60−59.47% | 31.03Δ −183.54−85.54% |
| 이 중 WPR 파일 쓰기³, MiB | 164.00기준 | 172.00Δ +8.00+4.88% | 72.00Δ −92.00−56.10% | 15.00Δ −149.00−90.85% |
| 디스크 읽기 작업 | 634기준 | 5,281Δ +4,647+732.97% | 4,241Δ +3,607+568.93% | 836Δ +202+31.86% |
| 디스크 쓰기 작업 | 5,690기준 | 2,410Δ −3,280−57.64% | 1,250Δ −4,440−78.03% | 1,783Δ −3,907−68.66% |
| 구간 길이, 초 | 299.986 | 299.999 | 300.006 | 300.016 |
각 값 아래에는 같은 단계의 Clean 대비 Δ가 표시됩니다. 행의 단위로 나타낸 절대 차이와 백분율 기준 상대 변화입니다. CPU 사용률의 절대 차이는 퍼센트포인트(п.п.)로 표시했습니다. 마이너스는 지표 감소, 플러스는 증가를 뜻하며, 구간 길이에는 델타가 적용되지 않습니다. 수식: Δ = этап − Clean, Δ% = (этап / Clean − 1) × 100.
CPU는 CPU Usage (Sampled) 샘플을 사용해 계산했으며, 간격 길이를 반영하고 논리 프로세서 16개에 대해 평균을 냈습니다. CPU 시간 추정치는 평균 사용률 × 구간 길이 × 16 / 100입니다. 피크는 약 1초 간격에서 가져왔으며, 양 끝의 간격은 더 짧을 수 있습니다. 이벤트는 전체 구간 내에서 집계하고, 프로세스와 스레드는 Idle을 제외한 구간 종료 시점 기준입니다. 실행 횟수는 같은 프로세스가 다시 생성된 경우도 포함합니다.
¹ 메모리 및 핸들: ETL 완료 시점, 종료 마커 이후 0,28–0,65초에 프로세스 카운터를 스냅샷으로 기록했습니다. 정확한 시차는 JSON에 저장되어 있습니다. 작업 집합 합계에는 공유 페이지가 중복 포함되므로 사용 중인 물리 RAM과 같지 않습니다. 프로세스 Commit은 RAM 또는 페이지 파일로 뒷받침되어야 하는 할당된 가상 메모리를 나타내며, 페이지 파일에 실제로 기록된 양은 아닙니다. 이 합계에는 커널, 드라이버 및 파일 캐시의 전체 메모리가 반영되지 않습니다.
² Hard faults는 파일 페이지를 포함해 RAM에 없는 페이지를 디스크에서 불러오는 것을 뜻합니다. 하드웨어 메모리 오류가 아닙니다. DPC와 ISR은 이벤트 빈도를 나타내며, 입력 지연이나 처리 시간은 나타내지 않습니다.
³ WPR 기록은 로거 파일 이름을 기준으로 분리했습니다. 이 기록은 전체 디스크 쓰기량에 이미 포함되어 있습니다. 디스크 지표에는 측정 도구의 활동이 포함되므로 애플리케이션 부하만을 순수하게 추정한 값이 아닙니다.
Clean과 Expert Hardcore를 비교하면 로그인 후 CPU 샘플 사용률은 약 5,3배, 유휴 상태에서는 6,8배 감소했습니다. 유휴 상태의 컨텍스트 전환은 약 5,8배 감소했고, 구간 종료 시 프로세스 수는 153 → 64였습니다. 이는 실제 측정한 개별 지표의 비율이지, 단일한 «Windows 가속» 계수가 아닙니다.
Safe의 유휴 상태 부하가 더 높았던 이유
섹션 제목: “ Safe의 유휴 상태 부하가 더 높았던 이유”Safe 유휴 상태의 마지막 1분 동안 mscorsvw.exe 및 ngen.exe이 실행되었습니다. mscorsvw.exe에서 약 56,4 CPU 초가 발생했습니다. 분 단위 평균 CPU: 0,40 → 0,20 → 0,19 → 0,19 → 7,49%. 그 결과 처음 4분은 더 조용했지만 전체 구간은 Clean보다 부하가 높았습니다.
이 급증은 기본 표에 그대로 포함되어 있습니다. 한 차례의 순차적 시리즈만으로는 모드의 지속적인 효과와 일회성 백그라운드 작업 및 시간 경과에 따른 Windows 상태 변화를 구분할 수 없습니다.
메모리 및 디스크 지표 읽기
섹션 제목: “ 메모리 및 디스크 지표 읽기”전체 디스크 쓰기량에는 WPR 자체의 기록이 포함됩니다. 예를 들어 Clean 유휴 상태에서 214,57 MiB를 기록했으며, 이 중 164 MiB는 WPR 로거 파일에 직접 기록되었습니다. 이 부분은 표에서 별도 행으로 표시했습니다. 테스트 폴더는 OneDrive에 있었으며 동기화의 영향은 별도로 분리하지 않았습니다. 이 문서에서는 네트워크 속도와 전력 소비를 비교하지 않습니다.
CS2: FPS 및 프레임 시간
섹션 제목: “ CS2: FPS 및 프레임 시간”| 지표 | Clean | Safe Advanced | Advanced Advanced | Expert Hardcore |
|---|---|---|---|---|
| 평균 FPS | 888.29기준 | 911.19Δ +22.91+2.58% | 914.56Δ +26.28+2.96% | 908.08Δ +19.79+2.23% |
| P1 FPS | 296.73기준 | 304.42Δ +7.69+2.59% | 308.55Δ +11.82+3.98% | 312.15Δ +15.42+5.20% |
| P0,1 FPS | 259.15기준 | 265.90Δ +6.76+2.61% | 260.28Δ +1.13+0.44% | 264.29Δ +5.14+1.98% |
| 1% low: 느린 프레임 평균, FPS | 275.50기준 | 283.63Δ +8.14+2.95% | 283.41Δ +7.91+2.87% | 288.21Δ +12.71+4.61% |
| 평균 프레임 시간, ms | 1.126기준 | 1.097Δ −0.028−2.51% | 1.093Δ −0.032−2.87% | 1.101Δ −0.025−2.18% |
| 프레임 시간 P99, ms | 3.370기준 | 3.285Δ −0.085−2.53% | 3.241Δ −0.129−3.84% | 3.204Δ −0.167−4.95% |
| 인접 프레임 간 평균 차이, ms | 0.351기준 | 0.338Δ −0.013−3.64% | 0.335Δ −0.016−4.53% | 0.329Δ −0.022−6.30% |
| 평균 FPS: 2회 실행 범위 | 884.85 – 891.72 | 908.79 – 913.59 | 914.55 – 914.57 | 907.57 – 908.59 |
Advanced Advanced에서 평균 FPS가 가장 높았습니다. **914,56 대 Clean의 888,29, +2,96%**였습니다. Expert Hardcore는 평균 FPS에서 약간 뒤졌지만 P1가 가장 높았습니다. **312,15 대 296,73, +5,20%**였습니다. 가장 공격적인 단계가 모든 지표에서 가장 좋은 결과를 낸 것은 아닙니다.
각 실행의 평균 FPS는 1000 / среднее время кадра в мс입니다. P1는 1000 / P99 времени кадра입니다. P99는 정렬된 프레임에 선형 보간을 적용해 계산합니다. 단계별 결과는 두 실행의 평균입니다. 각 값 아래에는 Clean 대비 절대 및 상대 델타가 표시됩니다. FPS는 높을수록 빠르고, 프레임 시간은 낮을수록 빠릅니다. 1% low 행은 1000 / среднее время самых медленных 1% кадров로 별도 계산했으며 P1와 일치하지 않습니다.
8회 실행 전체 및 긴 프레임
| 단계 / 실행 | 프레임 수 | 평균 FPS | P1 FPS | P99, ms | 최장 프레임, ms |
|---|---|---|---|---|---|
| Clean / 1 | 93,631 | 891.72 | 299.70 | 3.337 | 11.956 |
| Clean / 2 | 92,911 | 884.85 | 293.75 | 3.404 | 12.453 |
| Safe Advanced / 1 | 95,928 | 913.59 | 306.00 | 3.268 | 10.488 |
| Safe Advanced / 2 | 95,424 | 908.79 | 302.84 | 3.302 | 7.385 |
| Advanced Advanced / 1 | 96,030 | 914.55 | 307.77 | 3.249 | 11.177 |
| Advanced Advanced / 2 | 96,031 | 914.57 | 309.32 | 3.233 | 8.448 |
| Expert Hardcore / 1 | 95,295 | 907.57 | 310.07 | 3.225 | 9.144 |
| Expert Hardcore / 2 | 95,403 | 908.59 | 314.23 | 3.182 | 8.894 |
모든 프레임 간격은 양수이며 시간 순서는 단조 증가합니다. 긴 프레임도 보존했습니다. 프레임은 서로 독립적인 실험 반복이 아닙니다. 단계별 FPS 실행은 2회뿐입니다. 표의 범위는 이 두 실행의 편차를 나타내며 신뢰 구간이 아닙니다.
GPU 평균 사용률은 약 74–76%였고, 피크는 95–96%까지였습니다. 이 데이터만으로 시나리오의 모든 구간이 CPU 병목이라고 단정할 수 없습니다. CapFrameX의 PcLatency 필드는 «마우스 움직임 → 화면 표시»의 물리적 지연으로 사용하지 않았습니다.
Frametime Variance: 프레임 균일성
섹션 제목: “ Frametime Variance: 프레임 균일성”CapFrameX의 Variances 탭 원리를 사용했습니다. 서로 인접한 두 프레임 시간 차이의 절댓값 |tᵢ − tᵢ₋₁|을 밀리초 단위로 계산했습니다. 프레임 쌍은 다섯 구간으로 분류했습니다. <2, 2–<4, 4–<8, 8–<12 및 ≥12 мс. 이는 인접 프레임 간 변동 지표이며, 여기서는 ms² 단위의 통계적 분산을 계산하지 않습니다. 구간 경계는 CapFrameX v1.8.6 소스 코드와 대조했습니다.
Expert Hardcore에서 차이가 2 ms 이상인 프레임 쌍의 비율은 **4,091%**로, Clean의 **5,879%**보다 낮았습니다. 이는 −1,787 퍼센트포인트, 즉 **Clean 대비 −30,4%**입니다. Safe Advanced의 감소율은 18,0%, Advanced Advanced는 **26,1%**입니다. 이 비율은 2 ms 이상의 인접 프레임 변동 비율을 나타내며, FPS 증가나 조준 정확도를 뜻하지 않습니다.
| 인접 프레임 간 차이 | Clean | Safe Advanced | Advanced Advanced | Expert Hardcore |
|---|---|---|---|---|
| <2 ms | 94.1214% | 95.1774%Δ +1.0561 퍼센트 포인트 | 95.6581%Δ +1.5367 퍼센트 포인트 | 95.9087%Δ +1.7873 퍼센트 포인트 |
| 2–<4 ms | 5.8540% | 4.8038%Δ −1.0502 퍼센트 포인트 | 4.3226%Δ −1.5313 퍼센트 포인트 | 4.0693%Δ −1.7847 퍼센트 포인트 |
| 4–<8 ms | 0.0166% | 0.0162%Δ −0.0004 퍼센트 포인트 | 0.0172%Δ +0.0006 퍼센트 포인트 | 0.0210%Δ +0.0044 퍼센트 포인트 |
| 8–<12 ms | 0.0075% | 0.0026%Δ −0.0049 퍼센트 포인트 | 0.0021%Δ −0.0054 퍼센트 포인트 | 0.0010%Δ −0.0065 퍼센트 포인트 |
| ≥12 ms | 0.0005% | 0.0000%Δ −0.0005 퍼센트 포인트 | 0.0000%Δ −0.0005 퍼센트 포인트 | 0.0000%Δ −0.0005 퍼센트 포인트 |
각 단계에서는 두 실행의 프레임 쌍 카운터를 합산했으며, 한 실행의 마지막 프레임과 다음 실행의 첫 프레임을 연결하지 않았습니다. 분모는 두 실행의 N − 1 합계입니다. 따라서 비율은 FPS 두 값의 평균과 달리 프레임 쌍 수에 따라 가중됩니다. 정확한 개수는 JSON과 CSV에 저장되어 있으며, 표의 비율은 소수점 이하 4자리까지 반올림했습니다. CapFrameX는 더 일찍 반올림하므로 마지막 표시 자릿수가 다를 수 있습니다.
주요 감소는 2–<4 ms 구간에서 나타났습니다. Expert Hardcore에서 4–<8 ms 변동 비율은 Clean보다 약간 높았습니다. **0,0210% 대 0,0166%**였습니다. 드문 변동을 포함해 모든 구간을 보존했습니다. 실행이 2회뿐이므로 이 변화의 재현성을 확인할 수 없습니다.
조준에 미치는 의미: 이 벤치마크에서는 2 ms 임계값 기준으로 프레임 간격이 더 균일해졌습니다. 조준점 움직임의 시각적 부드러움에 도움이 될 가능성은 추정에 불과합니다. 프레임 간격 기록은 조준 정확도, 마우스 움직임 또는 이미지가 표시될 때까지의 지연을 측정하지 않습니다. 이 시리즈만으로 «조준이 훨씬 좋아진다»고 약속할 수 없습니다.
결론 및 결과의 한계
섹션 제목: “ 결론 및 결과의 한계”이 순차적 시리즈에서는 로그인 후 백그라운드 활동이 감소한 것으로 기록되었습니다. 선택한 CS2 시나리오에서는 이후 세 단계 모두 준비된 Clean보다 평균 FPS가 높았습니다. 이 테스트 환경에서의 실제 결과는 평균 FPS 약 2–3% 증가이며, Advanced와 Expert Hardcore는 각각 다른 강점을 보였습니다.
이 연구로는 개별 설정의 기여도, 보편적인 성능 향상 폭, Windows 시작 시간 또는 물리적 입력 지연을 확인할 수 없습니다. Expert Hardcore에는 전원 관리 옵션 변경이 포함되므로 단계 전체를 하나의 묶음으로 비교했습니다. 프로세스 수 감소 자체는 게임 성능의 척도가 아닙니다.
제한 사항: PC 1대, 단계 순서 고정, 단계별 완료된 WPR 기록 1회, FPS 실행 2회, 수동 캡처 시작, 바이너리 파일 해시가 저장되지 않은 Debug 빌드. 순서 효과, 캐시 워밍업 및 백그라운드 유지 관리의 영향은 최적화 효과와 분리하지 않았습니다. Clean 유휴 상태에서는 Task Manager도 잠시 실행되었으며, 해당 구간을 잘라내지 않고 전체 구간을 보존했습니다. 이 시리즈에는 독립적인 재현이나 Clean으로 되돌리는 대조 테스트가 없습니다.
바이러스 백신과 FPS
섹션 제목: “ 바이러스 백신과 FPS”FPS를 위해 바이러스 백신을 끄는 것은 권장하지 않습니다. 이 시리즈는 변경 사항 전체를 묶어 비교했으며, «보호 켬 / 끔»이라는 단일 변수만을 대상으로 한 테스트는 없습니다. 따라서 바이러스 백신이 FPS에 전혀 영향을 주지 않는다는 점을 입증하지 않으며, 바이러스 백신을 껐을 때 절약되는 메모리도 별도로 측정하지 않았습니다.
Microsoft는 실시간 보호를 켜 둔 상태로 유지할 것을 권장합니다. 부하가 눈에 띄는 경우에는 구체적인 원인을 찾을 수 있는 Microsoft Defender 성능 분석을 사용할 수 있습니다.
상태 복원
섹션 제목: “ 상태 복원”이 측정에서는 Expert Hardcore 적용 후 원래 상태로 복원되는지 확인하지 않았습니다. 독립된 상태에서 테스트를 반복하려면 미리 준비한 Clean 이미지를 복원하고 복원 과정을 기록해야 합니다. 롤백의 일반적인 제한 사항은 BoosterX 복원 한계에 설명되어 있습니다.
원본 데이터 및 재계산
섹션 제목: “ 원본 데이터 및 재계산”8 ETL · 8 CapFrameX JSON · 표, 그래프 및 재계산 스크립트. 결과를 보려면 압축 파일 안의 README.html을 여세요. 원본 기록은 편집 없이 보존되어 있습니다. infinst.exe라는 이름의 파일 2개도 CS2 테스트에 포함됩니다.
아카이브 SHA-2567f20104f7eb46428e5e4f383515653b1320827be39fc171d1b5590210d0fbcdd
WPR, CSV · 모든 FPS 실행, CSV · Frametime Variance, CSV · 계산 결과, JSON · 재계산 스크립트
완료된 WPR 단계 4개의 원본 디렉터리, Expert Hardcore 미완료 시도, 원본 CapFrameX JSON 8개, 기록 스크립트, 방법론, 표, 그래프 및 재계산 소스 코드를 하나의 아카이브에 모았습니다. 이전 smoke 테스트와 이를 반복하는 보조 아카이브는 포함하지 않았습니다. 원본 디렉터리에 이전 검증 상태가 남아 있어도 여기 제시된 ETL 기반 계산에는 영향을 주지 않습니다.
ETL을 직접 분석하려면 Windows Performance Toolkit이 필요하며, 원본 게임 기록에는 CapFrameX를 사용할 수 있습니다. 스크립트 analysis/analyze.py는 Python 3 및 WPT 10+를 사용하며, 기록을 시작하거나 시스템을 변경하지 않습니다. 사용 방법은 README.html에 있습니다. 체크섬으로 파일이 변경되지 않았는지 확인할 수 있지만, 실험 조건 자체를 입증하지는 않습니다.
시스템 추적은 원본 그대로 보존되어 있습니다. 여기에는 프로세스, 로컬 경로 및 시스템 식별자를 포함한 테스트 설치 환경의 기술 정보가 들어 있습니다. 이 아카이브는 익명화되었다고 주장하지 않습니다. BoosterX 애플리케이션의 소스 코드와 타사 실행 파일은 포함되어 있지 않습니다.
출처 및 변경 이력
섹션 제목: “ 출처 및 변경 이력”- 이 시리즈의 원본 기록과 재계산 스크립트는 위에서 확인할 수 있습니다.
- CS2 FPS BENCHMARK DUST2: 맵 설명 및 제한 사항.
- Microsoft: CPU Analysis, CPU 샘플 및 컨텍스트 전환.
- Microsoft: xperf cswitch 및 시간 경계.
- Microsoft: Defender 상시 보호 권장 사항.
- Microsoft: 프로세스 메모리 카운터.
- CapFrameX: Variances 탭 및 분포 비교.
- CapFrameX v1.8.6: Frametime Variance 계산 소스.
- Wiki 연구 일반 방법론.
마지막 검토: 2026-10-25. 첫 번째 편집본은 10월 24일에 작성되었습니다. 물리적 PC 1대에서 네 단계를 테스트하고, 원본 측정 데이터와 재계산 자료를 공개했습니다. 10월 25일에 Clean 대비 델타, 확장 FPS 표 및 Frametime Variance를 추가했습니다. 이 연구는 BoosterX 개발자가 준비했습니다. 독립적인 검증을 위해 원본 기록, 테스트 조건 및 재계산 스크립트를 공개했습니다.