Outsider's Dev Story

Stay Hungry. Stay Foolish. Don't Be Satisfied.
RetroTech 팟캐스트 44BITS 팟캐스트

나는 성과제를 별로 좋아하지 않는다

수많은 회사를 다녀본 것은 아니지만 내가 다녀본 회사들도 그렇고 들어본 얘기로도 국내 회사들은 대부분 성과제를 도입하고 있다. 하지만 보면 볼수록 불합리한 제도라는 생각밖에 들지 않고 시간이 갈수록 그따위 성과제에 연연하기 보다는 성과 좀 포기하고 맘편히 사는게 더 낫다고 느끼고 있다.

성과제의 원리는 간단하다. 더 열심히 혹은 더 잘 일하면 돈(혹은 그와 비슷한)으로 보상해 준다는 것인데 우리는 학교를 다니는 것은 아니므로 더 열심히 보다는 보통은 더 잘 즉 결과를 만들어내는 것에 초점이 맞추어져 있다. 이는 얼핏 보면 자연스러운 논리인 것처럼 보이지만 실상은 전혀 아니라고 생각한다. 제조업이가 전통적인 산업에는 어울리는 지 몰라도 최소한 IT 분야에는 오히려 방해가 된다.

성과에 대한 평가를 어떻게 하지?

만약에 봉투접기라던가 인형에 눈알 붙히기 같은 작업이라면 성과제는 유효할 것이다. 평소에 100개 만드는데 100개 이상 만들면 그만큼 돈 더 준다고 한다면 아마도 만드는 갯수가 올라갈 것이다.(물론 품질등 확인해야할 여러 요소들이 있겠지만.) 하지만 IT는 그렇게 단순하지 않고 한 부분에 집중하고 있는 벤처라면 좀 낫겠지만 조직이 클수록 누가 잘한 성과인지 판별하는 건 거의 불가능하다고 본다.

A 사업이 소위 대박이 낫다고 하자. 이 대박의 공은 누구의 공일까? 간단히 보면 해당 사업을 추진한 사업부나 세부 내용을 기획한 기획쪽에 둘 수 있고 해당 사업을 개발한 개발팀도 포함될 수 있다. 그러면 회사의 공통인프라에 가까운 QA나 네트워크팀, 서버관리쪽은 어떤가? 물론 이부분에서 엉망이었다면 사업을 성공할 수 없었을 지도 모른다. 이런 부서의 성과는 어느정도로 평가해야 하는 걸까? 사업이나 기획에서는 무리한 요구를 했는데 개발이나 QA 혹은 다른 부서에서 좀더 합리적인 제안을 한게 성공의 주요 요인일 수도 있다. 이런걸 판별할 수 있기나 한가? 그리고 신규사업이란 건 보통 새로운 도전이고 결과가 보장되지 않는다. 그래서 보통은 현재 회사를 지탱하고 있는 수익을 내는 사업이 있고 어찌 보면 이런 사업들이 있었기에 다른 부서가 신규사업에 도전할 수 있는 것이었다. 그러면 이러한 사업을 하는 팀은 성과를 어떻게 평가할 것인가?(보통은 익숙해 져서인지 성공한 사업도 수년이 지나면 더 성과를 내기를 바라지 현상 유지로 좋다는건 한번도 보지 못했다.)

성과를 주면 사람들이 더 열심히 일할까?

옆팀이 대박이 나서 엄청난 성과급을 받았다고 했을 때 "나도 내년에는 미친듯이 해서 성과급을 받겠어!"라고 하는 사람은 단 한명도 보지 못했다. 사람들은 대부분 자신이 상당히 열심히 잘 일했다고 생각하기 때문에 일반적인 반응은 "난 안해!"라는 것이다. 왜냐하면 이건 일을 잘한 것의 결과이기도 하지만 사람들은 다 잘 해왔기 생각하기에 그 결과는 좀 운빨로 보이기 때문인듯 하다. 그리고 성과제가 그렇게 유효하다면 전통적으로 회사의 기반이 되는 사업을 하는 사람은 아무도 없이 선택권이 있다면 새로 대박이 날 것처럼 보이는 회사로 다 몰려갈 것이다. 그러면 돈은 안되지만 유지는 해야하는 사업(어느 회사나 이런게 있다.)은 누가 하지? 일에 대한 열정도를 떠나서 경험상 그냥 시키니까 하는 거지 이런 일을 하고 싶어하는 사람은 없고 회사가 필요했다는 면에서 성과가 있지만 이들은 상대적인 박탈감을 느끼게 된다.

그리고 돌아가는 상황들을 보면 실제 성과를 내기 보다는 성과를 낸 것으로 포장하는 움직임이 훨씬 커진다. 왜냐하면 이게 훨씬 쉬운 일이기 때문이다. 모든 걸 성과로 연결시킴으로 써 각 조직들은 성과를 내기위해서 움직이지만 해당 사업이 잘못되었다고 생각했을 때 잘못을 인정하고 다른 길로 가는 것이 회사로써는 훨씬 생산적인 일이지만 그게 올해의 성과이기 때문에 잘못되었다고 깨달아도 인정하지 않고 성과가 나는 것으로 포장하게 되고 해당 사업과 회사는 점점 엉망이 되고 임원레벨(특별히 깨어있지 않다면)에서는 잘못된 성과보고를 보고 있을 가능성이 크다.

이러한 대표적인 제도가 내가 가장 멍청하다고 생각하는 KPI(Key Performance Indicators)인데 연간 혹은 분기별 목표를 잡고 움직인다는 건데 IT처럼 빠르게 움직이고 상황에 따라 움직여야 하는 분야에서는 KPI는 악에 가깝다. KPI를 적용하면 경험상 일을 제대로 하는 것보다 일은 적당히 하면서 KPI로 잡아놓은 일을 해내는게 성과를 내기에 훨씬 낫다.(물론 대부분은 이런거에 상관없이 팀장재량으로 인사고과가 결정되는 듯 하지만) 해당 KPI가 현재 팀에 도움되는지 회사에 도움되는 지 같은건 상관없고 KPI를 정했으면 그냥 거기에 집중하는게 개인에게 낫기 때문에 중간에 방향전환(KPI 조정시기 같은 형식적인게 있긴 하지만)을 하거나 KPI보다 회사에 도움되는 일을 찾기 보다는 그냥 KPI를 수행한다.


아무리 오랫동안 봐도 왜 유지되고 있는지 도저히 이해하기 어려운 제도 중 하나이다. 윗분들의 의도인지는 모르겠지만 거의 동작하지 않는다는 부분에서 여전히 이해할 수 없고 이건 이러한 정책을 정하는 사람들이 고민하기 싫어서 그냥 하던거 계속하는 식의 직무유기라고 밖에는 생각되지 않는다. 그럼 어떻게 하냐고 물을 수도 있지만 내 영역은 아니라서 나도 정확히 알수는 없지만 성과제로는 해결책이 아니라고 말하고 싶었던 거다. 내 얕은 생각으로는 그냥 1/n을 하면 되지 않는가 싶고 일잘하는 사람과 아닌 사람은 어차피 팀이나 같이 일하는 사람이 알기 마련이고 인사고과등 다른 접근 방법도 충분히 있다고 생각한다.

마지막으로 관련된 TED 영상 하나..

2013/08/10 23:57 2013/08/10 23:57