맥 외장하드 exFAT 손상, 영상 파일 유실 복구: 재마운트와 코덱 일치

exFAT 파일 시스템이 손상된 외장하드에서 영상 파일이 유실되었을 때, 문제를 진단하고 복구하는 과정을 담았다.

얼마 전, 맥 미니에 연결된 Elements 4TB 외장하드에 평소처럼 영상 작업물을 정리하고 있었다. 파일 시스템은 exFAT으로, 고해상도 장시간 영상 파일이 많아 늘 용량 관리에 신경 쓰는 편이다. 단순한 파일 이동 작업이었는데 왠지 모르게 불안한 느낌이 들었다.

외장하드 이상 감지: rsync 먹통과 파일 삭제 불가

문제는 한밤중에 찾아왔다. rsync 명령어로 영상 파일 하나(4.96GB) 대용량 영상 파일을 옮기던 중 진행률이 멈추고 터미널이 먹통이 되었다. 무려 6시간 동안 U-state로 있었고, 결국 프로세스를 kill -9로 강제 종료해야 했다. 재부팅하면 괜찮아지겠지 싶었지만, 그때는 새벽이라 그냥 잠들었고 다음 날 아침 이 사소한 행이 큰 문제로 이어질 줄은 예상하지 못했다.

다음 날 아침, 사태의 심각성을 깨달았다. rsync가 멈췄던 파일을 rm으로 지우려 했지만, 명령은 성공했다고 뜨는데 ls로 확인하니 파일이 그대로 남아있었다. 몇 번을 시도해도 마찬가지였고, 작은 텍스트 파일은 지워졌지만 영상 파일처럼 큰 건 꿈쩍도 안 했다. 파일 시스템이 완전히 정신을 놓은 듯 뭘 해도 제대로 반영되지 않는 지옥 같은 상황이었다.

불길한 예감은 적중했다. 또 다른 영상 파일 영상-052를 복사하려는데, 29GB짜리 파일이 고작 592MB만 읽히고는 EOF(End Of File) 에러를 뿜어냈다. 파일 크기는 29GB라고 뜨지만 실제 데이터는 앞부분만 살아있다는 뜻이었고, 파일이 아주 깔끔하게 잘린 상태였다. 겉으로는 멀쩡해 보이는데 속은 텅 비어 있었으니, 드라이브가 나를 기만하는 수준이었다.

exFAT 드라이버의 침묵: diskutil 재마운트가 답이었다

도대체 뭐가 문제였을까? rm이 먹통이던 문제부터 해결해야 했다. diskutil unmount /Volumes/Elements 후 diskutil mount /Volumes/Elements로 외장하드를 다시 마운트하자 거짓말처럼 rm이 제대로 작동했다. 맥OS의 fskit exFAT 드라이버가 I/O 오류나 프로세스 행 이후 조용히 오작동 상태에 빠지는 것이었다.

이런 경우, 삭제나 복사 명령이 겉으로는 성공한 것처럼 보여도 실제로는 아무것도 하지 않는다는 점을 깨달았다. 이제부터는 exFAT 드라이브에 이상 기미가 보이면 무조건 재마운트를 첫 처방으로 삼아야겠다고 생각했다. rm이 성공했다고 해도 반드시 ls나 du로 실제 반영되었는지 눈으로 확인하는 습관을 들여야 한다.

손상된 영상 파일 복구 전략: ffmpeg과 untrunc

이제 잘려나간 영상 파일을 살릴 차례였다. 영상-052 같은 파일은 dd 명령어로 일단 읽히는 부분까지만 복사해두고, dd bs=1m skip=N count=1 | wc -c 이진 탐색으로 읽기 한계를 정확히 파악했다. 그렇게 확보한 파일이 다행히 faststart (영상 메타데이터인 moov atom이 파일 시작 부분에 있는 형식)였다면 ffmpeg -c copy 명령으로 깨진 뒷부분을 잘라내고 다시 멀쩡한 MP4 컨테이너로 리먹싱할 수 있었다. 그러면 비록 길이가 짧아졌어도 온전하게 재생되는 영상 파일이 된다.

하지만 모든 파일이 그렇게 운이 좋지는 않았다. moov atom이 파일 끝에 있는 경우는 앞부분만 잘라내서는 재생 자체가 되지 않아 문제가 된다. 이럴 때 untrunc라는 복구 도구를 사용하는데, 이 도구는 손상된 영상 파일과 동일한 코덱으로 촬영된 멀쩡한 참조 파일을 가지고 손상된 파일의 moov atom을 재구축해준다.

untrunc의 함정: 코덱 일치의 중요성

여기서 또 한 번의 난관이 기다리고 있었다. H.264 코덱으로 촬영된 참조 파일을 가지고 HEVC(H.265) 코덱으로 촬영된 손상 파일을 복구하려 한 것이다. untrunc는 아무런 에러 메시지 없이 복구 작업을 진행하는 듯 보였으나, 몇 시간을 기다려 복구된 파일을 재생해보니 역시나 재생이 되지 않았다.

아무리 해도 안 되길래 매뉴얼을 다시 뒤적였고, 그제야

참조 파일은 반드시 코덱이 같아야 한다

는 문장을 발견했다. "아차!" 이런 기본적인 함정에 발목이 잡혔지만, 결국 같은 카메라로 찍은 HEVC 샘플 영상을 어렵게 구해 다시 untrunc를 돌렸고 그제서야 제대로 복구된 영상을 손에 넣을 수 있었다.

 

이런 류의 작업에서 가장 중요한 건 절대 컨테이너 파일 길이만 믿지 말라는 점이다. 파일 탐색기에서 29GB라고 표시되어도 실제로는 592MB밖에 재생되지 않을 수 있으니, 복구한 파일은 반드시 처음부터 끝까지 재생 가능한지 확인해야 한다.

예전에 장시간 영상 인코딩 작업 중 Mac mini의 MPS 캐시가 스왑 메모리를 48GB까지 채우고 macOS에 의해 SIGKILL 당해 통째로 날린 적이 두 번 있다. 8시간짜리 작업이 95%에서 죽는 순간은 정말 좌절스러웠지만, 그때부터 --mp4-fast-start 옵션을 써서 파편화된 MP4 파일을 만들어두는 습관이 생겼다. 덕분에 중간에 죽어도 부분적으로나마 파일이 살아남는다는 것을 배웠고, 이러한 경험이 영상 파일의 부분 손실과 복구에 집착하게 된 이유가 되었다.

외장하드 파일 관리와 복구를 위한 나의 교훈

이번 일을 통해 두 가지 중요한 교훈을 확실히 배웠다.

• 운영체제가 침묵하거나 오작동할 때, 겉으로 보이는 성공 메시지를 맹신하지 말고 항상 실제 결과를 검증해야 한다. 특히 exFAT 드라이브는 문제가 발생하면 diskutil unmount/mount가 만능 해결책이다.
• 영상 복구는 까다로우며, untrunc 같은 도구를 쓸 때는 참조 파일의 코덱 일치가 필수적이다. 단순히 파일 크기가 커졌다고 안심하지 말고, 실제 재생 가능 구간을 끝까지 확인하는 인내심이 필요하다.

함께 보면 좋은 글

• Codex CLI 로그인 오류 해결: brew cask, 401 Unauthorized, Git 레포
• Claude CLI 401 Unauthorized: 리프레시 토큰 재사용 문제 해결

※ 이 글은 직접 겪은 작업 경험을 바탕으로 AI의 도움을 받아 작성했습니다.