SSD 디스크 100%인데 몇 MB/s뿐, 무엇이 PC를 멈추게 할까?

SSD를 단 PC에서도 시작 메뉴나 폴더가 멈추는데 CPU는 한가한 순간이 있다. 이때 작업 관리자의 디스크 숫자가 100%라면, 빠른 SSD로 바꾸는 것보다 지금 무엇을 기다리는지 알아내는 일이 먼저다. 처리할 파일이 몰린 것인지, 한 요청이 끝나지 않아 뒤의 작업까지 기다리는 것인지에 따라 해결 방법이 달라진다.

100%는 바쁜 시간이고, MB/s는 옮긴 데이터양이다

작업 관리자의 성능 → 디스크에 있는 활성 시간은 디스크가 읽기·쓰기 요청을 처리하느라 바쁜 시간의 비율이다. 반면 읽기 속도와 쓰기 속도는 초당 데이터양이다. 탐색기의 남은 공간은 다시 다른 항목이다. 활성 시간 100%만 보고 파일을 지워야 한다고 판단하면 서로 다른 숫자를 섞게 된다.

작은 요청을 여러 번 처리하는 일은 큰 파일 하나를 연속해서 읽는 일과 다르다. 예를 들어 4KiB 요청을 초당 1,000번 처리하면 데이터양은 약 3.9MiB/s다. 이는 단위를 설명하기 위한 계산이며 특정 SSD의 실측 속도가 아니다. 몇 MB/s라는 숫자만으로 디스크가 거의 일하지 않는다고 결론 내릴 수 없는 이유다.

한 요청의 완료가 늦어져도 뒤의 작업이 기다린다. 그러면 전송한 양은 작지만 폴더 열기나 앱 실행은 오래 걸린다. 저장장치 성능을 설명하는 SNIA의 SSD 안내도 초당 요청 수인 IOPS, 초당 데이터양인 처리량, 요청을 완료하는 지연시간을 나눠 설명한다. 제품 상자의 순차 읽기 수치 하나로 이 세 가지를 대신할 수는 없다.

표의 모습은 원인을 확정하는 판정표가 아니다. 같은 100% 화면에서 다음에 볼 자료를 고르는 순서다. 큰 파일 복사 뒤 속도만 떨어지는 문제라면 SSD 복사 속도와 캐시·온도의 관계가 더 직접적인 질문이다.

작업 관리자에서는 멈춘 디스크와 응답시간을 함께 남긴다

Ctrl+Shift+Esc → 성능 → 해당 디스크를 연다. 디스크가 여러 개라면 100%인 장치의 모델명과 드라이브 문자를 먼저 확인한다. 게임은 D:에 있어도 Windows와 임시 파일이 있는 C:가 지연될 수 있다. 한 물리 SSD를 C:와 D:로 나눴다면 두 문자가 같은 장치의 작업을 공유한다.

멈출 때의 활성 시간, 평균 응답시간, 읽기 속도, 쓰기 속도와 시각을 함께 기록한다. 숫자 하나를 캡처하기보다 앱을 누른 직후부터 회복할 때까지 변화를 보는 편이 낫다. 로그인을 막 마쳤을 때만 생기는지, 특정 프로그램을 열 때마다 생기는지, 아무 작업 없이도 반복되는지도 구분된다.

응답시간은 전송 속도와 다른 단위다. 성능 모니터의 Avg. Disk sec/Read가 0.050이라면 요청당 평균 50ms라는 뜻이다. 이 역시 단위 환산 예다. Microsoft의 성능 진단 문서는 지연과 프로세스 활동을 연결해 조사한다. 문서의 서버용 지연 구간을 모든 소비자용 NVMe의 정상·불량 기준으로 옮기기보다, 같은 PC에서 멈추는 순간과 평소의 차이를 비교한다.

System만 보이면 리소스 모니터에서 파일 경로를 찾는다

작업 관리자에서 System이 위에 있다고 해서 종료할 앱이 System이라는 뜻은 아니다. 운영체제를 거치는 저장 작업이 그 이름 아래 보이면, 이름만으로 어떤 프로그램이나 파일에서 시작했는지 알기 어렵다. Win+R에서 resmon을 실행하고 ‘디스크’ 탭을 열면 조사 범위가 좁아진다.

1. ‘디스크 작업이 있는 프로세스’에서 합계 전송량과 프로세스 이름을 본다.
2. 후보의 체크박스를 선택해 아래 디스크 작업 목록을 좁힌다.
3. 파일 열에서 드라이브 문자와 경로를 확인하고, 읽기·쓰기와 응답시간을 함께 본다.
4. PC가 멈춘 순간에도 같은 파일이 반복되는지, 앱 동작과 맞물리는지 기록한다.

게임 설치 폴더라면 설치·압축 해제 진행 상황을, 동기화 폴더라면 해당 앱의 동기화 상태를 함께 확인한다. 파일명은 다음에 확인할 프로그램을 가리키는 단서다. 경로에 특정 회사 이름이 있다는 이유만으로 그 프로그램의 결함을 확정하지는 않는다. 한 앱이 쓴 파일을 다른 작업이 다시 읽는 상황도 있기 때문이다.

Citrix의 Windows 성능 관찰 안내도 작업 관리자의 빠른 확인 뒤 리소스 모니터의 큐·응답시간과 프로세스별 자료로 내려간다. 큐는 대기 중인 작업을 살피는 데 유용하지만, 동시 처리가 가능한 SSD에서 큐가 1을 넘었다는 이유만으로 고장이라고 판정할 수는 없다. 기다림이 길어지는 시각과 실제 앱의 멈춤이 맞는지가 중요하다.

하드 폴트는 고장 횟수가 아니라 디스크에서 페이지를 읽는 동작이다

앱을 여러 개 켠 뒤부터 지연된다면 리소스 모니터의 메모리 탭도 함께 본다. 하드 폴트는 필요한 메모리 페이지를 디스크에서 가져오는 동작이다. Microsoft의 하드 폴트 정의에서 말하는 ‘hard’는 SSD나 RAM의 물리적 고장을 뜻하지 않는다.

앱을 처음 실행하며 파일을 읽는 때와 메모리가 부족해 여러 앱을 오갈 때는 관찰 맥락이 다르다. 하드 폴트 수치가 한 번 높았다는 사실보다, 사용 가능 메모리가 줄고 디스크 활동과 앱 전환 지연이 함께 이어지는지를 본다. 페이지 파일 경로가 보이는지도 보조 단서다. 하드 폴트 횟수만으로 RAM 구매 용량을 정할 수는 없다.

열어 둔 작업을 저장한 뒤 메모리를 많이 쓰는 앱 하나를 닫고, 멈췄던 폴더나 프로그램을 다시 연다. 동시에 유지하는 앱을 줄였을 때만 지연이 줄어든다면 메모리 사용량을 좁혀 볼 이유가 생긴다. 반대로 메모리에 여유가 있고 앱을 닫아도 같은 저장장치 오류가 반복되면 RAM 부족만으로 설명하기 어렵다.

디스크 활동을 없애려고 페이지 파일부터 끄는 방법은 이 비교를 대신하지 못한다. 파일 활동이 줄었다고 메모리 부족이 해결된 것도 아니다. 현재 자동 관리 설정을 유지한 채 어떤 작업을 함께 실행했을 때 문제가 생기는지부터 확인하면, 저장장치 교체와 RAM 증설을 같은 처방으로 취급하는 일을 줄인다.

검색과 동기화는 확인된 작업 범위부터 줄인다

리소스 모니터에서 특정 앱의 파일 활동을 찾았다면 그 앱의 진행 상태와 연결한다. 동기화 앱은 앱 메뉴의 일시 중지를, 게임 런처는 다운로드·설치의 일시 중지를 이용해 비교한다. 동작 하나만 멈춘 뒤 같은 폴더를 다시 열면 어느 작업이 체감 지연에 영향을 주는지 알기 쉽다. 업데이트를 설치하는 도중이라면 진행 상태와 재시작 요구를 확인하고 완료 후 다시 비교한다.

검색 인덱스 작업이 확인됐다면 검색 대상에 들어간 파일 수와 폴더를 살핀다. Windows는 변경된 파일을 읽어 검색 목록을 갱신한다. Microsoft의 검색 인덱싱 안내에서 클래식과 확장 모드는 검색 범위와 자원 사용이 다르다. 검색할 필요가 없는 대규모 작업 폴더가 포함돼 있다면 서비스 전체를 없애는 것보다 그 범위를 조정할 이유가 있다.

설정의 개인 정보 및 보안 → 검색에서 검색 위치를 확인한다. Windows 버전에 따라 ‘Windows 검색’으로 표시되기도 한다. Microsoft의 인덱서 성능 문서는 제외 폴더와 고급 인덱싱 옵션의 ‘수정’을 통한 범위 조정을 설명한다. 제외한 폴더는 인덱스 기반 검색 범위에서 빠지므로, 업무 문서를 찾는 데 필요한 위치까지 없애지는 않는다.

특정 앱을 찾지 못했고 로그인 때마다 반복된다면 Microsoft의 클린 부팅 절차로 타사 시작 프로그램과 서비스의 영향을 비교할 수 있다. 시스템 구성의 서비스 탭에서 Microsoft 서비스를 숨긴 뒤 나머지를 진단 대상으로 삼고, 시작 앱에서 끈 항목도 기록한다. 비교가 끝나면 항목을 다시 켜며 원인을 좁히고 평소 시작 상태로 돌린다. 여러 서비스를 한꺼번에 영구 해제한 상태는 원인을 찾은 결과가 아니다.

전송이 거의 없는데 멈추면 같은 시각의 129·153을 본다

작업을 줄여도 PC가 통째로 멎고 한참 뒤 회복된다면 이벤트 뷰어 → Windows 로그 → 시스템에서 멈춘 시각을 찾는다. 전체 기록의 경고 수를 세기보다 같은 시각에 같은 저장 경로의 문제가 반복되는지를 본다. 이벤트 원본, 번호, 본문의 디스크 번호를 함께 남기면 제조사에 전달할 자료가 된다.

Microsoft의 저장장치 오류 문서는 129·153을 요청 시간 초과와 연결해 설명한다. 번호가 나왔다는 이유로 SSD의 NAND 고장만 확정할 수는 없다. 반대로 재시도가 반복되는데 건강 상태 한 줄만 정상이라고 원인을 지울 수도 없다.

이 단계에서는 중요한 파일을 다른 장치에 백업하고, SSD 모델·펌웨어와 PC의 저장 컨트롤러 정보를 확인한다. 제조사 진단 도구와 해당 모델의 지원 문서에서 알려진 문제·업데이트 대상을 맞춘다. SATA 연결 제품은 케이블과 전원 연결도 점검 범위다. 전원을 끈 상태에서 연결을 점검하거나 수리를 맡기며, BIOS의 저장 모드나 레지스트리 시간 초과 값을 임의로 바꾸어 오류만 숨기지 않는다.

건강 상태 100%와 현재 응답 지연은 다른 질문이다

건강 프로그램의 남은 수명이나 사용 비율은 지금 폴더를 여는 데 얼마나 기다렸는지를 직접 보여 주지 않는다. 내구도 항목이 좋아도 특정 작업의 지연 원인은 별도로 남는다. 어떤 수치가 교체 판단에 쓰이는지는 NVMe SSD 건강 수치와 TBW 해석으로 이어 볼 수 있다.

Windows에 중요한 저장장치 경고가 표시되면 해당 드라이브의 속성을 연다. Microsoft의 저장장치 경고 안내는 예비 용량 부족, 신뢰성 저하, 읽기 전용 전환을 구분한다. Windows 11의 위치는 설정 → 시스템 → 저장소 → 고급 저장소 설정 → 디스크 및 볼륨 → 해당 디스크 속성이다.

이 내장 건강 감시의 대상은 NVMe SSD이며 SATA SSD와 HDD는 제외된다. 따라서 SATA 제품에서 해당 경고가 없다는 사실을 정상 판정으로 쓰면 안 된다. 반대로 신뢰성 저하나 읽기 전용 경고가 실제로 있다면 속도 벤치마크를 반복하기보다 파일 백업과 제조사 점검이 먼저다. 100% 그래프와 중요 경고는 서로 다른 증거다.

같은 작업이 다시 잘 열리는지까지 확인한다

진단 뒤에는 문제가 생겼던 동작을 다시 한다. 같은 앱과 파일을 열고, 활성 시간뿐 아니라 응답시간·멈춤·오류 기록이 함께 달라졌는지 본다. 다운로드를 일시 중지한 동안만 빨라졌다면 해당 부하가 영향을 준 관찰이다. 그 한 번으로 SSD 전체가 정상이라고 확정하거나, 반대로 다운로드 앱 자체가 고장이라고 결론 낼 수는 없다.

재시작 직후에는 나아졌다가 같은 작업을 반복하면 다시 느려지는지도 구분한다. 모든 앱을 닫은 상태의 낮은 디스크 숫자보다 평소 업무를 다시 했을 때 기다림이 돌아오는지가 중요하다. 한 번에 바꾼 설정이 적을수록 어떤 조치가 영향을 줬는지 설명하기 쉽다.

기본 도구로 파일을 좁히지 못했다면 Microsoft Sysinternals의 Process Monitor가 더 깊은 파일 작업 추적에 쓰인다. 이 경우에도 관심 프로세스나 경로로 범위를 좁히고, 증상을 짧게 기록한 뒤 수집을 멈춘다. 일상적인 확인에는 먼저 작업 관리자와 리소스 모니터가 남긴 시각·프로세스·파일·응답시간을 활용하면 된다.

특정 작업을 줄일 때 회복되면 그 작업의 범위와 동시 실행량을 조정한다. 활동이 적어도 리셋·재시도가 반복되면 저장장치 경로를 점검한다. SSD 교체 여부는 이렇게 찾은 증상과 오류·건강 자료를 모아 결정할 문제다. 활성 시간 100%라는 숫자 하나에 서비스 해제, RAM 증설, SSD 교체를 모두 맡길 수는 없다.