똑똑한 프로그래머를 멍청이로 만드는 방법

知之者는 不如好之者요, 好之者는 不如樂之者니라. 
지지자는 불여호지자요, 호지자는 불여락지자니라.
알기만 하는 사람은 좋아하는 사람만 못하고,좋아하는 사람은 즐기는 사람보다 못하다.
천재는 노력하는사람을 이길수없고, 노력하는사람은 즐기는자를 이길수없다.
- <논어(論語)> 옹야편(雍也篇) -

한국사회의 오래된 논의중 한가지는 인재가 우수하기로는 둘째가라면 서러운 대한민국에서 왜 과학기술 분야의 노벨상 수상자가 나오지 않는가 이다. 이 논의에서 주범으로 지목되는것은 입시 위주의 교육인데, 어려서 부터 부모의 기대에 부응하기 위한 수단으로서 의 공부는 결국 좋은 성적을 거둬 좋은 대학, 좋은 직장에 취직하는것을 이루기 위한 수단일 뿐 목적이 될 수 없다. 하지만 인류의 지성이 아직 발견하지 못한 새로운 과학적 사실을 발견하기 위해서는 단순히 '열심히'만으로는 부족하다. 온 정신을 내 던지는 몰입이 이뤄질 수 없기 때문이다. 몰입적 사고를 주장하는 황농문 교수의 책 '몰입'에서도 비슷한 이야기가 나온다. '몰입'에서는 인생의 나머지 모든것들이 시시하게 느껴질 정도의 순수한 지적 활동이 가져오는 쾌락에 대해서 상세히 언급되고 있으며, 순수한 '앎'에 대한 열정만이 자신의 한계를 넘어서 새로운 발견을 이끌어내는 원동력이 될 수 있다고 서술하고 있다. 즉, 한계를 넘어서는 무엇인가를 하게 만드는것은 그 행위 자체가 가져오는 기쁨을 포함하지 않으면 안된다. 마치 즐기는 자를 노력하는자가 이길 수 없다고 하는 말 처럼 말이다.

뉴턴과 아인슈타인의 공통점은 ‘몰입’

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

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

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

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

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

인센티브는 동기 부여에 도움이 될까?
결론부터 말하자면 일의 성격에 따라 도움이 될 수도, 그 반대가 될 수도 있다.

Candle problem
현대 심리학계에 지대한 공을 세운 인물중 한명인 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)'에 소개된 내용이다.

차등 보상이 실패하는 논리적 이유

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

우수성과자의 경우

우수성과자는 이미 98점을 획득한 학생에 비유 할 수 있다. 즉, 성과를 더 높일만한 여지가 없다. 따라서 차등 보상은 우수성과자의 성과를 더 높이지 못한다. 

저성과자의 경우

영향을 미치지 않거나 부정적인 영향을 미친다.우수성과만 인정받는 상황에서 저성과자는 차등 보상 프로그램에서 소외된다. 이들 입장에서 차등보상 프로그램은 그들만의 리그로 인식되며 자신이 얼마나 인정받지 못하는지, 또 얼마나 상대적 박탈감을 느끼고 있는지 확인시켜 줄 뿐이므로 결과적으로 이들의 동기는 더 떨어진다. 따라서 차등보상은 저성과자의 성과를 끌어올리지 못한다. 

중간성과자의 경우 

부정적인 영향을 미친다. 평가가 진행되는 동안에는 중간성과자 중 많은 이들이 '당근'을 받기 위해 자발적으로 노력한다. 하지만 위에서 살펴봤듯이 당근의 대부분은 우수성과자에게 돌아가므로, 심리학적으로 당근을 못 받은 중간성과자는 '외 받지도 못할 당근을 위해 애써야 하지?'라고 생각하며 태도를 바꾼다. 자발적으로 노력하려 하지 않고 차등 보상 프로그램 실시 전에 비해 동기가 더 떨어지는 것이다. 따라서 차등 보상은 중간성과자의 성과를 높이지 못한다.

필자의 경우 성과주의도입을 직접 주도해 본 경험이 있다. 처음엔 대부분의 직원들은 성과주의 도입에 찬성했다. 자신이 주변 동료들보다 낮은 평가를 받을리 없다고 생각했기 때문이다. 평가가 끝난후엔 어떻게 되었을까? 낮은 평가를 받은 사람은 평가를 올리기 위해 노력했을까? 아니다. 그들의 노력은 관리자의 무능력을 공격하고 고성과자의 성과를 깎아 내리기 위해 사용되었다. 모든것이 폴 마르시아의 증명대로였다.

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

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

내가 프로젝트의 주인이다

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

능동적 개발을 가능하게 해 주는 티켓주도 개발 

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

티켓주도 개발

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

티켓 주도 개발은 비록 제한적이기는 하나 개발자들이 주어진 환경 속 에서 최대한 자율적으로 일 할 수 있게 도와 준다.

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

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

급여향상은 생산성 향상의 열쇠

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

빠른 개발이 가져다주는 선순환에 대하여 by Randy Shoup

결론

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

똑똑한 프로그래머를 멍청이로 만들고 싶은가?
그럼 멍청이로 대접하라. 
아마도 회사를 그만두던지 아니면 멍청이가 될 것이다.

선순환과 악순환의 시작은 개발 작업에 대한 관점의 차이에서 시작한다.
개발을 창조적인 작업으로 볼 것인가 아니면 단순 노동으로 볼 것인가?
당신의 선택에 달려있다.

참고자료

착각하는 CEO (유정식 저, 2013)

Dan Pink: The puzzle of motivation
Candle Problem
마음대로 해봐. 대신 책임져
'IT 엑소더스' 청년이 사라진 SW 업계