윈도우11 pagefile.sys, 삭제 전 가상메모리 확인법

윈도우11 가상메모리를 몇 MB로 설정할지 묻는다면, 먼저 현재 설정과 실제 작업량부터 확인하는 편이 낫다. 같은 32GB PC라도 문서 몇 개를 여는 사람과 가상머신·편집 도구를 함께 쓰는 사람의 메모리 요구량은 다르다. RAM의 일정 배수를 입력하거나 파일을 없애는 방법만으로 두 PC에 맞는 설정을 만들 수는 없다.

페이지 파일은 Windows의 가상메모리 관리에 쓰이는 저장장치의 파일이다. 가상메모리 전체가 이 파일과 같은 뜻은 아니다. 자주 접근하지 않는 수정된 메모리 내용을 저장장치로 내보내 RAM을 다른 작업에 쓰도록 하고, 시스템이 앱에 제공할 메모리의 한도를 넓힌다. Microsoft의 페이지 파일 설명도 이 기능과 오류 분석용 덤프 지원을 함께 다룬다.

‘커밋됨’은 RAM 사용률과 다른 한도를 보여 준다

Ctrl+Shift+Esc → 성능 → 메모리에서 ‘커밋됨’의 두 숫자를 읽는다. 앞의 A는 시스템이 현재 제공하기로 한 메모리 총량이고, 뒤의 B는 제공 가능한 한도다. 이 한도는 물리 RAM과 페이지 파일이 함께 뒷받침한다. 페이지 파일을 없애면 한도는 설치한 RAM보다 조금 작은 수준으로 줄어든다.

여기서 커밋은 앱의 요청에 따라 Windows가 사용할 메모리를 제공하기로 한 상태를 가리킨다. 커밋된 양이 곧 페이지 파일에 기록된 양은 아니며, 전부 현재 RAM에 올라와 있다는 뜻도 아니다. Microsoft의 성능 정보 정의에 따르면 메모리를 커밋하면 집계는 즉시 늘지만, 물리 페이지 사용은 실제 접근 때 발생한다. 그래서 RAM 사용률 그래프와 커밋 비율을 같은 숫자로 읽을 수 없다.

가령 커밋됨이 30/32GB라고 표시되는 상황을 생각할 수 있다. 남은 커밋 여유는 약 2GB다. 이때 새 작업이 4GB를 추가로 요구하고 한도를 확장하지 못하면, RAM 그래프가 가득 차지 않았더라도 메모리를 제공하지 못하는 상황이 생긴다. 이는 원리를 설명하기 위한 가상 숫자이며 특정 PC의 실측이 아니다.

확인 시점도 중요하다. 앱을 모두 닫은 뒤의 숫자는 작업이 몰렸던 순간을 보여 주지 않는다. 문제가 생기는 파일을 열거나 평소 함께 쓰는 프로그램을 실행했을 때 A와 B를 적으면, 작은 수동 상한이 작업을 막고 있는지 판단하기 쉽다. RAM 설치 용량 자체가 기대보다 작게 잡힌 경우는 하드웨어 예약과 사용 가능 메모리 확인의 다른 점검 대상이다.

수십 GB 파일과 수십 GB 사용은 다른 상태다

저장공간 분석에 pagefile.sys가 크게 나온다고 해서 그만큼의 데이터가 계속 쓰이고 있다는 뜻은 아니다. 파일에 배정된 용량과 현재 사용량을 함께 보면 구분할 수 있다. Windows PowerShell에서 다음 명령으로 현재 페이지 파일 정보를 읽는다. 설정을 바꾸거나 파일을 삭제하는 명령은 아니다.

Get-CimInstance Win32_PageFileUsage |
  Select-Object Name, AllocatedBaseSize, CurrentUsage, PeakUsage

Microsoft의 WMI 속성 정의에서 Name은 파일 경로, AllocatedBaseSize는 할당된 디스크 공간, CurrentUsage는 현재 사용량, PeakUsage는 최고 사용량이다. 용량 단위는 MB다. 여러 페이지 파일이 있으면 경로별로 결과가 나오므로 C드라이브 파일만 보고 전체 설정을 판단하지 않는다.

예를 들어 AllocatedBaseSize가 32768이고 CurrentUsage가 2048인 출력은 약 32GB를 배정한 파일에서 현재 약 2GB를 사용한다는 뜻이다. 두 값은 함께 존재할 수 있다. 이 역시 읽는 법을 보여 주는 가상 예시다. CurrentUsage가 지금 작다는 이유만으로 다른 작업 시간에도 필요량이 작았다고 단정하지 않고, PeakUsage와 커밋 한도를 함께 본다.

조회 결과는 현재 Windows에 만들어진 파일의 실행 상태다. 설정 창에서 바꿔 놓은 다음 아직 다시 시작하지 않았다면, 의도한 구성과 현재 값이 같은지도 확인할 필요가 있다. 출력이 없거나 조회 오류가 나면 우선 아래 가상메모리 창에서 드라이브별 설정을 읽는다. 오류를 해결하려고 시스템 파일의 소유권을 바꾸거나 숨김 파일을 강제로 지울 이유는 없다.

꺼 놓은 페이지 파일은 자동 관리로 복원한다

‘페이징 파일 없음’이나 작은 사용자 지정값을 적용한 뒤 문제가 생겼다면, 자동 관리로 되돌리는 것이 비교의 출발점이다. 설정을 바꾸기 전에 열어 둔 문서를 저장하고, 기존 드라이브와 선택값을 기록한다. 회사에서 관리하는 PC는 임의로 정책을 덮어쓰기보다 현재 화면과 오류를 관리자에게 전달한다.

1. 시작 메뉴에서 ‘고급 시스템 설정 보기’를 검색해 시스템 속성을 연다.
2. ‘고급’ 탭의 ‘성능’에서 ‘설정’을 누른다.
3. 성능 옵션의 ‘고급’ 탭에서 ‘가상 메모리 → 변경’을 연다.
4. 맨 위의 ‘모든 드라이브에 대한 페이징 파일 크기 자동 관리’를 선택하고 확인으로 창을 닫는다.
5. 저장한 작업을 확인한 뒤 Windows를 다시 시작한다. 같은 작업을 실행해 커밋됨 A/B와 오류 재현 여부를 비교한다.

드라이브를 직접 정해야 하는 환경이라면 전체 자동 관리와 드라이브별 ‘시스템이 관리하는 크기’ 선택을 구별한다. 후자는 해당 드라이브를 선택하고 ‘시스템이 관리하는 크기 → 설정’으로 적용하는 방식이다. Dell의 페이지 파일 설정 안내도 이 선택과 설정 버튼을 설명한다. 이전에 한 드라이브만 바꿨다면 나머지 목록에도 수동값이 남았는지 함께 읽는다.

복원 뒤에는 파일이 생겼다는 사실보다 원래 실패하던 작업이 어떻게 달라졌는지가 중요하다. 커밋 한도가 늘고 메모리 부족 오류가 사라졌다면 설정에 따른 용량 제한과 연결할 근거가 생긴다. 앱이 계속 같은 지점에서 종료된다면 오류 메시지와 시각을 남긴다. 페이지 파일 설정 하나로 모든 앱 충돌 원인을 설명할 수는 없다.

RAM 32GB에 맞는 고정 입력값은 없다

필요한 페이지 파일 크기는 가장 큰 커밋 요구량과 오류 덤프 설정으로 정한다. Microsoft의 크기 산정 문서는 같은 사양의 PC도 작업에 따라 요구량이 달라 일률적으로 일반화할 수 없다고 설명한다. RAM이 32GB라는 정보만으로 4GB 고정, 48GB 고정, 완전 비활성화 가운데 하나를 고를 근거는 부족하다.

직접 크기를 정해야 한다면 평소 가장 무거운 작업의 커밋량을 먼저 기록한다. 현재 한도와 얼마나 가까운지, 파일이 있는 드라이브에 늘어날 빈 공간이 있는지, 업무 도구가 별도 요구값을 안내하는지를 맞춘다. 메모리 부족을 피하려고 큰 상한을 적어 놓아도 저장장치가 이미 가득 차면 그 공간을 실제로 제공하기 어렵다.

덤프는 프로그램 작업량과 별도로 필요한 조건이다. 블루스크린이 났을 때 메모리 내용을 파일로 남겨 분석하려면, 선택한 덤프 종류를 지원할 페이지 파일 또는 전용 덤프 파일이 필요하다. RAM이 작업에 충분하더라도 이 용도가 남는다. 단지 SSD 공간을 되찾으려고 페이지 파일을 없애면 다음 장애에서 필요한 기록을 남길 조건까지 바뀐다.

따라서 C드라이브 공간이 빠듯한 PC에서는 파일을 끄기 전에 무엇이 공간을 차지하는지부터 나눠 본다. 일반 파일 정리로 빈 공간을 확보할 수 있는지, 페이지 파일을 줄이려는 목적이 단순 공간 확보인지, 특정 앱의 할당 오류를 해결하려는 것인지에 따라 다음 행동이 다르다. 가장 무거운 작업을 보지 않은 채 현재 사용량 하나만으로 영구 상한을 정하지 않는다.

자동 관리에서도 메모리 부족이 계속된다면

자동 관리로 복원했는데 오류가 계속되면, 오류가 난 순간의 커밋량과 앱별 증가를 확인한다. 작업 관리자 ‘세부 정보’에서 열 머리글을 오른쪽 클릭해 열 선택을 열고 ‘커밋 크기’를 표시한다. 기본 프로세스 목록의 메모리 값만 정렬했을 때와 다른 정보를 볼 수 있다.

Microsoft의 메모리 누수 진단 안내는 시스템 로그의 이벤트 2004가 가상메모리 자원 부족과 당시 많이 사용한 프로세스를 보여 준다고 설명한다. ‘이벤트 뷰어 → Windows 로그 → 시스템’에서 오류 시각 주변의 Resource-Exhaustion-Detector 기록을 찾는다. 해당 기록이 있으면 프로세스 이름과 사용량, 발생 시각을 앱의 커밋 변화와 맞춘다.

같은 파일로 작업하는데 특정 앱의 커밋이 계속 올라가고 줄어들지 않는다면, 파일 크기 설정만 반복해서 늘리기보다 그 앱의 동작을 조사할 이유가 있다. 앱을 다시 실행했을 때의 변화와 재현 조건을 남기면 개발사에 전달할 자료가 된다. 메모리를 가장 많이 쓰는 앱이 있다는 사실 하나로 누수라고 확정하지는 않는다.

다른 예외는 페이지 파일이 늘어나는 동안의 지연이다. Microsoft는 Windows 10·11의 빈번한 메모리 할당 작업에서 파일 증가 지연으로 할당 오류가 생기는 사례를 별도로 설명한다. 이 문서는 초기 크기를 수동 지정하는 우회책을 제시한다. 자동 관리가 켜져 있다는 이유로 이런 사례까지 배제해서는 안 된다.

수동값을 시험할 때는 원래 설정, 앱 버전, 같은 작업의 오류 시점과 커밋량을 남기고 한 조건씩 바꾼다. 해당 문서의 초기값 제안은 그 증상의 우회책이다. 모든 32GB PC의 성능을 높이는 공식으로 확대할 내용은 아니다. 이미 설정을 여러 번 바꿨다면 원래 상태로 돌아가는 방법도 함께 기록한다.

파일을 늘려도 SSD가 RAM 속도로 바뀌지는 않는다

커밋 한도가 부족했던 PC는 페이지 파일을 확보해 실패하던 메모리 요청을 처리할 여지가 생긴다. 그러나 저장장치에서 데이터를 다시 읽는 비용까지 사라지는 것은 아니다. 같은 작업을 계속 실행할 수 있게 되는 결과와 앱 전환·편집이 빨라지는 결과는 따로 살핀다.

리소스 모니터의 ‘하드 폴트’도 이름 때문에 오해하기 쉽다. Microsoft의 정의에서 이는 필요한 메모리 페이지를 RAM 대신 디스크에서 가져오는 동작이다. 그 숫자가 생겼다고 RAM 모듈이나 SSD가 고장이라는 뜻은 아니다. 앱을 여는 순간과 느려짐이 지속되는 구간을 구별해 관찰한다.

자동 관리 복원 뒤 오류는 없어졌지만 평소 쓰는 앱을 함께 열 때마다 물리 메모리가 빠듯하고 작업 전환 지연이 반복된다면, 동시에 실행할 작업을 줄이거나 RAM 용량을 늘릴 필요를 검토한다. 페이지 파일은 이런 작업의 RAM 수요 자체를 줄이지 않는다. 반대로 메모리와 커밋에 여유가 있는데 특정 연산만 느리다면 CPU·GPU·저장장치 등 그 작업이 실제로 기다리는 대상을 살펴보는 편이 맞다.