POP에서 IMAP으로 전환 후 이메일 날짜가 오늘로 표시되는 이유

월요일 아침의 익숙한 상황

POP3 계정을 IMAP으로 전환했습니다. 설정은 간단했고, 호스팅 업체의 안내도 따랐고, 별문제 없이 마쳤습니다. 그런데 받은편지함을 다시 열어보니... 2019년 이메일, 2021년 이메일, 작년 아카이브까지 전부 오늘 날짜로 표시되어 있습니다. 심지어 몇 초 차이로 같은 시각이 찍혀 있기도 해요.

이건 메일 클라이언트의 버그가 아닙니다. 시간대(타임존) 문제도 아닙니다. IMAP 프로토콜의 정상적인 동작 방식이며, 로컬에 저장된 이메일을 서버로 올릴 때 누구든 겪을 수 있는 상황입니다.

POP3 vs IMAP : 저장 방식의 근본적인 차이

왜 이런 일이 생기는지 이해하려면 먼저 POP3가 어떻게 작동하는지, 그리고 IMAP과 어떻게 다른지를 알아야 해요.

POP3에서 서버는 임시 우편함 역할만 합니다. Outlook, Thunderbird, Apple Mail 같은 클라이언트가 서버에 접속해서 메시지를 내려받은 뒤, 서버에서 삭제합니다(설정에 따라 남겨두기도 하지만요). 이후 이메일은 로컬에만 존재합니다. Outlook의 경우 .pst 파일, Thunderbird는 로컬 프로필, 하드디스크의 데이터베이스 파일 형태로 저장되죠.

IMAP은 정반대입니다. 이메일은 서버에 저장되고, 클라이언트는 원격으로 저장된 내용을 화면에 보여줄 뿐입니다. 그래서 모든 기기에서 동기화가 됩니다.

문제는 바로 전환 과정에서 발생해요. 로컬에 있던 POP 이메일을 IMAP 서버로 올리는 그 순간에요.

IMAP APPEND : 모든 것을 바꾸는 명령어

메일 클라이언트가 로컬 메시지를 IMAP 서버에 올릴 때, IMAP APPEND 명령어를 사용합니다. 서버에게 "이 메시지를 이 폴더에 저장해"라고 지시하는 겁니다.

서버는 메시지를 받아서 저장하고, 타임스탬프를 부여합니다. 이 타임스탬프가 바로 INTERNALDATE입니다. IMAP의 핵심 메타데이터로, 메시지가 서버에 저장된 시각을 나타냅니다. 그런데 APPEND 명령 시 클라이언트가 날짜를 명시적으로 전달하지 않으면, 서버는 기본적으로... 지금 이 순간을 사용합니다.

즉, 메시지 헤더에 2018년 날짜가 적혀 있어도, 아무도 서버에 "이 이메일은 2018년 것"이라고 알려주지 않으면, 서버는 지금 막 들어온 메시지로 판단하고 오늘 날짜로 INTERNALDATE를 설정합니다.

(이메일 원시 헤더를 한 번이라도 들여다본 적 있다면, 여러 줄의 Received: 사이에 Date: 줄이 있다는 걸 보셨을 거예요. RFC 2822에서 정의하는 이 Date: 필드가 실제 발송 날짜입니다. 그런데 IMAP INTERNALDATE는 서버 측에 별도로 저장되는 메타데이터로, 메시지 본문과는 무관한 값이에요.)

IMAP 간 마이그레이션과 다른 점

일반적인 IMAP 서버 간 마이그레이션(BitTitan, CloudM, imapsync 등 사용)에서는 문제가 조금 다릅니다. 마이그레이션 도구가 한 서버에서 다른 서버로 메시지를 복사할 때, 이론적으로는 APPEND 명령을 통해 원본 INTERNALDATE를 대상 서버에 전달할 수 있습니다. 그 경우 문제는 일부 도구가 마이그레이션 날짜로 된 Received: 헤더를 추가해서, Outlook 같은 클라이언트의 표시를 교란시킨다는 점이에요.

POP에서 IMAP으로 전환할 때는 상황이 다릅니다. 출발점이 완전히 로컬 데이터입니다. 복사할 원본 INTERNALDATE 자체가 없는 거예요. .pst 파일이나 Thunderbird 프로필은 자체 포맷과 내부 메타데이터로 메시지를 저장합니다. 메일 클라이언트가 이 메시지들을 IMAP 서버로 올릴 때, 메시지 내용을 기반으로 APPEND 명령을 재구성하는데, 대부분의 경우 명시적인 날짜를 전달하지 않습니다.

결과적으로 IMAP 서버는 수분 내에 수백 또는 수천 개의 메시지를 받게 되고, 모두 같은 시간대의 타임스탬프를 부여합니다. 지금 이 순간으로요.

이것이 바로 모든 기기에서 동시에 문제가 나타나는 이유입니다. 스마트폰, 태블릿, 두 번째 컴퓨터 모두 같은 IMAP 서버에 접속하므로 정확히 같은 내용을 봅니다. 클라이언트 측에서는 수정이 불가능해요.

클라이언트마다 표시 방식이 다른 이유

모든 메일 클라이언트가 같은 방식으로 반응하지는 않습니다. IT 관리자들이 사후에야 발견하는 부분이기도 해요.

Outlook은 최신 버전(특히 2023-2024년 업데이트 이후)에서 "받은 날짜" 열에 서버의 INTERNALDATE를 사용합니다. 따라서 원래 발송 날짜가 아니라, 서버에 올린 날짜가 표시됩니다. 이 동작에 대한 자세한 내용은 Outlook: IMAP 수신 날짜 vs 발송 날짜 차이 글을 참고하세요.

Gmail / Google Workspace와 Thunderbird는 조금 더 복잡한 동작을 보입니다. Gmail은 경우에 따라 메시지 헤더의 Date: 필드를 표시에 사용하기도 해서, 겉으로는 괜찮아 보이다가... 날짜 정렬을 시도하면 순서가 완전히 뒤죽박죽이 됩니다.

Apple Mail은 보통 Date: 헤더에서 날짜를 추출해 표시하지만, 정렬 및 검색은 내부적으로 INTERNALDATE를 사용합니다. 그래서 이메일이 시각적으로는 올바르게 날짜가 표시된 것처럼 보여도, 정렬 기능이 제대로 작동하지 않습니다. Apple Mail의 구체적인 동작은 Apple Mail: 마이그레이션 후 잘못된 날짜 표시 글을 확인하세요.

좋은 소식 : 원본 날짜는 그대로입니다

각 이메일의 Date: 헤더, 즉 실제 발송(또는 수신) 날짜가 담긴 필드는 전혀 건드려지지 않았습니다. 메시지 본문 안에 그대로 있어요. 이메일을 열어서 상세 정보를 확인하면 볼 수 있는 바로 그 날짜입니다.

IMAP 서버가 "망가뜨린" 것은 메시지 외부의 메타데이터인 INTERNALDATE뿐입니다. 메시지 자체는 온전합니다.

이것이 수정을 가능하게 하는 이유이기도 하고, 문제가 한동안 눈에 띄지 않는 이유이기도 해요. 이메일을 하나씩 열어보면 정상처럼 보입니다. 받은편지함 목록을 날짜순으로 정렬해야 비로소 문제가 드러납니다. 2019년 이메일이 방금 도착한 것처럼 목록 맨 위에 올라와 있고, 모두 같은 날짜로 표시되어 있어요.

규모의 문제 : 이메일 3,000개는 3개와 다릅니다

"그냥 삭제하고 다시 올리면 되는 거 아닌가요?"라고 생각할 수도 있습니다. 테스트용 5-10개 이메일이라면 맞는 말입니다. 중첩 폴더, 대용량 첨부 파일, S/MIME 서명 이메일, 2015년까지 거슬러 올라가는 대화 스레드가 포함된 8,000개 이메일 사서함이라면... 완전히 다른 이야기가 됩니다.

테스트 배치 50개에서 잘 작동하는 자체 제작 스크립트가 실제 운영 사서함에서는 중복 메시지를 만들거나, 첨부 파일을 잃어버리거나, 대화 스레드를 망가뜨릴 수 있습니다. API 할당량 관리, 네트워크 타임아웃, 비정형 MIME 구조 메시지... 비전문 도구는 이런 엣지 케이스를 처리하지 못해요.

중간에 무언가 잘못되면? 백업 및 롤백 메커니즘 없이는 데이터를 복구할 방법이 없습니다.

이 문제는 대규모 마이그레이션을 관리하는 관리자들에게 잘 알려진 상황입니다. 날짜가 왜 깨졌는지 이해하는 것과, 메시지 구조를 보존하면서 15,000개 이메일의 날짜를 제대로 수정하는 것은 전혀 다른 문제예요. 이 주제에 대해 더 알고 싶다면 마이그레이션 후 이메일 날짜를 수정할 수 있을까요? 글이 다양한 접근 방식과 한계를 상세히 설명하고 있습니다.

Redate.io가 이 상황을 처리하는 방법

Redate.io는 정확히 이런 상황을 위해 만들어졌습니다. 분석 엔진이 INTERNALDATE와 메시지 헤더의 날짜가 일치하지 않는 이메일을 식별합니다. POP에서 IMAP으로 전환한 경우든, IMAP 서버 간 마이그레이션이든, 로컬 아카이브를 수동으로 올린 경우든 상관없이요.

다단계 분석 파이프라인이 각 메시지의 헤더 체인을 검사하고, RFC 준수 여부를 검증하며, 메시지 내용을 변경하지 않고 날짜 메타데이터를 재구성합니다. 텍스트, 첨부 파일, MIME 구조, 디지털 서명 모두 그대로 유지됩니다. 수정된 각 이메일은 검증 전에 개별적으로 확인을 거칩니다.

원본은 30일 동안 눈에 보이는 백업 폴더에 보관됩니다. 문제가 생기면 복원할 수 있어요.

초기 스캔은 무료입니다. Redate.io가 사서함을 분석하고 영향을 받은 이메일을 파악해서, 결정을 내리기 전에 정확한 수치를 알려드립니다. 눈 감고 진행하는 일은 없습니다.

Redate.io는 Google Workspace(도메인 위임), Microsoft 365(Azure AD), 또는 직접 IMAP을 통해 사서함에 바로 연결됩니다. 로컬 설치 불필요. 손으로 .pst 파일을 조작할 일도 없습니다.

여러 사서함을 관리하는 관리자라면 MSP를 위한 클라이언트 이메일 날짜 문제 해결법도 참고해 보세요. Thunderbird에서의 POP/IMAP 전환 시 특유의 동작에 대한 내용은 마이그레이션 후 Thunderbird 날짜 오류 표시 문제에서 확인할 수 있습니다.

아직 마이그레이션 전이라면 : 미리 대비하는 방법

로컬 아카이브를 아직 IMAP 서버로 올리지 않았거나, 조직 내 다른 POP 계정 마이그레이션을 계획하고 있다면 다음 사항을 기억해 두세요.

• 메일 클라이언트가 APPEND 명령에 날짜를 명시적으로 전달하는 기능을 지원하는지 확인하세요. Thunderbird는 버전에 따라 이 부분의 동작이 달랐습니다.
• 먼저 검증 계정으로 테스트를 진행하세요. 오래된 이메일, 첨부 파일이 있는 이메일, 서명된 이메일 등 대표적인 50-100개 메시지로 테스트하고, 여러 클라이언트에서 날짜 표시를 확인하세요.
• 최종 사용자가 마이그레이션된 사서함을 사용하기 전에 수정 작업을 완료하세요. 이미 활성화된 사서함에서 날짜를 수정하는 것은 마이그레이션 직후 빈 사서함에서 하는 것보다 훨씬 복잡합니다.
• 마이그레이션 전후 이메일 수를 기록해 두세요. 소리 없이 사라진 데이터를 감지하는 유일한 방법입니다.

마이그레이션 전후에 확인해야 할 항목의 전체 체크리스트는 이메일 마이그레이션 체크리스트: 날짜 문제 예방 글에 정리되어 있습니다.

POP에서 IMAP으로 전환한 후 오래된 이메일이 오늘 날짜로 표시되고 있나요? Redate.io에서 무료 스캔을 시작하세요. 문제의 규모를 파악하고, 메시지 내용은 그대로 유지하면서 날짜 메타데이터를 수정할 수 있습니다.