개발자를 위한 바람직한 리더의 스타일

하버드 비즈니스 리뷰에 따르면 리더십에 6가지 스타일이 있다고 한다. 명령형(commanding), 비전제시형(visionary), 관계중심형(affiliative), 민주주의형(democratic), 날따라해... 형(pacesetting), 그리고 코치형(coaching)이 그들이다. 애매한 느낌이 드는 것도 있지만 일단 구분 자체는 재밌다.

리더십 포지션에 있는 사람들은 대부분 자신을 민주주의형이라고 믿는다. 확인해 볼 것도 없다. 착각은 자유이기 때문에 99%의 리더는 자기가 원하는대로 착각을 한다. 하지만 그를 위해서 일하는 사람에게 물어보면 실제로는 그가 명령형이거나 날따라해 스타일이라고 말할 확률이 높다. 골먼의 구분에 따르면 명령형과 날따라해 스타일은 근무환경에 해를 끼치는 나쁜 스타일이다.

우선 명령형은 폭군이다. 그는 자기애가 넘치기 때문에 하찮은(?) 부하들을 생각할 겨를이 없다. 부하직원은 자신이 원하는 결과를 생산하기 위한 부속물이며, 달걀을 낳는 암탉이다. 욕망의 속도는 언제나 실제 작업속도보다 빠르기 때문에 그는 불만과 분노를 억누르지 못한다. 그와의 대화는 "왜 내가 시키는데로 하지 않았지?"로 시작해서 "내가 시키는데로 해"로 끝난다. 그의 불만은 종종 지독한 마이크로관리로 흐르고, 직원들의 사기는 바닥이 보이지 않는 씽크홀로 빨려들어간다. 골먼에 의하면 폭군 스타일의 관리가 필요한 시점은 지극히 예외적인 위기상황밖에 없다.

날따라해... 스타일은 우리에게 낯설지 않다. 우린 그런 대통령을 경험한 적이 있다. 이런 리더와의 대화는 "내가 해봐서 아는데..."로 시작해서 "그렇게 밖에 못하나?"로 끝난다. 이 스타일이 흥미로운 점은 실제로 리더십 포지션에 있는 사람들이 대부분 "내가 해봐서 아는데..."를 발언한다는 점이다. 단어의 선택이나 배치는 달라도 의미는 동일하다.

6가지 리더십 스타일

이런 리더는 사무실이나 회식자리에서 자기 과시를 멈추지 않아서 부하들을 지치게 한다. 아부에 쉽게 흔들리고 실패한 프로젝트의 책임을 일말의 고민없이 부하에게 씌운다. 성공의 결과를 독식하는건 물론이다. 자기보다 실력이 좋은 것처럼 보이는 부하직원을 시기하고 견제하는 치졸함은 보너스다.

골먼은 관계중심형이 근무환경에 긍정적인 영향을 준다고 분류했는데 아마 생산성이라는 측면에서 보면 하위권에 속하는 스타일일 확률이 높다. 소프트웨어 개발 프로젝트를 예를 들면 이런 리더는 코딩을 할 줄 모르거나 코딩실력이 부족한 상태에서 직원들의 인간관계, 심리상태, 동기부여 등에 집중한다. 얼마 전에 내가 리더와 치어리더를 언급하면서 치어리더로 분류한 사람들이 속하는 범주다.

직원들의 심리와 사기에 좋은 영향을 준다는 점에서는 바람직하지만, 기술적으로 어려운 결정을 잘못 내리거나 스스로 내리지 못하는 방식으로 개발자들에게 스트레스를 주기도 한다. 이런 리더가 자기 역할을 제대로 수행하려면 기술적인 의사결정을 공식적으로 다른 사람에게 맡겨야 한다. 미국에서는 이런 사람을 피플매니저(people manager)라고 불러서 기술적 판단과 관리를 동시에 수행하는 테크니컬매니저(technical manager)와 구분한다. 한국의 IT 업계에서는 이런 구분이 명확하지 않아서 테크니컬매니저가 실질적으로는 피플매니저의 역할을 수행하는 일이 많은 것 같다.

골먼이 구분한 6개의 스타일 중에서 테크니컬매니저에게 가장 적합한 스타일은 코치형이고, CTO급 인사에게 어울리는 스타일은 비전제시형이다. 개발자에게 가장 바람직한 스타일을 꼽자면 이 둘을 말할 수 있다. 우선 테크니컬매니저가 되면 실제로 코딩을 하는 시간은 줄어든다. 아예 없을수도 있다.

하지만 팀원에게 기술적인 도움을 주고, 자기계발을 지도해 주고, 기술적으로 어려운 문제를 스스로 해결하고, 그러면서 동시에 모두를 하나의 팀으로 묶어서 이끌어가려면 기술적인 깊이가 필수적이다. 지금은 속도가 조금 느려졌다고 해도, 한때 손가락이 키보드 위를 날아다니던 전성기를 가지고 있어야 한다는 뜻이다. 기술의 현대적 흐름에도 밝아야 한다. 테크니컬매니저가 보유해야 하는 이런 능력을 "내가 해봐서 아는데..."라는 자기과시와 혼동하면 대단히 곤란하다.

하나의 팀을 이끄는 리더에서 하나의 그룹을 이끄는, 예컨대 더 높은 자리에 올라가는 사람이 되면 그에 따라 스타일도 변할 필요가 있다. 그룹을 이끄는 사람이 코치형에 머무르면 그것도 문제다.

그룹의 장은 부하직원을 코칭하는 것이 아니라 그룹 전체를 향해 비전을 제시해야 한다. 비전을 제시하는 일은 어쩔수 없이 기술적인 디테일과 거리를 갖는다. 그렇다고 해서 기술적인 디테일과 동떨어진 뜬구름은 아니다.

비전은 허공에서 뽑아내는 솜사탕이 아니다. 개발자들이 IDE에서 코딩을 하거나 디버깅을 할 때 투입하는 정성의 10배, 100배에 달하는 치열한 노력을 요구한다. 끊임없이 고민하고, 집중하고, 정보를 취합하고, 분석하고, 판단하고, 실수하고, 수정하는 과정을 거치면서 최종적으로 뽑아내는 엑기스다. 엄청난 노력과 무거운 책임을 수반하기 때문에 아무나 감당할 수 없다. 그래서 그런 자리에 올라갈 재능과 능력을 가진 그릇이 있고, 그렇지 않은 그릇이 있다. 그릇이 되는 사람이 자리에 올라가면 엄청난 결과를 내지만, 그릇이 되지 않는 사람이 자리에 올라가면 재앙이 시작된다. 인사가 만사라는 말이 있는 이유다.

골먼의 구분을 소재로 삼아 여러 가지 리더십 스타일을 이야기해 보았다. 그렇지만 내가 보기에 개발자 세상에서 리더의 조건은 실력과 예의다. 두 개만 있으면 된다. 두 개 중에서 하나만 부족해도 그 사람은 리더의 자리에 있으면 안 된다. 그리고 두 개를 모두 가진 리더는 골먼의 스타일 구분이 필요없다. 실력과 예의를 갖춘 리더는 언제 폭군처럼 굴어야 하고, 언제 비전을 제시하고, 언제 민주적으로 행동해야 하는지 스스로 알기 때문이다. 리더의 실력은 그런 거다. 스타일이 아니다.

*본 칼럼 내용은 본지 편집방향과 다를 수 있습니다.