imapsync 안전한 이메일 이전 운영 가이드

불안감을 주는 마이그레이션 프로젝트를 앞두고 있습니다. 단 하나의 메시지도 잃지 않고, 폴더 구조도 망가뜨리지 않으면서, 이미 소유한 바이트를 옮기는 데 외부 업체의 "마이그레이션 라이선스" 비용으로 사용자당 $15를 내지 않고 Server A의 이메일을 Server B로 이동해야 합니다.

필요한 도구는 imapsync입니다. 이 가이드에서는 사용자의 사서함을 망가뜨리지 않고 imapsync를 사용하는 정확한 방법을 설명합니다.

imapsync란 무엇이며 무엇이 아닌가

imapsync는 두 IMAP 서버 간에 사서함을 동기화하는 명령줄 유틸리티입니다. 프록시 역할을 하면서 두 서버에 동시에 연결하고, 원본에서 메시지를 읽어 대상에 추가합니다. 상태를 추적하고 중단 상황을 처리하며 폴더 구조, 플래그, 메시지 내용을 보존합니다.

백업 도구가 아닙니다. SMTP 릴레이도 아닙니다. Google Calendar, Outlook 연락처 또는 Exchange 전송 규칙은 다루지 않습니다. IMAP만 사용하며 그 외의 것은 처리하지 않습니다. 원본 서버가 방화벽으로 차단되어 있거나 오프라인이면 imapsync는 해당 서버에 접근할 수 없습니다. 그게 전부입니다.

사서함 간 이전에서 업계 표준이 된 이유는 상태 보존 계층에 있습니다. 성공적인 마이그레이션은 단순히 텍스트를 옮기는 일이 아니라 다음 세 가지를 보존하는 일입니다.

콘텐츠: RFC 822 메시지 본문, 첨부 파일, MIME 인코딩 등 메시지 안의 모든 내용입니다.
메타데이터: 플래그입니다. \Seen은 읽음, \Answered는 답장함, \Flagged는 별표 표시를 뜻합니다. 이것들이 이전되지 않으면 모든 사용자는 첫날에 새로 온 읽지 않은 이메일이 4,000개라고 생각하게 됩니다.
구조: 폴더 계층입니다. INBOX/Clients/ProjectA는 새 서버에서도 똑같이 보여야 하며, 이름에 점이 포함된 INBOX.Clients.ProjectA라는 단일 폴더로 합쳐져서는 안 됩니다.

올바르게 구성하기만 하면 imapsync는 이 세 가지를 모두 처리합니다. 구성이 가장 어려운 부분이며, 이 가이드는 바로 그 과정을 설명합니다.

명확한 한계: imapsync가 Gmail의 속도 제한이나 Microsoft의 API 스로틀링을 자체적으로 파악하지는 못합니다. 최고 속도로 실행하면 IP가 차단될 수 있습니다. 또한 데이터를 푸시하지 않으므로 데이터를 특정 위치로 보내려면 직접 가져오는 방식으로 작업해야 합니다. 기본적으로 대상에서 메시지를 삭제하지도 않습니다. 이는 안전 기능이지만 주의하지 않으면 문제가 될 수 있습니다. 자세한 내용은 6단계에서 설명합니다.

프로토콜 자체에 관한 더 폭넓은 설명은 도메인에 이메일을 설정하는 방법 가이드를 참조하십시오.

1단계: 포렌식 사전 조사, 절대 건너뛰지 마십시오

아마추어는 곧바로 복사를 시작합니다. 전문가는 먼저 환경을 점검합니다. 무엇을 옮기는지 모르면 실패할 수밖에 없으며, 문제를 해결하기에 너무 늦은 일요일 새벽 2시에 실패하게 될 것입니다.

1. 대용량 사용자를 찾으십시오

45GB 사서함을 사용하는 사람이 있을 수 있습니다. CEO일 수도 있고, 2011년부터 sales@ 별칭을 소유한 사람일 수도 있습니다. 이 사용자를 500MB 사용자와 같은 배치로 마이그레이션하려 하면 배치가 멈추고, 얼마나 진행되었는지 전혀 모르는 채 정지된 터미널만 바라보게 됩니다.

먼저 사전 검사를 실행하십시오.

imapsync \
  --host1 imap.source.com --user1 user@source.com --passfile1 /secret/pass1 \
  --host2 imap.dest.com --user2 user@dest.com --passfile2 /secret/pass2 \
  --dry --justfoldersizes

이 명령은 메시지를 하나도 건드리지 않고 폴더별 현황을 보여 줍니다. 10GB가 넘는 사서함은 더 긴 시간 제한, 전용 실행 시간대, 관리자의 집중적인 관리를 포함한 별도 처리가 필요합니다.

2. 다크 데이터 문제

어느 회사에나 좀비 계정이 있습니다. 이메일이 여전히 어딘가로 전달되는 퇴사자 계정이나, 실제로는 프린터 또는 오래된 CRM 통합에 쓰이는 공유 받은편지함인 "서비스 계정"이 이에 해당합니다. 인벤토리 작성 중 이런 계정을 빠뜨리면 DNS를 전환할 때 해당 데이터가 기존 시스템에 고립됩니다.

원본 사용자 목록을 실제 활성 사용자와 대조하십시오. bob@company.com이 삼 년 전에 퇴사했다면 지금 결정해야 합니다. 그의 사서함을 마이그레이션할지, EML 내보내기로 보관할지 선택하십시오. 전환 전에 결정하지 않으면 가장 나쁜 시점에 압박을 받으며 결정하게 됩니다. 전체 사전 점검용 인벤토리 템플릿은 고객 이메일 관리 가이드를 참조하십시오.

3. 실제로 중요한 항목 수

기가바이트 단위의 크기는 절대 그대로 믿지 마십시오. 원본 Server A는 사서함을 10GB로 보고하지만 대상 Server B는 정확히 같은 데이터를 11GB로 보고할 수 있습니다. 이는 버그가 아닙니다. 서버마다 저장 용량을 계산하는 방식이 다릅니다. Exchange는 Recoverable Items 폴더, 즉 "Dumpster"를 포함합니다. Gmail은 여러 라벨에 걸친 메시지를 중복 제거합니다.

중요한 지표는 항목 수입니다. 원본에 메시지가 14,200개 있고 대상에도 14,200개가 있다면 작업이 끝난 것입니다. 바이트 차이가 10% 미만인 것은 정상이며 예상 가능한 범위입니다. 10%를 넘는다면 완료 승인 전에 조사하십시오.

2단계: 안전한 마이그레이션 작업 흐름

모든 마이그레이션에서 가장 큰 실수는 금요일 밤에 전부 옮기고 월요일 아침까지 끝나기를 바라는 "Big Bang" 접근 방식입니다. 이메일이 50GB이고 속도가 500KB/s로 제한되어 있다면 계산이 맞지 않습니다. 월요일에도 서비스가 중단된 상태로 CEO에게 받은편지함이 왜 비어 있는지 설명하게 됩니다.

전문적인 접근 방식은 단계적 마이그레이션입니다. 사용자가 여전히 기존 시스템을 이용하는 동안 대부분의 데이터를 먼저 옮기고, 실제 전환 시점에 아주 작은 최종 델타만 처리합니다.

1단계: 시험 실행

단 하나의 바이트라도 옮기기 전에 연결할 수 있는지 확인하십시오. --dry를 --justfolders와 함께 사용합니다. 실제 복사 없이 실행을 시뮬레이션하고 폴더 구조를 보여 줍니다.

imapsync \
  --host1 imap.gmail.com --user1 user@source.com --passfile1 /secret/pass1 \
  --host2 imap.trekmail.net --user2 user@dest.com --passfile2 /secret/pass2 \
  --dry --justfolders

두 가지를 확인하십시오. 인증에 성공했는지, 폴더 이름이 어떻게 표시되는지 살펴봅니다. 원본에 [Gmail]/Sent Mail이 있다면 대상의 Sent Items에 매핑해야 합니다. 실제 전환 중에야 이 사실을 발견해서는 안 됩니다.

2단계: 대량 동기화 (사전 이전)

사용자가 기존 시스템을 이용하는 동안 전환 1-2주 전에 이 작업을 실행하십시오. 핵심 경로에서 데이터의 90-95%를 미리 옮기는 것이 목표입니다.

imapsync \
  --host1 imap.source.com --user1 user@source.com --passfile1 /secret/pass1 \
  --host2 imap.dest.com --user2 user@dest.com --passfile2 /secret/pass2 \
  --usecache --skipsize --maxsize 25000000

--usecache는 반드시 사용해야 합니다. 마이그레이션 상태를 로컬에 저장합니다. 이후 실행할 때마다 이 캐시와 비교하여 변경 사항만 처리하므로 모든 메시지를 처음부터 다시 검사하지 않습니다. 이 옵션이 없으면 매번 전체 검사를 수행합니다.

--maxsize 25000000은 첫 번째 패스에서 25MB보다 큰 메시지를 건너뜁니다. 대용량 첨부 파일은 시간 초과와 연결 끊김을 가장 자주 일으킵니다. 시간 제한을 늘린 전용 실행에서 따로 처리할 수 있습니다.

3단계: 델타 동기화

전환 며칠 전에 다시 실행하십시오. imapsync는 캐시를 읽고 대상에 이미 이메일 10,000개가 있음을 확인한 뒤 이를 건너뛰고, 대량 동기화 이후 도착한 새 메시지 50-100개만 복사합니다. 이 실행은 몇 시간이 아니라 몇 분 안에 끝나야 합니다.

4단계: 전환

이제 결정적인 순간입니다. 다음 순서대로 처리하십시오.

DNS TTL 낮추기: 전환 48시간 전에 MX 레코드의 TTL을 300초로 설정합니다. 마지막 순간까지 기다리면 일부 리졸버가 최대 24시간 동안 이전 MX를 캐시하므로 이미 전환한 뒤에도 이메일이 기존 서버에 도착합니다.
MX 레코드 전환: 새 호스트를 가리키도록 변경합니다.
주요 리졸버 전체에서 전파가 안정될 때까지 60분간 기다립니다.
최종 델타 실행: imapsync를 마지막으로 한 번 실행하여 전파 시간 동안 기존 서버에 도착한 메시지를 모두 가져옵니다.

DNS 전환 시간대와 전파 중 확인해야 할 사항에 관한 자세한 안내는 도메인에 이메일을 설정하는 방법 가이드를 참조하십시오.

3단계: 플래그, 폴더 및 보낸 편지함의 함정

IMAP 서버마다 서로 다른 방언을 사용합니다. 이 차이를 변환하지 않으면 사용자는 구조가 망가진 사서함을 마주하게 되고, 당연히 관리자를 탓할 것입니다.

구분자 문제

이는 직접 겪기 전까지는 아무도 이야기하지 않는 가장 흔한 기술적 실패입니다.

IMAP 서버마다 폴더 계층의 수준을 구분하는 문자가 다릅니다.

Dovecot은 일반적으로 점을 사용합니다: INBOX.Clients.ProjectA
Exchange/Outlook은 슬래시를 사용합니다: INBOX/Clients/ProjectA
일부 서버는 구분자를 전혀 사용하지 않고 IMAP NAMESPACE 명령에 의존합니다

아무런 확인 없이 마이그레이션하면 imapsync가 대상에 문자 그대로 INBOX.Clients.ProjectA라는 폴더를 만들 수 있습니다. 세 단계로 중첩된 계층이 아니라 이름에 점이 들어간 하나의 단일 폴더가 만들어지는 것입니다. 모든 사용자의 폴더 구조가 폭발한 것처럼 보이게 됩니다.

해결책은 정규식을 이용해 전송 중 폴더 경로를 다시 작성하는 --regextrans2입니다. 사용자 100명의 배치를 실행하기 전에 항상 하나의 테스트 계정에서 --dry로 폴더 생성을 시험하십시오.

보낸 편지함의 혼란

서버마다 보낸 편지함의 이름이 다릅니다. 이를 무시하면 단순한 불편을 넘어 사용자 경험에 심각한 문제가 생깁니다.

이메일 플랫폼	보낸 편지함 이름
Gmail / Google Workspace	`[Gmail]/Sent Mail`
Outlook / Exchange	`Sent Items`
cPanel / Courier	`Sent`
독일 서버	`Gesendete Elemente`
스페인 서버	`Enviados`

이러한 폴더를 매핑하지 않으면 사용자에게 보낸 편지함이 두 개 생깁니다. 현재 사용하는 Sent Items와 전체 과거 기록이 들어 있는 Sent Mail이라는 새 유령 폴더입니다. 사용자는 이를 바로 알아차릴 것이며 결코 만족하지 않을 것입니다.

다음과 같이 명시적으로 매핑하십시오.

--regextrans2 's/^\[Gmail\]\/Sent Mail/Sent Items/'

이 명령은 imapsync에 다음과 같이 지시합니다. "원본 폴더가 [Gmail]/Sent Mail로 시작하면 대상에서 이름을 Sent Items로 변경하십시오." 변경을 확정하기 전에 먼저 전체 폴더 매핑을 --dry 패스로 실행하여 각 매핑이 올바르게 적용되는지 확인하십시오.

Gmail All Mail의 함정

Gmail에는 [Gmail]/All Mail이라는 폴더가 있습니다. 라벨과 관계없이 모든 이메일의 사본이 하나씩 들어 있습니다. Gmail 내부의 전체 보기 기능이 IMAP 폴더로 노출된 것입니다.

All Mail과 Inbox와 Sent Mail을 마이그레이션하면 대상에서 모든 이메일이 두세 번씩 중복됩니다. 10GB 사서함이 30GB가 되고 모든 메시지가 여러 번 나타납니다. 심각한 문제입니다.

항상 다음과 같이 제외하십시오.

--exclude "All Mail"

반드시 가져와야 할 특별한 이유가 없다면 [Gmail]/Spam과 [Gmail]/Trash도 제외하십시오. 오래된 스팸까지 마이그레이션하려는 사람은 없습니다.

4단계: 성능 조정 및 속도 제한

Google이나 Microsoft에 데이터를 무제한으로 밀어 넣을 수는 없습니다. 이들의 인프라는 대용량 IMAP 연결을 서비스 거부 공격과 똑같이 취급합니다. 해당 업체의 관점에서는 둘이 똑같아 보이기 때문입니다.

제한에 따른 불이익

보통 Gmail 기준 초당 메시지 1개 또는 시간당 500MB 정도인 속도 제한을 넘으면 서버가 HTTP 429, NO [OVERQUOTA] 또는 단순히 BAD 오류를 반환하기 시작합니다. 계속 요청하면 계정이 24시간 동안 잠깁니다. 지원팀에 이런 문제로 문의하고 싶지는 않을 것입니다.

조정 옵션

--maxmessagespersecond 1     # Hard speed limit: 1 email per second
--maxbytespersecond 500000   # Bandwidth cap: 500KB/s
--timeout 120                # Network timeout in seconds (default is often too short for big attachments)
--reconnectretry1 3          # Retry on source connection drops
--reconnectretry2 3          # Retry on destination connection drops

초당 메시지 1개는 답답할 정도로 느리게 들립니다. 실제로도 느립니다. 하지만 꾸준히 진행되며 결국 완료됩니다. 3시간째에 차단되는 공격적인 실행은 영원히 끝나지 않습니다.

MSP 참고 사항: 여러 고객의 마이그레이션을 병렬로 실행하더라도 같은 원본 서버를 대상으로 동시에 실행해서는 안 됩니다. 시작 시간을 분산하십시오. 각 병렬 스트림에 별도의 속도 제한 여유가 필요합니다.

TrekMail로 마이그레이션하는 경우, 당사의 IMAP 수집 시스템은 다수의 동시 연결을 원활히 처리합니다. Google이나 Microsoft를 원본으로 사용할 때보다 대상 측에 더 높은 속도로 데이터를 보낼 수 있습니다.

5단계: 인증, 최신 인증 방식의 장벽

password123을 일반 텍스트 파일에 넣던 시대는 끝났습니다. Google과 Microsoft 모두 IMAP의 Basic Auth를 폐지했습니다. 표준 로그인 자격 증명을 사용하면 인증 오류와 함께 실패하며 무엇이 잘못되었는지 한 시간 동안 고민하게 됩니다.

앱 비밀번호 (중소기업 방식)

단일 도메인 마이그레이션에서는 대부분 앱 비밀번호가 가장 빠른 방법입니다. 앱 비밀번호는 16자 문자열로, 2FA를 우회하며 기존 IMAP 클라이언트에서 작동합니다.

원본 계정에 로그인합니다 (Gmail, Workspace 등)
2-Factor Authentication이 아직 활성화되지 않았다면 사용 설정합니다 (앱 비밀번호 생성에 필요)
Security settings → App Passwords로 이동합니다
"Other device"의 "Mail"용 비밀번호를 생성합니다
해당 문자열을 imapsync --passfile의 비밀번호로 사용합니다

명령줄이 아니라 chmod 600으로 권한을 설정한 파일에 저장하십시오. bash 기록에 자격 증명을 남기는 것은 언젠가 문제를 일으킬 수밖에 없습니다.

OAuth2 (MSP / 엔터프라이즈 방식)

사용자 500명을 마이그레이션하는 MSP라면 앱 비밀번호 500개를 수동으로 생성할 수 없습니다. OAuth2가 필요합니다. 더 복잡하지만 대규모 환경에서 유일하게 현실적인 방법입니다.

원본 테넌트에 애플리케이션을 등록합니다 (Microsoft는 Azure AD, Google은 Google Cloud Console)
테넌트 전체의 모든 사서함에 접근할 수 있는 권한을 부여합니다 (Global Admin 승인 필요)
사용자별 Refresh Token을 생성하거나 서비스 계정 가장을 사용합니다
--oauthaccesstoken1을 통해 토큰을 imapsync에 전달합니다

Azure AD 또는 GCP에서 애플리케이션 권한을 잘못 구성하면 모든 사서함에서 접근이 거부되거나, 더 심각하게는 의도한 것보다 광범위한 권한이 실수로 부여됩니다. "Grant admin consent"를 클릭하기 전에 권한 범위를 주의 깊게 읽으십시오.

대규모 마이그레이션의 실무적인 내용은 고객 이메일 관리 접근 방식에 관한 가이드를 참조하십시오.

6단계: 일반적인 실패 유형과 복구

아무리 완벽한 계획이라도 문제는 생깁니다. 처음부터 다시 시작하지 않고도 무엇이 잘못되었는지 파악하고 해결하는 방법을 소개합니다.

1. UIDVALIDITY 문제 (최악의 시나리오)

각 IMAP 폴더에는 UIDVALIDITY라는 고유 식별자가 있습니다. imapsync는 이 값을 이용해 이미 복사한 메시지를 추적합니다. 원본 서버의 폴더가 삭제된 뒤 다시 만들어지거나 서버의 인덱스가 손상되어 재구성되면 이 ID가 바뀝니다.

증상: imapsync는 새 UIDVALIDITY를 발견하면 완전히 새로운 폴더라고 간주하고 모든 항목을 다시 다운로드합니다. 이제 해당 폴더의 모든 메시지가 중복됩니다. 규모가 크면 수백 개 사서함에 걸쳐 수천 개의 중복 메시지가 생깁니다.

해결 방법: 임시 디렉터리에서 로컬 캐시 파일을 삭제한 다음 --useheader를 사용하여 다시 실행하십시오.

--useheader

이 옵션을 사용하면 imapsync가 폴더 UID에 의존하는 대신 변경할 수 없고 고유한 각 이메일의 Message-ID 헤더를 비교합니다. 속도는 느리지만 중복을 피하는 데 더 유리합니다. 원본 서버의 인덱스가 변경되었다고 의심될 때 사용하기에 적합합니다.

2. 손상된 메시지와 제로 바이트 메시지

오래된 서버에는 본문이 없는 헤더나 정확히 0바이트인 파일과 같은 "유령" 메시지가 쌓입니다. 대개 실패한 가져오기, 중단된 전송 또는 수년간 유지 관리가 미뤄진 아주 오래된 서버 때문에 생깁니다.

증상: imapsync가 메시지를 가져오려고 하면 서버가 120초 동안 멈춘 뒤 연결을 끊습니다. 같은 메시지에서 이 과정이 끝없이 반복됩니다.

해결 방법:

--minbytes 10

이 옵션은 10바이트보다 작은 메시지를 건너뛰도록 imapsync에 지시합니다. 정상적인 이메일이 10바이트 미만인 경우는 거의 없습니다. 사실상 "빈 파일 건너뛰기" 필터이며 대부분의 마이그레이션에 적용할 수 있습니다.

3. 좀비 삭제 문제

월요일에 대량 동기화를 실행했습니다. 화요일에는 사용자가 원본에서 이메일 50개를 삭제했습니다. 수요일에 델타를 실행합니다.

기본적으로 imapsync는 메일을 추가할 뿐이며, 원본에서 삭제된 항목을 대상에서 삭제하지 않습니다. 이는 의도된 동작이며 대부분의 사용 사례에 적합합니다. 하지만 삭제된 이메일 50개가 새 사서함에 다시 나타난다는 뜻이기도 합니다. 사용자는 이를 "유령 이메일" 또는 "삭제했는데 다시 나타난 이메일"이라고 신고할 것입니다.

해결책은 --delete2이지만 극도로 주의해서 사용해야 합니다.

--delete2

이 옵션은 imapsync에 다음과 같이 지시합니다. 메시지가 원본에 없으면 대상에서 삭제하십시오.

MX 전환 전 사전 이전 단계에서만 사용하십시오. 전환 후 실행하면 MX가 이미 대상을 가리키고 있어서 대상에 도착한 새 메일이 이전 원본에 존재하지 않는다는 이유로 삭제됩니다. 이메일을 잃게 됩니다. 전환 후에는 --delete2를 사용하지 마십시오.

4. 대용량 첨부 파일에서 연결 끊김

40MB PDF 첨부 파일은 시간 제한이 짧은 IMAP 연결을 때때로 멈추게 합니다. 서버가 메시지를 보내는 중 네트워크가 순간적으로 불안정해지면 95% 지점에서 연결이 끊기고, imapsync는 오류를 기록한 뒤 다음 항목으로 넘어갑니다. 그 결과 대상에는 불완전한 메시지가 남습니다.

해결 방법: 대용량 첨부 파일을 처리하는 패스에서는 --timeout을 300초로 늘리십시오. 대량 동기화에서 해당 파일을 건너뛰도록 --maxsize 25000000을 사용하는 것도 고려하십시오. 이후 속도 제한과 시간 제한을 완화한 대용량 첨부 파일 전용 패스를 실행합니다.

검증: 성공을 입증하는 방법

스크립트가 끝났고 터미널에는 완료되었다고 표시됩니다. CEO의 이메일이 어디선가 널 라우트로 사라지지 않았다는 것을 어떻게 알 수 있을까요?

1. 요약 블록 확인

imapsync는 매번 실행이 끝날 때 요약을 출력합니다. 다음 세 가지 숫자가 중요합니다.

Transferred: 최종 델타 실행에서 0이어야 합니다. 영이 아니면 아직 이전되지 않은 메시지가 있다는 뜻입니다.
Skipped: 전체 원본 메시지 수와 같거나 그보다 많아야 합니다. 이미 대상에 있는 메시지입니다.
Errors: 0이어야 합니다. 오류 수가 영이 아니면 완료로 판단하기 전에 반드시 조사해야 합니다.

2. 표본 검사

로컬 저장소가 캐시되지 않은 새로운 IMAP 클라이언트로 새 사서함에 로그인하십시오. 캐시된 클라이언트를 사용하면 검사 목적을 달성할 수 없습니다. 다음을 확인합니다.

Sent Items: 여러 해 동안 보낸 메일이 올바른 계층으로 들어 있습니까?
깊이 중첩된 하위 폴더: 계층이 올바르게 보입니까?
가장 최근 이메일: 원본에 표시되는 것과 같은 이메일입니까?
플래그 또는 별표 표시된 메시지: \Flagged 속성이 이전되었습니까?

3. 포렌식 검색

사용자가 이메일이 사라졌다고 신고했습니다. "분실된 것 같다"고 말하기 전에 로그를 확인하십시오.

grep -i "bob@sender.com" /var/log/imapsync/user@source.com.log

로그는 각 메시지의 처리 결과를 모두 기록합니다. Transferred, 이미 대상에 있는 Skipped, 또는 구체적인 오류 코드가 포함된 Error로 표시됩니다. Error라면 정확히 어떤 메시지와 폴더에서 어떤 오류 코드가 발생했는지 알 수 있습니다. 추측이 아니라 이 정보에서 복구를 시작해야 합니다.

4. 항목 수 감사

최종적으로 정상 여부를 확인하려면 두 서버를 직접 조회하십시오.

# On source (example for Dovecot)
doveadm mailbox status -u user@source.com messages '*'

# Or use imapsync's own count
imapsync ... --dry --justfoldersizes 2>&1 | grep "Messages"

원본 항목 수와 대상 항목 수를 비교하십시오. 스팸 폴더 제외와 Gmail All Mail 중복 제거를 고려하면 두 수치는 1-2% 이내에서 일치해야 합니다. 차이가 더 크다면 승인하기 전에 오류 로그를 자세히 살펴보십시오.

대안: 터미널을 사용하지 않는 방법

당사가 이 가이드를 작성한 이유는 투명성을 중요하게 생각하기 때문입니다. imapsync는 완전한 제어를 원하고 Perl 종속성, OAuth2 앱 등록, 로그 포렌식 작업을 직접 처리하는 데 부담이 없는 운영자에게 적합한 도구입니다.

하지만 첫 도메인을 이전하는 창업자든 고객 계정 200개를 마이그레이션하는 에이전시든, 많은 운영자에게는 이 모든 것을 구성하는 데 드는 시간 비용이 소프트웨어 비용 절감분보다 큽니다.

접근 방식	가장 적합한 경우	감수해야 할 비용
imapsync (직접 수행)	시스템 관리자, 완전한 제어가 필요한 상황, 특이한 원본 서버	도구 비용을 없애는 대신 필요한 시간과 전문성
TrekMail 내장 마이그레이션	시간을 중요하게 생각하는 창업자, 에이전시 및 운영자	속도와 단순성을 얻는 대신 포기하는 세부 플래그 제어
외부 마이그레이션 업체	규정 준수 요구 사항과 예산이 있는 엔터프라이즈	SLA 보장을 받는 대신 지불하는 비용 (보통 사용자당 $15-$25)

TrekMail의 내장 마이그레이션 도구는 서버 측에서 작동합니다. Outlook에서 세 시간 동안 폴더를 끌어다 놓거나 Perl 종속성 문제에 시달릴 필요가 없습니다. 원본 (Gmail, cPanel 또는 표준 IMAP 서버)을 지정하고 자격 증명을 입력하면 서버가 전송을 처리합니다. 대시보드에서 진행 상황도 확인할 수 있습니다.

가격 모델도 일반적으로 익숙한 방식과 다릅니다. 사용자별 요금이 없습니다. 월 $3.50부터 시작하는 정액 요금제로 최대 100명의 사용자를 50개 도메인에 걸쳐 지원하며, 전체 사용자가 스토리지를 공유합니다. 첨부 파일이 40GB인 임원 한 명 때문에 모든 사용자의 요금제를 업그레이드할 필요가 없습니다. 계정 전체가 스토리지를 공유하기 때문입니다.

각 요금제에 포함된 항목을 비교하려면 TrekMail 요금을 참조하십시오. 마이그레이션 도구의 구체적인 단계별 안내는 문서의 마이그레이션 시작 가이드를 참조하십시오.

imapsync로 직접 스크립트를 작성하든 당사 플랫폼을 사용하든 목표는 같습니다. 데이터 손실이나 혼란 없이, 사용자별 통행료를 내지 않고 이메일을 옮기는 것입니다.

사용자별 요금 지불을 중단하고 마이그레이션까지 맡기고 싶다면 TrekMail을 무료로 사용해 보십시오. 14일 무료 체험이며 카드가 필요하지 않습니다.

imapsync로 안전하게 이메일을 이전하는 운영 가이드 (2026)