[qrwerq] 프로젝트 매니저의 덕목

---

어쩌다가보니 최근 프로젝트 하나를 진행하게 되면서, 내가 일을 지시하는 입장과 내가 일을 받는 입장을 동시에 겪고 있는데, 일을 하다보니 바로 위에 있는 매니저가 어떨 때 (내가 생각하기에) 답답하게 느껴지는지를 고민하게 되었다. 내가 일을 하면서도 이러한 매니저가 되지 않도록 조심하자는 측면에서 한번 적어보도록 한다.

그러니까 아랫 사람이 느끼기에 답답한 (팀) 매니저의 특성을 적어보고자 한다.
(역시 개인의 관점이므로, 다른 사람의 경우 관점이 다를 수도 있다.)

1) 해당 프로젝트/분야에 대한 지식과 경험의 결여

지금 같이 프로젝트를 수행하고 있는 매니저의 경우에는, 의외로 이 프로젝트/분야에 대한 경험이나 지식이 별로 없다. 사실 이러한 상황은 대체할 수 있는 사람이 거의 없는 조직에서 발생하는 경우가 많은데, 나름대로의 중간 의사결정을 해야하는 이러한 자리에 해당 프로젝트에 대한 지식과 경험이 별로 없는 것은 굉장히 크리티컬하다. 왜냐하면, 잘못된 의사결정으로 인한 비용을 결국 실무자와 그 조직이 전체적으로 떠안아야하기 때문이다. 물론 실무자는 영혼이 없이 그냥 수행해도 된다. (삽질인 것을 알지만서도.) 문제는 이러한 삽질이 반복되기 시작하면, 실무자의 자아실현이나 실력 향상에 도움이 안된다는 것이다. (정확히 이야기하면, 효율적인 성장이 좀 어렵고, 삽질을 통해 왜 삽질을 하면 안되는지를 배우게 되긴 한다.) 또한 나쁜 팀원을 만났을 때, 이 팀원이 실질적으로 무얼 하고 있는지 파악하기 어렵다. 이는 다른 팀원의 사기를 저하시키는 요인이 된다.

(실무자 입장에서 아주 친절하게 코드를 짜놓고, 주석도 잘 달아주고, 참고문헌에 관한 요약 발표도 여러번 했는데, 딴 소리를 하고 있다면 실무자 입장에서 분통터질 노릇이다.)

2) 보이는 것에 과도하게 집착

매니저는 결국 팀 단위로 평가받아야하는 직책이다보니, 팀의 성과를 어떻게 하면 잘 보여줄 수 있을지에 대한 문제가 팀의 성과를 어떻게 낼 것이냐에 대한 문제만큼이나 중요할 것이다. 발표회장을 가더라도 어떻게 약을 잘 팔 수 있는가가 진짜 이 약이 괜찮은 약인가보다 더 중요하다는 것을 종종 보곤 했다. 결국 그러한 관점이 다른 사람들을 혹하게 하고 투자하고 프로젝트를 진행하도록 만드는 지름길이기는 할 것이다. 하지만 보이는 것에 과도하게 집착하는 성향은, 실무자로 하여금 무엇이 본질이고 본질이 아닌지 집중하기 어려운 사태에 빠지게 한다. 어떠한 프로젝트든 가시적으로 빨리 나타나는 지표와 가시적으로 늦게 나타나는 지표, 그리고 가시적으로 나타내기 어려운 지표들이 존재한다. 가시적인 지표들이 항상 잠재변수(latent variable)에 대한 설명력을 갖추는 것은 아니다. 가시적인 것에 대한 집착은, 장기적인 설계/확장성(Scalability)/호환성 등에 대해, 실무자로 하여금 이러한 고려를 배제하게 하는 특성이다. 실무자 입장에서는 어차피 모래성 위라도 보여주면 그만이다. 가시적인 결과로서 모든 것을 파악할 수 있다면, 그건 착각이다.

(껍데기를 보여주는 건 물론 중요한데, 그래도 MVP에 속하는 핵심 기능은 구현하고 있어야 하는 것 아니냐는 것이다. 껍데기가 고급껍데기로 진화한다고 별반 달라질까.)

3) 로드맵/청사진의 결여 혹은 모호함

1,2번과 연관되는 이야기이다. 실무자는 자신이 하는 작업들이 결국 전체의 거시적인 그림의 일부로서 효과적이고 효율적으로 작동하기를 원한다. 경험과 지식의 부족은 결국, 주어진 기간 내에 어떠한 목표를 달성할 수 있을지, 그리고 이러한 목표를 달성하기 위해 세부적인 구성요소들이 어떻게 필요하며, 개발/진행 프로세스 상에서 어떤 모듈화된 작업이 포함되어야할 지에 대한 로드맵이나 청사진을 구체적으로 그려넣지 못한다. 단지 '어떠한 작업을 했으면 좋겠어요' 라는 문장으로 제한될 뿐이다. 이 작업에 대한 세부 작업들이 분석되지 않으며, 각 세부작업들 간의 흐름/달성도와 관련된 연관은 엉켜있기 마련이다. A를 하려면 B가 필요하고, B를 하려면 A가 필요한 상황을 생각해보자. 이를 어떻게 해결할 것인가.

(우리가 Git을 쓰고 버전 관리를 중요하게 여기는 이유를 생각해보자.)

4) 팀원 지식/경험/의견에 대한 존중

1,2,3이 부족한 것은, 팀원 의견에 대한 존중으로 커버할 수 있다. 만약 4번이 없다면 1,2,3번을 갖추고 있어도 일의 진행 과정이 순탄치 않을 것이다. 왜냐하면 아무리 매니저가 충분한 경험과 지식을 가지고 있다고 하더라도, 세부적인 부분에서 실제로 매니저가 그 일을 하지 않는 이상, 새롭게 발생하는 병목이나 오류, 제한점을 발견하기 쉽지 않으며, 결국 구체적인 방향으로 해결하는 것은 실무자이기 때문이다. 본인이 스스로 어떠한 부분에 대한 역량이나 실력이 부족하다면, 그 것을 인정하고 이를 갖추고 있는 팀원의 의견에 귀를 기울이는 것이 필요하다. 필요할 때에 권한 위임을 하는 것은 상당히 중요한데, 생각보다 많은 조직의 장, 기업의 C-Level들이 이것을 못해서 망한다. 권한과 책임을 동시에 위임하면 된다.

일을 실제로 진행하는 실무자의 필요와 주체적 의무를 반영하여 3,4를 잘 섞으면 Agile 방법론의 일종이 될 것 같기는 하다.

---

좋은 매니저란, 위에서 적은 항목들에 대해 반대 방향을 지키고 추구할 수 있도록 노력하는 매니저라고 생각한다.

적다보니 너무나 뻔한 이야기를 한 것 같지만, 정리를 해두자는 차원에서 글을 적는다. 비단 어떠한 프로젝트 진행 뿐만 아니라, 협업의 관점에서, 관계의 관점에서도 마찬가지로 적용되는 덕목들일 것이다.