이메일 이전의 이해: DNS, IMAP 복사, 전환
"이메일 이전"이라는 표현은 오해를 부르기 쉽습니다. 현실에서 파일을 이전하면 A 위치에서 떠나 B 위치에 도착합니다. 이메일 인프라에서는 이런 방식으로 움직이지 않습니다.
이메일 이전은 실제로 두 가지 독립적인 작업을 동시에 수행하는 과정입니다. 데이터베이스를 복제하는 IMAP 동기화와 트래픽을 새 서버로 돌리는 DNS 전환입니다. 이 두 계층을 혼동하면 데이터 손실, 양쪽 서버로 메일이 갈리는 라우팅, 월요일 아침의 고객지원 요청으로 이어집니다.
이 안내서는 실제 현장에서 "이전"이 무엇을 뜻하는지, 어떤 항목이 옮겨지고 어떤 항목이 남는지, 상황에 맞는 방식을 어떻게 선택하는지 설명합니다.
이메일 이전의 세 가지 유형
서버를 건드리기 전에 범위부터 정하세요. "이전"은 서로 다른 세 가지 작업에 혼용되며, 이를 섞으면 실제 문제가 발생합니다.
1. 도메인 이전 (등록업체 변경)
example.com의 관리를 GoDaddy에서 Namecheap으로 옮기는 작업입니다. 도메인 요금을 청구하는 업체가 바뀝니다. DNS 영역 파일을 정확히 복사한다면 이메일에 미치는 영향은 없습니다. MX 레코드를 복제하지 않고 네임서버를 바꾸면 이메일이 즉시 중단됩니다.
2. 이메일 마이그레이션 (서비스 제공업체 변경)
Google Workspace를 해지하고 TrekMail이나 다른 호스팅 업체로 옮기는 작업입니다. 새 서버를 준비하고 기존 데이터를 복사한 뒤 DNS를 바꿔 새 메일이 그곳으로 전달되도록 해야 합니다. 이메일 전체에 영향을 줍니다. 데이터를 면밀하게 재구성하는 과정이며 이 글에서 집중적으로 다룹니다.
단계별 실행 계획은 전체 IMAP 동기화 안내서를 참고하세요.
3. 계정 소유권 이전
계정의 관리자 이메일을 bob@에서 alice@로 바꾸는 작업입니다. 데이터베이스 권한만 변경됩니다. 이메일에는 영향이 없습니다.
이메일 이전 중 관리해야 할 두 계층
이메일을 성공적으로 이전하려면 두 일정을 동시에 관리해야 합니다. 어느 한쪽에서라도 실수하면 문제가 생깁니다.
데이터 계층 (IMAP 복사)
새 업체가 기존 데이터를 저절로 가져가지는 않습니다. IMAP 프로토콜 (RFC 3501)을 통해 데이터를 가져와야 합니다. 이는 복사이지 이동이 아닙니다. 원본은 직접 삭제하기 전까지 기존 서버에 남습니다.
UIDVALIDITY의 함정: IMAP은 대량 복제가 아니라 메시지 열람을 위해 설계되었습니다. 폴더마다 UIDVALIDITY 값이 있습니다. 마이그레이션 중 원본 서버에 장애가 생기거나 색인이 다시 만들어지면 이 값이 바뀝니다. 마이그레이션 도구는 모든 메일을 새로 온 것으로 판단해 다시 내려받고, 사용자는 중복 메시지 10,000개를 보게 됩니다. IMAP UID만이 아니라 Message-ID 헤더를 기준으로 중복을 제거하는 도구를 사용해야 합니다.
라우팅 계층 (DNS 전환)
데이터를 복사하는 동안 새 메일의 목적지도 바꿔야 합니다. 이는 MX (Mail Exchange) 레코드로 제어합니다.
Old: MX 10 aspmx.l.google.com
New: MX 10 mx1.trekmail.net
분할 라우팅 위험: 전 세계 인터넷 서비스 제공업체는 DNS 레코드를 캐시에 보관합니다. TTL이 86,400초 (24시간)인데 금요일 5 PM에 MX를 바꾸면 일부 서버는 토요일 5 PM까지 기존 업체로 계속 보냅니다.
해결책은 "300초 규칙"입니다. MX TTL을 300초로 낮추되 이전하기 최소 24시간 전에 적용하세요. 전체 DNS 전환 절차는 도메인에 이메일을 설정하는 방법을 참고하세요.
IMAP으로 옮겨지는 항목과 그렇지 않은 항목
TrekMail은 메일용 IMAP과 SMTP, 사서함별 캘린더 및 연락처 동기화를 위한 CalDAV와 CardDAV를 제공하는 이메일 전문 플랫폼입니다. 문서, 스프레드시트, 화상 통화가 포함된 생산성 도구 모음은 아닙니다. Google이나 M365 같은 통합 도구에서 이메일 전문 호스팅으로 옮길 때는 어떤 항목이 따라오는지 정확히 알아야 합니다.
| 항목 | IMAP으로 이전? | 실제 처리 방식 |
|---|---|---|
| 이메일 | 예 | 두 서버가 지원하는 제목, 본문, 첨부 파일, 날짜를 복사하며 완료 후 항목 수와 표본을 원본과 대조합니다 |
| 폴더 구조 | 예 | 지원되는 하위 폴더를 다시 만들며 Exchange는 깊이를 300단계로 제한합니다 |
| 읽음/읽지 않음 플래그 | 예 | 두 서버가 지원하는 경우 Seen 플래그를 보존합니다 |
| 연락처 | 아니요 | CSV/vCard로 내보낸 뒤 로컬 기기로 가져옵니다 |
| 캘린더 | 아니요 | .ics로 내보내 다른 곳에 호스팅하거나 로컬에 보관합니다 |
| 별칭 | 아니요 | TrekMail 대시보드에서 직접 다시 만듭니다 |
| 서버 측 규칙 | 아니요 | 전달 및 필터 규칙을 다시 만들어야 합니다 |
현대식 인증 방식에서 생기는 단절
Google처럼 OAuth를 강제하는 업체에서 옮길 때는 구형 스캐너나 Outlook 2013 같은 오래된 기기가 표준 IMAP 서버에 연결하지 못할 수 있습니다. Google Workspace 마이그레이션 문서는 앱 비밀번호로 이 차이를 보완하는 방법을 설명합니다. TrekMail은 TLS 1.2를 통한 표준 IMAP/SMTP 인증을 지원합니다. 사용 중인 기기가 이를 지원하는지 확인하세요.
어떤 이메일 이전 방식이 필요한가요?
시나리오 A: Google Workspace 비용 절감
- 도메인을 연결한 TrekMail 계정을 설정합니다
- TrekMail 마이그레이션 도구로 지원되는 이메일 데이터를 복사합니다
- 연락처 (.vcf)와 캘린더 (.ics)를 로컬 파일로 내보냅니다
- MX 레코드를
mx1.trekmail.net/mx2.trekmail.net로 변경합니다 - 복사와 라우팅을 확인한 뒤 Google Workspace를 해지합니다
시나리오 B: 도메인을 새 등록업체로 이전
- 현재 등록업체에서 도메인 이전을 활성화합니다
- EPP/인증 코드를 받습니다
- 새 등록업체에서 이전을 시작합니다
- 중요: 네임서버가 바뀌지 않도록 하거나 영역 파일을 정확히 복사합니다
TrekMail에 내장된 이메일 이전 도구
수동 IMAP 마이그레이션은 오류가 나기 쉽습니다. 단 한 번의 시간 초과나 UIDVALIDITY 변경도 사서함 복사를 망칠 수 있습니다. TrekMail은 마이그레이션을 부가 기능이 아니라 핵심 인프라로 다룹니다.
마이그레이션 엔진
대시보드가 Gmail, cPanel, Exchange 같은 기존 업체에 직접 연결해 서버 간 IMAP 동기화를 처리합니다. 재시도, 속도 제한에 따른 대기, 헤더 기반 중복 제거가 자동으로 수행됩니다. 명령줄은 필요하지 않습니다.
에이전시용 공유 저장 공간
고객 50명을 옮기는 MSP가 저장 공간 할당량 50개를 따로 관리하는 것은 낭비입니다. TrekMail은 모든 도메인이 함께 쓰는 200 GB 같은 공유 저장 공간을 제공합니다. 필요한 곳에 공간을 배분하세요.
DNS 검증
간단한 DNS 검사 도구가 MX, SPF, DKIM 레코드의 설정을 확인하므로 전환 중에 실수로 수신 메일을 모두 차단하는 일을 피할 수 있습니다.
| 요금제 | 가격 | 마이그레이션 엔진 | 공유 저장 공간 |
|---|---|---|---|
| 무료 | $0 (카드 불필요) | 포함 | 아니요 |
| Starter | 월 $3.50 | 포함 | 아니요 |
| Pro | 월 $10 | 포함 | 아니요 |
| Agency | 월 $23.25 | 포함 및 일괄 도구 | 예 |
모든 유료 요금제에는 카드 등록이 필요한 14일 무료 체험이 포함됩니다. Nano 요금제는 카드가 필요하지 않습니다.
결론: 실제로 필요한 이메일 이전 유형을 파악하세요
대부분의 이메일 이전 실패는 도메인 이전, 이메일 마이그레이션, 계정 변경을 혼동해서 발생합니다. 데이터 계층의 IMAP 복사와 라우팅 계층의 DNS 전환을 분리해 서로 다른 일정으로 관리하고, 완료 후 항목 수와 표본을 원본과 대조하세요.
이전할 준비가 되었다면 무료 TrekMail 계정을 만들고 마이그레이션 엔진에 복잡한 작업을 맡기세요.
