Ting 이네 Software 이야기

익히 알려진 바와 같이, 인사평가가 100% 공정 - 공정이라는 단어의 정의를 어떻게 하느냐에 따라 달라질 수도 있겠지만 - 할 수는 없다.

일례로, 기왕이면 진급 대상자에게 상위고과를 주는 것이 어찌보면 '인지상정'이라고 할 수도 있을 것이다.

이런 것이 '좋다' 혹은 '바르다'라고 이야기 하는 것이 아니다. 평가는 100% 공정한 것이 좋다. 그렇지만, '공정'이라는 것이 그 속성상 100% 객과적일 수가 없기 때문에, 주관적인 판단이 반드시 개입된다는 것을 인정해야 한다.

그리고, 이런 '주관적인 판단'에는 주변의 환경적인 요소가 포함되기 마련이다.

예를 들면, "같은 성과라면, 기왕이면 진급이 절실한 사람에게 손을 들어 준다던가."라는 것들 말이다.

비슷한 이유로, 상위고과가 다른 이들보다 절실한 사람이 있기 마련이다.

그렇다고 해서, 인사평가 시즌에 무턱대로, 이런 사람에게 아무런 이유없이 상위고과를 줄 수는 없는 일이다.

이런 경우, 어떻게 해야 합리적인 방법으로 무리없이 이런 문제를 처리할 수 있을까?

내가 보기에, 인사평가는 "일을 얼마나 잘 하였느냐?"보다는, "어떤 일을 하였느냐?"가 더 많은 부분을 차지하는것 같다.

SW의 분야의 경우 예를 들어보면, 기존일을 '유지/보수'하는 일은 정말 압도적인 '실력/성과'를 보이지 않고서는 최상위 평가를 받기는 거의 볼가능하다.

그렇지만, 회사가 주요하게 추진하는 새로운 제품을 개발한다던가, 새로운 기능을 추가 구현하는 일은 일단 무사히 업무를 마치기만 해도 상위 평가를 받을 가능성이 높다.

이 두가지 업무 중 어느 쪽이 더 힘들고, 덜 힘든지는 경우에 따라 다를 것이지만, 일을 마쳤을 때 받을 수 있는 평가의 차이는 상당하다.

다시, 앞의 이야기로 돌아가 보자.

어떤 사람에게 '기왕이면' 상위고과를 주고 싶은 경우는 위에서 언급한 내용을 응용하는 것이 좋다.

그 사람에게, '상위고과를 받을 수 있는 일'을 할 수 있는 기회를 주는 것이다.

'좋은'일이 생겼을 때, 소위 '챙겨줘야'할 사람에게, 먼저 "이 일을 할 것인지?"에 대한 의사를 물어보는 것이다. 그리고, 이 일을 잘 해내었을때 좋은 평가를 받을 수 있다는 것도 같이 언급하는 것이 좋다.

이렇게 먼저 기회를 주고, 무사히 일을 잘 해내었을 경우 큰 물의를 일으키지 않고 필요한 사람에게 '상위고과'를 줄 수 있게 된다.

한편, 이런 기회에도 불구하고, 일처리가 미숙했다면, 그 사람은 거기까지가 한계인 것으로 볼 수 있다.

지금까지 어찌보면 굉장히 '부당'하다고 생각할 수도 있는 이야기를 했다.

읽는 사람에 따라서 상당히 불편하게 받아들일 수도 있을 것이다.

그렇지만, 사람이 사는 곳이라면 이런 문제가 반드시 발생하고, 실제 많은 조직에서 이런 문제가 심심치 않게 보인다는 것에 이견을 가진 사람은 없으리라 생각한다.

따라서, 이런 일을 피할 수 없다면, 최대한 합리적인 방법으로 처리할 필요가 있고, 내 개인적인 생각으로는 위과 같은 방법이 무난하다고 여겨진다.

여기서 다시 한번 강조하고 싶은 내용은, 상당히 많은 경우 "그 사람이 얼마나 일을 잘 했느냐?"가 아니라, "그 사람이 어떤 일을 했느냐?"가 평가에 더 많은 비중을 차지한다는 것이다.

Software분야에서 소위 '성과 평가'에 대한 문제는 아주 오래되고, 또 진부한 문제다.

여러가지 한계를 이야기 하고 있고, 그럼에도 불구하고, "평가를 하지 않는 것 보다는 하는게 낫다."라는 이론(?)을 근거로, 여전히 다양한 형태의 '평가'가 행하여 진다.

이 글은 '대안'을 제시 - 가장 어려운 부분 - 하는 것이 아니고, 기존 '평가' 방식이 가지는 여러가지 문제 중 하나를 언급하기 위해 작성된 것이다.

Software분야의 여러가지 연구 중 아래와 같은 것이 있었던 것으로 기억한다. (출처는 기억이 잘...)

"Software engineer에 개인의 기술적인 역량은, '어떤 group에 속해 있느냐'에 따라 상당히 많이 좌우된다."

즉, 좋은 group에서 좋은 경험을 쌓은 engineer가 기술적으로 뛰어난 engineer가 될 확률이 높다는 뜻이다.

그리고 또 재미있는 연구 중 하나는 (이것도 출처가 잘...)

"Software engineer 개인의 성과 차이는 100배까지도 발생하지만, 조직의 성과 차이는 10배 정도까지 밖에 차이가 나지 않는다."

관점에 따라서, 80:20 법칙을 생각나게 하기도 한다.

개인의 역량차는 심하게 나지만, 조직의 역량차는 그렇게까지 크지 않다는 뜻이다.

아마, [역량이 '1'인 엔지니어들의 group] vs. [역량이 '100'인 엔지니어들의 group] 과 같은 극단적인 조건에서가 아니라, 현실세계에 존재하는 일반적인 group을 대상으로 한 조사였을 것이라 생각된다. 

그리고 또, 일반적인 '회사'에서 똑같은 일을 두 곳 이상에서 하는 경우는 거의 없다.

내가 하고 싶은 말은, 

"조직의 역량 차는 각 개인의 역량차에 비해 크지도 않고, 또 같은 일을 하는 조직이 없기 때문에 SW조직의 역량을 비교 평가하는 것은 상당히 어려운 일이다."

라는 것이다.

특히, 같은 일을 하는 조직이 없다는 뜻은, 그 조직의 역량과 무관하게, 해당 분야의 history / 경험/ domain knowledge 등에 따라 진입장벽이 만들어 진다는 말이다. 그리고, 이 진입장벽으로 인해, 조직간 역량 평가는 결국 무의미해 진다."

즉, 개인의 성과 평가보다도 SW 조직(개발 조직)의 평가가 더 어렵다.

SW조직의 평가가 어렵다는 것을 받아 들인다면, 독립된 두 조직이 있을때 어느 조직이 더 나은 조직인지 알지 못한다는 뜻이다.

A, B 두 조직 중 실제 A 조직이 더 우수하지만, 조직 평가의 어려움 때문에 A, B 조직의 평가가 같게 나온 상황을 가정하자.

이 상황에서, 우수한 조직에서는 우수한 engineer가 배출될 확률이 높고(앞서 언급했다.) A 조직과 B조직의 역량차는 계속해서 커진다.

그렇지만, 여전히 조직간 평가의 문제점/어려움 때문에 이 부분이 보여질 가능성은 극히 낮다.

이런 상황에서, 일반적인 '회사'에서는 '상대평가'를 수행한다.

각 조직에서 상위 성과자와 하위 성과자를 구분하는 것이다.

개인의 역량평가를 정확히 실시하는 것도 사실 거의 불가능 하지만, 개인간 정확한 성과 평가가 가능하다는 것을 가정하더라도, 이미 조직의 평가에서 정확성을 잃어 버렸으므로, 개인간 평가의 정확성은 상당부분 희석될 수 밖에 없다.

뛰어난 조직의 하위 성과자가, 다른 조직의 상위 성과자 보다 더 나은 성과를 보였을 가능성도 무시하기 힘들다.

별다른 통일성이 없는 글이였는데... 정리하면...

SW분야에서 개인의 역량 평가에 대한 연구도 중요하지만, 조직의 역량 평가에 대한 연구도 동등 혹은 그 이상으로 중요하다.