조용한 유휴: 최적화 전후의 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 부하, 물리적 하드웨어 및 장시간 구간(수 시간 및 수 일)은 포함되지 않았습니다.
방법론
섹션 제목: “방법론”프로토콜은 «우리가 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 % |
| 네 스레드 (완전) | +0,19 % | 88,9 / 89,4 % |
| 여덟 스레드 (완전) | +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분 유휴 구간 동안 212 CPU초를 소비했습니다; - 원본 상태에서는 검색 서비스, SysMain 서비스, 텔레메트리, 인쇄 관리자 및 기타 구성 요소가 실행 중이었습니다 — 최적화 프로필은 약 50개의 백그라운드 서비스와 58개의 예약된 작업을 비활성화 상태로 전환합니다;
- 부팅 후에는 Windows 업데이트 오케스트레이터가 활동을 동반합니다.
백그라운드 구성 요소 비활성화가 백그라운드를 완전히 제거하지는 않습니다: 최적화된 상태에서도 애플리케이션 호환성 평가가 계속 실행되었고(유지 관리 구간에서 초당 약 3,7 ms CPU), 안정된 유휴에서 총 잔여 백그라운드는 초당 4,8 ms CPU — 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에 속하지 않습니다. 비교 시점에 시스템이 무엇으로 바쁜지에 따라 가시적 효과가 더 큽니다: 유지 관리 구간에서는 차이가 배수이고, 조용한 구간에서는 적당합니다.
권장 사항: 자신의 컴퓨터에서 모든 변경 이전과 이후의 백그라운드를 평가하십시오(작업 관리자 → «성능» 및 «프로세스», 리소스 모니터). 다른 사람의 백분율에 의존하지 마십시오. 특정 게임의 FPS가 목표라면 변경 이전과 이후에 바로 그것을 측정하십시오.
상태 복원
섹션 제목: “상태 복원”두 시리즈 모두 독립적인 디스크 복사본의 격리된 가상 머신에서 수행되었습니다; 측정 후 머신은 원래 상태로 되돌려졌습니다. 이 문서는 독자에게 매개변수 변경을 요구하지 않으므로 사용자 컴퓨터에서 별도의 복원 작업은 필요하지 않습니다.
공개 기본 출처
섹션 제목: “공개 기본 출처”- Microsoft: Windows Performance Recorder — 방법론에서 사용된 ETW 추적 기록 도구; 2026-09-20 확인.
- Microsoft: About Event Tracing — ETW 모델 및 손실된 이벤트 확인; 2026-09-20 확인.
- Microsoft: Windows의 Microsoft Defender Antivirus — Defender 프로세스 및 서비스, 작업 관리자의
MsMpEng.exe(«Antimalware Service Executable») 포함; 2026-09-20 확인. - 우리가 Windows를 연구하는 방법 — 증거 수준 및 측정 프로토콜.
- Service Host 및 Windows 11 백그라운드 구성 요소 — Windows가 백그라운드 서비스를 프로세스별로 배치하는 방법.
- Windows에서 실제로 얼마나 많은 메모리를 해제할 수 있는가 — 동일한 실험의 메모리 상세 분석.
- 데스크톱 대 로그인 화면 — 후속: 사용자 세션 노이즈의 구성.
변경 이력
섹션 제목: “변경 이력”- 2026-09-20: 최초 게시 — 두 개의 독립적인 유휴 측정 시리즈, 부팅 후 단계, 인벤토리 및 부하 테스트.
- 2026-09-20: 시리즈별 결과 귀속 명확화(commit 및 사용 중인 물리적 메모리 — 시리즈 2만; 프로세스 −49…−56 %); 이해 충돌 면책 조항이 표준 문구로 조정됨.