유휴 상태: 최적화 전후의 Windows 백그라운드 활동
목차
간단한 답변
섹션 제목: “간단한 답변”Windows 백그라운드 구성 요소를 비활성화하면 유휴 상태가 실제로 더 조용해집니다. 독립적인 두 측정 시리즈에서 프로세스 수는 49–56 % 감소했고, 유휴 상태의 CPU 사용률은 17–67 % 감소했으며, 두 번째 시리즈에서는 메모리 커밋(commit)이 52 % 감소했습니다. 하지만 CPU 전체 부하에서는 처리량이 0,2–0,5 %만 증가했습니다. «조용한 유휴 상태»란 백그라운드 작업과 리소스 경쟁이 줄어든다는 점이 확인되었다는 뜻이지, FPS가 향상된다는 뜻은 아닙니다. 이 연구에서는 최종적인 게임 성능 효과를 측정하지 않았습니다.
상태: 가상 머신의 동일한 Windows 11 빌드에서 독립적인 두 측정 시리즈를 통해 효과의 방향이 재현되었습니다. 시리즈별 수치가 다른 이유는 Windows 백그라운드 작업이 간헐적으로 발생하기 때문입니다. Microsoft Defender 검사가 진행되는 구간에서는 CPU 사용률 차이가 −67 %에 이르지만, 이미 조용한 구간에서는 −17 %입니다.
검증 가능한 주장
섹션 제목: “검증 가능한 주장”다음 네 가지 주장을 검증했습니다.
- 백그라운드 구성 요소를 비활성화하면 유휴 상태의 시스템 활동이 눈에 띄게 감소한다.
- 부팅 후 처음 몇 분 동안의 활동이 눈에 띄게 감소한다.
- 메모리 사용량이 눈에 띄게 줄어든다.
- CPU 전체 부하에서 측정 가능한 성능 향상이 나타난다.
연구 범위
섹션 제목: “연구 범위”- Windows 11 Pro, build 26300.9457 (26H2);
- 가상 머신: 4 vCPU, 8 GB RAM, VMware 가상화;
- 동일한 설치 환경의 두 상태: 초기 상태(«최적화 전»)와 BoosterX 최적화 프로필 적용 후 상태(측정일 기준 최신 빌드);
- 독립적인 두 측정 시리즈: 2026-09-18 및 2026-09-19. 측정이 서로 영향을 주지 않도록 독립적인 디스크 복사본에서 상태를 비교했습니다.
- 단계: 부팅 후 5분, 안정화 5분, 유휴 상태 5분;
- 짧은 합성 부하: 1, 4 및 8개 스레드, 메모리 부하, 간헐적 부하 및 우선순위 혼합.
실제 게임, GPU 부하, 물리적 하드웨어, 장시간 측정 구간(시간 및 일 단위)은 연구에 포함되지 않았습니다.
Ryzen 7 7800X3D가 장착된 물리적 PC에서 네 단계와 게임 측정을 수행한 별도 시리즈는 «BoosterX: Windows 백그라운드 작업과 CS2 FPS» 문서에 게시되어 있습니다. 해당 결과는 이 가상 머신 측정 시리즈와 합산하지 않습니다.
방법론
섹션 제목: “방법론”프로토콜은 «Windows 연구 방법»을 따릅니다.
- 각 단계는 ETW 추적(Windows Performance Recorder의 CPU, 디스크, 파일 및 네트워크 경량 프로필)과 성능 카운터로 기록했습니다. 시스템 카운터 간격은 5초, 프로세스별 카운터 간격은 15초였습니다.
- «부팅 후» 단계는 제어된 재부팅으로 시작했으며, 가동 시간이 약 1분일 때 측정을 시작했습니다.
- 각 추적에서 손실된 이벤트 수를 확인했습니다. 아래에 제시된 모든 구간에서 손실된 이벤트는 0개입니다.
- 단계 경계 안의 완전한 5초 간격만 평균에 포함했습니다(단계당 59개 간격).
- 2 시리즈에서는 가상 머신이 절전 모드로 전환된 첫 번째 «최적화 전» 실행을 제외하고 재실행 결과를 사용했습니다.
- 부하 테스트는 각각 두 번 수행하고 중앙값을 제시했습니다. CPU 사용률은 4개의 vCPU를 기준으로 정규화했습니다.
«최적화 전»과 «최적화 후»는 동일한 Windows 설치 환경의 두 상태입니다. «최적화 후» 상태는 최적화 프로필을 적용해 만들었고, «최적화 전»은 초기 상태입니다. 설정 전체를 한꺼번에 변경했으므로 개별 비활성화 항목의 기여도는 평가하지 않았습니다.
유휴 상태
섹션 제목: “유휴 상태”1 시리즈(2026-09-18) — 활성 유지 관리 작업이 없는 안정된 유휴 상태:
| 지표 | 최적화 전 | 최적화 후 | 변화 |
|---|---|---|---|
| CPU 사용률, % | 2,48 | 2,06 | −17 % |
| DPC + ISR, % CPU | 1,73 | 1,59 | −8 % |
| 컨텍스트 전환, /초 | 469 | 381 | −19 % |
| 프로세스(평균) | 134,9 | 69,3 | −49 % |
| 스레드(평균) | 1 444,6 | 738,7 | −49 % |
| 모든 프로세스의 총 CPU 사용률, % | 1,22 | 1,06 | −13 % |
| 사용 가능한 메모리, MB | 5 490 | 6 518 | +1 028 |
| 디스크 읽기, KB/초 | 22,6 | 24,4 | +8 % |
| 디스크 쓰기, KB/초 | 311,3 | 262,1 | −16 % |
| 네트워크(수신), KB/초 | 132,6 | 2,2 | −98 % |
| 네트워크(송신), KB/초 | 43,2 | 4,7 | −89 % |
2 시리즈(2026-09-19) — 동일한 유휴 구간이지만, «최적화 전» 상태에서 Microsoft Defender 백그라운드 검사가 진행되었습니다.
| 지표 | 최적화 전 | 최적화 후 | 변화 |
|---|---|---|---|
| CPU 사용률, % | 33,37 | 11,03 | −67 % |
| 컨텍스트 전환, /초 | 3 737 | 291 | −92 % |
| 프로세스(평균) | 142,3 | 61,9 | −56 % |
| 스레드(평균) | 1 494,7 | 637,1 | −57 % |
| 사용 가능한 메모리, MB | 5 174 | 6 653 | +1 479 |
| 사용 중인 물리 메모리, MB | 3 017 | 1 538 | −49 % |
| 메모리 커밋(commit), MB | 2 617 | 1 249 | −52 % |
| Nonpaged pool, MB | 298,2 | 212,9 | −29 % |
| Paged pool, MB | 258,5 | 86,0 | −67 % |
| DPC, % CPU | 0,89 | 0,19 | −78 % |
| 디스크 읽기, MB/초 | 7,42 | 0,01 | −99,9 % |
| 디스크 쓰기, MB/초 | 4,57 | 0,23 | −95,0 % |
2 시리즈의 유휴 상태에서는 두 상태 모두 네트워크 활동이 거의 없었으므로(초당 수십 바이트), 네트워크 행은 제시하지 않습니다. 두 시리즈의 차이는 모순이 아니라 백그라운드 작업 자체의 특성입니다. Windows가 유지 관리 작업을 수행할 때는 백그라운드 구성 요소를 비활성화해 절약되는 양이 더 많고, 이미 조용한 구간에서는 더 적습니다.
부팅 후 처음 몇 분
섹션 제목: “부팅 후 처음 몇 분”| 지표 | 1 시리즈(최적화 전 → 최적화 후) | 2 시리즈(최적화 전 → 최적화 후) |
|---|---|---|
| CPU 사용률, % | 3,42 → 2,59 | 14,62 → 11,88 |
| 컨텍스트 전환, /초 | 1 114 → 600 | 1 257 → 393 |
| 프로세스 | 132 → 74 | 139 → 64 |
| 스레드 | — | 1 719 → 746 |
| 사용 중인 물리 메모리, MB | — | 2 821 → 1 581 |
| 사용 가능한 메모리, MB | — | 5 370 → 6 610 |
| 디스크 읽기, KB/초 | — | 826 → 433 |
| 디스크 쓰기, KB/초 | 634 → 418 | 709 → 298 |
| 네트워크(수신), KB/초 | — | 1,15 → ~0 |
대시는 해당 시리즈에서 해당 단계의 지표를 기록하지 않았다는 뜻입니다.
구성 및 메모리
섹션 제목: “구성 및 메모리”유휴 상태의 인벤토리 스냅샷(1 시리즈):
| 최적화 전 | 최적화 후 | |
|---|---|---|
| 프로세스 | 136 | 70 |
| 스레드 | 1 679 | 842 |
| 총 working set, MB | 3 841 | 1 868 |
| 총 private bytes, MB | 1 524 | 660 |
최적화 전 메모리 사용량이 가장 큰 항목: 바이러스 백신 프로세스 MsMpEng.exe(257 MB), explorer.exe(213 MB), StartMenuExperienceHost(144 MB), msedge.exe(133 MB), SearchHost.exe(122 MB). 최적화 후에는 explorer.exe(170 MB), msedgewebview2(119 MB), SearchHost.exe(115 MB), StartMenuExperienceHost(106 MB)이 상위 항목이었습니다.
사용 가능한 메모리는 1,0–1,5 GB 증가했고, 메모리 커밋(commit)은 52 % 감소했습니다. 이 중 실제로 «해제»할 수 있는 메모리는 무엇인지, 프로세스 working set의 합계가 여유 메모리와 왜 다른지는 «Windows에서 실제로 얼마나 많은 메모리를 확보할 수 있는가»에서 설명합니다.
전체 부하 상태
섹션 제목: “전체 부하 상태”짧은 합성 테스트(2 시리즈, 두 번의 반복 측정 중앙값):
| 시나리오 | 처리량 변화 | CPU 사용률: 최적화 전 / 최적화 후 |
|---|---|---|
| 단일 스레드 | +5,4 % | 21,9 / 22,6 % |
| 4개 스레드(전체 부하) | +0,19 % | 88,9 / 89,4 % |
| 8개 스레드(전체 부하) | +0,50 % | 88,9 / 88,8 % |
| 메모리 부하 | +11,2 % | 84,8 / 87,5 % |
| 간헐적 부하(일시 중지 1 ms) | +5,4 % | 64,3 / 67,7 % |
| 혼합 우선순위 | +8,5 % | 21,2 / 22,5 % |
| 백그라운드 우선순위 | +77,1 % | 38,8 / 65,2 % |
4개 스레드를 모두 사용하는 전체 부하에서 유용한 프로세스는 최적화 전후 모두 4개 vCPU 용량의 약 89 %를 사용했습니다. 가상 머신에서 남은 ~11 %를 제거 가능한 «Windows 잡음»이라고 단정할 수는 없습니다. 게스트 추적에서는 하이퍼바이저 스케줄링을 볼 수 없기 때문입니다. 작업 스레드는 균등하게 분배되었고(스레드 간 작업량 편차는 0,994–0,997), 기아 현상은 관찰되지 않았으며, 최적화 후 유휴 상태의 CPU 대기열은 거의 비어 있었습니다.
백그라운드 작업의 원인
섹션 제목: “백그라운드 작업의 원인”«최적화 전» 상태에서 측정된 백그라운드 활동의 원인:
- 바이러스 백신 검사 — 2 시리즈 구간의 주요 원인입니다. 프로세스
MsMpEng.exe은 5분간의 유휴 구간에서 CPU 시간 212초를 사용했습니다. - 초기 상태에서는 검색 서비스, SysMain 서비스, 원격 분석, 인쇄 스풀러 및 기타 구성 요소가 실행 중이었습니다. 최적화 프로필은 백그라운드 서비스 약 50개와 예약된 작업 58개를 사용 안 함 상태로 전환합니다.
- 부팅 후에는 Windows 업데이트 오케스트레이터가 활동을 유발합니다.
백그라운드 구성 요소를 비활성화해도 백그라운드 작업이 완전히 사라지지는 않습니다. 최적화된 상태에서도 애플리케이션 호환성 평가가 계속 실행되었으며(유지 관리 구간에서 초당 CPU 약 3,7 ms), 안정된 유휴 상태의 잔여 백그라운드 작업은 초당 CPU 4,8 ms였습니다. 이는 4개 vCPU 용량의 약 0,12 %에 해당합니다(추적 데이터 기준).
확인된 사항
섹션 제목: “확인된 사항”- 재현됨(독립적인 두 시리즈): 프로세스 수 −49…−56 %, 스레드 수 −49…−57 %, 사용 가능한 메모리 +1,0–1,5 GB.
- 측정됨(2 시리즈): 유휴 상태에서 메모리 커밋(commit) −52 %, 유휴 상태에서 사용 중인 물리 메모리 −49 %, 부팅 후 단계에서 −44 %.
- 측정됨: 유휴 상태의 CPU 사용률은 조용한 구간에서 −17 %, 검사 구간에서 −67 %였습니다. 컨텍스트 전환은 각각 −19 %와 −92 %, DPC는 −78 %(2 시리즈 구간)였습니다. 부팅 후 활동은 두 시리즈 모두에서 감소했습니다.
- 측정됨: CPU 전체 부하에서 처리량은 +0,19 %(4개 스레드) 및 +0,50 %(8개 스레드) 증가했습니다. 부분 부하 및 혼합 부하에서는 +5,4 %에서 +11,2 %까지 증가했습니다.
- 측정됨: 백그라운드 우선순위 수준의 부하는 77,1 % 빨라졌습니다. «최적화 전» 상태에서는 바이러스 백신 검사 등 Windows 자체 백그라운드 작업과 경쟁했습니다.
- 관찰됨: 주요 백그라운드 작업은 바이러스 백신 검사, 유지 관리 및 호환성 작업이었습니다. 최적화 후 잔여 백그라운드 작업은 거의 0에 가깝지만 0은 아닙니다.
확인되지 않은 사항
섹션 제목: “확인되지 않은 사항”- 실제 게임에서의 FPS 향상, input lag 또는 frametime 감소: 측정하지 않았습니다. 합성 CPU 테스트는 GPU를 사용하는 게임을 모델링하지 않으며, 게임 성능 효과를 입증하지 않습니다.
- 개별 비활성화 항목의 기여도: 변경 사항을 묶음으로 적용했습니다.
- 절대 수치를 물리적 하드웨어, 다른 빌드 및 다른 최적화 프로필에 적용하는 것.
- 장시간 구간에서의 지속성: 각 단계는 5분이었습니다. Windows 백그라운드 작업은 간헐적으로 발생하므로 «평균적인 하루»는 측정하지 않았습니다.
제한 사항
섹션 제목: “제한 사항”- 측정은 가상 머신에서 수행했습니다. 가상화는 자체적인 DPC/ISR을 발생시키고 호스트의 스케줄링을 숨깁니다. 물리적 하드웨어에서는 절대 수치가 달라집니다. 동일한 조건에서 비교한 «최적화 전/후»의 비율과 변화 방향은 유지됩니다.
- ISR 지표는 표에서 제외했습니다. 가상 머신에서 PDH의 ISR 카운터는 ETW의 인터럽트 처리기 수치와 약 10 % 차이가 나며, 정확한 합계와 일치하지 않습니다.
- 2 시리즈의 «최적화 전» 구간에는 Defender 검사가 진행 중이었고, 구간별 호스트 부하도 달랐습니다(평균 44 % 대 24 %). 따라서 수치는 특정 구간에 한정되며, 변화 방향은 두 시리즈에서 확인되었습니다.
- 1 시리즈에서는 가상 머신이 약 26초 동안 외부 일시 중지되어 유휴 단계 일부가 중단되었습니다. 재개 후 캡처가 완료되었으며, 손실된 이벤트는 없습니다.
- 부하 테스트는 두 번 반복했습니다. 따라서 기술 통계이며, 통계적 유의성은 평가하지 않았습니다.
- 유휴 상태에서 얻은 이점의 일부는 Microsoft Defender 보호 구성 요소를 비활성화한 데서 비롯됩니다. 바이러스 백신 보호가 없는 시스템은 의도적인 절충이지, 비용 없는 최적화가 아닙니다. 보호 기능을 비활성화할 때는 그 대가를 이해해야 합니다.
- 측정 계층(추적 및 카운터) 자체도 소량의 백그라운드 부하를 발생시키며, 이 부하는 두 상태 모두에 존재합니다.
연구와 사용된 도구는 BoosterX 개발자의 소유이므로 개발자는 결과에 직접적인 이해관계가 있습니다. 방법론과 적용 범위는 위에 설명되어 있으며, 공개 데이터와 열거된 공개 자료를 통해 결론을 검증할 수 있습니다.
실용적인 결론
섹션 제목: “실용적인 결론”백그라운드 잡음 감소는 실제로 확인되었고 두 차례 재현된 효과입니다. 프로세스와 스레드 수는 절반으로, 메모리 커밋은 절반으로 줄었으며, 유휴 상태의 디스크 및 네트워크 활동은 한 자릿수 배수만큼 감소했습니다. 이는 시스템 응답성, 백그라운드 작업, 온도, 팬 소음 및 배터리 사용 시간에 그 자체로 도움이 되며, FPS 향상을 약속할 필요가 없습니다.
기대하지 말아야 할 점은 전체 부하에서의 성능 향상입니다. CPU가 이미 유용한 작업으로 용량의 ~89 %를 사용 중이라면, 백그라운드 활동을 비활성화해도 남은 11 %가 추가되지는 않습니다. 가상 머신에서는 그 용량이 Windows에 속하지 않습니다. 비교 시점에 시스템이 어떤 작업을 수행 중인지에 따라 눈에 보이는 효과가 달라집니다. 유지 관리 구간에서는 차이가 몇 배에 이르지만, 조용한 구간에서는 완만합니다.
권장 사항: 다른 사람의 백분율을 기준으로 삼지 말고, 자신의 컴퓨터에서 변경 전후의 백그라운드 작업을 확인하세요(Task Manager → «성능» 및 «프로세스», 리소스 모니터). 특정 게임의 FPS가 목표라면 변경 전후에 해당 게임의 FPS를 직접 측정하세요.
상태 복원
섹션 제목: “상태 복원”두 시리즈는 독립적인 디스크 복사본을 사용한 격리된 가상 머신에서 수행했으며, 측정 후에는 머신을 초기 상태로 되돌렸습니다. 이 문서는 독자에게 설정 변경을 요구하지 않으므로 사용자 컴퓨터에서 별도로 복원할 필요는 없습니다.
공개된 1차 자료
섹션 제목: “공개된 1차 자료”- Microsoft: Windows Performance Recorder — 방법론에서 사용한 ETW 추적 기록 도구. 확인일 2026-09-20.
- Microsoft: About Event Tracing — ETW 모델 및 손실된 이벤트 확인. 확인일 2026-09-20.
- Microsoft: Windows의 Microsoft Defender 바이러스 백신 — Defender 프로세스 및 서비스. 여기에는
MsMpEng.exe(Task Manager에서 «Antimalware Service Executable»로 표시됨)가 포함됩니다. 확인일 2026-09-20. - Windows 연구 방법 — 증거 수준 및 측정 프로토콜.
- Service Host와 Windows 11 백그라운드 구성 요소 — Windows가 백그라운드 서비스를 프로세스별로 호스팅하는 방식.
- Windows에서 실제로 얼마나 많은 메모리를 확보할 수 있는가 — 동일한 실험의 메모리 상세 분석.
- 데스크톱과 로그인 화면 비교 — 후속 문서: 사용자 세션의 잡음 구성.
변경 기록
섹션 제목: “변경 기록”- 2026-09-20: 최초 게시 — 유휴 상태의 독립적인 두 측정 시리즈, 부팅 후 단계, 인벤토리 및 부하 테스트.
- 2026-09-20: 시리즈별 결과 귀속을 명확히 했습니다(메모리 커밋과 사용 중인 물리 메모리는 2 시리즈에만 해당, 프로세스 수 −49…−56 %). 이해 상충 고지를 표준 문구로 수정했습니다.