800km 밖에 못 가는 이메일
Warning
노트
The case of the 500-mile email의 번역본이다. 글이 짧아서 전문을 번역한다.
500마일 이메일 사례 (원래는 SAGE 가장 불가능한 임무?)
몇 년 전, 캠퍼스 이메일 시스템을 관리하던 때에 통계학과 학과장한테 전화가 왔다.
"우리 학과에서 이메일을 보내는 데 문제가 있어요."
"어떤 문제인가요?" 내가 물었다.
"우리는 500마일 이상 멀리 이메일을 보낼 수 없어요," 학과장이 설명했다.
나는 라떼를 삼키며 "다시 말씀해 주시겠어요?"라고 말했다.
"500마일 이상 멀리 이메일을 보낼 수 없다는 거예요," 그가 반복했다. "사실 조금 더 멀리는 갈 수 있어요. 520마일 정도까지요. 하지만 그 이상은 안 돼요."
"음... 일반적으로 이메일은 그렇게 작동하지 않아요," 나는 당황한 걸 감추려고 애쓰며 말했다. 학과장 앞에서는 당황한 모습을 안 보이는 게 좋다. 특히 통계학과처럼 자원이 빠듯한 학과에서는 더 그렇다. "500마일 이상 보낼 수 없다고 생각하시는 이유가 뭔가요?"
"제가 생각하는 것이 아니라," 학과장이 짜증 섞인 목소리로 대답했다. "이 문제가 처음 발생했을 때 며칠 전부터--"
"며칠이나 기다리셨어요?" 나는 목소리가 떨리는 걸 느끼며 끼어들었다. "그 동안 이메일을 전혀 보내지 못했나요?"
"이메일은 보냈어요. 그냥 500마일 이상은--"
"--네, 알겠어요, 500마일이요," 나는 그의 말을 대신 끝냈다. "하지만 왜 더 일찍 전화하지 않으셨죠?"
"확실한 데이터를 수집할 때까지 기다렸어요." 아, 통계학 학과장이다. "어쨌든, 저희는 지리통계학자에게 이 문제를 조사하도록 했어요--"
"지리통계학자들이..."
"--네, 그리고 그녀는 우리가 이메일을 보낼 수 있는 반경이 500마일 조금 넘는다는 것을 보여주는 지도를 만들었어요. 그 반경 내에도 도달하지 못하는 목적지가 몇 군데 있긴 하지만, 저희는 절대로 이 반경보다 멀리 이메일을 보낼 수 없어요."
"알겠습니다," 나는 머리를 손에 묻으며 말했다. "이 문제가 언제 시작됐나요? 며칠 전이라고 했지만, 그때 시스템에 변화가 있었나요?"
"글쎄요, 컨설턴트가 와서 서버에 패치를 하고 재부팅했어요. 하지만 그에게 전화를 걸어 물어봤는데, 그는 메일 시스템에 손대지 않았다고 하더군요."
"알겠어요, 제가 한번 살펴보고 다시 연락 드리겠습니다," 나도 거의 믿기지 않는다는 투로 말했다. 만우절도 아닌데 누군가 나한테 장난을 치는 것 같았다.
나는 그 학과 서버에 로그인해서 테스트 메일을 몇 개 보냈다. 이 일은 노스캐롤라이나의 리서치 트라이앵글에서 일어났다. 내 계정으로 보낸 테스트 메일은 문제없이 도착했다. 리치몬드, 애틀랜타, 워싱턴으로 보낸 것도 마찬가지였다. 프린스턴(400마일 거리)으로 보낸 것도 갔다.
근데 멤피스(600마일)로 보내자 실패했다. 보스턴, 실패. 디트로이트, 실패. 나는 주소록을 꺼내 범위를 좁혀 가기 시작했다. 뉴욕(420마일)은 갔지만 프로비던스(580마일)는 실패했다.
정신이 나가는 것 같았다. 노스캐롤라이나에 사는 친구한테 메일을 보내려고 했는데, 그 친구의 ISP는 시애틀에 있었다. 다행히 실패했다. 문제가 메일 서버 위치가 아니라 받는 사람 위치랑 관련 있었다면 나는 울었을 거다.
보고된 문제가 사실이고 다시 재현까지 된다는 걸 확인하고 나서, 나는 sendmail.cf 파일을 살펴봤다. 파일은 멀쩡해 보였다. 사실 익숙해 보였다.
내 홈 디렉토리에 있는 sendmail.cf랑 비교해 봤다. 바뀐 게 없었다. 내가 쓴 sendmail.cf였다. 그리고 나는 500마일 이상 이메일을 실패하게 하는 옵션을 켠 적이 없다는 걸 확신했다. 답이 안 보여서 SMTP 포트에 telnet으로 붙었다. 서버는 SunOS sendmail 배너로 반갑게 응답했다.
잠깐, SunOS sendmail 배너라고? 당시 Sun은 Sendmail 8이 이미 꽤 성숙했는데도 운영 체제에 Sendmail 5를 같이 넣어서 내보내고 있었다. 좋은 시스템 관리자답게 나는 Sendmail 8을 표준으로 삼았다. 그리고 역시 좋은 시스템 관리자답게, Sendmail 5 시절의 암호 같은 코드 대신 Sendmail 8에서 쓸 수 있는 긴 자체 설명 옵션과 변수 이름을 쓰는 sendmail.cf를 썼다.
퍼즐이 한 번에 맞춰졌고, 나는 다시 차가워진 라떼 찌꺼기에 목이 메었다. 컨설턴트가 "서버를 패치했을" 때 그는 SunOS 버전을 업그레이드했고, 그 과정에서 Sendmail은 _다운그레이드_됐다. 업그레이드는 친절하게도, 이제 버전이 안 맞게 된 sendmail.cf 파일은 그대로 뒀다.
당시 Sun이 낸 Sendmail 5는 몇 가지 손을 봐서 Sendmail 8의 sendmail.cf랑도 돌아갈 수 있었다. 규칙 대부분이 그때까지 안 바뀌었기 때문이다. 근데 새로 생긴 긴 설정 옵션들은 Sendmail이 무시했다. 그리고 sendmail 바이너리에는 그런 설정들의 컴파일 기본값이 대부분 없어서, sendmail.cf에서 제대로 된 설정을 못 찾으면 값이 전부 제로(0)가 됐다.
0이 된 설정 중 하나가 원격 SMTP 서버에 붙을 때의 타임아웃이었다. 실험을 몇 번 해 보니, 이 기계는 평소 부하에서 타임아웃이 0이면 3밀리초를 조금만 넘겨도 접속 실패로 처리하고 있었다.
당시 우리 캠퍼스 네트워크의 이상한 점 하나는 100% 스위치 네트워크였다는 거다. 나가는 패킷은 POP을 지나 반대편 라우터에 닿을 때까지 라우터 지연이 없었다. 그러니까 가까운 네트워크에 있는 한가한 원격 호스트에 붙는 시간은 라우터 지연보다 목적지까지 빛이 가는 거리가 사실상 정했다.
심호흡을 하고 터미널에 입력했다.
"500마일, 아니면 조금 더."
- 트레이 해리스