Windows 11 작업 관리자를 열었는데
메모리 사용률이 70~90%까지 올라가 있는 경우가 있습니다.
그래서 메모리 사용량 순으로 정렬해
Chrome 1GB, 게임 2GB, 기타 프로그램을 전부 더해봤는데
전체 RAM 사용량과 몇 GB씩 차이가 나는 경우가 있습니다.
이 차이는 작업 관리자가 틀린 것이 아닐 가능성이 높습니다.
프로세스 목록에서 보이는 메모리와
Windows 전체가 사용 중인 물리 RAM은
측정 범위 자체가 다릅니다.
따라서 프로그램을 하나씩 종료하면서
숫자를 억지로 맞추기보다
Windows가 빠진 RAM을 어디에 사용하고 있는지
찾아야 합니다.
Baroit 진단 기준: 80%라는 숫자부터 보지 않습니다
메모리가 80%라는 숫자 하나만으로
문제가 있다고 판단하면 안 됩니다.
먼저 작업 관리자에서:
Ctrl + Shift + Esc
→ 성능
→ 메모리
를 열고 아래 값을 확인합니다.
| 항목 |
진단에서 보는 이유 |
| 사용 중 |
현재 실제 RAM 사용 규모 |
| 사용 가능 |
필요하면 즉시 다른 프로그램이 사용할 수 있는 메모리 |
| 커밋됨 |
시스템이 약속한 가상 메모리 양과 한도 |
| 캐시됨 |
파일·데이터 재사용을 위한 캐시 |
| 페이징 풀 |
커널·드라이버의 pageable 메모리 |
| 비페이징 풀 |
RAM에 계속 남아 있어야 하는 커널·드라이버 메모리 |
Baroit 메모리 1차 분기
메모리 80% + 사용 가능 메모리가 충분함
즉시 메모리 누수라고 판단하지 않음
메모리 80~95% + 사용 가능 메모리가 매우 적음
실제 Memory Pressure 조사
프로그램 합계가 적고 비페이징 풀이 큼
드라이버·커널 메모리 조사
프로그램 합계가 적고 Cached/Mapped File 계열이 큼
파일 캐시 쪽 조사
Committed가 Limit에 가까움
RAM뿐 아니라 Commit/Pagefile 문제 조사
왜 프로그램을 전부 더해도 전체 RAM과 숫자가 안 맞을까?
작업 관리자 프로세스 탭에서 보이는
Memory 값은 시스템 전체 RAM 사용량을
항목별로 나눈 회계 장부가 아닙니다.
Windows에는 프로그램 이외에도
여러 종류의 물리 메모리 사용처가 있습니다.
프로세스의 Private Working Set
여러 프로세스가 공유하는 메모리
파일 캐시와 Memory-mapped File
Windows Kernel
Paged Pool
Nonpaged Pool
Kernel Stack
Page Table
장치 드라이버가 잠근 물리 메모리
Microsoft의 Windows Performance 자료에서도
프로세스 Working Set만으로는
프로세스가 시스템 전체 메모리에 주는 실제 영향을
모두 보여주지 못한다고 설명합니다.
따라서 이런 계산은 정확하지 않습니다.
작업 관리자 프로그램 메모리 전부 더하기
= 전체 메모리 사용량
이 식 자체가 성립하지 않습니다.
첫 번째 판정값은 '사용 가능' 메모리입니다
Windows에서 Free와 Available은 같은 의미가 아닙니다.
Microsoft의 메모리 API 문서에 따르면
PhysicalAvailable은
즉시 재사용 가능한 메모리이며:
Standby List
+ Free List
+ Zero List
의 합으로 구성됩니다.
즉 캐시로 보이는 RAM 중 일부는
다른 프로그램이 필요로 하면
빠르게 재사용될 수 있습니다.
그래서 'Free RAM이 적다 = RAM 부족'이라는 판단도 정확하지 않습니다.
Windows는 사용하지 않는 RAM을
파일 캐시 등에 활용할 수 있습니다.
실제로 중요한 것은
사용 가능 메모리가 계속 줄어들면서
시스템이 느려지는지입니다.
몇 GB 남으면 진짜 부족한 걸까?
개인용 Windows PC에 모든 환경을 통틀어 적용할
절대적인 숫자는 없습니다.
다만 Microsoft의 Windows 성능 문제 해결 가이드에서는
Available MBytes의 실무 참고 기준으로:
| Available Memory |
Microsoft 성능 가이드 참고선 |
| 10% 이상 또는 최소 4GB |
Healthy 범위 |
| 10% 미만 |
Warning 범위 |
| 1% 미만 또는 500MB 미만 |
Critical 범위 |
이 기준은 Microsoft의 서버 성능 Troubleshooting 자료에서 제시하는
진단 참고선입니다.
가정용 Windows 11 PC에서
500MB가 되면 무조건 고장이라는 뜻은 아닙니다.
하지만 Available이 지속적으로 매우 낮아지고
페이지 파일 사용·프리징까지 증가한다면
실제 메모리 압박으로 볼 근거가 강해집니다.
Baroit 판정 ① 사용 가능 메모리가 충분하다
예를 들어 32GB RAM에서:
사용 중 24 GB
사용 가능 7.3 GB
사용률 약 75%
라고 가정해보겠습니다.
75%라는 숫자만 보면 높아 보이지만
7GB 이상을 여전히 사용할 수 있고
PC도 정상적으로 반응한다면
급하게 프로그램을 종료할 이유는 없습니다.
이 경우에는
메모리를 누가 사용하는지 확인하는 단계이지
바로 메모리 부족으로 판정할 단계가 아닙니다.
Baroit 판정 ② 사용 가능 메모리가 계속 500MB 근처까지 내려간다
반대로:
총 RAM 16 GB
사용 중 15.2 GB
사용 가능 400 MB
수준이 장시간 지속되면서:
프로그램 전환이 느림
게임이 순간적으로 끊김
브라우저 탭이 자주 다시 로딩됨
SSD 사용률이 같이 치솟음
Out of Memory 오류 발생
등이 나타난다면
실제 메모리 사용처를 찾아야 합니다.
여기서부터 Microsoft RAMMap을 사용합니다
RAMMap은 Microsoft Sysinternals에서 제공하는
Windows 물리 메모리 분석 프로그램입니다.
Microsoft 공식 설명에 따르면 RAMMap은:
Windows가 실제 RAM을 어떻게 할당하는지
파일 데이터가 RAM에 얼마나 캐시돼 있는지
Kernel과 Device Driver가 얼마나 RAM을 사용하는지
프로세스 Working Set이 얼마나 되는지
등을 볼 수 있습니다.
2026년 3월 기준 버전은
RAMMap v1.63입니다.
노트북 메인보드에 장착된 DDR4 SO-DIMM /
출처:
Wikimedia Commons
/
저작자: Diego Torres Silvestre /
CC BY 2.0
RAMMap에서 숫자를 이렇게 읽으면 됩니다
RAMMap을 실행한 뒤
가장 먼저 Use Counts 탭을 봅니다.
여기에서는 RAM을
“누가 사용하는가”와
“현재 어떤 상태인가”로 나눠 볼 수 있습니다.
| RAMMap 항목 |
의미 |
크다면 다음에 볼 곳 |
| Process Private |
프로세스 전용 메모리 |
Processes |
| Mapped File |
메모리에 매핑된 파일 데이터 |
File Summary |
| Metafile |
NTFS 파일 시스템 메타데이터 캐시 |
파일 작업 패턴 |
| Paged Pool |
디스크로 Paging 가능한 Kernel Pool |
Driver 조사 |
| Nonpaged Pool |
RAM에 계속 남아야 하는 Kernel Pool |
Driver Leak 조사 |
| Driver Locked |
드라이버가 물리 RAM에 잠근 페이지 |
가상화·장치 드라이버 |
| Page Table |
가상 주소와 물리 주소 매핑 구조 |
프로세스·매핑 사용량 |
이렇게 보면
“사라진 8GB”가 더 이상 사라진 RAM이 아닙니다.
Process Private가 아니라
Mapped File이나 Nonpaged Pool 같은 다른 항목에 있을 수 있습니다.
Baroit 핵심: Total만 보지 말고 Active를 같이 봅니다
RAMMap에서 특히 중요한 차이가 있습니다.
예를 들어 Mapped File이
총 8GB라고 표시돼도
8GB 전체가 현재 꼭 필요한 Active RAM이라고
단정하면 안 됩니다.
RAMMap에는:
Active
Standby
Modified
Zeroed
Free
같은 메모리 Page 상태가 따로 표시됩니다.
예:
Mapped File Total = 8GB
Active = 1GB
Standby = 7GB
라면
“파일이 RAM 8GB를 먹고 있어서 8GB 모두 못 쓴다”와는
해석이 다릅니다.
Standby 메모리는 필요할 경우
재사용 가능한 영역에 포함될 수 있습니다.
이게 일반적인 '캐시 삭제하세요' 글과 다른 부분입니다
인터넷에서는 RAM 사용량이 높으면
Standby Memory를 무조건 비우라고 하는 경우가 있습니다.
하지만 캐시는 Windows가
느린 저장장치에서 다시 읽는 일을 줄이기 위해
RAM을 활용하는 정상적인 메모리 관리 방식입니다.
따라서:
Cached가 큼
+ Available도 충분함
+ PC 정상
→ 캐시가 크다는 이유만으로 문제라고 판단하지 않음
이게 첫 번째 중요한 오진 방지 기준입니다.
Mapped File이 비정상적으로 Active 상태로 계속 커지는 경우
반대로 Available 메모리가 부족하면서
RAMMap에서 Mapped File의
Active 값이 매우 큰 경우는 조사 가치가 있습니다.
Microsoft는 시스템 파일 캐시 문제 진단에서도
RAMMap Use Counts의
Active Mapped File을 확인하도록 안내합니다.
이 경우 File Summary 탭에서
어떤 파일이 실제 RAM을 많이 사용 중인지
추가로 확인할 수 있습니다.
Baroit RAMMap 결과 분기
Process Private가 가장 큼
→ 특정 프로그램 조사
Mapped File Active가 큼
→ File Summary 확인
Standby만 매우 큼 + Available 정상
→ 누수로 단정하지 않음
Nonpaged Pool이 크고 계속 증가
→ Driver Memory Leak 의심
Driver Locked가 비정상적으로 큼
→ 가상화·스토리지·장치 드라이버 조사
가장 중요한 케이스: Nonpaged Pool이 계속 증가할 때
비페이징 풀은
일반 프로그램 메모리와 성격이 다릅니다.
Microsoft 문서에서 Nonpaged Pool은
페이지 파일로 내보낼 수 없는 Kernel Memory로 설명됩니다.
주로 운영체제와 장치 드라이버가 사용합니다.
여기서 중요한 것은
현재 숫자 하나보다 추세입니다.
PC 부팅 직후 Nonpaged Pool = 600MB
↓
2시간 후 = 1.2GB
↓
6시간 후 = 3.8GB
↓
프로그램을 모두 종료해도 감소하지 않음
같은 패턴이라면
일반 프로그램보다
Kernel Driver 쪽 Memory Leak을 조사할 가치가 높아집니다.
그래서 재부팅하면 잠깐 정상으로 돌아오는 경우가 있습니다
Driver Memory Leak이라면
컴퓨터를 다시 시작하면서
커널 메모리 할당이 초기화돼
사용량이 크게 낮아질 수 있습니다.
하지만 몇 시간 또는 며칠 사용하면
똑같이 Nonpaged Pool이 커질 수 있습니다.
재부팅해서 20%로 내려갔다고 해결된 것이 아닐 수 있습니다.
부팅 직후 값과
문제가 다시 발생했을 때의 값을 비교해야 합니다.
어떤 드라이버인지 찾는 단계는 PoolMon입니다
여기부터는 일반적인 메모리 정리 글에서 거의 다루지 않는 영역입니다.
Microsoft는 Kernel-mode Memory Leak을 조사할 때
PoolMon을 이용해
Pool Tag별 할당량을 확인하도록 안내합니다.
PoolMon은 Windows Driver Kit에 포함되는
고급 진단 도구입니다.
Pool Tag별:
Allocations
Frees
현재 Bytes
Paged / Nonpaged
Tag
를 비교해
계속 증가하는 Driver Pool을 추적할 수 있습니다.
여기부터가 Baroit 자가조치 종료선입니다.
Nonpaged Pool이 몇 GB까지 지속적으로 증가하고,
재부팅하면 초기화됐다가 다시 증가하며,
RAMMap에서도 해당 증가가 확인된다면
무작정 RAM을 추가하기보다
최근 설치한 장치 드라이버·VPN·백신·스토리지·네트워크·가상화 드라이버
등을 조사하는 것이 맞습니다.
프로그램 자체 Memory Leak은 어떻게 구분할까?
반대로 RAMMap에서
Process Private가 대부분을 차지한다면
프로세스 쪽으로 이동합니다.
RAMMap의 Processes 탭이나
작업 관리자 세부 정보에서
특정 프로그램의 메모리 사용량이
시간에 따라 어떻게 변하는지 봅니다.
프로그램 실행 직후 = 500MB
↓
1시간 후 = 1.5GB
↓
3시간 후 = 4GB
↓
작업을 종료해도 메모리 사용량이 거의 감소하지 않음
같은 패턴이 반복된다면
해당 프로그램의 Memory Leak 가능성을 조사합니다.
Microsoft Sysinternals에는
특정 프로세스의 가상·물리 메모리를 세부 분석하는
VMMap이라는 별도 도구도 있습니다.
Committed가 높은데 RAM 사용률은 이상하게 보일 때
또 하나 별도로 봐야 할 항목이
커밋됨(Committed)입니다.
작업 관리자에서는 보통:
Committed
18.5 / 31.7 GB
처럼 표시됩니다.
앞 숫자는 현재 시스템이 Commit한 양,
뒤 숫자는 현재 Commit Limit입니다.
Microsoft 문서에 따르면 Commit Limit은
Page File 크기나 시스템 메모리 구성에 따라 변할 수 있습니다.
Committed가 Limit에 가까워지는 건 RAM 100%와 다른 문제입니다
예를 들어:
RAM 사용률 75%
Committed
30.5 / 31.7 GB
라면 단순히 물리 RAM 사용률만 볼 상황이 아닙니다.
새로운 메모리 Commit을 받을 여유가 거의 없기 때문입니다.
페이지 파일을 인터넷 최적화 글만 보고
사용 안 함으로 설정했다면
Commit Limit이 줄어
메모리 부족 오류가 더 빨리 발생할 수도 있습니다.
Page File은 SSD 속도를 느리게 만드는
쓸모없는 임시파일이 아닙니다.
RAM을 추가해야 하는 상황과 아닌 상황
| 진단 결과 |
RAM 증설 효과 |
| Available이 항상 매우 낮고 정상 프로그램이 대부분 사용 |
높음 |
| 게임·영상편집 등 정상 워크로드가 RAM 대부분 사용 |
높음 |
| Nonpaged Pool Driver Leak |
근본 해결 아님 |
| 특정 앱 Memory Leak |
근본 해결 아님 |
| Standby Cache가 크지만 Available 정상 |
불필요할 수 있음 |
| Page File 비활성화로 Commit Limit 부족 |
먼저 Page File 설정 확인 |
Baroit 5분 진단 절차
메모리 사용처를 찾는 실제 순서
STEP 1
작업 관리자 → 성능 → 메모리
사용 중 / 사용 가능 / Committed / Cached / Paged Pool / Nonpaged Pool 기록
STEP 2
Available이 충분한지 확인
충분하다면 사용률 숫자만 보고 문제 판정하지 않음
STEP 3
Available이 매우 부족하다면 RAMMap 실행
STEP 4
Use Counts에서 큰 Active 사용처 확인
STEP 5
Process Private ↑
→ 프로그램 조사
Mapped File ↑
→ File Summary
Nonpaged Pool ↑
→ Driver 조사
Driver Locked ↑
→ 장치·가상화 Driver 조사
Standby ↑ + Available 정상
→ 즉시 누수라고 판단하지 않음
STEP 6
Committed / Limit도 같이 확인
STEP 7
부팅 직후와 몇 시간 뒤 값을 비교해
증가 추세 확인
이 글에서 가장 중요한 오진 5가지
| 흔한 판단 |
실제 확인해야 할 것 |
| RAM 80% = 무조건 부족 |
Available과 실제 성능 |
| 프로그램 합계가 안 맞음 = 작업 관리자 버그 |
커널·캐시·Pool·Driver 사용량 |
| Cached가 큼 = 캐시를 지워야 함 |
Active/Standby와 Available |
| 재부팅 후 정상 = 해결됨 |
몇 시간 후 다시 증가하는지 |
| RAM 추가하면 모든 문제 해결 |
Memory Leak인지 정상 용량 부족인지 |
서비스·전문 진단으로 넘어갈 기준
다음 조건이 겹친다면
단순 Windows 최적화 단계에서 끝내지 않는 것이 좋습니다.
Nonpaged Pool이 시간에 따라 몇 GB씩 계속 증가
재부팅 후 초기화되지만 다시 같은 패턴 반복
특정 드라이버 설치 이후 발생
RAMMap Driver Locked가 비정상적으로 증가
Committed가 Limit에 반복적으로 접근
메모리 부족과 함께 BSOD·Driver 오류가 발생
이 경우에는
RAM 증설보다 Driver·Kernel Memory Leak 분석이 우선입니다.
결론
작업 관리자에서 메모리가 80%인데
프로그램을 다 더해도 숫자가 안 맞는 것은
그 자체로 오류가 아닙니다.
프로세스 목록은 Windows 전체 물리 RAM의
모든 사용처를 보여주는 화면이 아니기 때문입니다.
Baroit에서는 이런 문제를
사용률 → Available → Commit → Pool → RAMMap Active 사용처
순서로 진단합니다.
특히 가장 중요한 것은
높은 메모리 숫자와 실제 메모리 부족을 구분하는 것입니다.
Standby Cache가 크면서 Available도 충분하다면
Windows의 정상적인 메모리 활용일 수 있습니다.
반대로 Nonpaged Pool이나 특정 Process Private가
시간에 따라 계속 증가한다면
그때부터는 실제 Memory Leak을 조사해야 합니다.
자료 기준
Microsoft Sysinternals -
RAMMap v1.63, 2026년 3월 26일 업데이트
Microsoft Sysinternals -
VMMap
Microsoft Learn -
Memory Performance Information
Microsoft Learn -
PERFORMANCE_INFORMATION 구조
Microsoft Learn -
Process Working Set
Microsoft Windows Performance Team -
Mystery Memory Leak: Where Did My Memory Go?
Microsoft Learn -
PoolMon / Kernel-mode Memory Leak 분석
Microsoft Windows Performance Troubleshooting -
Available MBytes / Committed Memory 참고 기준
Baroit 핵심 판정 기준
프로세스 메모리 합계와 전체 RAM 사용량은 직접 일치하지 않을 수 있음
Available Physical Memory에는 Standby·Free·Zero List가 포함됨
Nonpaged Pool은 Page File로 Paging할 수 없는 Kernel Memory
RAMMap의 Use Counts에서 Process Private, Mapped File, Metafile, Paged Pool, Nonpaged Pool, Driver Locked 등을 구분 가능
Driver Memory Leak은 현재 값 하나보다 시간에 따른 증가 추세가 중요
이미지 1
Wikimedia Commons -
RAM Module (SDRAM-DDR4).jpg
저작자: ElooKoN /
CC BY-SA 4.0
이미지 2
Wikimedia Commons -
Ram-slots.jpg
저작자: Norman Rogers /
Public Domain
이미지 3
Wikimedia Commons -
Crucial CT4G4SFS8213 on laptop motherboard 20171218.jpg
저작자: Diego Torres Silvestre /
CC BY 2.0
이미지 4
Wikimedia Commons -
DDR 4 SO-DIMM RAM slot PNr°0837.jpg
저작자: D-Kuru /
CC BY-SA 4.0
이미지 5
Wikimedia Commons -
Hand holds RAM module above a computer motherboard...jpg
저작자: Shixart1985 /
CC BY 2.0
확인일: 2026년 9월 1일
