Gmail에서 CloudM Migrate 마이그레이션 날짜 수정

CloudM Migrate(이전 Cloud Migrator)는 Gmail API를 통해 Google Workspace로 이메일을 업로드합니다. 업로드 과정에서 Gmail은 삽입 타임스탬프를 메시지의 INTERNALDATE로 기록합니다. 이메일 본문 내의 원래 Date 헤더는 마이그레이션 과정에서 살아남지만, IMAP 클라이언트가 메시지 수신 시점을 결정하기 위해 읽는 INTERNALDATE는 마이그레이션 날짜로 영구적으로 덮어쓰여집니다.

CloudM 마이그레이션이 특히 혼란스러운 이유는 Gmail의 이중 동작 때문입니다. Gmail 웹 인터페이스는 표시용으로 Date 헤더를 읽기 때문에 브라우저에서 이메일이 완벽하게 정상적으로 보입니다. 같은 사서함을 IMAP을 통해 Outlook에서 열면 모든 이메일이 마이그레이션 날짜를 표시합니다. Apple Mail, Thunderbird, 모바일 IMAP 클라이언트도 마찬가지입니다. 이 문제는 웹에서만 Gmail을 사용하는 사람에게는 보이지 않기 때문에 진단이 어렵고 무시하기 쉽습니다.

"마이그레이션이 잘 완료됐고, 날짜도 정확하게 보입니다." CloudM 콘솔이 알려주는 내용입니다. Gmail도 마찬가지입니다. 하지만 사용자의 60%가 Outlook을 통해 접속하고, 그들에게는 14개월치의 이메일 기록이 하루로 압축된 것입니다.

Google Admin 패널의 CloudM 관리 콘솔(관리자 > 앱 > Google Workspace Marketplace 앱 > CloudM Migrate)은 이것을 문제로 표시하지 않습니다. 오류도 없고, 경고도 없고, INTERNALDATE 손상을 언급하는 마이그레이션 후 보고서도 없습니다. 사용자가 불만을 제기해야만 드러나는 숨겨진 데이터 품질 문제입니다.

영향은 전적으로 사용자가 사서함에 어떻게 접근하느냐에 따라 달라집니다. Gmail 웹이면 정상적으로 보입니다. IMAP을 통한 Outlook, Apple Mail, Thunderbird에서는 모든 이메일이 받은 날짜 열에 마이그레이션 날짜를 표시합니다. 이 불일치가 혼란스러운 지원 티켓을 생성하며 비기술적 사용자에게 문제를 설명하기 어렵게 만듭니다.

화면 표시 문제 너머로, INTERNALDATE 손상은 규정 준수 및 백업 인프라에까지 영향을 미칩니다. Google Vault는 특정 보존 및 법적 보류 작업에서 INTERNALDATE를 참조하여 날짜 기반 eDiscovery 검색의 정확도를 저해할 수 있습니다. IMAP을 통해 연결하는 서드파티 백업 도구(Veeam, Spanning, Backupify)는 마이그레이션 날짜를 메시지 날짜로 아카이빙하여 복원이 필요할 때까지 발견되지 않을 수 있는 영구적인 백업 기록 부정확성을 만듭니다.

Redate.io는 CloudM이 주입한 마이그레이션 아티팩트만을 대상으로 하는 헤더 체인 분석과 날짜 메타데이터 재구성을 통해 이 문제를 수정합니다. Gmail 웹 경험(이미 정상적으로 표시되던)은 변경 없이 유지됩니다. IMAP 클라이언트, Google Vault, 백업 도구 모두 원래 날짜를 읽게 됩니다. 각 메시지는 수정 전후로 개별 검증되어 데이터 손실이 전혀 없습니다.