나는 올해 뛰어난 개발자였다

나는 올해 뛰어난 개발자였다. 영혼의 일부를 깍아서 버그들을 고치는데 사용했으며, 주어진 개발일을 완수하는데 최선을 다했고 이루었다고 생각한다. 그 동안의 수정된 이슈 개수들을 확인해봐도 알 수 있을 것이다. 야근을 해서라도 책임간 있게 일을 훌륭히 완수하였고 긍정적인 결과를 만들었다고 생각한다.

이것은 나의 개발자 생활 중 거만할 때 가지고 있었던 생각이고 평가를 하게 되는 상사와의 면담에서 주장했던 말이다. 실제로 일을 꽤 많이 해낼 수 있는 시점이었다. 농담이 조금 섞여있긴 했지만 스스로 야근을 해서라도 버그 수정 및 개발을 했었고 회사에 기여를 하고 있다는 느낌을 받고 있었다. 특히 그 당시 이슈트래커 해결된 이슈의 할당자 랭킹을 보면 상위 3위안에 내 아이디가 있었고, 지금도 상위권 어딘가에는 위치하고 있지 않을까 생각한다. 

생각해보면 잘하려고 노력하고 결과를 보여준 것도 많지만 단순히 스스로 할 수 있는 일에 대해서 집착하고 오버해서 일하고 있었다. 이슈 개수를 줄이는 목적으로 고용된 개발자가 아닌데 말이다. 돌이켜보면 오히려 번아웃으로 인하여 업무 능률이 떨어질 가능성도 있었다.

최근 이러한 생각을 다시 정리하게된 요인이 있었다. 작년에 업적 및 개발자 스킬에 대한 평가를 스스로 점수로 주게 하였는데 특정 그룹에서 내가 생각보다 많이 높은 점수를 스스로에게 주고 있었다. 그 사람들이 열심히 일하고 노력한 점은 간접적으로 알고 있었지만 문제는 굉장히 높은 점수를 받을만한 일을 하지 않았다는 것이다. 가령 다음과 같은 일이다.

• 회사에 돈을 벌어줄만한 매력적인 기능이나 제품을 제안한다. 특히 팀에서 필요한 개발이 아닌 제품에(다른 말로는 고객이라 부를 수 있는) 필요한 기능인지를 식별하고 개발한다.
• 비용적인 문제를 최소화할 수 있는 개선점을 제안한다. 이를 통해서 가치있는 일을 할 수 있는 시간을 벌 수 있다.
• 조직의 정해지지 않은 일에 대해서 누가 시키지 않아도 헌신적으로 나서서 처리하고 공유한다.
• 위와 같은 일들을 책임감을 가지고 마지막까지 좋은 결과를 만들어내려고 노력한다.

주어진 일을 해내는 것은 너무나도 중요하지만 이슈를 해결하는 행위에서 개수가 중요한게 아니라 어떤 좋은 영향을 끼쳤는지가 중요하다. 예를 들어 버그를 수정하는데 그 버그 수정에서 또다른 버그가 나왔다. 이런 패턴으로 그 사람은 다른 사람보다 2배의 버그 개수를 고쳤다고 가정해보자. 그 사람은 많은 이슈를 해결했으니 뛰어난 사람인가? 버그 100개를 수정하는것 보다, 버그 30개만 수정하고 버그가 자주 나오는 문제점등을 분석해서 재발을 방지하려는 노력이 어느정도 발전적인 방향이 아닐까?

경계해야할 것, 한가지 더 있다. 제품에 크리티컬한 문제를 해결한 사람에게 항상 좋은 평가로 이어지면 안된다는 것이다. 그 문제를 누가 만들었으며, 예방할 수 있는 시간은 없었는지 그리고 이 문제점을 해결하면서 본인에게 주어진 다른 과제까지도 해결하거나 조율하려는 노력은 있었는지 등이다.

예전에 나는 개인 범위의 업무 결과에만 초점을 맞추지 않았나 싶다.  정말 잘했다라고 말한다면 헌신도 필요하고 넓게 봐야할 필요성이 있다고 생각한다. 중요한 결과를 만든 사람이 좋은 평가를 받아야 한다. 흔히 일을 열심히 하는 것보다 잘하는 게 중요하다라고 말하는 것처럼 말이다. 주어진 일 그 이상으로 잘한 사람은 어떤 평가를 받아야 할까? 다 같이 만점을 받으면 될까?

정리하면, 

1. 개인에게 주어진 일을 해내는 것은 중요하다.
2. 제품이나 회사와 같은 큰 범위로 봤을 때, 일을 잘했는가가 더 중요하다.

한편으로는 평가자들도 자주 피드백을 줘야 할 필요성을 느꼈다. 민감한 사항이될지라도 주기적으로 만나서 업적과 평가에 대한 이야기를 주고 받아야 연말에 피평가자 입장에서도 반전을 느끼지 않을테니 말이다. 주기적인 면담과 피드백이 독이 되는 경우를 많이 보지 못한거 같다. 

난 올해 뛰어난 개발자였는가? 나를 통해서 제품이 그리고 회사가 무엇을 얻게 되었는지를 고민해보기 바란다. 잘 모르겠다면 상사에게 찾아가 피드백을 요청하자.