By sonny in PC — 2026년 6월 02일 조회수 조회중입니다

RAW로 잡혀버린 드라이브 데이터 살릴 수 있을까?

파일 시스템 손상, RAW 인식 chkdsk로 해결

※ 본 글은 Windows에서 사용하던 NTFS / FAT32 / exFAT 계열 드라이브가
RAW처럼 표시된 경우에 대한 작업 기록입니다.

chkdsk /f는 모든 RAW 드라이브를 복구하는 명령이 아니며,
원본 디스크의 파일 시스템을 직접 수정하는 작업입니다.

중요한 데이터가 들어 있는 디스크라면 먼저 포맷하거나 chkdsk를 실행하지 말고,
추가 쓰기를 중단한 뒤 디스크 이미지 백업 또는 전문 데이터 복구 절차를 우선 고려해야 합니다.

특히 SSD는 포맷, 삭제, 파티션 재생성 이후 TRIM과 내부 가비지 컬렉션이 개입할 수 있어
복구 가능성이 빠르게 낮아질 수 있습니다.

Linux ext4, macOS APFS/HFS+, NAS 전용 파일 시스템, 암호화 볼륨,
파티션 테이블 손상, 물리 고장 디스크에는 본 글의 방법이 맞지 않을 수 있습니다.

모든 작업은 개인의 책임 하에 진행해야 하며,
이에 따른 데이터 손실, 파일 손상, 장치 손상, 추가 고장 등

어떠한 불이익에 대해서도 작성자는 책임지지 않습니다.

어느 날 갑자기 디스크가 열리지 않는 경우가 있다.

분명 디스크 자체는 Windows에서 잡힌다.
장치 관리자나 디스크 관리에서도 디스크가 아예 사라진 것은 아니다.

그런데 탐색기에서 드라이브를 열려고 하면 접근이 되지 않는다.
오류 검사를 실행하려고 해도 실패하고, 조각 모음이나 드라이브 최적화도 정상적인 디스크를 참조하지 않는다는 식으로 에러가 발생한다.

이번 경우도 그랬다.

디스크는 잡히는데, 드라이브 접근이 되지 않았다.
Windows 기본 오류 검사도 되지 않았고, 조각 모음도 실행되지 않았다.

결론부터 말하면 이번 사례는 관리자 권한 CMD에서 chkdsk /f를 실행해 복구할 수 있었다.

다만 이 글은 chkdsk /f를 무조건 먼저 실행하라는 글이 아니다.
특히 SSD라면 포맷은 절대 먼저 하면 안 되고, chkdsk /f도 원본 디스크에 변경을 가하는 명령이기 때문에 상황에 따라 신중히 판단해야 한다.

1. 증상

이번에 확인한 증상은 다음과 같았다.

항목	확인 결과
디스크 인식	Windows에서 드라이브 자체는 인식됨
탐색기 접근	접근 불가
오류 검사	실행 불가
조각 모음 / 최적화	정상 디스크가 아니라는 식의 오류 발생
파일 시스템 상태	RAW 또는 파일 시스템 손상 상태로 보임
최종 조치	`chkdsk /f` 실행 후 접근 가능 상태로 복구

RAW 상태라는 것은 Windows가 해당 파티션의 파일 시스템을 정상적으로 해석하지 못하는 상태에 가깝다.

일반적으로 드라이브는 NTFS, FAT32, exFAT 같은 파일 시스템으로 인식되어야 한다.
그런데 파일 시스템 메타데이터가 손상되었거나, 파티션 정보가 꼬였거나, 디스크의 일부 영역을 정상적으로 읽지 못하면 Windows가 해당 볼륨을 RAW로 표시할 수 있다.

Microsoft 공식 문서 기준으로 chkdsk는 볼륨의 파일 시스템과 파일 시스템 메타데이터를 검사하는 명령이다. 옵션 없이 실행하면 상태만 표시하고, /f, /r, /x, /b 같은 옵션을 사용하면 오류 수정 작업을 수행한다.

2. 먼저 하면 안 되는 것

RAW로 잡힌 디스크를 열려고 하면 Windows에서 보통 이런 메시지를 띄운다.

데이터 복구가 목적이라면

여기서 포맷을 누르면 안 된다.

데이터가 필요 없는 디스크라면 포맷 후 다시 사용하면 된다.
하지만 내부 자료를 살려야 하는 상황이라면 포맷은 최후의 선택이다.

그 이유를 설명하자면,

상황	이유
내부 파일을 살려야 함	파일 시스템 구조가 새로 작성될 수 있음
백업이 없음	원본 손상 시 복구 난이도 상승
RAW 원인이 불명확함	논리 손상인지 물리 고장인지 아직 모름
SSD임	TRIM, 가비지 컬렉션 때문에 복구 가능성이 더 빠르게 떨어질 수 있음
외장하드 또는 USB 저장장치임	케이블, 전원, USB-SATA 브리지 문제일 수도 있음

즉, RAW 상태에서 가장 먼저 할 일은 멈추는 것이다.

포맷하지 않기→ 추가 쓰기 중단→ 디스크 상태 확인→ 가능하면 이미지 백업→ 복제본 기준으로 복구 시도

3. SSD라면 작업을 더 조심해야 하는 이유

HDD도 복구 전 포맷은 피해야 하지만, SSD는 더 조심해야 한다.

이유는 SSD가 HDD처럼 단순히 “물리 섹터 위에 데이터가 그대로 남아있는 구조”로만 동작하지 않기 때문이다.

SSD는 내부적으로 다음 기능들이 개입한다.

기능	설명
TRIM	운영체제가 더 이상 사용하지 않는 블록 정보를 SSD에 알려주는 기능
가비지 컬렉션	SSD 내부에서 불필요한 블록을 정리하는 작업
웨어레벨링	특정 NAND 셀만 빨리 닳지 않도록 쓰기 위치를 분산하는 기능
FTL	논리 주소와 실제 NAND 물리 위치를 매핑하는 계층

Windows는 SSD가 TRIM 또는 UNMAP을 지원하는지 확인하고, 저장장치 프로토콜에 따라 UNMAP 요청을 SCSI UNMAP 또는 ATA TRIM 명령으로 변환할 수 있다.

Microsoft 문서에서도 TRIM/UNMAP 힌트는 삭제된 영역을 저장장치에 전달해 SSD 성능 최적화에 활용된다고 설명한다.

문제는 데이터 복구 관점이다.

HDD에서는 빠른 포맷을 하더라도 실제 파일 본문 데이터가 물리 섹터에 남아 있어 복구 가능성이 남는 경우가 있다.
하지만 SSD는 포맷, 삭제, 파티션 재생성 이후 운영체제가 해당 영역을 빈 공간으로 판단하고 TRIM을 전달할 수 있다.

그 뒤 SSD 컨트롤러가 해당 영역을 더 이상 유효 데이터로 취급하지 않으면, 이후 가비지 컬렉션 과정에서 실제 NAND 데이터가 정리될 수 있다.

즉, SSD에서 포맷은 단순히 “파일 목록만 지우는 행동”으로 끝나지 않을 수 있다.

RAW 인식→ 사용자가 포맷 실행→ 새 파일 시스템 생성→ 기존 파일 시스템 메타데이터 손상 확대→ Windows가 빈 공간으로 인식→ TRIM 전달 가능→ SSD 내부 정리 작업 진행→ 복구 가능성 하락

이 말은 복구 관점에서도 중요하다.
SSD는 사용자가 보는 논리 주소와 실제 NAND 내부 위치가 단순하게 1:1로 고정되어 있지 않다.

그래서 SSD에서는 “포맷하고 복구 프로그램 돌리면 되겠지”라는 판단이 HDD보다 훨씬 위험하다.

4. HDD와 SSD의 차이

구분	HDD	SSD
저장 방식	자기 디스크 플래터	NAND 플래시
데이터 위치	물리 섹터 기반으로 비교적 직관적	FTL을 통해 논리 주소와 물리 위치 매핑
삭제 후 데이터	덮어쓰기 전까지 남아있을 가능성 있음	TRIM 이후 복구 가능성이 급격히 낮아질 수 있음
빠른 포맷 후 복구 가능성	남는 경우 있음	컨트롤러/TRIM 상태에 따라 낮아질 수 있음
불량 처리	배드 섹터 중심	예비 블록, 웨어레벨링, 컨트롤러 처리 개입
복구 난이도	논리 손상은 복구 가능성 있음	TRIM, 컨트롤러, NAND 상태에 따라 복잡해짐

정리하면 이렇다.

HDD는 포맷 후에도 실제 데이터가 남아 있을 가능성이 상대적으로 있다.
SSD는 포맷이나 삭제 이후 TRIM이 개입하면 복구 가능성이 더 빠르게 떨어질 수 있다.

따라서 SSD RAW 드라이브는 포맷 버튼을 누르는 순간부터 상황이 더 나빠질 수 있다.

5. 이번 경우의 판단

이번 디스크는 다음 조건에 가까웠다.

판단 항목	상태
디스크 장치 인식	가능
용량 인식	가능
탐색기 접근	불가
오류 검사	불가
조각 모음	불가
물리적 이상 징후	명확하게 확인되지 않음
RAW 또는 파일 시스템 손상 가능성	높음

디스크가 아예 죽은 상태는 아니었다.
용량도 잡혔고, Windows에서 장치 자체는 확인되었다.

따라서 컨트롤러 사망이나 완전한 물리 고장보다는 파일 시스템 메타데이터 손상 쪽 가능성이 높다고 판단했다.

그래서 관리자 권한 CMD에서 chkdsk /f를 실행했다.

단, 이 판단은 이번 사례 기준이다.
중요한 원본 데이터가 들어 있는 SSD라면 원칙적으로 이미지 백업이 먼저다.

6. 실행한 명령어

먼저 관리자 권한으로 명령 프롬프트를 실행한다.

문제가 발생한 드라이브 문자를 확인한다.
예를 들어 문제가 된 드라이브가 D:라면 다음 명령을 입력한다.

chkdsk D: /f

7. 옵션설명

처음부터 /r을 사용하는 경우도 있지만, 이번에는 /f를 먼저 사용했다.

옵션	의미	특징
`/f`	파일 시스템 오류 수정	비교적 기본적인 논리 오류 수정
`/r`	불량 섹터 검색 및 읽을 수 있는 정보 복구 시도	시간이 오래 걸리고 디스크 부하가 큼
`/x`	필요한 경우 볼륨을 먼저 분리	사용 중인 볼륨 검사 시 필요할 수 있음
옵션 없음	상태 확인	오류를 수정하지 않음

이번 경우는 물리 배드섹터 문제보다는 파일 시스템 손상으로 판단했기 때문에 /f를 먼저 실행했다.

특히 HDD에서 /r은 전체 표면 검사에 가까운 작업이 포함되어 시간이 오래 걸린다.
상태가 좋지 않은 디스크라면 긴 검사 과정 자체가 부담이 될 수 있다.

SSD에서도 무리한 전체 검사는 좋은 선택이 아닐 수 있다.
중요한 데이터가 있다면 원본에 직접 여러 복구 명령을 반복하는 것보다 이미지 백업 후 복제본에서 작업하는 편이 더 안전하다.

8. 실행 결과

chkdsk /f 실행 후, RAW처럼 보이던 드라이브가 다시 접근 가능한 상태가 되었다.탐색기에서 드라이브가 열렸고, 기존 파일 목록도 확인할 수 있었다.

정리하면 다음과 같다.

단계	결과
디스크 인식	가능
드라이브 접근	불가
Windows 오류 검사	불가
조각 모음	불가
`chkdsk /f` 실행	성공
파일 접근	가능 상태로 복구

이번 사례는 파일 시스템 논리 오류가 chkdsk /f로 복구된 경우에 가깝다.

9. 항상 성공하는 방법은 아니다

중요한 부분은 여기다.

chkdsk /f로 이번에는 복구가 되었지만, 모든 RAW 드라이브가 이 방법으로 복구되는 것은 아니다.

RAW 상태에서 chkdsk를 실행하면 아래와 같은 메시지가 나올 수도 있다.

CHKDSK is not available for RAW drives.

이 경우 Windows가 해당 볼륨을 chkdsk로 검사 가능한 정상 파일 시스템으로 해석하지 못하는 상태다.

즉, 디스크 관리에서는 RAW로 보이더라도 내부적으로 NTFS 구조 일부가 남아 있어서 chkdsk가 동작하는 경우가 있고, 반대로 파일 시스템 구조가 더 심하게 손상되어 chkdsk 자체가 거부되는 경우도 있다.

이번 사례는 전자에 가까웠다.

RAW로 보임→ 하지만 NTFS 구조 일부가 남아 있음→ chkdsk가 파일 시스템 복구 가능→ /f 옵션으로 오류 수정→ 드라이브 접근 가능

반대로 아래처럼 진행되는 경우도 있다.

RAW로 보임→ 파일 시스템 구조를 거의 해석하지 못함→ chkdsk 실행 불가→ 복구 프로그램 또는 전문 복구 영역

따라서 chkdsk /f는 RAW 드라이브 만능 해결책이 아니다.

10. 왜 이런 일이 생겼을까?

정확한 원인은 디스크 상태를 더 깊게 분석해야 알 수 있다.

다만 일반적으로 이런 증상은 아래 원인에서 발생할 수 있다.

가능 원인	설명
비정상 종료	파일 시스템 기록 중 전원 차단
USB 저장장치 강제 제거	쓰기 캐시가 반영되기 전 분리
파일 시스템 메타데이터 손상	MFT, 인덱스, 비트맵 등 NTFS 구조 오류
케이블 / 포트 불량	연결 불안정으로 인한 읽기·쓰기 오류
외장 케이스 문제	USB-SATA 브리지 또는 전원 공급 문제
디스크 노후화	읽기 오류, 배드 섹터, NAND 오류 누적
컨트롤러 문제	저장장치 내부 컨트롤러 이상

특히 외장 SSD나 외장 HDD라면 디스크 자체만 볼 것이 아니라
케이블, USB 포트, 전원 공급, 외장 케이스 상태도 함께 확인해야 한다.

디스크 자체에는 문제가 없더라도 USB-SATA 브리지나,
케이블 접촉 불량 때문에 쓰기 작업이 비정상적으로 끊기고,
그 결과 파일 시스템이 손상될 수 있다.

따라서 외장 저장장치는 사용 후 바로 뽑기보다,
Windows의 하드웨어 안전하게 제거 기능을 사용해 연결을 해제한 뒤
물리적으로 분리하는 것이 좋다.

이 과정은 쓰기 캐시가 남아 있는 상태에서 저장장치가 분리되는 상황을
줄이는 데 도움이 된다.

11. 중요한 데이터라면 chkdsk /f도 바로 실행하지 않는 편이 안전하다

chkdsk /f는 읽기 전용 명령이 아니다.

/f 옵션은 파일 시스템 오류를 수정한다.
즉, 원본 디스크에 변경 작업을 수행한다.

이번 사례에서는 chkdsk /f가 좋은 결과를 냈지만, 다음과 같은 상황이라면 바로 실행하지 않는 편이 낫다.

상황	권장 판단
중요한 원본 자료가 하나뿐임	이미지 백업 우선
SSD에 중요한 데이터가 있음	포맷 금지, 원본 쓰기 최소화
디스크에서 이상 소음 발생	즉시 중단, 전문 복구 검토
연결과 해제가 반복됨	케이블/전원/케이스 점검 우선
용량이 이상하게 표시됨	컨트롤러 또는 파티션 문제 가능성
`chkdsk`가 RAW라며 거부함	복구 프로그램 또는 전문 복구 검토
복구 실패 시 손실이 큼	원본 작업 금지

데이터 복구의 기본은 원본 보존이다.

원본 디스크에 직접 수정= 성공하면 빠름= 실패하면 손상 확대 가능

반대로 이미지 백업 후 복제본에서 작업하면 다음 장점이 있다.

원본 보존→ 복제본에서 복구 시도→ 실패해도 다시 다른 방법 시도 가능

따라서 업무 자료, 사진, 문서, 회계 자료, 프로젝트 파일처럼 중요한 데이터라면 chkdsk /f를 원본에 바로 실행하기 전에 이미지 백업부터 고려하는 편이 맞다.

12. SSD RAW 드라이브에서 권장 순서

SSD가 RAW로 잡혔고, 내부 데이터가 필요하다면 순서는 다음이 안전하다.

순서	작업	이유
1	포맷 취소	새 파일 시스템 생성 및 TRIM 가능성 방지
2	추가 쓰기 중단	기존 데이터 영역 훼손 방지
3	케이블/포트/외장 케이스 확인	단순 연결 문제 배제
4	SMART 상태 확인	물리적 이상 여부 확인
5	가능하면 디스크 이미지 백업	원본 보존
6	복제본 기준 복구 시도	실패해도 원본 유지
7	논리 손상으로 판단될 때 `chkdsk /f` 검토	파일 시스템 복구 시도
8	복구 후 즉시 다른 디스크로 백업	재발 또는 추가 손상 대비

여기서 가장 중요한 것은 첫 번째다.

포맷하지 않기

SSD에서는 포맷이 단순 초기화처럼 보이더라도 복구 관점에서는 손실 가능성을 키우는 행동이 될 수 있다.

13. 복구 후 확인해야 할 것

드라이브가 다시 열린다고 해서 바로 정상이라고 단정하면 안 된다.

복구 후에는 먼저 필요한 자료를 다른 저장장치로 복사해야 한다.

그다음 상태 확인을 진행하는 편이 좋다.

13-1. 파일 접근 확인

아래 항목을 확인한다.

확인 항목	이유
주요 폴더 열림 여부	디렉터리 구조 복구 확인
주요 파일 열람 가능 여부	실제 데이터 접근 확인
대용량 파일 복사 가능 여부	읽기 오류 여부 확인
파일명 깨짐 여부	인덱스 손상 여부 확인
일부 파일 누락 여부	복구 과정에서 손실 발생 여부 확인

드라이브가 열린다고 해서 모든 파일이 정상이라는 뜻은 아니다.

파일 목록은 보이지만 일부 파일이 열리지 않거나, 복사 중 오류가 발생할 수 있다.

13-2. chkdsk 상태 확인

복구 후 상태 확인용으로는 옵션 없이 실행할 수 있다.

예를 들어 D: 드라이브라면 다음과 같이 입력한다.

chkdsk D:

옵션 없이 실행하면 오류 수정 없이 상태 확인만 수행한다. Microsoft 공식 문서에서도 옵션 없이 chkdsk를 실행하면 볼륨 상태만 표시하고 오류를 수정하지 않는다고 설명한다.

단, 이미 복구가 된 직후라면 검사보다 먼저 중요한 파일 백업이 우선이다.

13-3. SMART 상태 확인

HDD나 SSD 모두 SMART 상태를 확인하는 것이 좋다.

확인할 항목은 다음과 같다.

항목	의미
재할당 섹터 수	HDD에서 물리 섹터 문제 가능성
보류 중인 섹터 수	읽기 불안정 섹터 가능성
CRC 오류	케이블/연결 문제 가능성
사용 시간	노후화 판단 참고
SSD 수명 관련 항목	NAND 마모도 참고
미디어 오류	SSD 내부 읽기/쓰기 오류 가능성

SMART가 나쁘다면 해당 디스크는 계속 쓰지 않는 편이 안전하다.

14. 이번 사례 정리

이번 사례는 다음과 같이 정리할 수 있다.

구분	내용
문제	디스크는 잡히지만 접근 불가
증상	오류 검사, 조각 모음 모두 실패
상태	RAW 또는 파일 시스템 손상 상태로 보임
조치	관리자 권한 CMD에서 `chkdsk /f` 실행
결과	드라이브 접근 가능 상태로 복구
주의	중요한 데이터라면 이미지 백업 우선
SSD 주의점	포맷 시 TRIM/가비지 컬렉션으로 복구 가능성 하락 가능

실행한 명령은 다음과 같다.

chkdsk D: /f

여기서 D:는 예시다.
실제 작업할 때는 문제가 발생한 드라이브 문자로 바꿔야 한다.

15. 결론

이번 RAW 드라이브는 디스크 자체는 인식되지만 탐색기 접근, 오류 검사, 조각 모음이 모두 불가능한 상태였다.

파일 시스템 손상 가능성이 높다고 판단했고, 관리자 권한 CMD에서 다음 명령을 실행했다.

chkdsk D: /f

결과적으로 드라이브 접근이 다시 가능해졌고, 기존 파일도 확인할 수 있었다.

하지만 이 방법은 만능 복구법이 아니다.

chkdsk /f는 파일 시스템 오류를 수정하는 명령이다.
즉, 원본 디스크에 변경을 가한다.

특히 SSD라면 더 조심해야 한다.

SSD는 HDD와 달리 TRIM, 가비지 컬렉션, 웨어레벨링이 개입한다.
포맷을 누르는 순간 기존 파일 시스템 정보가 새로 작성될 뿐 아니라, 운영체제가 빈 공간으로 판단한 영역에 TRIM이 전달될 수 있다. 이후 SSD 컨트롤러가 해당 NAND 영역을 정리하면 복구 가능성은 더 낮아진다.

따라서 SSD가 RAW로 잡힌 상태에서 데이터가 필요하다면 가장 먼저 해야 할 일은 포맷이 아니다.

포맷하지 않기→ 추가 쓰기 중단→ 가능하면 디스크 이미지 백업→ 복제본 기준 복구 시도→ 원본 수정 작업은 최후 판단

HDD에서도 포맷은 위험하지만, SSD에서는 포맷이 복구 가능성을 더 빠르게 떨어뜨릴 수 있다.

그래서 RAW 드라이브 복구의 핵심은 다음이다.

디스크가 잡힌다 = 아직 기회가 있을 수 있음포맷을 누른다 = 복구 가능성을 줄일 수 있음chkdsk /f = 경우에 따라 효과적이지만 원본 수정 작업중요 데이터 = 이미지 백업 우선

이번 사례는 운 좋게 chkdsk /f로 복구된 경우였다.

하지만 RAW로 보이는 디스크는 이미 한 번 파일 시스템 문제가 발생한 상태다.
복구 후에는 그대로 계속 사용하기보다 필요한 자료를 먼저 다른 저장장치로 백업하는 것이 우선이다.