iCloud에서 Office 365 마이그레이션 후 이메일 날짜 오류

날짜를 체계적으로 망가뜨리는 마이그레이션 시나리오

iCloud 메일을 Office 365로 이전하는 작업을 막 마쳤습니다. 이메일은 다 있고, 폴더도 제자리에 있고, 모든 게 완벽해 보입니다. 그런데 월요일 아침, 첫 번째 민원이 들어옵니다. "예전 이메일이 전부 오늘 날짜로 표시돼요." 그리고 두 번째, 세 번째... 곧 열 개가 됩니다.

이건 단순한 오류가 아닙니다. iCloud Mail에서 Office 365로의 마이그레이션은 이메일 날짜 손상 사례 중 가장 많이 보고되는 시나리오 중 하나입니다. Apple Mail의 동작 방식, IMAP 프로토콜의 특성, 그리고 Microsoft 365가 수신 메시지를 처리하는 방식이 맞물려 발생하는 기술적으로 명확한 이유가 있습니다.

iCloud에서 Office 365로 마이그레이션할 때 날짜가 깨지는 이유

문제를 이해하려면 많은 사람들이 (숙련된 IT 관리자들조차) 혼동하는 세 가지 개념을 구분해야 합니다. Date: 헤더, IMAP INTERNALDATE, 그리고 파일 생성 날짜입니다.

Date: 헤더 (RFC 2822)

모든 이메일에는 메시지가 발송된 시점을 나타내는 Date: 헤더가 포함되어 있습니다. 이 헤더는 메시지 원본 본문에 포함되어 있으며 이론적으로는 절대 변경되지 않습니다. 엄밀한 의미에서 "원본" 날짜입니다.

IMAP INTERNALDATE

IMAP 프로토콜(RFC 3501에 정의)은 각 메시지에 INTERNALDATE라는 별도의 메타데이터를 연결합니다. 대부분의 메일 클라이언트는 Date: 헤더가 아닌 이 값을 기준으로 받은 편지함의 메시지를 정렬하고 표시합니다. 특히 Outlook은 화면 표시와 정렬에 INTERNALDATE를 매우 강하게 의존합니다.

문제는 여기서 시작됩니다. 마이그레이션 도구가 한 IMAP 서버에서 다른 서버로 이메일을 복사할 때, 이상적으로는 INTERNALDATE도 함께 보존해야 합니다. 실제로는 항상 그렇게 되지 않습니다.

Apple Mail의 독특한 동작 방식

Apple Mail은 iCloud에서 메시지를 동기화할 때 서버 측 파일 생성 날짜를 INTERNALDATE의 기준으로 사용하는 경우가 있습니다. 이건 엄밀히 버그가 아니라 IMAP 사양에 대한 해석 방식의 차이입니다. (사실 원시 IMAP RFC를 읽으면서 INTERNALDATE 문제를 디버깅해본 적이 있다면, 이 부분의 사양이 꽤 넓은 해석 여지를 남긴다는 걸 알 겁니다.)

결과적으로, Apple Mail을 통해 iCloud에서 내보내거나 마이그레이션할 때 메시지의 INTERNALDATE는 Office 365에 도착하기도 전에 이미 잘못된 값을 가질 수 있습니다.

iCloud 마이그레이션의 세 가지 방법과 각각의 함정

직접 IMAP 마이그레이션

가장 일반적인 방법은 iCloud를 IMAP 소스로, Office 365를 대상으로 설정한 다음 마이그레이션 도구(imapsync, MigrationWiz, 또는 자체 제작 도구)를 사용하는 것입니다. 도구가 두 서버에 연결해서 메시지를 복사합니다.

여기서 문제는 두 가지입니다. 첫째, Apple의 IMAP 서버는 속도 제한이 있어 도구가 간헐적으로 일시정지해야 하는데, 이 과정에서 연결이 끊겼다 다시 연결되면서 불필요한 INTERNALDATE가 생성될 수 있습니다. 둘째, IMAP APPEND를 통해 Exchange Online에 복사된 각 메시지는 마이그레이션 도구가 삽입 명령에 원본 INTERNALDATE를 명시적으로 전달하지 않는 한 기본적으로 복사 시점의 날짜를 받게 됩니다.

제대로 처리하는 도구도 있습니다. 그렇지 않은 도구도 있고요. 4만 개의 메시지가 있는 사서함에서 2% 오류율만 되어도 날짜가 잘못된 이메일이 800개입니다.

imapsync를 사용한 마이그레이션의 경우, Microsoft 365에서 imapsync 마이그레이션 날짜 수정도 참고하세요.

.mbox 또는 .eml 내보내기 후 가져오기

일부 사용자는 Apple Mail을 통해 iCloud 이메일을 .mbox 형식으로 내보낸 다음 Outlook으로 가져오려 합니다. 결과가 들쑥날쑥한 수동 방법입니다.

.mbox 형식은 이메일을 텍스트 메시지의 연속으로 인코딩합니다. 날짜는 개별 Date: 헤더에 존재하지만, 메시지 간 구분 행("From ")에는 일부 가져오기 도구가 생성 날짜로 해석할 수 있는 날짜가 포함됩니다. Outlook은 .mbox를 .pst로 변환해서 가져올 때 메시지 자체의 Date: 헤더 대신 이 구분 행의 날짜를 사용하는 경우가 있습니다.

Outlook에서 끌어다 놓기

이게 가장 큰 피해를 유발하는 방법입니다. 사용자가 Outlook에서 두 계정(iCloud와 Office 365)을 모두 설정한 다음, 한 폴더에서 다른 폴더로 메시지를 끌어다 놓는 방식입니다. 간단해 보이지만, 날짜 관점에서는 재앙입니다.

Outlook이 두 IMAP 계정 사이에서 끌어다 놓기로 메시지를 이동할 때, 실제로는 새 .EML 파일을 생성해서 대상 계정에 삽입하고 원본을 삭제합니다. 이 새 파일은 Windows 파일 생성 날짜, 즉 끌어다 놓기를 한 정확한 시점을 상속받습니다. 원본 Date: 헤더는 메시지 본문에 여전히 존재하지만, Exchange Online 서버에 기록된 INTERNALDATE는 작업 시점의 날짜가 됩니다. 이후 Outlook은 이동된 모든 메시지에 이 마이그레이션 날짜를 표시합니다.

정확히 말하면, 이 동작은 Outlook 버전에 따라 다릅니다. 2023년 가을 Outlook 업데이트 이후 일부 시나리오에서는 약간 개선되었지만, 계정 간 끌어다 놓기는 여전히 날짜 손상의 원인으로 문서화되어 있습니다.

Office 365와 Outlook이 실제로 표시하는 것

Exchange Online은 이메일을 INTERNALDATE와 함께 저장합니다. Outlook Desktop은 이 INTERNALDATE를 읽어 "받은 날짜" 열에 표시하고 받은 편지함을 정렬합니다. 마이그레이션 중에 INTERNALDATE가 덮어씌워졌다면, Outlook은 마이그레이션 날짜를 표시합니다. 그게 전부입니다.

Outlook Web App(OWA)도 마찬가지입니다. 원본 Date: 헤더의 날짜를 보여주는 "대안 보기" 같은 건 없습니다. 날짜 열에 보이는 것이 INTERNALDATE입니다.

원본 Date: 헤더는 여전히 그 자리에 있고, 손상되지 않았으며, 메시지의 원시 헤더를 표시하면 읽을 수 있습니다. 하지만 일반적인 화면에서는 보이지 않습니다. 이게 이 문제의 핵심적인 답답함입니다. 올바른 정보는 존재하는데, 기술적인 수정 없이는 접근이 불가능합니다.

Microsoft 지원팀이 해결해주지 못하는 것

이 문제로 Microsoft 지원 티켓을 열면 아마 이런 답변을 받을 겁니다. 표시된 날짜가 저장된 INTERNALDATE와 일치한다는 확인, Outlook의 정렬 설정을 확인하라는 제안, 그리고 사용한 마이그레이션 도구 쪽으로 문의하라는 안내입니다.

악의가 있어서가 아닙니다. Microsoft에는 Exchange Online에 이미 수집된 수천 개의 메시지 INTERNALDATE를 소급해서 수정할 수 있는 기본 도구가 없습니다. 수정을 위해서는 각 메시지에 개별적으로 접근해서 헤더를 분석하고 날짜 메타데이터를 재구성해야 하는데, 이는 표준 지원 범위를 벗어납니다.

iCloud 지원 쪽에서는 메시지가 올바르게 내보내졌으며 문제는 대상 쪽에 있다고 봅니다. 두 지원팀이 서로에게 책임을 돌리는 사이, 사용자는 마이그레이션 당일 날짜로 된 이메일 12,000개를 안고 있게 됩니다.

규모의 문제

날짜가 깨진 이유를 이해하는 것과 실제 운영 사서함에서 수동으로 수정하는 것은 전혀 다른 이야기입니다.

일부 IT 관리자들은 스크립트로 수정을 시도합니다. 기본 개념은 어렵지 않지만, 실제 규모에서 실행하면 직접 만든 스크립트가 제대로 처리하지 못하는 문제들이 발생합니다.

• S/MIME으로 서명되거나 PGP로 암호화된 이메일은 암호화 서명을 무효화하지 않고는 수정할 수 없습니다
• 복잡한 multipart/alternative 구조(HTML + 일반 텍스트 + 중첩 첨부 파일)를 가진 메시지는 조작하기 취약합니다
• 비ASCII로 인코딩된 헤더(RFC 2047, 특히 일본어, 아랍어, 키릴 문자)는 이런 인코딩을 제대로 처리하지 못하는 도구에 의해 손상될 수 있습니다
• Microsoft Graph API 할당량과 Exchange Online 속도 제한(429 Too Many Requests 오류)은 지수 백오프 처리를 고려하지 않은 스크립트를 중단시킵니다
• 500개의 테스트 이메일에서 잘 돌아가던 스크립트가 실제 사서함의 8,000번째 메시지에서 새벽 3시에 멈추고, 재시작 메커니즘도 없습니다

그리고 핵심 질문이 남습니다. 수정 후 각 이메일이 온전한지 어떻게 확인하나요? 첨부 파일이 여전히 있는지? 스레드가 끊기지 않았는지? 직접 만든 스크립트는 보통 이런 검증을 하지 않습니다.

Redate.io가 iCloud에서 Office 365 마이그레이션을 처리하는 방법

Redate.io는 Microsoft 365(Azure AD) 권한을 통해 Office 365에 직접 연결하며, iCloud 서버에 대한 접근은 필요하지 않습니다. Redate가 작업을 시작할 때 이메일은 이미 Exchange Online에 있습니다.

Redate의 수정 엔진은 각 메시지의 헤더 체인을 분석해서 원본 날짜를 식별합니다. 마이그레이션 중에 추가된 Received: 헤더와 정당한 날짜 메타데이터를 구분하고, 알려진 마이그레이션 도구 서명에 대한 패턴 매칭을 수행합니다. 이를 통해 불필요한 헤더가 즉시 명확하지 않은 경우에도 식별할 수 있습니다.

수정된 각 이메일은 처리 후 개별적으로 검증됩니다. 원본은 30일 동안 눈에 보이는 백업 폴더에 보관되는데, 직접 만든 스크립트는 기본적으로 이 작업을 하지 않습니다. 초기 스캔은 무료이며, 수정을 결정하기 전에 영향을 받은 이메일 수를 정확하게 파악할 수 있습니다.

Redate는 Google Workspace에서 Office 365로의 마이그레이션이나 cPanel 마이그레이션 후의 수정도 지원합니다. 관련 내용은 Microsoft 365 마이그레이션 후 이메일 날짜 수정 또는 Exchange Online 마이그레이션 후 이메일 날짜 오류를 참고하세요.

먼저 스캔하고, 그 다음에 수정하세요

잘못된 날짜가 발생한 iCloud에서 Office 365로의 마이그레이션에서 권장하는 시작점은 영향받은 사서함에 Redate.io의 무료 스캔을 실행하는 것입니다. 스캔은 INTERNALDATE가 의심스러운 이메일이 정확히 몇 개인지, 어떤 폴더에 있는지를 식별합니다.

볼륨에 따라 12분에서 45분 정도 걸리며, 어떤 작업을 하기 전에 문제의 범위를 명확하게 파악할 수 있습니다. 마이그레이션 후 여러 사서함을 동시에 관리하는 MSP라면, 이 일괄 스캔을 통해 수정이 필요 없는 사서함에 불필요한 작업을 하지 않을 수 있습니다.

iCloud에서 마이그레이션 후 이메일 날짜가 잘못 표시된다면, Redate.io에서 무료 스캔을 시작해 Office 365 사서함의 문제 규모를 먼저 확인하세요.