매니저와 백업 프로그래머

매니저는 프로그래머가 아니다.

일반적으로 매니저는 사람과의 관계를 통해서, 혹은 lead를 통해서 일을 해 나가야 한다.
작업을 통해서가 아니라.

프로그래머에게 어떤 프로젝트의 관리를 하라고 하면,
프로그래머는 그 프로젝트를 분석하고 해부하고, 프로그램과 아키텍트에 대해서 많은 것을 알려고 노력한다.
프로그래머는 자신을 전문가라고 생각하기 때문에 어떤 질문이 왔을 때,
그것에 대한 답변을 잘 하지 못하면, 자존심에 스크래치를 입는다.
따라서 자신이 관계된 혹은 매니저가 된 프로젝트에 대해서 모든 것을 알 때 까지 멈추지 못한다.
자신이 "상관"이 되었으면, 자신보다 "아래"에 있는 사람을 압도할 정도의 지식이 없으면 어떻게 그들에게 당당히 지시를 내릴 수 있단 말인가?
...
라고 생각하는 것이 매니저가 된 프로그래머의 생각 방식인 것 같다.

그 결과로 이 매니저는 프로젝트의 몇 사람이 갑자기 빠져도, 프로젝트를 유지 시킬 수 있는 "백업 프로그래머"가 되고, 프로젝트 인계자가 된다.

물론, 상황에 따라서는 프로젝트를 맡긴 사람이 원한 것이 이것일 수도 있다.
정신나간 관리자가 프로그래머에게 "니가 저 프로젝트 관리해야 돼. 그러니까 백업 프로그래머가 되도록 해" 라고 시킨 것일 수 있으니 말이다.
내가 보기에는 이런 무능한 사람이 시니어 관리자인 경우도 흔히 볼 수 있다고 생각한다.

하지만, 일반적으로 프로그래머에서 관리자를 맡게 된 사람이 가장 먼저 알아야 하는 것은,
자신이 앞으로는 "관리"업무를 하게 된다는 것이다.
관리 업무는 직접적으로 무언가를 생산해 내는 것이 아니라, 생산 업무가 원활하게 이루어 지도록 관리하는 것이 업무이다.

컴퓨터와 사람으로 구성 된 소프트웨어 개발 환경에서 관리자가 할 일은,
컴퓨터와 사람을 관리하는 것이다.

대부분 컴퓨터는 잘 고장나거나 하지 않으므로, 90%는 사람을 관리하는 것일테다.
나머지는 코드 백업이 잘 되고 있는지, 서버가 불안정 하지는 않은지 같은 잡무와, 현황을 파악해서 궁금해 하는 사람들에게 털어 주는 정도일까?
아니면, 스케쥴 관리를 하면서 프로그래머 들이 안정적으로 개발하도록 이끌어 주는 것.

매니저 역할이 자신과 맞지 않는 많은 관리자가 된 프로그래머 들은,
"내가 이 프로그램을 완벽하게 모르는데, 어떻게 스케쥴을 관리하고, 어떻게 현황을 파악할 수 있겠어?"
라고 되묻곤 한다. 물론, 자신이 그 대답을 알면서도 말이다.

매니저는 프로그래머를 통해서 스케쥴과 현황을 알게되는 것이다.
당연히 프로그래머들은 그것을 매우 귀찮아 하고, 자신을 방해 한다고 생각하며, 당신을 싫어할 것이다.
마치 당신이 프로그래머 일 때 그랬듯이,
"왜 알지도 못하는 놈이 와서 남의 프로젝트에 끼어들어서 방해질을 하지?"
하는 생각을 하면서 말이다.

당연히 매니저가 된 프로그래머는 자신이 더 많이 안다고 외치기 위해 프로젝트를 프로그래머 보다 더 자세히, 촘촘히, 완벽하게 알고 싶어진다. 바로, 백업 프로그래머가 되고 싶어진다.

그렇지만, 매니저는 프로그래머가 아니다.
자신이 얼마나 훌륭한 프로그래머 였던지 간에, 당신이 이미 매니저라면,
당신이 해야 할 일은, 프로그래머의 생각을 들으며 관계를 다지고,
그들 필요하다는 일을 하거나 조율 해 나가며 신뢰를 쌓아서,
사람을 통해 전체 적인 방향을 더 나은 방향으로 이끌어 가야 하는 것이다.


물론, 이 글을 쓰면서도, 한 부분의 전문가인 프로그래머에게
사람을 관리하는 전문분야 외의 일을 "강제로" 시키는 것이 가장 큰 오착이라고 생각한다.

하지만, 자신이 선택했든, 그것이 짐 지워진 일이 되었든,
매니저가 되라고 했을 때, 백업 프로그래머가 되는 것은 크나 큰 패착이다.

매니저가 프로그래머를 이해하기 위해서 코드를 보는 것은 의미가 있는 일이겠지만,
프로그래머와 경쟁하거나, 자신이 백업 프로그래머가 되기 위해서 코드를 보지는 말아야 한다.

매니저가 되는 순간,
자신의 주 업무가 프로그래밍이 아니라는 것을 이해해야 한다.

매니저는 프로그래머가 아니다.