플랫폼 PM이 프로덕트 관리자 중 가장 어려운 역할인 이유 6가지

다들 PM이 힘들다고 하는데, 플랫폼 PM은 왜 유독 더 힘들까요?

PM(프로덕트 매니저)이라는 직무 자체가 이미 쉽지 않다는 건 다들 아실 거예요. 빠르게 크는 서비스에서는 모든 게 급하고, B2B라면 실제 쓰는 사람이 아니라 회사에 제품을 팔아야 하죠. 내부 도구를 맡으면 조직 정치까지 신경 써야 하고요.

그런데 이 모든 것보다 한 단계 더 어렵다고 꼽히는 자리가 있어요. 바로 플랫폼 PM(Platform PM)입니다. 저도 플랫폼 기반 프로덕트를 맡아보면서 "왜 이렇게까지 힘들지" 싶었던 순간이 많았는데, 최근 프로덕트 코치 앤트 머피(Ant Murphy)의 글을 보고 무릎을 탁 쳤어요. 1만 5천 명 넘는 프로덕트 피플이 구독하는 뉴스레터에서 나온 이야기라 가볍게 넘길 말이 아니더라고요.

오늘은 이 여섯 가지 이유를 하나씩 짚어보면서, 왜 플랫폼 PM이 프로덕트 관리 역할 중 가장 요구가 많은 포지션인지 정리해볼게요.

플랫폼 PM이 정확히 뭘 하는 사람인가요

'플랫폼 PM'이라는 말 자체가 낯설 수 있어요. 쉽게 말하면, 다른 팀이 제품을 만들 수 있도록 기반이 되는 시스템을 책임지는 PM입니다.

예를 들어볼게요. 카카오가 카카오톡 앱 자체를 만드는 PM은 일반 PM이에요. 그런데 외부 개발자들이 카카오 로그인, 메시지 전송 같은 기능을 쓸 수 있게 API를 관리하는 PM은 플랫폼 PM에 가깝습니다.

요즘엔 국내에서도 네이버, 카카오, 토스 같은 빅테크는 물론이고, B2B 소프트웨어 회사들에서도 플랫폼 기획자, 플랫폼 PO(프로덕트 오너) 직무가 눈에 띄게 늘고 있더라고요. 저도 인슈어테크 회사에서 플랫폼 PO로 일하면서 이 흐름을 체감하고 있어요.

한 줄 정리, 플랫폼 PM은 최종 소비자가 아니라 제품을 만드는 다른 팀을 위한 기반을 관리하는 사람입니다.

첫 번째 이유, 고객이 두 겹이라 이해해야 할 게 두 배예요

일반 제품은 단순해요. 제품 하나, 사용자 집단 하나. 그 사용자만 잘 이해하면 됩니다.

플랫폼은 달라요. 먼저 플랫폼을 쓰는 내부 팀, 그러니까 개발자나 기획자를 이해해야 하고요. 그 팀이 서비스하는 최종 이용자까지도 파악해야 합니다.

한 다리 건너 고객이 생기는 구조인 거죠. 이걸 놓치면 그냥 주문받는 사람이 돼요. 내부 팀이 요청하는 것만 만들어주는 수행자로 전락하는 거예요.

진짜 플랫폼 PM은 내부 팀의 요청 너머를 봐요. 그 팀의 최종 고객이 뭘 원하는지 먼저 파악하고, 그걸 가능하게 해주는 플랫폼 기능을 먼저 제안하는 사람이에요. 저도 처음엔 요청받은 것만 처리하다가, 어느 순간 "이 요청 뒤에 있는 진짜 니즈가 뭘까"를 고민하기 시작하면서 일하는 방식이 완전히 바뀌었어요.

한 줄 정리, 플랫폼 PM은 고객을 두 겹으로 이해해야 합니다. 내부 팀 그리고 그 팀의 최종 사용자, 둘 다요.

두 번째 이유, 이해관계자가 일반 PM의 10배예요

이해관계자가 많은 건 모든 PM의 공통 과제지만, 플랫폼 PM은 이게 특히 심해요.

왜냐하면 플랫폼은 보통 회사 내 여러 제품 라인을 동시에 지원하거든요. 제품 라인마다 이해관계자가 따로 있고, 플랫폼 PM은 그 모든 팀과 소통해야 합니다.

변경 사항 하나가 다섯 개 팀에 영향을 줄 수 있어요. 그 다섯 팀 각각의 담당 임원, 기획자, 개발자와 모두 조율해야 하는 거죠. 이건 그냥 소통 잘하면 되는 수준이 아니에요.

강한 영향력 행사 능력과 이해관계자 관리 역량이 없으면 버티기 어려워요. 플랫폼 PM 채용 공고에 '커뮤니케이션 능력'이 단골로 등장하는 이유가 여기 있는 거예요.

한 줄 정리, 플랫폼이 여러 팀을 지원하는 만큼 이해관계자 수도 그만큼 늘어납니다. 관계 관리 자체가 핵심 업무예요.

세 번째 이유, 성과가 늦게 나타나고 내 통제 밖에 있어요

일반 제품은 기능을 배포하면 사용자 반응이 비교적 빨리 와요. 다운로드 수, 사용 시간, 전환율이 곧장 바뀌죠.

플랫폼은 달라요. 새 기능을 만들면 먼저 내부 팀이 채택해야 합니다. 그 팀이 새 기능을 써서 자기네 제품에 반영하고, 그 제품이 최종 사용자에게 배포되고, 그때서야 비로소 지표가 움직여요.

새 플랫폼 기능 출시, 팀 도입, 팀 제품에 적용, 사용자 배포. 이 사이클이 몇 달씩 걸릴 수 있어요.

그래서 플랫폼 PM은 선행 지표를 잘 설계해야 합니다. '비용 절감'이라는 큰 목표 하나만 봐선 안 돼요. 시스템 안정성 향상, 인시던트 감소, 평균 대응 시간 단축 같은 중간 지표를 쪼개서 추적해야 해요.

한 줄 정리, 플랫폼 PM의 성과는 시간차를 두고 나타납니다. 중간 지표를 잘 만들어야 길을 잃지 않아요.

네 번째 이유, 보이지 않는 일을 설득해야 해요

일반 제품은 데모가 가능해요. 화면을 보여주면 사람들이 바로 이해하죠.

플랫폼은 대부분 눈에 안 보여요. API, 내부 인프라, 백엔드 코드. 화면에 아무것도 안 바뀌어도 엄청난 작업이 이루어지고 있는 거예요.

임원진 앞에서 "이번 분기에 평가 시스템과 파인튜닝을 개선했습니다"라고 말해봐야, 비기술 임원들은 무슨 말인지 모릅니다. 겉으로는 제품이 그대로인 것처럼 보이니까요.

그래서 플랫폼 PM은 뛰어난 스토리텔러여야 해요. "고객이 이런 문제를 겪었어요. 그 팀이 이렇게 해결했고요. 우리 플랫폼이 그걸 가능하게 했습니다"라는 흐름으로 보이지 않는 걸 보이게 만들어야 하는 거예요.

많은 조직이 "플랫폼은 기술적이니까 기술 PM을 붙이면 된다"고 생각해요. 하지만 기술 이해도는 필요조건이지 충분조건이 아닙니다. 스토리텔링이 약한 플랫폼 팀은 예산을 못 받고 조직 내에서 서서히 존재감을 잃어요.

한 줄 정리, 보이지 않는 플랫폼 작업일수록 그것을 이야기로 풀어내는 능력이 더 중요해져요.

다섯 번째 이유, 강제 도입은 독약이에요

일반 제품은 강제로 쓰게 할 수 없어요. 사용자가 싫으면 그냥 안 씁니다. 그래서 PM은 제품을 자연스럽게 매력적으로 만들어야 하죠.

내부 플랫폼은 다릅니다. 임원이 "전 팀원 이번 달부터 신규 플랫폼으로 이전"이라고 공지할 수 있어요. 강제 도입이 가능한 거예요.

하지만 이건 대부분 재앙으로 끝나요. 직원들이 가장 불평하는 도구가 뭔지 떠올려보세요. 대부분 어쩔 수 없이 써야 하는 내부 시스템이잖아요.

진짜 플랫폼 PM은 신제품을 출시하듯 내부 플랫폼도 관리해요. 파일럿 프로그램을 운영하고, 얼리어답터의 피드백을 반영하고, 입소문이 퍼지길 기다리는 거예요.

경영진이 "빨리 전체 도입하자"고 압박할 때, 이를 설득해 속도를 조절하는 것도 플랫폼 PM의 중요한 역할이에요.

한 줄 정리, 강제 도입은 불만만 만듭니다. 내부 입소문과 자발적 채택이 훨씬 오래가는 방법이에요.

여섯 번째 이유, 버전 관리가 안 되면 팀 전체가 인질이 돼요

플랫폼이 성장하면 새 버전을 출시하게 됩니다. 그런데 새 버전으로 이전하려면 다른 팀들이 자기 코드를 수정해야 할 때가 많아요.

플랫폼이 v1에서 v2로 업그레이드되면 A팀, B팀, C팀이 모두 같은 날 이전을 완료해야 하는 상황이 생겨요. C팀이 다른 긴급 이슈로 바쁘면 전체가 멈춥니다. 한 팀이 인질이 되는 거예요.

해결책은 하위 호환성과 버전 공존이에요. v2를 출시해도 v1을 일정 기간 유지하는 거죠. 각 팀이 자기 일정에 맞춰 이전하면 됩니다.

중요한 건 '날짜'가 아니라 '기간'을 주는 거예요. "3월 1일까지 모두 v2로"가 아니라 "v1은 6개월 후 종료됩니다, 그 안에 각 팀 일정에 맞게 이전하세요"라고 하는 거죠.

물론 너무 많은 버전을 동시에 운영하는 건 비용이 크니까, 동시에 지원하는 버전 수에 명확한 정책을 만들어두어야 해요.

한 줄 정리, 모든 팀을 같은 날 이전시키려 하면 반드시 병목이 생깁니다. 기간을 주고 각자 알아서 이전하게 하는 게 현명해요.

마무리

플랫폼 PM이 어려운 진짜 이유는, 기존 PM 역량을 더 복잡한 환경에 맞게 적용해야 하기 때문이에요. 고객 인터뷰 기법, 이해관계자 관리, 스토리텔링, 제품 출시 전략까지 모든 걸 내부 플랫폼 맥락에 맞게 변형할 수 있어야 합니다.

그래서 플랫폼 PM은 시니어 역할이에요. 기본기가 탄탄하지 않으면 오히려 더 빨리 무너집니다. 주니어 PM을 플랫폼에 배치하는 건 성공을 위한 설정이 아니라 실패를 위한 설정이라고 앤트 머피는 단언해요.

정리하면 플랫폼 PM은 두 겹의 고객, 10배의 이해관계자, 보이지 않는 성과, 설득이 필요한 스토리, 강제가 통하지 않는 도입, 그리고 버전 의존성이라는 여섯 가지 어려움을 동시에 다루는 역할입니다. 기술 이해만으로는 부족하고, 탁월한 커뮤니케이션과 이해관계자 관리, 스토리텔링 능력까지 갖춰야 비로소 제대로 된 플랫폼 PM이 될 수 있어요. 플랫폼을 플랫폼이 아니라 제품처럼 바라보는 것, 그게 출발점이에요. 지금 플랫폼 PM으로 일하고 계신 분들이라면 이 글이 조금이나마 위안이 됐으면 좋겠습니다.