Google Workspace에서 다른 메일 호스팅 서비스로 신중하게 이전하면 전체 기간은 약 일주일, 실제 작업 시간은 3-4시간 정도입니다. 핵심은 두 시스템이 동시에 메일을 받도록 구성하는 것입니다. Workspace에서 계속 메일을 받는 동안 새 호스트를 설정하고, IMAP 마이그레이션 도구로 기존 메일을 백그라운드에서 복사합니다. 그런 다음 DNS TTL을 낮춘 상태에서 MX 레코드를 바꾸면 전환 시간을 몇 시간이 아닌 몇 분으로 줄일 수 있습니다.
대부분의 'Google Workspace 이전' 안내서는 DNS 변경 사항이 전파되는 동안 메시지가 누락되는 일괄 전환 방식을 설명합니다. 이 방식은 수신량에 따라 보통 10-50개의 메시지를 잃게 됩니다. 아래의 여섯 단계 방식에서는 메일이 하나도 누락되지 않습니다. 설정에 30분을 더 투자하면, 이전이 끝난 뒤 '그 고객의 메일은 어디로 갔지?'라며 당황하는 일을 막을 수 있습니다.
이 안내서에서는 구체적인 DNS 레코드 예시와 함께 여섯 단계 마이그레이션 절차를 살펴봅니다. 전체적인 이전 과정은 Google Workspace에서 메일 마이그레이션하기를 참고하세요.
Google Workspace 이전이 생각보다 어렵지 않은 이유
Google Workspace에서 이전하는 일이 부담스럽게 느껴지는 이유는 하나의 계정에 메일, 캘린더, Drive, Meet가 모두 묶여 있기 때문입니다. 복잡해 보이는 원인은 대부분 이 통합 구성에 있습니다. 메일만 따로 보면 IMAP과 DNS 레코드가 전부이며, IMAP을 지원하는 호스트라면 어디로든 깔끔하게 옮길 수 있습니다.
실제 이전 작업은 명확하게 나눌 수 있습니다. 메일은 아래 여섯 단계에 따라 1-2일 동안 작업합니다. 캘린더는 Workspace에서 내보낸 다음 새 캘린더 호스트로 가져옵니다. Fastmail Calendar, Apple Calendar 또는 직접 운영하는 CalDAV를 사용할 수 있습니다. Drive는 rsync와 같은 방식으로 새 파일 스토리지 호스트에 복사합니다. Meet는 가입 단계에서 Zoom 같은 서비스로 대체합니다. 각 항목을 따로 옮길 수 있으므로 전체 프로젝트는 'Google Workspace 이전'이라는 말에서 받는 인상만큼 부담스럽지 않습니다.
한눈에 보는 여섯 단계 마이그레이션
다음 여섯 단계에 따라 진행하면 전환 중에 수신되는 메시지를 잃지 않고 Google Workspace 메일을 이전할 수 있습니다. 순서가 중요합니다. 각 단계의 결과가 다음 단계의 기반이 되며, 하나라도 건너뛰면 이후 과정에 빈틈이 생겨 DNS 변경 사항이 전파되는 동안 배송 중인 메일이 누락될 수 있습니다.
- 48시간 전에 DNS TTL을 낮춥니다. 전환 시 MX 레코드가 전파되는 시간을 몇 시간에서 몇 분으로 단축합니다.
- 새 호스트를 준비합니다. 새 메일 호스트에 도메인을 추가하고 기존과 같은 메일함을 만듭니다.
- 백그라운드에서 IMAP 마이그레이션을 실행합니다. Workspace에서 계속 메일을 받는 동안 기존 메일을 새 호스트로 복사합니다.
- MX 레코드를 전환합니다. DNS가 새 메일 호스트를 가리키도록 변경합니다. 전파되는 동안 두 시스템에서 메일을 동시에 받습니다.
- 검증 및 왕복 테스트를 진행합니다. 세 개 수신 서비스에서 인증을 통과하는지 확인합니다.
- Workspace 운영을 종료합니다. MX 레코드 전환 후 48-72시간을 기다린 다음 Workspace 메일함을 비활성화합니다.
전체 과정은 약 일주일이 걸립니다. 실제 작업 시간은 그 기간에 걸쳐 3-4시간 정도입니다. 여섯 단계 절차를 정확히 따르면 계획 없이 Google Workspace를 이전할 때 반복적으로 발생하는 메일 손실을 막을 수 있습니다.
1단계: 48시간 전에 DNS TTL 낮추기
Google Workspace 이전의 첫 번째 단계는 예정된 전환 48시간 전에 MX 레코드의 DNS TTL을 낮추는 것입니다. Workspace의 기본 MX TTL은 보통 3600, 즉 한 시간입니다. 이를 300, 즉 오 분으로 낮추면 4단계에서 MX 레코드를 빠르게 전환할 수 있습니다.
; before - default TTL
yourcompany.com. 3600 IN MX 1 aspmx.l.google.com.
; after - low TTL for cutover window
yourcompany.com. 300 IN MX 1 aspmx.l.google.com.
DNS 호스트에서 각 MX 레코드의 TTL을 수정합니다. 캐시가 만료되면서 변경 사항은 이후 1-2시간에 걸쳐 전파됩니다. 낮아진 TTL이 전 세계에 완전히 반영되도록 48시간을 기다리세요. 6단계에서 마이그레이션이 끝나면 정상 운영을 위해 TTL을 다시 3600으로 올립니다.
2단계: 새 호스트 준비하기
Google Workspace 이전의 두 번째 단계에서는 새 메일 호스트를 준비합니다. TrekMail 또는 선택한 대체 서비스에 가입하세요. 관리 화면에서 도메인을 추가하고 확인용 TXT 레코드로 소유권을 인증합니다. Workspace에서 사용하던 것과 같은 이름의 메일함을 만드세요. 예를 들어 sarah.smith@, mike.davis@ 등이 있습니다. SPF, DKIM, DMARC 값을 생성하되 아직 게시하지는 마세요. 이 레코드는 4단계에서 게시합니다.
이 시점에는 새 호스트의 메일함이 준비되어 있지만 MX 레코드는 여전히 Workspace를 가리킵니다. 따라서 실제 메일은 아직 새 메일함으로 들어오지 않습니다. 이 준비 작업을 마치면 4단계에서 두 시스템이 동시에 메일을 받는 방식으로 원활하게 전환할 수 있습니다. 대체 서비스 선택에 대한 자세한 내용은 Google Workspace 대체 서비스를 참고하세요.
3단계: 백그라운드에서 IMAP 마이그레이션 실행하기
Google Workspace 이전의 세 번째 단계에서는 백그라운드로 IMAP 마이그레이션을 실행합니다. TrekMail의 서버 측 IMAP 마이그레이션 도구를 사용하면 됩니다. 메일함별로 Workspace IMAP 인증 정보를 입력하면 Workspace에서 새 메일을 계속 받는 동안 도구가 몇 시간에 걸쳐 폴더별로 복사합니다.
대부분의 마이그레이션은 24시간 이내에 끝납니다. 사용자당 메일함 용량이 일반적인 1-10GB일 때의 기준입니다. 50GB가 넘는 대용량 메일함은 시간이 더 걸립니다. 4단계를 시작하기 전에 기존 메일이 새 호스트에 모두 복사되도록 전환에 앞서 마이그레이션을 실행하세요. 관리 화면에서 진행 상황을 확인할 수 있습니다. 개별 메일함에 확인이 필요한 IMAP 문제가 있으면 도구가 메일함별로 오류를 표시합니다.
4단계: MX 레코드 전환하기
Google Workspace 이전의 네 번째 단계에서는 MX 레코드가 새 호스트를 가리키도록 변경합니다. 2단계에서 받은 새 MX 값과 SPF, DKIM, DMARC 레코드를 게시하세요. DNS 변경 사항은 약 5분이면 전파됩니다. 1단계에서 TTL을 낮춰 두었기 때문입니다.
; new MX pointing at TrekMail
yourcompany.com. 300 IN MX 10 mx1.trekmail.net.
yourcompany.com. 300 IN MX 20 mx2.trekmail.net.
; authentication records
yourcompany.com. 300 IN TXT "v=spf1 include:_spf.trekmail.net ~all"
trekmail._domainkey.yourcompany.com. 300 IN TXT "v=DKIM1; k=rsa; p=..."
_dmarc.yourcompany.com. 300 IN TXT "v=DMARC1; p=none; rua=mailto:dmarc-reports@yourcompany.com"
변경 사항이 전파되는 동안 일부 발신 서버는 계속 Workspace로 보내고, 나머지는 새 호스트를 사용합니다. 두 시스템이 동시에 수신하므로 메일이 반송되지 않습니다. DNS 캐시가 오래 유지되는 발신 서버에서 배송 중인 메일도 받을 수 있도록 MX 레코드 전환 후 최소 48-72시간 동안 Workspace 메일함을 활성 상태로 유지하고 접속할 수 있게 하세요.
5단계: 검증 및 왕복 테스트하기
Google Workspace 이전의 다섯 번째 단계에서는 새 호스트에서 보낸 메일의 인증 결과를 확인합니다. 각 메일함에서 Gmail, Outlook.com, Yahoo 계정으로 테스트 메시지를 보내세요. 세 곳 모두에서 헤더에 SPF=PASS, DKIM=PASS, DMARC=PASS가 표시되는지 확인합니다. 하나라도 FAIL이 나오면 실제 운영을 시작하기 전에 4단계에서 게시한 레코드를 수정해야 합니다.
수신도 확인하세요. 외부 주소에서 새 메일함 중 하나로 테스트 메시지를 보냅니다. 몇 분 안에 새 호스트로 도착하는지 확인하세요. 메일이 Workspace로 도착한다면 DNS 전파가 아직 끝나지 않은 것입니다. 10-15분 더 기다린 뒤 다시 테스트하세요. 검증은 반드시 거쳐야 합니다. 이를 건너뛰면 전환 시점에 발견할 수 있었던 전송 신뢰도 문제가 대규모 운영 중에 드러나게 됩니다.
6단계: Workspace 운영 종료하기
Google Workspace 이전의 여섯 번째 단계는 MX 레코드 전환 후 48-72시간이 지나 Workspace 메일함 운영을 종료하는 것입니다. 이때는 DNS 변경 사항이 전 세계에 모두 반영된 상태입니다. 관리 콘솔에서 메일함을 비활성화하고 현재 결제 주기가 끝날 때 구독을 해지하세요. DNS TTL은 다시 3600으로 올립니다.
나중에 과거 자료를 확인해야 할 때를 대비해 최종 해지 전에 Workspace 데이터 내보내기 파일을 보관하세요. 메일, 캘린더, Drive가 대상입니다. Google Takeout으로 내보낸 뒤 구독이 종료되기 전에 로컬 스토리지에 다운로드합니다. 그러면 새 호스트와 별개로 과거 Workspace 상태를 백업해 둘 수 있습니다. 체계적인 작업 목록은 이메일 마이그레이션 체크리스트를 참고하세요.
다음 단계
Google Workspace 메일을 이전하는 여섯 단계 방식은 전체 기간이 약 일주일이고 실제 작업은 3-4시간 정도입니다. 두 시스템에서 동시에 메일을 받도록 올바르게 구성하면 한 건의 메일도 잃지 않습니다. DNS 변경 사항이 전파되는 동안 새 호스트가 배송 중인 메일을 받고, 이전 MX로 향하는 일부 메일은 Workspace에서 계속 처리합니다.
trekmail.net/pricing에서 TrekMail Nano를 무료로 이용해 보세요. 카드 등록은 필요하지 않습니다. 월 $4의 Starter에는 Google Workspace 이전의 3단계에 필요한 서버 측 IMAP 마이그레이션 도구가 포함됩니다. 대부분의 사용자가 매일 Docs나 Sheets를 쓰지 않는 메일 중심 팀이라면 연 $42의 정액 요금으로 Workspace 비용을 보통 90% 이상 절감할 수 있습니다. IMAP 마이그레이션의 전체적인 내용은 IMAP 마이그레이션 안내서를 참고하세요.
구체적인 사례를 살펴보겠습니다. 헬싱키의 24명 규모 SaaS 기업은 오랜 기간 사용한 Google Workspace에서 이전했습니다. 이전 전에는 Workspace Business Starter에 연 $1,728을 지출했습니다. 낮은 TTL이 반영되는 시간과 동시 수신 전환을 포함해 전체 작업은 5일이 걸렸고, IMAP으로 180GB의 기존 메일을 24개 메일함에서 옮겼습니다. 이전 후 동일한 용도로 사용하는 TrekMail Pro 비용은 연 $96입니다. 연간 $1,632를 절약해 팀의 Notion 구독료를 내고도 마이그레이션이 완료된 다음 운영 연도에 여유 자금이 남습니다.
두 번째 사례는 텔아비브에 있는 40명 규모의 중견 기업이 Google Workspace Business Standard에서 이전한 경우입니다. 이전 전 비용은 연 $5,520였습니다. 사용 현황을 조사한 결과, Docs와 Sheets 사용은 경영진 및 회계 담당자를 포함한 8명에게 집중되어 있었습니다. 마이그레이션 계획은 40개 메일함에 TrekMail Pro를 연 $96로 사용하고, 문서 작업이 많은 사용자를 위해 Workspace Business Starter 8석을 연 $576에 유지하는 것이었습니다. 이전 후 총비용은 연 $672입니다. 연간 절감액은 $4,848입니다.
두 사례에서 확인할 수 있듯이 Google Workspace 이전은 전부 유지하거나 전부 옮기는 양자택일의 문제가 아닙니다. 생산성 도구를 실제로 사용하는 계정을 조사하면 서비스를 나누어 운영할 수 있습니다. 대부분의 계정은 정액제 메일 전용 호스트로 옮기고, 문서 작업이 많은 계정만 Workspace에 남깁니다. 이 방식은 실제로 필요한 사용자에게 생산성 도구를 유지하면서 Workspace 비용을 보통 70-90% 절감합니다.
