소프트웨어 회사에서 성과 위주의 치열한 내부 경쟁 강요는 단기적인 성과는 낼 수 있을지 몰라도 개발 문화와 기업 문화를 망친다. 그 결과 장기적으로는 오히려 혁신을 못하고 경쟁력이 약화된다.
많은 회사의 경영진은 성과에 따른 차등 보상을 통해서 개발자들의 의욕을 고취하려고 한다. 명백한 차등 보상을 통해서 너도 높은 성과를 내서 보상을 받으라고 독려하곤 한다. 이를 위해서 기본 연봉을 줄이고 성과급을 높임으로써 보상이 진정한 보상이 아니라 보상을 받지 못하면 평균 이하의 대접을 받게 되기도 한다.
개발자들이 받아야 할 적절한 연봉을 제대로 못 받고 선심 쓰듯 지급하는 성과급을 통해서 개발자들의 의욕을 고취하려는 방법은 조삼모사와 크게 다를 바 없다.
하지만 이런 방법은 탄광 같은 육체노동에서는 통할지 몰라도 정신노동에서는 잘 통하지 않는다. 특히 지식 산업인 소프트웨어는 단기 성과를 위해서 쉽게 미래를 갉아 먹을 수 있기 때문에 성과 드라이브는 약이 아니라 독이 되는 경우가 많다. 소프트웨어는 8시간 일하는 사람이 10시간 일한다고 성과가 더 나아 지는 것은 아니다. 그렇게 생각한다면 소프트웨어 개발을 육체 노동으로 생각하고 있는 것이다.
더 큰 문제는 평가의 불공정성이다. 평가의 기준을 무엇으로 삼을 것인가? 매출? 코딩 라인 수? 버그 해결 개수? 무엇으로 따져도 불공평하다.
매출은 사실 개발자들의 노력의 정도를 말해주지 않는다. 매출을 기준으로 보상을 한다면 개발자는 운에 따라서 연봉이 달라지는 결과를 가져온다. 단기적인 매출에 미치는 개발자 노력의 비중은 크지 않다. 분야에 따라서 천차만별이지만 환율이나 경쟁사 관계가 매출에 더 영향을 미치기도 한다. 억지로 단기 매출에 집착하다가 소프트웨어 아키텍처를 망치기도 한다. 소프트웨어의 어려운 점은 속으로 썩어도 당장 눈에 잘 안 보이는 것이다.
단기적인 특수 과제를 성공했을 때 보상하는 것도 불공평하기는 마찬가지다. 약간 선물식의 보상은 큰 문제는 없어도 단기 프로젝트 성공 팀에게 큰 보상을 하는 것은 다른 개발자들에게 상대적인 박탈감을 가져온다. 열심히 해도 운에 따라서 보상을 받지 못할 바에는 슬슬 어려운 일은 피하고 자기 시간을 가지며 여유롭게 생활하려고 한다. 개발 문화와 회사에 기여는 생각하지 않고 폭탄만 피하자는 무사안일이 판칠 수도 있다.
성과에 대해서 보상을 노골적으로 하면 보통 성과 위주로 일을 한다. 이게 무슨 잘못인가 생각하겠지만 소프트웨어는 지식산업이기 때문에 큰 문제다. 예를 들어서 매출에 비례해서 평가를 한다면 매출이 많은 부서로 옮기는 것이 가장 좋은 방법이다. 버그를 많이 고치는 것을 평가 기준으로 삼으면 일부러 사소한 버그를 많이 만들어내거나 버그 보고를 더 많이 하고 버그도 근본 원인을 해결하기 보다는 대충 증상만 잡을 수가 있다. 버그를 하나라도 더 고치기 위해서 애를 쓴다. 거짓말이 아니다. 개발자가 나쁜 사람이 이라서가 아니라 이런 정책에 길들여진 결과다.
개발자의 활동은 지극히 창의적인 활동이라서 성과 드라이브로 밀어 붙이면 당장은 성과가 좋은 것 같아도 장기적으로 대부분 더 손해가 난다. 소스코드를 잘 정리해야 하는데 당장은 문제가 안되니 엉망진창으로 놔두던가, 소스코드에 주석을 달 시간이 아까워서 주석을 안단다. 문서도 엉터리로 작성하고 당장에 단기 성과에 직접적인 영향이 있는 활동에만 집중한다.
그렇다고 성과가 중요하지 않는 것은 아니다. 성과가 중요하다는 것은 개발자들도 잘 알고 있다. 하지만 너무 성과로만 밀어 붙이고 이에 대해서 큰 차별적인 보상을 하면 더 큰 문제가 발생한다는 것이다.
소스코드가 망가지고 개발문화를 해치며 보상에서 소외된 90%의 사기에 저하된다. 보상을 받은 사람도 다음해에는 보상에서 제외될 수 있다.
몇몇 회사는 개발에게 원래 100을 주는 것이 적당한데 70만 주고 30은 성과에 따라서 보상하겠다고 한다. 이는 영업직에게나 적당한 정책이다.
인생이 운칠기삼이라고 해서 운이 매우 중요하고 보상을 받는 팀이나 회사에 속하는 것은 운이 좋아서라고 생각할 수는 있지만 개발자들을 성과에 따른 보상으로 움직이는 꼭두각시로 만들면 회사의 소프트웨어 개발역량은 점점 나빠질 것이다.
경영자들은 개발자들이 조삼모사 원숭이처럼 다룰 생각을 하면 안된다. 개발자를 움직이는 것은 여러 가지가 있지만 그 중에서 가장 중요한 것 중 하나가 연봉이다. 70주고 잘하면 30을 준다고 하지 말고 100을 모두 연봉으로 주는 것이 좋다.
개발자는 보통 일 자체를 즐긴다. 즐길 때 성과가 가장 높다. 그렇다고 개발자들이 노는 것은 아니다. 개발자들도 성과를 내야 한다는 것을 잘 알고 있다. 개발문화, 공유, 문서, 성과 사이에서 균형을 잘 잡아야 장기적으로 성과가 증가한다. 단기적인 성과를 절대로 무시할 수 없지만 그만큼 장기적으로 개발문화를 잘 발전시키는 것도 중요하다.
많은 회사의 경영진은 성과에 따른 차등 보상을 통해서 개발자들의 의욕을 고취하려고 한다. 명백한 차등 보상을 통해서 너도 높은 성과를 내서 보상을 받으라고 독려하곤 한다. 이를 위해서 기본 연봉을 줄이고 성과급을 높임으로써 보상이 진정한 보상이 아니라 보상을 받지 못하면 평균 이하의 대접을 받게 되기도 한다.
개발자들이 받아야 할 적절한 연봉을 제대로 못 받고 선심 쓰듯 지급하는 성과급을 통해서 개발자들의 의욕을 고취하려는 방법은 조삼모사와 크게 다를 바 없다.
하지만 이런 방법은 탄광 같은 육체노동에서는 통할지 몰라도 정신노동에서는 잘 통하지 않는다. 특히 지식 산업인 소프트웨어는 단기 성과를 위해서 쉽게 미래를 갉아 먹을 수 있기 때문에 성과 드라이브는 약이 아니라 독이 되는 경우가 많다. 소프트웨어는 8시간 일하는 사람이 10시간 일한다고 성과가 더 나아 지는 것은 아니다. 그렇게 생각한다면 소프트웨어 개발을 육체 노동으로 생각하고 있는 것이다.
더 큰 문제는 평가의 불공정성이다. 평가의 기준을 무엇으로 삼을 것인가? 매출? 코딩 라인 수? 버그 해결 개수? 무엇으로 따져도 불공평하다.
매출은 사실 개발자들의 노력의 정도를 말해주지 않는다. 매출을 기준으로 보상을 한다면 개발자는 운에 따라서 연봉이 달라지는 결과를 가져온다. 단기적인 매출에 미치는 개발자 노력의 비중은 크지 않다. 분야에 따라서 천차만별이지만 환율이나 경쟁사 관계가 매출에 더 영향을 미치기도 한다. 억지로 단기 매출에 집착하다가 소프트웨어 아키텍처를 망치기도 한다. 소프트웨어의 어려운 점은 속으로 썩어도 당장 눈에 잘 안 보이는 것이다.
단기적인 특수 과제를 성공했을 때 보상하는 것도 불공평하기는 마찬가지다. 약간 선물식의 보상은 큰 문제는 없어도 단기 프로젝트 성공 팀에게 큰 보상을 하는 것은 다른 개발자들에게 상대적인 박탈감을 가져온다. 열심히 해도 운에 따라서 보상을 받지 못할 바에는 슬슬 어려운 일은 피하고 자기 시간을 가지며 여유롭게 생활하려고 한다. 개발 문화와 회사에 기여는 생각하지 않고 폭탄만 피하자는 무사안일이 판칠 수도 있다.
성과에 대해서 보상을 노골적으로 하면 보통 성과 위주로 일을 한다. 이게 무슨 잘못인가 생각하겠지만 소프트웨어는 지식산업이기 때문에 큰 문제다. 예를 들어서 매출에 비례해서 평가를 한다면 매출이 많은 부서로 옮기는 것이 가장 좋은 방법이다. 버그를 많이 고치는 것을 평가 기준으로 삼으면 일부러 사소한 버그를 많이 만들어내거나 버그 보고를 더 많이 하고 버그도 근본 원인을 해결하기 보다는 대충 증상만 잡을 수가 있다. 버그를 하나라도 더 고치기 위해서 애를 쓴다. 거짓말이 아니다. 개발자가 나쁜 사람이 이라서가 아니라 이런 정책에 길들여진 결과다.
개발자의 활동은 지극히 창의적인 활동이라서 성과 드라이브로 밀어 붙이면 당장은 성과가 좋은 것 같아도 장기적으로 대부분 더 손해가 난다. 소스코드를 잘 정리해야 하는데 당장은 문제가 안되니 엉망진창으로 놔두던가, 소스코드에 주석을 달 시간이 아까워서 주석을 안단다. 문서도 엉터리로 작성하고 당장에 단기 성과에 직접적인 영향이 있는 활동에만 집중한다.
그렇다고 성과가 중요하지 않는 것은 아니다. 성과가 중요하다는 것은 개발자들도 잘 알고 있다. 하지만 너무 성과로만 밀어 붙이고 이에 대해서 큰 차별적인 보상을 하면 더 큰 문제가 발생한다는 것이다.
소스코드가 망가지고 개발문화를 해치며 보상에서 소외된 90%의 사기에 저하된다. 보상을 받은 사람도 다음해에는 보상에서 제외될 수 있다.
몇몇 회사는 개발에게 원래 100을 주는 것이 적당한데 70만 주고 30은 성과에 따라서 보상하겠다고 한다. 이는 영업직에게나 적당한 정책이다.
인생이 운칠기삼이라고 해서 운이 매우 중요하고 보상을 받는 팀이나 회사에 속하는 것은 운이 좋아서라고 생각할 수는 있지만 개발자들을 성과에 따른 보상으로 움직이는 꼭두각시로 만들면 회사의 소프트웨어 개발역량은 점점 나빠질 것이다.
경영자들은 개발자들이 조삼모사 원숭이처럼 다룰 생각을 하면 안된다. 개발자를 움직이는 것은 여러 가지가 있지만 그 중에서 가장 중요한 것 중 하나가 연봉이다. 70주고 잘하면 30을 준다고 하지 말고 100을 모두 연봉으로 주는 것이 좋다.
개발자는 보통 일 자체를 즐긴다. 즐길 때 성과가 가장 높다. 그렇다고 개발자들이 노는 것은 아니다. 개발자들도 성과를 내야 한다는 것을 잘 알고 있다. 개발문화, 공유, 문서, 성과 사이에서 균형을 잘 잡아야 장기적으로 성과가 증가한다. 단기적인 성과를 절대로 무시할 수 없지만 그만큼 장기적으로 개발문화를 잘 발전시키는 것도 중요하다.
