Google Workspace 테넌트 간 마이그레이션: 이메일 날짜 깨짐

아무도 의심하지 않는 상황

Google Workspace 테넌트에서 다른 테넌트로의 마이그레이션이 막 끝났습니다. 회사 인수, 도메인 변경, 수년간 별도의 G Suite 계정으로 운영되던 두 조직의 합병. 작업은 잘 마무리됐고, 사서함도 제자리를 잡았고, 사용자들도 로그인하고 있습니다. 월요일 아침, 첫 번째 티켓: "이메일이 전부 같은 날짜로 표시됩니다." 이어서 두 번째. 그리고 열 개.

직감적으로 이렇게 생각하게 됩니다. IMAP 문제겠지, 도구 설정 오류겠지, 뭔가 특이한 케이스겠지. Google에서 Google로 마이그레이션한 건데 설마 거기서 문제가 생기겠어. 그런데 바로 거기서 발생합니다.

이 시나리오는 업계에서 가장 문서화가 덜 된 문제 중 하나입니다. 이 상황을 마주하는 IT 관리자 대부분은 메일 클라이언트 쪽, Outlook 쪽, 계정 설정 쪽에서 원인을 찾다가 수 시간을 낭비한 후에야, 문제가 이메일 헤더 자체에 있다는 사실을 깨닫습니다.

Google에서 Google로 마이그레이션해도 날짜가 깨지는 이유

무슨 일이 벌어지는지 이해하려면 이메일 헤더의 작동 방식으로 돌아가야 합니다. RFC 2822 규격의 모든 메시지에는 발신 클라이언트나 서버가 전송 시점에 기록한 Date: 필드가 있습니다. 이것이 이메일의 "진짜" 날짜, 즉 메시지가 작성되고 발송된 시점입니다.

그런데 또 다른 메커니즘이 있습니다. 바로 IMAP INTERNALDATE입니다. 서버 측에 저장되는 메타데이터로, 메시지가 사서함에 삽입된 시점을 나타냅니다. 여기서부터 흥미로워집니다.

마이그레이션 도구가 한 Google Workspace 테넌트에서 다른 테넌트로 이메일을 옮길 때, 두 서버 모두 Google이더라도 IMAP 프로토콜을 통해 처리됩니다. 메시지는 소스에서 읽힌 뒤 목적지에 재삽입됩니다. 이 재삽입 시점에 목적지 서버가 자동으로 Received: 헤더를 추가하는데, 여기에는 마이그레이션 작업 시점의 타임스탬프, 즉 마이그레이션 날짜가 기록됩니다.

문제는 Outlook 같은 메일 클라이언트가 원래의 Date: 필드 대신 헤더 체인의 첫 번째 Received:를 기준으로 날짜를 표시한다는 점입니다. 결과적으로 모든 이메일이 마이그레이션 당일 날짜로 표시됩니다.

어떤 도구가 문제를 일으키나요

Google Workspace 테넌트 간 마이그레이션에 사용되는 사실상 모든 도구가 해당됩니다. 예외는 없습니다.

• GSMMO (Google Workspace Migration for Microsoft Outlook): 원래 Exchange에서 마이그레이션하기 위해 설계됐지만, 일부 GWS-to-GWS 워크플로에서도 사용됩니다.
• CloudM Migrate: MSP들이 Google 간 마이그레이션에 많이 쓰는 도구로, 마이그레이션 Received: 헤더를 항상 추가합니다. CloudM 상세 분석을 참고하세요.
• BitTitan MigrationWiz: 동일한 동작을 합니다. BitTitan 관련 문서에서 자세한 내용을 확인할 수 있습니다.
• imapsync: Google 테넌트 간을 포함한 IMAP 마이그레이션 스크립트 작성에 쓰이는 오픈소스 도구입니다.
• Takeout + IMAP 재임포트 방식의 수동 내보내기/가져오기: 덜 일반적이지만 정확히 같은 결과를 낳습니다.

이유는 간단합니다. 이 도구들은 모두 표준 IMAP 클라이언트처럼 동작합니다. 메타데이터를 보존해 줄 Google 전용 네이티브 경로에는 접근할 수 없습니다. 두 테넌트 모두 Google에 있더라도 전송은 IMAP 레이어를 통해 이루어지고, 이 레이어는 자기 자신과 통신하고 있다는 사실을 알지 못합니다.

Received 헤더의 작동 방식 자세히 보기

(Gmail이나 Outlook에서 이메일의 원시 헤더를 읽어본 적이 있다면, 그게 딱히 즐거운 독서가 아니라는 걸 잘 아실 겁니다. 그래도 진실은 거기에 있습니다.)

정상적으로 전달된 이메일에는 여러 개의 Received: 헤더가 경로의 역순으로 나열됩니다. 메시지를 마지막으로 처리한 서버가 맨 위에 옵니다. 마이그레이션 이후에는 마이그레이션 헤더가 스택의 맨 위에 위치하게 됩니다.

CloudM을 통해 GWS 테넌트 간 마이그레이션된 메시지의 실제 모습입니다.

Received: from mail-migration.cloudm.io (mail-migration.cloudm.io [203.0.113.42])
        by mx.google.com with ESMTPS id xyz123
        for <user@new-domain.com>
        ; Mon, 14 Oct 2024 09:17:32 +0000 (UTC)
Received: from mail-relay.google.com ...
        ; Tue, 5 Mar 2019 14:22:08 +0000
Date: Tue, 5 Mar 2019 14:22:08 +0000

Date: 필드는 2019년을 가리킵니다. 첫 번째 Received:는 2024년 10월을 가리킵니다. Outlook은 첫 번째 Received:를 읽습니다. 사용자는 2019년 이메일을 2024년 10월 날짜로 보게 됩니다.

원래의 Date: 필드는 그대로 있습니다. 아무것도 바뀌지 않았습니다. 좋은 소식이 있다면, 데이터는 거기 있다는 것입니다. 올바르게 활용되기를 기다리고 있을 뿐입니다.

Outlook과 Gmail의 표시 방식 차이

이건 중요한 차이점입니다. Gmail 웹 인터페이스로 이메일을 확인하는 사용자는 대부분 올바른 날짜를 보게 됩니다. Gmail은 메시지 표시 시 RFC 2822의 Date: 필드를 우선적으로 사용하기 때문입니다. 웹에서는 문제가 눈에 덜 띕니다.

반면, Google Workspace 사서함을 IMAP으로 Outlook에 연결하거나 Exchange ActiveSync 동기화를 사용하는 사용자들은 잘못된 날짜를 그대로 마주칩니다. Outlook은 마이그레이션 시 추가된 첫 번째 Received: 헤더를 반영한 IMAP INTERNALDATE를 신뢰하기 때문입니다.

정확히 말하면, Outlook의 동작은 버전과 연결 방식에 따라 다소 다릅니다. Outlook 2019와 Microsoft 365 최신 버전은 IMAP 연결 시 INTERNALDATE를 사용합니다. 구버전은 약간 다른 동작을 보일 수 있습니다. 그러나 실제 운영 환경에서 관찰된 모든 사례에서, IMAP을 통한 GWS-to-GWS 마이그레이션은 Outlook에서 잘못된 날짜를 유발했습니다.

그래서 새 테넌트로 마이그레이션 후 일부 사용자는 Gmail 웹을, 다른 사용자는 Outlook을 쓰는 혼합 환경에서는 티켓 접수가 들쭉날쭉합니다. IT 팀은 "왜 어떤 사람만 영향을 받는지" 파악하는 데 시간을 쏟지만, 답은 단순합니다. 메일 클라이언트가 다르기 때문입니다.

인수, 합병, 도메인 변경: 가장 흔한 사례들

이런 유형의 마이그레이션은 드문 일이 아닙니다. 가장 많은 티켓을 발생시키는 시나리오를 정리했습니다.

기업 인수

인수된 회사는 자체 Google Workspace 테넌트(@구회사.com)를 갖고 있었습니다. 인수 후 모든 것이 모회사 테넌트(@그룹.com)로 이전되어야 합니다. 사서함 250개, 8년치 이메일 기록 전체를. BitTitan이나 CloudM이 작업을 맡았고, 결과적으로 약 240만 개의 이메일이 마이그레이션 주말 날짜로 표시됩니다.

도메인 변경

리브랜딩을 마친 회사가 @이전이름.com에서 @새이름.com으로 넘어갑니다. Google 테넌트는 동일하지만, 설정 잔재를 없애기 위해 새 테넌트를 만들어 깔끔하게 시작하기로 결정합니다(흔한 선택입니다). imapsync 또는 GSMMO로 사서함을 마이그레이션하면 날짜가 똑같은 방식으로 깨집니다.

자회사 통합

4개 자회사가 각자의 G Suite 테넌트를 쓰던 그룹이 하나의 통합 테넌트로 모든 것을 모으기로 결정합니다. 4개의 마이그레이션이 동시에 진행되고, 4개 배치의 이메일 날짜가 손상된 채로 처리해야 할 상황이 됩니다.

세 시나리오 모두 문제는 동일하고 해결책도 같습니다. 이메일 마이그레이션 체크리스트를 활용하면 마이그레이션을 시작하기 전에 이런 문제를 미리 파악할 수 있습니다.

직접 만든 스크립트가 답이 아닌 이유

문제를 이해하는 것과, "Python 스크립트로 헤더를 정리해야지"라고 생각하고 운영 환경의 이메일 3만 건에 적용하는 것은 전혀 다른 문제입니다.

엣지 케이스는 끝이 없습니다. 깨끗한 테스트 환경에서 이메일 50건에 잘 작동하던 스크립트는 실제 운영 사서함에서 반드시 다음과 같은 상황을 만납니다.

• S/MIME 서명이나 PGP 암호화 콘텐츠가 포함된 메시지. 메시지 구조를 조금이라도 수정하면 암호화 서명이 무효화됩니다.
• 복잡한 중첩 MIME 구조를 가진 이메일(multipart/mixed 안에 multipart/alternative가 있고 수십 MB 첨부파일이 포함된 형태).
• RFC 2047로 인코딩된 헤더(ASCII가 아닌 문자들). 잘못 설정된 파서는 이를 조용히 삭제해버립니다.
• 수정 배치 처리 도중 새벽 2시에 발생하는 Google API의 429 Too Many Requests 오류. 프로세스가 불확정 상태로 중단됩니다.
• Received: 체인이 모호한 이메일. 여러 마이그레이션 도구가 순차적으로 각자의 헤더를 추가했을 때, 어떤 것을 제거해야 하는지 판단하기가 쉽지 않습니다.

그리고 가장 중요한 질문입니다. 수정된 각 메시지가 온전하고, 아무것도 손실되거나 손상되지 않았다는 것을 이메일 하나하나 어떻게 검증할 건가요? 직접 만든 스크립트는 보통 이 검증을 하지 않습니다. Redate.io는 자동으로 검증하고, 30일간 볼 수 있는 백업 폴더에 원본을 보관합니다.

이런 마이그레이션에서 Redate.io가 하는 일

Redate.io는 도메인 위임(Domain Delegation)을 통해 목적지 Google Workspace 테넌트에 연결합니다. 사서함 하나하나에 수동으로 접근할 필요가 없습니다. 그런 다음 날짜 메타데이터가 메시지 내용과 일치하지 않는 이메일을 스캔합니다. 이 스캔 단계는 무료로 제공되며, 수정 작업 전에 문제의 규모를 정확히 파악할 수 있습니다.

독자적인 보정 엔진은 각 메시지의 헤더 체인을 분석하고, BitTitan, CloudM, imapsync, GSMMO를 비롯한 기타 덜 알려진 마이그레이션 도구들의 알려진 시그니처에 대해 패턴 매칭을 수행합니다. 그 후 메시지 내용을 변경하지 않고 날짜 메타데이터를 정밀하게 보정합니다. 수정된 각 이메일은 개별적으로 검증되고, 원본은 보존됩니다.

특히 Google Workspace 테넌트 간 마이그레이션의 경우, 여러 차례 마이그레이션이 이루어진 사서함(예: 2021년에 한 번 마이그레이션된 후 2024년에 다시 마이그레이션된 경우)에서 여러 겹으로 쌓인 불필요한 헤더를 정리하는 작업도 처리합니다.

이 설정 유형에 대한 구체적인 수정 가이드는 CloudM to Google Workspace 및 BitTitan to Google Workspace 페이지에서 연결 단계를 자세히 안내합니다.

사용자가 불만을 제기하기 전에 문제 발견하기

손상된 날짜를 발견하기 가장 좋은 시점은 고-라이브 전, 마이그레이션 직후입니다. Thunderbird 같은 IMAP 클라이언트로 파일럿 사서함 몇 개를 빠르게 확인해서 날짜 표시가 예상과 일치하는지 비교해보세요. 가져온 이메일이 모두 최근의 동일한 날짜로 표시된다면, 이 문제의 전형적인 징후입니다.

그런데 현실에서는 마이그레이션 후 몇 주가 지나서야 문제가 발견되는 경우가 많습니다. 어떤 사용자가 오래된 계약서를 찾다가, Gmail 사서함이 완벽하게 정렬되어 있긴 한데... 마이그레이션 날짜 기준으로 정렬되어 있다는 걸 깨달을 때입니다. 수천 개의 이메일이 같은 타임스탬프에 쌓여 있습니다. 날짜 검색은 더 이상 작동하지 않습니다. 대화 스레드는 뒤죽박죽입니다. 이메일 기록이 사라진 것처럼 보입니다.

Google Workspace 테넌트 간 마이그레이션을 정기적으로 진행하는 MSP라면, 고객 검수 전 마이그레이션 후 체크리스트에 Redate.io 스캔을 포함시키면 이런 뜻밖의 상황을 방지할 수 있습니다.

두 Google Workspace 테넌트 간 마이그레이션 후 이메일 날짜가 잘못 표시되고 있나요? Redate.io에서 무료 스캔을 시작하세요. 수정 전에 문제의 규모를 먼저 확인할 수 있습니다.