배신의 계절이 왔다

feat. 업적평가, 고과 시즌

이맘때는 송년회, 신년회도 있지만, 고과때문에 속상해서 술을 많이 먹는 사람들이 많다. 다 그런것은 아니겠지만 믿고 있던 상사의 말과 행동, 그리고 비공식 약속 같은 것들이 와장창 무너지는 배신의 계절이다. 인사고과가 뭐라고 당장 회사를 그만두거나 조직이 변경되는 것도 아닌데, 활력이 없고 일이 손에 안잡히고 마음이 뒤숭숭하다. 기대만큼 받은 사람은 별일 없겠지만 적당히 받은 사람은 적당히 받은 사람대로, 못 받은 사람은 못 받은대로 집단으로 심란한 분위기가 사무실에 깔린다.

사실 고과가 아니라도 누군가에게 평가 받는 다는 것은 언제나 큰 스트레스이고, 시험이든 발표든 어릴때부터 꾸준히 우리는 이 스트레스를 받아왔다. 이제는 익숙하게 다룰 수 있어야 할 법도 한데 여전히 마음이 힘든 이유는 무얼까.

신뢰의 문제를 넘어서

가장 마음이 아픈것은 전혀 예상치 못한 결과가 갑작스럽게 찾아와서 너무나 당당하게 결과를 수용하기를 바라는 것이고, 억울하고 답답한 그 상황 속에서 별다른 저항 조차 할 수 없이 무기력하게 결과에 무릎을 꿇어야 하는 상황이다.

올 해 고과를 약속하며 온 갖 궂은 일을 다 시켰던 부장이 갑자기 사라진다. 조직 개편으로 자리를 옮기거나, 이직을 하거나 심지어 이민을 가기도 한다. 새로온 부장에게 성과와 실적, 그리고 구두 약속에 대해서까지도 강하게 설명해보지만, 자신은 모르는 일이며, 심지어 고과는 전임 부장의 평가에 따라서 결정된 것이라고 빨뺌을 한다. 그렇다. 완전 새됐다.

부장이 멀쩡히 자리를 지키고도 배신을 때리는 경우도 있다. 그나마 이 경우에는 이의를 제기 해 볼 수 있지만, 충분히 객관적인 데이터를 많이 확보된 경우가 아니라면 결과를 뒤집기 힘들다. 부장이 구두로 고과를 빌미로 맡겼던, 그리고 기꺼이 묵묵히 잘 해냈던 많은 일들 중에는 데이터로 증명할 수 없는 헌신과 노력이 많은 경우가 허다하다. 공통 업무에 헌신한 내용이나 사람들이 기피하는 작업을 도맡아서 했다고 한들 그 수치를 어떻게 객관적으로 제시할 수 있겠냔 말이다.

이 계절에 반복되는 속상함은 어쩌면 우리가 객관적인 평가의 과정을 신뢰의 문제로 옮겨버렸기 때문일 수 있다.

배신 상처는 서로에게 깊게 남아서 둘 중 하나가 조직을 이탈하게 만든다. 이탈하지 못하고 잔류하는 경우도 팀웍이나 개인적인 성장에 큰 장애물이 된다. 역설적이지만 신뢰를 지키기 위해서는 오히려 신뢰를 넘어서는 객관적인 데이터를 바탕으로 의사소통이 필요하다. 평가의 계절이 왔을 때, 평가자에게 막연한 믿음을 갖을 것이 아니라 연초부터 꾸준히 포인트를 모으고 주기적으로 본인의 포인트를 확인하는 과정이 필요한 것이다. 이것이 수시 평가의 역할이고, 꼭 수시 평가가 아니라도 반드시 소통을 통해서 눈높이를 맞춰야 한다.

여기서 주의해야 할 부분이 있는데, 기계가 아닌 평가자에게 평가를 맡기는 이유는 여전히 정성적인 평가가 중요하기 때문이라는 점이다. SW 개발자라면 생성한 코드의 품질이나 뛰어나 문제 해결 능력이 중요한 지표가 될 수 있다. 그러므로 가능하면 자신의 아름다운 코드와 업적을 적극적으로 상사에게 어필하라. 만약 코드를 보지않고 프로그래머를 평가할 수 밖에 없는 상황이라면 동료들의 간접평가를 통해서라도 자신의 정성적인 평가에 신경을 써야한다. 좋은 품질의 코드, 중요한 작업을 훌륭하게 해내는 개발자라는 평가가 중요하다.

좋은 회사라면, 위에서 언급한 내용들이 잘 갖춰져 있는 곳일 것이다. 평가자가 고과를 언급하면서 자신의 영향력을 행사하고 작업 지시를 내려서는 안된다. 피평가자는 주기적으로 피드백을 받으면서 본인의 실적과 성장, 프로젝트 기여도에 대해서 확인 할 수 있어야 한다. 그리고 평가자는 정성적으로 피평가자는 능력을 평가할 수 있어야 한다. 정성적 평가는 언제나 중요하다. 때때로 히어로 개발자가 당장 실적이 부족해도 좋은 평가를 받을 수 있는 이유이기도 하다. 히어로 개발자는 당장의 실적도 중요하지만 꼭 필요한 한방을 위해서도 관리해야할 대상이기 때문이다.

최악의 평가자는 부서원들을 고과로 겁박하고, 피평가자 피드백은 등한시 한 채 자신의 평가자 눈치만 보며, 코드 한 줄 이해하지 못 한 채 프로그래머를 평가하는 사람이다. 가까이에 있다면 얼른 탈출하라!

평가란 상대적인 것

평가는 상대적일 수 밖에 없다. 일반적으로 상대 평가는 동료들과 비교해서 상대적인것을 의미하지만, 그 보다 자신의 몫, 즉 기대값에도 상대적인 것이 바람직하다. 원래 해야할 일을 했다면 평고과를 받을 것이고, 기대 이상의 성과를 냈다면 그에 걸맞는 평가를 받아야 하는 것이 정상이다. 그게 잘 안되니까 속상한 사람이 많은 것인데, 애초에 내가 해야할 분량, 나의 몫에 대한 정의가 모호한 경우가 대부분이다.

'몇 일이면 돼?' 개발자가 가장 많이 듣지만 답이 의미가 있나 싶을 만큼 맞추기 어려운 질문이다. 스토리 포인트 산출에 참여한 개발자라면 누구나 공감할 것이다. Estimation은 매우 어렵다. 마찮가지로 SW 개발자에게 요구되는 기대치, 한 해동안 해내야 할 업무량에 대한 구체적인 정의도 불분명하다. 보험왕처럼 명확한 기준이 있는게 아니다.

Estimation이 어렵지만 그럼에도 불구하고 피할 수가 없는 것처럼 내가 해내야 할, 나의 몫에 대해서도 추정이 필요하다. 그리고 그 내용을 고과권자와 공유하고, 서로간에 합의가 필요하다. 수시 평가를 통해서 신뢰를 넘어서는 의사소통이 필요하다고 했는데 이때 필요한 것이 기대치에 대한 정의와 지금까지 결과에 대한 평가다. 나한테 기대하는 것이 무엇인지, 내가 지금 잘하고 있는 지 당당하게 이야기 하자.

고과권자한테 나한테 기대하는 것이 무엇인지 직접적으로 묻는 것이 부담스럽고 망설여지는 일일 수 있다. 굳이 그런 말을 일일이 해야되나, 그냥 주어진 업무 열심히 잘 해내면 되겠지라는 생각으로 이야기하지 않는 경우가 많다. 하지만 하기 싫은 일도 해야 한다면 기꺼이 해야한다. 리더는 일괄적으로 개인의 기대값만큼의 업무를 주는 것이 아니라 팀이나 프로젝트 상황 등의 종합적인 정보를 모두 고려해서 업무를 배정하기 때문에 주어진 업무를 다 잘해도 기대값을 충족하지 못할 수 있다는 것을 명심하자.

평가는 기준에 맞춰 상대적인 것이며, 모호한 기준을 최대한 명확하게 하려고 노력하지 않으면 결국 배신의 씨앗을 심게 되는 것이다.

한 해보다 길게 스스로를 평가하자

아무리 잘해도, 소통을 많이해도 배신감이 들고 억울하고, 부당하다는 생각이 드는 것이 고과 평가인것 같다. 프로세스나 평가자가 완벽할 수도 없는데, 온갖 노이즈나 예외 처리가 섞이게 되니 더더욱 그런것 같다. 그래서 이맘때면 날도 추워지는데 마음도 허해지곤 한다.

한해를 마무리하는 추수의 계절이 끝나며 크리스마스나 새해 맞이 이벤트도 이어지는데 들뜬 분위기와 달리 마음은 복잡하고, 내가 잘살고 있나 옳을 방향으로 가는 것인가 싶은 근원적인 고민이 찾아올만큼 심리적 혼돈의 시간이 온다.

그 시간을 잘 보내는 것은 각자의 몫이지만 너무 힘들어하거나 괴로워하지 않길 바란다. 무사히 완주해냈다는 것만으로도 충분히 자랑스러워 할 만한 결과다. 한해 고과는 회사에서 정해놓은, 지극히 제한적인 관점에서, 아주 일부분에 대한 평가일 뿐이다. 나에 대한 평가가 필요하다고 생각한다면, 좀 더 다각도로 그리고 긴 기간을 고려해서 스스로를 평가해보면 좋을 것 같다. 내 인생은 회사에서 담지 못하는 부분이 너무 많고, 회사의 사정이나 부서의 다른 직원들에 대한 고려 같은 것을 배제하고 평가해야 할 것들이 많다.

스스로가 자기 자신의 평가자가 되어서 객관적으로 평가해보고 피드백도 작성해보자. 나의 성장을 위해서, 그리고 다른 사람들이 알아 주지 못한 수고를 치하하기 위해서! 그렇게 정리하고 신나게 연말을 즐기자.