Windows에서 실제로 확보할 수 있는 메모리 양
목차
간단한 답변
섹션 제목: “간단한 답변”실제로 확보할 수 있는 메모리는 “메모리 최적화 도구”가 약속하는 것보다 적습니다. 이 실험에서 백그라운드 구성 요소를 끄면 사용 가능한 메모리 1,0–1,5 GB가 확보되고 시리즈 2에서 커밋(commit)량이 52 % 줄었습니다. 그러나 널리 쓰이는 빠른 방법들은 작동하지 않습니다. 셸 프로세스 종료 — Windows가 약 20초 만에 스스로 다시 시작합니다. working set 정리 — 내보낸 페이지는 캐시로서 RAM에 그대로 남습니다. 메모리 관리자 레지스트리 매개변수 — 확인된 이점이 없습니다. 이미 최적화된 시스템 위에 적용한 국소적 비활성화는 정직하게 +22–30 MB를 제공했습니다. standby 목록의 메모리는 “사용 가능”에 이미 포함된 캐시입니다.
상태: 최종 수치는 Windows 11 (26H2, build 26300.9457)이 설치된 8 GB RAM 가상 머신에서 얻었습니다. 방향성은 Microsoft 문서와 당사의 통제된 실험으로 확인되었으며, 다른 구성에서의 절대값은 달라질 것입니다.
검증 가능한 주장
섹션 제목: “검증 가능한 주장”우리는 네 가지 주장을 검증했습니다:
- “불필요한” 백그라운드 프로세스를 종료하면 메모리가 확보된다.
- working set 또는 standby 목록 정리(“RAM 최적화 도구”의 메커니즘)는 메모리를 확보한다.
- 메모리 관리자 레지스트리 매개변수는 메모리를 눈에 띄게 확보한다.
- 백그라운드 구성 요소를 끄면 많은 양의 메모리가 확보된다.
연구 범위
섹션 제목: “연구 범위”- Windows 11 Pro, build 26300.9457 (26H2); 가상 머신, 8 GB RAM;
- 동일 설치의 두 가지 상태: 초기(“이전”)와 BoosterX 최적화 프로필 적용 이후 — 측정은 두 개의 독립적인 시리즈로 수행되었습니다(자세한 프로토콜과 나머지 지표는 «조용한 유휴: 최적화 전후의 Windows 백그라운드» 참조);
- “이후” 상태 위에 백그라운드 소스의 국소적 비활성화 패키지(진단용 ETW 자동 로거, 알림 서비스, 섀도 복사, 업데이트 오케스트레이터);
- 지표: 사용 가능 및 사용 중 메모리, 커밋(commit)량, nonpaged/paged pool, 프로세스별 working set과 private bytes, 페이지 오류(hard faults).
포함하지 않음: 물리적 하드웨어, 다른 RAM 용량의 시스템, pagefile 비활성화 실험, 서드파티 “메모리 최적화” 유틸리티.
방법론
섹션 제목: “방법론”- 메모리 인벤토리는 안정된 유휴 상태에서 수집되었습니다: 시스템 카운터(사용 가능, 사용 중, commit, 풀)와 working set 및 private bytes가 포함된 프로세스 목록.
- “셸 프로세스 종료” 통제 실험: 두 개의 인터페이스 프로세스(
SearchHost.exe및StartMenuExperienceHost)를 중지하고 20초와 40초 후 상태를 확인했으며, commit을 이전과 이후에 기록했습니다. - 국소적 비활성화 패키지를 “이후” 상태에 적용한 다음 재부팅하고, 패키지 없이 동일 상태를 네 번 대조 부팅한 것과 비교했습니다. 부팅 테스트는 성능 회귀가 없음을 확인했습니다.
- 측정 계층(추적, 카운터, 수집 스크립트) 자체가 메모리를 차지합니다 — 개별 측정에서 최대 수백 MB 이상의 working set; 이는 제한 사항에 명시되어 있습니다.
백그라운드가 차지하는 양
섹션 제목: “백그라운드가 차지하는 양”유휴 상태의 인벤토리 스냅샷(시리즈 1):
| 이전 | 이후 | 변화 | |
|---|---|---|---|
| 총 working set, MB | 3 841 | 1 868 | −51 % |
| 총 private bytes, MB | 1 524 | 660 | −57 % |
| 사용 가능한 메모리, MB | 5 490 | 6 518 | +1 028 |
시리즈 2: 사용 중 메모리 3 017 → 1 538 MB, 사용 가능 5 174 → 6 653 MB, 커밋량 2 617 → 1 249 MB. 방향은 두 시리즈 모두 일치합니다: 백그라운드 구성 요소가 이 프로필의 사용 중 메모리 절반 정도를 차지하고 있습니다.
사용 중 메모리의 구조
섹션 제목: “사용 중 메모리의 구조”“이후” 상태에서 메모리는 다음과 같이 분배되었습니다(총 working set, 시리즈 1):
- 셸(파일 탐색기, DWM, 시작 메뉴 검색, 세션 호스트) — 약 640 MB;
- 백그라운드 서비스 — 약 640 MB(39개의 호스트 프로세스에 있는 57개 서비스);
- 검색 웹 구성 요소 — 약 320 MB;
- 커널 풀 — 약 167 MB, 그중 약 76 MB는 레지스트리 풀입니다.
프로세스의 working set은 확보되는 메모리와 같지 않습니다: 여기에는 각 프로세스에서 동시에 계산되는 공유 페이지(시스템 라이브러리 코드, 공통 데이터)가 포함됩니다. 시리즈 1의 “이후” 상태에서 75개 프로세스의 working set 합계는 1 868 MB였고 private bytes 합계는 660 MB였습니다. 국소적 비활성화 실험의 대조 부팅에서 총 working set은 2 036 MB였습니다. 가장 큰 인터페이스 프로세스(시리즈 2):
| 프로세스 | Working set, MB | Private, MB |
|---|---|---|
SearchHost.exe (검색) |
187 | 80 |
explorer.exe (파일 탐색기) |
167 | 36 |
StartMenuExperienceHost |
107 | 24 |
dwm.exe (DWM) |
73 | 34 |
“이후” 상태에서 standby 목록은 711 MB였습니다. 이것은 손실된 메모리가 아니라 캐시입니다: standby는 이미 “사용 가능”에 포함되어 있으며, Windows는 애플리케이션이 메모리를 요구할 때 이 페이지들을 즉시 재사용합니다.
실험: 셸 프로세스 종료
섹션 제목: “실험: 셸 프로세스 종료”SearchHost.exe 및 StartMenuExperienceHost 중지 후(시리즈 2):
- 두 프로세스 모두 약 20초 만에 새로운 식별자로 자동 재시작되었습니다. 40초 후에도 여전히 실행 중이었습니다.
- 커밋량은 줄지 않고 12,6 MB 증가했습니다(1 386,9에서 1 399,5 MB로) — 셸 프로세스 재시작 자체가 새로운 작업을 만들어냅니다.
- “사용 가능” 메모리의 단기적 93 MB 증가는 절약이 아닙니다: 대상 프로세스가 돌아왔고 commit이 증가했습니다.
별도 측정에서의 파일 탐색기 종료(시리즈 1) 역시 자유 메모리의 지속적인 증가를 가져오지 않았습니다: 이 구간에서 자유 메모리는 오히려 97 MB 감소했고 standby는 13 MB 증가했습니다 — 내보낸 페이지는 캐시로서 시스템에 남아 있고, 셸과 관련 프로세스는 계속 작동합니다.
실험 결론: 시스템 프로세스를 강제로 종료해도 메모리는 확보되지 않습니다. Windows는 셸 구성 요소를 자동으로 재시작하며, 절약 대신 추가 부하를 얻게 됩니다.
working set 및 standby 목록 정리
섹션 제목: “working set 및 standby 목록 정리”메커니즘은 Microsoft에 문서화되어 있습니다. working set에서 페이지를 내보내는 것(예를 들어 EmptyWorkingSet 함수 또는 “빈” 크기의 SetProcessWorkingSetSize — 바로 이것들이 “RAM 최적화 도구”에서 사용됩니다)은 페이지를 과도 상태로 전환합니다: 다시 필요해지거나 재사용될 때까지 RAM에 캐시된 상태로 남습니다. 프로세스가 해당 페이지에 다음으로 접근하면 소프트 페이지 오류가 발생하고 working set으로 복귀합니다.
따라서 working set 정리는 카운터의 “자유” 수치를 바꾸지만 물리적으로 사용 가능한 메모리를 만들어내지는 않습니다: 페이지는 어디로도 사라지지 않고, 다시 접근하는 비용이 더 비싸집니다. standby 목록 정리도 같은 이유로 무의미합니다: standby는 이미 시스템이 사용할 수 있는 메모리입니다. 우리 측정에서 메모리 pressure는 두 상태 모두에서 없었으므로(hard faults는 낮게 유지됨) 추가 내보내기는 아무것도 개선하지 못했습니다.
이 실험에서 얻은 우리의 기준: “메모리 확보”의 결과는 “자유” 행의 단기적 증가가 아니라 commit, 페이지 오류, 메모리 재사용 시의 지연으로 평가해야 합니다.
국소적 비활성화: 정직한 증가분
섹션 제목: “국소적 비활성화: 정직한 증가분”“이후” 상태 위에 우리는 아홉 개의 진단용 ETW 자동 로거와 네 개의 백그라운드 서비스(알림, 섀도 복사, 업데이트 오케스트레이터)를 비활성화하고 결과를 네 번의 대조 부팅과 비교했습니다:
| 지표 | 대조 부팅 | 패키지 적용 | 차이 |
|---|---|---|---|
| 자유 메모리, MB | 6 664–6 674 | 6 696 | +22…+30 |
| Nonpaged pool, MB | 69,8–71,8 | 58,7 | −11…−13 |
| 총 working set, MB | 2 036 | 1 959 | −77 |
| 테스트 성능 | 변화 없음 | 변화 없음 | — |
자동 로거만이 −13,2 MB의 nonpaged pool을 제공했습니다(별도로 측정). 중요: 인벤토리에 따르면 비활성화된 구성 요소의 working set 합계는 약 78 MB였지만 실제 자유 메모리 증가분은 +22–30 MB였습니다. 차이는 “비활성화된” 것의 일부가 애초에 실행되지 않았기 때문에 발생합니다. 이것이 시스템 구성 요소를 삭제하지 않는 국소적 비활성화의 정직한 한계입니다. 부수적으로 동일 패키지는 유휴 백그라운드 활동을 추가로 24 % 줄였습니다.
메모리 관리자 레지스트리 매개변수(풀 크기, 시스템 캐시 등)는 이 실험에서 이득의 원천으로조차 고려되지 않았습니다: 그것들의 검토와 실질적 유용성은 «Memory Manager와 시스템 cache»에서 다루어졌습니다 — RAM 확보에 대한 확인된 이점은 없습니다.
확인된 것
섹션 제목: “확인된 것”- 재현됨(두 시리즈): 백그라운드 구성 요소 비활성화는 사용 가능한 메모리 1,0–1,5 GB를 확보합니다. 총 working set은 51 % 감소했고(시리즈 1), 사용 중 메모리는 49 %, 커밋(commit)량은 52 % 감소했습니다(시리즈 2).
- 측정됨: 중지된 셸 프로세스가 20초 이내에 자동 재시작됩니다. 이때 commit은 줄지 않습니다(우리 실험에서는 12,6 MB 증가).
- 측정됨: 파일 탐색기 종료는 자유 메모리의 지속적인 증가를 가져오지 않습니다. 내보낸 페이지는 standby에 남습니다.
- 문서화됨: working set에서 페이지를 내보내면 RAM에 캐시된 과도 상태로 전환됩니다. standby 메모리는 사용 가능에 포함됩니다.
- 측정됨: 최적화된 시스템 위의 국소적 비활성화는 성능 변화 없이 자유 메모리 +22–30 MB를 제공합니다. 비활성화된 것의 working set 합계는 자유 메모리 증가분과 같지 않습니다.
확인되지 않은 것
섹션 제목: “확인되지 않은 것”- 서드파티 “RAM 최적화 도구”는 직접 테스트되지 않았습니다: 그것들이 기반으로 하는 메커니즘(working set 정리)이 검증되었습니다.
- pagefile 비활성화는 측정되지 않았습니다. pagefile이 crash dump와 메모리 커밋 한도에 필요하다는 것만 알려져 있습니다.
- 다른 RAM 용량, 다른 빌드, 물리적 하드웨어를 가진 머신으로의 수치 이전.
- 긴 구간에서의 절약 지속성: 측정은 안정된 유휴 상태에서 수행되었습니다.
제한 사항
섹션 제목: “제한 사항”- 8 GB RAM 가상 머신: 절대 수치는 이 구성에 묶여 있습니다. 백그라운드 구성 요소가 많은 프로필은 더 많이 확보하고, “조용한” 시스템은 더 적게 확보합니다.
- 프로세스별 working set 합계는 공유 페이지 때문에 고유한 흔적을 과대평가합니다. 그래서 우리는 private bytes를 함께 제시합니다.
- 측정 계층 자체가 상당한 메모리를 차지했습니다(개별 측정에서 최대 수백 MB의 working set) — 상태 수치에는 측정의 존재가 포함됩니다.
- 실험에서 메모리 압박은 없었으므로(hard faults 낮음) 절약이 RAM 부족 상황에서 스래싱을 줄이는지는 확인하지 않았습니다.
- 확보의 일부는 Microsoft Defender 보호 구성 요소 비활성화와 관련됩니다 — 이것은 보안과의 타협이며, 공짜로 얻은 메모리가 아닙니다.
연구와 사용된 도구는 BoosterX 개발자에게 속하며, BoosterX는 Windows 최적화 도구이므로 최적화 효과의 측정은 그의 직접적인 이해관계입니다. 방법론과 적용 범위는 위에 설명되어 있으며, 결론은 공개 데이터와 나열된 공개 출처로 검증할 수 있습니다. 인기 있는 “메모리 확보” 방법에 대한 부정적 결과는 긍정적 결과와 동등하게 공개되었습니다.
실용적 결론
섹션 제목: “실용적 결론”이 실험에 따르면 실제로 메모리를 확보하는 것:
- 사용하지 않는 애플리케이션 닫기 — private bytes가 전부 확보됩니다;
- 정말로 불필요한 백그라운드 구성 요소 비활성화 — 측정된 총체적 효과는 «조용한 유휴»에 설명되어 있습니다. 이것은 검증된 방법 중 기가바이트를 제공한 유일한 방법이며, 그 대가는 해당 기능의 상실입니다;
- 결과를 “자유” 행이 아니라 commit과 사용 가능한 메모리로 평가하기(작업 관리자 → “성능” → “메모리”).
작동하지 않는 것:
- 시스템 프로세스 강제 종료: Windows가 몇 초 만에 다시 시작하고 commit이 증가합니다;
- “RAM 최적화 도구”와 standby 정리: 내보낸 페이지는 캐시로서 RAM에 남아 있고, 다시 작동시키는 데는 소프트 페이지 오류가 듭니다;
- 메모리 관리자 레지스트리 매개변수.
Standby 메모리는 문제가 아니라 캐시의 작동입니다: “사용 가능”에 이미 포함되어 있습니다. Pagefile은 시스템 관리하에 두십시오: 메모리 커밋 한도와 충돌 덤프에 필요합니다.
상태 복원
섹션 제목: “상태 복원”실험은 테스트 상태 분기에서 격리된 가상 머신으로 수행되었습니다. 측정 후 테스트 분기는 초기화되었고 머신은 초기 상태로 되돌려졌습니다. 이 문서는 시스템 프로세스를 종료하거나 pagefile을 비활성화할 것을 권장하지 않으므로, 사용자 컴퓨터에서 별도의 복원 작업은 필요하지 않습니다.
공개 1차 출처
섹션 제목: “공개 1차 출처”- Microsoft: Working Set — working set의 구성, 페이지 내보내기, RAM에 캐시되는 과도 페이지,
EmptyWorkingSet/SetProcessWorkingSetSize함수; 2026-09-20 확인. - Microsoft: EmptyWorkingSet — “메모리 최적화” 유틸리티에서 사용하는 API; 2026-09-20 확인.
- Microsoft: About Memory Management — 가상 메모리와 공유 페이지 모델; 2026-09-20 확인.
- Microsoft: Introduction to the page file — commit charge, 커밋 한도, pagefile의 역할; 2026-09-20 확인.
- Memory Manager와 시스템 cache — 메모리 관리자 레지스트리 매개변수 연구.
- 조용한 유휴: 최적화 전후의 Windows 백그라운드 — 측정 프로토콜과 동일 실험의 나머지 지표.
- 우리가 Windows를 연구하는 방법 — 증거 수준과 측정 규칙.
변경 이력
섹션 제목: “변경 이력”- 2026-09-20: 수치를 시리즈 표에 맞게 조정했습니다: 시리즈 1의 “이후” — 1 868/660 MB, 지표와 시리즈별 백분율 귀속을 명확히 했습니다; 이해충돌 면책 조항을 완전한 문구로 강화했습니다.
- 2026-09-20: 최초 게시 — 두 시리즈의 메모리 인벤토리, 프로세스 종료와 정리에 대한 부정적 실험, 국소적 비활성화의 정직한 증가분.