CloudM Migrate: 잘못된 이메일 날짜 수정 방법

아무도 경고하지 않는 CloudM Migrate 날짜 문제

CloudM Migrate가 작업을 마쳤어요. 대시보드에 100% 완료, 모든 사용자 마이그레이션 완료, 오류 0건이 표시되어 있어요. 프로젝트 티켓을 닫고 다음 클라이언트로 넘어가요.

그런데 일주일 후 IT 이사가 전화해요. "받은편지함의 모든 이메일에 4월 2일이라고 표시되는 건 왜인가요?"

일부 이메일이 아니에요. 전부예요. 5년간의 고객 서신, 법적 문서, HR 기록, 2020년 발주서, 전부 CloudM이 마이그레이션을 실행한 날짜로 표시돼요. 메시지는 있고, 내용은 손상되지 않았고, 첨부파일도 정상이에요. 하지만 모든 이메일에서 날짜가 잘못되어 있어요.

이건 CloudM 버그가 아니에요. CloudM의 자체 지원 문서에서도 이를 공개적으로 인정하고 있어요. 문제는 마이그레이션 도구가 메시지를 전송하는 방식과 대상 메일 서버가 수신 이메일 메타데이터를 처리하는 방식의 교차점에 있어요. 하지만 그걸 알아도 받은편지함이 정렬 불가능해진 고객에게는 도움이 되지 않아요.

CloudM이 실제로 이메일 메시지를 전송하는 방식

CloudM Migrate는 각 플랫폼의 API를 통해 소스와 대상 플랫폼에 연결해요. Google Workspace의 경우 도메인 전체 위임이 있는 서비스 계정(Google 관리 콘솔의 보안 > API 제어에서 구성)을 의미해요. Microsoft 365의 경우 마이그레이션 경로에 따라 Exchange Web Services 또는 Microsoft Graph API를 사용해요.

CloudM이 소스에서 메시지를 읽으면 모든 원본 헤더와 메시지 본문을 포함한 전체 RFC 2822 콘텐츠를 가져와요. 원본 Date: 헤더(이메일이 처음 전송될 때 발신자의 메일 서버가 찍은 것)는 손상 없이 도착해요. 메시지의 배달 경로를 추적하는 모든 원본 Received: 헤더도 마찬가지예요.

문제는 대상 측에서 발생해요. CloudM이 그 메시지를 대상 메일함에 쓸 때, 대상 서버는 이를 새로운 배달로 취급해요. 현재 날짜와 시간이 포함된 새로운 Received: 헤더를 찍고, INTERNALDATE(IMAP이 정렬에 사용하는 타임스탬프)를 삽입 시점으로 설정해요.

CloudM에서 Microsoft 365로 마이그레이션 후 헤더 체인은 다음과 같아요:

Received: from cloudm-migrate.processing.cloudm.io
    by outlook.office365.com; Wed, 02 Apr 2026 08:14:52 +0000
Received: from mail.original-company.com
    by smtp.original-company.com; Mon, 23 Sep 2019 14:07:11 +0200

2019년 헤더가 거기 있어요. 원본 Date: 헤더는 여전히 2019년 9월 23일이라고 말하고 있어요. 하지만 Outlook은 표시 순서를 결정하기 위해 가장 최신의 Received: 헤더를 읽는데, 그건 이제 2026년 4월 2일이라고 말하고 있어요.

CloudM의 "Strip Received Headers" 설정

CloudM은 이 문제를 해결하기 위한 설정을 제공해요. 대상 플랫폼의 고급 설정, 메시지 옵션 아래에 "Strip Received Headers" 토글이 있어요. 활성화하면 CloudM은 메시지를 삽입하기 전에 received 헤더를 제거하고 이메일의 Date: 헤더와 일치하는 단일 헤더로 대체해요.

모든 걸 해결하는 것처럼 들리죠? 그렇지 않아요.

첫째, 마이그레이션을 실행하기 전에 이 설정에 대해 알아야 해요. 대부분의 관리자는 마이그레이션 완료 후에 날짜 문제를 발견해요. 그 시점에서 메시지는 이미 잘못된 날짜로 대상에 있어요. 이 설정을 활성화하고 CloudM을 다시 실행하면 중복만 생성될 뿐, 이미 있는 것은 수정되지 않아요.

둘째, 대상이 Google Workspace인 경우 이 설정에는 심각한 제한이 있어요. Google 자체 문서에서 확인하고 있어요: Gmail은 API를 통해 삽입된 메시지의 Received: 헤더를 항상 재작성하며 삽입 타임스탬프를 찍어요. 이것은 CloudM이 재정의할 수 없는 플랫폼 수준의 제한이에요. "Strip Received Headers"가 활성화되어 있어도 Google Workspace는 마이그레이션 날짜가 포함된 자체 Received: 헤더를 추가해요.

Microsoft 365 대상의 경우 이론적으로 설정이 더 잘 작동하지만, M365 전송 파이프라인에는 자체 동작이 있어요. Exchange Online은 메시지가 시스템에 들어오는 방식에 따라 자체 배달 처리에 기반해 INTERNALDATE를 설정할 수도 있어요.

어떤 CloudM 마이그레이션이 날짜를 망가뜨리나요 (그리고 어떤 것이 안 망가뜨리나요)

모든 CloudM 마이그레이션이 잘못된 날짜를 만드는 것은 아니에요. 결과는 소스-대상 조합과 CloudM이 사용하는 특정 API 경로에 따라 달라요:

• Google Workspace에서 Microsoft 365로: 날짜가 망가져요. CloudM이 Gmail API를 통해 읽고 Exchange에 써요. M365 전송 계층이 새 Received 헤더를 찍어요.
• Microsoft 365에서 Google Workspace로: 날짜가 망가져요. Strip Received Headers를 사용해도 Google API가 Received 헤더를 삽입 날짜로 재작성해요. CloudM 지원 문서는 이를 "엄격한 플랫폼 제한"이라고 부르고 있어요.
• Google Workspace에서 Google Workspace로: 날짜가 망가져요. 도메인 변경, 테넌트 통합, 인수 합병에서 대상 Google 테넌트는 수신 메시지에 항상 마이그레이션 날짜를 찍어요.
• 온프레미스 Exchange에서 Microsoft 365로: IMAP 경로에서는 보통 망가져요. CloudM이 양쪽에서 EWS를 사용하면 날짜 보존이 더 안정적이지만 보장되지는 않아요.
• 범용 IMAP 소스에서 모든 대상으로: 날짜가 망가져요. CloudM이 범용 IMAP 서버를 소스로 연결하면 대상은 여전히 자체 배달 헤더를 추가해요.

까다로운 부분이 뭐냐면요. CloudM의 마이그레이션 대시보드는 이 중 어떤 것도 표시하지 않아요. 진행률 바가 채워지고, 상태 열은 "완료"라고 말하고, 항목 수가 일치해요. CloudM의 관점에서 마이그레이션은 성공했어요. 기술적으로도 성공했고요. 메시지가 전송됐어요. 다만 날짜가 이동 과정에서 살아남지 못했을 뿐이에요.

CloudM 관리형과 셀프서비스: 같은 날짜 문제

CloudM은 두 가지 배포 모델을 제공해요. SaaS 버전(호스팅된 CloudM Migrate)은 CloudM의 인프라에서 완전히 실행돼요. 자체 호스팅 버전은 자체 네트워크, Google Cloud, Azure 또는 AWS에 1차 및 2차 마이그레이션 서버를 배포할 수 있게 해줘요.

일부 MSP는 마이그레이션 서버를 직접 관리하므로 자체 호스팅 옵션이 날짜 처리에 대해 더 많은 제어권을 제공한다고 가정해요. 그렇지 않아요. 날짜 문제는 CloudM의 처리 노드가 아니라 대상 서버에서 발생해요. 마이그레이션 팜이 CloudM 클라우드에서 실행되든 자체 Azure VM에서 실행되든, 대상 메일 서버는 수신하는 모든 메시지에 마이그레이션 날짜를 찍어요.

CloudM은 팀이 프로젝트를 처음부터 끝까지 관리하는 완전 관리형 "Serviced Migration"도 제공해요. 날짜에 대한 결과는 동일해요. 엔지니어링은 동일하고, 키보드 위의 손만 달라요.

잘못된 Date 헤더 합병증

상황을 더 악화시키는 또 다른 CloudM 고유의 동작이 있어요. CloudM이 RFC 822를 준수하지 않는 Date: 헤더(잘못된 시간대, 누락된 요일, 비표준 형식)가 있는 소스 이메일을 발견하면 메시지를 마이그레이션할 수 있도록 헤더를 수정해요.

이것은 일부 이메일이 원본 날짜 참조조차 잃게 된다는 뜻이에요. 수정된 Date: 헤더가 실제 전송 날짜와 전혀 일치하지 않을 수도 있어요. CloudM의 지원 문서는 "마이그레이션된 항목의 가능한 변경 사항" 아래에서 이를 알려진 동작으로 언급하지만 수정된 날짜가 무엇이 되는지는 명시하지 않아요.

8년간 축적된 12,000통의 메시지가 있는 메일함의 경우 약간 비표준적인 Date 헤더를 가진 이메일이 수백 통 있을 수 있어요(특히 오래된 메일 서버, 자동화 시스템, 시간대 형식 차이가 있는 해외 발신자의 메시지). CloudM의 수정과 대상 서버의 Received 헤더 재작성 후, 이러한 메시지는 현실과 전혀 관련 없는 날짜로 끝나게 돼요.

CloudM 후 수동 수정이 대규모에서 작동하지 않는 이유

직접 수정할 수 있을까요? 기술적으로 원본 Date: 헤더는 대부분의 메시지에 여전히 포함되어 있어요(CloudM이 RFC 준수를 위해 수정한 것 제외). 일부 관리자는 CloudM 마이그레이션 후 날짜를 수정하는 스크립트를 작성해 봤어요.

그 접근 방식의 현실은 다음과 같아요. 잠재적으로 수천 개의 메일함에 연결해야 하고, 각각에 수천 통의 메시지가 있어요. 각 이메일에 대해 전체 헤더 체인을 분석하고, CloudM이나 대상 서버가 추가한 Received: 헤더를 식별하고, 엣지 케이스를 처리해야 해요(헤더 수정이 서명을 깨뜨리는 S/MIME 서명된 메시지, PGP 암호화 콘텐츠, 중첩된 경계가 있는 멀티파트 MIME 구조, 일본어나 한국어 발신자의 RFC 2047 인코딩된 비ASCII 헤더). 그리고 이 모든 것을 첨부파일 하나 잃지 않고 이메일 스레드를 깨뜨리지 않으면서 해야 해요.

깨끗한 메일함의 테스트 이메일 50통에서 작동하는 스크립트는 10년에 걸친 40,000통의 메시지가 있는 프로덕션 환경과의 접촉에서 살아남지 못할 거예요. 중첩된 첨부파일 6개가 있는 47MB 이메일을 만나면 어떻게 될까요? API 속도 제한(Google의 사용자당 초당 250 할당 단위, Microsoft의 10분당 약 10,000 요청 제한)은 어떻고요? 메시지 번호 8,347에서 문제가 발생했을 때의 롤백 계획은 무엇인가요?

그리고 대부분의 관리자가 너무 늦을 때까지 묻지 않는 진짜 질문: 수정된 각 메시지가 실제로 손상되지 않았음을 어떻게 검증하나요?

Redate.io로 CloudM 마이그레이션 날짜 수정하기

Redate.io는 영향받은 메일함(Google Workspace, Microsoft 365 또는 IMAP)에 직접 연결하여 CloudM의 마이그레이션 날짜 시그니처를 가진 이메일을 스캔해요. 스캔은 무료이며 메일함당 몇 분 소요되고, 어떤 약정 전에도 영향받은 메시지의 정확한 수를 보여줘요.

수정은 Received 헤더 체인에서 CloudM 고유의 마이그레이션 패턴을 식별하는 독자적인 헤더 체인 분석 엔진을 사용해요. Redate.io는 메시지 콘텐츠를 변경하지 않으면서 타겟팅된 메타데이터 수정을 수행하고, 첨부파일, 스레드, 라벨, 폴더, 디지털 서명을 보존해요. 수정된 각 메시지는 프로세스가 진행되기 전에 원본에 대해 메시지 무결성을 확인하는 개별 검증을 거쳐요.

원본 이메일은 메일함 내 보이는 Redate.io - Originals 백업 폴더에 30일간 보관돼요. 롤백이 필요하면 원본이 메일함 내에 있고, 외부 아카이브에 묻혀 있지 않아요.

클라이언트 환경에서 CloudM을 사용한 MSP를 위해, Redate.io는 1개 메일함이든 500개 메일함이든 동일한 메시지별 검증으로 다중 메일함 수정을 처리해요. CloudM이 남긴 날짜 문제가 클라이언트의 메일 환경의 영구적인 특성이 될 필요는 없어요.

CloudM 마이그레이션 플랫폼별 가이드

수정 프로세스는 대상 플랫폼에 맞게 적응해요. Redate.io는 각 플랫폼의 특성을 자동으로 처리하지만, 설정 세부 사항은 다음을 참조하세요:

• Gmail에서 CloudM 마이그레이션 날짜 수정
• Outlook에서 CloudM 마이그레이션 날짜 수정
• Google Workspace에서 CloudM 마이그레이션 날짜 수정
• Microsoft 365에서 CloudM 마이그레이션 날짜 수정

CloudM뿐만 아니라 모든 마이그레이션 도구에서 이런 일이 발생하는 이유에 대한 더 자세한 설명은 마이그레이션 후 이메일이 잘못된 날짜를 표시하는 이유를 참조하세요.

CloudM으로 마이그레이션하고 모든 이메일의 날짜가 잘못되었나요? 무료 스캔을 실행하여 영향받은 메시지 수와 수정 비용을 정확히 확인하세요.