Outlook 프로필 재생성 후 날짜가 바뀌는 이유

날짜를 망가뜨리는 흔한 문제 해결 방법

사용자가 Outlook 동기화 문제를 호소합니다. 이메일이 도착하지 않고, 보낸 편지함이 업데이트되지 않고, 화면에는 로딩 아이콘만 계속 돌아갑니다. 기술 담당자는 손상된 프로필로 진단하고, OST 파일을 삭제한 뒤 Outlook 프로필을 처음부터 새로 만듭니다. 결과: Outlook이 다시 연결되고, 이메일이 나타나고, 모든 게 작동하는 것처럼 보입니다.

그런데 다음 날 아침, 사용자가 받은 편지함을 열어 보면 8년치 이메일이 전부 같은 날짜, 즉 오늘 날짜로 표시됩니다.

이건 IMAP 마이그레이션이 잘못됐을 때와 정확히 같은 증상입니다. 이유도 같고요.

기술적으로 무슨 일이 일어나는가

프로필을 재생성하면 왜 이런 결과가 나오는지 이해하려면, 대부분의 기술자들이 잘 모르는 구분 하나를 짚어야 합니다. 이메일의 Date: 헤더와 IMAP의 INTERNALDATE의 차이입니다.

모든 이메일에는 RFC 2822 헤더 안에 Date: 필드가 있습니다. 발신자의 메일 클라이언트가 메시지를 보낼 때 이 필드를 작성하고, 이후 모든 서버를 거치는 동안 그대로 전달됩니다. 절대 바뀌지 않아요. 2019년 3월 14일 09:32에 보낸 이메일은 이후 어떤 일이 있어도 항상 그 Date: 필드를 그대로 가지고 있습니다.

IMAP INTERNALDATE는 다른 이야기입니다. 이건 메시지 내용과는 별개로 메일 서버가 관리하는 메타데이터입니다. 메시지가 메일함에 "저장된" 시각을 나타내죠. 정상적인 상황에서는 SMTP를 통해 이메일이 도착하면 서버가 수신 시각을 INTERNALDATE로 기록합니다. 그래서 2019년 3월 14일에 받은 이메일은 발신 날짜와 일치하는 INTERNALDATE를 갖게 됩니다.

Outlook은 기본적으로 메시지 자체의 Date: 헤더가 아니라 IMAP 서버에서 전달받은 INTERNALDATE를 기준으로 이메일을 정렬하고 표시합니다. (Outlook에서 이메일 속성을 열어 원시 헤더를 본 적 있다면, 그게 얼마나 복잡한 내용인지 아실 거예요.)

OST 파일 삭제가 촉발하는 일

Outlook이 IMAP 계정을 사용할 때는 로컬 데이터베이스를 유지합니다. OST 파일(Offline Storage Table)이 바로 그것입니다. 서버에 저장된 이메일과 해당 메타데이터, 읽음 상태, 분류 등의 로컬 미러 역할을 합니다.

OST 파일을 삭제하면 이 로컬 미러가 지워집니다. Outlook은 IMAP 서버에서 모든 것을 다시 다운로드해야 합니다.

문제는 여기서 시작됩니다. Outlook이 IMAP을 통해 메시지를 다시 다운로드할 때 FETCH 명령으로 내용을 가져옵니다. 그런데 모든 구성 및 버전에서 FETCH INTERNALDATE 명령을 사용해 원래의 IMAP 날짜를 가져와 보존하지는 않습니다. 일부 Outlook 버전에서는 서버에 저장된 INTERNALDATE 대신 메시지를 다시 다운로드한 시각을 기준으로 로컬 인덱스를 재구성합니다.

그 결과, 메일함의 모든 이메일이 재다운로드된 날 날짜로 표시됩니다.

모든 Outlook 버전이 똑같이 동작하지는 않아요

정확히 말하면, 이 동작이 모든 Outlook 버전에서 동일하게 나타나지는 않습니다. 그리고 바로 그 점이 진단을 복잡하게 만듭니다.

IMAP 모드의 Outlook 2016과 2019는 캐시 삭제 후 인덱스를 잘못 재구성하는 동작이 문서화되어 있습니다. 2023년 말부터 단계적으로 배포된 새 Outlook(웹 기반)은 캐시 처리 방식이 달라 결과가 일정하지 않을 수 있습니다. Exchange/Microsoft 365 계정을 Exchange 모드로 구성한 Outlook은 MAPI/Exchange 프로토콜이 IMAP과 다르게 동기화를 처리하기 때문에 이 문제에 덜 노출됩니다.

하지만 사용자가 클래식 Outlook에 IMAP 계정을 구성했고 기술 담당자가 OST 파일을 삭제하거나 프로필을 재생성했다면, 이 문제가 발생할 위험은 충분히 있습니다.

실제 마이그레이션과 구분하는 방법

프로필 재생성 후 "날짜가 이상하다"는 티켓을 받은 IT 관리자는 마이그레이션 문제로 오인할 수 있습니다. 두 경우를 구분하는 방법을 알아봅시다.

IMAP 마이그레이션의 경우

IMAP 마이그레이션(BitTitan, CloudM, imapsync 등) 시에는 마이그레이션 도구가 한 서버에서 다른 서버로 이메일을 복사합니다. 복사된 각 메시지는 IMAP APPEND 명령을 통해 대상 서버에 새로 등록됩니다. 이때 도구가 원래 INTERNALDATE를 명시적으로 지정하지 않으면, 대상 서버는 현재 시각을 INTERNALDATE로 기록합니다. 일부 도구는 마이그레이션 날짜가 담긴 Received: 헤더를 추가하기도 하는데, 이는 특정 클라이언트에서 문제를 악화시킵니다. 이 메커니즘의 자세한 내용은 IMAP INTERNALDATE와 날짜 깨짐 글에서 확인할 수 있어요.

프로필 재생성의 경우

이 경우 이메일은 여전히 같은 서버에 있고, 원래의 INTERNALDATE도 그대로입니다. 서버 측에서는 아무것도 바뀌지 않았습니다. Outlook의 로컬 캐시만 잘못된 날짜로 재구성된 것입니다. 겉으로 보이는 증상은 동일하지만(모든 이메일이 최근 날짜로 표시), 원인은 다릅니다.

확인하는 방법: 웹메일(Gmail, Outlook.com, 또는 호스팅 업체의 웹메일 인터페이스)로 메일함에 접속해 보세요. 웹메일에서 날짜가 올바르게 표시되면, 문제는 Outlook 로컬 환경에만 있는 겁니다. 웹메일에서도 날짜가 잘못 표시된다면, 서버 측 문제입니다(마이그레이션이거나 서버에서 INTERNALDATE가 변경된 것입니다).

원래 날짜를 복구할 수 있는 이유

좋은 소식이 있습니다. 두 경우 모두(마이그레이션이든 프로필 재생성이든) 원래 날짜는 사라지지 않습니다.

RFC 2822 Date: 헤더는 메시지의 일부입니다. 본문이나 첨부 파일과 마찬가지로 변경되지 않습니다. 2017년에 보낸 이메일의 원시 텍스트를 보면 이런 내용이 있습니다:

Date: Mon, 12 Jun 2017 14:23:41 +0200

이 줄은 서버에 저장된 메시지 안에 그대로 있습니다. 수정된 적이 없습니다. Outlook이 (잘못) 표시하는 것은 메시지 내용 외부에 있는 메타데이터입니다.

바로 이 점 덕분에 수정이 가능합니다. Redate.io의 엔진은 각 메시지의 헤더 체인을 분석해 실제 원래 날짜를 추출하고, 메시지 내용을 건드리지 않으면서 메타데이터를 정밀하게 수정합니다. Outlook에 표시되는 INTERNALDATE가 메시지 안에 항상 존재하는 이 신뢰할 수 있는 정보를 바탕으로 재구성됩니다.

'깨끗한' 재생성의 함정

사용자의 동기화 문제를 해결했습니다. Outlook이 다시 작동하고, 새 이메일도 잘 들어옵니다. 티켓을 닫습니다.

사흘 뒤, 사용자가 다시 연락합니다. 작년에 거래처에서 온 이메일을 찾고 있는데, Outlook에서 2023년 이메일이 전부 "어제" 받은 것으로 나온다고 합니다. 아무것도 찾을 수가 없습니다. 자동 보관 기능이 최근 이메일을 오래된 것으로 분류해 버렸을 수도 있습니다. 그리고 상사가 법적 분쟁 때문에 2022년 9월 이메일 대화 내용을 요청하고 있고요.

이런 일은 자주 발생합니다. 기술 담당자가 잘못한 게 아니라, 이 Outlook 동작이 표준 문제 해결 가이드에 눈에 띄게 문서화되어 있지 않기 때문입니다.

아무 소용 없는 잘못된 해결책들

Outlook에서 "수신 날짜" 대신 "발송 날짜"로 정렬하는 것이 사용자들이 제일 먼저 시도하는 방법입니다. 작동하는 것처럼 보이기도 하죠... 발송 날짜 정렬이 일부 폴더에서만 가능하고, 보기를 바꾸면 사라지며, 모바일이나 웹메일, 자동 정렬 규칙 같은 다른 앱들은 계속 잘못된 INTERNALDATE를 사용한다는 걸 알아채기 전까지는요.

발송 날짜 정렬은 해결책이 아닙니다. 실제 문제를 건드리지 않고 증상만 가리는 임시방편입니다. 이 내용은 발송 날짜 정렬은 해결책이 아닙니다 글에서 자세히 설명하고 있어요.

프로필을 다시 한 번 재생성하면 어떨까요? Outlook이 캐시를 현재 날짜로 재구성하는 동작이 바뀌지 않는 한, 아무것도 달라지지 않습니다.

PST로 내보냈다가 다시 가져오는 방법은요? 주의하세요. 날짜가 잘못 표시되는 Outlook에서 PST로 내보내면 잘못된 메타데이터가 그대로 내보내집니다. 그 파일을 다시 가져와도 아무것도 수정되지 않고, 오히려 날짜가 뒤죽박죽인 중복 메시지를 만들어 상황을 악화시킬 수 있습니다. 이 주제는 PST 가져오기 후 Outlook 날짜가 오늘로 바뀌는 이유 글에서 별도로 다루고 있습니다.

Redate.io가 이 경우에 하는 일

문제의 원인이 IMAP 마이그레이션이든 Outlook 프로필 재생성이든, 서버 측에서 나타나는 결과는 비슷합니다. 날짜 메타데이터가 실제 내용과 맞지 않는 이메일들이 생깁니다.

Redate.io는 메일함(Google Workspace, Microsoft 365, 또는 직접 IMAP)에 직접 연결해 메타데이터가 잘못된 메시지를 모두 스캔한 뒤, 다단계 분석 파이프라인을 통해 각 이메일을 개별적으로 수정합니다. 모든 수정은 검증됩니다. 원본 메시지는 사용자가 직접 삭제하기 전까지 메일함의 보이는 백업 폴더에 그대로 보관됩니다.

직접 만든 스크립트가 항상 놓치는 엣지 케이스들도 처리합니다. S/MIME 서명 메시지, 헤더에 비ASCII 인코딩이 있는 이메일(RFC 2047), 복잡한 멀티파트 구조, 비표준이거나 잘못 형성된 시간대가 포함된 Date: 헤더. 개발용 메일함의 이메일 50개에서 잘 돌아가는 스크립트가 운영 환경의 이메일 2,000개를 돌이킬 수 없이 망가뜨릴 수 있습니다. IMAP에는 사전 백업 없이 메시지를 교체하면 되돌릴 수 있는 기본 롤백 메커니즘이 없습니다.

Outlook 관련 사례는 Outlook에서 수동 IMAP 복사 날짜 수정 페이지에서 메일함을 연결하고 분석을 시작하는 방법을 자세히 안내하고 있습니다.

다음 작업 시 문제를 예방하는 방법

Outlook 프로필 작업을 자주 하는 기술자나 IT 관리자라면, 몇 가지 습관으로 이런 상황을 예방할 수 있습니다.

OST 파일을 삭제하거나 프로필을 재생성하기 전에, 웹메일에서 표시되는 날짜를 확인하세요. 날짜가 올바르다면 티켓에 기록해 두세요. 재생성 후에는 웹메일에 다시 접속해 날짜를 Outlook의 날짜와 비교해 보세요. 차이가 있다면, 사용자가 사흘 뒤에 불만을 제기하기 전에 바로 문제를 파악할 수 있습니다.

마이그레이션이 계획되어 있다면, 이메일 마이그레이션 체크리스트에 작업 전후로 확인해야 할 사항이 나와 있어요. 작업이 끝나자마자 이런 유형의 문제를 바로 발견할 수 있습니다.

Outlook 프로필을 재생성한 후 메일함의 날짜가 전부 잘못 표시되고 있나요? Redate.io에서 무료 스캔을 시작하세요. 영향받은 이메일을 찾아내고 메시지 내용은 건드리지 않고 메타데이터만 수정합니다.