이메일 이전 단계: T-7부터 T+1까지 일자별 계획

이메일 이전 단계: 중단 위험을 줄이는 일자별 일정

이메일 이전은 파일 복사가 아닙니다. 사용자가 양쪽에서 데이터를 수정하는 동안 두 운영 데이터베이스의 상태를 전환하는 일입니다. 데이터 계층(IMAP)과 라우팅 계층(DNS)의 시점이 어긋나면 조직 일부는 이전 서버에서, 나머지는 새 서버에서 메일을 받는 분할 라우팅이 생깁니다.

이 실행서는 T-minus 7부터 T-plus 1까지 매일 수행할 순서를 제시합니다. 구조적 배경은 이메일 설정 가이드를 참고하십시오.

관리해야 할 세 계층

모든 이메일 이전에는 세 계층이 있으며, 어느 하나의 실패도 중단을 일으킬 수 있습니다.

1. 데이터 계층: 과거 이메일(IMAP)
2. 라우팅 계층: 새 메일의 도착지를 정하는 DNS 레코드(MX)
3. 접속 계층: 메일을 여는 Outlook과 모바일 앱의 클라이언트 설정

T-7일: 현황 조사와 정리

존재를 모르는 것은 옮길 수 없습니다. 사용자 목록만으로는 충분한 자산 현황이 되지 않습니다.

모든 항목 조사

• 개체 유형 파악: 사서함, 별칭, 배포 목록, 공용 폴더를 모두 기록합니다.
• 대용량 사서함 식별: 20 GB 초과 사서함을 찾습니다. Google의 IMAP 다운로드는 약 2,500 MB/day로 제한됩니다. 50 GB 사서함은 몇 시간이 아니라 몇 주가 걸릴 수 있습니다. Google Workspace 데이터 이전 가이드에서 한도를 확인하십시오.
• 불필요한 데이터 정리: 퇴사자의 사서함을 로컬 보관 파일로 내보냅니다.

Exchange에서는 압축 때문에 GB 용량 비교가 부정확할 수 있으므로 PowerShell로 실제 항목 수를 조회합니다.

T-2일: 사전 동기화

금요일 밤까지 기다리지 말고 사용자가 일하는 동안 과거 데이터의 90%를 옮겨 전환 위험을 낮춥니다.

동기화 시작

이전 도구 또는 imapsync가 30일보다 오래된 메일을 옮기도록 설정합니다. HTTP 429(Too Many Requests)와 Google 11001 오류를 관찰합니다.

확인할 속도 제한

Gmail 주의: All Mail과 각 라벨을 별도 폴더처럼 동시에 옮기지 마십시오. Gmail 라벨은 같은 메시지를 가리키므로 잘못 매핑하면 중복이 생깁니다. 라벨을 폴더에 신중히 매핑하고 이 구성에서는 Gmail/All Mail을 제외합니다.

T-1일: TTL 낮추기, 300초 규칙

DNS 레코드는 흔히 24시간(TTL 86,400) 캐시됩니다. TTL을 미리 낮추지 않으면 일부 DNS 리졸버가 MX 변경 후에도 이전 서버로 메일을 보낼 수 있지만, 정확히 하루 동안 계속된다고 단정할 수는 없습니다.

1. Cloudflare나 Route53 같은 DNS 공급자에 로그인합니다.
2. MX 레코드를 찾습니다.
3. TTL을 300초(5분)로 바꿉니다.
4. 기존 레코드를 삭제하지 말고 TTL만 갱신합니다.

dig로 확인합니다.

T-0, 금요일 저녁: 전환

사용자가 작업을 멈춘 뒤 가장 중요한 이전 단계를 실행합니다.

1단계: 변경 중지

사용자에게 메일 발송을 멈추도록 안내하고 가능하면 원본 계정을 잠가 고립된 메일을 방지합니다.

2단계: 증분 동기화

이전 도구를 다시 실행해 최근 30일과 새 항목을 가져옵니다. 대량 데이터는 이미 옮겼지만 실제 소요 시간은 데이터량과 공급자 제한에 따라 달라집니다.

UIDVALIDITY 확인: 원본 서버가 폴더 색인을 다시 만들었다면 도구가 중복을 내려받을 수 있습니다. 먼저 시험 실행하십시오. IMAP RFC 3501에서 자세한 의미를 확인할 수 있습니다.

3단계: MX 레코드 전환

MX 레코드를 새 공급자로 바꿉니다. TrekMail 값은 다음과 같습니다.

TTL이 300초여도 실제 전환 시간은 캐시와 DNS 리졸버에 따라 달라지며 5분을 보장하지 않습니다.

4단계: SPF와 DKIM 업데이트

새 공급자가 발송하기 전에 새 IP를 SPF에 게시하고 검증합니다. 기존 공급자가 계속 보내는 동안에는 해당 승인도 유지합니다. 자세한 내용은 도메인 이메일 인증 설정 가이드를 참고하십시오.

T+1, 월요일 아침: 검증

마지막 단계는 검증입니다. 성공했다고 가정하지 말고 확인하십시오.

항목 수 검증

원본과 대상의 항목 수를 비교합니다. 1% 미만과 5% 초과는 조직의 운영 정책에 따른 조사 기준으로 사용하되, 차이의 원인을 확인해야 합니다. 큰 차이는 폴더 깊이나 필터 설정 문제일 수 있습니다.

클라이언트 재설정

메일 클라이언트를 새 계정으로 전환합니다. 기존 프로필을 안전하게 수정할 수 있는 경우도 있고, 삭제 후 다시 추가하는 편이 나은 경우도 있습니다.

일정과 연락처

TrekMail은 CalDAV 일정과 CardDAV 연락처를 서버에 저장하는 기업용 전문 이메일 호스팅입니다. 그러나 IMAP 이전은 지원되는 메일과 폴더만 옮깁니다. 기존 공급자에서 일정은 .ics, 연락처는 .vcf로 내보낸 뒤 TrekMail로 가져오고 각 기기의 동기화를 확인하십시오.

진행 여부 확인 관문

되돌리기 계획

새 시스템이 메일을 거부하거나 중요한 데이터가 없다면 다음을 수행합니다.

1. MX 복구: MX를 이전 공급자로 돌립니다. TTL이 300s여도 5분 내 반영은 보장되지 않습니다.
2. 간극 내보내기: 새 공급자를 계속 열어 두고 DNS 캐시가 사라질 때까지 재확인합니다. 그곳에 도착하는 메일을 EML/MBOX로 내보내 이전 서버에 가져옵니다.
3. 진단: 재시도 전에 550 5.7.1(Relay Access Denied)과 방화벽 차단을 확인합니다.

TrekMail의 이메일 이전 자동화

수동 이전은 위험이 큰 작업입니다. TrekMail은 인프라 작업 일부를 자동화해 고객 업무에 집중하도록 돕습니다.

소규모 기업

내장 이전 도구는 지원되는 IMAP 메일과 폴더의 연결, 재시도, 속도 제한을 처리합니다. 로그인 정보를 입력해 이전한 뒤 원본과 항목 수를 최종 대조하십시오.

에이전시와 MSP

100+개 도메인을 대량 구성할 수 있습니다. 사용자별 한도 대신 모든 고객이 함께 쓰는 공유 저장 공간을 제공하며 관리형 SMTP는 자체 IP 워밍업이 필요 없습니다.

모든 유료 요금제에는 14일 무료 체험이 포함되며 카드가 필요합니다. Nano 요금제에는 카드가 필요하지 않습니다.

마무리

각 단계가 이전 단계에 의존하므로 일정의 순서가 중요합니다. TTL을 미리 낮추지 않으면 일부 라우팅이 최대 24시간가량 나뉠 수 있고, 사전 이전을 생략하면 금요일 밤 작업이 토요일까지 이어질 수 있습니다.

일정을 따르고 항목 수를 검증하며 되돌리기 계획을 준비하십시오. 이것이 핵심입니다.

시작할 준비가 됐습니까? 무료 TrekMail 계정을 만들고 내장 이전 엔진으로 주요 작업을 처리하십시오.