링크드인 글 발췌

출처: 링크드인 글

 

아직 풀리지 않은 의문들, 그 중 첫 번째: 한국에서의 product manager란 무엇인가.

한국에서의 PM들 상당수는, 내가 아는 PM들(실리콘밸리 빅 테크 회사들 및 미국 테크 스타트업들의 PM들)과 다른 것 같다.

내가 아는 PM들은, 업무 영역의 경계가 없었다. 맡은 프로덕트가 뭐가 됐든, 무슨 수를 써서라도 그걸 성공시키는 게 PM의 임무였다. 비주얼 디자인이든 코딩이든 비즈니스 모델 개발이든 데이터 해석이든, 어떻게든 시킬 사람을 찾아 시키고 안되면 본인이 직접 하기도 했다.

그러다가 허구헌날 높은 사람들(엔지니어링 리드도 포함)한테 깨지곤 했고, 대부분의 시간엔 이 사람 저 사람 들쑤시며 친한 척 하는, 하지만 사실은 들들 볶는 게 그들의 일이었다. 회사 밖으로 싸돌아다니며 온갖 사람들을 만나며 뭔가 알아보거나 부탁할 때도 많았고.

다른 사람들(특히 엔지니어들)이 시간을 효율적으로 쓸 수 있도록, time consuming한 단순 잡일은 본인들이 하곤 했다. 그리고 조직 외부의 craziness가 엔지니어들 등을 disturb하지 않도록 프로덕트 팀을 잘 encapsulate시키고, 밖에서 튀는 피와 뼈를 자기들이 몸으로 막아내곤 했다(이들이 그런 걸 잘 하면 엔지니어들은 눈치도 못 챈다). PM들이 착해서 또는 비굴해서 그런 게 아니라, 그게 본인들이 살 길이니까 그랬을 것이다.

그야말로 그 프로덕트의 CEO란 말이 어울리는 사람들이었다. 사실상 프로덕트 팀의 오너이자 리더 역할을 하는 이들이었다. 하지만 그들에게 누군가가 리포트하는 경우는 거의 없었다. 매니저로서의 지위와 권한이 주어지지 않지만 어떻게든 사람들을 밀고 당겨서 한 방향으로 align시키고 프로덕트를 만들어야 하는 것이다. 초기 스타트업이라면 사실 창업자 겸 CEO가 이런 일들을 하다가, 일의 규모가 커지면 PM을 뽑아 일들을 위임하겠지.

이런 PM들이 나중에 창업해서 CEO가 되는 경우도 많았고, 반대로 스타트업이 빅 테크에 acquired 될 때 스타트업 창업자이자 CEO가 그 빅 테크에서 PM 역할을 맡게 되는 경우도 많았다.

PM 중에는 대학 갓 졸업한 젊은 사람은 별로 없었고, 어디서 엔지니어링이나 비즈니스를 *상당한 수준으로* 하다 온 사람들이 대부분이었다. 유명 컨설팅 회사 출신들도 많았고. 대부분 공학 박사(주로 컴퓨터 사이언스 관련 전공)나 MBA 정도의 학위가 있었다. 경력이 별로 없는 '주니어'들에게는 APM이라는 다른 타이틀이 부여됐던 걸로 기억한다.

이들에게는 written language로 문서를 잘 만드는 능력이 필수적이었다. Product requirements document (PRD) 를 써야 하기 때문이다. PRD가 엔지니어링, 비즈니스, 리걸, 그리고 많은 높은 사람들의 리뷰를 거치며 살아남아야 프로덕트를 만들기 시작할 수 있다. 살아남은 PRD는 프로덕트 팀에게 하이 레벨의 방향을 제시하는 가이드 역할을 한다(디테일은 보통 엔지니어, 비주얼 디자이너들이 알아서 한다).

나는 실리콘밸리 빅 테크 회사에서 오래 있었으니, 아마도 내가 아는 이러한 PM들의 모습이 더 '원래 형태'에 가까울 것이라 생각한다. 한국 IT 업계에서 그것을 참고하여 PM이라는 타이틀과 역할을 도입했으리라 짐작된다.

그런데 한국에서는... 많이 달라 보인다. 한국에서의 PM이 뭔지 나는 아직 잘 파악하지 못한 것 같다. 지금 내가 이해하기로는, 이들은 '온라인 서비스의 UX 플로우를 설계하는 사람들'에 가까워 보인다(물론 미국 빅 테크 PM도 이런 일을 하지만 이것은 그들 일의 일부일 뿐이다). 대학 졸업하고 그런 일을 시작해서, 그런 스킬셋을 강화시키는 방향으로 커리어를 발전시킬 거라 추측된다. 그렇게 '발전'하면 나중엔, 엔지니어들이 아무 생각 없이 코드로 번역만 하면 될 정도로 상세한 설계까지 하게 될 것 같다. 그리고 아마, '스크럼 마스터'나 '애자일 코치'같은 일을 하기도 하겠지(나는 스크럼 마스터나 애자일 코치라는 사람들을 개입시키는 걸 별로 좋아하지 않는다. 일을 분배하고 프로그레스 체크를 하는 건 테크 리드나 엔지니어링 매니저가 하면 된다. 스크럼이니 뭐니 하는 용어를 갖다붙이며 특별한 척 할 필요가 없다고 생각한다. 일이 좀 크다 싶으면 테크니컬 프로그램 매니저를 채용하면 될 것이다).

그러다가 나중엔 시니어 소프트웨어의 영역까지 들어와 백엔드 아키텍춰에까지 관여를 하는 것 같다. 정말 이해가 안 된다. SI 업체들의 코딩 한 줄 안 해 본 '소프트웨어 아키텍트'들과 비슷하게 되는 것인가?

나는 PM의 가장 근본적이고 중요한 역할이 무슨 프로덕트를 만들지, 왜 만들지 등에 대해 생각하는 거라 믿는데, 우리 나라의 많은 PM들은, 이런 생각은 높은 사람들이 해 주는 거라고 생각하는 것 같기도 하다.

쿠팡에선 prod mgr을 프로덕트 오너라 한다고 들었다. 쿠팡에는 실리콘밸리 및 아마존 출신들이 많으니 그들의 시스템을 꽤 잘 카피했으리라 추측되는데, 왜 그런 데에서 많이들 쓰는 PM이란 말을 안 쓰고 굳이 PO란 말을 유행시켰을까? 한국에서 이미 PM이란 말의 뜻이 많이 달라져버렸다고 판단해서였을까?

한국에는 '기획자'란 말이 있고, prod mgr란 말도 그것과 거의 비슷한 뜻으로 쓰는 것 같다. 기획이 뭔지 알긴 알겠는데... 신기한 것이, 미국에는 그런 말이 없다. 굳이 번역하면 planning? 그런 말을 별로 쓰지 않는다. Service planner나 business planner라는 포지션은 들어본 적도 없다. '기획한다'라는 말에 대응되는 표현도 잘 모르겠다. 실리콘밸리에선 PM들이 프로덕트를 define하고 PRD를 쓰고 execute하고 launch한다. 기획에 대응되는 말이 없다.

어쨌든 한국에 왔으니, Google 시절의 방식은 묻어 두고 내가 적응해야 하는가? 그렇다면 여기선 prod mgr의 정의를 '서비스 기획자' 정도로 생각하면 될까? 그럼 내가 아는 '원래' PM을 채용하려면 어떡해야 하지? 사업'기획'자를 뽑으면 되나?