"발송 취소/보내기 취소" 버튼을 눌렀는데도 상대방에게 답장을 받았던 기억이 있는가?
오늘은 왜 이런 일이 일어나는지에 대해 알아보자.
때는 바야흐로 약 2주 전, 중간고사 이후 기계학습개론 두 번째 과제 마감 직전이었다.
MNIST dataset에 대해 KNN, SVM, Random Forest, Gradient Boosting에서 각각 최대한 높은 accuracy를 도출하는 모델을 찾아내는 과제였다.
나는 이미지 데이터셋에 대해 일반적으로 많이 활용되는 hyper params 후보들을 리스트에 넣고 중첩 iteration으로 알아서 가장 좋은 조합을 찾도록 코드를 짰다.
비록 Gradient Boosting 같은 classifier 때문에 거의 1200분 정도 걸리긴 했지만 어쨌든 결과는 나쁘지 않았다.
어차피 돌리는 동안 다른 일을 하면 되기도 하고.
같이 수업을 듣는 후배님도 이걸 보더니 좋아보였는지 어느샌가 중첩 iteration으로 best param set을 찾고 있더라.
그런데 그것도 잠시, 먼저 과제를 제출하고 여유로운 저녁을 보내고 있는데 어디에선가 갑자기 절규 소리가 들렸다.
뭔가 했더니 러닝을 돌리던 중에 노트북이 자꾸 프리징된다는 거였다.
아마도 메모리 과부하로 노트북이 터진 것 같았다.
안타까운 마음에 내가 코드를 대신 돌려주기로 했고, 모든 게 해결된 줄 알았으나...
마감일이 코앞이어서였을까.
급한 마음에 교수님께 억울함을 토로하는 메일을 보냈다고 한다. 무려 두 통이나...
심지어 처음 보낸 것은 본인피셜, "매우 무례했다"고 한다.
정신 차리고 undo를 눌렀지만 새벽 3시쯤 답장이 왔단다.
후배님이 보여준 메일 원본을 보니 그렇게 처절할 수가 없었다.
덕분에 아침부터 빅웃음으로 하루를 시작했다.
그런데 왜 이런 문제가 발생한 것일까?
개발자가 unit test도 없이 릴리즈를 했기 때문일까?
언젠가 나도 겪었던 문제라 원인이 궁금해졌다.
그래서 나름대로 컴퓨터 네트워크 교과서와 GPT, 구글링한 내용들을 종합해 보며 원인을 분석해 봤다.
이메일은 어떻게 작동할까?
일단 기본적인 이메일 시스템은 크게 3요소로 이루어져 있다.
- User Agent
- 이메일을 작성, 수정, 읽기 위한 client software
- Outlook과 같은 메일 프로그램
- Mail Server
- 이메일을 송수신하고 저장하는 서버
- Message Queue + Mailbox
- Email Protocol (e.g. SMTP, IMAP, POP3)
이때 Message Queue란, 발신 이메일이 다른 메일 서버로 이동하기 전에 저장되는 공간이다.
Mailbox는, 이와 반대로 수신된 이메일이 user agent에 전달되기 전에 저장되는 공간이다.
이론적으로 수신자가 메일을 열람하기 전까지 메일을 다운로드하지 않는 것이 기본이다.
이후에 user agent에서 이메일을 읽을 때 비로소 메일 서버에 저장된 이메일을 다운로드하게 되는 것이다.
그렇다면 읽기 전에 삭제 요청을 보내서 mailbox 속의 메일을 지울 수 있는 게 아닐까?
이메일 프로토콜
이는 프로토콜 때문에 불가능하다.
네이버 메일이나 아웃룩 등의 user agent에 외부 메일을 등록해 봤다면 다음의 프로토콜들이 익숙할지도 모르겠다.
- SMTP (Simple Mail Transfer Protocol)
- IMAP (Internet Message Access Protocol)
- POP3 (Post Office Protocol 3)
먼저 SMTP는 이메일 전송 전용 프로토콜로, 전송 후에는 제어가 불가능하다는 특징이 있다.
즉 Recall 기능을 전혀 제공하지 않는다는 것이다.
그렇다면 수신 전용 프로토콜인 IMAP, POP3는 무엇일까?
IMAP은 메일을 서버에 남겨둔 채 읽을 수 있는 프로토콜로, 다중 기기에서 동일한 메일함을 접근할 수 있도록 해주는 프로토콜이다.
때문에 수신자가 메일을 열람하기 전이라면 서버 내의 메일을 삭제할 수 있는 가능성이 존재한다.
반면 POP3는 메일을 특정 기기에서 다운로드하면 서버에서 메일을 자동으로 삭제하는 프로토콜이다.
요즘에는 POP3를 자주 사용하지 않는다곤 하지만 여전히 남아있기도 하다.
하지만 여기까지만 봐서는 완벽히 이해하기 어렵다.
우리는 어쨌든 "발송 취소" 기능을 사용하고 있기 때문이다.
Recall은 없는 거야
Recall = Undo = 발송 취소 = 보내기 취소
사실 이메일 시스템 상에 Recall이라는 기능은 없다.
근데 약간 의아하다. 필수일 것 같은 기능이 대체 왜 없다는 걸까?
대부분의 인터넷 프로토콜은 뭔가 이해가 가지 않는다면 주로 설계 철학이 원인인 경우가 많더라(물론 보안 문제, 기술적 난이도 문제가 원인인 부분도 있다).
기본적으로 이메일 시스템은 안정성, 투명성, 상호 운용성을 최우선 가치로 설계되었다고 한다.
결국 이에 따르면, Recall 같은 사후 제어는 본질적으로 이메일 시스템의 설계 원칙에 위배되는 기능인 것이다.
우리가 기본 기능이라고 착각하는 Recall 시스템은 사실 특정 환경에서만 제한적으로 제공되는 부가 기능일 뿐이다.
Recall 버튼을 누르면,
발신자의 메일 클라이언트가 수신자에게 메일 삭제 요청 메시지를 전달한다.
만약 수신자도 Recall 기능을 지원하는 환경이라면, 해당 요청을 처리해서 메일을 삭제하게 되는 것이다.
정리해 보자면, 나뿐만 아니라 상대방의 시스템도 Recall 메시지를 처리할 수 있는 경우에만 동작한다.
찾아보니 Outlook에서 Exchange 서버를 활용하지 않는 한은 Recall 기능을 기대하긴 어려운 것 같다.
혹은 Recall 기능이 정상적으로 구현되어 있는 동일한 메일 시스템끼리 메일을 주고받는 경우라면 가능할 것이다(e.g. 교내 메일 시스템, 인트라넷 메일, ...).
지메일, 네이버, 다음, 썬더버드 등은 기본적으로 Recall 메시지를 무시한다고 한다(이건 GPT피셜이라 아닐 수도 있다).
다만 가능한 경우더라도, POP3, IMAP 설정으로 외부 메일 시스템에 우회 연결을 해뒀다면 무의미해질 가능성이 크다.
결국에는
Recall 기능은 없다고 생각하는 게 마음 편하다.
따라서 중요한 메일일수록 보내기 전에는 반드시 충분한 고민 후에 발송하도록 하자.
후배님 덕분에 웃음도 얻고 소소한 네트워크 지식도 얻고.
좋다.