기업의 이메일 계정을 이전하는 작업은 개인 받은편지함 하나를 옮기는 것과 다릅니다. 메일은 계속 도착하고 사용자는 답장하며 별칭도 작동해야 합니다. DNS가 잘못되면 두 시스템으로 수신이 나뉠 수 있습니다. 먼저 조사하고 사전 복사한 뒤 전환하세요. DNS를 수정하기 전에 비즈니스 이메일 안내서로 전체 운영 맥락을 살펴볼 수 있습니다.
PST를 내보내고 Outlook에서 폴더를 끌어 옮기며 모든 주소가 일반 계정이라고 가정하면 문제가 남습니다. 월요일에 sales@ 수신이 멈추고 큰 계정은 동기화 중이며 어느 서버가 기준인지 불분명해질 수 있습니다. 이전을 단순 파일 복사가 아닌 운영 중인 인프라 변경으로 다루세요.
이 안내서는 운영자 관점에서 이메일 계정을 이전하는 절차를 설명합니다. IMAP 수동 작업, 전환 순서와 주요 실패 원인, 팀·에이전시·MSP가 자체 스크립트 관리를 줄일 수 있는 TrekMail의 설명된 방식까지 살펴봅니다. 더 빠르거나 중단이 없다는 보장은 아닙니다.
이메일 계정 이전의 의미
IMAP 서버 사이에서 메일 데이터를 복사하고 별칭과 전달을 다시 구성한 뒤 필요한 경우 DNS 수신 경로를 전환합니다. MX 변경은 소유하고 관리하는 도메인의 수신 호스트가 바뀔 때만 적용됩니다. 개인 서비스 주소가 자동으로 이전되는 것은 아닙니다.
IMAP은 메시지, 폴더와 지원되는 상태를 옮기지만 주변 계정 기능까지 복사하지는 않습니다. RFC 3501도 메시지 접근과 메일함 조작을 다루지 기업 계정 전체를 내보내는 형식을 정의하지 않습니다.
따라서 실제로는 세 가지 작업입니다.
- 메시지와 지원되는 폴더 구조 복사.
- 별칭, 배포 목록과 전달 등 라우팅 구성 복구.
- 필요한 자체 도메인의 DNS 수신 경로를 적절한 시점에 변경.
하나를 놓치면 이전이 불완전해져 사용자 문제가 생길 수 있습니다. 데이터와 운영 기능을 함께 검증하세요.
IMAP으로 이전되는 것과 아닌 것
IMAP은 메시지와 폴더, 지원되는 읽음·읽지 않음 상태를 복사합니다. 캘린더, 연락처, 작업, 데스크톱 서명과 앱 규칙, 계정 권한은 별도 계획이 필요합니다. 원본과 대상, 도구의 지원 범위도 확인하세요.
IMAP만 수행하는 프로젝트라면 범위를 문서로 명확히 안내하세요. 설명된 TrekMail 이전은 메일 호스팅용 IMAP 절차이지 협업 계정 전체 복제가 아닙니다. 그래서 원본 호스트, 포트, 사용자 이름, 비밀번호와 대상 계정이 중요하며 공유 일정은 별도입니다.
다음 구분을 참고하세요.
| 항목 | IMAP으로 이전? | 할 일 |
|---|---|---|
| 이메일 메시지 | 지원되면 가능 | 동기화 후 내용과 첨부 파일 검증 |
| 폴더 | 지원되면 가능 | 시험 이전 후 매핑 확인 |
| 읽음·읽지 않음 상태 | 지원에 따라 가능 | 시험 계정에서 플래그 점검 |
| 캘린더 | 아니요 | 별도 내보내기 또는 다른 서비스 유지 |
| 연락처 | 아니요 | CSV나 VCF로 별도 내보내기 |
| 작업과 메모 | 아니요 | 메일 복사 외 절차로 처리 |
| 서버 측 전달 | 아니요 | 허가와 정책에 맞게 재구성 |
| 별칭과 그룹 | 아니요 | MX 전환 전에 재구성 |
특히 마지막 항목을 놓치기 쉽습니다. 별칭과 메일함 비교 안내서로 차이를 확인하면 잘못된 계정 구성을 줄일 수 있습니다.
이전 전에 전체 구성 조사하기
동기화 전에 가능한 한 완전한 목록을 작성하세요. 각 계정, 별칭, 그룹, 전달, 할당량 문제와 큰 계정을 대상 객체 및 이전 그룹에 연결합니다. 필요한 기능을 대상이 지원하는지도 검토하세요.
사용자 목록만으로 부족합니다. 눈에 잘 띄지 않는 의존성도 찾아야 합니다.
적어도 다음을 조사하세요.
- 기본 메일함: 활성 사용자, 공유 및 역할 계정.
- 별칭: 다른 계정으로 배달되는 추가 주소.
- 배포 목록과 그룹: 일반 IMAP 계정이 아닌 라우팅 구성.
- 전달: info@에서 owner@로 보내는 서버 규칙과 허가·정책.
- 캐치올: 유지, 제한 또는 종료 여부 결정.
- 큰 계정: 일찍 준비하고 복사 시작.
큰 계정은 전체 일정에 영향을 줍니다. 제공업체의 IMAP 제한으로 복사가 며칠 걸릴 수 있습니다. 오랜 첨부 파일과 보관 정책을 검토하지 않고 주말 완료를 약속하지 마세요.
예를 들어 금요일 전환 대상은 사용자 60명인데 임원 계정이 48 GB입니다. 일요일에 59명은 완료됐지만 큰 계정은 여전히 복사 중일 수 있습니다. 고정 일정이 아니라 사전 계획의 중요성을 보여 주는 예입니다.
계정 생성도 표준화한다면 계정 일괄 생성 절차를 함께 사용하세요. 프로비저닝 오류도 DNS 오류처럼 이전을 방해할 수 있습니다.
여러 계정의 단계적 이전 계획
한꺼번에 전환하지 말고 그룹으로 나누세요. 시험 그룹은 로그인, 폴더 매핑과 원본 접근을 확인합니다. 사전 복사 그룹은 과거 메일을 옮기고 마지막 그룹은 DNS 전환 전후의 변경을 반영합니다.
실제 순서는 다음과 같습니다.
그룹 1: 시험 이전
IT 직원, 시험 계정과 대표적인 일반 사용자 하나를 선택하세요. 포트 993의 TLS와 인증서 체인·호스트 이름, 전체 계정 로그인 정보를 검증합니다. 보낸편지함, 임시보관함, 보관함과 사용자 폴더의 매핑도 점검하세요.
그룹 2: 사전 복사
전환 주말 전에 대량 복사를 시작하세요. 사용자가 기존 계정을 쓰는 동안 과거 데이터를 옮겨 MX 변경 뒤에 긴 기록의 복사를 처음 시작하지 않도록 합니다.
그룹 3: 변경분과 전환
변경분을 동기화하고 대상을 검증한 뒤 필요한 MX 변경을 수행합니다. 전환 후에도 늦게 도착한 오래된 날짜의 메일, 폴더 이동과 지원되는 플래그를 반복 반영하세요. 캐시와 SMTP 재시도가 남는 동안 원본 수신, 관리용 동기화와 복구 경로를 유지합니다.
이 절차는 제공업체 제한과 주말 작업에 따른 위험을 줄일 수 있지만 중단 없는 이전을 보장하지 않습니다.
imapsync를 이용한 수동 계정 이전
직접 제어가 필요하면 imapsync 같은 IMAP 간 동기화 도구를 사용할 수 있습니다. 재시도, 매핑과 플래그 지원을 활용하려면 설치된 버전과 옵션을 검증해야 합니다.
Outlook 끌어 놓기, PST 내보내기와 기억에 의존한 명령은 일관된 기록을 남기기 어려울 수 있습니다. 무조건 나쁜 방식은 아니지만 통제와 검증이 필요합니다. 앱에서는 원본을 삭제하는 이동 대신 복사를 사용하세요. 프로필 삭제 전에는 동기화되지 않은 로컬 메일, 초안, 연락처와 캘린더를 백업합니다.
계정별 로그와 정해진 변경분 동기화를 갖춘 반복 실행은 추적에 도움이 됩니다. TrekMail의 설명된 기능도 유사한 운영 절차를 제공하며 자체 스크립트 관리를 줄일 수 있습니다. 자세한 내용은 imapsync 운영 안내서를 참고하세요.
다음 예는 그대로 실행할 준비가 된 스크립트가 아닙니다. 셔뱅이 잘못되어 있으며 호스트와 옵션은 현재 앱 설정 및 설치된 도구 버전과 대조해야 합니다. --log는 로그 기능을 켜는 옵션이지 파일 이름을 받는 옵션이 아니므로 --logfile과 다른 유효한 옵션을 확인하세요. 쉼표 기준 읽기는 완전한 CSV 파서가 아니므로 따옴표로 묶인 쉼표, 따옴표나 줄바꿈이 있는 로그인 정보를 제대로 처리하지 못합니다. 암호화만으로 인증서 검증이 입증되지는 않으므로 인증서 체인과 호스트 이름을 명시적으로 검증하세요.
#!$0
# users.csv format:
# source_user,source_pass,dest_user,dest_pass
while IFS=, read -r src_user src_pass dest_user dest_pass
do
echo "[START] $src_user -> $dest_user"
imapsync \
--host1 imap.old-provider.com --user1 "$src_user" --pass1 "$src_pass" --ssl1 \
--host2 mail.trekmail.net --user2 "$dest_user" --pass2 "$dest_pass" --ssl2 \
--automap \
--usecache \
--fast \
--skipsize \
--subfolder2 "Imported_Mail" \
--log "logs/${src_user}.log"
echo "[DONE] Review logs/${src_user}.log"
done < users.csv
실무에서는 다음을 고려하세요.
캐시 활용. 지원되는 저장 상태는 반복 메타데이터 읽기를 줄일 수 있습니다. UID 연결은 개별 폴더와 UIDVALIDITY 범위의 상태이며 전체 서버의 고유 식별자나 내용 해시 검증이 아닙니다. 캐시만으로 중복과 손상을 방지하지는 못합니다.
임시 폴더 활용. Imported_Mail은 복사본을 구분하는 데 도움이 되지만 최종 폴더 경로의 매핑이 필요합니다. 두 계정의 동시 사용이나 이동·삭제 충돌을 해결하지는 않습니다. 활성 사용자 쓰기 환경을 명확히 정하고 내용, 첨부 파일, 날짜와 플래그를 검증하세요.
계정별 로그 보관. 평문 파일 접근을 소유자 등 필요한 사용자로 제한하고 프로세스 인수와 로그의 비밀 정보 노출을 방지하세요. 무조건 출력하는 DONE은 성공 증거가 아닙니다. 종료 상태, 로그, 메시지 수와 내용을 확인해 어느 계정의 어떤 단계가 실패했는지 조사합니다.
DNS 전환을 통제하기
소유한 도메인의 수신 호스트를 바꿀 때는 DNS를 단계적으로 변경합니다. TTL을 미리 낮춰도 기존 캐시는 이전 값에 따라 남습니다. 대상 준비와 사전 복사를 검증한 뒤 전환하고 늦은 메일을 위해 원본 수신을 유지하세요.
복사를 끝낸다고 수신 경로가 바뀌지는 않습니다. DNS가 발신자에게 목적지를 알려 줍니다. 개인 제공업체 도메인의 MX를 바꿀 권한이 생기거나 개인 주소가 이전되는 것은 아닙니다.
캐시와 재시도로 잠시 두 호스트에 메일이 도착할 수 있습니다. 반복 동기화와 한 곳의 활성 사용자 쓰기 환경으로 관리하고 양쪽 계정을 동시에 수정하도록 방치하지 마세요.
계정의 최신 DNS 값을 확인하세요. 아래는 예시이며 실제 SPF 발송 권한을 유지해야 합니다. DMARC는 통과하고 정렬된 SPF 또는 유효하고 정렬된 DKIM 서명으로 통과합니다. 정책은 조사와 테스트 후 결정하며 이전만을 이유로 격리를 적용하지 않습니다.
@ MX 10 mail.trekmail.net.
@ TXT "v=spf1 include:spf.trekmail.net -all"
dkim._domainkey TXT "<unique TrekMail DKIM value>"
_dmarc TXT "v=DMARC1; p=quarantine;"
전환 시 다음을 확인하세요.
- 활성 DNS에서 기존 MX를 제거하되 원본의 늦은 수신 유지.
- 관리하는 도메인의 새 MX 올바르게 게시.
- 모든 사용 중인 발송 서비스를 포함한 SPF 병합.
- DKIM 게시와 실제 서명 검증.
- DMARC 정책 및 정렬 테스트.
- 새 시험 메일의 대상 도착과 원본의 잔여 수신 확인.
전환 뒤에도 수신과 발신을 관찰하세요. Google Postmaster Tools는 적용되는 Gmail 트래픽에 도움이 될 수 있지만 전체 관측이나 받은편지함 도착을 보장하지 않습니다. 마지막 복사 뒤에도 운영 검증은 필요합니다.
TrekMail을 이용한 계정 이전
TrekMail은 서버 측 IMAP 이전 도구를 소개합니다. 자체 VM과 스크립트 관리를 줄일 수 있지만 원본 제한, 진행 상황과 오류는 계속 점검해야 합니다.
다음은 가능한 운영 방식의 비교이며 모든 제공업체에 적용되는 구분은 아닙니다.
| 가능한 수동 방식 | 소개된 TrekMail 방식 |
|---|---|
| Linux 시스템과 도구 운영 | 대시보드에서 이전 시작 |
| 일괄 스크립트 자체 보관과 관리 | 지원되는 기본 이전 절차 활용 |
| 계정별 인증과 폴더 문제 조사 | 제공업체 설정이나 일반 IMAP을 검증해 사용 |
| 일부 서비스에서 사용자별 저장 한도 확대 구매 | 계정 한도 안에서 공유 저장 공간 사용 |
| 사용자 라이선스 비용이 팀과 함께 증가 | 조건에 맞는 여러 도메인 요금제 선택 |
소개된 절차에도 준비와 검증이 필요합니다.
- 도메인과 DNS를 준비하되 대상과 사전 복사 검증 후 MX 전환.
- 대상 계정과 라우팅 구성 생성.
- 대시보드에서 이전 열기.
- 원본 IMAP 호스트, 포트, 전체 사용자 이름과 허용된 로그인 정보 입력.
- TrekMail 계정을 대상으로 선택.
- 가져오기 실행 후 상태와 데이터 확인.
최신 문서인 IMAP 이전 개요, 대시보드에서 이전 시작, 계정 생성, 필수 DNS 기록을 확인하세요. 설명된 가져오기는 직접 IMAP 정보를 사용하며 대화형 OAuth는 제공하지 않습니다. Gmail 앱 비밀번호는 이중 인증과 정책에 따르며 접근이 불가능하면 OAuth 지원의 다른 도구나 제공업체 경로가 필요할 수 있습니다.
소개된 Starter 가격은 월 $3.50, Nano는 $0이며 유료 Starter, Pro, Agency와 Enterprise가 있습니다. Nano는 카드가 필요 없는 무료 요금제, 유료 요금제의 무료 체험은 카드가 필요한 14일로 설명됩니다. 현재 조건과 가격을 확인하세요. 공유 저장 공간이 큰 계정에 도움이 될 수 있어도 계정과 서비스 한도는 남습니다.
요금제 비교는 최신 TrekMail 가격을 확인하세요.
운영 중인 팀의 최종 전환 점검
필요한 MX 전환 직전에 누락된 별칭, 잘못된 로그인, 오래된 DNS와 미완료 복사를 점검하세요. 문제 발견에 도움이 되지만 모든 메일 손실을 방지한다는 보장은 아닙니다.
변경 전에 다음을 확인합니다.
- 모든 대상 계정 생성 및 로그인 성공.
- 별칭, 전달과 그룹을 허가받아 재구성.
- 포트 993의 TLS와 인증서 검증을 통한 원본 IMAP 접근.
- 큰 계정을 일찍 사전 복사.
- TTL 사전 감소와 기존 캐시 만료 고려.
- 기존 MX를 확인과 복구용으로 기록.
- 전환 전후의 변경분 동기화 계획.
- 사용자에게 기존 서버 규칙 수정 중단 시점 안내.
- 수신·발신 시험 계정 준비.
- 전환 후 관측과 정리를 담당할 운영자 지정.
중요한 것은 눈에 띄는 기술이 아니라 사전에 의존성을 확인하고 결과를 검증하는 절차입니다.
결론: 기대가 아닌 절차로 계정 이전하기
도메인 하나든 쉰 개든 이메일 계정을 이전할 때 주소와 기능을 조사하고 데이터를 사전 복사하며 필요한 DNS를 신중하게 전환하세요. 이후 수신과 데이터까지 검증합니다. IMAP 복사만으로 잘못된 설계를 해결할 수는 없습니다.
도구를 직접 관리하고 세밀한 제어가 필요하면 수동 방식이 적합할 수 있습니다. 반복 이전에는 TrekMail의 소개된 여러 도메인 가격, 공유 저장 공간, IMAP 이전과 운영 대시보드를 검토할 수 있습니다. Nano 또는 이전이 필요한 유료 요금제의 현재 가격을 확인하고 기능과 한도를 검토한 뒤 선택하세요.