???: 이메일이 800km 밖으로는 전송이 안돼요 ㅠㅠㅠ

500마일 밖으로는 안 가는 이메일 사건

말도 안 되는 헛소리처럼 들렸던 문제 하나를 소개합니다. 사실 학회 같은 자리에서 술 한잔 걸치며 풀기에 딱 좋은 썰이라, 이걸 공개된 곳에 올려버리는 게 좀 아깝기도 하네요. :-)

참고로 관계자들의 프라이버시를 지켜주고, 지루하고 불필요한 세부 사항은 쳐내면서 이야기를 전반적으로 더 재미있게 다듬기 위해 약간의 각색을 거쳤습니다.

몇 년 전, 대학 캠퍼스 이메일 시스템을 관리하는 일을 하고 있을 때 통계학과 학과장님에게서 전화 한 통을 받았습니다.

"우리 과 밖으로 나가는 이메일에 문제가 좀 생겨서요."

"어떤 문제인가요?" 내가 물었습니다.

"메일이 500마일 넘는 곳으로는 가질 않아요." 학과장님이 설명했습니다.

나는 마시던 라떼를 뿜을 뻔했습니다. "…네? 뭐라고요?"

"여기서 500마일보다 먼 곳으로는 메일을 보낼 수가 없다니까요." 학과장님이 반복해서 말했습니다. "정확히는 조금 더 가긴 합니다. 한 520마일 정도? 하지만 그 이상은 절대 안 가요."

"음… 메일 시스템은 원래 그런 식으로 작동하지는 않는데요." 당황한 기색을 숨기려 애쓰며 대답했습니다. 통계학과처럼 비교적 예산이 쪼들리는 학과라 할지라도, 학과장에게 대놓고 멘붕 온 모습을 보일 수는 없으니까요. "메일이 500마일 넘게 못 간다는 걸 어떻게 아셨습니까?"

"그냥 제 '추측'이 아닙니다." 학과장님이 퉁명스럽게 쏘아붙였습니다. "보세요, 며칠 전에 이 현상을 처음 발견했을 때—"

"며칠을 기다리셨다고요?" 나도 모르게 떨리는 목소리로 말을 끊었습니다. "그럼 그동안 계속 이메일을 못 보내신 겁니까?"

"이메일은 보낼 수 있었습니다. 단지—"

"—500마일 넘는 곳만 안 갔다, 이 말씀이시죠." 학과장님의 말을 받아쳤습니다. "그건 알겠습니다. 그런데 왜 진작 연락을 안 주셨습니까?"

"상황을 확신할 만큼 충분한 데이터를 수집하지 못했었으니까요. 방금 전에서야 데이터가 모였습니다."

…그렇지. 이분 통계학과 학과장님이셨지.

"아무튼, 공간통계학 전공자 한 명한테 조사를 좀 부탁했더니—"

"공간통계학자요…?"

"—네, 그랬더니 지도를 하나 만들어 오더군요. 우리가 이메일을 보낼 수 있는 반경을 표시한 건데, 500마일보다 아주 약간 넓은 수준이었습니다. 물론 그 반경 안에서도 아예 안 가거나 간헐적으로만 가는 곳들이 몇 군데 있긴 했지만, 확실한 건 그 반경 밖으로는 절대 보낼 수가 없다는 점입니다."

"그렇군요." 나는 머리를 감싸 쥐었습니다. "이게 언제부터 시작된 건가요? 며칠 전이라고 하셨는데, 혹시 그때 시스템 쪽에 뭔가 변경된 게 있나요?"

"글쎄요, 외주 엔지니어가 와서 서버 패치를 하고 재부팅을 하긴 했습니다. 하지만 그 친구한테 전화해 보니 메일 시스템은 전혀 손대지 않았다고 하더군요."

"알겠습니다. 제가 한번 살펴보고 다시 연락드리겠습니다."

내가 지금 장단을 맞춰주고 있는 게 맞나 싶었습니다. 만우절도 아니었고, 나한테 이런 짓궂은 장난을 칠 만한 빚을 진 사람이 있었나 머리를 굴려보았습니다.

통계학과 서버에 접속해 테스트 메일을 몇 통 보내보았습니다. 당시 서버 위치는 노스캐롤라이나주 리서치 트라이앵글이었습니다. 내 개인 계정으로 보낸 테스트 메일은 아무 문제 없이 도착했습니다. 리치먼드, 애틀랜타, 워싱턴으로 보낸 메일도 정상 도착. 프린스턴(400마일)으로 보낸 것도 잘 갔습니다.

그런데 멤피스(600마일)로 메일을 보내봤습니다. 전송 실패.

보스턴, 실패. 디트로이트, 실패.

주소록을 꺼내 들고 범위를 좁혀보기 시작했습니다. 뉴욕(420마일)은 성공, 하지만 프로비던스(580마일)는 실패.

슬슬 내가 미쳐가는 건가 싶었습니다. 혹시나 해서 노스캐롤라이나에 살지만 ISP(인터넷 서비스 제공자)는 시애틀에 있는 친구에게 메일을 보내보았습니다.

다행히도, 전송 실패가 떴습니다. 만약 수신자가 거주하는 물리적 위치에 따라 메일이 안 가는 거였다면, 난 아마 그 자리에서 주저앉아 울어버렸을 겁니다.

믿기 힘들지만 보고된 문제가 진짜였고, 완벽하게 재현까지 된다는 걸 확인한 뒤 sendmail.cf 설정 파일을 열어보았습니다. 겉보기엔 평범했습니다. 아니, 사실 아주 익숙한 파일이었습니다.

내 홈 디렉터리에 있던 sendmail.cf와 diff로 비교해 보았습니다. 수정된 흔적은 없었습니다. 애초에 내가 작성했던 sendmail.cf 파일 그대로였습니다. 그리고 내 기억에 FAIL_MAIL_OVER_500_MILES 같은 황당한 옵션을 켜두지는 않았을 터였습니다. 도무지 감이 안 잡혀 SMTP 포트로 telnet 접속을 시도했습니다.

그러자 서버는 해맑게도 SunOS 전용 Sendmail 배너를 띄워 반겨주었습니다.

잠깐만… SunOS Sendmail 배너라고?

당시 Sendmail 8이 이미 꽤 안정화된 버전으로 나와 있었음에도, Sun사에서는 여전히 자사 운영체제에 Sendmail 5를 기본으로 탑재해 출하하고 있었습니다. 하지만 개념 있는 시스템 관리자였던 나는 Sendmail 8로 표준화를 마친 상태였습니다. 게다가 일 잘하는 관리자답게, Sendmail 5에서 쓰던 암호 같은 구두점 코드 대신 Sendmail 8에서 지원하는 직관적이고 친절한 긴 옵션명과 변수명을 써서 sendmail.cf를 작성해 뒀었습니다.

퍼즐 조각들이 한순간에 딱 맞아떨어졌습니다. 다 식어빠진 라떼 찌꺼기를 삼키다 사레가 들렸습니다.

외주 엔지니어가 "서버 패치"를 하면서 SunOS 버전을 업그레이드했고, 그 과정에서 Sendmail을 다운그레이드해 버린 것이었습니다. 친절하게도(?) 업그레이드 프로그램은 sendmail.cf 파일은 건드리지 않고 그대로 놔두었는데, 정작 버전이 안 맞는 파일이 되어버린 것이죠.

공교롭게도 Sun사가 약간 손봐서 내놓은 Sendmail 5 버전은 Sendmail 8의 sendmail.cf를 읽을 수는 있었습니다. 기본적인 룰셋 문법은 크게 바뀌지 않았기 때문입니다. 하지만 길게 풀어서 쓴 새로운 설정 옵션들은 완전히 쓰레기 값 취급하며 그냥 건너뛰어 버렸습니다. 게다가 sendmail 바이너리 자체에는 이런 옵션에 대한 기본 컴파일 값이 없었기 때문에, sendmail.cf에서 유효한 값을 찾지 못하자 전부 0으로 설정해 버린 것입니다.

0으로 설정된 옵션 중 하나가 바로 '원격 SMTP 서버와의 연결 타임아웃(timeout)'이었습니다.

이 특정 서버의 일반적인 시스템 부하를 고려해 테스트해 본 결과, 타임아웃 값이 0이면 시스템 연결(connect) 호출은 약 3밀리초를 조금 넘기는 시점에 강제 종료되었습니다.

당시 우리 캠퍼스 네트워크의 특이한 점은 100% 스위칭 환경이었다는 점입니다. 즉, 나가는 패킷은 학내 접속점(POP)을 찍고 반대편 라우터에 도달하기 전까지 라우터로 인한 지연(delay)을 전혀 겪지 않았습니다. 따라서 가까운 네트워크에 있는 부하가 적은 원격 호스트로 연결을 맺는 데 걸리는 시간은, 부수적인 라우터 지연 시간이 아니라 목적지까지의 물리적 거리를 빛의 속도로 이동하는 시간에 의해 결정되고 있었던 것입니다.

약간의 현기증을 느끼며, 셸에 명령어를 입력해 보았습니다.

"500마일, 혹은 그보다 조금 더."