틀을 깨야 한다는 틀을 깨기
2024년 5월 22일 수요일 - 100일 차
☁ 춥다. 많이 춥다. 이제 좀 따뜻해졌으면 좋겠다.
나는 정해진 틀이 좋다. 잘 따르기만 하면 좋은 결과가 보장된다는 점이 마음에 든다. 무엇을 해야 하는지 명확할수록 마음이 편하다. 예를 들면, 이름 있는 대학교를 나와 대기업에 입사해 최대한 빨리 승진하면 성공한 삶에 가까워질 수 있다. 학교 성적이 좋을수록, 인턴십 경험이 많을수록 대기업에 입사하기 유리하다.
대학교에서 컴퓨터 과학(CS)을 전공했다. 이 전공으로 할 수 있는 건 두 가지뿐인 줄 알았다. 공부를 더 해서 교수가 되거나 개발자로 취업해서 돈을 벌거나. 공부는 내 적성이 아니었으니 개발자가 되어야 했다. 하지만 3학년 여름 IT 회사에서 개발자로 인턴을 하고는 큰일 났다 싶었다. 개발자도 영 내 스타일이 아니었기 때문이다.
대학교 졸업이 얼마 안 남았을 때였다. 마이크로소프트에서 면접 볼 기회가 생겼다. 면접실에 들어가자마자 면접관이 개발자로 면접을 보러 왔는지, PM으로 면접 보러 왔는지 물었다. PM이 뭘 하는 사람인지, 무엇의 약자인지도 몰랐지만 개발자는 죽어도 하기 싫어서 PM이라고 했다. 면접 한 시간 내내 어떻게 하면 모자라 보이지 않고 PM이 무엇인지 알아낼 수 있을까 고민했다.
운 좋게 면접에 합격하고 마이크로소프트에 입사했다. 이제는 최대한 빨리, 많은 승진을 하는 게 목표가 됐다. 그러려면 PM이 무엇인지 알아야 했다. 뭘 해야 하는지 알아야 잘할 수 있다고 생각했기 때문이다. 그 누구도 명확하게 PM이 무엇인지 설명해주지 못했다. 여러 사람들과의 대화와 책에서 찾은 내용도 다 제각각이었다.
PM으로 일한 지 3년이 지나서야 좀 알 것 같았다. 당시 내가 생각했던 PM의 역할은 다음과 같았다.
분기 별 목표와 성과 지표(Objectives and Key Results) 정하기
크루(crew)* 이끌기
프로젝트 제안서 쓰기
프로젝트 디자인하기
프로젝트 세부 계획서 쓰기
프로젝트 진행 잘 되고 있는지 확인하기
완성된 프로젝트 홍보하기
유저 피드백받기
*크루(crew)는 같은 분야의 프로젝트를 위해 PM, 개발자(SWE), 데이터 과학자(DS)가 모인 팀이다.
주로 한 명의 PM이 리드하고 여러 명의 SWE와 DS로 구성되어 있다.
이렇게 역할을 파악한 지 얼마 되지 않아 새로운 crew에 배정됐다. 이 crew는 전과는 많이 달랐다. 개발자 매니저가 PM 없이 일을 해버렸기 때문이다. 내가 프로젝트 제안서를 쓸 동안 개발자들이 코드를 짜기 시작했다. 완성된 디자인이나 세부 계획도 없이. 심지어 프로젝트 진행 상황 보고는 내가 없는 미팅에서 이뤄졌다. 내가 생각했던 PM의 역할 대부분을 뺏겼다. 내가 설 곳이 없어진 것 같아 우울했다. 실제로 무언가를 만들어 낼 수 있는 개발자가 PM 역할까지 할 수 있다면 내가 팀에 기여할 수 있는 게 무엇인지 확신이 서지 않았다.
그래서 PM이 무엇인지 다시 알아보기 시작했다. 내 매니저는 make things happen, 그러니까 일을 성사시키는 사람이라고 했다. 우연히 듣게 된 세미나에서 PM은 문제를 해결하는 사람이라고 했다. 종합해 보면 PM은 팀에서 해결해야 하는 문제를 파악하고, 문제가 해결될 수 있도록 도와야 하는 것이다. 그곳까지 어떻게 도달할 것인지는 내 몫이다. 직접 디자인을 하는 것도 하나의 방법이지만 누군가가 디자인을 해버렸다면 그게 맞는 해결책인지 끊임없이 질문하고 방향을 제시해 줄 수도 있다.
나는 아직도 틀이 좋다. 틀에 박히지 말라고, 틀을 깨라고들 하는데 나는 틀 안에 있을 때의 안정감이 좋다. 그리고 그 틀이 도움이 된 적도 많다. 하지만 이제는 틀을 넓힐 때가 된 것 같다. PM의 역할에 대한 방향을 찾았으니 그곳을 향해 어떻게 갈지는 그때 그때 유연하게 대처해보려고 한다.
