[이 글은 내가 21일에 현대자동차에서 발표했던 세미나 내용 중 일부를 좀더 확장하여 작성해 본 것이다]
다른 나라도 그런지 모르겠지만 우리나라의 개발자로서 마음에 안드는 것 한 가지는 개발자 평가를 연차로 하는 방식이 일반적이라는 것이다. 개발자 개개인마다 경험과 능력이 다른데 연차로만 평가하다니 이게 무슨 초등학생 학년 올라가는 건가?
개발 현장에서 연차로만 모든 걸 평가하는 건 아니지만 시장에서는 연차에 의한 평가와 그에 따른 급여 수준이 책정되는 것이 일반적이다. 기본적으로 우리의 소프트웨어 개발에 대한 수요-공급 시장은 프로젝트 단위의 단기 계약 위주로 편성돼 있고 그 과정에서 개발자는 단순히 연차에 의해 도매금으로 비용이 산정되는 것이 일반적이다. 개발자 평가가 그렇다보니 프로젝트 역시 Man-Month 기반으로 산술적인 노동력에 대해서만으로 비용을 산정하게 된다.
개발 능력이 아무리 좋아도 고졸이고 신입이라면 이 업계에서는 금전적 대우를 받기 쉽지 않다.
개발 능력이 좋다고 평가받는 것은 우선 기술적인 능력에 있어서 다음과 같은 여러가지 주제에 대해 실무 능력이 있는 경우를 말하는 것일 것이다.
- 데이터 구조, 앨거리듬
- 버전 관리, 형상 관리, 빌드/배포 자동화
- 버그 해결, 테스팅, 품질
- 확장성 있는 시스템
- 통신, 서버, 암호화 및 시스템 프로그래밍
- 프레임웍, API
- 데이터베이스
그런데 개발자들의 연차가 아무리 올라가도 어떤 분야는 무지에 가까울수도 있고 어떤 분야는 남보다 탁월할 수 있다. 이런 차이를 연차로만 재단한다는 것은 상당한 무리가 있는 것이다.
그 동안 본 개발자 중에는 연차가 상당했고 SQL은 어느 정도 개발하지만 자바(Java)는 초보나 비슷한 수준인 개발자가 있었다. 주력 개발은 자바로 해야 하는데 이런 개발자에게도 연차로 계산한 급여를 줘야만 하는가?
위에서 본 기술 항목 하나 하나가 상당히 큰 주제가 되는 내용들이지만 나는 개발 능력을 평가하는 핵심적인 주제 하나를 고르라면 앨거리듬에 대한 이해라고 말하고 싶다.
사실 현대적인 개발 환경에서 앨거리듬을 개발자가 직접 구현해야 하는 경우는 별로 없다. C++의 경우 Boost 라이브러리가, 자바의 경우 표준 런타임 라이브러리가 상당히 많은 소프트웨어 앨거리듬을 구현하고 있다. 해시테이블, 검색, 트리 같은 데이터 구조 앨거리듬부터 압축, 암호화 등. 개발자는 가져다 쓰기만 하면 되고 개발 본연의 업무적인 구현에 집중할 수 있다.
하지만 앨거리듬을 이해하고 사용하는 것과 모르고 사용하는 것은 차이가 있다. 개발 능력의 차이는 이러한 것에서도 발생한다.
예를 들자면 해시맵은 배열에 비해 우수한 찾기 성능을 보인다. 말하자면 배열은 데이터 항목들을 겹쳐서 나열했기 때문에 뭔가를 찾으려면 하나씩 뒤져봐야 하지만 해시맵은 “버킷” 단위로 펼쳐놨기 때문에 키 값에 따라 원하는 항목을 바로 집어낼 수 있다. 그런데 데이터 항목 수에 비해 버킷 수가 많으면 메모리가 낭비된다. 반대로 버킷 수가 적으면 해시맵이 원래 의도한 성능을 낼 수 없다. 이걸 모르고 해시맵을 사용한다면 비효율성이 발생할 수 있는 것이다.
실제로 예전 프로젝트에서 우리 회사 개발자가 XML을 처리하는 프로그램을 만들었는데 간혹 메모리 부족 오류가 발생하는 것이었다. 알고보니 XML의 크기에 상관 없이 DOM 방식으로 파싱하고 있었고 모든 XML을 한번에 가져와 for 반복문으로 처리하고 있었다. DOM 방식이 SAX 방식에 비해 메모리를 많이 사용한다는 것을 알았다면, 모든 XML을 한 번에 읽어 처리하기보다는 하나씩 처리할 필요가 있음을 알았다면 그런 문제는 만들지 않았을 것이다.
끝으로 개발자를 평가하는 능력에 있어서 기술적인 능력 외에 다른 능력도 중요함을 말하고 싶다. 개발자에 있어 개발 능력은 기본이다. 기본은 누구나 해야 하는 것이다. 그렇다면 기본을 갖춘 후에는 다른 것들이 중요해진다. 내가 생각하는 또 다른 중요한 것은 협업 및 의사 소통이다.
프로젝트를 진행함에 있어서 특히 큰 규모의 프로젝트는 의사 소통이 정말 중요하다. 진행 상황에 대한 공유도 해야 하고 기술적인 이해 기반도 공유해야 하고 업무 내용에 대한 이해도 공유해야 한다. 사람에 따라 그 정도가 다르지만 나는 프로젝트에서 협업과 의사 소통이 차지하는 비중이 50%는 된다고 생각한다. 그 50%를 실패하는 것은 개발을 실패하는 것과 똑같은 중요도를 실패하는 것이다.
낭중지추. 개발자의 능력이 뛰어나다면 드러내지 않아도 남들이 알아주게 된다. 개발자들이 제대로 평가받는 체계가 조성됐으면 한다.