데이터 손실과 중단을 줄이는 이메일 이전 가이드

데이터 손실과 중단 없이 이메일 이전하기

이메일을 공급자 간에 이전하는 일은 단순한 파일 복사가 아닙니다. 새 메시지가 들어오고 사용자가 항목을 삭제하며 메타데이터가 바뀌는 동안 살아 있는 데이터베이스를 동기화합니다. 잘못하면 분리된 라우팅, 메일 손실, 월요일 아침의 혼란이 생길 수 있습니다.

이 가이드는 소규모 기업 이메일 이전을 DNS 준비, IMAP 동기화, 전환, 사후 검증 단계로 나눈 엄격한 계획을 제공합니다. 각 단계는 실제 공급자와 환경에 맞춰야 합니다.

많은 이메일 이전이 실패하는 이유

세 가지 누락이 많은 실패를 만듭니다. 실제 환경에서 이전하기 전에 이해하면 시행착오를 줄일 수 있습니다.

DNS 캐싱: 전환 전에 TTL을 낮추지 않으면 최대 24시간 동안 이전 및 새 서버 양쪽으로 메일이 갈 수 있습니다.
속도 제한: Google 같은 공급자는 IMAP 다운로드를 하루 약 2,500 MB로 제한할 수 있습니다. 한도에 도달하면 동기화가 멈춥니다.
범위 확대: IMAP은 이메일만 옮깁니다. 캘린더와 연락처는 CalDAV/CardDAV 같은 별도 프로토콜에 있으며 자동으로 따라오지 않습니다.

단계 1: 기술 감사(T-minus 7일)

존재를 모르는 항목은 이전할 수 없습니다. 기억에 의존하지 말고 기술 목록을 만드세요.

숨은 주소 식별

사용자 이름 목록만으로 부족합니다. 메일 시스템의 모든 진입점을 기록하세요.

• 별칭: john@이 sales@ 메일도 받나요? 새 호스트에 별칭을 만들지 않으면 일부 메일이 반송될 수 있습니다.
• 배포 목록: team@과 info@이 공유 사서함인지 전달 그룹인지 확인하세요.
• 전달: 서버 측 전달 규칙을 감사합니다. 개인 Gmail 계정으로 보내는 숨은 규칙은 안전하게 다시 만들지 않으면 끊깁니다.

대형 사서함 찾기

10 GB보다 큰 사서함을 찾으세요. IMAP은 상호작용이 많아 50 GB 사서함이 한 시간에 끝나지 않습니다. Microsoft 365는 하루 약 20 GB 뒤 제한할 수 있습니다. 이런 사용자는 전환 최소 5일 전에 사전 동기화를 시작하도록 표시하세요. Google Workspace 데이터 이전 가이드에서 최신 한도를 확인할 수 있습니다.

이메일만 이전된다는 점 확인

imapsync와 TrekMail 내장 엔진을 포함한 이전 도구는 IMAP 프로토콜(RFC 3501)을 사용합니다. IMAP은 이메일만 전송합니다.

캘린더와 연락처는 IMAP에 없습니다. Exchange, CalDAV 같은 형식과 프로토콜을 사용합니다. 캘린더는 .ics, 연락처는 .vcf 또는 .csv로 기존 구독을 취소하기 전에 내보내고 별도로 가져오기를 시험하세요.

단계 2: 인프라 준비(T-minus 48시간)

아직 데이터를 건드리지 마세요. 목적지가 준비되도록 기반부터 구성합니다.

300초 규칙(DNS TTL)

DNS 레코드의 Time To Live(TTL)는 주소를 캐시하는 시간을 정합니다. 기본값이 86,400초(24시간)라면 금요일 변경 뒤 토요일까지 기존 서버가 캐시될 수 있습니다.

Cloudflare, GoDaddy, Route53 같은 DNS 공급자에서 MX 레코드 TTL을 300초로 설정하세요. 공급자가 허용한다면 이전 최소 24시간 전에 수행합니다.

목적지 프로비저닝

새 공급자에 사서함을 만듭니다. TrekMail 사용자는 대시보드에서 도메인과 사용자를 설정할 수 있습니다. Nano 요금제에서는 현재 기능을 확인하고 SES/Mailgun BYO SMTP 자격 증명을 미리 구성해 전환 뒤 발신을 준비하세요.

원본 사서함 비밀번호나 지원되는 관리자 자격 증명을 확보하세요. 없으면 비밀번호를 재설정하거나 승인된 관리자 경로를 써야 합니다.

단계 3: 사전 동기화 전략

금요일 밤에 전부 옮기는 일괄 이전은 피하세요. 단계적 이전은 위험을 크게 줄일 수 있습니다.

절차 1: 과거 데이터 처리(T-minus 3일)

7일보다 오래된 모든 이메일을 동기화하도록 도구를 설정합니다. 사용자가 계속 일하는 동안 데이터 약 95%를 옮길 수 있습니다. 2 GB 첨부파일이 실패해도 몇 시간 대신 며칠 동안 해결할 수 있습니다.

HTTP 429 또는 사용자 제한 오류를 확인하세요. 나타나면 동시 이전을 줄입니다. 공급자 한도에 따라 5명씩 처리하고 50명씩 처리하지 않는 식입니다.

절차 2: 동결(T-zero, 금요일 저녁)

사용자에게 이전 중이며 새 메일을 보내지 말고 웹메일은 읽기 전용이라고 알립니다. 정책과 접근 권한이 허용하면 원본 쓰기를 제한해 최종 검사에서 빠지는 메일을 방지하세요.

절차 3: 델타 동기화

도구를 다시 실행합니다. 마지막 7일과 사전 단계 중 변경된 항목을 가져옵니다. 약 95%가 이미 있다면 한도와 수량에 따라 훨씬 짧게 끝날 수 있습니다.

단계 4: 전환

MX 레코드 변경

DNS MX 레코드를 새 공급자로 바꿉니다. TrekMail 사용자는 현재 문서에 따라 다음을 지정합니다.

TTL이 300초면 트래픽이 빠르게 이동할 수 있지만 캐시와 전파는 다를 수 있으므로 양쪽을 감시하세요.

SPF 및 DKIM 인증

새 호스트로 옮길 때 인증 레코드를 갱신하세요. 올바르지 않으면 스팸 분류나 거부 위험이 커집니다.

• SPF: TXT 레코드를 갱신합니다. 예: v=spf1 include:spf.trekmail.net -all
• DKIM: 새 공급자 대시보드에서 키를 만들고 필요한 CNAME/TXT 레코드를 DNS에 추가합니다.

자세한 전환 절차는 도메인 이메일 설정을 참고하세요.

좀비 확인

Google Workspace를 떠나지만 Drive/Docs 계정을 유지하면 Google이 내부 메일을 새 MX로 보내지 않고 잡을 수 있습니다. 해당 사용자의 Gmail을 끄거나 최신 관리 문서에 따라 분할 배달을 구성하세요.

단계 5: 검증

사용자에게 전부 있는지만 묻지 말고 측정 가능한 값으로 이전 결과를 확인하세요.

용량이 아닌 항목 수

공급자마다 압축이 다르므로 전체 GB만 비교하지 마세요. 폴더별 항목 수를 비교합니다.

이 방식에서 1% 미만 차이는 손상되거나 잘못된 항목일 수 있지만 위험에 맞춰 검토해야 합니다. 5%를 넘으면 조사하세요.

폴더 계층

폴더가 평탄화되지 않았는지 확인하세요. Clients/2024/Project A/Invoices/Paid 같은 깊은 트리는 잘릴 수 있습니다. INBOX.Sent와 Sent 같은 네임스페이스 차이도 확인합니다.

일반적인 실패 해결

TrekMail 내장 이전 엔진

IMAP 동기화, 속도 제한, DNS 전파 조율이 위험하게 느껴진다면 TrekMail이 일부 작업을 자동화할 수 있습니다. 사후 검증과 대조는 여전히 필요합니다.

소규모 기업(1-50명)

설명된 TrekMail 요금제에는 기본 이전 엔진이 포함됩니다. 기존 공급자를 연결하고 사서함을 선택해 실행합니다. 인프라는 재시도, 속도 제한, 중복 제거를 처리하도록 설계됐습니다. 완료 후 수량과 예외를 확인하세요.

에이전시(100+ 도메인)

여러 고객의 이전은 수익성을 낮출 수 있습니다. TrekMail은 설명된 대량 작업, 도메인 간 통합 저장공간, 정액 가격을 제공합니다. 최신 한도와 지원 원본을 확인하세요.

설명된 상품에서 유료 요금제는 카드가 필요한 14일 무료 체험을 포함하며 Nano는 카드가 필요 없습니다. 최신 조건을 확인하세요.

결론: 이메일을 올바르게 이전하기

절차를 지키면 이메일 이전은 관리할 수 있습니다. 데이터를 미리 동기화하고 가능하면 TTL을 300초로 낮추고 델타를 실행한 뒤 직감이 아닌 항목 수로 검증하세요. 목표는 데이터 이동뿐 아니라 사용자별 가격 함정 없이 기업 이메일 요구를 지원하는 인프라로 전환하는 것입니다.

시작할 준비가 됐다면 무료 TrekMail 계정을 만들고 내장 이전 도구, 지원 원본, 최신 한도를 확인하세요.