2008.07.24

개발자는 무엇으로 사는가

Esther Schindler | CIO

개발자를 관리하는 일은 여러 가지 측면에서 다른 직원들을 관리하는 일과 바를 바 없다. 이들은 비즈니스 문제와 기술적 문제를 해결해주고, 불필요한 사내 정치로부터 자신들을 보호해주고, 개인적인 경력 목표를 달성하는 데 도움을 줄 관리자를 원한다.

 

그러나 프로그래머에게는 보통 직원들과 다른 면이 있다. 예술가와 비슷한 창의적 기질을 가진 이들은 큰 그림을 보다가도 일순간에 극히 세세한 사항으로 사고의 차원을 전환하고, 유치한 장난감에 넋이 나가기도 하며, 야식에 혹해 야근을 자청한다. 이런 사람들을 이해하고 이들에게 동기를 부여하는 일은 관리자, 특히 기술적 배경이 없는 관리자에겐 골치 아픈 일이 될 수도 있다.

 

물론 새삼스러운 문제는 아니다. 메인프레임 시절부터 관리자들은 프로그래머에게 영감을 주기 위해 노력해 왔으며, 이젠 고전이 된 몇몇 책들의 내용은 지금도 그대로 적용된다. 예를 들어 톰 디마르코의 ‘피플웨어’는 창의적인 사람들이 혁신을 일구어내는 열정적이고 창조적인 분위기를 해치지 않도록 벨소리를 끌 수 있는 전화기를 개발자들에게 지급해야 한다고 주장한 최초의 책이다.

 

마스터 시스템즈에 자문 서비스를 제공하는 스탠 리프킨은 M. 스콧 마이어스가 1964년에 쓴 "동기가 부여된 직원은 누구인가?"라는 하버드 비즈니스 리뷰 에세이를 언급하며 "엔지니어에게 어떻게 동기를 부여할 것인가는 오래 전부터 화두였다. 이 문서의 인용 날짜를 보면 알 수 있다"고 말했다. 이 문서는 그보다 1~2년 전에 역시 HBR에 게재된 허즈버그의 선구적 에세이에 바탕을 두고 있다. 리프킨은 "우리가 던지는 질문의 대다수는 이미 연구와 자료에 의해 해답이 나와 있는 상태다. 우리는 해답을 찾는 방법만 알아내면 된다"고 말했다.

 

그러나 개발자들과 이야기를 해보면, 대부분의 관리자들은 아직 개발자를 관리할 수 있는 적절한 기술을 익히지 못한 것으로 보인다.

 

관리자가 개발자에게 동기를 부여하는 방법, 그리고 개발자를 가장 효과적으로 관리하는 방법은 당사자인 개발자들이 잘 알고 있을 것이란 생각에, 필자는 여러 온라인 커뮤니티와 소셜 네트워크 사이트에 사이트에 질문을 올렸다.

 

"개발자 관리와 동기 부여에 대해 CIO가 알아야 하는 것을 딱 하나만 꼽자면 무엇인가?"

 

실제 개발자들의 의견을 정리했다. 이 질문 자체가 스스로의 욕구를 생각하게끔 만들기 때문에 몇 가지 뜻밖의 답변들도 나왔다.

 

개발자의 업무 수행 능력을 믿어라

어떤 관리자는 개발자를 그냥 두면 스스로는 절대 코딩을 하지 않으며, 하루 종일 컴퓨터 게임이나 하면서 시간을 보낸다고 생각한다. 물론 이는 사실이 아니다. 필자의 질문에 답변을 보낸 개발자들이 관리자에 대해 갖는 1차적인 희망 사항은 자신과 팀의 능력을 인정하고, 이들의 업무 수행 능력을 믿어달라는 것이다. 한 개발자는 트위터를 통해 "나를 좀 제대로 활용해 보세요. 나는 당신이 지금 시키는 일보다 훨씬 더 많은 일을 할 수 있습니다"라고 전했다.

 

30년 개발자 경력을 가진 SQL 컨설턴트인 루디 라임백은 "모든 동기는 내부로부터 나온다"며 "개발자가 개발을 하게 해줘야 한다. 그게 바로 개발자가 사랑하는 일이기 때문"이라고 말했다.

 

관리자는 개발자가 일에서 느끼는 자부심에 호소할 수도 있다. 디지 인포메이션시스템의 일리야 프라우는 "개발자가 무슨 일을 하고 싶어하는지 알아보고, 그 일을 하게끔 해 주면 이는 결국 회사의 이익으로 돌아온다"며, "가장 동기가 강한 사람은 바로 원하는 일을 하는 사람"이라고 말했다.

 

퀵 솔루션스에서 선임 데이터베이스 컨설턴트로 일하는 브루스 린드먼은 "작업 결과의 품질에 나도 신경을 쓴다는 사실을 관리자가 이해했으면 한다"며, "나는 코드 주석에 내 이름을 덧붙인다. 작성하는 모든 스크립트나 프로시저에 ‘서명’을 하는 셈이다. 조잡한 결과물을 만들어 내거나 품질을 희생하는 것은 내가 가장 싫어하는 일"이라고 말했다.

 

개발자에게 무언가를 생각하고 만들어낼 시간과 공간도 주지 않으면서 그들에게 창의성을 요구할 수는 없다. 로터스 노츠계의 고수인 벤 풀은 "개발자들에겐 코드를 작성하는 시간 외에 생각할 시간도 필요하다"고 말했다.

 

한 언론사의 IT 책임자인 폴 다니엘슨은 "전체적으로 볼 때 개발자들은 유능한 사람들이다. 이들에게는 작업과 방법론에 대해 관리자, 특히 CIO급의 간섭을 받지 않고 스스로(동료의 도움은 어느 정도 있겠지만) 솔루션을 개발할 수 있는 여유가 필요하다. 개발자에게 작업을 할당한 후에 그 작업을 수행할 방법을 일일이 지시하는 것만큼 개발자의 의욕을 꺾는 것은 없다"고 말했다.

 

또한 관리자는 소프트웨어가 정해진 틀에 따라 만들어진다고 생각해서는 안된다. 소프트웨어 개발은 6시그마 활동이 아니다. 선임 개발자인 제임스는 "개발은 제조가 아니라 탐구"라고 강조했다.

개발자가 전체적인 그림을 볼 수 있도록 하는 것도 중요하다. 한 독자는 트위터를 통해 "되도록 많은 작업을 미리 받는 것이 좋다. 그러면 끌려가면서 일하지 않고 직접 끝까지 책임질 수 있기 때문"이라고 말했다.

 

개발자에게 개발 외적인 일을 요구하지 말 것

대부분의 개발자는 우수한 품질의 코드를 만드는 데 집중하기를 원한다. 그 외의 모든 일은 관심 밖이다.

 

많은 개발자들이 생각하는 관리자의 가장 중요한 역할은 쓸데없는 회사 일로부터 개발자를 보호하는 것이다. 개발자들은 관리자가 "사내 정치, 불필요한 회의, 서류 작업 등을 알아서 차단해주기를 원하고, 또 그렇게 해주리라 기대한다"고 라임백은 말했다.

 

차단 1순위는 마케팅 부서, 아니면 멋대로 출하 날짜를 잡는 사람들이다. 성능 담당 엔지니어인 짐 펜실은 "마케팅 부서의 시간 계획에 끌려갈수록 현실적인 판단은 멀어지고, 예정된 날짜를 넘어 연장되는 마케팅 부서 프로젝트에 계속 묶이게 된다"고 말했다.

 

어떤 개발자들은 임박한, 또는 이미 넘긴 마감 시한을 하루에도 몇 번씩 되풀이해서 말하는 관리자들에 대해 불만을 토로한다. 이들은 작업에 순서를 정해 처리하라고 지시하는 관리자들을 싫어한다. 한 독자는 트위터를 통해 "작업 우선순위를 정하고 나면, 나머진 내게 맡기면 좋겠다. 간섭은 사절이다. 내가 할 일은 나도 잘 안다"라고 썼다. 많은 개발자들은 과제를 던져준 다음에는 더 이상 사사건건 간섭하지 않는 사람들과 일할 때 가장 일이 잘 된다고 말한다.

 

듣고, 대답하고, 칭찬하라.

개발자들은 자신이 무슨 일을 하는지 상관이 꼭 이해하기를 원하지는 않지만, 상관이 의사 결정을 내리기 전에 작업에 대한 자신의 의견을 듣고 대답해 주기를 바란다. IT 전문가인 마이클 퍼매니악은 "작업자들과 가끔 대화를 나눠라. 무엇이 그들에게 동기를 부여하는지 살펴보고, 그들 수준에서 프로젝트를 완료하기 위한 조건이 무엇인지도 알아보라"며, "동기 부여는 언제든 될 수 있지만 직접 대화하지 않으면 아무것도 이해할 수 없다"고 말했다.

 

미니애폴리스의 자칭 고집불통인 제이슨 트레빌록은 "적극적으로 듣고 터놓고 말하기"를 중요한 덕목으로 꼽는다. 트레빌록은 "다행히 내가 일하는 곳의 CIO는 그런 식으로 일을 진행한다. 그러나 이는 CIO뿐 아니라 조직 전체의 모든 사람에게 적용된다. 마음을 열고 진솔하게 대화하지 않으면 여러 가지 문제에 봉착하게 될 것"이라고 말했다.

 

명확하게 표현하는 것도 중요하다. 모든 사물을 원인과 결과로 분석하려 드는 개발자들에게 모호함은 먹히지 않는다. "에둘러 말하기" 역시 도움이 안 된다. 개발자는 이런 식의 표현이 대체 무슨 뜻인지 이해하지 못한다.

 

정확한 정보 교환만이 대화의 전부는 아니다. 대화에는 개발자의 작업에 대한 피드백, 그리고 칭찬도 포함된다. 동기를 부여하고자 한다면 이 부분은 특히 더 중요하다. 한 익명의 개발자는 트위터를 통해 "나한테는 칭찬이 특효약"이라며, "부족한 부분이 있더라도 칭찬을 들어야 일할 의욕이 난다"고 밝혔다.

 

그러나 피드백이 개발자의 뛰어난 면을 부각시키기 위한 것만은 아니다. 피드백은 기대치 설정, 그리고 일관성과 공정성에 관한 개념이다. 다음은 트위터에서 받은 네 가지 응답이다. (자신의 추종자들에게 140자 미만 조건으로 응답을 받아 준 마이클 롭에게 감사를 전합니다.)

 

- 듣기만 좋고 알맹이는 없는 칭찬보다는 불쾌하더라도 일관적이고 공정한 의견이 더 낫다.

- 명확한 목표와 기대치조차 없는 상태에서도 깎아 내리기. 능력에 대한 치사한 인신 공격.

- 나를 비판하라. 그러면 나는 완벽주의 탓에 더 열심히 일할 것이다. 당연히 나는 일 중독자가 아니다.

- 나의 기술과 재능을 인정하고 이용하는 것이 나를 잘 활용하는 방법이다.

 

QA 전문가인 조 스트래지어는 CIO에게 대화의 필요성을 강조한다. 그는 "CIO의 가운데에 있는 ‘I’는 정보를 의미하지만, 근본적으로 모든 문제는 사람들의 문제다. 사람을 먼저 생각하라. 기술은 그 다음"이라고 말했다.

 

어려운 문제: 개발자에게 넉넉히 보상하라.

앞서 살펴본 이야기들은 조금만 생각하면 예상할 수 있는 응답들이다. 대부분의 개발자는 자신의 기술에 대한 가치를 인정받기를 원하고, 최선의 결과물을 내놓으리라는 믿음을 받기를 원하고, 솔직하고 유익한 피드백을 받기를 원한다. 그런데 뜻밖에도 오로지 금전적인 측면만 따지는 대답도 적지 않았다.

 

예를 들어 "개발자를 관리하고 동기를 부여하는 일과 관련해 CIO(IT 관리자)에게 한 가지만 납득시킬 수 있다면, 그 한 가지는 무엇입니까?"라는 질문에 대해 한 개발자는 돈이라는 한 글자로 답했다. 이어서 나오는 질문인 "그것을 선택한 이유는 무엇입니까?"라는 질문에 그는 "여자들이 돈을 따르니까"라고 답했다.

 

필자는 이 대답을 읽고 크게 웃었지만, 이런 의견을 보낸 개발자들은 적지 않았다. 한 사람은 "동기 부여라… 나는 돈을 받지 못한다면 손가락 하나 까딱하지 않을 것"이라고 말했다. 또 어떤 사람은 "이 일은 나만이 할 수 있다는 둥의 입에 발린 소리는 그에 상응하는 금전적 대가가 없다면 나에게 동기를 부여하지 못한다"고 말했다.

 

한 데이터베이스 관리자는 CIO에게 해당 직종에 대한 업종의 현재 대우를 살펴보고, 여기에 맞춰 직원이 만족을 느낄 수 있는 적정한 수준으로 연봉을 조정해 나가야 한다고 권고했다. 그는 "어떤 직업에서든 가장 큰 동기 부여자는 돈이다. 이 사실을 인정하고 제대로 처리하면 즐겁게 일하는 직원을 보게 될 것"이라고 덧붙였다.

 

이러한 의견을 액면 그대로 받아들여 보자. 개발자는 훈련된 전문가이며 자신의 경력과 기술에 대한 충분한 보상을 기대한다. 확실히 개발자에게 피드백을 제공하는 한 가지 방법은 (특히 그 개발자가 가장 유능한 개발자라면) 연봉 계약서를 통해 의사를 표현하는 것이다.

 

물론 돈이 전부는 아니다. 모든 사람들에게는 저마다 "아무리 돈을 많이 줘도 그 짓은 못한다"고 생각하는 직종이 있는 반면, 금전적 보상은 비교적 낮아도 저 일이라면 무척 만족하리라고 생각하는 직종도 있다. 필자가 내린 다소 이상주의적인 결론이 틀릴지도 모르겠지만, 개인적으로는 올바른 결론이라고 생각한다. 보수는 높지만 장래성이 없는 직업과 보수는 좀 낮지만 자부심과 성취감을 이끌어내는 보람 있는 일 사이에서 선택권이 주어질 경우, 많은 개발자들이 전자를 선택하리라고는 믿기 어렵다.

 

돈만 따지는 대답에 대한 필자의 해석은 대부분의 개발자들이 정말로 자신에게 동기를 부여하는 요소가 무엇인지 잘 모른다는 것이다. 관리자 입장에서 이는 부하 직원들을 집단이 아닌 각 개인으로서 판단해야 함을 의미한다. "돈"이라는 대답이 쉬운 이유는 돈을 싫어하는 사람은 없기 때문이다.

 

모든 개발자가 자기 자신에 대해 깊이 생각하지는 않는다. 팀 관리에 친화적인 성격이 아닌 한, 개발자들은 자신에게 동기를 부여하기 위해 상관이 어떤 일을 할 수 있는지 따위에 대해서는 별로 생각하지 않는다. 결국 그런 생각은 관리자 자신이 해야 한다. 질문에 답변을 한 개발자들은 자신이 원하는 바를 잘 아는 개발자들이므로 이러한 조언을 참고하면 도움이 될 것이다.

 

가장 적절한 비유

피플소프트 기술 전문가인 데이터베이스 관리자 팻 펠런은 훌륭한 IT 직원을 고양이로 생각하는 방법이 도움이 된다고 말한다. 그는 "잘 보살펴주면서 가끔 특별 보상도 해주고 공정하게 규율을 적용하면 아무 문제없다. 가끔 한두 가지를 신경 쓰지 못하는 정도라면 그럭저럭 받아들인다. 그러나 이러한 조건 중 어느 한 가지라도 지속적으로 신경을 쓰지 않는다면 이들은 더 나은 기회를 찾아 길을 떠날 것"이라고 말했다.

 

개발자들을 관리하는 일은 여러 마리의 고양이를 키우는 일과 비슷하다. 펠런은 이 경우에도 사람이나 고양이나 똑같다고 말한다. 예를 들어 고양이 한 마리만 세세하게 관리해서는 안된다. 이 경우 고양이도, 고양이 주인도 모두 피곤해진다. 펠런은 "당신이 원하는 바를 고양이가 이해하도록 하라. 고양이를 어느 정도 잘 돌봐주면 종종 생각지도 못한 방식으로 뜻밖의 즐거움을 안겨준다"고 말했다.

 

반대로 고양이를 이해하기 위한 노력은 학구적인 의미는 있을지언정 실질적 도움은 거의 되지 않는다. 결국 고양이는 자기가 원하는 행동을 한다. 펠런은 고양이에게 먹이를 과하게 주거나 모자라게 주는 것은 적절치 않다며 "먹이를 많이 주면 게을러지고 적게 주면 성격이 사나워진다. 각 고양이마다 적절한 선을 찾아라. 잘 대해주되 가끔 주어지는 특별 보상이 효과를 발휘할 여지를 남겨둬야 한다. 이러한 보상은 어떤 행동의 대가로 주어지기도 하고, 가끔은 ‘그냥’ 주어지기도 한다"고 말했다.

 

펠런은 고양이를 괴롭히지 말라고 당부했다. 고양이는 주인이 생각지도 못한 방식으로 앙갚음을 한다. 또한 고양이는 놀이를 통해 많은 부분을 학습한다는 점도 중요하다. 따라서 항상 놀 시간을 남겨주도록 노력해야 한다. 운동도 좋고 공동체 의식을 높이기 위한 활동도 좋다. 이러한 노력을 통해 바람직한 행동 습관을 가진 고양이를 길러낼 수 있다.



2008.07.24

개발자는 무엇으로 사는가

Esther Schindler | CIO

개발자를 관리하는 일은 여러 가지 측면에서 다른 직원들을 관리하는 일과 바를 바 없다. 이들은 비즈니스 문제와 기술적 문제를 해결해주고, 불필요한 사내 정치로부터 자신들을 보호해주고, 개인적인 경력 목표를 달성하는 데 도움을 줄 관리자를 원한다.

 

그러나 프로그래머에게는 보통 직원들과 다른 면이 있다. 예술가와 비슷한 창의적 기질을 가진 이들은 큰 그림을 보다가도 일순간에 극히 세세한 사항으로 사고의 차원을 전환하고, 유치한 장난감에 넋이 나가기도 하며, 야식에 혹해 야근을 자청한다. 이런 사람들을 이해하고 이들에게 동기를 부여하는 일은 관리자, 특히 기술적 배경이 없는 관리자에겐 골치 아픈 일이 될 수도 있다.

 

물론 새삼스러운 문제는 아니다. 메인프레임 시절부터 관리자들은 프로그래머에게 영감을 주기 위해 노력해 왔으며, 이젠 고전이 된 몇몇 책들의 내용은 지금도 그대로 적용된다. 예를 들어 톰 디마르코의 ‘피플웨어’는 창의적인 사람들이 혁신을 일구어내는 열정적이고 창조적인 분위기를 해치지 않도록 벨소리를 끌 수 있는 전화기를 개발자들에게 지급해야 한다고 주장한 최초의 책이다.

 

마스터 시스템즈에 자문 서비스를 제공하는 스탠 리프킨은 M. 스콧 마이어스가 1964년에 쓴 "동기가 부여된 직원은 누구인가?"라는 하버드 비즈니스 리뷰 에세이를 언급하며 "엔지니어에게 어떻게 동기를 부여할 것인가는 오래 전부터 화두였다. 이 문서의 인용 날짜를 보면 알 수 있다"고 말했다. 이 문서는 그보다 1~2년 전에 역시 HBR에 게재된 허즈버그의 선구적 에세이에 바탕을 두고 있다. 리프킨은 "우리가 던지는 질문의 대다수는 이미 연구와 자료에 의해 해답이 나와 있는 상태다. 우리는 해답을 찾는 방법만 알아내면 된다"고 말했다.

 

그러나 개발자들과 이야기를 해보면, 대부분의 관리자들은 아직 개발자를 관리할 수 있는 적절한 기술을 익히지 못한 것으로 보인다.

 

관리자가 개발자에게 동기를 부여하는 방법, 그리고 개발자를 가장 효과적으로 관리하는 방법은 당사자인 개발자들이 잘 알고 있을 것이란 생각에, 필자는 여러 온라인 커뮤니티와 소셜 네트워크 사이트에 사이트에 질문을 올렸다.

 

"개발자 관리와 동기 부여에 대해 CIO가 알아야 하는 것을 딱 하나만 꼽자면 무엇인가?"

 

실제 개발자들의 의견을 정리했다. 이 질문 자체가 스스로의 욕구를 생각하게끔 만들기 때문에 몇 가지 뜻밖의 답변들도 나왔다.

 

개발자의 업무 수행 능력을 믿어라

어떤 관리자는 개발자를 그냥 두면 스스로는 절대 코딩을 하지 않으며, 하루 종일 컴퓨터 게임이나 하면서 시간을 보낸다고 생각한다. 물론 이는 사실이 아니다. 필자의 질문에 답변을 보낸 개발자들이 관리자에 대해 갖는 1차적인 희망 사항은 자신과 팀의 능력을 인정하고, 이들의 업무 수행 능력을 믿어달라는 것이다. 한 개발자는 트위터를 통해 "나를 좀 제대로 활용해 보세요. 나는 당신이 지금 시키는 일보다 훨씬 더 많은 일을 할 수 있습니다"라고 전했다.

 

30년 개발자 경력을 가진 SQL 컨설턴트인 루디 라임백은 "모든 동기는 내부로부터 나온다"며 "개발자가 개발을 하게 해줘야 한다. 그게 바로 개발자가 사랑하는 일이기 때문"이라고 말했다.

 

관리자는 개발자가 일에서 느끼는 자부심에 호소할 수도 있다. 디지 인포메이션시스템의 일리야 프라우는 "개발자가 무슨 일을 하고 싶어하는지 알아보고, 그 일을 하게끔 해 주면 이는 결국 회사의 이익으로 돌아온다"며, "가장 동기가 강한 사람은 바로 원하는 일을 하는 사람"이라고 말했다.

 

퀵 솔루션스에서 선임 데이터베이스 컨설턴트로 일하는 브루스 린드먼은 "작업 결과의 품질에 나도 신경을 쓴다는 사실을 관리자가 이해했으면 한다"며, "나는 코드 주석에 내 이름을 덧붙인다. 작성하는 모든 스크립트나 프로시저에 ‘서명’을 하는 셈이다. 조잡한 결과물을 만들어 내거나 품질을 희생하는 것은 내가 가장 싫어하는 일"이라고 말했다.

 

개발자에게 무언가를 생각하고 만들어낼 시간과 공간도 주지 않으면서 그들에게 창의성을 요구할 수는 없다. 로터스 노츠계의 고수인 벤 풀은 "개발자들에겐 코드를 작성하는 시간 외에 생각할 시간도 필요하다"고 말했다.

 

한 언론사의 IT 책임자인 폴 다니엘슨은 "전체적으로 볼 때 개발자들은 유능한 사람들이다. 이들에게는 작업과 방법론에 대해 관리자, 특히 CIO급의 간섭을 받지 않고 스스로(동료의 도움은 어느 정도 있겠지만) 솔루션을 개발할 수 있는 여유가 필요하다. 개발자에게 작업을 할당한 후에 그 작업을 수행할 방법을 일일이 지시하는 것만큼 개발자의 의욕을 꺾는 것은 없다"고 말했다.

 

또한 관리자는 소프트웨어가 정해진 틀에 따라 만들어진다고 생각해서는 안된다. 소프트웨어 개발은 6시그마 활동이 아니다. 선임 개발자인 제임스는 "개발은 제조가 아니라 탐구"라고 강조했다.

개발자가 전체적인 그림을 볼 수 있도록 하는 것도 중요하다. 한 독자는 트위터를 통해 "되도록 많은 작업을 미리 받는 것이 좋다. 그러면 끌려가면서 일하지 않고 직접 끝까지 책임질 수 있기 때문"이라고 말했다.

 

개발자에게 개발 외적인 일을 요구하지 말 것

대부분의 개발자는 우수한 품질의 코드를 만드는 데 집중하기를 원한다. 그 외의 모든 일은 관심 밖이다.

 

많은 개발자들이 생각하는 관리자의 가장 중요한 역할은 쓸데없는 회사 일로부터 개발자를 보호하는 것이다. 개발자들은 관리자가 "사내 정치, 불필요한 회의, 서류 작업 등을 알아서 차단해주기를 원하고, 또 그렇게 해주리라 기대한다"고 라임백은 말했다.

 

차단 1순위는 마케팅 부서, 아니면 멋대로 출하 날짜를 잡는 사람들이다. 성능 담당 엔지니어인 짐 펜실은 "마케팅 부서의 시간 계획에 끌려갈수록 현실적인 판단은 멀어지고, 예정된 날짜를 넘어 연장되는 마케팅 부서 프로젝트에 계속 묶이게 된다"고 말했다.

 

어떤 개발자들은 임박한, 또는 이미 넘긴 마감 시한을 하루에도 몇 번씩 되풀이해서 말하는 관리자들에 대해 불만을 토로한다. 이들은 작업에 순서를 정해 처리하라고 지시하는 관리자들을 싫어한다. 한 독자는 트위터를 통해 "작업 우선순위를 정하고 나면, 나머진 내게 맡기면 좋겠다. 간섭은 사절이다. 내가 할 일은 나도 잘 안다"라고 썼다. 많은 개발자들은 과제를 던져준 다음에는 더 이상 사사건건 간섭하지 않는 사람들과 일할 때 가장 일이 잘 된다고 말한다.

 

듣고, 대답하고, 칭찬하라.

개발자들은 자신이 무슨 일을 하는지 상관이 꼭 이해하기를 원하지는 않지만, 상관이 의사 결정을 내리기 전에 작업에 대한 자신의 의견을 듣고 대답해 주기를 바란다. IT 전문가인 마이클 퍼매니악은 "작업자들과 가끔 대화를 나눠라. 무엇이 그들에게 동기를 부여하는지 살펴보고, 그들 수준에서 프로젝트를 완료하기 위한 조건이 무엇인지도 알아보라"며, "동기 부여는 언제든 될 수 있지만 직접 대화하지 않으면 아무것도 이해할 수 없다"고 말했다.

 

미니애폴리스의 자칭 고집불통인 제이슨 트레빌록은 "적극적으로 듣고 터놓고 말하기"를 중요한 덕목으로 꼽는다. 트레빌록은 "다행히 내가 일하는 곳의 CIO는 그런 식으로 일을 진행한다. 그러나 이는 CIO뿐 아니라 조직 전체의 모든 사람에게 적용된다. 마음을 열고 진솔하게 대화하지 않으면 여러 가지 문제에 봉착하게 될 것"이라고 말했다.

 

명확하게 표현하는 것도 중요하다. 모든 사물을 원인과 결과로 분석하려 드는 개발자들에게 모호함은 먹히지 않는다. "에둘러 말하기" 역시 도움이 안 된다. 개발자는 이런 식의 표현이 대체 무슨 뜻인지 이해하지 못한다.

 

정확한 정보 교환만이 대화의 전부는 아니다. 대화에는 개발자의 작업에 대한 피드백, 그리고 칭찬도 포함된다. 동기를 부여하고자 한다면 이 부분은 특히 더 중요하다. 한 익명의 개발자는 트위터를 통해 "나한테는 칭찬이 특효약"이라며, "부족한 부분이 있더라도 칭찬을 들어야 일할 의욕이 난다"고 밝혔다.

 

그러나 피드백이 개발자의 뛰어난 면을 부각시키기 위한 것만은 아니다. 피드백은 기대치 설정, 그리고 일관성과 공정성에 관한 개념이다. 다음은 트위터에서 받은 네 가지 응답이다. (자신의 추종자들에게 140자 미만 조건으로 응답을 받아 준 마이클 롭에게 감사를 전합니다.)

 

- 듣기만 좋고 알맹이는 없는 칭찬보다는 불쾌하더라도 일관적이고 공정한 의견이 더 낫다.

- 명확한 목표와 기대치조차 없는 상태에서도 깎아 내리기. 능력에 대한 치사한 인신 공격.

- 나를 비판하라. 그러면 나는 완벽주의 탓에 더 열심히 일할 것이다. 당연히 나는 일 중독자가 아니다.

- 나의 기술과 재능을 인정하고 이용하는 것이 나를 잘 활용하는 방법이다.

 

QA 전문가인 조 스트래지어는 CIO에게 대화의 필요성을 강조한다. 그는 "CIO의 가운데에 있는 ‘I’는 정보를 의미하지만, 근본적으로 모든 문제는 사람들의 문제다. 사람을 먼저 생각하라. 기술은 그 다음"이라고 말했다.

 

어려운 문제: 개발자에게 넉넉히 보상하라.

앞서 살펴본 이야기들은 조금만 생각하면 예상할 수 있는 응답들이다. 대부분의 개발자는 자신의 기술에 대한 가치를 인정받기를 원하고, 최선의 결과물을 내놓으리라는 믿음을 받기를 원하고, 솔직하고 유익한 피드백을 받기를 원한다. 그런데 뜻밖에도 오로지 금전적인 측면만 따지는 대답도 적지 않았다.

 

예를 들어 "개발자를 관리하고 동기를 부여하는 일과 관련해 CIO(IT 관리자)에게 한 가지만 납득시킬 수 있다면, 그 한 가지는 무엇입니까?"라는 질문에 대해 한 개발자는 돈이라는 한 글자로 답했다. 이어서 나오는 질문인 "그것을 선택한 이유는 무엇입니까?"라는 질문에 그는 "여자들이 돈을 따르니까"라고 답했다.

 

필자는 이 대답을 읽고 크게 웃었지만, 이런 의견을 보낸 개발자들은 적지 않았다. 한 사람은 "동기 부여라… 나는 돈을 받지 못한다면 손가락 하나 까딱하지 않을 것"이라고 말했다. 또 어떤 사람은 "이 일은 나만이 할 수 있다는 둥의 입에 발린 소리는 그에 상응하는 금전적 대가가 없다면 나에게 동기를 부여하지 못한다"고 말했다.

 

한 데이터베이스 관리자는 CIO에게 해당 직종에 대한 업종의 현재 대우를 살펴보고, 여기에 맞춰 직원이 만족을 느낄 수 있는 적정한 수준으로 연봉을 조정해 나가야 한다고 권고했다. 그는 "어떤 직업에서든 가장 큰 동기 부여자는 돈이다. 이 사실을 인정하고 제대로 처리하면 즐겁게 일하는 직원을 보게 될 것"이라고 덧붙였다.

 

이러한 의견을 액면 그대로 받아들여 보자. 개발자는 훈련된 전문가이며 자신의 경력과 기술에 대한 충분한 보상을 기대한다. 확실히 개발자에게 피드백을 제공하는 한 가지 방법은 (특히 그 개발자가 가장 유능한 개발자라면) 연봉 계약서를 통해 의사를 표현하는 것이다.

 

물론 돈이 전부는 아니다. 모든 사람들에게는 저마다 "아무리 돈을 많이 줘도 그 짓은 못한다"고 생각하는 직종이 있는 반면, 금전적 보상은 비교적 낮아도 저 일이라면 무척 만족하리라고 생각하는 직종도 있다. 필자가 내린 다소 이상주의적인 결론이 틀릴지도 모르겠지만, 개인적으로는 올바른 결론이라고 생각한다. 보수는 높지만 장래성이 없는 직업과 보수는 좀 낮지만 자부심과 성취감을 이끌어내는 보람 있는 일 사이에서 선택권이 주어질 경우, 많은 개발자들이 전자를 선택하리라고는 믿기 어렵다.

 

돈만 따지는 대답에 대한 필자의 해석은 대부분의 개발자들이 정말로 자신에게 동기를 부여하는 요소가 무엇인지 잘 모른다는 것이다. 관리자 입장에서 이는 부하 직원들을 집단이 아닌 각 개인으로서 판단해야 함을 의미한다. "돈"이라는 대답이 쉬운 이유는 돈을 싫어하는 사람은 없기 때문이다.

 

모든 개발자가 자기 자신에 대해 깊이 생각하지는 않는다. 팀 관리에 친화적인 성격이 아닌 한, 개발자들은 자신에게 동기를 부여하기 위해 상관이 어떤 일을 할 수 있는지 따위에 대해서는 별로 생각하지 않는다. 결국 그런 생각은 관리자 자신이 해야 한다. 질문에 답변을 한 개발자들은 자신이 원하는 바를 잘 아는 개발자들이므로 이러한 조언을 참고하면 도움이 될 것이다.

 

가장 적절한 비유

피플소프트 기술 전문가인 데이터베이스 관리자 팻 펠런은 훌륭한 IT 직원을 고양이로 생각하는 방법이 도움이 된다고 말한다. 그는 "잘 보살펴주면서 가끔 특별 보상도 해주고 공정하게 규율을 적용하면 아무 문제없다. 가끔 한두 가지를 신경 쓰지 못하는 정도라면 그럭저럭 받아들인다. 그러나 이러한 조건 중 어느 한 가지라도 지속적으로 신경을 쓰지 않는다면 이들은 더 나은 기회를 찾아 길을 떠날 것"이라고 말했다.

 

개발자들을 관리하는 일은 여러 마리의 고양이를 키우는 일과 비슷하다. 펠런은 이 경우에도 사람이나 고양이나 똑같다고 말한다. 예를 들어 고양이 한 마리만 세세하게 관리해서는 안된다. 이 경우 고양이도, 고양이 주인도 모두 피곤해진다. 펠런은 "당신이 원하는 바를 고양이가 이해하도록 하라. 고양이를 어느 정도 잘 돌봐주면 종종 생각지도 못한 방식으로 뜻밖의 즐거움을 안겨준다"고 말했다.

 

반대로 고양이를 이해하기 위한 노력은 학구적인 의미는 있을지언정 실질적 도움은 거의 되지 않는다. 결국 고양이는 자기가 원하는 행동을 한다. 펠런은 고양이에게 먹이를 과하게 주거나 모자라게 주는 것은 적절치 않다며 "먹이를 많이 주면 게을러지고 적게 주면 성격이 사나워진다. 각 고양이마다 적절한 선을 찾아라. 잘 대해주되 가끔 주어지는 특별 보상이 효과를 발휘할 여지를 남겨둬야 한다. 이러한 보상은 어떤 행동의 대가로 주어지기도 하고, 가끔은 ‘그냥’ 주어지기도 한다"고 말했다.

 

펠런은 고양이를 괴롭히지 말라고 당부했다. 고양이는 주인이 생각지도 못한 방식으로 앙갚음을 한다. 또한 고양이는 놀이를 통해 많은 부분을 학습한다는 점도 중요하다. 따라서 항상 놀 시간을 남겨주도록 노력해야 한다. 운동도 좋고 공동체 의식을 높이기 위한 활동도 좋다. 이러한 노력을 통해 바람직한 행동 습관을 가진 고양이를 길러낼 수 있다.



X