Redate.io

BitTitan MigrationWiz: 이메일 날짜 오류 수정

읽는 시간 5분 최종 업데이트:

BitTitan MigrationWiz가 이메일 날짜에 미치는 영향

금요일에 마이그레이션이 완료되었어요. 47개의 메일함이 온프레미스 Exchange에서 Microsoft 365로 이전되었고, MigrationWiz 대시보드에서는 모두 녹색이에요. 그런데 월요일 아침, 첫 번째 티켓이 들어와요. "모든 이메일이 2026년 3월 28일로 표시돼요."

모든 메시지가 그래요. 수년간의 업무 서신, 2019년 고객 제안서, 2021년 청구서까지 전부 마이그레이션 날짜로 표시돼요. MigrationWiz 로그에는 모든 항목이 성공적으로 전송되었다고 나와요 (기술적으로는 맞아요). 하지만 날짜가 사라졌어요.

BitTitan MigrationWiz는 클라우드 간 이메일 마이그레이션에 가장 널리 사용되는 도구 중 하나예요. Exchange에서 Microsoft 365로, Google Workspace에서 Exchange로, 테넌트 간 이동까지 다양한 마이그레이션을 처리해요. 도구 자체는 설계된 목적대로 잘 작동해요. 날짜 문제는 MigrationWiz의 버그가 아니에요. 각 사본이 새 메일함에 기록될 때 어떤 날짜를 가지고 오는지, 그것 하나에 달려 있어요.

잘못된 날짜가 실제로 있는 곳

MigrationWiz가 소스에서 대상으로 이메일을 전송할 때 IMAP 프로토콜(또는 엔드포인트 유형에 따라 Exchange Web Services)을 사용해요. 대상은 전달받은 날짜를 그대로 유지해요. Microsoft 365, Outlook.com, Gmail은 사본이 원래 날짜를 담고 있으면 그 날짜를 그대로 유지해요. 따라서 모든 이메일이 마이그레이션 날짜로 표시된다면, 문제는 MigrationWiz가 그 날짜를 전달했는지 여부에 있어요.

MigrationWiz 마이그레이션 이후에도 이메일 헤더에 여전히 남아 있는 내용은 다음과 같아요.

Date: Tue, 15 Jan 2019 09:32:10 +0100
Received: from original-server.company.com
    by mail.company.com; Tue, 15 Jan 2019 09:41:33 +0100

2019년의 원본 Date: 헤더는 여전히 남아 있고, 원본 Received: 체인도 마찬가지예요. 그런데 Microsoft 365에서 Outlook이 수신 날짜로 표시하는 값은 메일함 자체가 각 이메일이 도착했다고 기록한 값이에요. MigrationWiz가 원래 날짜를 전달하지 않았다면, 그 기록은 2026년 3월 28일을 가리켜요.

INTERNALDATE 값(IMAP 서버가 정렬에 사용하는 타임스탬프)은 사본이 받은 날짜예요. MigrationWiz는 날짜를 보존하려고 시도하고, Microsoft 365는 전달받은 날짜를 그대로 유지해요. 그런데도 날짜가 잘못 나온다면, 각 이메일에 전달된 날짜가 원래 날짜가 아니었던 거예요.

MigrationWiz 날짜 매핑이 작동하지 않는 이유

BitTitan은 MigrationWiz 고급 옵션에서 "Date Mapping" 기능을 제공해요. 문서상으로는 해결책처럼 보여요. 그런데 실제로는? 마이그레이션할 메시지의 날짜 범위를 제어하는 것이지, 대상에서 날짜가 어떻게 보존되는지를 제어하는 게 아니에요.

혼동은 이해할 수 있어요. 설정 이름에 "날짜"라고 적혀 있으니까요. 하지만 실제로 하는 일은 마이그레이션 전에 소스 메시지를 날짜 범위로 필터링하는 거예요. 2018년 메시지도 마이그레이션 타임스탬프로 대상에 도착해요.

IMAP 대 Exchange 엔드포인트 문제도 있어요. MigrationWiz가 EWS(Exchange Web Services)를 사용하여 두 Exchange 서버 간에 마이그레이션할 때는 EWS가 메시지 메타데이터에 대한 제어가 더 크기 때문에 날짜 보존이 더 잘 작동해요. IMAP을 사용할 때도 대상은 전달받은 날짜를 그대로 유지해요. 중요한 것은 원래 날짜가 전달되는지 여부예요.

일부 관리자는 다른 엔드포인트 구성으로 마이그레이션을 다시 실행해 봤어요. IMAP에서 EWS로 전환하면 날짜가 소급 수정될 거라고 기대하면서요. 수정되지 않아요. 메시지는 이미 잘못된 날짜로 대상에 있어요. MigrationWiz를 다시 실행하면 중복만 생겨요.

날짜를 깨뜨리는 MigrationWiz 시나리오

모든 MigrationWiz 마이그레이션이 날짜 문제를 일으키는 건 아니에요. 문제는 엔드포인트 조합에 따라 달라요.

  • Exchange(온프레미스)에서 Microsoft 365로 IMAP 경유: 날짜가 깨져요. 각 이메일이 사본의 날짜를 갖게 돼요.
  • Google Workspace에서 Microsoft 365로: 날짜가 깨져요. MigrationWiz가 Google에서 IMAP으로 읽어서 원래 날짜 없이 M365에 기록해요.
  • Exchange에서 Exchange로 (EWS에서 EWS): 날짜는 보통 보존돼요. EWS를 사용하면 원래 날짜가 메시지와 함께 이동해요.
  • 어디에서든 Google Workspace로 IMAP 경유: IMAP 경유일 때 Gmail은 도구가 전달하는 날짜를 그대로 유지하고 아무것도 추가하지 않아요. 그 날짜가 원래 날짜가 아니거나, 사본이 Gmail의 가져오기 API를 거쳐 복사한 날짜가 찍힌 Received: 줄이 추가되는 경우에만 날짜가 깨져요.
  • 테넌트 간 Microsoft 365 마이그레이션: 모두 그 방법이 전달하는 날짜에 달려 있어요.

MigrationWiz 대시보드는 날짜 문제를 표시하지 않아요. 메시지가 실제로 성공적으로 전송되었기 때문에 모든 항목이 "Completed"로 표시돼요. 콘텐츠는 온전하고, 첨부파일도 정상이고, 폴더 구조도 보존돼 있어요. 변경된 건 날짜뿐이고, MigrationWiz는 이것을 마이그레이션 오류로 추적하지 않아요.

MigrationWiz 이후 잘못된 날짜의 실제 비용

잘못된 이메일 날짜는 단순히 불편한 게 아니에요. BitTitan으로 마이그레이션한 조직에게 그 영향은 지저분한 받은편지함을 넘어서요.

법무팀은 모든 메시지가 실제 발송 날짜가 아닌 마이그레이션 날짜를 표시할 때 이메일을 증거로 사용할 수 없어요. 세무 감사에는 커뮤니케이션의 시간순 증거가 필요해요. SOX, HIPAA, GDPR 같은 컴플라이언스 프레임워크는 정확한 기록 관리를 의무화하고 있으며, 위조된 타임스탬프가 있는 이메일은 이 요건을 충족하지 못해요.

그리고 실무적인 문제도 있어요. 전체 메일함이 2026년 3월을 표시하는 상태에서 2022년 11월의 계약 관련 논의를 찾아보세요. 날짜순 정렬? 쓸모없어요. 날짜 범위 검색? 전부 나오거나 아무것도 안 나오거나 둘 중 하나예요.

클라이언트 환경에서 MigrationWiz를 사용한 MSP에게 이것은 책임 문제를 만들어요. 클라이언트는 마이그레이션 비용을 지불했어요. 마이그레이션은 완료되었지만, 이메일 아카이브는 날짜 기반 워크플로에 대해 사실상 사용할 수 없게 되었어요.

한 로펌의 메일함 약 380개를 마이그레이션한 MSP 사례를 들었어요. 3개월 후, 그 로펌의 소송팀이 문서 디스커버리 과정에서 날짜 문제를 발견했어요. 증거로 제출해야 하는 모든 이메일이 마이그레이션 날짜를 표시하고 있었어요. MSP는 6년치 타임스탬프가 찍힌 서신이 왜 모두 2025년 6월을 표시하는지 설명해야 했어요.

BitTitan MigrationWiz 날짜 수정하기

원본 Date: 헤더는 여전히 모든 이메일 안에 있어요. MigrationWiz는 메시지 본문이나 원본 헤더를 건드리지 않아요. 표시 문제를 일으키는 것은 메일함이 각 사본에 대해 기록한 날짜예요.

Redate.io는 메일함(Google Workspace, Microsoft 365 또는 IMAP)에 연결하여 MigrationWiz 마이그레이션의 영향을 받은 이메일을 스캔하고, 독자적인 다단계 분석 파이프라인을 통해 날짜 메타데이터를 수정해요. 어떤 도구가 마이그레이션을 수행했는지 알 필요 없이, 표시된 날짜가 원래 날짜와 일치하지 않는 이메일을 찾아내요.

수정된 모든 이메일은 원본과 개별적으로 검증돼요. 검증에서는 메시지 무결성, 첨부파일 보존, 폴더 배치, 스레드 동작을 확인해요. 원본 이메일은 롤백이 필요할 경우를 대비하여 Redate.io - Originals 폴더에 그대로 보관되며, 직접 삭제하기 전까지 남아 있어요.

문제를 이해하는 것과 15,000통의 이메일을 첨부파일 손실, S/MIME 서명 손상, 멀티파트 MIME 경계 훼손 없이 수정하는 것은 완전히 다른 문제예요. 실험실에서 10개의 테스트 메시지로 작동하는 스크립트로는 7년간의 서신, PGP 암호화 메시지, RFC 2047 비ASCII 헤더가 있는 운영 메일함의 엣지 케이스를 처리할 수 없어요.

수정된 각 메시지가 온전한지 어떻게 확인하나요? 스레드가 여전히 작동하는지, 캘린더 초대가 여전히 처리되는지, 2020년 그 이메일의 47MB 첨부파일이 손상되지 않았는지? Redate.io는 모든 메시지에 대해 이것을 자동으로 수행해요. 그리고 무언가 이상하면 원본이 백업 폴더에 바로 있어요.

무료 스캔은 약 2분 정도 걸려요. 메일함에 연결하여 MigrationWiz 마이그레이션 날짜 타임스탬프가 있는 모든 이메일을 식별하고, 결제 전에 정확한 수량과 비용을 보여줘요. 신용카드 불필요, 약정 없음.

BitTitan 사용자를 위한 플랫폼별 수정 가이드

수정 프로세스는 MigrationWiz가 이메일을 이전한 대상에 따라 달라요. Redate.io는 각 플랫폼의 특성을 자동으로 처리하지만, 특정 환경에 대한 세부 정보가 필요하면 아래를 참조하세요.

Redate.io는 몇 달 또는 몇 년 전에 완료된 마이그레이션에도 작동해요. 원본 Date 헤더에는 만료 기한이 없어요.

BitTitan MigrationWiz로 마이그레이션했는데 날짜가 잘못된 상태인가요? 무료 스캔을 실행해서 어떤 결정을 내리기 전에 영향받은 이메일이 정확히 몇 통인지 확인해 보세요.

관련 기사

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

OVH, Infomaniak, Ionos, o2switch에서 Microsoft 365로 이메일을 마이그레이션했다면 날짜가 두 번 잘못될 수 있습니다. 원인과 해결 방법을 알아보세요.

Veeam/Datto: 복원 후 이메일 날짜가 오늘로 바뀌는 이유

Veeam, Datto, AvePoint로 복원 후 이메일 날짜가 복원 시점으로 바뀌는 기술적 원인과 수정 방법을 설명합니다. 원본 날짜는 항상 메시지 안에 보존되어 있습니다.

Outlook 프로필 재생성 후 날짜가 바뀌는 이유

Outlook 프로필을 삭제하고 다시 만들면 모든 이메일 날짜가 오늘 날짜로 바뀝니다. 기술적 원인과 날짜를 복구하는 방법을 설명해요.