프로덕트 매니저란 정말 무엇인가? (당신의 LinkedIn 소개와는 다를 수 있어요)
이 글은 PM(프로덕트 매니저)이라는 직무의 실체를 솔직하고 날카롭게 파헤칩니다. PM은 아무것도 직접 만들지 않지만 모든 것에 책임을 지는 역할이며, 핵심은 고객·비즈니스·개발 사이의 긴장을 조율하는 '번역가'에 가깝습니다. 권한 없이 영향력만으로 일해야 하는 이 역할의 본질을 이해하는 것이 이 글의 핵심 메시지입니다.
1. PM은 아무것도 만들지 않는다, 그런데도 모든 책임을 진다 🤔
PM이 뭐 하는 사람이냐고 열 명에게 물어보면 열한 가지 답이 돌아오고, 그 중 누군가는 꼭 "아, 프로젝트 매니저 같은 거요?"라고 묻습니다. 그 순간 영혼이 육체를 떠나는 느낌이 드는 건 PM이라면 공감할 겁니다.
"코드는 당신 덕분에 배포되지 않는다. 픽셀 하나도 당신이 그린 게 아니다. 당신은 실제 제품에 들어가는 코드 한 줄 쓰지 않을 것이다. 그런데도 제품이 실패하면, 모두가 당신을 쳐다본다."
이게 PM이라는 직업의 불편한 진실입니다. 직접 만드는 건 없지만, 잘못되면 책임은 고스란히 돌아옵니다. 그렇다면 대체 이 일의 본질은 무엇일까요?
PM은 항상 세 가지 힘이 서로 멀어지려는 마찰 속에 존재하는 유일한 사람입니다.
- 고객이 필요로 하는 것
- 비즈니스가 필요로 하는 것
- 개발팀이 주어진 시간 안에 현실적으로 만들 수 있는 것
로드맵, 유저 스토리, 끝없는 Jira 티켓들은 모두 이 긴장을 관리하기 위한 '서류 작업'에 불과합니다. 일의 진짜 본질은 바로 이 세 가지 사이의 균형을 잡는 것입니다.
2. 삼각형의 진짜 모습 📐
PM의 역할을 설명할 때 흔히 "사용자 경험, 비즈니스 가치, 기술적 실현 가능성"을 꼭짓점으로 하는 삼각형을 그리고, PM이 그 중심에 유엔 평화 유지군처럼 앉아 있는 그림을 보여줍니다. 귀여운 다이어그램이지만, 현실에서는 거의 쓸모가 없습니다.
실제로 벌어지는 일은 이렇습니다. 개발팀은 지금 코드베이스가 청테이프와 기도로 간신히 붙어 있다며 리팩터링을 원합니다. 영업팀은 다음 분기에 세 건의 엔터프라이즈 계약을 성사시킬 기능을 원합니다. 그리고 고객들은 막상 이야기해보면 그 둘과는 완전히 다른 것을 원하는데, 대개 건물 안의 누구도 예상하지 못한 더 작고 더 평범한 무언가입니다.
"당신의 일은 셋 모두를 행복하게 만드는 것이 아니다. 그건 불가능하고, 가능하다고 말하는 사람은 프레임워크를 팔려는 것이다."
PM의 진짜 역할은 지금 이 순간 무엇이 가장 중요한지 파악하고, 그 이유를 논리적으로 구성한 뒤, 그 주장이 자신에게 동의하지 않는 VP와의 회의를 살아남게 만드는 것입니다.
바로 이 때문에 "PM은 제품의 CEO다"라는 말은 역대 가장 해로운 문구 중 하나입니다. CEO는 권한이 있습니다. 사람을 해고하고, 예산을 배분하고, 전략을 세우면 그게 실제로 통합니다. PM에게는 그런 게 없습니다. 있는 건 영향력뿐이고, 그 영향력은 매주, 매번의 회의마다, 직함의 크기가 아닌 사고의 질로 새롭게 벌어야 합니다.
3. 진짜 일은 '번역'이고, 번역은 잔인하다 🗣️
시니어 PM들이 알고 주니어 PM들이 혹독하게 배우는 것이 있습니다. 가장 어려운 부분은 무엇을 만들지 결정하는 게 아니라, 기술적으로는 같은 언어를 쓰지만 실질적으로는 다른 언어를 구사하는 사람들 사이를 통역하는 것이라는 점입니다.
개발팀이 "3스프린트 걸립니다"라고 말할 때, 실제 의미는 이렇습니다.
"아무것도 안 깨지고, 아무도 아프지 않고, 우리가 의존하는 API가 밑에서 바뀌지 않는다면 3스프린트입니다. 물론 바뀔 겁니다."
영업팀이 "고객이 이번 분기 말까지 이게 필요하다고 했어요"라고 말할 때, 실제 의미는 이렇습니다.
"계약을 성사시키려고 고객에게 이게 될 거라고 했고, 지금 당신한테 말함으로써 소급해서 그걸 사실로 만들고 있는 겁니다."
고객이 "대시보드가 필요해요"라고 말할 때, 열 번 중 아홉 번은 실제로 원하는 게 이겁니다.
"자신도 모르는 나쁜 일이 일어나고 있는 건 아닐까 하는 불안감에서 벗어나고 싶은 것입니다. 대시보드는 그 불안이 '해결책을 묘사해 보세요'라는 질문을 만났을 때 취하는 형태일 뿐입니다."
좋은 PM은 이 세 가지를 그대로 받아쓰지 않습니다. 진짜 문제가 드러날 때까지 "왜요?"를 거듭 묻습니다. 처음 나오는 말이 실제 문제인 경우는 거의 없기 때문입니다.
4. '얼라인먼트'는 말랑해 보이지만 사실 가장 어려운 기술이다 🧩
'얼라인먼트(정렬, 합의)'라는 단어를 들으면 화이트보드 앞에서 하는 회의 같은 기업 용어처럼 들립니다. 하지만 제대로 실행된 얼라인먼트는 회사에서 할 수 있는 가장 지적으로 까다로운 일 중 하나입니다.
동시에 서로 모순되는 3~4가지 현실을 머릿속에 담고, 가장 중요한 사람들이 앞으로 나아갈 수 있게 하면서도 누구에게도 거짓말하지 않는 '진실의 버전'을 찾아내야 합니다. 그리고 그것을 개발자, 디자이너, 재무 담당자가 모두 같은 이해를 갖고 회의실을 나가도록 명확하게 전달해야 합니다.
"얼라인먼트가 제대로 작동하면, 그건 보이지 않습니다. 팀은 그냥... 제때 맞는 걸 출시하고, 모두가 그게 당연한 일이라고 생각합니다. 실패하면, 그건 파국적이고 굉장히, 굉장히 눈에 잘 보입니다. 그리고 사후 보고서에 누구 이름이 올라가는지 맞춰보세요."
가장 뛰어난 PM은 아무도 알아채지 못하는 사람인 경우가 많습니다. 성공하면 당연한 것처럼 보이고, 실패하면 가장 먼저 지목되는 역할이 바로 PM입니다.
5. 아무도 말해주지 않는 것: 모든 것에 책임지지만 거의 아무것도 통제하지 못한다 😤
이것이야말로 모든 PM 채용 공고의 "빠르게 변하는 환경"과 "다양한 역할 수행" 문구 바로 아래에 써놔야 할 문장입니다.
당신은 직접 움직일 수 없는 지표에 대해 책임을 집니다. 리텐션이 떨어지면? PM 문제입니다. 비록 리텐션은 제품 품질, 고객 지원, 가격, 온보딩, 시장 상황, 경쟁사가 더 화려한 걸 출시했는지 여부의 결과물임에도 불구하고요. 인게이지먼트가 정체되면? PM 문제입니다. 설령 마케팅이 지난 분기에 잘못된 유저를 데려왔고 아무도 당신에게 알리지 않았더라도요.
당신이 통제할 수 없는 것들:
- 개발팀의 일정
- 디자인팀의 여유 시간
- CEO가 경쟁사 트윗을 보고 갑자기 새치기시킨 기능
당신이 통제할 수 있는 것:
- 자신의 판단력
- 설득력 있게 거절하는 능력
- 중요한 것을 위한 논리를 다른 사람보다 먼저 만들어내는 능력
"PM은 가장 권한이 없는 가장 힘든 직업"이라는 클리셰는 단순한 불평이 아닙니다. 그게 사실상 직무 기술서입니다. 권한 격차 자체가 이 일입니다. 권한이 있다면 CEO가 되는 거고, 그러면 이 역할은 존재할 필요가 없습니다. PM이 존재하는 이유는 정확히, 그냥 명령으로는 내릴 수 없는 결정들을 누군가가 내려야 하기 때문입니다.
6. 그렇다면 진짜 잘하는 PM은 무엇이 다를까? ✨
카리스마가 아닙니다. MBA 학위도 아닙니다. 완벽한 PRD 템플릿을 쓰는 능력도 아닙니다.
좋은 PM과 나쁜 PM을 가르는 것은 거의 항상 하나입니다. 아무것도 만들기 시작하기 전에 던지는 질문의 질입니다.
- 나쁜 PM: "어떻게 만들까?"
- 좋은 PM: "이걸 만들어야 할까? 틀렸다면 어떻게 될까?"
"최고의 PM들은 모두 약간 불편한 특성을 공유합니다. 그들은 회의실에서 속도를 늦추는 사람이 되는 것에 편안함을 느낍니다. 마찰을 좋아해서가 아니라, 올바른 문제를 파악하는 데 보낸 일주일이 잘못된 해결책을 아름답게 만드는 데 낭비한 한 분기를 아껴준다는 걸 배웠기 때문입니다."
마무리 💡
PM이라는 역할은 결국 이런 것입니다. 불완전한 정보, 서로 충돌하는 이해관계, 아무도 강제로 듣게 할 수 없는 상황 속에서 무엇이 진실인지, 무엇이 중요한지, 그것에 대해 무엇을 해야 하는지를 알아내는 일입니다.
피곤하게 들린다면, 실제로도 그렇습니다. 하지만 맞아떨어지는 순간, 이 일은 테크에서 가장 지적으로 살아있는 직업 중 하나입니다. 순수한 엔지니어도, 순수한 비즈니스맨도, 순수한 연구자도 아닌, 세 가지 모두를 서투르게, 동시에, 끊임없이 하는 것. 그리고 어떻게 보면, 그게 바로 핵심입니다.