이메일 마이그레이션 체크리스트: 날짜 문제 예방

마이그레이션 체크리스트가 필요한 이유

이메일 마이그레이션은 조직이 수행할 수 있는 가장 위험한 IT 작업 중 하나예요. 수년간의 업무 커뮤니케이션을 플랫폼 간에 이동시키는 작업인데, 작은 실수 하나가 모든 사서함의 메타데이터를 손상시킬 수 있습니다. 가장 자주 피해를 입는 것은? 바로 이메일 날짜입니다. 마이그레이션 후에는 각 이메일이 원래 발송일이나 수신일 대신 마이그레이션 날짜를 표시하게 될 위험이 있어요.

이 체크리스트는 마이그레이션 프로세스의 모든 단계를 다룹니다. 아래 단계를 따라 날짜 손상 및 기타 메타데이터 문제의 위험을 최소화하세요. 마이그레이션이 이미 완료되었고 날짜 문제가 발생했다면, 계속 읽어보세요.

1단계: 마이그레이션 전 계획

사서함 목록 정리

마이그레이션 도구를 건드리기 전에, 마이그레이션할 모든 사서함을 문서화하세요. 총 사서함 수, 사서함별 대략적인 이메일 수, 가장 오래된 이메일의 날짜 범위, 공유 사서함 및 배포 그룹을 기록해 두세요. 이 목록은 어떤 마이그레이션 도구를 사용할지, 마이그레이션에 얼마나 걸릴지, 그리고 마이그레이션 후 수정이 필요할 경우 어떤 요금제가 적용될지 결정하는 데 도움이 됩니다.

올바른 마이그레이션 도구 선택

모든 마이그레이션 도구가 날짜를 동일한 방식으로 처리하는 것은 아닙니다. 각 도구가 IMAP INTERNALDATE 보존을 어떻게 처리하는지, APPEND 과정에서 "Received" 헤더를 추가하는지 여부를 조사하세요. 주요 도구로는 BitTitan MigrationWiz, CloudM Migrate, imapsync, GSMMO, Exchange 관리 센터 기본 가져오기 등이 있어요. 이 도구들은 모두 날짜 문제를 유발할 수 있습니다. IMAP 프로토콜 자체가 삽입 시 대상 서버가 "Received" 헤더를 추가하도록 요구하기 때문이에요. 다만 일부 도구는 INTERNALDATE를 다른 도구보다 더 잘 보존합니다. INTERNALDATE 작동 방식에 대해 더 알고 싶다면 IMAP INTERNALDATE: 날짜가 깨지는 이유를 참고하세요.

모든 것을 백업하기

마이그레이션 전에 모든 사서함을 완전히 백업하세요. 이 백업은 안전망이자 마이그레이션 후 날짜를 검증하는 기준점이 됩니다. Google Workspace의 경우 Google Takeout 또는 써드파티 백업 도구를 사용하고, Microsoft 365의 경우 Exchange Online 백업이나 PST 내보내기를 사용하세요. IMAP 서버의 경우 imapsync를 사용해 로컬 복사본을 만드세요.

백업은 소스 서버와 대상 서버에서 완전히 분리된 위치에 저장하세요.

원본 날짜 기록

각 사서함에서 서로 다른 날짜 범위에 걸친 이메일 10~20개를 선택하세요 (가장 오래된 것, 가장 최근 것, 그 사이 여러 개). 각 이메일의 "수신" 날짜, "발송" 날짜, 원시 헤더를 기록하세요. 이 기준 이메일들이 마이그레이션 후 검증의 토대가 됩니다. 날짜순으로 정렬된 사서함의 스크린샷을 찍어 원래 시간순 순서를 시각적으로 기록해 두세요.

2단계: 테스트 마이그레이션

테스트 사서함부터 먼저 마이그레이션

테스트 없이 전체 마이그레이션을 시작하지 마세요. 절대로요.

대표적인 이메일 샘플 (최소 100개, 수년에 걸친)이 포함된 테스트 사서함을 만드세요. 이 사서함 하나만 마이그레이션을 실행하고 계속 진행하기 전에 결과를 깊이 살펴보세요. 이 테스트를 통해 프로덕션 사서함에 영향을 미치기 전에 날짜 문제, 인코딩 오류, 첨부 파일 처리 버그, 폴더 구조 차이를 미리 발견할 수 있습니다.

테스트 사서함의 날짜 검증

테스트 사서함 마이그레이션 후 즉시 날짜를 확인하세요. 최종 사용자들이 실제로 사용할 이메일 클라이언트 (Outlook, Apple Mail, Thunderbird 또는 웹메일 인터페이스)에서 사서함을 열어보세요. 표시된 날짜를 1단계에서 기록한 기준 이메일과 비교하세요. "수신" 날짜와 "발송" 날짜를 모두 확인하세요. 여러 이메일의 원시 헤더를 열고 마이그레이션 타임스탬프가 찍힌 새로 추가된 "Received" 헤더를 찾아보세요.

테스트 사서함에서 날짜가 틀리다면, 모든 사서함에서 틀릴 거예요. 전체 마이그레이션을 진행하기 전에 멈추고 문제를 해결하세요.

여러 이메일 클라이언트로 테스트

이메일 클라이언트마다 날짜를 다르게 표시합니다. Gmail 웹 인터페이스는 올바른 날짜를 보여줄 수도 있지만 ("Date" 헤더를 사용하기 때문에), Outlook은 마이그레이션 날짜를 표시할 수 있어요 ("Received" 헤더를 우선시하기 때문에). 조직 사용자들이 쓰는 모든 클라이언트로 테스트하세요. Outlook 데스크톱, Outlook 웹, Apple Mail, Thunderbird, 그리고 모든 모바일 이메일 앱을 포함해서요.

3단계: 마이그레이션 실행

마이그레이션 도구 설정

가능한 한 INTERNALDATE를 보존하도록 마이그레이션 도구를 설정하세요. imapsync에서는 대상에서 INTERNALDATE를 설정하기 위한 적절한 플래그를 사용하세요. BitTitan MigrationWiz에서는 날짜 처리 옵션에 대한 고급 설정을 확인하세요. 이 설정들이 "Received" 헤더 문제를 완전히 막지는 못하지만, 일부 클라이언트에서 날짜 문제의 심각도를 줄여줄 수 있어요. 필요한 경우 마이그레이션을 재현할 수 있도록 사용한 모든 설정 파라미터를 문서화하세요.

배치로 마이그레이션

모든 사서함을 동시에 마이그레이션하지 마세요. 10~20개 사서함씩 배치로 마이그레이션하고 각 배치 후 날짜를 확인하세요. 한 배치에서 날짜 문제가 발생하면, 조직 전체가 영향을 받기 전에 발견할 수 있습니다. 배치 마이그레이션은 소스 및 대상 서버의 부하도 줄여주어 부분 마이그레이션을 유발할 수 있는 타임아웃이나 연결 오류의 위험을 낮춰줍니다.

진행 상황 모니터링

각 사서함의 마이그레이션 진행 상황을 추적하세요. 시작 시간, 종료 시간, 마이그레이션된 이메일 수, 발생한 오류를 기록하세요. 마이그레이션 도구는 일반적으로 로그를 제공하는데, 각 사서함별로 이를 보관하세요. 나중에 날짜 문제가 발견될 경우, 로그를 통해 정확히 어떤 마이그레이션 배치와 어떤 설정이 사용되었는지 파악할 수 있습니다.

4단계: 마이그레이션 후 검증

즉시 날짜 검증

마이그레이션 후 24시간 이내에 이메일 날짜를 확인하세요. 각 배치에서 5~10개 사서함을 열고 날짜를 마이그레이션 전 기준과 비교하세요. 날짜가 틀리다면, 정보가 아직 생생할 때 문제의 범위 (영향받은 사서함 수, 사서함당 이메일 수)를 문서화하세요.

모든 폴더 유형 확인

날짜 문제는 폴더마다 다르게 나타날 수 있어요. 받은 편지함, 보낸 편지함, 임시 보관함, 그리고 모든 사용자 지정 폴더나 레이블에서 날짜를 확인하세요. 일부 마이그레이션 도구는 폴더를 순차적으로 처리하며, 한 폴더의 오류가 반드시 다른 폴더의 오류를 의미하지는 않습니다.

검색 및 정렬 검증

마이그레이션된 사서함을 열고, 날짜순으로 정렬해서 시간순 순서가 원본과 일치하는지 확인하세요. 날짜 범위로 이메일을 검색하고 결과가 정확한지 검증하세요. 수신 날짜에 의존하는 자동화된 규칙이나 필터를 테스트하세요. 조직에서 컴플라이언스 또는 eDiscovery 도구를 사용한다면, 날짜 기반 쿼리가 올바른 결과를 반환하는지 확인하세요.

날짜 문제를 유발하는 흔한 실수들

테스트 마이그레이션 건너뛰기

가장 흔한 실수는 먼저 테스트하지 않고 모든 사서함을 마이그레이션하는 것입니다. 날짜 문제가 발견될 때는 이미 모든 사서함이 영향을 받았고, 소스 서버는 이미 종료되었을 수도 있어요. 30분짜리 테스트 마이그레이션으로 몇 주간의 수정 작업을 피할 수 있는데, 왜 건너뛰는 걸까요?

"Received" 헤더 추가 무시

관리자들은 흔히 INTERNALDATE 보존에만 집중하고 "Received" 헤더 문제를 간과합니다. INTERNALDATE가 올바르게 설정된 경우에도, 마이그레이션 "Received" 헤더 때문에 Outlook과 다른 클라이언트들이 잘못된 날짜를 표시하게 됩니다. 이것이 마이그레이션 후 불만 신고의 가장 흔한 원인이에요. 기술적인 설명은 마이그레이션 후 이메일 날짜가 바뀌는 이유에서 확인하세요.

소스 서버 너무 일찍 종료

소스 서버를 종료한 후에 날짜 문제가 발견된다면, 재마이그레이션 옵션은 사라집니다. 마이그레이션 후 최소 30일 동안은 소스 서버를 접근 가능한 상태로 유지하세요 (읽기 전용도 괜찮습니다). 나중에 심각한 문제가 발생할 경우를 대비한 대안이 되어줄 거예요.

날짜가 이미 잘못된 경우

마이그레이션이 이미 완료되었고 날짜가 잘못된 경우에도, 문제는 수정 가능합니다. 원본 "Date" 헤더는 각 이메일에 보존되어 있어요. 즉, 올바른 날짜 정보가 여전히 존재한다는 뜻입니다. 이메일 날짜는 마이그레이션 후에도 수정할 수 있으며, 몇 달 또는 몇 년이 지난 후에도 마찬가지예요.

Redate.io의 독자적인 수정 엔진은 사서함에 연결하여 날짜 메타데이터가 손상된 이메일을 찾아냅니다. 다단계 분석 파이프라인이 마이그레이션 서명을 식별하고, 메시지 무결성 (S/MIME 서명, multipart 구조, 비ASCII 헤더 포함)을 보존하면서 타깃 수정을 적용한 후, 수정된 각 이메일에 대해 무결성 검사를 실행합니다. 분석은 무료이며 영향받은 이메일이 정확히 몇 개인지 보여줘요. 원본은 30일간 눈에 보이는 백업 폴더에 보관됩니다.

이런 수정을 수동으로 또는 커스텀 스크립트로 시도하는 것은 매력적으로 들리지만 위험합니다. PGP 암호화된 메시지, 손상된 MIME 경계, 중첩된 multipart 구조, Content-Transfer-Encoding 불일치 같은 엣지 케이스들은 너무 늦을 때까지 알아차리지 못하는 사이에 이메일을 조용히 손상시킬 수 있어요. 10,000개의 수정된 이메일이 모두 손상 없이 멀쩡한지 어떻게 검증할 건가요?

사서함에 날짜 문제가 있는지 확인할 준비가 되셨나요? Redate.io로 무료 분석을 시작하세요 - 영향받은 이메일 수를 확인하는 데 결제가 필요 없습니다.