(펌)

여기 불가능처럼 들리는 문제가 있습니다. 이 이야기를 공개적인 곳에 올리는걸 분명 후회할겁니다. 왜냐면 이 이야기는 컨퍼런스 갔을 때 술마시면서 하기 좋은 대단한 이야기기 때문이니까요. ???? 이 이야기는 잘못된 부분, 관련 없고 지루한 내용은 좀 정리하고 전체적인 내용을 좀 더 흥미롭게 만들었습니다.

저는 학내 이메일 서비스를 운영하는 일을 하고 있던 몇 년 전에 통계학부 주임교수에게 전화를 받았습니다.

“지금 학부 외부로 메일을 보내는데 문제가 발생했습니다.”

“무슨 문제인가요?” 제가 물었습니다.

“500 마일 (역주. 800km 가량) 이상 되는 거리엔 메일을 보낼 수가 없어요.” 주임교수가 말했습니다.

난 마시던 커피를 뿜을 뻔 했습니다. “뭐라고 하셨죠?”

“500마일보다 먼 거리에는 메일을 보낼 수가 없다고 했어요.”, 교수가 다시 말했습니다. “정확히는 조금 더 멀어요. 520 마일. 하지만 그 보다 먼 곳으로는 보낼 수가 없어요.”

“음… 이메일은 그런 방식으론 동작하진 않습니다. 일반적으로는,” 내 놀란 목소리를 억누르며 말했습니다. 학부 주임교수에게 놀란 모습을 보이지 않았습니다. 비록 통계학부가 상대적으로 빈곤하긴 했지만 말입니다. “어떤 점이 500여 마일보다 먼 거리에 메일을 보낼 수 없게 한다고 생각하시나요?”

“내가 그렇게 생각하는게 아니라,” 주임교수가 무의식적으로 답변했습니다. “보세요. 이 문제를 처음으로 알게 된 것은 며칠 전입니-”

“며칠을 기다렸다고요?” 떨리는 목소리로 교수의 말을 잘라버렸습니다. “그리고 매번 메일을 보낼 수 없었다는 건가요?”

“메일은 보낼 수 있어요. 단지 더 먼 거리–”

“아 500마일, 네.” 교수의 말을 제가 대신 정리했습니다. “이제 알겠습니다. 하지만 왜 더 일찍 전화하지 않으셨죠?”

“아, 어떤 점이 문제인지, 무슨 일이 나타나고 있는 것인지 지금까지 충분한 자료를 모으지 못했기 때문입니다.” 맞습니다. 지금 통계학 전임교수랑 통화하고 있었습니다. “아무튼, 이 문제를 지리통계학자에게 물어봤습니다–”

“지리통계학자들요….”

“–네, 그분은 우리가 이메일을 발송한 범위를 지도 위에 반경으로 그렸는데 500 마일을 약간 넘는 거리였습니다. 반경 내에서도 이메일이 도달하지 않은 곳도 산발적으로 있긴 했지만 절대 500 마일 범위를 넘기지는 못했습니다.”

“알겠습니다.” 대답하며 머리에 손을 얹었다. “언제부터 이런 문제가 생겼나요? 아까 며칠 전이라 말씀하셨는데 그 기간 동안 시스템이 달라진 부분은 없었나요?”

“한번은 컨설턴트가 와서 서버를 패치하고 재부팅을 했습니다. 그분에게 전화해서 물어봤는데 메일 시스템은 전혀 만지지 않았다고 하더군요.”

“알겠습니다, 제가 살펴보고 다시 전화 드리죠.” 이 말을 점점 믿게 되는 게 두려웠습니다. 만우절 장난도 아니었습니다. 혹시나 이전에 이런 장난을 쳤던 적이 있었나 생각해봤습니다.

그 부서 서버에 접속한 후에 테스트 메일을 발송했습니다. 이 서버는 노스 케롤라이나의 연구소 삼각지역에 있었고 테스트 메일은 제 메일로 문제 없이 들어왔습니다. 같은 메일을 리치몬드, 아틀란타와 워싱턴에 전송했습니다. 프린스턴 (400 마일)에도 문제 없었습니다.

그리고 멤피스에 이메일을 보냈습니다. (600 마일) 실패했습니다. 보스턴, 실패. 디트로이트, 실패. 제 연락처 목록을 보면서 범위를 좁혀 나갔습니다. 뉴욕(420 마일)은 수신에 성공했고 프로비던스(580 마일)은 실패했습니다.

제가 점점 정신이 나가고 있나 생각이 들었습니다. 저는 노스 케롤라이나에 있지만 시애틀에 있는 ISP를 사용하는 친구에게 이메일을 보냈습니다. 감사하게도, 실패했습니다. 메일 서버가 아니라 실제로 메일을 수신한 사람의 지리적 위치가 문제였다면 저는 울어버렸을 겁니다.

이 문제는 –믿을 수 없지만– 실제로 존재하고 반복 가능한 상황이었습니다. sendmail.cf 파일도 확인했지만 평범했습니다. 파일 내용은 심지어 친숙하게 느껴졌습니다.

제 홈 디렉토리에 있는 sendmail.cf랑 비교해보니 이 sendmail.cf와 토씨 하나 다르지 않는 것 보니 제가 작성한 것에 틀림 없습니다. 제가 “500마일이상전송_불가” 설정을 해놓지 않았다는 것은 분명했습니다. 포기하는 심정으로 SMTP 포트에 텔넷 접속을 했습니다. 서버는 SunOS 샌드메일 문구를 행복하게 보여줬습니다.

잠깐, SunOS의 샌드메일 문구를 보게 되었습니다. 당시에 Sun은 Sendmail 8이 상당히 성숙했지만 Sendmail 5를 운영체제와 함께 배부하고 있었습니다. 저는 좋은 시스템 관리자로서 Sendmail 8을 표준으로 사용했습니다. 그리고 또한 좋은 시스템 관리자로서 Sendmail 5에서 쓰던 암호같은 코드로 짜여진 설정 파일 대신 sendmail.cf에 각 설정과 변수를 길게 설명하는 Sendmail 8의 설정 파일을 사용했습니다.

문제 조각이 하나씩 들어맞기 시작할 때 이미 다 차가워진 커피에 사레 걸렸습니다. 컨설턴트가 “서버를 패치했다”고 말했을 때 SunOS 버전을 업그레이드 한 것은 분명했지만 샌드메일을 다운그레이드도 했던 것입니다. 업그레이드 동작에서 친절하게 sendmail.cf는 그대로 남게 되었고 전혀 맞지 않는 버전과 함께 돌아가게 되었습니다.

Sun에서 제공한 Sendmail 5는 몇가지 차이가 있긴 했지만 Sendmail 8에서 사용하는 sendmail.cf도 별 문제 없이 그대로 사용할 수 있었습니다. 하지만 새로운 설정 내역의 경우는 쓸모 없는 정보로 처리하고 넘겨버렸습니다. sendmail의 바이너리에는 컴파일에 기본 설정이 포함되어 있지 않아서 적당한 설정을 sendmail.cf 파일에 적지 않은 경우는 0으로 설정하고 있습니다.

0으로 설정된 것 중 하나로 원격 SMTP 서버에 접속하기 위한 대기시간(timeout)이 있었습니다. 이 장비에서 일정 사용량이 있는 상황으로 가정하고 몇가지 시험을 수행했습니다. 대기시간이 0으로 설정된 경우에는 3 밀리초가 조금 넘으면 접속에 실패한 것으로 처리되고 있었습니다.

당시 캠퍼스 네트워크의 특이한 기능 중 하나는 100% 스위치라는 점이었습니다. 외부로 나가는 패킷은 POP에 닿기 전이나 라우터로부터 한참 떨어진 곳이 아닌 이상에야 라우터 지연이 발생하지 않았습니다. 그래서 네트워크에서 가까운, 부하가 약간 있는 상태의 원격 호스트에 접속하는 상황이라면 문제가 될 만한 라우터 지연없이 광속에 가까운 속도로 접속할 수 있었습니다.

심호흡을 하고 쉘에서 계산해봤습니다.

$ units 1311 units, 63 prefixes You have: 3 millilightseconds You want: miles * 558.84719 / 0.0017893979

“500 마일, 또는 그보다 조금 더.”


------------------

요약 : 서버 패치로 메일 설정이 삑나서 디폴트인 대기시간 0 (=3 밀리초)로 설정되버림
-> 전기 신호가 3밀리초 (0.003 초 * 거의 광속 = 약 558 마일) 내로 전송완료가 안 되면 전송 실패가 뜸


이 사례를 보면, 누가 상식적이지 않은 사례를 말해도 사실은 무언가 이유가 있지 않을까 한 번 더 생각하게 됩니다..