발송 날짜 정렬은 해결책이 아닙니다

모든 포럼에서 가장 많이 나오는 조언

"마이그레이션 후 이메일 날짜가 잘못 표시된다"고 검색하면, 첫 번째 답변은 거의 항상 같습니다. "수신 날짜 대신 발송 날짜로 정렬해 보세요." 이 조언은 Microsoft 포럼, Google Workspace 도움말 스레드, Reddit 게시물, Spiceworks 토론 어디서든 볼 수 있어요. 사실은 서버 수준의 데이터 문제인데, 어느 순간부터 이게 기본 답변처럼 굳어버렸습니다.

조언 자체는 나쁜 의도에서 나온 건 아닙니다. Outlook에서 정렬 열을 "받은 날짜"에서 "보낸 날짜"로 바꾸면, 화면에 보이는 이메일 순서가 실제로 바뀌니까요. 마이그레이션 날짜로 모두 같아 보이던 메시지들이 갑자기 원래 시간 순서대로 나타납니다. 겉으로 보면 문제가 해결된 것 같습니다.

하지만 그렇지 않습니다.

왜 해결된 것처럼 보이는가

눈에 보이는 개선

사용자가 Outlook 보기를 "보낸 날짜" 정렬로 바꾸면, 받은 편지함이 즉시 올바르게 보입니다. 2020년 이메일이 2023년 이메일 앞에 나타나죠. 같은 날짜로 10,000개 이메일을 바라보던 사람에게는 정말 극적인 개선처럼 느껴집니다.

한 기기, 한 화면에서만 작동한다

이 정렬 방식은 딱 한 곳에서만 통합니다. 사용자가 변경한 특정 기기의 특정 폴더 보기에서만요. 다른 폴더로 이동하면 보기가 원래대로 돌아올 수 있고, 다른 기기에서 이메일을 확인하면 설정이 적용되지 않습니다.

실패하는 모든 이유

검색 결과에는 여전히 잘못된 날짜가 표시된다

Outlook, Gmail, Apple Mail, Thunderbird의 이메일 검색은 보낸 날짜가 아니라 수신 날짜(INTERNALDATE)를 기준으로 메시지를 색인합니다. 사용자가 "2022년 3월에 받은 이메일"을 검색하면, 검색 엔진은 INTERNALDATE를 확인하는데 거기에는 여전히 마이그레이션 날짜가 적혀 있어요. 결과는 2022년 3월 이메일 0건, 마이그레이션 날짜의 이메일 수천 건입니다.

특정 분기의 청구서를 찾는 회계 담당자나, 특정 기간의 메일 왕래를 모아야 하는 법률 담당자처럼 날짜 범위 검색을 자주 쓰는 사용자에게 이 받은 편지함은 사실상 쓸 수 없는 상태입니다. 정렬 열을 바꾼다고 검색 엔진이 사용하는 데이터가 달라지지는 않으니까요.

규정 준수 및 eDiscovery가 손상된다

Microsoft Purview, Google Vault, 그리고 서드파티 컴플라이언스 플랫폼은 INTERNALDATE를 포함한 서버 측 메타데이터를 조회합니다. Outlook에서 발송 날짜로 정렬하는 것은 이런 도구들이 가져오는 데이터에 전혀 영향을 미치지 않아요. "2023년 1월부터 3월 사이에 수신된 모든 이메일"에 대한 법적 보존 요청은 잘못된 결과를 반환합니다.

금융, 의료, 법률, 공공 부문 기관에서는 부정확한 eDiscovery 결과가 제재, 과징금, 불리한 법원 판결로 이어질 수 있습니다. 국내에서도 개인정보 보호법이나 전자금융거래법 등 규정 준수가 요구되는 상황에서 이런 오류는 심각한 리스크가 됩니다.

기기마다, 폴더마다 다시 설정해야 한다

Outlook은 보기 설정을 전역으로 적용하지 않습니다. 받은 편지함의 정렬 열을 바꿔도 보낸 편지함, 임시 보관함, 보관함, 사용자 지정 폴더에는 반영되지 않아요. 폴더마다 개별로 조정해야 하고, 설정은 로컬에 저장되기 때문에 기기마다 반복해야 합니다. 사용자 100명, 각자 기기 4대에 폴더 10개라면 보기 수정이 4,000건입니다. 누가 이걸 다 할까요?

INTERNALDATE는 여전히 잘못되어 있다

서버의 IMAP INTERNALDATE는 그대로 잘못된 상태입니다. 이는 백업 도구, 향후 마이그레이션 도구(잘못된 INTERNALDATE를 그대로 전파하게 됩니다), API 연동, 이메일 아카이빙 시스템에 모두 영향을 줍니다. 서버 수준에서 수정하지 않는 한, INTERNALDATE 문제는 계속 남아있습니다.

이메일 규칙과 필터는 수신 날짜를 기준으로 작동한다

수신 날짜 기반의 Outlook 규칙, Gmail 필터, Exchange 전송 규칙이 오작동합니다. "90일 이상 된 이메일을 보관함으로 이동" 규칙이 받은 편지함 전체를 보관하거나, 아무것도 이동하지 않을 수 있어요. 수신 날짜를 기준으로 이메일을 처리하는 Power Automate 흐름이나 Google Apps Script도 잘못된 결과를 냅니다.

일부 이메일 클라이언트는 이 기능 자체를 지원하지 않는다

모든 이메일 클라이언트가 발송 날짜 정렬을 지원하는 건 아닙니다. iOS의 Apple Mail에는 "보낸 날짜로 정렬" 옵션이 없어요. Thunderbird는 날짜 열을 Outlook과 다르게 처리합니다. Roundcube, Horde 같은 웹메일 인터페이스는 열 사용자 지정 기능이 제한적입니다.

대화 스레드가 깨진다

대화 보기를 지원하는 이메일 클라이언트는 헤더와 날짜를 기반으로 관련 메시지를 묶습니다. 수신 날짜가 잘못되면 대화 내 메시지 순서가 틀어지거나, 스레드 날짜 자체가 마이그레이션 날짜로 표시될 수 있습니다.

진짜 해결책: 서버 측 데이터를 수정하는 것

"발송 날짜로 정렬"이 실패하는 이유는 증상(잘못된 표시 순서)만 건드리고, 원인(서버 측 날짜 메타데이터 오류)은 고치지 않기 때문입니다. 진짜 해결책은 영향받은 각 이메일의 날짜 메타데이터를 서버에서 수정하는 것입니다.

서버 측 데이터가 수정되면, 모든 이메일 클라이언트에서 올바른 날짜가 표시됩니다. 검색 결과도 정확한 날짜 범위를 반환하고, 컴플라이언스 도구도 올바른 타임스탬프를 조회합니다. 규칙과 필터도 실제 수신 날짜를 기준으로 동작하고요. 기기별, 폴더별 설정이 필요 없습니다. 수정은 영구적이고 모든 곳에 적용됩니다.

Redate.io가 서버 수준 수정을 수행하는 방식

Redate.io의 독자적인 수정 엔진은 메일함(Google Workspace, Microsoft 365 또는 모든 IMAP 서버)에 연결해, 마이그레이션 "Received" 헤더가 있는 이메일을 스캔합니다. 스캔은 무료입니다.

영향받은 각 이메일에 대해, 다단계 분석 파이프라인이 수백 가지 알려진 마이그레이션 도구 시그니처를 패턴 매칭으로 식별합니다. 그런 다음 S/MIME 서명, 멀티파트 구조, 인라인 첨부 파일, 비ASCII 헤더 등 수십 가지 엣지 케이스를 처리하면서 메시지 무결성을 보존하는 정밀한 수정을 적용합니다. 수정된 모든 이메일에는 무결성 검증이 실행되고, 원본은 30일간 보이는 백업 폴더에 보관됩니다. 전체 과정은 마이그레이션 후 이메일 날짜 수정 방법 글에 자세히 설명되어 있습니다.

수정 후에는 Outlook에서 따로 설정할 것도, 기기마다 바꿔야 할 것도, 기억해야 할 임시방편도 없습니다. 날짜는 어디서나, 영구적으로 올바르게 표시됩니다.

반만 작동하는 임시방편에 의존하는 것은 이제 그만하세요. 무료 스캔을 시작해서 날짜가 잘못된 이메일이 몇 통인지 확인하고, 10통을 무료로 수정해 결과를 직접 검증해 보세요.