-------------------------------------------------------------------------------- "열심히"씨와 "훌륭한"씨는 각각 "엄청난소프트웨어회사"와 "허벌난소프트웨어회사"의 두 직원이다. 우연치 않게 두 회사에 정확히 똑같은 내용의 주문이 들어왔다. "열나어려운문제" 해결을 위한 프로그램을 작성해 달라는 것이었다.
열심히씨는 처음 예상 소요 시간인 3개월 동안 정말 열심히 일했다. 하지만 일을 하면서 예상 외의 장애를 직면했고, 밤샘 작업까지 해가면서 3개월의 마지막 날 매니져에게 이런 말을 할 수 있었다. "정말 열나게 프로그램을 짰슴다. 밤샘도 하고요. 제가 지금까지 작성한 프로그램은 2000줄입니다. 그런데, 새로운 문제가 기술적으로 불가피하게 발생했습니다. 복잡한 버그(프로그램의 오류)도 몇 가지 해결해야 하고요. 한 달 가량이 더 필요합니다." 그러고 한달 후 열심히씨는 몇 개의 버그와 더불어 나름대로 작동하는 프로그램을 매니져와 고객에게 자랑스럽게 보여줄 수 있었다. 벌겋게 충혈된 눈과 미쳐 깎지 못한 수염, 무지무지 어렵고 복잡해 보이는 2500여 줄의 프로그램과 함께. "예상보다 훨씬 더 복잡한 문제였군요. 정말 수고하셨습니다."라는 칭찬을 들으면서.
훌륭한씨는 매니져가 "의무적으로" 잡아놓은 예상 소요 시간 3개월의 첫 2달 반을 빈둥거리며 지냈다. 매니져는 훌륭한씨가 월말이 되어서 "정말 죄송해요. 아직 한 줄도 못짰어요. 너무 어려워요. 좀 봐주세요."라고 처량하게 자비를 구할 날을 손꼽아 기다렸다. 웬걸, 마지막 날 훌륭한씨는 예의 "너무도 태연스러운" 모습으로 나타났다. 150여 줄의 프로그램과 함께. 그 프로그램은 멋지게 "열나어려운문제"를 해결했다. 하지만, 매니져가 그 코드를 들여다 보자, 한마디로 "너무도 쉬웠다." 초등학생도 생각해 낼 정도였다. 매니져와 고객은 이름을 "열나쉬운문제"로 바꾸는 데에 전적으로 동의한다. 훌륭한씨는 "이렇게 간단한 문제를 3개월 씩이나 걸려서 풀었습니까? 왜 이렇게 성실하지 못하죠?"라는 비난을 들어야 했다.
둘 중에 누가 승진을 했을까?
열심히씨는 승진하고, 급여인상을 받았다. 훌륭한씨는 급여삭감을 직면하고는 퇴사해 버렸다.
훌륭한 프로그래머는 가난하다. 훌륭한프로그래머의딜레마인 것이다.
--김창준 [이 이야기는 SE계의 잘 알려지지 않은 명작 Wicked Problems, Righteous Solutions 에 나온(원래는 CACM 기사였던) 일화를 직접 각색한 것이다]
위나라의 임금이 편작에게 묻는다. "그대 삼형제 가운데 누가 제일 잘 병을 치료하는가?" 큰 형님의 의술이 가장 훌륭하고 다음은 둘째 형님이며 저의 의술이 가장 비천합니다. 임금이 그 이유를 묻자 편작이 대답한 내용은 이러했다. '큰 형님은 상대방이 아픔을 느끼지 전에 얼굴빛을 보고 그에게 장차 병이 있을 것임을 안다. 그리하여 그가 병이 생기기도 전에 원인을 제거하여 준다. 그러므로 상대는 아파보지도 않은 상태에서 치료를 받게 되고 따라서 그간 자기의 고통을 제거해 주었다는 사실을 알지 못한다. 큰 형이 명의로 소문나지 않은 이유는 여기에 있다. 둘째는 상대방이 병세가 미미한 상태에서 그의 병을 알고 치료를 해준다. 그러므로 이 경우의 환자도 둘째형이 자신의 큰 병을 낫게 해주었다고 생각하지 않는다. 그러나 나는 병이 커지고 환자가 고통속에 신음할 때가 되어서야 비로소 병을 알아 보았다. 환자의 병이 심하므로 그의 맥을 짚어야 했으며 진기한 약을 먹이고 살을 도려내는 수술도 했다. 그런데 사람들은 나의 그러한 행위를 보고서야 비로소 내가 자신의 병을 고쳐주었다고 믿게 되었다. 내가 명의로 소문이 나게 된 이유는 여기에 있다.'
-------------------------------------------------------------------------------- 훌륭한 프로그래머는 어려운 문제를 "터무니 없을 정도로 간단한 문제"(see also RidiculousSimplicity)로 풀어내는 재주가 있다. 남들이 보기에는 그것이 너무도 당연한 해결법으로 보인다. 하지만 그들은 쉽게 생각해 내지 못한다. 그러고는 훌륭한 프로그래머를 우습게 본다.
중간치기나 하치기 프로그래머는 어려운 문제를 어렵게 혹은 더욱 어렵게 풀어내는 재주가 있다. 남들이 보기에는 그것이 너무도 기발한 해결법으로 보인다. 역시 그들은 쉽게 생각해 내지 못한다. 그러고는 중간치기 하치기 프로그래머를 대단하게 본다.
see also 노자 도덕경
-------------------------------------------------------------------------------- 과거 IBM사에서는 프로그램의 줄 수에 따라 급여를 계산했었다. (사실 지금도 이런 회사가 상당수 있다) 그런데 프로그램 줄 수가 늘어날 수록 숨겨진 버그 수와 유지관리에 드는 비용은 기하 급수적으로 늘어나게 된다. 이 문제를 해결하기 위해 프로그램 줄 수는 더 늘어나게 되고, 덕분에 프로그래머는 돈을 더 벌게 된다.
-------------------------------------------------------------------------------- 남들이 보기 쉽게 짤 수 도 있으나 어렵게 짜는 수를 일부러 부릴 때도 있는 것같네요. 위에 "훌륭한" 프로그래머가 이 세상에서 살아남기 위해선 "열심히" 프로그래머인 것처럼 해야하는 것이 아닐까요, 군발이 시절 3시간 정도 할 수 있는 일을 언제나 하루 정도 걸려서 끝마쳤죠. 만약에 그 일을 3시간에 정말 끝마쳐 버린다면 다음 프로젝트때는 그 일에 해당하는 시간을 2시간 정도를 주는 것으로 바뀌어져 버리니까요. 이건 곧 그사람의 직업관?에도 연관 되는 문제가 아닐련지. --rururara
-------------------------------------------------------------------------------- 훌륭한 프로그래머는 "터무니 없을 정도로 간단한 문제"로 풀어내는 재주가 있을 뿐더러, "터무니 없을 정도의 어려운 문제로 보이는 쉬운 문제"를 잘 섞어서 좋은 아이디어를 제시하는 재주가 있다. 당연히 중간치기, 하치기 프로그래머 모임에 있어서는 훌륭한 프로그래머가 해결안을 제시하기도 전에 간단히 배제가 되고 만다. 이유는?? 중간치기, 하치기 프로그래머가 바라보는 시선이 이미 한정되어 있기 때문에, 그 범위 밖에서 문제를 해결한다거나, 뿌리를 잘라내는 얘기는 당연히 범위 밖의 바보같은 얘기이기 때문이다.^^
예로, 입술에 묻은 밥알을 떼기 위해서는 일반적으로 인간에게 있어 미세한 행동을 할 수 있는 손, 그 중에서도 엄지와 검지손가락이 필요하다는 전제하에서 이루어지는 중간치기 하치기 프로그래머들의 모임이 있다.
훌륭한 프로그래머의 "입술에 묻은 밥알을 혀로 떼어 먹으면 되잖아요"란 해답은 당연히 먹힐리 없다. "어깨 반경을 좁히기 위헤 손을 직선으로 올려 팔꿈치로 90도를 꺾으면 최단거리의 궤적이 나오고, 이때 밥알의 접착성을 이용해서, 검지로만 문제를 해결해야 하는데, 접착성은 상온에서만 유지되고 밥알은 굳기 이전의 14시간 내에, 습도 70%이상에서만 해결할 수 있는 문제이고, 그 이외의 문제는 나중에 해결하자"란 답이 그 회의에서의 정답이기 때문이다.
훌륭한 프로그래머는 훌륭한 중간관리자가없이는 훌륭해질 수 없다.--cavin
-------------------------------------------------------------------------------- 훌륭한 프로그래머의 조건에는 자신이 한 일이 얼마나 중요하고 가치있는 일인지 설득할 수 있는 능력도 포함됩니다. 그가 한 일이 어떤 일인지 아무도 알아차리지 못한다면, 그는 대수롭지 않은 일을 해낸 것에 불과합니다.
관리자가 바보가 아니라면, 쉬운 일을 복잡하게 풀어내는 능력을 더 평가할 리 없습니다. 관리자, 평가자의 문제이죠. 보통 회사에서는 source code를 '갑'에게 보여주지 않습니다. source code를 길게 짜는 능력은 간혹 필요할 때만 쓰면 되는 능력이죠. 일을 간단하게 해결했어도 '갑'에게는 엄청난 연구개발 끝에 성공했다고 구라를 쳐야만 합니다.
보통 회사에서는 일이 끝나면 다음 일을 넘겨주기 때문에, 복잡한 일을 간단하고 쉽게 풀어내는 사람은 훨씬 더 많은 일을 하게 됩니다. 영업하는 사람이 바보가 아닌 다음에야 적정한 가격에 적정 규모 프로젝트를 수주하게 되고, 결국 일을 간단하고 쉽게 풀어내는 사람은 더욱 많은 매출을 올리는 기여를 하게 되고, 급여가 올라가게 됩니다.
회사 내부적으로도 프로젝트의 업무를 분담할 때 미리 회의를 통해 업무량을 가늠해보고 그에 맞추어 일정을 정하고 인력을 배정합니다. 예상보다 일을 빨리 끝내면 당연히 더 높은 평가를 받게 됩니다.
회사의 관리가 그렇게 비합리적이고 어설프지는 않습니다. 훌륭한 프로그래머는 자신만 그렇게 생각하는 것인지, 남들도 그렇게 생각해주는 것인지 고민해 보고, 남들이 왜 그렇게 생각해주지 않는지 분석해 볼 필요가 있습니다. 자신만의 착각일수도 있고, 남들에게 제대로 표현하지 못한 문제일 수도 있습니다. 어쨌거나 자신이 훌륭한 프로그래머라고 생각되는데 남들은 그것을 인정해주지 않는다면, 그것은 자신에게 문제가 있는 것입니다.
-------------------------------------------------------------------------------- 글을 읽다보니 프로그래머의 평가에 대한 부분도 고려해볼 문제네요~ SI나 관리, 운영에 있다보면 그룹웨어에 매일매일 올라가는 내용을 체크해보고, 분기별로 평가를 팀장-중간관리직-최고관리직이 한다던가라는 식이면 처리한 일의 분량과 가치별 적절히 판단할 수도 있겠다 싶지만, 이는 어디까지나 훌륭한 프로그래머가 일의 분량이 앞설 수 있는 상황이거나, 수행해 낸 결과물의 가치를 팀장을 포함한 그 윗선에서도 명확히 인식할 수 있을 때의 문제라고 생각되네요~
특정 프로젝트 수행에 대한 가치를 판단할 때에 팀장이나 혹은 그 위의 관리직 보기에 어려운 문제를 적은 시간내에 잘 해결했다라고 생각하는 것과, 쉬운문제를 그렇게 오랜시간에 빙글빙글 놀면서 풀었다라고 판단 하는 것은 어디까지나 일의 수행능력과 일의 처리능력의 문제가 아닌 평가 및 판단하는 사람의 입장에서 어떻게 받아들이는가의 문제가 아닐까요?
시간이 차차 지나면서 대부분의 훌륭한 프로그래머는 훌륭하다는 것을 주위 사람이 인식하기도 하지만, 그렇지 않은 경우도 위와같은 이유로 왕왕 있다는 잡담이랍니다. 특히나 연구 및 제품개발과 같이 분량의 차이보다 가치판단을 요하는 경우엔 말이죠~ 개인적인 생각입니다^^;
tag는 게시물의 성격을 나타내는 키워드를 입력하는 공간입니다.
tag는 로그인 후 사용하실 수 있습니다.
