7년 동안 IT 업계에서 프로젝트 매니저(PM)로 일해오면서, 종종 듣는 질문이 있어요.
“PM은 그냥 일 시키는 사람이죠?” 혹은 “PM이 기획도 하죠?”
정확히 어떤 역할인지 묻는 사람도 있고, 이미 정해진 인식을 내게 확인받고 싶어 하는 경우도 있어요.
사실 저도 처음엔 이 역할을 정확히 모르고 시작했는데요.
기획자인 줄 알았고, 개발자들 사이에 일을 조율하는 사람인 줄 알았고, 회의 정리나 스프레드시트 잘 다루는 사람인 줄 알았죠.
하지만 7년이 지난 지금, 어느 정도는 그 질문에 답할 수 있게 된 것 같아요.
그래서 오늘은 이 얘기를 한번 풀어보려고요.
PM이 ‘기획자’로 오해받는 건 정말 흔해요. 특히 스타트업이나 소규모 조직에서는 기획자와 PM을 한 사람이 동시에 맡는 경우가 많기 때문에 더더욱 헷갈리죠.
하지만 ‘기획’이라는 역할은 사용자 경험 중심의 UX 기획, 기능과 흐름을 설계하는 서비스 기획, 콘텐츠나 비즈니스 전략을 세우는 마케팅 기획 등 여러 갈래가 있어요.
그중에서 PM이 담당하는 기획은 “프로젝트를 성공시키기 위한 흐름을 설계하는 기획”에 가깝습니다.
예를 들어 신규 웹 서비스를 런칭한다고 했을 때, 기획자는 어떤 기능이 필요한지 정의하고 화면 흐름을 설계하죠.
PM은 그 다음 단계, 이 기획이 현실이 되기까지의 모든 진행 상황을 설계하고 통제합니다.
예산, 일정, 우선순위, 리소스 배분, 커뮤니케이션, 리스크 관리까지요.
PM을 ‘일 시키는 사람’으로 보는 시각도 많아요.
“PM은 기획자한테 받은 요구사항을 개발자한테 전달하고, 일정 맞춰서 닦달만 하는 거 아닌가요?”
이 말도 아주 틀린 말은 아니에요. 하지만 단순 전달자라면 PM은 존재할 필요가 없겠죠.
요즘엔 Notion, Slack, Jira 같은 협업 툴이 발달해 있어서 누구나 할당된 업무를 바로 확인할 수 있어요.
그럼에도 불구하고 여전히 PM이 필요한 이유는, ‘정보’가 아니라 ‘의도’를 전달하는 역할이기 때문이에요.
기획서에 담기지 않은 맥락, 회의에서 스치듯 나온 우선순위, 클라이언트의 눈빛 한 줄기에서 느껴지는 미묘한 분위기까지 PM은 그것들을 읽고 해석하고, 상황에 맞게 팀을 이끄는 사람이에요.
그리고 그 와중에도 모두가 제자리를 지키며 협업할 수 있게 만드는 설계자이기도 하죠.
한 프로젝트에 디자이너, 개발자, 클라이언트, 마케터, 운영 담당자 등 다양한 이해관계자가 존재해요.
이들 사이의 소통을 단순히 ‘전달’만으로 해결할 수 있을까요?
사실 이 과정은 항상 불완전하고, 예측 불가하고, 갈등의 연속이에요.
누군가는 일정 때문에 불만을 품고, 누군가는 기획이 자꾸 바뀌어서 힘들다고 하고, 누군가는 리소스 부족으로 퇴사 위기를 말하기도 하죠.
이럴 때 PM은 중간에서 모든 말을 듣고, 받아들이고, 다시 설계해서 ‘모두가 합의할 수 있는 다음 단계’를 만들어요.
그래서 전 PM을 ‘프로젝트의 설계자’이자 ‘팀의 심리적 조율자’라고 생각해요.
기획서 한 장 없이 시작한 프로젝트도, PM이 있는 팀과 없는 팀은 완전히 다른 결과를 낼 수 있거든요.
성공하는 프로젝트 뒤에는 항상 보이지 않는 PM의 고군분투가 있어요.
지금도 어디선가 야근하며 이슈 트래킹을 하고 있는 PM들,
슬랙과 노션, 지라, 피그마, 메일함을 동시에 열어놓고 하루를 버티는 PM들,
아무도 모르게, 조용히, 묵묵히 팀을 이끌어가는 PM들.
우리는 단순한 전달자가 아니고, 혼자 다 떠안는 슈퍼 히어로도 아니에요.
그저 답이 없다는 걸 알지만 답을 찾기 위해 끝까지 고민하는 사람이에요.
오늘도 프로젝트를 향해 달려가는 모든 PM분들, 정말 수고 많으셨고, 우리 모두 화이팅이에요.
아, 그리고 최근에 재밌게 본 현업 PM의 인터뷰 글이 하나 있는데요.
링크 남겨두고 인사드리겠습니다~~ 감사합니다.