오래된 이메일이 모두 같은 날짜로 표시되는 이유

증상: 오래된 이메일이 모두 같은 날짜로 묶여 있어요

어느 날 아침 Outlook, Gmail, 또는 Apple Mail을 열었더니 뭔가 이상합니다. 수백, 혹은 수천 개의 오래된 이메일이 모두 같은 날짜로 표시되어 있어요. 며칠 전이나 몇 주 전 날짜로요. 2021년, 2019년, 2016년에 받은 메시지들이 마치 어제 수신한 것처럼 보입니다. 날짜 정렬은 아무 의미가 없어졌고, 작년에 받은 중요한 이메일을 찾으려면 전부 같은 날 도착한 것처럼 보이는 수천 개의 메시지 더미를 뒤져야 합니다.

새로 받은 이메일은 날짜가 정상으로 표시돼요. 오래된 메시지만 영향을 받은 거죠.

도대체 무슨 일이 있었던 걸까요?

첫 번째 반응: 소프트웨어 탓을 하게 됩니다

자연스럽게 버그를 의심하게 됩니다. Outlook이 충돌했거나, 업데이트가 잘못됐거나, 파일이 손상됐다고요. 그리고 여기서부터 긴 여정이 시작됩니다. "Outlook 날짜 버그"를 검색하면 OST 파일, SCANPST.exe, Outlook 프로필 초기화 방법을 이야기하는 포럼 글들이 나오죠.

두 시간쯤 이것저것 시도해봐도 문제는 그대로예요.

사실 SCANPST는 로컬 Outlook 데이터 파일을 복구하는 도구입니다. 특정 파일 손상은 고칠 수 있지만, 메일 서버에 저장된 데이터는 건드리지 않아요. 즉, OST 파일을 완벽하게 복구해도 날짜는 여전히 잘못된 채로 남습니다. 문제가 내 컴퓨터에 있는 게 아니니까요.

문제는 서버에 있는 이메일 자체에 있습니다.

실제로 무슨 일이 있었나: 마이그레이션

거의 모든 경우, 이 증상은 이메일 마이그레이션 이후에 나타납니다. 회사가 기존 시스템에서 Google Workspace나 Microsoft 365, 또는 새 서버로 전환했을 때요. 누군가가 모든 이메일을 한 곳에서 다른 곳으로 옮기는 도구를 사용한 거예요.

이 사실을 몰랐을 수도 있고, 알았더라도 날짜 문제와 연결 짓지 못했을 수 있어요. 충분히 이해할 수 있습니다.

마이그레이션 도구들은 엄청난 작업을 수행합니다. 수천 개의 메시지, 폴더 전체, 첨부파일까지 복사하죠. 그런데 여기에 꽤 교묘한 부작용이 있어요. 이메일이 한 서버에서 다른 서버로 옮겨질 때, 도구가 "Received:"라는 기술적 헤더 항목을 이메일에 추가합니다. 이 항목에는 메시지가 새 서버에 도착한 시각, 즉 마이그레이션 날짜가 기록되어요.

바로 여기서 문제가 시작됩니다.

이메일 클라이언트가 날짜를 결정하는 방법

이메일에는 사실 여러 개의 날짜 정보가 기술 데이터 안에 숨어 있습니다. 원래 발송 날짜(우리가 보통 보는 날짜)도 있고, 메시지가 인터넷을 통해 이동하는 각 단계를 기록한 "Received:" 헤더들도 있어요.

(이메일에서 "원본 보기" 또는 "전체 헤더 보기"를 클릭해본 적 있다면, 도무지 알 수 없는 텍스트 덩어리 같은 줄들을 보셨을 겁니다. 바로 그게 이 헤더들이에요.)

정상적인 상황에서는 이메일 클라이언트가 가장 최근의 "Received:" 헤더를 보고 표시할 날짜를 결정합니다. 이 방식은 완벽하게 작동해요. 마지막 "Received:"는 항상 발송 후 몇 초 만에 내 받은편지함에 도착한 시각에 해당하니까요.

그런데 마이그레이션 이후에는 이 로직이 역효과를 냅니다. 마이그레이션 도구가 맨 위에 새로운 "Received:" 헤더를 추가하면서 여기에 전송 날짜를 기록한 거죠. 이메일 클라이언트는 이 헤더를 제일 먼저 읽고, 마이그레이션 날짜를 표시해버려요. 원래 발송 날짜는 여전히 이메일 데이터 안 더 아래쪽에 온전히 남아있지만, 클라이언트는 첫 번째 헤더에서 멈추기 때문에 그걸 보지 못합니다.

결과적으로 8,000개의 이메일이 전부 어느 화요일 11월에 도착한 것처럼 보이게 되는 거예요.

어떤 도구들이 이 문제를 일으키나요?

주요 마이그레이션 도구들은 모두 이런 동작을 합니다. BitTitan MigrationWiz, CloudM, imapsync, GSMMO(Google이 Outlook에서 마이그레이션할 때 제공하는 무료 도구), 그 외 여러 도구들이 모두 마찬가지예요. 이게 이 도구들의 결함이라고 보기는 어렵습니다. 메시지가 서버 간에 전송될 때 이 헤더를 추가하는 게 이메일 프로토콜의 기술적 동작 방식이에요.

문제는 사용자에게 이런 일이 일어난다고 아무도 알려주지 않는다는 점입니다.

최근 회사의 이메일 시스템이 바뀌었거나 IT팀이 "클라우드 마이그레이션"을 진행했다면, 십중팔구 이게 원인입니다. 영향을 받은 날짜들을 확인해보세요. 전부 비슷한 시기에 몰려 있나요? 그렇다면 그 시기가 마이그레이션이 진행된 때입니다.

피해야 할 잘못된 해결책들

포럼에서 자주 보이는 방법들인데, 실제로는 효과가 없어요.

SCANPST로 데이터 파일 복구하기

앞서 언급했듯이, SCANPST는 컴퓨터에 저장된 로컬 Outlook 파일(.pst 또는 .ost 파일)을 복구합니다. 서버의 이메일은 수정하지 않아요. 복구가 끝나도 이메일의 날짜는 여전히 잘못 표시됩니다. 날짜 문제는 이메일 자체에 있는 것이지, 로컬 파일에 있는 게 아니니까요.

Outlook 프로필 다시 만들기

같은 논리입니다. Outlook 프로필을 새로 만들면 로컬을 초기화한 다음 서버에서 모든 이메일을 다시 다운로드하는 것과 같아요. 다시 다운로드한 이메일들은 전과 똑같이 잘못된 날짜를 갖게 됩니다. 재설정하느라 시간만 낭비한 셈이죠.

"수신 날짜" 대신 "발송 날짜" 기준으로 정렬하기

일부 포럼에서는 Outlook의 정렬 기준을 수신 날짜에서 발송 날짜로 바꿔보라고 합니다. 경우에 따라 도움이 될 수도 있지만... 항상 그런 건 아니에요. 그리고 다른 소프트웨어, 다른 기기, 또는 같은 메일함을 함께 쓰는 다른 사람들에게는 아무 효과가 없습니다. 근본 원인은 그대로 남아 있어요. 발송 날짜로 정렬하는 건 해결책이 아니라 임시방편일 뿐입니다.

이메일 소프트웨어 재설치

아니요. 이메일은 소프트웨어가 아니라 서버에 있습니다. Outlook, Gmail, Apple Mail, Thunderbird를 재설치해도 온라인에 저장된 데이터는 전혀 바뀌지 않아요.

좋은 소식: 원래 날짜는 아직 살아있습니다

여기서 중요한 점이 있습니다. 수정을 가능하게 만드는 사실이에요. 각 이메일의 원래 발송 날짜는 삭제되지 않았습니다. 여전히 이메일 안에, "Date:"라는 헤더에 고스란히 남아있어요. 이 헤더는 발신자가 선택한 발송 날짜를 담고 있습니다. 이건 모든 마이그레이션 도구들이 지키는 이메일 표준(RFC 2822라는 기술 규격으로 정의된)이에요. 이걸 수정하는 건 표준의 심각한 위반이 되니까요.

다시 말해, 2022년 3월 14일에 받은 이메일이 있다면, 그 이메일 데이터 어딘가에는 아직도 그 날짜가 들어있습니다. 클라이언트가 먼저 보여주는 날짜가 아닐 뿐이죠.

바로 이것이 수정을 가능하게 합니다. 데이터가 손실된 게 아니에요. 메타데이터를 읽는 방식의 문제인 겁니다. 이메일 클라이언트가 잘못된 날짜를 읽고 있지만, 올바른 날짜는 항상 거기 있었어요.

직접 수정하려 하면 안 되는 이유

IT 담당자가 스크립트를 짜서 해결할 수 있지 않을까 생각하실 수 있어요. 무슨 일이 일어났는지 이해하는 건 한 가지고, 수천 개의 이메일을 하나도 잃지 않고 깔끔하게 수정하는 건 전혀 다른 문제입니다.

이메일은 단순한 텍스트 파일이 아니에요. 첨부파일, 디지털 서명, 복잡한 형식으로 인코딩된 콘텐츠가 포함될 수 있습니다. 이런 메시지의 메타데이터를 구조를 깨뜨리지 않고 수정하려면 수십 가지 예외 상황을 처리해야 해요. 전자서명 메시지(S/MIME), 암호화된 이메일(PGP), 비표준 인코딩, 멀티파트 구조... 테스트용 이메일 20개에서 잘 작동하는 스크립트가 15,000개짜리 운영 메일함에서는 제대로 작동하지 않을 가능성이 매우 높습니다. 그리고 뭔가 잘못됐을 때 어떻게 이메일이 손상되거나 유실되지 않았다고 확인할 수 있을까요? 직접 만든 스크립트로는 불가능해요.

각 이메일에 대한 개별 백업 및 검증 메커니즘이 없다면, 부수적인 피해가 발생할 위험은 실제로 존재합니다.

Redate.io가 하는 일

Redate.io는 바로 이 문제를 위해 설계된 서비스입니다. 메일함(Google Workspace, Microsoft 365, 또는 IMAP 서버)에 연결해 마이그레이션으로 날짜가 변경된 이메일을 식별하고, 전체 헤더 체인을 분석해 각 메시지의 날짜 메타데이터를 재구성하는 독점 수정 엔진으로 이를 교정합니다.

수정된 이메일은 각각 개별적으로 검증됩니다. 원본은 30일 동안 눈에 보이는 백업 폴더에 보관돼요. 문제가 생기면 언제든 되돌릴 수 있습니다.

초기 스캔은 무료입니다. Redate.io가 메일함을 분석해서 어떤 결정을 내리기 전에 몇 개의 이메일이 영향을 받았는지 정확히 보여줘요. 예상치 못한 상황은 없습니다.

요금은 수정할 이메일 수량에 따른 일회성 결제 방식입니다. 구독이 아니에요. 한 번 결제하면 문제가 해결됩니다.

결정하기 전에 피해 규모를 먼저 파악하고 싶으신가요? Redate.io에서 무료 스캔을 시작하면 몇 분 안에 영향받은 이메일 수를 확인할 수 있어요.