어떻게 프로그래머의 고과를 매길 것인가?

  조엘 온 소프트웨어 (Joel on software) 에서도 여러번 다룬 이야기지만, 막상 평가를 당하는 대상이 되면 이건 전혀 다른 이야기다. 특히나 우리회사 같이 큰 회사에서 많은 수의 사원들을 대상으로 랜덤이 돌아가고 있다고 느껴진다면 이건 정말 큰 문제가 된다. 프로그래머들은 의욕을 잃고, 능력이 부족한 동료 때문에 자기에게 추가 업무가 전가되는 것에 짜증을 내기 시작한다. 불투명한 고과가 팀웍을 깬다. 그건 곳 그 고과권자가 무능함을 뜻한다.

  조엘이 자신의 글에서 실증적인 예를 들었듯이, 프로그래머를 평가하는 객관적인 방법은 없다. 어떠한 잣대를 들이대더라도 프로그래머는 빠져나갈 구멍을 만들 것이며, 어떠한 잣대도 프로그래머의 창의성을 저해할 것이다. 평가를 받는 프로그래머의 목표는 더이상 가장 뛰어난 프로그램을 만드는 것이 아니기 때문이다. 그의 목표는 당연히 고과 기준에 맞는 일을 하는 것이 될 것이다. 심지어 그것이 의도적인 버그를 숨기는 일이 될지라도 말이다.

  특히나, 우리회사 같은 곳에서는 문제가 더 심각하다. 대한민국 100대 기업 안에든다는 회사가 나 입사할 때만 해도 조엘 점수가 12점 만점에 8.5점을(매우 후하게 준 것이다) 겨우 넘기는 정도였다. 조엘은 자신의 책에서 11점 미만은 가서는 안된다고 단언을 했지만, 우리회사는 입사 경쟁률이 꽤 높았다. 지금은 많이 개선되어서 11점 정도 되었다. 하지만 아직도 가장 Critical한 문제가 남아있다. 바로 채용의 문제인데, 프로그래머를 채용하면서 프로그래밍 능력을 묻지 않는다. 하하...

  프로그래머의 고과를 객관적으로 매길 수 없다면, 처음부터 A급 프로그래머를 뽑는 수 밖에 없다. B급 프로그래머의 10배 일을 하는 A급 프로그래머들로 팀을 꾸리고 모두에게 A고과를 줘라. 그리고 그들이 마음대로 뛰어놀 수 있도록 풀어놔라. 맨먼스 미신에서 말하는 것 처럼, 300명의 프로그래머와 25명의 관리자 보다 뛰어난 25명이 그냥 일을 하는 편이 더 좋다. 내가 입사하기 전에도 제품은 출시가 되었고, 인원이 두 배가된 지금도 버그는 엄청나게 숨어있다. 결국, 인원이 늘어났지만 나아진 것은 별로 없다는 뜻이다. 아니, 문제는 더 늘어나고 있는 걸지도 모른다. 제대로된 프로그래머를 채용하지 않는다면 인원이 늘어날 수록 문제도 따라 늘어날 것이다. 제발 인사쪽에서 제조업 마인드를 버렸으면 좋겠다.