공유 호스팅에서 Microsoft 365 마이그레이션: 숨겨진 날짜 오류

아무도 알려주지 않은 문제

OVH, Infomaniak, Ionos 또는 o2switch에서 Microsoft 365로 메일함 마이그레이션을 막 완료했다고 가정해 보세요. EAC(Exchange Admin Center) 마이그레이션 마법사가 밤새 돌아갔고, 모든 표시등이 초록색이고, 메일함에는 이메일이 가득 찼습니다. 월요일 아침, 첫 번째 티켓이 들어옵니다. "예전 이메일이 전부 오늘 날짜로 표시돼요." 그 다음 또 한 장. 그리고 열 장.

이건 Microsoft 365의 버그가 아닙니다. 우연도 아닙니다. IMAP 마이그레이션의 구조적인 결과입니다. 공유 호스팅에서 마이그레이션한 경우라면 이 문제는 일반적인 마이그레이션보다 두 배로 심각한 경우가 많습니다. 이유를 설명해 드릴게요.

IMAP이 날짜를 처리하는 방식 (그리고 어디서 어긋나는가)

IMAP 서버에 저장된 이메일에는 두 가지 종류의 날짜 정보가 있습니다. 하나는 메시지 본문 안에 포함된 Date: 헤더(RFC 2822 정의)로, 메시지가 발송되거나 수신된 날짜를 나타냅니다. 다른 하나는 INTERNALDATE로, 이 메시지가 메일함에 저장된 날짜를 가리키는 서버 수준의 메타데이터입니다. Outlook 같은 이메일 클라이언트가 기본적으로 이메일을 정렬하고 표시할 때 사용하는 값이 바로 INTERNALDATE입니다.

(EAC에서 이메일의 원본 헤더를 직접 읽어보려 한 적이 있다면, 내용에 도달하기 전에 헤더만 20~30줄씩 펼쳐지는 걸 보셨을 겁니다. 그다지 즐거운 독서는 아니죠.)

IMAP 마이그레이션 도구가 메시지를 한 메일함에서 다른 메일함으로 옮길 때, 대상 서버에서 이 INTERNALDATE를 다시 설정해야 합니다. 제대로 처리하는 도구도 있지만, 그렇지 않은 도구도 많습니다. 수신 서버의 동작도 중요합니다. 반면 수신 서버는 받은 그대로를 유지합니다. 복사본이 원래 날짜를 가지고 있다면, Exchange Online도 그 날짜를 그대로 유지합니다. 따라서 날짜가 잘못 표시된다면, 문제는 Microsoft 365가 아니라 도구 쪽에 있습니다.

결과는 하나입니다. 마이그레이션된 이메일이 모두 마이그레이션 당일에 "수신된" 것처럼 보입니다. 원래 2019년 메일이었다고 해도요.

두 단계 날짜 오류 시나리오: 공유 호스팅이 문제를 악화시키는 이유

OVH, Infomaniak, Gandi, Ionos, o2switch 같은 공유 호스팅에서 마이그레이션할 때 상황이 정말 복잡해지는 지점이 여기입니다.

이 호스팅 업체들은 보통 표준 IMAP 설정의 Postfix, Dovecot, cPanel 공유 서버를 사용합니다. 많은 중소기업이 2010년이나 2012년부터 수년치 이메일을 이 서버에 쌓아두고 있습니다. Microsoft 365로 넘어가기로 결정했을 때, 마이그레이션은 종종 두 단계로 진행됩니다.

1단계: 첫 번째 날짜 오류 (Microsoft 365로 오기 전부터)

많은 경우 이메일은 이미 한 차례 마이그레이션을 거쳤습니다. 회사가 수년에 걸쳐 공유 호스팅 업체를 한두 번 바꿨을 수 있습니다. 예를 들어 2018년에 Gandi에서 OVH로, 2022년에 OVH에서 Infomaniak으로 이동한 경우처럼요. 각 IMAP 전송마다, 도구가 원래 날짜를 전달하지 않았다면 원래 INTERNALDATE가 전송 당일로 초기화될 수 있으며, 일부 도구는 그 날짜가 찍힌 자체 마이그레이션 헤더를 남기기도 합니다.

Microsoft 365에 도착하는 이메일은 이미 상처를 입은 상태입니다. 원래 Date: 헤더는 멀쩡합니다(메시지 본문 안에 있어서 아무도 건드리지 않으니까요). 하지만 날짜 메타데이터는 이미 한 번 망가진 상태입니다.

2단계: Exchange Online으로 전환 시 두 번째 날짜 오류

EAC의 IMAP 마이그레이션 도구나, IMAP 모드로 설정된 BitTitan MigrationWiz 같은 서드파티 도구가 이미 날짜가 잘못된 이메일을 처리합니다. 그 도구도 각 이메일의 원래 날짜를 전달하지 않는다면, Exchange Online은 전송 당일로 이메일을 분류하며, Outlook이 표시하는 "받은 날짜"가 바로 그 날짜가 됩니다.

2017년 3월에 발송된 이메일에 잘못된 날짜가 두 겹으로 쌓일 수 있습니다. 2022년 이동 당시 남은 마이그레이션 헤더, 그리고 2024년 Microsoft 365 마이그레이션에서 생긴 받은 날짜까지요. Outlook은 2024년을 표시하고, 사용자는 2024년을 봅니다. 두 단계에 걸쳐 잘못된 정보입니다.

사실 정확히 말하면, Outlook은 Exchange Online이 기록한 INTERNALDATE와 헤더를 조합해서 표시 날짜를 결정합니다. 하지만 마이그레이션 도구가 원래 날짜를 전달하지 않는 경우, Exchange Online으로의 이동은 기존 오류 위에 새로운 오류 레이어를 추가합니다.

마이그레이션 도구와 호스팅: 위험한 조합들

공유 호스팅에서의 마이그레이션에서 자주 등장하는 조합들이 있습니다.

• OVH / Infomaniak / Ionos + EAC IMAP 도구: Microsoft 기본 도구는 편리하지만, 대용량 IMAP 마이그레이션 시 날짜를 제대로 보존하지 못하는 것으로 유명합니다.
• cPanel (o2switch, LWS 등) + BitTitan MigrationWiz IMAP 모드: IMAP 모드의 MigrationWiz는 자체 마이그레이션 헤더를 추가합니다. 자세한 내용은 Microsoft 365에서 BitTitan MigrationWiz 마이그레이션 날짜 수정 페이지를 참고하세요.
• Gandi / Mailcow + imapsync: imapsync는 강력한 도구이지만 INTERNALDATE 처리는 설정에 따라 달라집니다. 적절한 옵션 없이는 날짜가 보존되지 않습니다. imapsync 날짜 보존 안 됨 가이드도 함께 확인해 보세요.
• Outlook에서 드래그 앤 드롭으로 수동 복사: 두 계정을 Outlook에 설정해 놓고 폴더 전체를 드래그해서 복사했다면, 모든 이메일의 INTERNALDATE가 복사 날짜로 덮어씌워집니다. 예외 없이요.

공통점은 하나입니다. 이 방법들 모두 Outlook에서 표시되는 날짜가 실제와 전혀 맞지 않는 이메일을 Exchange Online에 남깁니다.

대규모 환경에서 "직접 수정"이 위험한 이유

문제를 이해하는 것과 실제로 고치는 것은 전혀 다른 이야기입니다. 40개의 Exchange Online 메일함에 흩어진 8,000개의 이메일을, 복잡한 폴더 구조와 S/MIME 서명 메시지, 대용량 첨부파일, 중첩된 대화 스레드까지 있는 환경에서 수정하는 건 결코 간단하지 않습니다.

테스트용 이메일 10개에서는 잘 작동하는 것 같던 PowerShell 스크립트가, 손상된 MIME 경계나 RFC 2047 인코딩 헤더(=?UTF-8?B?...?= 형식으로 발신자 이름에 비ASCII 문자가 포함된 경우) 때문에 4,237번째 메시지에서 조용히 실패할 수 있습니다. 개별 검증 메커니즘이 없으면 알 수 없습니다. 그냥 이메일 하나가 사라지는 거죠.

이런 종류의 마이그레이션에서 직접 수정 시 발생하는 실제 위험들:

• 삽입 로직이 중간에 실패하면 메시지 중복 발생
• multipart 구조가 잘못 재구성되면 첨부파일 누락
• Outlook에서 대화 스레드 깨짐 (대화는 References:와 In-Reply-To: 헤더 기반인데, 이게 변경될 수 있습니다)
• 새벽 3시에 Microsoft Graph API 429 오류(Too Many Requests)가 발생해 롤백 없이 처리 중단
• 8,000개 수정이 모두 올바르게 적용됐는지 확인할 간단한 방법 없음

공유 호스팅에서의 마이그레이션에는 어려움이 하나 더 있습니다. 이메일에 불필요한 Received: 헤더가 한 겹이 아니라 여러 겹 쌓여 있다는 점입니다. "마지막 Received: 헤더를 제거한다"는 단순한 스크립트로는 부족합니다. 어떤 헤더가 어떤 마이그레이션에서 비롯된 것인지, 그리고 어떤 것이 실제 원래 수신 날짜를 나타내는지 전체 체인을 분석해야 합니다.

Redate.io가 다르게 접근하는 방법

Redate.io는 각 사용자가 자신의 Microsoft 계정으로 직접 로그인하는 방식으로 연결되며, 그 로그인이 부여하는 권한으로 해당 메일함을 엽니다. 초기 스캔은 무료입니다. Redate.io는 표시된 날짜와 실제 날짜가 일치하지 않는 모든 이메일을 식별하고, 메일함별로 정확한 수치를 제공합니다.

수정은 각 메시지의 전체 헤더 체인을 분석하고, 사용된 마이그레이션 도구가 무엇이든 관계없이, 여러 오류 레이어가 겹쳐 있는 경우에도 날짜 메타데이터를 정확하게 재구성하는 독점 엔진을 기반으로 합니다. 수정된 각 이메일은 개별적으로 검증됩니다. 원본은 삭제되지 않으며, 사용자가 직접 삭제하기 전까지 메일함의 눈에 보이는 백업 폴더에 보존됩니다.

공유 호스팅에서의 마이그레이션의 경우, Redate.io의 다단계 분석 파이프라인이 이중 날짜 오류 시나리오를 명시적으로 처리합니다. 마지막 Received: 헤더만 보는 것이 아니라 전체 이력을 거슬러 올라가 실제 수신 날짜를 찾아냅니다. 일반적인 마이그레이션 후 날짜 수정 방법은 Microsoft 365 마이그레이션 후 이메일 날짜 수정을, IMAP 날짜 오류의 기술적 메커니즘은 IMAP INTERNALDATE 해설을 참고하세요.

마이그레이션 전후: 두 가지 시점에서의 대응

상황에 따라 접근 방식이 달라집니다.

아직 마이그레이션 전이라면, 피해를 최소화할 수 있습니다. 일부 마이그레이션 도구(Exchange 모드의 MigrationWiz, 올바른 옵션을 설정한 CloudM)가 날짜를 더 잘 보존합니다. 하지만 최선의 경우에도 깔끔한 이력이 없는 공유 호스팅에서의 마이그레이션은 흔적을 남길 가능성이 높습니다. 마이그레이션 후 사용자에게 메일함을 넘기기 전에 Redate.io를 통한 검증을 계획해 두세요.

이미 마이그레이션을 완료했고 티켓이 쏟아지고 있다면, Redate.io는 마이그레이션 시점에 관계없이 Microsoft 365의 기존 메일함을 수정합니다. 스캔을 통해 어떤 작업을 하기 전에 각 메일함의 실제 상태를 정확히 파악할 수 있습니다. 앞으로 같은 문제를 방지하려면 이메일 마이그레이션 체크리스트도 함께 확인해 보세요.

OVH, Infomaniak, Ionos 또는 o2switch에서 Microsoft 365로 마이그레이션 후 날짜가 잘못 표시되고 있나요? Redate.io 계정을 만들어 메일함을 무료로 스캔하고, 어떤 결정을 내리기 전에 정확한 상황을 확인해 보세요.