서비스 기획 (PM) 실무 알아보기
목차
1. PM 한 줄 넣었다가 광탈하는 전형적인 패턴
지원자분들의 이력서를 보면 직무란에 PM, 서비스 기획, Product Manager를 적어 놓고도 실제 내용은 전혀 PM이 아닐 때가 많습니다. 문제는 회사가 이걸 “허풍” 혹은 “직무 이해 부족”으로 판단한다는 점입니다. 실제 실무에서는 지원자가 어떤 타이틀을 썼는지보다, 그 타이틀을 쓸 만큼 제품과 비즈니스에 책임을 지고 일해본 사람인지부터 검증합니다. 그래서 애매한 경험에 PM을 덧씌우면, 역량의 부족보다 “직무를 얕게 이해한다”는 인상을 먼저 주게 되고, 이게 곧바로 탈락 사유가 됩니다.
2. 회사가 보는 ‘진짜 PM’의 정의
PM, 서비스 기획자를 현업에서 어떻게 정의하느냐에 따라 이력서 평가 기준이 완전히 달라집니다. 채용하는 입장에서 PM은 다음 요소로 구분합니다. 첫째, 문제 정의 책임입니다. 주어진 요구사항을 문서로 정리하는 사람이 아니라, “어떤 고객 문제를 왜 지금 해결해야 하는가”를 스스로 정의해본 사람인지부터 봅니다. 둘째, 우선순위와 의사결정입니다. 모든 요구를 다 담는 기획이 아니라, 제한된 리소스 안에서 무엇을 먼저 할지, 무엇을 버릴지 스스로 결정해 본 경험을 중요하게 봅니다. 셋째, 협업 리더십입니다. 개발, 디자인, 운영, 마케팅 사이에서 실무를 조율하고, 갈등을 풀고, 일정과 품질을 동시에 맞추려고 애써본 사람인지가 핵심입니다. 넷째, 결과 책임입니다. “기획서까지가 내 일”이 아니라, 출시 이후 성과를 수치로 확인하고, 잘못된 가설을 수정해가며 끝까지 제품을 끌고 가본 사람인지부터 확인합니다. 이 네 가지가 전혀 보이지 않는데 타이틀만 PM이라 적혀 있으면, 회사는 그 이력서를 과감하게 걸러냅니다.... 더보기
3. 이력서에서 바로 티 나는 ‘가짜 PM’ 신호
실무자들은 서류를 볼 때 몇 가지 신호로 지원자를 빠르게 분류합니다. 다음 항목이 많이 보일수록 “PM 역량 미흡”으로 판단하게 됩니다. 첫째, ‘문서 생산자’처럼 보이는 경우입니다. “요구사항 정의서 작성”, “화면 기획서 작성”, “스토리보드 작성” 등 산출물 나열만 있고, 왜 그 기획을 했는지, 어떤 문제를 해결했는지, 어떤 결과가 나왔는지에 대한 맥락이 없습니다. 둘째, 직무 용어를 나열만 하는 경우입니다. “AARRR, 펀널 분석, 가설 검증, 데이터 기반 기획” 같은 키워드를 적어두고 실제로 어떤 데이터로 어떤 의사결정을 했는지 사례가 전혀 없는 경우가 가장 대표적입니다. 셋째, 본인 역할이 흐릿한 경우입니다. “서비스 기획 프로젝트 참여”, “앱 리뉴얼 참여” 같은 표현만 있고, 구체적으로 본인이 결정한 것, 주도한 것, 실패하고 수정한 것이 무엇인지 드러나지 않습니다. 넷째, 숫자가 전혀 없는 경우입니다. “이용자 만족도 향상”, “전환율 개선”, “유입 증가”처럼 정성적 표현만 있고, 몇 퍼센트, 어느 정도 기간, 어떤 기준에서 개선되었는지에 대한 수치가 없습니다. 이 신호들 때문에 “PM 쓴 이력서”가 아니라 “PM을 잘 모르는 사람의 이력서”라고 판단되어 초반에 걸러집니다.
4. 신입·취준생이 특히 오해하는 PM의 실무
취업준비생 분들이 특히 많이 착각하는 포인트가 있습니다. 이 오해가 풀리지 않으면 이력서부터 방향이 완전히 틀어집니다. 첫째, “아이디어 내는 직무”라는 오해입니다. 실제 PM은 아이디어보다 “문제 정의”와 “우선순위 결정” 비중이 훨씬 큽니다. 좋은 아이디어를 많이 냈다는 이야기는 평가에서 거의 의미가 없습니다. 둘째, “모든 걸 결정하는 오너”라는 오해입니다. 실무에서는 개발, 디자인, 사업, 운영, 보안, 법무 등 수많은 이해관계자 사이에서 끊임없이 설득과 타협을 해야 하는 직무입니다. 권한보다 책임이 훨씬 앞서기 때문에, ‘내가 다 정한다’는 태도는 되려 감점 요소입니다. 셋째, “문서만 잘 쓰면 된다”는 오해입니다. 기획서는 결과물이지 핵심 역량이 아닙니다. 회의에서 논리를 세워 설득하고, 데이터를 해석해 가설을 재설정하고, 제품을 직접 써가며 문제를 찾는 과정이 중요합니다. 문서만 강조된 이력서는 금방 티가 납니다. 넷째, “신입 PM 포지션이 많다”는 오해입니다. 대부분의 회사는 PM에게 난이도 높은 의사결정을 요구하기 때문에, 2~3년 이상 어떤 영역에서든 실무 경험이 있는 사람을 선호합니다. 신입 타이틀로 지원할수록 “경험 대비 과한 타이틀”이라는 인식을 심어주기 쉽습니다.
5. 그럼 신입은 PM을 절대 쓰면 안 될까?
신입이 PM이라는 말을 이력서에 절대 쓰지 말라는 뜻은 아닙니다. 다만, 타이틀을 전면에 내세우기보다 “PM을 향해 가는 과정”을 솔직하게 보여주는 전략이 필요합니다. 첫째, 포지션명은 낮추고, 역할 설명에서 PM 성향을 드러내는 방식이 좋습니다. 예를 들어, 학생 때 프로젝트를 했다면 직책은 팀원, 기획 담당 정도로 쓰되, 활동 내용에서 “문제 정의, 지표 설정, 우선순위 결정, 일정 조율, 이해관계자 설득” 같은 PM 코어 업무를 구체적으로 풀어냅니다. 둘째, 직무 희망은 ‘주니어 PM/서비스 기획’으로 명확히 적되, 본인이 아직 실무 경험이 없는 단계임을 전제로 겸손하게 포지셔닝합니다. 즉, “저는 이미 PM입니다”가 아니라 “PM이 요구하는 역량을 작은 프로젝트에서 실험해본 상태입니다”라는 메시지를 주는 것이 좋습니다. 셋째, 초기 커리어 타이틀을 PM에 집착하지 않는 것도 전략입니다. 운영, 마케터, 데이터 분석 인턴, 서비스 오퍼레이션 등에서 시작해도, 그 안에서 PM스러운 문제 해결 경험을 쌓으면 2~3년차에 훨씬 자연스럽게 PM 전환 기회를 잡을 수 있습니다.... 더보기
6. 이력서를 ‘PM 눈’으로 다시 쓰는 방법
지금 가지고 있는 경험이 많지 않더라도, 정리 방식만 바꿔도 서류의 무게감이 달라집니다. 현직자가 실제로 보는 기준에 맞춰 이력서를 다시 구조화해보시길 권합니다. 첫째, 모든 경험을 “문제 – 선택 – 실행 – 결과” 구조로 정리합니다. 어떤 상황에서 어떤 문제를 발견했고, 여러 대안 중 무엇을 왜 선택했는지, 실행 과정에서 어떤 역할을 했는지, 결과가 어땠는지까지 한 줄씩이라도 채워 넣습니다. 둘째, 가능한 모든 경험에 숫자를 붙입니다. “앱 이용자 피드백을 반영해 UX를 개선했습니다”가 아니라, “주 1회 10명 인터뷰를 4주 진행해 공통 불만 3가지 도출, 그 중 A를 우선 개선하여 전환율 12%p 개선”처럼 표현합니다. 수치가 작아도 솔직하게 적는 편이 신뢰를 줍니다. 셋째, 팀 안에서의 조율 경험을 강조합니다. 개발자, 디자이너, 운영자, 심지어 동아리 동기들과 일정·역할을 어떻게 나누고, 갈등을 어떻게 풀었는지 구체적으로 적어야 PM 서류로 보입니다. 단순 협업이 아니라 “이견을 조정해 결론을 이끌어낸 경험”이 핵심입니다. 넷째, 산출물보다 의사결정에 쓴 근거를 보여줍니다. “기획서 작성”이라는 문장 아래에, 어떤 인터뷰, 어떤 로그, 어떤 경쟁 서비스 리서치를 근거로 기획 방향을 잡았는지 한두 줄만 추가해도 수준이 전혀 다르게 보입니다.
7. 지금 단계에서 반드시 쌓아야 할 실무형 경험
취업준비생에게 가장 현실적인 액션은 “작게라도 진짜 제품을 다뤄보는 것”입니다. 이력서에 PM을 쓸지 말지보다, 적을 만한 경험을 만드는 게 우선입니다. 추천하는 축적 방식은 다음과 같습니다. 첫째, 완주 기준의 사이드 프로젝트를 1~2개 만듭니다. 기획안에서 끝나는 프로젝트보다, 실제 배포까지 간 경험 1개가 훨씬 강력합니다. 토이 앱, 웹서비스, 노코드 툴(anyform, Notion, Glide 등)을 써도 좋으니, 실제 사용자가 써볼 수 있는 형태까지 가져가 보시길 권합니다. 둘째, 사용자 인터뷰와 데이터 수집을 직접 해봅니다. 지인 5명, 타겟 유저 5명만 인터뷰해도 좋습니다. 설문만 돌리지 말고, 실제로 사용 장면을 보면서 문제를 발견하고, 그 내용을 문서로 정리해보는 경험이 중요합니다. 셋째, 협업형 프로젝트를 반드시 경험합니다. 개발자·디자이너와 함께하는 교내/온라인 프로젝트, 부트캠프, 동아리 활동 등을 통해 일정 관리, 스펙 조율, 우선순위 논의를 실제로 경험해야 합니다. 개인 프로젝트만으로는 PM 역량을 보여주기 어렵습니다. 넷째, 운영/고객응대에 가까운 경험도 적극적으로 활용합니다. 고객센터, 서비스 운영, 오퍼레이션 아르바이트 등에서 접한 고객 문의 패턴을 정리하고, 이를 토대로 “어떤 개선을 제안했고 무엇이 수용/거절되었는지”를 정리해두면, 지원 시 강력한 PM 지향 경험으로 풀어낼 수 있습니다.
8. 취준 로드맵: 3개월 액션 플랜
구체적인 행동 계획이 없으면, 직무 이해만 늘고 이력서는 그대로인 상태로 시간이 흐릅니다. 3개월 기준으로 현실적인 플랜을 제안드립니다. 1주차~4주차: 직무 이해와 경험 인벤토리 정리 - PM 관련 서적/콘텐츠를 하루 1시간 이내로만 보고, 나머지 시간은 본인 경험을 “문제 – 선택 – 실행 – 결과” 구조로 정리합니다. - 지금까지 했던 프로젝트, 대외활동, 과제, 아르바이트를 모두 나열하고, 그중 PM스러운 요소가 있는 경험을 골라 스토리를 만듭니다. 5주차~8주차: 작은 서비스 하나를 실제로 만들어보기 - 노코드든, 간단한 웹·앱이든 형태는 상관 없으니, 특정 타겟의 문제 하나를 골라 해결하는 서비스를 기획하고 최소 기능으로 출시합니다. - 이 과정에서 기능 요청이 들어올 때마다 무엇을 먼저/나중으로 할지 우선순위를 기록하고, 그 이유를 문서로 남겨두면 이력서·포트폴리오에 바로 사용 가능합니다. 9주차~12주차: 이력서·포트폴리오 고도화와 지원 - 상기 프로젝트와 기존 경험을 모두 PM 관점으로 재정리해, “어떤 문제를 어떻게 정의했고, 협업과 데이터로 어떤 결정을 했으며, 결과는 어땠는지” 중심으로 작성합니다. - 인턴, 주니어 PO/PM, 서비스 운영·기획 인턴 등 인접 포지션까지 넓게 지원하면서, 서류와 과제, 면접에서 동일한 스토리 라인을 유지합니다. 이때 이력서에 PM을 쓸지 여부는 경험의 밀도에 따라 조정하되, 과한 타이틀만 피하는 방향으로 가시는 것이 좋습니다.... 더보기
9. 마무리: 타이틀보다 ‘직무 진실성’이 먼저입니다
PM이라고 썼다가 떨어지는 핵심 이유는 대부분 역량의 절대치보다 “타이틀과 내용의 불일치” 때문입니다. 회사는 신입에게 완성된 PM을 요구하지 않습니다. 다만, PM이 무엇을 하는 직무인지 이해하고, 작은 환경에서라도 그 역할을 실험해본 사람을 찾습니다. 따라서 지금 당장 해야 할 일은 멋진 타이틀을 붙이는 것이 아니라, 작게라도 문제를 정의하고, 사람들과 협업해 해결해 보고, 그 과정을 숫자와 스토리로 정리해두는 것입니다. 이 과정을 충실히 밟고 나면, 이력서에 PM이라는 세 글자를 적더라도 더 이상 허풍이 아니라, “아직 작지만 분명히 같은 일을 해본 사람”으로 읽히게 됩니다. 그 지점부터 비로소 서류가 통과되기 시작합니다.
