태도의 문제, 편협함을 경계할 것! 바닐라 아이스크림에 알레르기가 있는 자동차

나는 기계 밥 먹고 사는 엔지니어다.
나름의 배경지식으로 문제가 될 부분을 소거해 나가는 식으로 추론해 일을 해결하곤 하는데, 
말도 안 되는 것은 무시하고 빠른 결론을 내리기 위한 합리적인 방법을 취하곤 한다. 
그런데 진짜 말도 안 되는 것이 때론 말이 되곤 한다.  그리고 그건 기상천외한 방법으로 나에게 훈계를 준다. 

GM사의 폰티악 부서에 고객 불만 사항이 하나 접수되었다

"이게 제가 귀사에 보내는 두 번째 편지입니다만, 
제가 좀 정신 나간 사람으로 보였을 수도 있으니까 답변이 없으신 것을 탓하려는 것은 아니고요, 
어쨌든 우리 가족이 매일 저녁식사 후 디저트로 아이스크림을 먹는 전통이 있는 것은 사실입니다. 
그런데 아이스크림의 종류가 많으니까 매일 저녁식사가 끝나면 온 가족이 그 날은 어떤 아이스크림을 먹을 것인지 투표를 해서 제가 그걸 사러 차를 타고 가게에 갑니다. 
제가 최근 폰티악 신차를 구입하였는데 그 이후로 가게에 다니는 일에 문제가 생긴 것도 사실입니다. 
제가 바닐라 아이스크림을 사기만 하면 차에 돌아와 다시 시동을 걸려고 해도 시동이 안 걸리더라 이 말씀입니다. 다른 종류의 아이스크림을 샀을 때는 그야 아주 잘 걸리고요. 아무리 바보 같이 들리실망정, 제가 이 문제에 심각하다는 사실을 알아주시기 바랍니다: '폰티악 자동차에 제가 바닐라 아이스크림을 사면 시동이 안 걸리고 다른 종류를 사면 쉽게 걸리게 만드는 그 무엇이 있는 건가요?'"

GM 사장은 그 편지를 보고 물론 납득하기 어려웠지만 어쨌든 엔지니어 한 사람을 점검하러 보냈다. 엔지니어는, 고급 주택가에서 잘 살며 분명히 학력이 높아 보이는 한 남자의 영접을 받고 놀랐다. 저녁식사 직후에 만나기로 약속이 되어 있었으므로, 두 사람은 즉시 차에 올라 아이스크림 가게로 갔다. 그날 저녁은 바닐라 아이스크림이었는데, 아닌 게 아니라, 차에 돌아왔을 때 시동이 걸리지 않았다.

엔지니어는 그 후로도 사흘간을 저녁마다 방문하였다. 첫날 초콜릿 아이스크림을 사니까 시동이 걸렸다. 둘째 날 딸기 아이스크림을 사니까 시동이 걸렸다. 셋째 날 바닐라 아이스크림을 샀더니 시동이 안 걸렸다.

그러자 논리적 성격인 엔지니어는, 그 차가 바닐라 아이스크림에 알레르기가 있다고 믿지는 않았으므로, 문제 해결에 얼마나 시간이 걸리건 계속 방문해 보기로 하였다. 그리고 그 목표를 위하여 메모를 하기 시작하였다: 그는 모든 종류의 데이터를 기록하였다 - 일시, 연료의 종류, 왕복 소요시간 등.


얼마 안 가서 그는 실마리를 잡았다.
바닐라를 살 때는 다른 종류를 살 때보다 시간이 덜 걸렸다. 왜냐고? 해답은 그 가게의 상품 배치 형태였다.


바닐라는 가장 인기있는 품목이기 때문에 사람들이 빨리 살 수 있도록 다른 통에 담아 가게의 맨 앞 쪽에 따로 놓여 있었다. 다른 향의 아이스크림들은 모두 다른 계산대 근처의 가게 뒤 쪽에 진열되어 있어서 향을 고르고 계산을 마칠 때까지 시간이 상당히 오래 걸리게 되어 있었다.


이제 엔지니어에게 남은 숙제는 어째서 시간이 덜 걸리면 시동이 안 되는가 하는 문제였다. 일단, 바닐라 아이스크림이 아니고, 시간이 문제로 떠오르자 엔지니어는 금세 해답을 찾을 수 있었다: 다름 아닌 「베이퍼락」이었다. 그 현상이 매일 저녁에 발생하였지만, 다른 향의 아이스크림을 살 때는 시간이 조금 더 걸리니까 엔진을 좀 더 식혀 주어서 시동이 잘 되었던 것이고, 바닐라 향을 살 때는 엔진이 아직 너무 뜨거워 베이퍼락이 해소되지 못한 상태였던 것이다.


이 이야기의 교훈 : 말도 안 돼 보이는 문제일지라도 때로는 진지할 수 있다.


['vaporlock'은 '증기 폐색(김 잠금)'이라고 번역되는 일종의 엔진 트러블인데요, 실린더 내에 증기가 꽉 차 있어서 일시적으로 점화를 방해하는 현상이랍니다 = 역자 주]

 

아내가 아이에게 프로그래밍을 가르치면 논리적인 판단을 하는 게 쉬워질 테니 가르치는 게 어떻냐는 질문을 했었다.

그 질문에 나는 No 라고 대답했고, 그 이유로 편협해질 수 있어서 라고 말했다.
모국어 하나만 잘 하는 사람이 100%의 언어 표현력을 가진다고 하면 두 개의 언어를 다 잘하는 바이링구얼(이중언어구사자)은 두 개 모두 80%가량만 표현하는 것과 비슷하다. 

사람은 자기에게 동질감을 주는 것에는 너그럽지만, 작은 이질감에서부터는 거부감이 강해지곤 한다.
바이링구얼이 20%를 메꾸기 위한 노력을 잘 안 하게 되는 것과, 자신의 논리를 벗어나는 것은 현실 부정을 먼저 하게 되는 것과 같다.

 

 

 

위와 비슷한 사례가 또 있는데, 이메일 서비스 설정에 대한 지식이 있다면 좀 더 이해하기 쉽지만 아니라도 문맥으로 이해할 수 있어서 소개합니다.

아울러 좀 더 직설적으로 스스로 엔지니어라고 생각하는 사람에게 읽어보았으면 하는 글의 링크도 남깁니다.

 

원문 : The case of the 500-mile email 500 마일 이메일 문제

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

저는 학내 이메일 서비스를 운영하는 일을 하고 있던 몇 년 전에 통계학부 주임교수에게 전화를 받았습니다.
“지금 학부 외부로 메일을 보내는데 문제가 발생했습니다.”
“무슨 문제인가요?” 제가 물었습니다.
“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 마일, 또는 그보다 조금 더.”

출처 : The case of the 500-mile email 500 마일 이메일 문제