프로그램 개발자의 연봉 기준은?

개발자의 가치(연봉) 책정의 기준은 무엇일까?

일반적인 회사에 개인의 업무능력을 평가하는 기준이 있다면, 아마 인사 담당자에게 제출되는 개인업무 성과를 수치화 하는 문서가 전부라고 생각 된다.(내가 경험한 대부분의 회사가 그랬다.) 이 기준은 어떤 프로젝트를 참여해서 어떤 결과를 냈고, 어떤 문제점이 있었는가 하는 내용을 수치화하는 것 뿐이다.
과연 이런 내용으로 개발자 평가가 가능할까? (편의상 앞에 말한 평가 기준 혹은 자료를 "일반평가기준"라고 부르자!)

다른 일반적 업무(마케팅, 일반사무 등)에 대한 별도 평가기준도 없는 마당에 개발자에 대한 평가기준이라는 것은 좀 우습게 느껴질지도 모른다. 하지만 큰 문제는 현재 사용되고 있는 일반평가기준은 절대로 개발자의 능력을 평가 할 수 없다는 것이다.

개발자의 업무는 단순하게 "어떤 일을 마무리했는가?" 하는 결과적인 것 보다 과정이나 업무의 비중이 더 중요하다. 하지만 일반평가기준에는 이런 내용을 표시 하지 못하는 것이 현실이다.
쉽게 말해 일반평가기준에는 업무의 강도를 표시 할 수 없다는 것이다.

일반평가서에 표현 가능한 범위는 참여한 프로젝트의 성공여부와 수익뿐일 것이다. 그래서 개발자 개개인의 능력 보다는 참여한 프로젝트의 전체 평가 혹은 기획자 혹은 관리자의 능력에 종속적인 평가가 이루어진다.
평가자가 대상자가 수행한 프로젝트를 상세히 알고 있어야 가능하지만, 그렇지 못한 경우가 많다. 그래서 관리자들의 눈에 보이는 UI(사용자 인터페이스)를 위주로 평가가 진행된다.
즉 자기의 눈에 보이는 내용을 위주로 평가된다.

이런 현실에서 개발자에 대한 평가는 능력과 관계없이 이루어지게 된다. 즉 좋은 개발자에 대한 평가가 정상적으로 이루어지지 못한다는 것이다.

이해를 돕기 위해 극단적인 예를 들어보자!
약삭빠른 개발자 A 와 성실한 개발자 B가 있다고 생각해보자. (업무를 하는 사람이 약삭빠르다는 것이 아니다. 절대 오해 없길! 극단적인 예라고 명시 한 것처럼 일반화 하는 것이 아니다.)

A : 간단한 로직과 UI 위주의 작업 진행
B : 내부 로직 위주의 코어 작업 진행

A : 작은 규모의 프로젝트 다수를 진행
B : 프로젝트를 말아먹은 C의 퇴사로 대신 마무리 후 내년까지 이어지는 프로젝트 진행

A : 최종 결과 위주로 프로그램 개발을 통한 프로젝트 기간 단축
B : 향후 일어날 수 있는 오류 및 확장성을 고려한 개발 및 협의로 프로젝트 기간 늘어남

탄탄한 비즈니스 로직을 구현하는 B 보다 빨리 구현하는 A와 같은 사람의 평가가 좋다.
A와 B 모두 열심히 일하는 사람이고 능력도 비슷하다면 뭐가 문제가 되겠는가? 우리나라의 현실은 A와 같은 사람이 더 좋은 평가를 받고 있는 것이 사실이다.

업체의 성격마다 프로젝트마다 다르겠지만 특히 내부 서비스 개발에도 동일한 잣대가 적용된다면 문제가 크다.
A와 같은 사람이 필요한 프로젝트도 있지만 회사의 미래와 우리나라 IT 미래를 생각 한다면 조금 더 정확한 평가지표가 필요 할 것이다.

이런 상황이 계속되면 좋은 프로그래머들은 떨어져나가고, 좋은 프로그래머도 나쁜 프로그래머로 변해가는 것이 당연하다. 지금 당신의 회사는 좋은 프로그래머를 나쁜 프로그래머로 만들고 있지는 않습니까?

마무리 지으면서
2000년도 IT버블 당시에 학원에서 찍어내듯이 생산해내고, 능력 없는 이들이 억대 연봉을 받으면서 떵떵거리던 시절도 있었다. 하지만 IT 버블이 꺼지면서 이런 사람들은 대부분 떨어져나가고, 덩달아 프로그래머가 저평가되고 연봉은 정말 바닥이라는 것이 사실이다.

이런 상황이라면 영악한 요즘 세대들 그리고 다음 세대들은 더 이상 프로그래머라는 직업을 택하지 않게 될 것 이다. 프로그래머 없이는 IT산업도 없다는 것을 기억해줬으면 한다.