평가를 어떻게 해야 할까?

개발자 여러분 평가철이 다가왔습니다. 이미 평가를 끝낸 회사도 있을 것이고 한창 평가를 하고 있는 회사도 있을 것입니다.

평가가 항상 만족스럽고 공정하다고 생각하나요? 그렇지 않은 분들이 더 많을 겁니다.

평가 시에 자주 보는 것은 개발자들 순위 매기기 입니다. 흔히 "나래비" 세운다고 하죠. (일본말에서 유래)

대부분의 개발자들은 이런 순위매기기의 결과가 공정하지 않다고 생각하고 팀워크를 깨기 일쑤입니다.

A평가를 받은 개발자와 D평가를 받은 개발자의 차이가 크지 않은 경우가 많습니다.  심지어는 더 잘한 개발자가 더 낮은 평가를 받는 경우가 흔합니다. 그런데 평가시스템에서 A는 10%, B는 50%, C는 30%, D는 30%를 할당 받아서 무조건 나눠야 하는 경우가 있습니다. 개발자가 5명밖에 안된다면 나누기도 어렵습니다. 기계적인 평가시스템 적용이 1년 동안 고생한 개발자들을 한순간에 힘을 잃게 할 수도 있다.

물론 D 평가를 받아야 할 개발자도 있을 수 있으나 열심히 일했고 성과도 꽤 잘 냈음에도 불구하고 D평가를 받는 개발자들도 있습니다. 그렇다고 평가를 관리자 마음대로 하라고 할 수도 없습니다. 그럼 더 엉망이 될 것입니다. 

평가는 불공평할 수밖에 없지만 불공평하다는 의식이 너무 팽배해지면 개발자들이 진정으로 열심히 하려고 하지 않을 것입니다. 평가를 잘 받기 위한 편법이 난무할 수 있습니다.

이렇게 평가가 공정하지 못하다는 인식은 평가의 기준이 애매하거나 없기 때문인 경우가 많습니다. 팀장 또는 관리자가 맘에 내키는 대로 평가를 하면 무슨 기준으로 평가를 했는지 알 수 없는 개발자들은 평가 결과를 납득하기가 어렵습니다.

그렇다고 너무 구체적인 평가 기준(KPI)도 문제가 됩니다. 몇가지 예를 보죠.

• 개발 일정을 맞추면 평가를 잘 주겠다. 
  코드는 엉망으로 만들어서 유지보수를 어렵게 만들지만 일단 일정은 지킵니다. 하지만 나중에 유지보수 개발자들이 엄청난 고생을 하게 됩니다.
  
• 버그를 많이 찾으면 평가를 잘 주겠다. 
  테스터는 스펙, 설계단계의 검토를 소홀히 하여 버그가 더 많이 발생하도록 합니다. 전체적으로 프로젝트 기간이 늘어나고 비용도 증가합니다.
  
• 버그를 적게 만들면 평가를 잘 주겠다.
  개발자는 최대한 일을 적게 하려고 하게 됩니다. 약간의 리스크가 있는 시도도 두려워하게 되며 새로운 기술도 연구하지 않게 됩니다.

이쯤 되면 개발자는 공장의 생산직 직원처럼 평가가 불가능하다는 것을 눈치채셨을 겁니다. 개발자들은 원래 돈에 그렇게 좌지우지 되지 않는데 공정하지 않은 평가를 몇번 받게 되면 기분이 나빠서라도 평가를 잘 받기 위해서 편법을 동원할 수 있게 됩니다.

흔히 하는 실수 중의 하나가 평가가 이렇게 부정확한데도 불구하고 평가에 의해서 A와 D 등급의 개발자를 엄청난 연봉 인상의 차이를 두면 개발자들이 더욱 열심히 일할 것이라고 생각하는 것입니다. 이는 착각이며 자칫하면 평가만 잘 받기 위한 편법이 난무하게 되며 평가의 결과는 불공정하다는 불만만 팽배하게 됩니다.

공정한 평가는 필요하지만 100% 공정하기는 불가능합니다. 그렇다고 평가를 하지 않을 수 없습니다. 평가는 잘못 휘두르면 안 한 만도 못하게 되고 그렇다고 안 할 수도 없는 균형잡기 어려운 줄타기입니다. 그리고 다음과 같은 기준은 세울 수 있습니다.

• 평가 기준은 회사의 비전과 일치해야 한다.
• 평가 기준은 평가자나 피평가자 모두가 납득해야 한다.
• 평가 기준은 연초에 미리 정해야 한다. 
• 평가 기준은 객관적이어야 한다. 즉 평가 가능해야 한다.
• 평가 결과를 너무 믿지 말아야 한다. 적당히 활용해야 한다.

평가의 목적은 결과를 보고 상과 벌을 주기 위한 것이 아닙니다. 평가기준이 회사의 비전을 절묘하게 잘 반영하여 하나의 목표를 가지고 매진할 수 있도록 하기 위한 것입니다. 잘 만들어진 평가 기준은 평가 결과를 가지고 벌을 주지 않아도 이미 목표를 달성한 것입니다.

A를 받은 개발자는 기분이 좋고 C나 D를 받아도 별로 기분이 나쁘지 않은 그런 평가 어디 없을까요?