이 글의 목적은 NVMe 드라이버를 교체한 뒤 읽기·쓰기 속도, 랜덤 성능, 지연시간이 갑자기 나빠지는 문제를 원인별로 진단하고, 안전하게 정상 성능으로 복구하는 절차를 실무 관점에서 정리하는 것이다.
1. 문제를 정확히 “성능 저하”로 확정하는 방법
드라이버 문제는 체감만으로 판단하면 오진이 많으므로, 교체 전후의 측정 조건을 통일해 수치로 확인하는 것이 우선이다.
1-1. 측정 전 체크리스트
- 노트북은 반드시 전원 어댑터 연결 상태로 측정하는 것이 원칙이다.
- Windows 전원 모드는 “최고 성능” 또는 “고성능”에 맞추는 것이 원칙이다.
- 백신 실시간 감시, 클라우드 동기화, 대용량 다운로드 등 디스크 점유 작업을 중지하는 것이 원칙이다.
- 측정 툴의 테스트 파일 크기와 반복 횟수를 동일하게 맞추는 것이 원칙이다.
1-2. 빠른 상태 점검 명령어
powercfg /getactivescheme winsat disk -drive c fsutil behavior query DisableDeleteNotify
TRIM 상태는 DisableDeleteNotify 값이 0이면 활성 상태이다.
주의 : 드라이버를 여러 번 바꾸는 과정에서 부팅 불가, BitLocker 복구키 요구, 저장장치 접근 오류가 발생할 수 있다. 작업 전 시스템 복원 지점 생성과 BitLocker 복구키 확보가 필수이다.
2. NVMe 드라이버 교체 후 성능이 떨어지는 대표 원인 10가지
NVMe는 “드라이버 이름”만으로 성능이 결정되지 않으며, 전원 정책, PCIe 링크 상태, 쓰기 캐시, 펌웨어, 슬롯 대역폭, 스로틀링, 보안 기능이 함께 영향을 준다.
| 증상 | 가능 원인 | 핵심 확인 지점 | 우선 조치 |
| 순차 읽기/쓰기 모두 하락하다. | PCIe 링크가 x4에서 x2/x1로 떨어지다. | 메인보드 M.2 슬롯 공유, BIOS 설정, 장착 위치이다. | 다른 M.2 슬롯 이동 또는 공유 포트 비활성화이다. |
| 랜덤 4K QD1 지연이 커지다. | 전원 관리(APST/ASPM)로 지연이 증가하다. | 전원 모드, PCIe 링크 상태 전원 관리이다. | 고성능 전원 설정, 링크 상태 전원 관리 끄기이다. |
| 쓰기만 급격히 느려지다. | 쓰기 캐시 비활성, SLC 캐시 소진, 백그라운드 작업이다. | 장치관리자 정책 탭, 여유 공간, 온도이다. | 쓰기 캐시 켜기, 여유 공간 확보, 냉각 개선이다. |
| 초반만 빠르고 곧 급락하다. | 발열 스로틀링이 걸리다. | 센서 온도, 히트싱크, 케이스 공기 흐름이다. | 방열판 부착, 써멀패드 교체, 팬 세팅 조정이다. |
| 부팅 후 일정 시간 동안만 느리다. | 인덱싱, OneDrive 동기화, 백신 스캔이다. | 작업 관리자 디스크 사용률, 리소스 모니터이다. | 백그라운드 작업 제한, 예외 처리이다. |
| 게임/작업 로딩이 끊기다. | 드라이버 충돌 또는 저장소 필터 드라이버 영향이다. | 이벤트 뷰어 디스크 경고, 스토리지 소프트웨어이다. | 문제 드라이버 롤백, 필터 제거이다. |
| 교체 직후부터 전체적으로 느리다. | 호환되지 않는 제조사 전용 드라이버를 강제로 적용하다. | 컨트롤러 벤더, 지원 모델 목록이다. | 표준 NVMe 드라이버로 복귀 또는 정식 지원 버전 적용이다. |
| 복사 속도가 들쭉날쭉하다. | 전원 절약, USB 외장장치 병목, 케이블 문제이다. | 복사 대상 장치 성능, 포트 규격이다. | 내부 디스크끼리 비교, 포트/케이블 교체이다. |
| 장치가 가끔 사라지거나 오류가 나다. | 펌웨어/BIOS 호환, 전원 관리 문제이다. | BIOS 업데이트, NVMe 펌웨어, 절전 복귀 로그이다. | 펌웨어/BIOS 최신화, 절전 옵션 조정이다. |
| 특정 벤치에서만 낮게 나오다. | 테스트 조건 차이, 파일 크기, 캐시 영향이다. | 동일 설정 재현 여부이다. | 동일 조건으로 재측정 후 판단이다. |
3. 가장 먼저 확인할 것: 현재 적용된 NVMe 드라이버가 무엇인지 확인하다
성능 저하의 출발점은 “어떤 드라이버가 실제로 로딩되어 동작 중인지”를 정확히 확인하는 것이다.
3-1. 장치 관리자에서 확인하다
- 장치 관리자 → “저장소 컨트롤러” 또는 “디스크 드라이브”에서 NVMe 관련 항목을 확인하다.
- 문제 상황에서는 제조사 전용 드라이버가 아닌 다른 드라이버로 바뀌었거나, 반대로 비공식 전용 드라이버가 강제로 잡혔을 가능성이 크다.
3-2. 드라이버 파일과 제공자 확인을 명령어로 확인하다
pnputil /enum-drivers | findstr /i "nvme" driverquery /v | findstr /i "nvme"
드라이버 제공자, 버전, 배포 날짜가 교체 시점과 일치하는지 확인하는 것이 핵심이다.
4. 해결의 핵심 1단계: “롤백”이 가능한 상태면 롤백부터 하다
교체 직후부터 성능이 떨어졌다면, 우선 롤백이 가장 빠르고 안전한 복구 방법이다.
4-1. 장치 관리자에서 롤백하다
- 장치 관리자 → 해당 NVMe 컨트롤러 또는 디스크 → 속성 → 드라이버 → “드라이버 롤백”을 실행하다.
- 재부팅 후 동일 조건으로 벤치를 다시 측정하다.
주의 : 롤백 후 BitLocker가 복구키를 요구하면 정상 동작이다. 복구키 입력 후 부팅하고, TPM 관련 설정을 임의로 만지지 않는 것이 안전하다.
5. 해결의 핵심 2단계: 드라이버를 “정상 루트”로 재설치하다
롤백이 불가능하거나 이미 여러 번 교체한 상태라면, 정상 루트로 드라이버를 재설치해야 한다.
5-1. 권장 원칙을 먼저 정리하다
- 제조사 전용 NVMe 드라이버는 “해당 모델을 공식 지원”할 때만 적용하는 것이 원칙이다.
- 공식 지원이 불명확하면 Windows 표준 NVMe 드라이버가 안정성과 호환성이 가장 높다.
- 메인보드/칩셋 드라이버와 BIOS 업데이트는 NVMe 성능과 안정성에 직접 영향을 주다.
5-2. 문제 드라이버를 제거하고 재인식시키다
pnputil /enum-devices /class DiskDrive pnputil /enum-drivers | findstr /i "nvme"
위 출력에서 문제 드라이버의 oemXX.inf를 확인한 뒤 제거하는 방식이 표준 절차이다.
pnputil /delete-driver oemXX.inf /uninstall /force
제거 후 재부팅하면 Windows가 기본 드라이버로 재인식하는 흐름이 일반적이다.
주의 : /force 옵션은 강제 제거이므로, 시스템 디스크 드라이버를 잘못 제거하면 부팅 문제가 발생할 수 있다. 제거 대상이 “실제로 NVMe에 적용 중인 드라이버”인지 반드시 확인하고 진행해야 한다.
6. 성능 저하가 “전원 관리” 때문인지 3분 안에 판별하다
드라이버를 바꾼 뒤 랜덤 성능과 지연이 나빠지는 경우, 실제 원인은 전원 관리 정책인 경우가 매우 많다.
6-1. Windows 전원 모드를 고성능으로 맞추다
- Windows 설정에서 전원 모드를 “최고 성능”으로 바꾸다.
- 제어판 전원 옵션에서 “고성능” 계획을 적용하다.
6-2. PCI Express 링크 상태 전원 관리를 끄다
특히 노트북이나 소형 PC에서 링크 상태 전원 관리가 과도하게 걸리면 NVMe 지연이 커지다.
- 전원 옵션 → 고급 설정 → PCI Express → “링크 상태 전원 관리”를 “끔”으로 설정하다.
6-3. 절전 복귀 후 느려지는 경우 추가 점검하다
- 절전 복귀 직후 성능 저하나 끊김이 있으면, 빠른 시작과 절전 관련 옵션이 영향을 줄 수 있다.
- 빠른 시작을 끄고 증상을 비교하는 것이 진단에 도움이 되다.
7. 성능 저하가 “쓰기 캐시/정책” 때문인지 확인하다
드라이버 교체 과정에서 디스크 정책이 초기화되면, 쓰기 성능이 눈에 띄게 떨어질 수 있다.
7-1. 장치 관리자에서 쓰기 캐시를 확인하다
- 장치 관리자 → 디스크 드라이브 → 해당 NVMe → 속성 → 정책 탭에서 “장치에 쓰기 캐시 사용”을 확인하다.
- 업무용 PC에서 정전 위험이 큰 환경이면 캐시 정책 변경은 운영 정책과 함께 결정해야 하다.
주의 : 쓰기 캐시는 성능을 올리지만, 전원 장애 시 데이터 손상 위험을 키울 수 있다. UPS 환경과 백업 정책이 없는 상태에서 무리하게 설정하지 말아야 한다.
8. “슬롯 대역폭/공유” 문제를 반드시 확인하다
드라이버 교체가 계기였을 뿐, 실제로는 M.2 슬롯 공유로 PCIe 레인이 줄어든 사례가 현장에서 매우 흔하다.
8-1. 대표적인 발생 시나리오이다
- 그래픽카드, 추가 PCIe 카드, SATA 포트를 동시에 쓰면서 M.2가 x4에서 x2로 떨어지다.
- 메인보드의 특정 SATA 포트를 사용하면 특정 M.2 슬롯이 비활성화되다.
- BIOS 업데이트 또는 초기화 후 M.2 관련 설정이 바뀌다.
8-2. 조치 순서이다
- 메인보드 매뉴얼 기준으로 M.2 슬롯 공유 규칙을 확인하다.
- 가능하면 CPU 직결 M.2 슬롯을 사용하다.
- 공유되는 SATA 포트를 비워두고 재측정하다.
9. 발열 스로틀링을 “측정으로” 잡아내다
드라이버 교체 후 성능이 떨어졌다고 느끼지만, 실제로는 장시간 쓰기나 게임 설치 중 발열로 속도가 급락하는 경우가 많다.
9-1. 의심 기준을 명확히 하다
- 초반 5~20초는 정상인데 시간이 지나면 순차 쓰기가 급락하면 발열 스로틀링 가능성이 크다.
- 케이스 내부 공기 흐름이 나쁘거나, 노트북 하판 흡기가 막히면 증상이 커지다.
9-2. 해결 방향이다
- NVMe 방열판과 써멀패드를 적용하다.
- 노트북은 스탠드 사용으로 흡기 공간을 확보하다.
- 케이스 팬 흡기/배기 밸런스를 조정하다.
10. 시스템 무결성과 파일 시스템 상태를 점검하다
드라이버 교체 과정에서 강제 재부팅이 반복되면 파일 시스템 체크가 필요하다.
chkdsk c: /scan sfc /scannow DISM /Online /Cleanup-Image /RestoreHealth
11. “정답 조합”을 빠르게 찾는 실전 복구 시나리오 3가지
현장에서 가장 재현성이 높은 복구 흐름을 3가지로 정리하다.
11-1. 시나리오 A: 교체 직후 성능 급락, 롤백 버튼이 살아있다
- 장치 관리자에서 드라이버 롤백을 수행하다.
- 전원 모드를 최고 성능으로 맞추다.
- 링크 상태 전원 관리를 끄고 재측정하다.
11-2. 시나리오 B: 제조사 전용 드라이버를 설치했는데 느리다
- 해당 NVMe 모델이 그 드라이버를 공식 지원하는지 확인하다.
- 지원이 불명확하면 표준 NVMe 드라이버로 되돌리다.
- 칩셋 드라이버와 BIOS를 최신으로 맞추다.
11-3. 시나리오 C: 드라이버를 되돌려도 여전히 느리다
- M.2 슬롯 공유와 PCIe 레인 저하를 우선 의심하다.
- 발열 스로틀링 여부를 확인하다.
- 쓰기 캐시 정책과 백그라운드 작업을 점검하다.
12. 재발 방지를 위한 운영 기준을 세우다
NVMe 성능 문제는 “한 번 고치고 끝”이 아니라, 재발 방지 기준을 만들면 업무 효율이 크게 좋아지다.
12-1. 드라이버 교체 전 표준 절차이다
- 현재 드라이버 버전과 설치 날짜를 기록하다.
- 복원 지점을 생성하고 BitLocker 복구키를 확보하다.
- 벤치마크 기준값을 동일 조건으로 저장하다.
12-2. 교체 후 검증 기준이다
- 순차 성능만 보지 말고 4K QD1 지연과 랜덤 성능을 함께 확인하다.
- 짧은 테스트와 5분 이상 지속 쓰기 테스트를 모두 수행하다.
- 절전 복귀 후 성능이 유지되는지 확인하다.
FAQ
Windows 표준 NVMe 드라이버가 항상 느린 것인가?
항상 느린 것은 아니다. 많은 환경에서 표준 드라이버는 안정성과 호환성이 높고 성능도 충분히 잘 나오다. 특정 제조사 전용 드라이버가 이점을 주는 경우도 있지만, 공식 지원 모델과 조합이 맞을 때 효과가 나다.
드라이버를 바꿨는데 순차 쓰기만 낮게 나오는 이유가 무엇인가?
쓰기 캐시 정책, 여유 공간 부족으로 인한 SLC 캐시 소진, 발열 스로틀링이 대표 원인이다. 장치 정책에서 쓰기 캐시를 확인하고, 디스크 여유 공간을 확보하며, 장시간 쓰기에서 온도가 급상승하는지 확인하는 것이 핵심이다.
절전 모드에서 깬 뒤 NVMe가 느려지거나 끊기는 이유가 무엇인가?
전원 관리(APST/ASPM)로 지연이 커지거나, BIOS/펌웨어 조합에서 절전 복귀 안정성이 떨어지는 경우가 원인이다. 전원 모드를 높이고 링크 상태 전원 관리를 끄며, BIOS와 NVMe 펌웨어를 최신으로 맞추는 것이 실전 해결책이다.
드라이버 제거가 무서운데 최소 위험으로 복구하는 방법이 있는가?
가장 안전한 순서는 장치 관리자 롤백 → 표준 드라이버로 업데이트(자동 선택) → 전원/정책 조정이다. 강제 제거(pnputil /force)는 마지막 수단이며, 제거 전에 대상 inf가 NVMe와 실제로 연결되어 있는지 반드시 확인해야 하다.