‘주니어’ PM

작년, 생애 처음으로 프로젝트 매니저를 맡았다. 내가 활동했던 데이터 분석 학회에서는 학기 중반이면 기업의 의뢰를 받아 연계 프로젝트를 진행한다. 이 프로젝트에서 동료들이 감사하게도 팀 리드 자리를 맡겨준 것이다. 남을 이끄는 자리가 아예 처음인 것은 아니었지만, 기업측과의 커뮤니케이션, 계약 조율, 예산 운용 및 팀 리드 업무를 포함하여 어떻게든 ‘일이 되게 하는’ 프로젝트 매니저는 처음이었다. 역할이 확정된 10월 무렵에는 지하철을 타다가도 번뜩 내가 프로젝트 매니저라는 사실이 떠올라 흥분과 설렘과 불안에 휩싸였다. 그럴 때마다 나는 구글에 ‘좋은 프로젝트 매니저란’ 따위를 검색했다. 아주 쓸모 없는 짓은 아니었다. 한 스타트업 대표가 신규 입사자를 온보딩하는 자신의 방법에 대해 쓴 이 글을 발견했기 때문이다. 프로젝트 매니저에 대한 글은 아니었지만, 막연하게만 생각하던 리더의 자질을 명확한 행동 지침으로 써내려간 유익한 글이었다. 내가 특히나 와닿았던 부분은 다음과 같다.

주어진 역할을 성공적으로 수행했을 때 예상되는 결과물의 형태를 구체적으로 제시할 것
팀원에게 어떤 점을 기대하고 있는지 표현하여 지지와 신뢰를 드러낼 것
주기적인 개인 미팅을 통해 문제를 체크하고 개인적인 고민을 공유할 것

위 조언들은 전반적인 태도와 방향성에 대한 지침이다. 곧이 곧대로 받아들이기 보다는 조직의 형태와 프로젝트의 성격에 따라 상세한 양식을 달리하는 게 당연하다. 내가 몸담은 조직은 일반적인 회사의 팀과 달리 10월부터 12월까지 세 달 간의 프로젝트를 위한 단기 조직이었다. 모두 배우는 단계이다 보니 팀 리드와 팀 멤버 간 경험치의 차이가 크지 않다는 것도 차이점이었다. ‘주니어’ PM으로 프로젝트성 조직을 이끌면서 많은 시행착오를 겪었다.

PM은 모든 것을 다 아는 사람이 아니다

기대하는 결과물의 형태를 구체적으로 제시하며 업무를 할당하는 일은 생각만큼 쉽지 않았다. 구체적인 지시는 구체적인 사전 지식을 요했다. 아직 시작하지도 않은 작업에 대해서 말이다. 예를 들면, 현업 실태에 대해 리서치가 필요한데, 이를 지시하기 위해서는 내가 미리 리서치를 해야하는 요상한 상황이었다. 특히 전체적인 방향성을 잡아 나가던 프로젝트 초반에는 일곱 명의 팀원들이 나의 지시를 기다리고 있고 나는 사전 리서치를 하면서 식은땀을 흘리곤 했다. 앞선 조언을 그대로 적용하려 하다보니 발생한 일이었다.

생각이 바뀐 건 한 번의 실패를 겪고 난 다음이었다. 최신 논문과 아티클을 공부하며 파악한 이론을 파이썬으로 구현하기 위해 참고할 만한 자료를 찾던 중이었다. 주요 키워드로 검색한 결과 깃헙에서 관련 있어 보이는 레포지토리를 몇 개 찾을 수 있었다. 공개되어 있는 코드들을 하나씩 맡아 코드가 어떻게 작동하는지 파악해 오기로 했다. 동작 원리를 이해하기 위해 라인 바이 라인으로 세세하게 해석해오라는 지시를 덧붙였다. 그 전 시간에 다른 샘플코드를 내가 직접 분석해 클래스의 구조와 주요 변수와 함수의 역할을 브리핑 한 적이 있기에 성공적인 결과물에 대한 상을 모두가 공유하고 있다고 생각했다. 하지만 착각이었는데, 팀원 중 한 명이 모듈의 가장 겉부분에 해당하는 main.py 파일만을 읽어온 것이다. 방법은 맞았다. main.py 파일을 한 줄 씩 구동해보며 모든 변수와 함수의 의미와 원리를 해석하고 주석까지 곁들였다. 하지만 팀에게 필요했던 것은 클래스 내부의 원리였다.

그 이후로는 해당 업무의 성과가 프로젝트의 전체적인 맥락에서 어떤 역할을 하는지 이해시키는 쪽으로 지시하려고 노력했다. ‘코드를 한 줄 씩 읽어오기’, ‘코드에 주석 달기’는 일의 방법에 해당한다. 하지만 구체적이어야했던 부분은 일의 목적이었다. 예를 들면 이렇게 이야기할 수 있었다. - “우리가 앞서 연구한 이론들이 파이썬 코드로 어떻게 구현되는지 참고할만한 자료가 필요하다. 각자 담당한 파이썬 코드의 각 부분이 이론의 어떤 단계에 해당하는지 이해해 오라. 그것을 바탕으로 다음 시간에는 팀 전체에게 파이썬 코드와 이론에서 제기된 방법 간의 공통점과 차이점을 설명해줬으면 좋겠다. 모듈 구조의 적절성과 코드의 효율성 및 가독성에 대한 감상도 덧붙여달라. 이론과의 정합성과 코드의 퀄리티에 대한 너의 분석을 기반으로 이 코드를 참고할지말지 결정할 예정이다.”

개인 미팅의 함정

개인 미팅에 대해서 느낀 바도 있다. 개인 미팅의 내용이 계속해서 비공식적인 부분으로 수면 아래 남아있을 수는 없다는 것이었다. 껄끄럽고 불편할 수 있지만, 모두가 같이 의논하는 자리도 필요했다. 학회 활동 시간은 주 3회 서너시간으로 정해져있다보니, 개인 미팅은 학회를 오가면서, 쉬는 시간에, 회식 자리에서 안부를 물으면서 비공식적 대화를 나누는 것으로 대체했다. 내용을 이해하기 어렵다는 팀원도 있었고, 그저 재밌다는 팀원이나 걱정된다는 팀원도 있었고, 좀처럼 속을 드러내지 않는 팀원도 있었다. 어떨 때는 개인이 토로하는 문제 상황이 조직 전체와 연결되어 있곤 했다. 이러한 목소리를 흘려보내지 않고 공동으로 노력해야하는 사안으로 유연하게 전환해야겠다는 생각이 들었다. 이런 점에서 프로젝트 중간 결산은 의도치 않게 큰 몫을 했다.

중간결산은 단기에 성과를 내는 것이 중요한 프로젝트에서 진행이 늘어지는 일을 방지하기 위해 중간 지점과 그 때까지 달성할 목표를 설정해놓은 것이었다. 클라이언트가 요구에서 정량적인 사항만 남긴 ‘최소한의 실행가능한 모델’을 구현하는 것을 중간 목표로 잡았다. 모델의 성과를 개선하고 실무에서의 활용 방안을 연구하는 것은 그 다음으로 남겨두었다. 이 중간목표 덕분에 너무나 많은 문제에 압도될 수 있는 초반에 모델의 작동과 관련된 이슈에 집중할 수 있었다.

중간결산은 업무를 진행하느라 미처 터놓고 얘기할 수 없었던 조직의 상태를 점검하는 기회이기도 했다. 팀 리드의 역할에 대한 피드백부터 시작해서(무척 떨렸다) 개인적으로 업무의 진행과 커뮤니케이션 형식에 대해 느꼈던 바를 나눴다. 그러다가 특정 팀원에게 이미 익숙한 기술을 활용한 업무가 몰려 있어서 성장의 기회가 부족하다는 이야기도 나왔다. sql에 이미 능숙한 팀원이 업무의 효율성 때문에 계속해서 sql 업무만 맡게 된다는 것이었다. 나도 인지하고 있던 문제라 마음이 무거웠는데, 다들 똑같이 느끼고 있었던 것이다. 이미 알고 있던 문제인데 뭐가 달라지냐고 물을 수도 있겠다. 수면 위로 드러나는 것, 그래서 두루뭉실한 심증이 아니라 빼도박도 못하는 합의가 되는 것은 중요하다. 공동의 문제가 되는 시점부터 비로소 모두가 배려하고 노력해야하는 부분이라고 의식되기 때문이다. 그런 이야기를 주고 받으며 우리는 후반부에는 새로운 도전을 성장할 수 있는 기회를 서로에게 많이 주자고 다짐했다.

관리자의 ‘일잘’은?

실무자로서 일을 잘하던 사람이 관리자가 되면 삐걱거린다는 이야기가 있다. 프로젝트 초반에는 프로젝트 매니저의 일을 부수적인 운영과 행정의 일이라고 생각했다. 다른 프로젝트에서 그래왔던 것처럼 나한테 다른 팀원과 동등하게 한 사람 몫의 실무를 부여했다. 프로젝트 매니저로서의 일은 관리가 필요한 부분이 생길 때만 하는 것이며 기본적으로 팀리드는 실무에 있어서도 가장 뛰어난 사람이어야한다고 (내멋대로) 생각했다. 그렇게 운영관리업무와 리서치나 코드 작성 등 실무를 병행하면서 지쳐갈 때 쯤이었다. 한 팀원이 어느 날은 ‘왜 언니가 그런 것을 하고 있냐’고 따끔하게 이야기했다. 자신이 속해있던 프로젝트에서 팀장은 어떤 실무도 담당하지 않고 각자의 진행상황을 체크하며 조언을 덧붙이는 식이었다고 이야기했다. 그 때서야 실무자의 영역에 갇혀있던 ‘일잘’을 관리자의 영역에서 궁리하기 시작했다.

그 이후로 나는 실무에서는 빠졌다. 간혹가다 잦은 조율이 필요한 업무를 하는 팀에 느슨하게 걸치는 정도였다. 그리고 팀 구성원을 위한 리드미를 작성했다. 지금까지의 논의 사항과 진행 단계를 요약하고 언제든 생각이 나지 않으면 들릴 수 있게 참고 문서와 주요 논쟁들을 집대성한 자료였다. 그 문서에 기반해 팀원들은 현재의 업무가 전체에서 어느 부분에 해당하는지 이해할 수 있었고, 나 또한 팀원들의 노력의 발자취를 그 문서에 주기적으로 업데이트 했다.

문서화는 곧 구조화다. 온전한 글의 형태로 문서에 업데이트를 하면서 각 업무가 전체적인 흐름과 잘 align하고 있는지, 방향성에 분기가 생기고 있는지, 그 다음 단계는 무엇일지 바로바로 확인할 수 있었다. 예를 들면 raw 데이터를 전처리하여 원하는 형태로 가공하는 방법으로 두 가지가 제안됐다. 두 팀으로 나누어 동시에 구현을 시작했고, 리드미를 쓰면서 각 방법의 로직, 파라미터와 효율성을 정리하면서 자연스럽게 두 방법을 비교할 수 있었다. 공통적인 부분을 통합하여 superclass로 두고, 각 방법이 유리할만한 시나리오를 생각해보는 것이 자연스럽게 다음 업무로 떠올랐다.

사람을 남기는 일

프로젝트 내용을 소화해내는 데에 더해 조직 내에서 나에게 부여된 새로운 역할에 적응하느라 치열한 3개월이었다. 그 기간을 견뎌내고 클라이언트로부터 인정을 받을 수 있었던 건 팀원들의 도움이 컸다. 이 부분은 팔로워로서 프로젝트에 참여했을 때는 잘 느끼지 못했던 부분이었다. 팀원들이 방황하는 모습부터 성공적으로 해내는 모습까지 함께하며 성장하는 과정을 지켜보는 것 말이다. 자신은 못한다며 주저하던 팀원이 다음 모임날 다른 팀원들한테 자랑스럽게 본인의 작업물을 발표할 때, 비슷한 작업을 하는 두 팀원이 각자의 고민을 공유하며 다음 작업을 논의할때, 회사와 미팅을 하며 마침 팀원 중 하나가 신경써서 작업한 부분에 질문이 들어왔을때, 그 팀원과 함께 질문에 만족스럽게 대답했을 때, 그 순간 팀원들에 대한 치솟는 애정을 느꼈다.

최종 미팅에서 마무리 피드백을 클라이언트로부터 들으면서, 한 분이 팀워크가 좋은 것 같다는 말을 했다. 우리 팀이 같이 일하는 것을 직접적으로는 볼 기회가 없었기에 어떻게 알았는지 의아한 마음이 들면서도 그 팀워크가 아니었으면 불가능한 작업이었을 수 있겠다는 생각이 스쳤다. 이번 프로젝트에서는 프로젝트 매니저라는 자리가 있어서 그런지 일하면서 좋은 조직에 대해 특히 더 고민했다. 그 안에서 사실 조직에 대해 고민하고 점검하는 노력 자체가 조직의 건강성을 좌우한다는 것을 깨달았다. 프로젝트 매니저라는 자리가 아니었어도, 보다 적극적으로 조직의 상황을 기민하게 인식할것을 다짐하게 된다.