2년 차 운전자 A씨의 이야기
이 차는 차를 운전한지 2년 차 된 A씨 소유입니다. A씨는 운전은 하지만 사실 차에 대해서는 잘 모릅니다. (음.. 예전 모 CF의 광고문구네요.) A씨는 작년에 타던 중고차를 처분하고 이번에 M 사의 최신 자동차를 구입했습니다. 남들이 하는 걸 보니 멋져 보여서 차에 사제 HID도 달고, 오디오 튜닝도 했습니다.
다음 날 A씨는 급한 약속이 있어서 가족과 함께 어딘가로 가기 위해 차의 시동을 걸어봅니다. 어라? 멀쩡하던 차가 시동이 안 걸립니다. 몇 번 시동을 걸어보다가 자기 나름대로는 보닛도 열어봤습니다만 도대체 뭐가 뭔지, 시동이 왜 안 걸리는지 하나도 모르겠습니다. 아내는 바쁜데 이게 뭐냐고 구박하고, 애는 덥다고 에어컨 틀어달라고 빽빽 울어대기 시작했습니다. 나름 유명회사의 최신 자동차를 비싸게 주고 샀는데 차가 말썽이 생기니 짜증이 이만 저만 나는 게 아닙니다.
일단 보험회사에 전화를 했는데 긴급출동 서비스 제공 대상 고객이 아니랍니다. 기억을 더듬어 보니, 보험 가입 첫해인 작년에는 긴급출동 서비스를 가입했었는데 올해 자동차 보험을 갱신하면서 어차피 잘 안 쓰는 거 같아서 보험료 아낀다고 긴급출동 서비스를 빼버렸던 게 기억이 납니다.
일반 카센터에 전화를 할까 했지만, 돈이 많이 들어갈 것 같아서 무섭습니다. 어찌할까 발을 동동 구르다가 문득 근처에 사는 아는 후배 중에 자동차에 대해 좀 아는 B가 있다는 것이 기억이 나서 전화를 합니다.

A씨 : "야, B! 나 지금 되게 급한데 차가 시동이 안 걸려. 빨리 와서 좀 해결해줘!"
B씨 : "예? 음.. 제가 지금 바로는 안되고 30분 내로는 갈 수 있습니다만.."
A씨 : "아씨, 급하다니깐! 빨리 와!"
B씨 : "... 네.. 알겠습니다."

결국 불쌍한 후배 B가 바로 달려왔습니다.

B씨 : "어디가 문제죠?"
A씨 : "몰라, 어제까지 되던 놈이 안되네. 빨랑 시동 좀 걸어봐!"

잠시 후 B는 배터리가 방전되었다는 것을 찾아냅니다.

B씨 : "배터리 방전이네요."
A씨 : "그래서? 어떻게 해야 되는데?"
B씨 : "다른 차랑 점프 케이블로 연결하면 시동이 걸릴 겁니다."
A씨 : "그래? 그게 어딨어?"
B씨 : "일단 제 차에 있습니다. 앞으로 또 이런 일이 있을지 모르니 선배님도 하나 구입하시고, 어떻게 하는지도 한번 보시죠."
A씨 : "난 그런 거 몰라. 그냥 자네가 해결해줘."
B씨 : "..."

결국 B씨가 혼자 점핑을 해서 시동을 걸어줍니다.

A씨 : "아, 드디어 걸렸네!"
B씨 : "선배님 그런데 이 차 말입니다. 아무래도 전기장치가 좀 불안한 거 같은데요. 특별한 증상 같은 거 없으셨나요?"
A씨 : "아아, 나중에 얘기하자구. 내가 급해서~"

A씨는 서둘러 가족들을 태우고 떠납니다.

가족들과 볼 일을 마친 A씨는 또다시 시동이 걸리지 않는 것을 발견합니다.
또다시 B에게 전화를 했지만 이번에는 B가 전화를 받지 않습니다.
결국 A씨는 카센터에 전화를 했고, 출장 기사가 왔습니다.
그런데 이번에는 점핑으로도 시동이 걸리지 않아서 결국 견인을 하게 됩니다.
카센터에서 점검 결과 배터리가 완전히 나가 버렸다고 합니다.
문제는 아무래도 불법으로 장착한 사제 HID와 오디오 때문인 것 같습니다.
결국 A씨는 견인비와 배터리값으로 많은 돈을 지출하게 됩니다.
그리고 마음 속으로 다시는 M사의 자동차는 사지 않겠다고 굳은 결심을 합니다.

A씨의 이야기에 담긴 것은?
A씨 얘기를 읽으면서 재밌으셨습니까? 여기에 숨겨져 있는 A씨와 일부 개발자들의 공통점을 짚어내 보도록 하겠습니다.

1. 과정보다는 결과를 중요시한다.
A씨는 시동이 걸리지 않은 원인, 시동이 걸리지 않는 문제를 조치하는 과정에는 전혀 관심없이 빨리 차를 몰고 약속장소로 가야 한다는 결과에만 집착했습니다.
이렇듯 질문의 상당 부분들은 ‘문제에 대한 해결 요청’인 경우가 많습니다. 일단 문제는 터져 있는 상황이고, 빨리 해결 못하면 위에서 쪼아댈테고.. 그러다 보니 문제를 최대한 빨리 해결하는 것에 관심이 있지, 문제가 발생하는 원인이 무엇이며 그 원인을 제거하거나 회피하기 위해서 어떤 과정을 거쳐서 처리해야 한다는 것에는 관심이 없습니다.

2. 문제가 발생하는 것에는 항상 계기가 있다.
뭔가 문제가 발생해서 오는 질문들 중에 가장 황당한 질문은 "어제까지는 됐는데, 갑자기 오늘 아침부터 갑자기 안 됩니다. 어떻게 해야 되나요?"라는 것입니다. 흠, 컴퓨터나 소프트웨어가 갑자기 오늘부터 삐진 걸까요? ^^
아니 땐 굴뚝에 연기가 날 일이 없듯이, 어제와 오늘 사이에는 분명히 무슨 일이 있었던 것입니다. 문제는 그 일들에 대해 대수롭지 않게 생각하고 난 아무것도 손댄 것 없다고 주장해버린다는 것입니다.
예전 고객 사이트들에서 실제로 이러한 질문들이 있었습니다. 멀쩡하게 잘 돌아가던 프로그램이 있고 손댄 것도 아무것도 없는데 오늘 아침부터 안 된다는 것입니다. 어제와 오늘 사이에 다른 작업을 한 것이 없냐고 물어도 절대 없다고 시치미를 떼었기에 문제를 찾는데는 상당한 시간이 소요되었습니다. 결국 찾아낸 문제의 원인은 그 전날 퇴근하면서 설치한 XP 서비스팩 2 때문이었습니다.

3. 문제에 대해 충분히 설명을 하지 않는다.
"우리 사이트에서 갑자기 결제 오류가 나는데 어떻게 해야 되나요?"
실제로 달랑 이 한 줄을 메일로 보내고 해결해달라고 하시는 분이 계셨습니다. 저를 전지전능한 신으로 착각하시나 봅니다. -_-;;
문제가 있을 때는 문제가 발생하는 상황에 대해서 정확하게 기술해야 합니다. 또한 여러분은 일반 사용자가 아닌 개발자입니다. ‘갑자기 결제 오류가 나는데 해결해 달라’는 질문은 일반 사용자가 하는 질문이지, 개발자가 하는 질문이 아닙니다. 기본적으로 개발자는 발생하는 오류에 대한 정보를 수집하기 위해 최선을 다해야 합니다. 다음은 개발자가 수집해야 할 최소한의 정보라고 생각되는 것을 나열한 것입니다.

- 정확한 오류 메시지의 내용은 무엇인가?
- 오류가 발생되는 것으로 추정되는 소스 코드 위치는 어디인가?
- 이 오류를 발생시키기 위한 상황은 무엇인가? 오류를 재현하려면 어떻게 해야 하는가?
- 이 오류가 특정 컴퓨터/서버/네트워크 위치에서만 발생하는가?
- 정상적으로 작동하던 때와 오류가 발생하는 시점 사이에 변경된 것은 무엇인가?

4. 문제를 해결하기 위한 스스로의 노력
적어도 개발자라면 문제가 있거나 과제가 주어졌다면 그것을 해결하기 위해 자기 스스로 최대한 노력을 해야 합니다. 물론 남이 해결해 주는 게 시간 상으로는 더 단축이 될 수도 있겠지만, 적어도 자기가 직접 노력을 해보고 나서 해봐야 하지 않을까요?
상당수의 질문들은 도움말을 몇 분만 찾아보면 얻을 수 있는데다가, 인터넷이 발달한 요즘처럼 좋은 세상에는 네이버 지식인과 구글 검색만으로도 상당수의 답을 얻을 수 있습니다. 옛날에는 모든 해답이 MSDN에 다 있었지만, 요즘은 구글에 다 있더군요. 애인이랑 식사할 맛있는 스파게티 전문점을 검색하는데는 자신의 시간을 투자하면서 문제를 해결하기 위해 자료를 검색하는 건 왜 스스로 하지 않나 모르겠습니다. 구글에서 5분이면 찾을 수 있는 것을 물어볼 때, 나 귀찮으니깐 니가 대신 검색해서 내놔라 라는 말 밖에 되지 않습니다.
또한 많은 개발자들이 문제가 발생했을 때 디버깅조차 제대로 해보지 않는 경우가 많습니다(특히 웹 개발자들의 경우). 디버깅을 해보면서 조금만 추적해보면 금새 답이 나오는데, 전체 코드도 아닌 쪼가리 코드만을 주고 해답을 찾아내라고 던지시더군요. 그때마다 제 머리 속에서는 코드 텍스트를 머리 속에서 컴파일해가면서 실시간 디버깅(?)을 해야 합니다. 제발 디버깅 한번이라도 해보세요!

5. 적절한 사람에게 적합한 질문을 하라.
역시 제가 받은 황당한 질문 시리즈 중 하나는 비주얼 스튜디오 좀 주시거나 구할 수 있는(구매한다는 의미가 아니죠?) 곳을 알려 달라는 것입니다. 아, 그보다 더 황당한 것도 있습니다. 어떤 분은 비주얼 스튜디오 싸게 살 수 있는 방법이 없냐고 물어보시더구요. -_-;; 비주얼 스튜디오 설치하다가 CD가 에러가 난다는 분들도 계시고... 심지어 몇번째 장이 에러나는데 그거 하나만 구워서 보내줄 수 있냐고..
저는 MS 소프트웨어 판매 유통업에 종사하고 있지도 않고, MS 기술지원부서에 근무하고 있지도 않습니다. 제품은 소프트웨어 판매하는 곳에서 구매하시면 되고, 돈이 없으시면 알아서 능력껏 어둠의 경로에서 구하세요. 그리고 제품 설치에 대한 질문은 MS 기술지원부서에다 하셔야지 왜 저한테 하시는지.. (불법사용자라서 그럴까요? -_-;;)
어떤 분은 SQL 서버에서 데이터 마이닝을 하는 방법에 대해서 저한테 물어보시더구요. 안타깝게도 저는 DB 전문가가 아니랍니다. 답을 해드리고 싶어도 몰라서 못해드린답니다.

6. 멋도 모르면서 남들이 좋다고 하면 다 따라서 한다.
일단 개발자라고 하면 비주얼 스튜디오는 깔아야 한다고 생각하는 분들이 많더군요. 또 깔아도 항상 최상위 버전(2005의 경우 Team Suite)를 깔아두시더라고요.
개발 툴이나 기술이 일단 남들이 하는 거면 그것이 자기한테 적합한지, 자신이 하고자 하는 것에 맞는지 살펴보지도 않고 무조건 다 따라 하는 사람들이 있습니다. 정확한 목적의식없이 할려니 의욕도 안 생기고 헤매기 십상입니다.
사실 개발자라는 직업 자체가 그렇습니다. IT 열풍과 미친 정부 덕에 IT 인력을 양산해 냈지만, 개발자는 단순히 밥벌이를 위해서라면 참으로 힘들고 괴로운 직업이거든요. 먹고 사는 게 목적이라면 이것 말고 다른 방법을 얼른 찾아보시는 게 빠를 겁니다.

7. 문제가 생기면 남 탓부터 한다.
요즘 작업을 하다 보면 개발자 혼자 원맨쇼로 작업을 하는 게 아니라 여러 명이 공동 작업을 하는 경우가 많습니다. 그러다 보면 남이 짠 소스나 모듈을 가져다 붙여서 작업을 해야 하는 경우가 많은데, 문제가 생기면 정확한 문제의 원인이 무엇인지 찾아서 해결하는 게 아니라 이 문제가 나 때문에 발생한 게 아니라는 걸 찾아내는데 주력하는 사람들이 있습니다. 거참, 당신 잘못이 아니라 다른 사람 잘못이라는 걸로 판명 낸다고 해서 문제가 해결되나요? 일단 문제를 해결해놓고 범인이 누군지 찾는 건 나중에 해야죠.
저희 회사가 하는 일이 개발 프레임워크와 같은 공통 모듈을 만드는 작업을 많이 하다 보니 이러한 일을 부지기수로 겪습니다. 개발 프레임워크를 가져다 개발하면서 문제가 생기기만 하면 프레임워크 탓으로 돌리더군요.
모 사이트에서 작업하면서 O사의 컴포넌트를 가져다 사용한 적이 있었습니다. 저희 쪽에서는 그 컴포넌트를 좀 더 쓰기 쉽게 래핑해서 개발 프레임워크 내에 집어넣었습니다. 그런데 사용하다 보면서 갑자기 문제가 발생했습니다. 발생한 시점은 O사의 컴포넌트를 최신 버전으로 교체하고 난 이후였고, 열심히 디버깅해본 결과 최종적인 오류는 O사의 컴포넌트 내부에서 발생하는 것으로 판명되었습니다. 당장 이전 버전으로 롤백을 하면 문제는 없겠지만, 최신 버전에 포함되어 있는 기능이 필요하기에 당장 결정할 수는 없는 상황이었습니다. 그래서 문제를 O사에 문의했습니다. 유사한 문제가 발생한 적 있는지, 아니면 이를 수정할 수 있는 방안이 있는지. 워낙 급한 문제라서 바로 긴급 기술지원을 요청했고, O사 엔지니어가 왔더군요. 이 엔지니어는 오자마자 시스템이나 코드는 열어보지도 않고 무조건 절대 자기 회사 컴포넌트에서 문제가 발생할리가 없다고 주장하더군요. 일단 보기라도 하고 말하라고 했더니 잠시 살펴본 후에 이번에는 래핑하는 프레임워크 코드가 잘못 되었다고 주장하더군요. 프레임워크 안의 코드는 그들이 제공하는 예제 코드를 그대로 가져다 쓴 것이었습니다. O사 엔지니어는 자신들이 제공하는 예제를 돌리면 문제가 없으며 너희가 분명히 어딘가 코딩을 잘못 했을거다라고 하더군요. 그래서 아예 그럼 당신이 직접 그 예제를 가지고 돌려보라고 했습니다. 도대체 뭘 하는지 모르겠지만 몇 시간을 예제 가지고 끙끙대고 있더군요.
그러다 엔지니어가 온지 무려 6시간 만에 자기들 컴포넌트의 문제인 것 같다고 시인하더군요. 우리가 원하는 건 문제의 해결이지 누구 잘못인지를 따지는 것이 아닌데, 자기들 문제라고 시인하는데 무려 6시간이 소요되었습니다. 그래서 디버깅을 통해 빨리 문제를 분석하고 해결해줄 수 있냐고 했더니 한번 알아보겠답니다. 언제까지 해결하겠다는 것도 아니고 알아보겠다니, 정말 미치는 노릇이죠!
결국 이 사람을 믿느니 직접 찾아보는게 낫겠다고 싶어서 열심히 인터넷을 검색한 결과 유사한 문제를 여러 건 찾아냈고, 당장 해결되는 버전은 없지만 이를 피하기 위한 Workaround가 있다는 것을 알아냈습니다.
교통사고 부상자가 있을 때 부상자를 구호하는 게 우선이지 누가 가해자고 누가 피해자를 따지는 게 중요한 게 아닌 것과 똑같습니다.

8. 별거 아닌 습관 속에서 문제가 발생할 수도 있다.
A씨가 차에서 내리기 전에 실내등을 껐는지만 확인했다면 당장 시동이 걸리지 않는 문제는 없었을 겁니다(아, 물론 근본적인 원인일 수 있는 불법 튜닝은 빼고). 이와 같이 개발자의 사소한 습관 때문에 엄청난 문제가 야기될 수 있습니다.
예를 들어 저는 while 루프를 작성할 때는 가장 먼저 루프를 탈출하는 코드부터 작성합니다. 깜빡하고 빼먹어서 자칫 잘못하면 무한 루프가 되어 버릴 경우가 있기 때문이죠.
실제로 모 사이트에서 이런 일을 본 적이 있습니다. 개발자들이 중구난방으로 쓰던 코드를 통합 모듈로 작성해주고, 통합 모듈을 사용하도록 기존 코드를 수정하라고 했습니다. 수정하는데 시간은 좀 걸리지만 문제점을 격리시킬 수 있으니까요. 그런데 개발자 한 명 중에 유난히 이 작업을 귀찮아 하는 사람이 있었습니다. 공교롭게도 통합 모듈을 적용해서 사이트를 돌렸는데, 갑자기 웹 서버의 CPU가 100%을 치면서 사이트가 죽었다가 살아나는 현상이 생기더군요. 불평이 많던 개발자가 바로 통합 모듈 때문이라면서 온갖 비난을 쏟아내더군요. 한참 문제를 찾아본 결과 특정 페이지에서 특정 조건 시에만 문제가 발생한다는 것을 찾아냈습니다. 열심히 코드를 디버깅 해본 결과, while 루프에 탈출문이 없어서 무한 루프를 돌고 있더군요. 어처구니 없게도 이 코드를 작성한 개발자는 불만이 가장 많고 문제가 생기자마자 목청껏 떠들던 바로 그 개발자였습니다. 참 민망했겠죠? ^^

9. 문제는 예방하는 것이 최선이지만, 소를 잃더라도 외양간을 고치자.
어쩌면 A씨가 긴급출동서비스만 넣어두었다면 좀 더 시간과 비용을 절약할 수 있었을 겁니다. 또한 점프 케이블을 준비해두고 점핑하는 방법을 알았다면 좀 더 나았겠죠.
사전에 문제를 예측해서 예방하고, 문제가 발생했을 때 이를 최대한 빨리 해결하는 방법을 수립해두는 것은 중요합니다. 또한 문제 해결 방법을 알고 나면 다음에 동일한(혹은 유사한) 문제가 발생했을 때 스스로 대처할 수 있도록 숙달해두는 것 역시 중요합니다.
저는 한 번 물어본 질문을 다시 물어보는 사람을 참 싫어합니다.

10. 그래도 가장 중요한 것은 사람으로서의 예의이다.
위의 사례에서 보면 A씨는 자기의 문제를 해결하는데 급급해서 상대방의 입장을 전혀 고려해보지 않는 무례한 행동을 많이 합니다. B씨 입장에서는 앞으로 A씨를 대하는 것이 절대 예전처럼은 되지 않을 겁니다.
질문 메일을 받다 보면 이처럼 다짜고짜 용건만 말하고 빨리 답을 달라고 강요하는 사람들이 있습니다. 이런 경우, 참 답을 주기 싫지요. 답을 줘도 고맙다는 얘기를 듣는 건 하늘에 별 따기입니다.
고객 센터에 질문하는 것도 아니고, 누군가에 도움을 요청할 때는 자신이 누구인지를 밝히면서 양해를 구하고 이러한 상황인데 도와주시면 감사하겠다고 정중하게 말하는 것이 최소한의 예의가 아닐까 합니다. 이런 메일이라면 최소한 도와주지 못하더라도 답장은 쓰게 되더라구요.
예전에 어떤 분은 제가 7년 전에 어딘가에 올려둔 소스를 보고 나서, "님이 올린 소스 잘 봤는데, 내가 이런 이런 기능이 필요한데 추가해서 빨리 보내주세요."라고 딱 한 줄을 보내오셨습니다. 제가 답을 했을까요? ^^
마찬가지로 맞춤법, 띄어쓰기도 엉망이고, 어법에도 맞지 않는 글을 보내오는 경우도 그렇습니다.