GSMMO 마이그레이션 후 이메일 날짜 오류 수정 방법

아무도 경고하지 않는 GSMMO 날짜 문제

Google Workspace Migration for Microsoft Outlook(GSMMO)은 PST 파일, Outlook 프로필, 로컬 이메일 아카이브를 Gmail로 마이그레이션하기 위해 Google이 제공하는 데스크톱 도구입니다. 무료이며 공식적으로 지원되고, Outlook에서 Google Workspace로 소규모 팀이나 몇 개의 개별 메일함을 옮길 때 Google이 권장하는 마이그레이션 경로입니다.

도구는 작동합니다. 이메일이 Gmail에 도착하고, 폴더 구조가 라벨에 매핑되며, 연락처도 이전됩니다. 하지만 그 후 Gmail을 열고 날짜순으로 정렬해 보세요. 모든 이메일이 오늘 날짜를 표시합니다. 2021년 1월에 보낸 제안서였나요? 2026년 4월입니다. 2023년 3월 회계사가 보낸 청구서였나요? 역시 2026년 4월입니다.

GSMMO는 이런 일이 일어난다고 경고하지 않습니다. 마이그레이션 로그는 모든 메시지에 대해 성공을 표시합니다. Google 자체 문서도 이를 알려진 제한 사항으로 언급하지 않습니다. 누군가가 날짜 범위로 오래된 이메일을 검색하다가 결과가 하나도 나오지 않을 때에야 이 문제를 발견하게 됩니다.

GSMMO가 실제로 이메일을 업로드하는 방식

GSMMO는 PST 파일(또는 Outlook 프로필에서 직접)에서 메시지를 읽어 Gmail API를 통해 Gmail에 업로드합니다(도구의 Google 공식 릴리스 노트에도 그렇게 나와 있습니다). 날짜 문제는 여기서 시작되며, 그 메커니즘을 이해할 필요가 있습니다. 왜 이 수정이 "다시 가져오기만 하면 되는" 단순한 문제가 아닌지 설명해 주기 때문입니다.

GSMMO가 Gmail API를 통해 메시지를 업로드하면, Gmail은 업로드 시점의 날짜가 찍힌 새로운 Received: 헤더를 추가합니다. 그리고 원래 날짜가 함께 전달되지 않으면, Gmail이 내부적으로 정렬과 표시에 사용하는 타임스탬프인 INTERNALDATE가 원래 발송 날짜가 아니라 업로드 시점으로 설정됩니다.

GSMMO 마이그레이션 이후 헤더 체인은 다음과 같은 모습입니다:

Received: by 2002:a05:6512:3ca2:0:0:0:0 with SMTP id
    bi34csp1847206lfb; Sun, 5 Apr 2026 03:17:42 -0700 (PDT)
Received: from [127.0.0.1] (localhost [127.0.0.1])
    by gmailapi.google.com; Sun, 05 Apr 2026 10:17:41 +0000
Date: Wed, 18 Sep 2019 14:33:07 +0200

2019년 9월의 원래 Date: 헤더가 보이시나요? 여전히 그대로, 손대지 않은 채로 남아 있습니다. GSMMO는 메시지 본문이나 원래 헤더를 수정하지 않습니다. 하지만 Gmail은 표시 목적으로 이를 무시하고 대신 INTERNALDATE를 사용하는데, 이제 2026년 4월이라고 나옵니다.

GSMMO와 관리자 측 마이그레이션 도구 비교

혼란은 대개 여기서 시작됩니다. Google에는 여러 마이그레이션 도구가 있고, 모두 같은 방식으로 동작하지는 않습니다.

GSMMO(데스크톱 앱)는 사용자의 컴퓨터에서 실행됩니다. Outlook이나 PST 파일에서 읽어 Gmail API를 통해 이메일을 업로드합니다. 사용자는 Google Workspace 계정과 Outlook에 설치된 GSMMO 플러그인이 필요합니다. 클라이언트 측 도구입니다.

Google Workspace Migration Service(관리 콘솔 도구)는 서버 측입니다. 관리자가 Google 관리 콘솔에서 이를 설정하고 Exchange 서버나 다른 Google Workspace 테넌트를 지정하면, 마이그레이션은 Google의 인프라에서 실행됩니다. 이 도구는 원본 메타데이터를 기반으로 INTERNALDATE를 설정할 수 있기 때문에 일부 구성에서는 날짜 처리가 조금 더 낫습니다. 하지만 "조금 더 나음"이 "안정적임"을 의미하지는 않으며, 많은 관리자가 이 도구에서도 동일한 날짜 문제를 겪었다고 보고합니다.

핵심적인 차이는 무엇일까요? GSMMO에는 날짜 보존을 결정하는 서버 측 지능이 없습니다. 업로드하는 모든 메시지는, 최근 이메일이든 10년 된 아카이브 메시지든 동일하게 처리됩니다. 업로드한 날 날짜가 찍힌 Received: 헤더가 붙습니다. 그게 전부입니다.

GSMMO의 날짜 보존이 작동하지 않는 이유

GSMMO 설정을 살펴봤다면, 실제로 "날짜 보존" 옵션이 없다는 것을 알아차렸을 것입니다. 이는 실수가 아닙니다. GSMMO는 API를 통해 업로드된 메시지를 Gmail이 처리하는 방식에 의존하며, 이를 재정의할 수 없습니다.

기술적인 단계는 다음과 같습니다:

1. GSMMO는 원래 타임스탬프를 포함해 PST 파일에서 메시지를 읽습니다
2. GSMMO는 Gmail API를 통해 메시지 데이터를 업로드합니다
3. Gmail은 업로드를 받아 메시지를 메일함에 저장합니다
4. Gmail은 업로드 시점의 날짜가 찍힌 새로운 Received: 헤더를 추가합니다(위 예시의 gmailapi.google.com 줄)
5. 원래 날짜가 함께 전달되지 않으면, Gmail은 INTERNALDATE를 업로드 시점의 타임스탬프로 설정합니다
6. 메시지는 오늘 날짜로 Gmail에 도착합니다

4단계와 5단계가 핵심입니다. Gmail은 도구가 무엇을 전송하든 API를 통해 업로드된 모든 메시지에 그 헤더를 추가하며, GSMMO에는 원래 날짜를 전달하거나 유지할 설정이 없습니다. 그 결과 과거의 모든 이메일이 오늘 도착한 것처럼 보이게 됩니다.

일부 관리자는 특정 Google Workspace 설정을 활성화하거나 GSMMO 프로필 설정을 조정하며 GSMMO를 실행해 보았습니다. 이 중 어느 것도 날짜 동작에 영향을 주지 않습니다. Received: 헤더는 Google 쪽에서 추가되며, 어떤 클라이언트 측 설정도 이를 바꾸지 못합니다.

날짜를 망가뜨리는 구체적인 GSMMO 시나리오

모든 GSMMO 마이그레이션이 날짜 혼란으로 끝나지는 않지만, 대부분은 그렇습니다. 다음이 문제가 되는 경우입니다:

• PST 파일에서 Gmail로: 날짜가 깨집니다. 가장 흔한 GSMMO 사용 사례이며 가장 큰 영향을 받습니다.
• Outlook 프로필에서 Gmail로: 날짜가 깨집니다. PST 가져오기와 동일한 Gmail API 업로드입니다.
• GSMMO를 통한 Exchange Online(Microsoft 365)에서 Gmail로: 날짜가 깨집니다. GSMMO는 Exchange 서버에서 읽어 Gmail API를 통해 업로드합니다.
• GSMMO를 통한 온프레미스 Exchange에서 Gmail로: 날짜가 깨집니다. 동일한 메커니즘입니다.
• Gmail에서 Gmail로(PST 내보내기 재가져오기): 날짜가 깨집니다. 원래 이메일의 PST 안 날짜가 정확했더라도, 재가져오기는 새로운 날짜를 찍습니다.

패턴은 분명합니다. Gmail API를 통해 업로드된 모든 메시지는 업로드한 날 날짜가 찍힌 Received: 헤더를 받습니다. GSMMO는 항상 이 경로를 사용합니다.

특히 답답한 점은 GSMMO 마이그레이션 보고서가 모든 것을 성공으로 표시한다는 것입니다. 날짜에 대한 경고도, 오류도, 표시도 없습니다. 마이그레이션 전후 타임스탬프를 직접 비교해야만 이를 발견할 수 있는데, 대부분의 관리자는 사용자가 불평하기 전까지 그렇게 하지 않습니다.

정렬을 넘어선 영향

GSMMO 마이그레이션 이후의 잘못된 날짜는 어수선한 메일함을 넘어서는 실질적인 문제를 만듭니다.

방금 Google Workspace로 옮긴 회계사라고 가정해 보겠습니다. 세금 신고를 위해 2024년 3분기의 모든 고객 서신을 찾아야 합니다. Gmail에서 날짜 범위로 검색합니다: 7월부터 9월까지. 결과가 하나도 없습니다. 그 기간의 모든 이메일이 이제 마이그레이션 날짜를 표시하고 있어, Gmail의 날짜 필터가 그것들을 찾지 못합니다. 수천 개의 메시지를 직접 스크롤하거나, 정확한 검색어를 기억하길 바라며 키워드로 검색하는 수밖에 없습니다.

규제 산업에서는 이는 불편함을 넘어서는 문제입니다. 이메일 타임스탬프는 법적 증거로 쓰입니다. 거래일 이전에 공시를 보냈다는 것을 증명해야 하는 금융 자문가는, 이메일이 2023년 2월 대신 2026년 4월로 표시된다면 그것을 증명할 수 없습니다. SOX나 HIPAA에 따른 컴플라이언스 감사는 정확한 통신 타임스탬프에 의존하며, 잘못된 날짜는 감사 실패를 의미합니다.

그리고 스레드 문제도 있습니다. Gmail은 대화를 날짜와 제목으로 그룹화합니다. 스레드의 모든 메시지가 같은 날짜를 표시하면 대화 보기가 뒤섞입니다. 답장이 원본 메시지보다 먼저 나타납니다. 전체 스레드 구조가 동일한 날짜가 찍힌 이메일 더미로 붕괴됩니다.

Redate.io로 GSMMO 날짜 수정하기

좋은 소식은, 원래 Date: 헤더가 마이그레이션된 모든 이메일 안에 여전히 그대로 남아 있다는 것입니다. GSMMO는 메시지 콘텐츠를 수정하지 않습니다. 올바른 날짜는 그 자리에 있으며, INTERNALDATE와 최상위 Received 헤더가 마이그레이션 날짜를 가리키기 때문에 Gmail의 표시 로직에서 무시되고 있을 뿐입니다.

Redate.io는 Google Workspace 메일함에 연결하여 GSMMO 마이그레이션의 영향을 받은 이메일을 스캔하고, 독자적인 헤더 체인 분석 및 날짜 재구성 엔진을 사용해 날짜 메타데이터를 수정합니다. Redate는 어떤 도구가 마이그레이션을 수행했는지 알 필요가 없습니다. 표시된 날짜가 원래 날짜와 일치하지 않는 이메일을 찾아내고, 메시지 콘텐츠, 첨부파일, 스레드를 바꾸지 않고 수정합니다.

수정된 각 이메일은 개별적으로 검증을 거칩니다: 메시지 완전성, 첨부파일 보존, 라벨 매핑, 스레드 일관성. 원본은 직접 삭제하기 전까지 사용자 메일함 안에 있는 눈에 보이는 Redate.io - Originals 백업 폴더에 보관됩니다.

직접 스크립트로 이 문제를 해결할 수 있을까요? 문제를 이해하는 것과, 프로덕션 메일함에서 12,000개의 이메일을 S/MIME 서명을 손상시키거나 중첩된 MIME 파트를 깨뜨리거나 RFC 2047로 인코딩된 헤더를 뒤엉키게 하지 않고 수정하는 것은 완전히 다른 일입니다. GSMMO가 가져왔지만 겨우 붙어 있는, 38MB 첨부파일과 손상된 MIME 경계를 가진 이메일은 어떻게 처리하시겠습니까? 모든 메시지가 온전히 통과했는지 어떻게 하나하나 검증하시겠습니까? 테스트용 메시지 20개에서는 잘 작동하는 스크립트도, 8년치 서신이 쌓인 실제 메일함에서는 버텨내지 못합니다.

GSMMO를 위한 플랫폼별 가이드

GSMMO는 특히 Google Workspace로 마이그레이션하므로, 수정은 Gmail 수준에서 이루어집니다. 하지만 영향을 받은 이메일은 해당 Gmail 계정에 연결된 모든 클라이언트에서 보입니다:

• Gmail에서 GSMMO 마이그레이션 날짜 수정
• Outlook에서 GSMMO 마이그레이션 날짜 수정(Google Workspace 연결)
• Apple Mail에서 GSMMO 마이그레이션 날짜 수정

몇 달 전에 이미 마이그레이션했나요? 원래 Date 헤더는 시간이 지나도 저하되지 않습니다. Redate.io는 마이그레이션이 지난주에 있었든 3년 전에 있었든 GSMMO 영향을 받은 이메일을 수정할 수 있습니다.

GSMMO 마이그레이션으로 이메일 날짜가 잘못되었나요? 무료 스캔을 실행해 영향받은 이메일의 정확한 수와 수정 비용을 확인한 후, 결정을 내리세요.