이제 프로그래머에 대한 이야기를 해 보자. IT서비스를 포함한 성공한 프로그램은 예외없이 한가지 공통점을 가진다. 품질이 좋다. 단순히 기발한 아이디어를 구현했다던지, 독자적인 무엇인가를 가지고 있다는 레벨이 아니다. 요즘같이 아이디어가 오픈되어 있는 시대에서는 기능면,성능,편의성,안정성. 어느것 하나 뚜렷한 약점이 존재해서는 성공하기 힘들다. 만약 어느 한 영역에 뚜렷한 약점이 있다면 반짝 히트는 가능할 지라도 롱런하기 힘든 제품이 될 것이다. 그만큼 소비자의 기준은 엄격하고 취향은 까다롭다. 이러한 높은 품질의 프로그램을 만들어 내기 위해서는 노력만으로는 감당이 안된다. 발상의 전환과 같은 창의적인 문제 해결 능력이 필요 하다. 노벨상에 비할바는 아니지만 좋은 소프트웨어를 만들어 내는 작업은 단순히 시키는 것을 열심히 하는것 만으로는 부족 하다는것이 자명하다. 끊임없이 스스로 배우고 생각하고 적용해 나가는 선순환의 루틴을 만들어 낼 수 있어야만 하는 이유다.

즉, 개발자의 무한 희생이 아니라 '개발'자체가 개발자에게 기쁨과 즐거움이 될 수 있어야 한다.

이는 비단 일반 유저를 대상으로 하는 B2C에만 해당되는것은 아니다. 사내 업무 시스템과 같은 B2B프로젝트 또한 엄연히 요구사항이 정의되어 있기는 하지만 모든 사항을 사전에 파악하고 문서로 정의할 수는 없을 것이다. 그 보다는 시스템을 만들어가는 개발자가 사용자의 입장에서 시스템을 바라 보고 보다 나은 시스템을 만들려는 노력을 멈추지 않는 자세가 필요하다. 그리고 모두가 잊고 있었던 당연한 이 사실을 다시한번 일깨워 준 것이 바로 애자일 선언이다.

오늘은 개발자의 동기부여라는 주제로 이야기를 해 보고자 한다.

양초의 법칙 : 프로그래머를 지적 노동자로 만들것인가 단순 노동자로 만들 것인가?

인센티브는 동기 부여에 도움이 될까?

결론부터 말하자면 일의 성격에 따라 도움이 될 수도, 그 반대가 될 수도 있다.

현대 심리학계에 지대한 공을 세운 인물중 한명인 Karl Duncker는 1945년 실시한 실험을 통해 선입견에 대한 연구를 진행하였다.

Duncker는 피험자들에게 테이블 위에 압정이 가득 든 상자와 양초, 그리고 성냥을 주고는 "테이블에 촛농이 떨어지지 않게 양초로 벽에 고정시키시오"라는 과제를 제시하였다.

이 문제에 대한 해법은 상자안의 압정을 모두 쏟아내고 압정 한개만을 이용해 상자를 벽에 고정시키고 양초에 불을 붇이는 것 이었다.

Duncker는 피험자를 두 그룹으로 나누고 상자안에 압정이 있는 경우와 상자 밖에 압정을 모두 쏟아낸 두가지 상황의 제시를 통해 "상자"가 가지는 선입견이 문제 해결에 미치는 영향을 입증해 내었다.

상자를 단순히 압정을 담는 도구로만 인식할 경우 이 문제는 풀 수 없으나 발상을 전환이 가능할 경우에만 문제를 풀 수 있게 된 것이다.

그로부터 17년후, 뉴욕대학의 대학원생이었던 Glucksberg는 이 실험을 응용하여 포상과 문제해결 사이의 상관관계를 찾아내었다. 그는 피험자를  A,B 두 그룹으로 나누고 한

A그룹에는 그냥 문제를 풀고 시간을 알려 달라고만 했고 B그룹에는 문제를 푼 사람에게 5달러를, 가장 빨리 문제를 푼 사람에게 20달러를 지급한다 설명했다.

한쪽은 무상으로 문제를 풀도록 하고 다른 한쪽은 인센티브를 제시한 것이다.

결과는 A그룹이 평균 7분, B그룹이 평균 10.5분이 걸렸다. 상금이 걸린쪽이 무려 35%나 낮은 성과를 낸 것이다.

이 결과는 다음과 같이 설명되었다. "난이도가 높은 문제의 경우 해결에는 시행 착오와 발상의 전환이 필요하다. 그러나, 보상이나 벌칙에 압받을 받게되면 인간은 사고의 유연성을 잃어버리고 하나의 생각에 집착하는 경향을 보인다. 결과적으로, 창의력을 요하는 문제의 경우 부담없이 임하는 것이 오히려 빨리 답에 도달하게 된다."

이 실험의 또 다른 버전이 있다.

스텐포드 대학의 Michael C. Frank과 Michael Ramscar는 Glucksberg의 실험과 거의 동일한 실험을 진행하였다. 이들이 진행한 실험에서는 압정을 상자안에서 모두 꺼내어 상자에 대한 선입견을 제거했다. 즉, 문제에 대한 난이도를 낮춘것이다. 그 결과는 인센티브를 제시한 그룹이 25%에서 50% 빨리 문제를 해결하는 성과를 내었다. 창의력이 배재된 단순 작업의 경우, 인센티브가 효율적으로 작동한다는 것. 즉, 우리가 익히 알고 있는 비즈니스 세계의 룰의 효용성이 증명된 것이다.

자 이제 다시 프로그램의 세계로 돌아오자.

인센티브를 통해 프로그래머에게서 높은 성과를 뽑아내려 한다면 어떤 결과가 올까? 

스스로 "생각"을 하기 보다는 눈에 보이는 결과를 낼 수 있는 "행동"에 집착할 것이다. 눈에 보이는 부분에 대해서 열심히는 하겠지만 창의적인 업무 처리와는 점차 거리가 멀어지게 된다. 더욱 나쁜것은, 상사나 외부로부터 "평가"되지 않는 행동들에 대해서는 더이상 신경쓰지 않게 된다는 점 이다. 

공부 못하는 아이를 반장으로 임명하는 것 과 같이, 우등생으로 대접하면 성적이 오른다는 교육이론이 있다. 이 이론을 위의 문제 난이도와 인센티브간의 상관관계에 접목시키면 창의력을 요하는 프로그래머 를 인센티브로 길들이는 것 과 같이 단순 노동자 취급을 하면 정말로 단순 노동자가 되어버린다는 사실이다. 그리고 스스로 생각하는것을 그만 둔 프로그래머는 당연히 생산성이 낮아진다. 낮아진 생산성은 낮은 평가와 낮은 급여 그리고 이직으로 이어지며 이렇게 떠나간 사람이 회사에 대해서 좋은 감정을 가지고 있을리 없다. 회사에 대한 나쁜 소문이 퍼지기 시작하고 좋은 인재가 기피하는 회사가 된다. 악순환의 완성이다.

창의적인 업무처리와 생산성은 어떠한 상관관계를 가질까? 예를 들어 수십개의 테이블에 대한 단순 입출력과 검색을 구현하는 화면을 작성하는 작업이 있다고 해 보자. 성실히 구현해 나간다면 당초 예상보다 일정을 앞당길 수도 있을것이다. 품질개선에도 신경을 쓴다면 좋은 품질을 유지 할 수도 있을것이다. 하지만 Rails와 같은 프레임워크를 생각해 낸다면 이러한 노력의 절약과 품질의 향상에 극적인 변화를 기대 할 수 있을것이다. 이러한 발상의 전환은 어느정도 재능은 필요하겠지만 천재성을 필요로 하진 않는다. 오픈소스 시대에서 모든 지식이 공개되어 있기 때문이다. 따라서 사고의 전환을 할 수 있을 만한 여유와 스스로 계획할 수 있는 권한, 그리고 실패에 대한 관용의 문화가 있다면 개발자들은 얼마든지 창의적으로 일 해 나갈 수 있다.

비단 프로그래머가 아니어도 경영학적 관점에서 차등 보상에 기반한 성과주의가 실패하는 것은 논리적으로 증명된 사실이다.

다음은 '착각하는 CEO(유정식 저,2013)'에 소개된 내용이다.

경영 컨설턴트이자 심리학 박사인 폴 마르시아노는 차등보상프로그램이 직원들의 동기를 전반적으로 떨어뜨린다는 점을 논리적으로 증명해 보였다. 차등 보상이 실행되었을 경우, 직원을 성과 평가 결과에 따라 우수성과자, 저성과자, 중간성과자로 구분해서 각각의 경우에 어떠한 영향을 미치는지 살펴보자.

그렇다면 어떻게 해야 프로그래머에게 동기부여를 할 수 있을까?

필자가 생각하는 가장 좋은 방법은 동기부여가 이미 되어 있는 사람을 채용하는 것 이다. 호기심이 많고 배움에 대한 열정이 가득한 사람이라면 지금 가진 업무에 대한 지식이 약간 부족하다 할 지라도 크게 문제가 되진 않는다. 일 자체를 즐길 수 있기 때문이다. 어차피 빠르게 변화해 가는 기술 트렌드 속에서 지금 얼마나 알고 있는가는 그다지 중요하지 않다. 이러한 사람의 경우 나이가 많고 적음을 떠나 남과 구별되는 무언가를 이뤄낸 경우가 많다. 면접관은 이러한 부분에 대해 주의 깊게 관찰하고 질문하여 판단하여야 한다. 필자의 경험상으로는 탑코더식의 코딩시험도 많은 도움이 된다.

능동적인 일의  진행은 프로그래머 뿐만 아니라 프로젝트 구성원에게 큰 동기 부여가 된다. 팀 안에서 자율적으로 결정하고 결정된 사항에 대해서 책임을 지는것. 이것은 많은 전 현직 구글 직원들이 꼽는 구글의 성공비결중 하나이기도 하다. 고객이 제시한 가이드라인을 따라야 하는 SI프로젝트라해도 일 자체의 진행에는 많은 융통성이 존재한다. 팀원들에게 최대한의 자율권과 그에 따르는 책임을 부여하라. 상명하복에 길들여져있는 조직이라면 이것은 말처럼 쉽지 않다. 전술한 내용을 도입하려는 리더라면 자율성의 도입에 많은 고민과 노력을 기울여야만 할 것이다. 비슷한 경험을 가진 사람의 조언을 받거나 조직 문화 개선에 대한 책을 읽는것도 좋지만, 제일 중요한 것은 사람들의 의견을 듣고 대화해 나감으로서 공감대를 형성하는 것 이다.

SI에서 적용 할 수 있는 능동적인 프로젝트 진행의 팁을 한가지 소개하겠다. 아마 대부분의 SI현장에서 비교적 도입이 쉬우면서도 효과적이리라 생각한다. 바로 티켓주도 개발(TiDD)의 도입이다.

원리는 간단하다. 폭포수형개발의 경우라면 WBS에 의해 테스크가 분할될 것이며, 반복형 개발이라면 이터레이션 별로 구현해야 할 유저 시나리오나 성과물이 존재할 것이다.

초기에는 관리자가 필수 작업으로서의 티켓을 주로 등록하게 되지만 티켓주도 개발이 제대로 정착하게 된다면 마일스톤에 직접적으로 관련이 있는 작업들만 관리자가 등록을 하고, 이하 세부적인 티켓틀은 프로젝트 구성원들이 능동적으로 등록할 수 있게 된다. 구성원들은 자신의 업무를 등록된 티켓 안에서라는 제한적 범위이긴 하지만 스스로 정할 수 있게 되고 일정 또한 스스로 산출한다. 리팩토링이나 모델링의 수정, 테스트케이스의 추가와 같은 기술적 채무에 대한 사항들도 일정상의 여유가 없다면 미리 등록만 해 놓고 여유가 생겼을때 작업 할 수 있게 된다. 관리자 입장에서도 이슈트레커의 기능을 이용해 작업의 배치상태와 진척사항등을 빠르게 체크할 수 있고, 이에 대한 보고서 작성시간 또한 크게 단축 할 수 있다.

필자는 대부분의 프로그래머들은 배움에 대한 열망이 높고 스스로의 일에 대해 강한 책임감과 자부심을 가지고 있다고 생각한다. 경영진이나 관리자는 이들이 가진 이러한 열망을 정확하게 이해하고 해소해 줌으로서 성과급을 지불하는것 보다 훨씬 많은것을 얻을 수 있을것 이다. 

다시한번 말하지만 당근과 채찍으로 개발자를 다루려 하지 마라. 어떻게 하면 일 자체가 당근이 될 수 있을까를 고민하라. 즐겁고 쾌적하게 일할 수 있는 환경을 제공하라. 빠른 작업용PC와 맘에 드는IDE로 작업 할 수 있게 허락하라. 개발자의 개성과 선택을 존중하라. 관리자는 이에 대해 책임이 따른다는 점을 주지시키기만 하면 된다. 특히나 요즘들어 개발자들을 가장 많이 괴롭히는 보안관련 사항에 있어서도 같은 해법이 적용 가능할 것이다. 

성과급 제도와는 별도로 급여는 다른 의미에서 매우 중요한데, 바로 생산성에 직접적으로 연관이 있기 때문이다. 2011년 LGCNS의 연구원인 이강배씨가 발표한 논문 "IT 노동과 자본의 총 산출에 대한 직,간접 효과"에 의하면 IT노동자에게 지급하는 임금은 매출 증가에 직접적으로 영향을 미치며, 구체적으로 IT노동자에게 임금 1억원을 추가지급할 경우 5.55배 이상의 부가가치가 새롭게 창출된다고 한다. 이는 비IT 노동자 급여 대비 7.5배 높은 수치로 게임이나 인터넷 서비스와 같은 비제조IT산업의 경우는 1억원에 대한 추가 부가가치가 무려 8.45배에 달하는 것으로 나타났다. 생산성과 부가가치 창출이 전적으로 인적자원에 달려있는 SW산업에 있어서 이러한 결과는 어떻게 보면 당연하다고도 할 수 있다. 게다가 좋은 대우를 해 주면 회사의 평판이 저절로 올라가고, 이는 다시 좋은 인재의 채용으로 이어진다. 이것이 바로 인재 채용에 있어서의 선순환이며 IT기업 생산성 향상의 핵심열쇠이다.

자 이제 타이틀에 대한 답을 제시하는것을 이 글을 마무리 짓고자 한다.

똑똑한 프로그래머를 멍청이로 만들고 싶은가?

그럼 멍청이로 대접하라. 

아마도 회사를 그만두던지 아니면 멍청이가 될 것이다.

선순환과 악순환의 시작은 개발 작업에 대한 관점의 차이에서 시작한다.

개발을 창의적인 노동을 볼 것인가 아니면 단순 노동으로 볼 것인가?당신의 선택에 달려있다.

[출처] http://www.moreagile.net/2014/06/dontPerformance-basedsystem.html