PST 가져오기 후 Outlook 날짜가 오늘로 바뀌는 이유

증상: 가져온 이메일이 전부 오늘 날짜로 표시된다

PST 가져오기를 막 완료했다고 상상해 보세요. 진행 표시줄이 100%에 도달했고, 아무 오류도 없었습니다. 그런데 받은 편지함을 열어보면... 가져온 이메일마다 오늘 날짜가 찍혀 있습니다. 2019년 메시지, 2021년 메시지, 5년 된 아카이브까지, 전부 같은 날짜입니다. 바로 가져오기를 실행한 날짜로요.

이건 표시 버그가 아닙니다. 시간대 문제도 아니에요. IMAP이 날짜 메타데이터를 처리하는 방식에서 비롯된, 문서화된 동작입니다. 그렇다고 해서 과거 이메일을 날짜별로 찾아야 하는 사람에게 재앙이 아닌 건 아니죠.

로컬 PST와 IMAP: 완전히 다른 두 세계

왜 날짜가 깨지는지 설명하기 전에, 날짜 관리 측면에서 PST 파일이 어떤 존재인지 이해해야 합니다.

PST(Personal Storage Table) 파일은 Microsoft의 독점 형식입니다. 발송 날짜, 수신 날짜, 첨부 파일, 범주, 읽음 상태 등 이메일의 모든 메타데이터를 저장합니다. 이 메타데이터는 어떤 메시징 프로토콜과도 무관하게 Outlook이 직접 관리합니다. 서버 연결 없이 Outlook에서 PST를 열면, 표시되는 날짜는 PST 파일 내부 필드에서 직접 가져옵니다. 여기까지는 문제없습니다.

문제는 이 내용을 IMAP 서버에 호스팅된 메일함으로 옮기려 할 때 발생합니다. Microsoft 365든, Google Workspace든, 일반 호스팅 업체든 마찬가지입니다. PST 세계에서 IMAP 세계로 넘어가는 순간, 규칙이 완전히 달라집니다.

IMAP APPEND와 INTERNALDATE: 문제의 핵심

IMAP에서 서버에 저장되는 각 메시지에는 두 종류의 날짜 데이터가 존재합니다:

• Date: 헤더 (RFC 2822): 메시지 내용 자체에 포함된 헤더입니다. 발신자가 메시지에 기록한 날짜예요.
• INTERNALDATE: IMAP 서버가 관리하는 메타데이터입니다. 메시지가 서버에 도착한 시점을 나타내며, Outlook이 "받은 날짜" 보기에서 메시지를 정렬할 때 바로 이 값을 사용합니다.

(이메일 원시 헤더를 직접 읽어본 적 있다면, 그게 딱히 즐거운 독서가 아니라는 걸 알 거예요. 그래도 모든 게 거기서 일어납니다.)

이메일이 정상적으로 서버에 도착하면, 메일 서버가 수신 시점을 INTERNALDATE로 자동 설정합니다. 그 결과 Outlook에 표시되는 날짜가 실제로 메시지를 받은 날짜와 일치하는 겁니다.

Outlook이 PST 파일을 IMAP 메일함으로 가져올 때는 IMAP APPEND 명령으로 각 메시지를 서버에 전송합니다. IMAP 표준은 APPEND 시 명시적인 INTERNALDATE를 전달하는 것을 허용합니다. 하지만 Outlook은 그렇게 하지 않습니다. INTERNALDATE를 지정하지 않은 채 메시지를 전송하죠. 서버는 지시가 없으면 기본 규칙을 적용합니다. INTERNALDATE를 현재 시각, 즉 가져오기 실행 시점으로 설정하는 겁니다.

결과: 이메일 8,000개를 가져오면, 8,000개 전부 오늘 날짜가 됩니다.

Outlook이 이렇게 동작하는 이유

이건 Microsoft의 실수가 아닙니다. 당시에는 합리적으로 보였을 구현상의 선택입니다. PST 가져오기의 원래 사용 사례에서 사용자는 메시지를 로컬에 보관하다가 현재 메일함으로 "가져오는" 것이었습니다. 정렬에 적합한 날짜는 원래 수신 날짜여야 하는데, Microsoft는 가져오기 작업 중 INTERNALDATE를 전달하지 않는 쪽을 택했습니다.

정확히 말하면, 이 동작은 Outlook 기본 가져오기 마법사(파일 > 열기 및 내보내기 > 가져오기/내보내기)를 통한 PST 가져오기에 해당합니다. 일부 서드파티 도구나 Exchange 관리 센터를 통한 마이그레이션 등 다른 가져오기 방법은 IMAP APPEND 구현에 따라 다르게 동작할 수 있습니다.

이 동작은 수년째 Microsoft 포럼에 문서화되어 있습니다. Outlook 2016에서도, 2019에서도, 현재 Microsoft 365 버전에서도 변하지 않았습니다. 지금 PST를 가져오는 사용자는 2015년과 똑같은 문제를 겪게 됩니다.

일반 IMAP 마이그레이션과의 차이점

흥미로운 부분이 여기입니다. PST 가져오기는 날짜가 깨지는 일반 IMAP 마이그레이션과 비슷한 결과를 만들지만, 메커니즘은 다릅니다.

BitTitan MigrationWiz나 imapsync를 쓰는 일반적인 IMAP 마이그레이션에서는 이메일이 소스 IMAP 서버에서 대상 IMAP 서버로 이동합니다. 마이그레이션 도구가 메시지를 가져와 IMAP APPEND로 다시 삽입합니다. 일부 도구는 INTERNALDATE를 올바르게 보존하고, 일부는 그렇지 않습니다. 어느 경우든 메시지에는 마이그레이션 날짜가 찍힌 Received: 헤더가 추가되어, INTERNALDATE와 무관하게 Outlook 표시에 영향을 줄 수 있습니다.

PST 가져오기의 경우 메커니즘이 더 단순합니다. 마이그레이션용 Received: 헤더가 추가되지 않습니다 (PST 파일은 중간 메일 서버를 거치지 않으니까요). 다만 INTERNALDATE가 올바른 값으로 설정되지 않을 뿐입니다. 눈에 보이는 결과는 같아도, 근본 원인은 조금 다릅니다.

이 차이는 수정 방법에도 직접적인 영향을 미칩니다. IMAP 마이그레이션과 PST 가져오기는 접근 방식이 완전히 같지 않습니다. 두 경우에 대한 자세한 설명은 IMAP INTERNALDATE 해설: 날짜가 깨지는 이유를 참고하세요.

Outlook 보기 옵션으로는 아무것도 해결되지 않는 이유

문제를 발견하면 대부분 Outlook 설정부터 뒤집니다. 그리고 실제로 유망해 보이는 옵션이 하나 있죠. "받은 날짜" 대신 "날짜"로 정렬하는 옵션입니다.

발송 날짜 정렬은 해결책이 아닙니다. 임시방편일 뿐입니다.

이유는 이렇습니다. 원본 날짜에 해당하는 메시지의 Date: 헤더를 표시하는 "날짜" 열로 정렬을 바꿔도, 여러 문제가 남습니다:

• Outlook 검색은 INTERNALDATE를 기준으로 인덱싱합니다. "2020년 1월 이메일"을 검색해도, 가져온 이메일의 INTERNALDATE가 가져오기 날짜로 되어 있으면 검색 결과에 나타나지 않습니다.
• Outlook 인터페이스의 "오늘", "이번 주", "이번 달" 폴더는 Date: 헤더가 아닌 INTERNALDATE를 기준으로 합니다.
• Outlook Web App, Gmail 등 웹 인터페이스와 모바일 클라이언트에서는 표시 날짜와 정렬이 거의 항상 서버 INTERNALDATE에 의존합니다.
• 수신 날짜 기반 자동 규칙과 필터가 올바르게 작동하지 않습니다.

간단히 말해, 보기를 바꾸면 특정 사용자의 특정 클라이언트에서 특정 구성으로는 표시가 해결됩니다. 근본적인 문제가 수정되는 건 아닙니다.

OST 재동기화도 소용없습니다

또 다른 흔한 시도는 OST 캐시를 삭제하고 서버에서 완전히 재동기화를 강제하는 겁니다. 문제가 서버가 아니라 Outlook의 로컬 캐시에서 비롯됐을 수도 있다는 생각에서요.

잘못된 방향입니다. OST 파일은 IMAP 서버 상태를 반영하는 로컬 캐시입니다. 서버의 INTERNALDATE가 잘못되어 있으면, 재동기화 후 OST도 잘못된 값을 갖게 됩니다. OST를 삭제해도 Exchange Online이나 Google Workspace 서버에 저장된 데이터는 전혀 바뀌지 않습니다. 권한은 서버에 있으니까요.

날짜를 수정하는 유일한 방법은 서버 측에서 메시지별로 메타데이터를 직접 수정하는 겁니다. 바로 여기서 수동 작업이 복잡해집니다.

규모의 문제: 이메일 1개는 간단합니다. 15,000개는 전혀 다른 이야기입니다

기술적으로, 문제를 이해한다면 메일함을 순회하면서 각 메시지의 Date: 헤더를 읽고 INTERNALDATE를 수정하는 스크립트를 작성할 수 있다고 생각할 수 있습니다. 문제를 이해하는 것과, 이메일 15,000개를 단 하나도 잃지 않고 수정하는 것은 완전히 다른 일입니다.

현장의 현실을 몇 가지 짚어보면:

• Microsoft Graph API와 Gmail API는 모두 속도 제한(rate limit)을 부과합니다. 단순한 스크립트는 429 Too Many Requests 오류를 일으키고, 수정 도중에 실행이 중단되어, 어떤 이메일이 처리됐고 어떤 이메일이 처리되지 않았는지 모른 채 부분적으로만 수정된 메일함을 남겨놓게 됩니다.
• PST 내 일부 이메일은 Date: 헤더가 잘못됐거나 없을 수 있습니다. 이런 예외 처리 없는 스크립트는 해당 메시지를 손상시키거나 조용히 건너뛸 수 있습니다.
• 서명된 이메일(S/MIME)이나 암호화된 이메일(PGP)은 무결성 제약이 추가됩니다. 메타데이터를 주의 없이 수정하면 암호화 서명이 무효화될 수 있습니다.
• 복잡한 MIME 경계를 가진 multipart/alternative 구조는 수정 작업에 예측 불가능하게 반응하기도 합니다.
• 롤백 메커니즘이 없습니다. 처리 중간에 무언가 잘못되면 초기 상태로 어떻게 돌아가나요?

테스트 이메일 10개에서 작동하는 스크립트가 50,000개 메시지를 담은 프로덕션 메일함에서는 작동하지 않습니다. 작년에 40GB짜리 PST 아카이브를 가진 고객이 Stack Overflow에서 찾은 Python 스크립트로 이걸 수정하려 했습니다. 결과: 이메일 3,000개 중복, 첨부 파일에 접근할 수 없는 메시지 200개, 그리고 2주에 걸친 수동 정리 작업이었습니다.

이 경우 Redate.io가 하는 일

Redate.io는 대상 메일함의 각 메시지 메타데이터를 분석하고, 날짜가 잘못된 이메일(PST 가져오기로 인한 것 포함)을 식별한 다음, 독자적인 수정 엔진을 통해 교정을 적용합니다. 다단계 분석 파이프라인은 각 메시지의 헤더 체인을 비교하고, RFC 적합성 검증을 거쳐 원본 날짜를 추출하며, 메시지 내용을 변경하지 않고 메타데이터를 정밀하게 수정합니다.

수정된 이메일은 하나하나 개별 검증됩니다. 원본은 최종 수정 전 30일 동안 눈에 보이는 백업 폴더에 보관됩니다. 수정은 세 가지 주요 플랫폼에서 작동합니다. Microsoft 365(Azure AD 경유), Google Workspace(도메인 위임 경유), 그리고 일반 호스팅 업체를 위한 직접 IMAP입니다.

초기 스캔은 무료입니다. 어떤 결정을 내리기 전에 영향받은 이메일이 정확히 몇 개인지, 잘못된 날짜의 분포가 어떤지 확인할 수 있습니다.

관련 글:

• Microsoft 365 마이그레이션 후 이메일 날짜 수정
• Outlook: IMAP 수신 날짜 vs 발송 날짜 차이
• 마이그레이션 후 이메일 날짜를 수정할 수 있을까요?

PST 가져오기 후 이메일 날짜가 전부 오늘로 바뀌었나요? Redate.io에서 메일함을 무료로 스캔해 조치를 취하기 전에 문제의 범위를 파악하세요.