기업(그리고 임원)이 알아야 할 개발자 동기부여의 비밀

우수한 개발자는 조직에게 여러 분명한 이득을 선사한다. 때로는 정량화하기 애매한 미묘한 이득을 안겨줄 때도 있다. 애석하게도 개발자가 역량을 십분 발휘하도록 하기란 꽤나 까다롭다. 당신이 개발자를 바라보는 시각이 문제이자 해법일 수 있다. 
 

인사 전문가들은 오래전부터 돈이 최고의 동기요인이 아니라는 사실을 알고 있었다. 연봉 외에도 오늘날 직원들은 좀더 형이상학적인 것을 중시하며, 우리는 이것을 의미라고 부른다. 

개발자들도 의미, 즉 자신의 일에 목적이 있다는 감각을 추구한다. 그러나 이를 찾는 그들만의 고유한 방식이 있으며, 이 부분은 다른 직종의 사람들에게 그리 구체적이지 않을 수 있다. 코드 개발자가 아니라면 개발 작업의 고유한 특성에 대해 이해하기 어렵다.

예를 들어, 일반적으로 생각하는 것보다 소프트웨어 개발에는 많은 창의성이 수반된다. 프로그래머는 이런 코딩의 창의적인 측면에서 동기를 부여받는다. 댄 무어가 ‘새로운 개발자들에게 보내는 편지’ 블로그에서 이야기했듯이 “신입 개발자라도 지속적으로 작은 창의적인 결정(변수 이름 결정 등)을 내리기 마련이다. 이런 부분 때문에 소프트웨어 개발이 성취감을 주고 재미있는 것이다.” 

즉 생산적 유인과 창의적 유인의 균형이 장기적인 개발자 성공의 열쇠이지만, 이는 개발자 관리 및 공급 측면에서 흔히 간과되는 요인이다.

개발자 사고방식, 즉 진정으로 동기를 부여하는 것(또는 개발자의 동기를 없애는 것)에 대한 비밀에 대한 다음의 인사이트는 IT 리더가 장기적인 개발자 성공의 열쇠인 생산적 유인과 창의적 유인의 균형을 찾는 데 도움이 될 것이다.

적절한 성과를 측정하라
Y만큼의 성과에 대해서는 X만큼을 지불하고, 잘못된 방향으로 나아가면 퇴출되는 것이 비즈니스 분야의 생리다. 하지만 결과를 정량화 하기가 매우 어렵기 때문에 코드 개발자를 이런 식으로 보는 것은 특히 위험하다. 개발자가 재사용이 가능한 방식에 관해 고민하느라 보내는 시간은 향후 예측할 수 없는 이익으로 돌아올 수 있다. 그들이 샤워 중 소프트웨어 구성요소들의 결합 방식에 관해 생각할 때 갑자기 떠오른 인사이트가 그들에게 비용을 지불하고 개발하라고 요구한 기업보다 가치가 더 클 수 있다.

다시 말해, 개발자를 그저 입력 요원으로 생각하는 것이 최악이다. 이런 이해는 완전히 잘못되었다. 요건을 달성하는 최소량의 코드가 최고이기는 하다. 정수에 가까울수록 좋은 것도 사실이다. 하지만 이런 사고방식은 개발자에게 소외감과 괴리감을 느끼게 할 것이다.

‘코드 완성’(Code Complete)이라는 저서에서 스티브 맥코넬은 WIMP(Why Isn’t Mark Programming) 원칙을 설명했다. 이것은 코딩 리더(해당 저서의 예에서는 육군 대령)가 프로그래머들이 일하고 있지 않는 것처럼 보이는 풍경을 궁금해하는 현상을 의미한다. 

물론, 이 산업은 맥코넬의 저서가 2004년에 공개된 이후로 많이 성숙했다. 이제는 다수가 소프트웨어 개발에 있어 숙고 단계의 필요성을 많이 이해하고 있다. 애자일 프로그래밍 사고방식에서는 명시적으로 디자인과 계획을 라이프사이클에 통합하고 있다. 

혁신의 가능성을 허용하라
개발자가 성과를 내도록 돕는 강력한 프로세스를 운용하는 것이 필수적이다. 하지만 이 외에도 개발자의 우수성을 향상시킬 수 있는 여지가 크다. 옥타(Okta)의 개발자 변호사 매트 라이블은 이렇게 말했다.

“배움에 대한 열정과 기회가 개발자에게 중요하다고 생각한다. 혁신을 위한 능력과 여력을 마련하는 것도 갈채를 받을 만한 일이다.”

혁신이 지시된 목표 지향적인 활동이 아니라 놀이 또는 자유 실험과 유사한 상황에서 이루어지는 경우가 많다는 점은 혁신에 관한 흥미로운 역설이다. 결국, 혁신의 여력, 사고 능력, 즉각적인 성과 이상의 것을 위한 노력이 열정을 강화한다. 열정과 혁신은 외부적인 목적보다는 아름다운 소프트웨어를 개발하여 공유하는 것 자체에 집중하는 피드백 루프 안에 존재한다.

실용적이며 심지어 혁신적인 애플리케이션은 더욱 그렇다. 외부자들이 이해하기 어려울 수 있지만 프로그래머들은 품격 있는 소프트웨어 시스템 자체에 가치가 있다고 생각하곤 한다.

하지만 모든 미덕은 균형에 있다. 개발자들은 다른 방향으로 멀리 나아갈 책임이 있지만, 기술 전문가의 전통적인 실수에 빠지고 활용성을 고려하지 않고 개발을 위한 개발을 하기도 한다.
 
비즈니스 출신의 전문가가 스스로 건전하게 운영되는 비즈니스로부터 기쁨과 만족감을 얻는 것처럼 엔지니어는 건전하게 운용되는 소프트웨어에서 그런 것을 얻는다는 것을 기억해야 한다.

창의성은 그 자체로 동기요인이다
많은 개발자들이 (아마도 대부분이) 창의성으로부터 높은 동기를 부여 받는다. 그래서 소셜 코딩(Social Coding)이 그렇게 인기를 얻고 있는 것이다. 코드 개발자들은 자신의 작업, 표현을 최종 제품뿐 아니라 내부 디자인 등 코드 자체에 관한 가치를 보고 평가할 수 있는 사람들과 공유하고 싶어한다. 마찬가지로 다른 사람들이 한 일을 보고 코드에 녹아 든 다른 사람의 독창성에 충격을 받는 것도 흐뭇한 일이다.

코딩에 대한 이런 긍정적이고 동기를 부여하는 느낌은 음악과 창작의 그것과 유사하다. 다양한 이점이 있지만 그 자체 그리고 이를 다른 사람과 공유하는 활동에 내재된 가치도 있다. 이런 노력에는 예술적인 측면도 있다고 말할 수 있다. 

솔리드JS(SolidJS)의 개발자 라이언 카니아토가 “외부인들의 눈에는 개발이 블랙박스처럼 보인다”라고 말했다. 이로 인해 입력/출력 기계로 보이기 쉽다. 그리고 개념화부터 구현에 이르는 프로세스 때문에 아이디어가 투입되면 결과가 나온다고 생각하기 쉽다.

카니아토는 “창의성에 대해 존중 받고 있다고 느끼지만, 가끔 디자인 및 구축에 투입되는 노력을 인정받지 못하는 것처럼 느껴지는 경우가 있었다. 성과가 아니라 소프트웨어를 만들고 있다는 사실을 이따금씩 상기시켜야 할 필요성도 있었다”라고 말했다.

기술 업계는 오래전부터 개발자의 창의성이 필수적이라는 점을 인정했다. 하지만 개발자와 비즈니스 사이의 격차는 여전히 존재한다. 우리는 그 창의적이고 인간적인 측면을 늘 기억해야 한다.

이런 창의적인 유인을 비즈니스 쪽으로 전달하는 데 도움이 될 수 있는 리더는 가치 있는 동기를 위해 일한다는 감각을 제공하면서 개발자의 영혼을 채워주는 가능성의 감각을 성숙시키다. 이런 리더가 개발자로부터 보기 드문 성과를 얻을 수 있을 것이다. ciokr@idg.co.kr