일반 포맷이 수행하는 작업은 정확하게 무엇일까? - 오류 검사 vs 제로필

이 글은 아래의 관련 글들에 댓글로 들어온 의문 제기에 대한 저의 답변이자 윈도우의 포맷에 대한 종합적인 테스트 결과입니다.

[디스크 정보] 파일 시스템과 포맷 2 장 - 일반 포맷과 빠른 포맷
빠른 포맷과 일반 포맷의 차이점 - 무엇을 선택해야 하나?
빠른 포맷과 일반 포맷의 차이점 - 실제 포맷 결과 비교

글을 시작하기 전에 먼저 최초의 의문 제기 후 거의 두 달만에 답변을 하게 되는 점 굉장히 죄송하게 생각합니다. 댓글을 다신 시기와 제가 잠시 블로그 활동을 쉰 시기가 맞물려 잊어버리고 있었습니다. 그러다 새로 다신 댓글을 보고 이제야 생각이 나서 글을 작성하게 되었네요. 그럼 글을 시작하도록 하겠습니다.

Ⅰ. 일반 포맷 문제에 대한 새로운 접근 가능성에 대하여

포맷과 관련된 글들에서 제가 공통되게 했던 이야기가 있습니다. 바로 일반 포맷은 데이터 영역의 모든 공간을 0 으로 가득 채우는 제로필 작업을 진행하고, 그로 인해 일반 포맷을 진행한 드라이브는 모든 데이터가 완전히 삭제되어 파일 복구 프로그램을 통해서는 파일들을 복구할 수 없다는 이야기입니다.

먼저 짚고 넘어가고 싶은 것은 제가 진행했던 헥스 에디터를 통해 직접 섹터의 내용을 확인하는 테스트 방식은 제가 아는 한도 내에서는 잘못된 것이 아니며 문제가 없다는 것입니다. 제 지식 내에서 그러한 확신조차 없었다면 그것을 토대로 결론을(제로필) 내리고 글로 작성하지도 않았을 겁니다.

추가로 이게 그 당시 제가 진행했던 테스트에서 실수한 부분인데요. 그것은 일반 포맷이 제로필 작업을 진행한다는 결론은 디스크와 파티션 강좌를 정리했던 시기인 1차 윈도우 비스타에서, 2차 윈도우 7 에서 여러 번의 테스트를 진행하고 내렸던 결론이란 것을 미리 밝힙니다.


아무튼, 해당 글들에서 제가 이야기했던 것과는 다르게 일반 포맷은 제로필 작업을 진행하지 않고, 고로 파일 복구 프로그램을 통해 섹터 영역을 직접 검색하면 파일 복구가 가능하다는 댓글이 달렸습니다. 그리고 본인께서 실제로 일반 포맷을 진행한 후 FinalData 2.0 이라는 파일 복구 프로그램을 통해 복구를 한 적이 있었다는 내용이었죠. 그와 함께 제가 잘못된 결론을 내리게 된 것은 애초에 저의 테스트 방식에 문제가 있는 것이고, 그것은 아마도 헥스 에디터가 정확하게 뭔지는 모르겠지만 그게 범인일 것이다라는 이야기를 하셨습니다.

일단 다른 것은 제쳐두고라도 제가 해당 댓글들에서 가장 중요하게 생각하는 것은 실제로 일반 포맷을 진행한 후 파일 복구 프로그램을 통해 파일들을 복구를 한 적이 있었다는 사실입니다. 착각하여 빠른 포맷을 일반 포맷으로 잘못알고 진행한 것이 아니라면 그것은 굉장히 중요한 가치를 가지는 사실이 되는 거죠.


제가 진행한 테스트는 제가 직접 한 것이기 때문에 저에게 있어서는 의심할 여지가 없는 사실입니다. 하지만 관련 글들의 댓글에서 언급된 것처럼 (정확하게 일반 포맷을 진행하였는지는 직접 보지 못해 알 수 없지만 그것이 사실이라면) 실제로 일반 포맷을 진행한 후 파일을 복구한 것도 사실입니다.

일단 이 둘이 모두 맞다는 가정을 하면 가능성은 한 가지로 압축됩니다. "윈도우의 차이" 즉, 댓글에서 사용하였다고 언급된 FinalData 2.0 이란 파일 복구 프로그램은 윈도우 XP 시절에 사용되던 것이고, 저는 윈도우 비스타와 윈도우 7 에서 테스트를 진행하였으니 둘의 결정적인 차이는 윈도우라고 생각할 수 있는 것이죠. 그러면 아래와 같은 추론이 가능합니다.

* 윈도우의 버전에 따라 포맷의 작업 방식이 바뀌었을 가능성이 있다. (여러 정황상 윈도우 비스타로 넘어오면서)

어차피 포맷도 프로그램입니다. 프로그램은 항상 변합니다. 내가 보안 삭제 프로그램을 만드는 프로그래머이고, 그래서 어제까지 0x00 으로 덮어쓰기 하는 삭제 알고리즘 방식으로 만들었었다면, 오늘부터는 0xFF 로 덮어쓰기 하는 삭제 알고리즘 방식으로 바꿀 수도 있는 것이죠.

만약에 이러한 가정이 사실이라면 제가 예전에 글을 쓸 당시에 실수한 것은 비스타와 7 이라는 겨우 두 가지 윈도우에서만 진행한 테스트 결과를 가지고 다른 윈도우에서도 모두 동일할 것이라고 섣부른 판단을 한 것이겠죠. [사실 큰 실수를 했다고 할 수 있죠.] 실제로 직접 일반 포맷 후 파일을 복구했었다는 이야기를 듣고 골똘히 생각해보다가 이러한 추론에 다다랐을 때는 정말로 좋았는데... 근데 잠깐 쉬려던 게 너무 오래 쉬었네요. 아무튼, 이것은 오늘 진행할 테스트를 통해 알 수 있게 될 것입니다.

물론 제가 믿어 의심치 않는 헥스 에디터를 통해 직접 섹터를 확인하는 방식의 테스트가 사실은 잘못된 것일 수도 있고, 댓글에선 일반 포맷을 했었다고 하였지만, (제가 직접 보지 못했으니) 실제론 빠른 포맷을 하곤 착각을 했을 수도 있습니다. 당연하게도 이 둘의 가능성도 의심을 해봐야 합니다. 아무튼, 이러한 모든 것의 확인을 위해선 그 당시 진행했던 테스트보다 좀 더 폭넓은 테스트를 진행해야 할 필요가 있습니다.

Ⅱ. 테스트 과정에 대한 설명과 사전 준비

위에서 이야기한 모두를 확인할 수 있는 테스트를 진행해야 합니다. 그래서 테스트의 큰 틀을 짜봤습니다.

01. 모든 공간에 대한 제로필이 완료된 깨끗한 디스크와 파티션을 준비한다.
02. 해당 파티션에 파일들을 집어넣는다.

03. 윈도우 XP 에서 빠른 포맷을 진행한다.
04. 헥스 에디터를 통해 파일이 기록된 섹터 영역을 확인한다.
05. 파일 복구 프로그램을 통해 파일의 복구를 시도한다.

06. 이어서 일반 포맷을 진행한다.
07. 헥스 에디터를 통해 파일이 기록된 섹터 영역을 확인한다.
08. 파일 복구 프로그램을 통해 파일의 복구를 시도한다.

09. 일반 포맷의 결과에 따라 추가로 보안 삭제 프로그램을 통해 파티션을 통채로 제로필한다.
10. 헥스 에디터를 통해 파일이 기록된 섹터 영역을 확인한다.
11. 파일 복구 프로그램을 통해 파일의 복구를 시도한다.

**. 파일 시스템의 종류에 따른 차이는 없는지 확인하기 위하여 FAT32 와 NTFS 로 파일 시스템을 달리하여 테스트한다.
**. 동일한 방식으로 윈도우 비스타, 윈도우 7, 윈도우 8 모두에서 테스트를 진행한다.

대충 이정도면 될 것 같습니다. 만약 동시에 테스트한 헥스 에디터 확인 방식과 파일 복구의 결과가 다르게 나타난다면 둘 중에 하나가 잘못되었음을 의미하는 것이기에 모든 작업에서 둘 모두로 확인하는 것으로 하였습니다.



먼저 깨끗한 디스크와 파티션을 준비하기 위해 테스트용 디스크를 완전히 제로필하였습니다. 제로필은 윈도우 DiskPart 의 Clean All 기능을 사용하였으며, Clean All 작업이 못 미더운 분들을 위해 HDD Low Level Format Tool 4.25 란 프로그램을 통해 다시 한 번 더 제로필 작업을 진행하였습니다.

그리고 아래는 테스트를 위해 설치한 윈도우 XP, 비스타, 7, 8 의 모습과 포맷 테스트에 사용된 파티션인 T: 드라이브의 모습입니다. T: 드라이브는 테스트의 속도를 위해 200MB 의 소용량으로 잡았습니다. [물론 디스크 전체를 통으로 하나의 파티션으로 잡고 동일한 방식으로 추가 테스트를 진행하였고, 동일한 결과를 보여줌을 확인하였습니다.]

* 윈도우 환경 정보

- Windows XP Professional Service Pack 3 x86
- Windows Vista Ultimate K Service Pack 2 x86
- Windows 7 Ultimate K Service Pack 1 x86
- Windows 8 Pro K x64

마지막으로 아래는 해당 드라이브에 담을 파일들의 모습입니다.

이 때 파일의 종류로 사진 파일과 텍스트 파일 두 가지를 준비한 것은 아래와 같은 이유가 있습니다.

먼저 사진 파일들은 파일 복구시에 정확하게 복구가 된 것인지 빠르게 확인이 가능합니다. 사진 파일의 경우 일부 데이터가 손실되더라도 복구가 가능한 경우가 많고, 만약 복구되었다면 파일이 온전히 복구된 것인지 깨진 채로 복구된 것인지 바로 보이기 때문에 확인하기가 편합니다.

다음으로 텍스트 파일은 드라이브 공간의 거의 대부분을 차지하도록 약 160MB 정도로 크게 생성하였으며 보시는 것과 같이 오직 CApple 이라는 글자만 담겨 있습니다. 이렇게 영문으로만 구성된 텍스트 파일은 헥스 에디터를 통해 살펴볼 때도 해당 텍스트가 그대로 나타나므로 해당 파일의 공간이 실제로 지워졌는지 아니면 그대로 남아 있는지를 손쉽게 확인할 수 있습니다. 만약 텍스트 파일 말고 다른 종류의 파일을 사용해서 바이너리 코드를 그대로 보고 있다면 그게 정확하게 파일인지 뭔지 바로 파악할 수 있을까요? 그래서 빠르게 확인이 가능하도록 드라이브의 공간 대부분을 차지하도록 텍스트 파일을 크게 만든 것입니다.



참고로 이러한 사전 준비는 모두 제 메인 윈도우인 윈도우 8 에서 작업하였습니다. 보시는 것과 같이 일단 윈도우 8 에선 파티션 생성만 해두고, 실제로 테스트를 위한 포맷 작업과 데이터의 복사 등 나머지 모든 작업은 각각의 윈도우에서 진행을 하였습니다. 그리고 해당 파티션은 모든 윈도우에서 동일하게 T: 드라이브로 할당하였음을 알려드립니다.

준비는 모두 마쳤습니다. 아래부터는 실제 테스트 과정 및 그 결과입니다.

Ⅲ. 윈도우 XP - 포맷 테스트

제가 생각하기에 가장 정확한 확인이 필요한 부분은 윈도우 XP 에서의 포맷입니다. 그래서 다른 윈도우들에 비해 좀 더 다양한 프로그램들을 사용하여 테스트를 진행하였음을 미리 알려드립니다. 또한 진행하는 테스트 작업에 대한 정확한 이해를 위해 최대한 자세하게 각 과정을 설명하게 될 것입니다. 그리하여 윈도우 XP 부분은 다소 내용이 길게 느껴질 수도 있습니다. 이점 미리 양해 부탁드립니다.

1. 테스트 프로그램 및 준비

일단 제가 예전에 헥스 에디터를 통한 테스트를 진행했을 때는 WinHex 라는 프로그램을 사용했었습니다. 그러니 우선 오해의 소지가 없도록 해당 프로그램을 동일하게 사용하고, 이와 함께 동일한 종류의 HxD 라는 프로그램을 추가로 사용하였습니다. 참고로 이러한 헥스 에디터는 디스크의 섹터에 직접 접근하여 해당 섹터의 내용을 읽는 프로그램입니다.

※ 테스트에 사용된 헥스 에디터 프로그램

- WinHex 16.4 SR-5
- HxD 1.7.7.0

파일 복구 프로그램으로는 댓글에서 문제를 제기하신 분께서 사용하셨던 프로그램과 동일하게 FinalData 2.0 과 함께 해당 프로그램의 최신 버전인 FinalData 3.0 을 사용하였습니다. 이 때 FinalData 는 디스크의 섹터에 직접 접근하여 섹터 검색을 통해 파일을 복구할 수 있는 프로그램입니다. 그리하여 당연하게도 모든 파일 복구 테스트는 섹터 검색(클러스터 검색)을 통해 진행하였습니다.

※ 테스트에 사용된 파일 복구 프로그램

- FinalData 2.0 Enterprise
- FinalData 3.0 Standard

마지막으로 T: 드라이브 전체를 제로필하는 작업에는 CCleaner 에 내장된 보안 삭제 기능을 사용하였습니다.

※ 테스트에 사용된 드라이브 보안 삭제(제로필) 프로그램

- Piriform CCleaner v4.00.4064

보시는 것과 같이 헥스 에디터와 파일 복구 프로그램 모두 디스크의 섹터에 직접 접근한다는(디스크의 섹터를 직접 읽는다는) 것에서 기본적인 디스크에 대한 접근 방식은 동일합니다. 물론 저의 지식이 잘못되어 있을 수도 있습니다. 가능성은 언제나 열려 있으니까요. 아무튼, 제가 맞다면 FinalData 에서 복구가 가능하다는 것은 WinHex 나 HxD 에서도 확인이 가능하다는 것이고, WinHex 나 HxD 에서 확인이 불가능하다는 것은 FinalData 에서도 복구가 불가능하다는 것이 될테죠. 이것은 이제 아래의 실험으로 그 사실 여부가 밝혀질 것입니다.

2. 윈도우 XP - FAT32 빠른 포맷 테스트

본격적인 테스트를 위해 먼저 T: 드라이브를 FAT32 방식으로 포맷하여 준비하고 미리 준비해두었던 파일들을 복사하였습니다.

이 상태에서 T: 드라이브를 빠른 포맷하였습니다.

이렇게 빠른 포맷을 진행 한 후 먼저 WinHex 와 HxD 를 통해 직접 섹터의 모습을 살펴봤습니다. WinHex 와 HxD 에서 보이는 섹터는 동일한 영역으로 무작위로 선택한 곳입니다. 보시는 것과 같이 드라이브 공간의 대부분을 차지하고 있는 CApple.txt 파일의 일부가 보이네요. [말했지만 이렇게 섹터 영역 아무 곳이나 대충 찍어도 CApple 이라는 글자를 확인할 수 있도록 CApple.txt 라는 텍스트 파일을 크게 준비한 겁니다. 그래야 파일의 데이터가 온전히 남아 있는지 확인하는 것이 빠를 테니까요. 물론 다른 영역들도 확인해보았음을 밝힙니다.]

헥스 에디터들을 통해 파일의 데이터가 사라지지 않고 존재하고 있음을 확인하였습니다. 물론 이러한 헥스 에디터를 통해 볼 수 있는 파일이 완벽하게 남아 있는 파일이라고는 보장할 수 없습니다. 이것은 완벽하게 남아 있는 파일일 수도 있고, 포맷 과정에서 일부 데이터가 사라져 깨진 파일일 수도 있습니다.



그럼 이번엔 파일 복구 프로그램을 통해 복구를 진행해보도록 하겠습니다. 아래는 FinalData 2.0 과 FinalData 3.0 을 통해 각각 클러스터 검색(섹터 검색)을 진행한 후 나온 결과와, 그렇게 검색된 파일들을 다른 드라이브로 복구한 모습입니다.

그 결과 아쉽게도 텍스트 파일은 복구하지 못했지만, 사진 파일들은 일부 사진 파일이 깨지긴 했지만 상당량의 파일을 정상적으로 복구할 수 있음을 확인할 수 있었습니다. 참고로 이를 통해 빠른 포맷을 진행하면 제로필 작업을 진행하지 않더라도 일부 파일이 깨질 수 있음을 알 수 있습니다. 특히나 용량이 큰 파일의 경우 파일 자체가 연속된 공간에 있지 못하고 조각나 있는 경우가(단편화) 많고, 그런 경우 복구 실패율이 높은 편인데 그러한 경향이 이번 테스트에서도 나타나네요.


이번에 진행한 테스트의 결과는 아래와 같습니다.

※ 윈도우 XP 에서는 FAT32 파티션을 빠른 포맷하면 제로필을 진행하지 않는다.

3. 윈도우 XP - FAT32 일반 포맷 테스트

방금 전 빠른 포맷 테스트를 진행하였고, 그 결과 디스크에는 파일들의 흔적이 고스란히 남아 있는 것을 확인하였죠. 그를 통해 실제로 파일들을 복구할 수도 있었습니다. 그렇다면 이 상태에서 굳이 다시 새로이 셋팅하지 않고, 곧바로 일반 포맷을 진행하여 결과를 확인해도 괜찮다는 결론이 나옵니다. 어차피 데이터는 현재 있으니까요. 무슨 말인지 이해하셨으리라 믿습니다.

자 그럼 이제 아래와 같이 곧바로 T: 드라이브를 일반 포맷하였습니다.

그리고 앞서 빠른 포맷에서 확인했던 동일한 영역을 헥스 에디터를 통해 살펴 보았습니다.

헥스 에디터들을 통해 파일의 데이터가 사라지지 않고 존재하고 있음을 확인하였습니다.



마찬가지로 이번엔 파일 복구 프로그램을 통해 복구를 진행해보도록 하겠습니다. 동일하게 클러스터 검색(섹터 검색)을 진행한 후 나온 결과와, 그렇게 검색된 파일들을 다른 드라이브로 복구한 모습입니다.

사실상 빠른 포맷과 다르지 않은 결과를 보여주었습니다.


마찬가지로 결과는 아래와 같습니다.

※ 윈도우 XP 에서는 FAT32 파티션을 일반 포맷하면 제로필을 진행하지 않는다.

4. 윈도우 XP - FAT32 제로필 보안 삭제 테스트

이번엔 확실하게 제로필 작업을 진행하는 보안 삭제 프로그램을 이용하여 T: 드라이브를 깨끗하게 제로필을 해보도록 하겠습니다.

그리고 앞서의 포맷에서와 동일한 영역을 헥스 에디터를 통해 살펴 보았습니다.

헥스 에디터 상으로는 파일의 데이터가 완벽하게 사라진 것으로 보입니다.



그렇다면 실제로도 파일 복구 프로그램을 통해서는 파일을 복구할 수 없을까요?  클러스터 검색(섹터 검색)을 통해 파일 복구를 시도해보았습니다.

아무 것도 나오지 않습니다.


이를 통해 저는 다음의 두 가지를 확신할 수 있었습니다.

- 제로필이 되면 파일 복구 프로그램을 통해서는 복구를 할 수 없다.
- 헥스 에디터들이 보여준 것은 거짓이 아니다.

5. 윈도우 XP - NTFS 빠른 포맷 테스트

이러한 의문이 들 수도 있습니다. 이것은 어쩌면 파일 시스템에 따라 달리 적용될 지도 모른다고 말이죠. FAT 파일 시스템과 NTFS 파일 시스템은 근본 구조부터가 다르니 어쩌면 다른 결과가 나올 지도 모른다고 말이죠.


먼저 다시 깨끗하게 파티션을 준비하고 파일을 준비했습니다.

그리고 빠른 포맷을 진행한 후 위와 동일한 테스트 과정을 거쳤습니다.

▼ 빠른 포맷

▼ 헥스 에디터를 통해 살펴본 모습

▼ 파일 복구 테스트

빠른 포맷은 역시나 익히 알려진 것과 같습니다.

※ 윈도우 XP 에서는 NTFS 파티션을 빠른 포맷하면 제로필을 진행하지 않는다.

6. 윈도우 XP - NTFS 일반 포맷 테스트

FAT32 때와 마찬가지로 일반 포맷을 진행한 후 동일한 테스트 과정을 거쳤습니다.

▼ 일반 포맷

▼ 헥스 에디터를 통해 살펴본 모습

▼ 파일 복구 테스트

NTFS 의 일반 포맷 결과 역시 FAT32 와 동일했습니다.

※ 윈도우 XP 에서는 NTFS 파티션을 일반 포맷하면 제로필을 진행하지 않는다.

7. 윈도우 XP - NTFS 제로필 보안 삭제 테스트

이번에도 역시나 확실하게 제로필 작업을 진행하는 보안 삭제 프로그램을 이용하여 T: 드라이브를 깨끗하게 제로필을 해보도록 하겠습니다.

그리고 앞서와 포맷에서와 동일한 영역을 헥스 에디터를 통해 살펴 보았습니다.

역시나 헥스 에디터 상으로는 파일의 데이터가 완벽하게 사라진 것으로 보입니다.



그렇다면 마찬가지로 실제로 파일을 복구할 수 없을까요?  클러스터 검색을 통해 파일 복구를 시도해보았습니다.

역시나 아무 것도 나오지 않습니다.

8. 윈도우 XP 포맷 테스트를 통해서 알 수 있었던 것들

첫 째, [일반 포맷 = 제로필] 은 모든 윈도우에서 공통적으로 적용되는 내용이 아니다.

이 부분에 대해선 사과 드립니다. 그 당시 제가 전제를 잘못 잡은 것이 명확합니다. 그 결과 저는 그 어떠한 조건도 달지 않고 [일반 포맷 = 제로필] 이라는 공식을 사용하여 그 동안 많은 이야기를 진행한 오류를 범했네요. 제 생각이 많이 짧았습니다.

둘 째, 헥스 에디터가 보여주는 섹터의 내용은 거짓이 아니다.

헥스 에디터가 보여주는 내용은 섹터의 내용이 맞습니다. 그것은 마찬가지로 섹터의 내용을 직접 검색하여 파일을 복구하는 복구 프로그램의 결과와도 일치하는 것으로 알 수 있었습니다.

한 가지 헥스 에디터를 둘이나 사용하여 내용을 확인시켜 드린 것은 헥스 에디터들끼리 동일한 내용을 보여준다는 것을 확인시켜드리기 위함입니다. 사실 제가 글에서 과거엔 WinHex 를 사용하였고, 무료 프로그램인 HxD 를 소개해드린 이후로는 HxD 를 사용하고 있습니다. 앞으로의 테스트에선 HxD 를 사용할 텐데요. 지금 제가 가장 많이 사용하고 있고, 누구에게나 무료로 열려 있어서 쉽게 접근이 가능한 것은(누구나 저와 같은 테스트를 진행해볼 수 있는 것은) HxD 에 좀 더 가까우니까요. 만약 그 때는 WinHex 를 사용했으면서 이제는 왜 HxD 를 사용하느냐? 그래서 이러한 헥스 에디터들끼리 동일한 결과를 보여준다는 것을 확인시켜드릴 필요가 있다고 생각했습니다. 아무튼, 그래서 앞으로의 테스트에서는 두 헥스 에디터 중 여러분들도 쉽게 접할 수 있는 무료 헥스 에디터인 HxD 를 사용하도록 하겠습니다.



이제 남은 것은 제가 과거 글에서 그 근거의 토대로 삼았던 [헥스 에디터에서의 제로필 확인 = 실제 제로필] 이라는 내용을 좀 더 확실하게 보여드리는 겁니다. 그렇게 되면 저의 [일반 포맷 = 제로필] 이라는 주장은 완전히 틀리지만은 않은 것이 될 테니까요.

그것은 위의 윈도우 XP 에서 [빠른 포맷, 일반 포맷, 제로필] 세 가지 범주의 테스트를 통해 확인된 결과인 [헥스 에디터에서의 제로필 확인 = 파일 복구 프로그램의 파일 복구 불가] 를 재차 확인시켜 드리는 것으로 하면 충분하리라고 생각합니다. 그리고 그러한 테스트에는 역시나 가장 믿음직한 FinalData 가 적격이라고 생각합니다. 하지만 FinalData 2.0 이 공식적으로 지원하는 것은 윈도우 XP 까지입니다.

그래서 앞서의 윈도우 XP 테스트에서 FinalData 2.0 과 FinalData 3.0 의 결과가 동일함을 보여드리기 위해 파일 복구 프로그램 테스트에 일부러 서로 다른 회사의 프로그램이 아닌 동일한 회사의 동일한 제품을 사용하였습니다. 아무튼, FinalData 2.0 이 공식으로 지원하는 운영체제는 윈도우 XP 까지이니, 윈도우 7 까지 공식으로 지원하고, 더불어 윈도우 8 에서도 아무런 문제가 없는 FinalData 3.0 하나로 테스트를 진행하도록 하겠습니다.



종합하면 앞으로의 글에서는 테스트를 헥스 에디터는 HxD 로 파일 복구 테스트는 FinalData 3.0 으로만 진행하도록 하겠습니다. 한 가지 미리 밝혀둘 것이라면 FinalData 3.0 의 검색을 통해 삭제된 파일 목록으로 나온 경우엔 모두 복구가 가능했기 때문에 복구한 파일을 확인하는 스크린 샷은 생략하도록 하겠습니다. 그리고 테스트 방식과 그 중간 중간의 의미는 윈도우 XP 에서 충분히 설명을 드렸다고 판단하기에 앞으로 남은 윈도우 비스타, 7, 8 은 쭈욱 결과만 확인하는 방식으로 진행하도록 하겠습니다.

또한 CCleaner 를 통한 제로필에 대한 내용은 충분히 그 의미가 전달되었다고 판단되고, 앞으로 일반 포맷에서 제로필 작업이 진행된 경우에는 테스트에서 제외하도록 하겠습니다. [물론 다음 테스트 과정으로 넘어가기 전에 확실하게 하기 위하여 제로필 작업은 진행을 하였습니다.]

Ⅳ. 윈도우 비스타 - 포맷 테스트

1. 윈도우 비스타 - FAT32 빠른 포맷 테스트

▼ 드라이브 및 파일 준비

▼ 빠른 포맷

▼ 헥스 에디터를 통해 살펴 본 모습

▼ 파일 복구 테스트

※ 윈도우 비스타에서는 FAT32 파티션을 빠른 포맷하면 제로필 작업을 진행하지 않는다.

2. 윈도우 비스타 - FAT32 일반 포맷 테스트

▼ 일반 포맷

▼ 헥스 에디터를 통해 살펴 본 모습

▼ 파일 복구 테스트

※ 검색된 파일의 전체 용량을 보면 알겠지만 이것은 제대로된 파일을 검색한 것이 아닙니다.

※ 윈도우 비스타에서는 FAT32 파티션을 일반 포맷하면 제로필 작업을 진행한다.

3. 윈도우 비스타 - NTFS 빠른 포맷 테스트

▼ 파일 준비

▼ 빠른 포맷

▼ 헥스 에디터를 통해 살펴 본 모습

▼ 파일 복구 테스트

※ 윈도우 비스타에서는 NTFS 파티션을 빠른 포맷하면 제로필 작업을 진행하지 않는다.

4. 윈도우 비스타 - NTFS 일반 포맷 테스트

▼ 일반 포맷

▼ 헥스 에디터를 통해 살펴 본 모습

▼ 파일 복구 테스트

※ 윈도우 비스타에서는 NTFS 파티션을 일반 포맷하면 제로필 작업을 진행한다.

Ⅴ. 윈도우 7 - 포맷 테스트

1. 윈도우 7 - FAT32 빠른 포맷 테스트

▼ 드라이브 및 파일 준비

▼ 빠른 포맷

▼ 헥스 에디터를 통해 살펴 본 모습

▼ 파일 복구 테스트

※ 윈도우 7 에서는 FAT32 파티션을 빠른 포맷하면 제로필 작업을 진행하지 않는다.

2. 윈도우 7 - FAT32 일반 포맷 테스트

▼ 일반 포맷

▼ 헥스 에디터를 통해 살펴 본 모습

▼ 파일 복구 테스트

※ 검색된 파일의 전체 용량을 보면 알겠지만 마찬가지로 이것은 제대로된 파일을 검색한 것이 아닙니다.

※ 윈도우 7 에서는 FAT32 파티션을 일반 포맷하면 제로필 작업을 진행한다.

3. 윈도우 7 - NTFS 빠른 포맷 테스트

▼ 파일 준비

▼ 빠른 포맷

▼ 헥스 에디터를 통해 살펴 본 모습

▼ 파일 복구 테스트

※ 윈도우 7 에서는 NTFS 파티션을 빠른 포맷하면 제로필 작업을 진행하지 않는다.

4. 윈도우 7 - NTFS 일반 포맷 테스트

▼ 일반 포맷

▼ 헥스 에디터를 통해 살펴 본 모습

▼ 파일 복구 테스트

※ 윈도우 7 에서는 NTFS 파티션을 일반 포맷하면 제로필 작업을 진행한다.

Ⅵ. 윈도우 8 - 포맷 테스트

1. 윈도우 8 - FAT32 빠른 포맷 테스트

▼ 드라이브 및 파일 준비

▼ 빠른 포맷

▼ 헥스 에디터를 통해 살펴 본 모습

▼ 파일 복구 테스트

※ 윈도우 8 에서는 FAT32 파티션을 빠른 포맷하면 제로필 작업을 진행하지 않는다.

2. 윈도우 8 - FAT32 일반 포맷 테스트

▼ 일반 포맷

▼ 헥스 에디터를 통해 살펴 본 모습

▼ 파일 복구 테스트

※ 윈도우 8 에서는 FAT32 파티션을 일반 포맷하면 제로필 작업을 진행한다.

3. 윈도우 8 - NTFS 빠른 포맷 테스트

▼ 파일 준비

▼ 빠른 포맷

▼ 헥스 에디터를 통해 살펴 본 모습

▼ 파일 복구 테스트

※ 윈도우 8 에서는 NTFS 파티션을 빠른 포맷하면 제로필 작업을 진행하지 않는다.

4. 윈도우 8 - NTFS 일반 포맷 테스트

▼ 일반 포맷

▼ 헥스 에디터를 통해 살펴 본 모습

▼ 파일 복구 테스트

※ 윈도우 8 에서는 NTFS 파티션을 일반 포맷하면 제로필 작업을 진행한다.

Ⅶ. 결론

이상 진행한 테스트로 제가 내린 결론은 아래와 같습니다.

1. 윈도우 XP 에서는 일반 포맷 작업에 오류 검사만을 진행한다.
2. 윈도우 6.x (비스타, 7, 8) 에서는 일반 포맷 작업에 제로필 작업을 함께 진행한다.

일단 제 테스트 결과를 토대로 생각해본다면 윈도우에 내장된 일반 포맷의 작업 방식은 [윈도우 5.x -> 윈도우 6.x] 를 거치면서 변화한 것이라고 보입니다. 정확한 이유는 모르겠으나 보안 강화 측면에서 따로 제로필 유틸리티 없이 윈도우의 기본 포맷 기능만을 가지고도 제로필을 진행할 수 있도록 만든 것은 아닐까 막연히 생각할 뿐입니다. 그에 맞춰 DiskPart 의 Clean All 기능도 함께 추가되었다고 보면 그럭저럭 말은 되는 듯 합니다. 또는 단순하게 이제는 오류 검사보다는 제로필이 좀 더 효율적이라고 판단했을지도 모를테고요. 정확한 이유는 저도 모르겠습니다.

그리고 테스트에서 사용했던 FinalData 3.0 README 텍스트 파일을 확인해보면 퀵 포맷으로 포맷한 경우엔 복구가 가능하다고 설명하고 있습니다. 2.0 메뉴얼에서와 달리 일반 포맷에 대한 언급은 빠졌더군요. 아마 이것도 비스타 이후부터 변경된 포맷과 뭔가 연관이 있지 않을까 생각합니다.



제가 실수했던 것은 [일반 포맷 = 오류 검사] 라는 내용이 있었음에도, 제 테스트 결과를 너무 맹신한 나머지 그것을 너무 오래된 이야기로 치부하고 정확하게 확인하지 않은 점입니다. 실제로 컴퓨터에 관련된 지식과 기능들은 세대가 바뀌면서 이전과는 다르게 변화하는 부분들이 많고 포맷도 그러한 것들 중에 하나로 여겼습니다. 그래서 그러한 내용은 도스 시절에나 통용되던 낡은 것이고 "윈도우 시대로 넘어 오면서 바뀌었다" 라는 잘못된 판단을 내린 채 그것을 단지 그당시 제가 사용하던 윈도우 비스타와 윈도우 7 에서만 확인을 해본체 맞다고 결론을 내리고 그 이전의 설명들은 무시하고 글을 작성한 것이죠.

결국은 제가 했던 이야기들도 어쨌든 완벽하지 않은 틀린 설명이 된 것이고 많은 분들께 혼란을 주게 되었습니다. 오늘의 제 테스트가 신뢰할만하고 다른 분들께서도 저와 같은 테스트를 진행해보고 마찬가지로 같은 결과를 보인다면

[오류 검사 = 윈도우 5.x 이하 ← 일반 포맷 → 윈도우 6.x 이상 = 제로필]

이라는 새로운 결론을 내릴 수 있을 듯 합니다. 그렇다면 그에 맞춰 제 블로그의 관련된 글들에 "이것은 윈도우 비스타 이후에 적용되는 내용" 이라는 것을 보다 정확하게 언급하는 방향으로 수정을 해야 할테고요. 뭐 그렇습니다.



추가로 더 생각해보아야 하는 것은 윈도우에서 기본적으로 제공하는 포맷 기능 뿐만 아니라, 써드 파티의 다른 디스크 파티션 관리 유틸리티에서 제공하는 포맷 툴들에 대한 확인도 필요할 듯 보입니다. 그래서 일반 포맷의 "오류 검사 vs 제로필" 이라는 것이 과연 "해당 프로그램이 사용되는 윈도우의 기본 방식을 따르는 것"인지 아니면 "포맷도 어차피 하나의 프로그램이니 각각의 프로그램마다 다른 작동 방식을 보여주는 것" 인지도 확인이 필요할 듯 싶고요.



테스트가 너무 오래 걸려서 피곤한 나머지 발행하고 곧바로 뻗어버렸는데요. 한숨 자고 오니까 머리가 개운하네요. 문맥이 이상한 부분이나 불필요한 부분들, 미처 하지 못한 이야기들을 추가하여 다시 다듬었습니다. 이상입니다. ^^

★ 빠른 포맷과 일반 포맷의 차이점 - 무엇을 선택해야 하나?
★ 빠른 포맷과 일반 포맷의 차이점 - 실제 포맷 결과 비교
★ 일반 포맷이 수행하는 작업은 정확하게 무엇일까? - 오류 검사 vs 제로필