예약 발송과 수신 확인이 실제로 보장하는 것

이 두 기능은 흔히 기능 목록에 나란히 표시되지만, 신뢰할 수 있는 정도는 전혀 다릅니다.

예약 발송은 서비스가 정상적으로 운영되는 동안 정해진 대로 작동합니다. 서버가 메시지를 보관했다가 선택한 시각에 발송합니다. 노트북을 닫거나 연결이 끊기거나 잠자리에 들어도 됩니다. 발송은 사용자의 기기가 계속 온라인인지에 의존하지 않습니다.

수신 확인은 요청일 뿐입니다. 수신자의 메일 프로그램에 메시지가 표시됐을 때 알려 달라고 요청하지만, 프로그램은 거부하거나 먼저 사용자에게 묻거나 요청을 무시할 수 있습니다. 확인이 오지 않았다는 사실만으로는 거의 아무것도 알 수 없습니다.

두 기능 모두 유용하지만, 각각 무엇을 알려 줄 수 있는지 알고 사용해야 합니다.

예약 발송의 작동 방식

메시지를 작성하고 보내기 옆의 메뉴를 연 다음 시각을 선택합니다. 미리 설정된 항목에는 내일 오전, 내일 오후, 다음 주 월요일 오전이 있으며 그 밖의 시각은 날짜 선택기로 지정할 수 있습니다. 메시지는 예약됨 폴더로 이동해 발송 시각까지 머뭅니다.

중요한 점은 메시지가 어디에서 기다리는가입니다. 메시지는 서버에 저장되고, 처리 프로세스가 매분 발송 시각이 된 항목을 확인합니다. 사용자 기기는 관여하지 않습니다. 브라우저 탭을 열어 둘 필요도, 앱을 실행해 둘 필요도 없으며 컴퓨터를 꺼도 됩니다. 이것이 서버 측 예약 발송과 일부 데스크톱 클라이언트의 로컬 예약 기능이 다른 점입니다. 후자에서 '예약'은 해당 시각에 컴퓨터가 켜져 있어야 발송된다는 뜻일 수 있습니다.

발송되기 전까지 예약 메시지는 자유롭게 수정할 수 있습니다. 예약됨 폴더를 열어 취소하거나 시각을 바꾸거나 내용을 편집하면 됩니다. 취소한 메시지는 삭제되지 않고 임시 보관함으로 돌아갑니다.

미리 알아 둘 제한이 하나 있습니다. 공유 사서함으로 작업할 때는 예약 발송을 사용할 수 없습니다. 팀 받은편지함에서 몇 시간 전에 대기열에 넣은 메시지는 발송 시점에 담당자가 명확하지 않을 수 있습니다. 작성자가 이미 팀을 떠났을 수도 있고, 기다리는 동안 다른 구성원에게는 메시지가 보이지 않습니다. 공유 주소에서 즉시 보내는 기능에는 영향이 없습니다.

발송 취소는 예약 발송이 아닙니다

두 기능은 자주 혼동되지만 서로 다른 문제를 해결합니다. 발송 취소는 클릭한 뒤 오 초 안에 발견한 실수를 바로잡는 기능이고, 예약 발송은 몇 주 뒤일 수도 있는 발송 시각을 정하는 기능입니다.

발송 취소는 모든 메시지에 오 초의 대기 시간을 추가합니다. 보내기를 클릭하면 메시지가 바로 전송되지 않고 대기열에 들어가며 카운트다운이 나타납니다. 실행 취소를 클릭하면 메시지가 편집 가능한 상태로 작성 화면에 돌아옵니다. 시간이 끝나면 발송됩니다.

오 초는 의도적으로 정한 시간입니다. 흔히 생기는 두 가지 실수인 첨부 파일 누락과 잘못된 수신자는 창을 닫은 직후 알아차리는 경우가 많아 대체로 이 시간 안에 대응할 수 있습니다. 동시에 발송이 느리다고 느끼지 않을 만큼 짧습니다.

더 긴 취소 시간은 좋아 보이지만 불편도 생깁니다. 삼십 초로 설정하면 모든 메시지가 반 분 동안 애매한 상태에 머뭅니다. '이미 발송됐나?'라는 질문에 답하려면 직접 확인해야 하고, 보낸편지함도 실제 상태보다 늦게 반영됩니다.

시간대 때문에 예약 발송이 어긋나는 경우

두 사람이 서로 다른 곳에 있는 순간 '내일 오전 9시'는 모호해집니다. 예약 발송에서는 이 모호함 때문에 메시지가 오전 3시에 도착할 수 있습니다.

선택한 시각에는 브라우저에서 가져온 사용자의 시간대가 적용됩니다. 베를린의 노트북에서 샌프란시스코의 동료에게 보낼 메시지를 예약한다면 오전 9시는 베를린의 오전 9시이며, 상대에게는 자정입니다.

과거에는 같은 종류의 문제가 일정에서 훨씬 심각하게 나타났습니다. 그래서 오늘날 일정 이벤트는 시간대가 없는 단순한 시계 시각 대신 이벤트별로 명시적인 시간대를 저장합니다. 베를린에서 만든 회의를 샌프란시스코에서 열면 잘못된 장소에 같은 숫자를 보여 주는 대신 양쪽 화면에 맞는 현지 시각을 표시합니다.

실제로 예약할 때는 내 아침이 아니라 수신자의 아침을 기준으로 생각하고, 시계가 바뀌는 주에는 특히 주의해야 합니다. 세 주 뒤로 예약하면서 그 사이에 일광 절약 시간 전환을 지나면, 처음 생각한 현지 시각보다 한 시간 어긋나 도착할 수 있습니다.

수신 확인: MDN이란?

이메일의 수신 확인은 Message Disposition Notification, 즉 MDN이며 RFC 8098에 표준화되어 있습니다. 작동 방식은 다음과 같습니다.

1. 자신의 주소가 들어 있는 Disposition-Notification-To 헤더와 함께 메시지를 보냅니다.
2. 수신자의 메일 프로그램이 헤더를 확인합니다. 다음에 무엇을 할지는 전적으로 해당 프로그램과 설정에 달려 있습니다.
3. 응답하기로 하면, 이 사용자가 이 시각에 메시지를 표시했다는 내용을 기계가 읽을 수 있는 작은 구조화 메시지로 돌려보냅니다.
4. 그 알림은 일반 메일처럼 받은편지함에 들어오며 Original-Message-ID를 통해 원본과 연결됩니다.

당사 시스템에서는 확인을 요청할 때 발송 시점에 수신자별로 한 건의 대기 항목을 기록합니다. 올바르게 연결할 수 있는 유효한 MDN이 도착하면 해당 항목에 시각이 표시됩니다. 보낸편지함 목록에는 표시가 생기고, 메시지를 열면 누가 확인했고 누가 확인하지 않았는지 수신자별 보고서를 볼 수 있습니다.

숨은 참조 수신자는 의도적으로 보고서에서 제외합니다. 숨겨진 수신자의 확인을 발신자 보고서에 표시하면, 화면을 보는 다른 사람에게 숨은 참조의 존재가 드러날 수 있습니다. 숨은 참조의 의미를 몰래 훼손하는 기능은 결함입니다.

작성 화면에서 메시지마다 확인을 켤 수 있고, 모든 메시지에서 정말 필요하다면 설정에서 사서함별 기본값을 정할 수도 있습니다. 대부분의 사용자에게는 항상 켜 두는 방식을 권하지 않습니다.

추적 픽셀과 다른 이유

메시지 열람 여부를 추정하는 또 다른 방법은 발신자가 관리하는 서버에 있는 1×1 투명 이미지를 넣고, 수신자의 클라이언트가 이미지를 불러올 때 요청을 기록하는 것입니다. 많은 '이메일 추적' 브라우저 확장 프로그램과 영업 도구가 이 방식을 사용합니다.

당사가 이 방식을 쓰지 않는 데에는 세 가지 이유가 있습니다.

은밀하게 작동합니다.수신자는 무언가 기록된다는 명확한 안내를 받지 못합니다. MDN 요청은 눈에 보입니다. 클라이언트가 사용자에게 알리거나 허가를 요청할 수 있어 동의가 메커니즘에 포함됩니다.

열람 시각보다 많은 정보가 새어 나갑니다.이미지 요청에는 IP 주소와 사용자 에이전트가 포함되므로 대략적인 위치와 메일을 읽은 기기 종류를 추정할 수 있습니다. 이는 '메시지가 표시됨'과는 본질적으로 다른 정보이며 명시적으로 묻지 않고 수집될 수 있습니다.

현재는 신호가 거의 믿을 만하지 않습니다.Apple Mail 개인정보 보호는 프록시를 통해 이미지를 미리 가져올 수 있습니다. 그러면 실제 수신자와 다른 위치에서 즉시 열린 것처럼 기록됩니다. Gmail도 자체 캐시를 통해 이미지를 제공합니다. 따라서 데이터에 잡음이 많습니다.

MDN이 주는 데이터는 더 적지만, 클라이언트가 알리기로 선택한 동작을 나타냅니다. 의도적으로 택한 절충안입니다.

확인이 없을 때 알 수 있는 것 (거의 없음)

이 점은 분명히 말해야 합니다. 많은 수신 확인 요청에는 끝내 응답이 오지 않습니다. 그 이유는 메시지를 실제로 읽었는지와 관계가 없습니다.

따라서 빈 보고서는 아직 읽지 않음, 휴대전화나 Gmail에서 읽음, Outlook에서 열고 사용자가 아니요를 선택함, 읽었지만 확인하지 않음 등 모든 상황과 일치합니다. 이들을 구분할 수는 없습니다.

올바른 해석은 비대칭적입니다. 확인이 도착했다면 클라이언트가 메시지를 표시했다는 강한 신호입니다. 도착하지 않았다면 열람 여부에 대한 증거가 아닙니다. 전자는 신호로, 후자는 침묵으로 받아들이세요.

필요한 것이 열람 증명이 아니라 전달 증명이라면, 이는 별개의 문제이며 일반적으로 더 잘 확인할 수 있습니다. 발송 로그에는 수신 서버가 메시지를 받아들일 때 보낸 SMTP 응답이 기록되며, 상승하는 반송률은 주시해야 할 신호입니다. 인프라는 서버의 수락을 관찰할 수 있지만, 열람은 수신자가 자발적으로 알려 주는 정보입니다.

보고서 읽는 법

보낸편지함 목록에는 확인을 요청한 메시지가 표시됩니다. 메시지를 열면 받는 사람과 참조에 있는 각 수신자가 확인 시각 또는 빈 상태로 나타납니다.

판정이 아니라 후속 연락의 계기로 사용하세요. '다섯 명 중 세 명이 확인했고, 답이 필요한 두 명은 아직 확인하지 않았다'는 후속 연락의 합리적인 근거가 될 수 있습니다. '14:32에 내 메일을 읽고 답하지 않았다'는 말은 대화를 시작할 좋은 문장이 아니며, 상대가 불편해할 만한 이유도 충분합니다.

각 기능을 써야 할 때

예약 발송은 업무 시간 밖에 작성했지만 오전 1시까지 일하는 것처럼 보이고 싶지 않을 때, 수신자가 다른 시간대에 있어 상대의 아침에 도착시키고 싶을 때, 갱신 안내나 계약 기한처럼 특정 날짜에 나가야 할 때, 또는 보내기 전 한 번 더 생각할 시간이 필요할 때 사용하세요.

수신 확인은 메시지가 정말 중요하고, 확인 여부에 따라 다음 행동이 달라지며, 응답이 없다고 해서 열람 여부를 알 수 없다는 사실을 미리 받아들인 경우에 요청하세요. 기본으로 켜 두면 매번 질문을 받는 사람을 불편하게 하고, 정말 중요한 메시지에서 신호의 가치도 떨어집니다.

자주 묻는 질문

컴퓨터가 꺼져 있어도 예약 발송이 작동하나요?

예. 서비스가 정상적으로 운영되는 동안 메시지는 서버에 보관되고 처리 프로세스가 매분 발송 시각이 된 항목을 확인합니다. 사용자의 어떤 기기도 켜져 있거나 온라인일 필요가 없습니다.

발송 전에 예약 메시지를 수정할 수 있나요?

예. 예약됨 폴더를 열어 내용이나 시각을 바꾸거나 예약을 취소할 수 있습니다. 취소하면 임시 보관함으로 돌아갑니다.

공유 사서함에서 예약 발송을 쓸 수 없는 이유는 무엇인가요?

팀 받은편지함에서 몇 시간 전에 등록한 메시지는 발송 시점에 담당자가 명확하지 않을 수 있고, 기다리는 동안 다른 구성원에게 보이지 않습니다. 공유 주소에서 즉시 보내기는 정상적으로 작동합니다.

Gmail에서도 수신 확인이 작동하나요?

개인 Gmail 계정에서는 보통 MDN을 기대하지 않는 편이 좋습니다. Google Workspace에서는 관리 설정에 따라 달라지며 비활성화되어 있을 수 있습니다. 실제 동작은 현재 도메인과 클라이언트 구성으로 결정됩니다.

수신자는 내가 확인을 요청했다는 사실을 알 수 있나요?

예. 의도한 동작입니다. 클라이언트가 사용자에게 알리거나 허가를 요청할 수 있습니다. 감시가 아니라 요청입니다.

수신 확인은 메시지가 전달됐다는 증거인가요?

유효한 확인은 메시지가 전달됐고 또한 클라이언트에 표시됐음을 나타냅니다. 확인이 없다는 사실은 아무것도 증명하지 않습니다. 전달 상태는 발송 로그와 수신 서버의 SMTP 응답을 확인하세요.

추적 픽셀을 사용하나요?

아니요. 확인에는 수신자의 프로그램이 거부할 수 있는 표준 MDN 메커니즘을 사용합니다. 삽입 이미지나 열람 추적 비콘이 없으며, 이 메커니즘은 수신자 측의 IP나 사용자 에이전트를 기록하지 않습니다.

확인으로 메시지 전달 여부를 알 수 있나요?

아니요. MDN은 원래 수신자의 처리 상태만 보고합니다. 다른 사람에게 전달됐는지는 알 수 없습니다.