새 Outlook: 마이그레이션 후 날짜가 잘못 표시되는 진짜 이유

두 가지 Outlook, 같은 이메일에 대한 두 가지 동작

최근 Microsoft 365로 메일함을 마이그레이션했는데 일부 사용자들이 오래된 이메일이 모두 같은 날짜(마이그레이션 날짜)로 표시된다고 불평한다면, 아마 이상한 점을 눈치챘을 거예요. 클래식 Outlook을 쓰는 사용자는 읽기 창에서 올바른 날짜가 보이는 경우가 있는데, 새 Outlook for Windows를 쓰는 사용자는 항상 마이그레이션 날짜만 표시되는 거죠. 같은 메일함, 같은 이메일인데 결과가 다릅니다.

엄밀히 말하면 버그가 아니에요. 이건 IMAP 마이그레이션 후 날짜가 표시되는 방식에 직접적인 영향을 주는 아키텍처 설계 결정이에요. 무슨 일이 일어나는지 이해하려면 이메일 헤더와 IMAP 프로토콜의 세부 사항을 들여다봐야 해요. 가벼운 읽을거리는 아니지만, 왜 클라이언트 측 조작으로는 문제를 해결할 수 없는지 이해하는 데 꼭 필요합니다.

IMAP INTERNALDATE: 진짜 원인

이메일이 IMAP 서버에 저장될 때, 두 종류의 날짜가 공존하며 서로 혼동되지 않아요.

첫 번째는 RFC 2822에서 정의한 Date: 헤더예요. 메시지 자체에 기록된 날짜로, 발신자가 이메일을 보낼 때 설정한 날짜입니다. 메시지 본문의 일부이기 때문에 이메일이 어떤 경로를 거치더라도 절대 바뀌지 않아요.

두 번째는 INTERNALDATE입니다. 메시지 외부에서 IMAP 서버가 관리하는 메타데이터예요. 서버가 메시지를 저장한 날짜를 나타내죠. 정상적인 마이그레이션에서는 제대로 된 도구가 원래 INTERNALDATE를 보존해요. 하지만 잘못 설정된 마이그레이션이나 이 메타데이터를 제대로 처리하지 못하는 도구를 쓰면, INTERNALDATE가 마이그레이션 당일 날짜로 초기화됩니다. 결과적으로 마이그레이션된 모든 이메일이 서버 입장에서는 같은 수신 날짜를 갖게 돼요.

(참고로, imapsync나 MigrationWiz 로그를 읽어보신 분이라면 INTERNALDATE를 보존하려는 특정 옵션이 있다는 걸 아실 거예요. 이 옵션이 항상 작동하지는 않고, 일부 대상 서버는 이를 아예 무시하기도 합니다.)

클래식 Outlook: 날짜를 읽는 방식

클래식 Outlook, 즉 로컬에 설치되는 COM 버전(Outlook 2016, 2019, 2021 및 Microsoft 365 Apps 데스크톱 클라이언트)은 메시지 목록에 표시할 날짜를 결정하는 데 좀 더 복잡한 메커니즘을 사용해요.

보낸 편지함 이메일에는 Date: 헤더를 사용해요. 받은 이메일에는 우선 서버의 INTERNALDATE를 사용하지만, 특정 맥락(OST 캐시가 관여하거나 읽기 창에 처음 표시될 때)에서는 Received: 헤더 체인을 읽어 대략적인 원래 날짜를 재구성하기도 합니다.

그래서 이런 일관성 없는 동작이 나타나는 거예요. 클래식 Outlook은 읽기 창에서 올바른 날짜를 표시하는 경우가 있는데, 상세 미리보기용으로 메시지 원본 Date: 헤더를 읽기 때문이에요. 이메일 목록 자체는 여전히 잘못된 INTERNALDATE를 사용하고 있지만요. 단, 이건 신뢰할 수 없는 동작이고 아무것도 고치지 않아요. 정렬은 여전히 깨져 있고, 날짜 검색도 여전히 잘못된 결과를 냅니다.

새 Outlook: 완전히 다른 아키텍처

2023년 말부터 단계적으로 배포된 새 Outlook for Windows는 더 이상 COM 애플리케이션이 아니에요. 본질적으로 Outlook on the web(OWA)과 같은 코드베이스를 기반으로 한 프로그레시브 웹 앱(PWA)입니다. 이 재설계는 깊은 함의를 가져요.

새 Outlook은 날짜 표시를 Microsoft 365 API에 완전히 위임해요. Received: 헤더를 직접 읽지 않고, 헤더 체인을 파고들어 원래 날짜를 찾으려 하지도 않으며, 클라이언트 측에서 재구성을 시도하지도 않습니다. 그냥 서버가 반환하는 값, 즉 INTERNALDATE를 표시할 뿐이에요.

결과적으로, 마이그레이션 중 INTERNALDATE가 잘못됐다면 새 Outlook은 망설임 없이 예외 없이 모든 해당 이메일에 마이그레이션 날짜를 표시해요. 클래식 Outlook보다 일관되고 예측 가능한 동작이지만, 마이그레이션 문제를 즉시 눈에 띄게 만들어 무시할 수 없게 합니다.

금요일 저녁에 300개 메일함을 마이그레이션한 관리자는 월요일 아침에 새 Outlook 사용자 전원의 이메일 보관함 전체가 지난 주말 날짜로 표시된다는 사실을 알게 돼요. 티켓은 금방 쏟아집니다.

클라이언트 측 임시방편이 효과 없는 이유

많은 관리자들이 문제가 서버 데이터에 있다는 걸 깨닫기 전에 클라이언트 측 해결책을 시도해요. 자주 시도되는 방법들과 왜 실패하는지 정리했어요.

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

Outlook에서 발송 날짜로 정렬하면 메시지의 Date: 헤더를 사용하는데, 이 헤더는 손상되지 않았어요. 그러니 이 정렬은 작동할 수 있어요. 하지만 이건 임시방편이지 해결책이 아닙니다. 날짜 검색은 여전히 깨져 있고, 날짜 기반 규칙도 사용할 수 없어요. 무엇보다 사용자가 폴더마다, 메일함마다 수동으로 재설정해야 해요. 300개 메일함에서 이건 비현실적이에요. 발송 날짜 정렬은 해결책이 아니에요. 최종 사용자들은 왜 습관을 바꿔야 하는지 이해하지 못합니다.

Outlook 캐시 삭제 또는 프로필 재생성

이 방법은 서버 측 INTERNALDATE에 전혀 영향을 주지 않아요. 프로필을 다시 만들면 Outlook이 서버에서 이메일을 다시 동기화하면서 똑같이 잘못된 메타데이터를 가져옵니다. 캐시가 문제가 아닌 거죠.

대신 OWA 사용하기

OWA와 새 Outlook은 같은 데이터베이스를 공유해요. Exchange Online 서버에서 INTERNALDATE가 잘못됐다면 OWA도 정확히 같은 잘못된 날짜를 표시합니다. 클라이언트를 바꿔도 데이터는 바뀌지 않아요.

문제는 서버에, 각 메시지의 메타데이터 안에 있습니다. 서버에 저장된 데이터를 클라이언트 측 작업으로 수정할 수는 없어요.

Received 헤더의 함정: 왜 모든 걸 복잡하게 만드나

마이그레이션 도구가 IMAP을 통해 한 서버에서 다른 서버로 이메일을 복사할 때, 대상 서버는 자동으로 체인 맨 위에 Received: 헤더를 추가해요. 삽입 날짜와 시간을 함께요. 이건 RFC를 준수하는 SMTP 및 IMAP 서버의 정상적인 동작이에요.

이 헤더들은 이메일이 거쳐온 경로의 역순으로 쌓여요. 가장 최근 것이 맨 위에 있죠. 일부 메일 클라이언트는 첫 번째 Received: 헤더를 읽어 수신 날짜를 추정하는데, 그러면 원래 날짜가 아니라 마이그레이션 날짜가 나와요.

한 가지 중요한 점: 이 동작은 특정 도구에만 국한되지 않아요. BitTitan MigrationWiz, CloudM, imapsync, GSMMO, 그리고 두 Thunderbird 클라이언트 간의 수동 IMAP 복사까지 모두 같은 결과를 낳아요. 메시지 안의 원본 Date: 헤더는 그대로 남아 있어요. 바로 이 점이 기술적으로 수정을 가능하게 하는 근거예요. 하지만 INTERNALDATE는 서버가 관리하는 별도의 메타데이터로, 클라이언트 측에서 단순히 메시지 헤더를 조작하는 것으로는 수정할 수 없어요.

이 메커니즘에 대해 더 알고 싶다면 IMAP INTERNALDATE 해설: 날짜가 깨지는 이유 문서에서 서버별 메타데이터 처리 방식을 자세히 설명하고 있어요.

Microsoft 365에서 이 문제를 일으키는 마이그레이션 도구

자주 나오는 질문이 있어요. 모든 마이그레이션 도구가 이 문제를 일으키나요?

짧은 답변은, 설정과 대상 플랫폼에 따라 다르다는 거예요. Exchange Online / Microsoft 365에서는 서버가 INTERNALDATE 처리에 특히 까다로워요. 보존을 시도하는 도구들도 실패하는 경우가 있는데, API Graph와 EWS(Exchange Web Services)가 사용하는 삽입 경로에 따라 동작이 달라지기 때문이에요.

BitTitan MigrationWiz는 Microsoft 365 마이그레이션에서 가장 많이 쓰이는 도구 중 하나이고, 날짜 문제가 가장 잘 문서화된 도구이기도 해요. Microsoft 365에서 BitTitan MigrationWiz 마이그레이션 날짜 수정 페이지에서 주의해야 할 특정 설정을 다루고 있어요. CloudM과 imapsync는 각각의 특이 사항이 있는데, Microsoft 365에서 CloudM Migrate 마이그레이션 날짜 수정과 Microsoft 365에서 imapsync 마이그레이션 날짜 수정에서 각각 확인할 수 있어요.

이 모든 도구의 공통점은 원본 Date: 헤더가 마이그레이션 후에도 살아남는다는 거예요. 수정이 가능한 것도 바로 이 때문이에요.

직접 만든 스크립트가 여기서 위험한 이유

문제를 이해하다 보면 해결책이 간단해 보이는 착각이 들 때가 있어요. 프로덕션 규모에서는 절대 그렇지 않습니다.

Exchange Online에 저장된 이메일의 메타데이터를 수정하는 건 간단하지 않아요. Microsoft의 Graph API는 엄격한 요청 제한이 있어요(야간 배치 처리 중 429 Too Many Requests 오류는 금방 발생해요). S/MIME 서명 이메일이나 PGP 암호화된 이메일은 서명이 무효화되지 않도록 특별한 주의가 필요해요. 용량이 큰 첨부 파일이 포함된 멀티파트 구조는 네트워크 타임아웃에 제약을 더해요. 무엇보다, 이메일 하나하나마다 내용이나 첨부 파일이 변경되지 않았는지 어떻게 검증할 건가요?

테스트용 이메일 50개에서 잘 돌아가는 스크립트가 8년치 기록이 담긴 이메일 40,000개짜리 메일함에서도 같은 방식으로 동작하지 않아요. 메시지 수가 늘어날수록 엣지 케이스가 문제를 일으킬 확률이 높아지고, 롤백 메커니즘 없이 중간에 오류가 발생하면 메일함이 불일치 상태로 남게 됩니다.

더 자세한 내용은 Microsoft 365 마이그레이션 후 이메일 날짜 수정에서 가용한 옵션들을 종합적으로 확인해 보세요.

Redate.io가 실제로 하는 일

각 사용자는 자신의 Microsoft 계정으로 로그인하고, Redate.io는 그 로그인이 부여하는 권한만으로 해당 메일함을 엽니다(비밀번호는 저장하지 않아요). 날짜가 잘못된 이메일을 무료로 스캔한 다음, 식별된 메시지에 독자적인 수정 엔진을 적용합니다. 다단계 분석 파이프라인은 수백 개의 알려진 마이그레이션 도구 서명과의 패턴 매칭, RFC 준수 검증, 헤더 체인 분석을 통해 올바른 날짜 메타데이터를 재구성해요.

수정된 이메일은 하나하나 개별적으로 검증돼요. 원본 메시지는 삭제되지 않고, 사용자의 메일함 안에 있는 눈에 보이는 백업 폴더에 그대로 보관됩니다. 가격 모델은 메일함당 일회 결제 방식으로, 구독이 없어요.

서버 데이터가 실제로 수정되기 때문에, 새 Outlook도 올바른 날짜를 표시하게 됩니다. 감추는 게 아니에요.

새 Outlook에서 영향받은 메일함이 있나요? Redate.io에서 무료 스캔을 시작해서 어떤 조치를 취하기 전에 정확히 몇 개의 이메일이 영향받았는지 확인해 보세요.