신정아씨의 메일이 정말 복구된 것일까요?

'되살린 戀書'...지울 수 없는 e메일? [머니투데이 | 2007-09-11]

변양균씨와 신정아씨가 주고받은 메일을 복구하여 수사가 많이 진척되고 있고, 급기야 결국 그 메일 내용으로 인해 변양균씨마저 거짓말을 한 것이 들통나 옷을 벗는 상황까지 이르렀군요. 역시 메일의 위력(?)이란...

1년하고도 8개월전, 메일과 관련해서 세상을 뒤집었던 사건이 또 있었으니, 이름하여 황우석 사태. 그때 수사기관은 아주 당연스럽게 포털 메일 서버를 압수·수색·검증했고, 형사소송법상 사법기관이 수사에 필요한 증거 채집을 위해 동원할 수 있는 가장 강력한 수단인 압수수색이 집행된, 포털을 포함한 메일 서비스 업체에서는 당연히 영장에 따라 데이터를 제공했습니다. 안 따르면 형사처벌 받으니까요 :(

웃기는 건, 그때도 그랬고, 지금도 그러는, 메일에서 뭐만 나왔다 하면 '지운 데이터까지 싸그리 줬느냐,' 또는 '메일을 지워도 안 지워지고 서버에 남은거 아니냐'라는 기자 양반들의 설레발입니다. 아주 즐겁죠. 보면 볼수록 웃음만 나옵니다. 물론 사회부 기자들이 - 아 이번에는 정치부 기자들도 있으려나요 - 관련 분야에 대한 지식이 아무래도 부족할 수 밖에 없다는 것을 감안하더라도, 재밌는걸요. :) 뭐 하긴, 관련 분야에 대한 지식이 있다고 하더라도 메일 서비스의 구조가 어떻게 되어있는지까지 모두 알기는 어려우니까(전문 분야가 아니니까요), 인정합니다.

아웃룩이나 아웃룩 익스프레스, 또는 썬더버드를 이용하시는 분들은 잘 아실 것이라 생각됩니다만, 메일 유저 에이전트(MUA·간편하게 메일클라이언트라 통칭)은 메일 박스를 관리할 때 디렉토리 구조가 아닌 파일 구조로 접근하게 됩니다. DB? 오우, 물론 아니죠. 메일클라이언트를 실행해보시면 받은메일함, 보낸메일함, 지운메일함 등으로 메일 박스가 나뉘어져있는 것을 보실 수 있을겁니다. 썬더버드의 예를 들어볼까요?

아, 참고로 이 포스팅은 일반 사용자를 대상으로 하는 일반론이기 때문에, 어떤 메일 시스템이나 메일클라이언트에서 아래 내용과 다르게 처리한다고 해서 반론하실 필요는 없습니다. 예외까지 다 따지게 되면 피곤해지잖아요 :)

위 이미지를 보시면, Gmail 계정에 대해 받은편지함, 임시보관함, 보낸편지함, 지운편지함 등으로 메일 박스가 나뉘어져있는 것을 확인하실 수 있습니다. 그럼 이것이 썬더버드의 프로필 디렉토리에서는 어떻게 나뉘어져있을까요?

이런 식으로 각 메일 박스마다 파일로 구분하는 것을 확인할 수 있습니다. 받은편지함은 Inbox, 보낸편지함은 Sent, 임시보관함은 Drafts 이런 식으로 말이죠. 왜 한개 한개 메일을 파일로 저장하지 않고 한개 메일 박스를 한개의 파일로 저장할까요?

위 스크린샷에서 MLB라는 확장자없는 파일을 보시면 용량이 3.11메가인 것으로 확인하실 수 있습니다. 실제로 저 메일 박스 내에는 172통의 메일이 저장되어있습니다. 오래 쓰고 많이 보관한 메일 박스일수록 저 파일 크기가 커지고, 저장되어있는 메일 수량도 많겠죠?

만약 172통의 메일을 모두 한개 한개의 메일 파일(아웃룩 익스프레스에서 사용하는 eml 형식도 괜찮겠죠)로 나눈다면, 용량은 거의 동일할겁니다. 어차피 메일 원문은 텍스트 파일이니까요(eml 파일은 첨부파일이 붙어있더라도 메모장 같은 텍스트 에디터에서 그냥 열리는 텍스트 파일입니다). 그러나 용량은 동일하더라도 속도가 떨어집니다. 하드디스크라는 물리적 작동을 요하는 매체에 저장되어있기 때문입니다.

하드디스크가 아무리 엑세스 타임이 빠르고 전송 속도가 빠르더라도 결국 플래터가 회전을 하고 암(Arm) 끝에 달린 헤드가 해당 데이터가 저장되어있는 플레터의 섹터를 찾아 읽고 쓰기를 하는, 물리적 동작에 따른 시간 지연을 배제할 수 없습니다. SATA2라도, SCSI라도 마찬가지죠. 거기에 하드디스크는 기본적으로 무작위 접근 저장(랜덤 액세스) 방식이니, 찾아야할 데이터량이 많으면 많을수록 탐색 시간의 지연이 누적되면 속도는 엄청나게 떨어질 수 밖에 없습니다.

저 메일 박스에야 겨우 172통의 메일이 들었다지만, 오래 쓰는 경우 한 메일 박스에 1천통이 넘는 경우가 없을 수 없는데, 1천통을 전부 탐색하는데 걸리는 시간 지연은 프로그램 신뢰도에 지대한 타격을 줍니다. 그런 비효율적인 작동을 하는 것보다, 한 개의 메일 박스를 한 개의 파일로 만들어서 빠른 시간내로 사용자가 데이터에 접근하게 하는 방식이 훨씬 이치에 맞을겁니다. 거기에 메일은 기본적으로 텍스트(첨부파일은 인코딩해서 붙여놓습니다)이기 때문에, 메일클라이언트에서 압축 기능을 지원한다면 첨부파일이 왕창 붙어있더라도 파일 크기를 절반 이하로 줄일 수 있습니다. 읽을때 압축 해제를 해야하긴 하지만, CPU 처리 속도가 좋아졌으니 무시할 정도죠.

메일클라이언트만 얘기를 주욱 했는데, 기본적으로 웹메일들도 마찬가지입니다. 아무리 속도가 빠른 서버용 SCSI 하드디스크를 사용한다 하더라도 메일을 각각 한 개의 파일로 만들어 저장하는 것은 기본적으로 용량 낭비 및 속도 저하의 주원인이 됩니다. 페이지가 조금만 늦게 열려도 컴플레인이 쏟아지는 웹서비스에서, 속도 저하는 용납할 수 없는 팩트요, 비용 절감을 위해 몇개월 이용 안하면 서비스를 에이징(aging)시켜 계정 및 데이터를 삭제까지 하는 마당에 스토리지 장비에 돈이 들어가야하는 용량 낭비 또한 절대 용서받지 못할 녀석입니다. 그래서, 대부분의 메일 서비스 업체에서는 한 메일 박스를 한 개의 파일로 처리합니다.

자, 이런 상황에서, 한 개의 파일이라 함은, 메일을 수신하거나 삭제할 경우 메일 박스 목록을 업데이트하기 위해 해당 파일을 수정하고 저장을 해야한다는 것을 뜻합니다. 물론 논리적 위치는 전혀 변동이 없고, 물리적 섹터 위치도 변동이 없다는 것입니다(물론 섹터 점유가 더 늘어나거나 줄어들겠지만). 그렇다면 이 얘기는 곧, '한 개의 메일 박스를 한 개의 파일로 관리하는 경우 기사에서 얘기한 것처럼 삭제한 메일이 남아있을 수 없다'라는 얘기가 되겠습니다. 간단한 예로, 메모장에서 간단한 텍스트 파일을 작성해서 저장한 다음, 수정해서 다시 저장하고 난 뒤에 파이널 데이터 등의 복구 프로그램으로 한번 처음의 텍스트 파일을 검색해보세요. 안 나옵니다. 글쎄요, 수사기관에서 사용하는 프로그램이 얼마나 대단한 프로그램인지는 모르겠습니다만, 기본적으로 섹터를 일일히 검색해서 데이터의 조각을 찾아낸다는 원리는 차이가 없을텐데, 무언가 특별한 것이 있나봅니다.

그래서 이번 신정아씨 메일 복구라는 상황에 대해서 저는 이런 것이 가능하다고 봅니다.

1. 신정아씨가 아웃룩이나 아웃룩 익스프레스 등의 메일 클라이언트를 사용한다는 가정하에,
   - 메일 클라이언트가 사용하는 데이터 파일을 신정아씨가 직접 삭제했다면 복구 가능
   - 단순히 메일 클라이언트 내에서 저장되어있는 메일을 삭제했다면 복구 불가능

2. 사용하지 않는다는 가정, 즉, 웹메일만 사용한다는 가정하에,
   - 웹메일내 삭제 기능을 이용해서 메일을 삭제했다면 복구 불가능
   - 신정아씨가 메일을 일일히 텍스트로 저장하거나, 메일 서비스에서 제공하는 백업 기능을 이용해서 PC의 하드디스크에 저장해두고, 웹메일내 삭제 기능을 이용해서 메일을 삭제했다면 PC 하드디스크에 남아있는 데이터 또는 복구한 데이터를 이용해서 복구 가능(이 경우에도 웹메일쪽에서는 복구 불가능)

그러면, 복구 불가능이었을 때 - 수사기관으로써는 증거 채집상 최악의 상황이겠죠 - 검찰이 확보한 100여통의 메일은 어떻게 된 것일까요? 뭐, 그건 저도 모르겠군요. 아마 나중에 최종 수사 결과가 나오더라도 어떻게 했는지는 얘기 안할겁니다. 차후 수사에 막대한 지장이 생길테니. :) 그리고 전 지금 언론에서 떠들어대는 "어떻게 복구했을까"라는 내용에 대해서는 위에 설명한 연유로 인해 전혀 신뢰를 보내지 않습니다.

참고로, 위에 설명한 신정아씨 메일 복구 상황에서 얘기한 바와 같이, 웹메일은 한번 삭제하면(휴지통까지 비우면) 그걸로 끝입니다. 백업본요? 삭제를 직접 했다는 것은 더 이상 그 메일이 필요하지 않다는 사용자의 의지 표명이고, 그렇다면 메일 서버에서도 구태여 그 메일을 남겨둘 필요도 없을 뿐더러 개인정보 침해에 해당할 수 있습니다. 아주 말끔하게 지워져버리니까(메일 박스 파일을 덮어써버리니까) 걱정 안하셔도 되고, 또 주의하셔야합니다. 삭제되면 못 살리니까요. 낙장불입(落張不入)이라고도 하죠? :) ⓣ