PM 포트폴리오는 어떻게 작성해야 할까: 주니어 PM과 이직 준비자를 위한 실전 가이드

PM을 준비하거나 이직을 고민하기 시작하면 결국 같은 질문에 도달합니다.

PM 포트폴리오는 대체 뭘 보여줘야 할까.

문서를 예쁘게 정리하는 것만으로는 부족합니다. 그렇다고 프로젝트를 많이 나열한다고 해결되지도 않죠. 기업이 보고 싶은 건 산출물의 양이 아니라, 그 사람이 어떤 문제를 어떻게 정의하고 판단했는지입니다. 결국 PM 포트폴리오는 ‘작업 모음집’이 아니라 ‘판단의 기록’이어야 합니다.

---

 

PM 포트폴리오가 중요한 이유

PM은 개발자처럼 코드를 제출하는 직무도 아니고, 디자이너처럼 화면 결과물만으로 평가되는 직무도 아닙니다.

그래서 채용 과정에서는 이 사람이 실제로 어떤 식으로 사고했고, 무엇을 근거로 결정했고, 어떤 방식으로 협업했는지를 포트폴리오를 통해 확인하려고 합니다.

 

특히 주니어 PM 포트폴리오와 이직용 PM 포트폴리오는 공통점이 있습니다.

둘 다 “무엇을 했다”보다 “왜 그렇게 했는가”가 더 중요하다는 점입니다.

 

즉, 좋은 PM 포트폴리오는 이런 질문에 답할 수 있어야 합니다.

• 어떤 문제를 다뤘는가
• 왜 그 문제가 중요했는가
• 어떤 선택지를 검토했는가
• 왜 그 방향으로 결정했는가
• 실행 이후 무엇을 확인했는가
• 무엇을 배웠는가

 

이 여섯 가지가 비어 있으면, 포트폴리오는 금방 얕아 보입니다.

---

 

PM 포트폴리오에서 기업이 실제로 보는 것

많은 지원자가 포트폴리오를 “내가 열심히 한 프로젝트 소개 자료”처럼 만듭니다.

하지만 채용 담당자나 현업 PM이 보는 포인트는 다릅니다.

 

기업이 보는 핵심 관점

보는 항목	채용 담당자가 확인하고 싶은 것	흔한 실수
문제 정의	이 사람이 문제를 스스로 구조화할 수 있는가	문제 없이 바로 해결안부터 제시함
우선순위 판단	왜 이 일을 먼저 해야 했는지 설명 가능한가	중요해 보여서 했다고만 설명함
사용자 이해	사용자의 불편과 맥락을 이해했는가	사용자 관점 없이 기능만 설명함
비즈니스 감각	서비스 성과와 연결해서 생각했는가	예쁜 기능 제안으로 끝남
협업 방식	개발/디자인/운영과 어떻게 일했는가	“협업했다”는 말만 있고 방식이 없음
회고/학습	결과를 보고 수정할 수 있는가	성공 사례만 쓰고 배운 점이 없음

포트폴리오를 읽는 사람은 “이 사람이 PM처럼 생각하는가”를 봅니다.

결국 문서의 디자인보다 논리 구조가 먼저입니다.

---

 

PM 포트폴리오의 기본 구조는 어떻게 잡아야 할까

좋은 PM 포트폴리오는 프로젝트 수보다 구조의 일관성이 중요합니다.

프로젝트마다 아래 구조를 통일해서 쓰면 읽는 사람이 훨씬 빠르게 이해할 수 있습니다.

 

추천 기본 구조

순서	섹션명	반드시 들어가야 할 내용
1	프로젝트 개요	프로젝트명, 기간, 역할, 팀 구성, 서비스 맥락
2	문제 정의	어떤 문제가 있었는지, 왜 중요한지
3	목표 설정	무엇을 개선하려 했는지, 성공 기준은 무엇인지
4	분석 과정	사용자 조사, 데이터, VOC, 퍼널, 경쟁사 분석 등
5	핵심 판단	여러 선택지 중 무엇을 택했고 왜 그랬는지
6	실행 내용	실제로 어떤 기능/정책/프로세스를 만들었는지
7	협업 방식	누구와 어떤 이슈를 조율했는지
8	결과와 회고	성과, 한계, 배운 점, 다음 액션

이 구조는 신입에게도 좋고, 이직 준비자에게도 좋습니다.

왜냐하면 경험의 깊이가 달라도 사고의 틀은 동일하게 보여줄 수 있기 때문입니다.

---

 

PM 포트폴리오에서 가장 중요한 것은 문제 정의입니다

PM 포트폴리오의 승부처는 대개 여기서 갈립니다.

대부분의 문서는 해결안 설명에 많은 분량을 쓰지만, 정작 채용에서 더 중요한 건 문제를 얼마나 정확히 잡았는가입니다.

 

예를 들어 이런 식입니다.

 

나쁜 예시

“사용자 편의를 위해 예약 화면을 개선했습니다.”

 

이 문장은 너무 약합니다.

왜 개선해야 했는지 전혀 보이지 않기 때문입니다.

 

좋은 예시

“예약 시작 단계에서 이탈률이 62%로 높았고, VOC에서는 ‘선택해야 할 정보가 많아 복잡하다’는 반응이 반복적으로 확인됐습니다. 이에 따라 예약 초기 단계의 선택 부담을 줄이는 방향으로 화면 구조를 재설계했습니다.”

 

이건 다릅니다.

문제의 존재가 보이고, 해결 방향의 근거도 보입니다.

 

즉, PM 포트폴리오 예시에서 좋은 문장은 늘 같은 특징을 갖습니다.

현상을 말하고, 근거를 붙이고, 판단 방향을 연결합니다.

---

 

주니어 PM 포트폴리오와 이직용 PM 포트폴리오는 무엇이 다를까

두 포트폴리오는 기본 구조는 비슷하지만, 강조점이 다릅니다.

 

주니어 PM과 이직 PM 포트폴리오의 차이

구분	주니어 PM 포트폴리오	이직용 PM 포트폴리오
핵심 평가 포인트	사고력, 문제 정의, 잠재력	성과, 영향력, 판단 수준
강조할 경험	프로젝트 경험, 운영 경험, 분석 과정	실제 성과, 의사결정, 조직 기여
좋은 사례	사이드프로젝트라도 운영과 개선 경험이 있음	실서비스에서 KPI나 프로세스를 바꾼 경험
주의할 점	화면 설계 위주로 끝내지 말 것	단순 업무 나열형 경력기술서가 되지 말 것
설득 방식	“이 사람은 PM처럼 생각할 수 있구나”	“이 사람은 이미 PM으로 성과를 냈구나

주니어라면 결과 숫자가 크지 않아도 됩니다.

대신 생각의 깊이가 보여야 합니다.

반대로 이직 준비 중인 PM이라면 “기여했다”가 아니라 어떤 기여를 했고, 그 판단이 어떤 결과로 이어졌는지를 더 분명하게 보여줘야 합니다.

---

 

PM 포트폴리오에 꼭 넣어야 할 프로젝트 수는 몇 개일까

이 질문도 많이 나옵니다.

결론부터 말하면 많을 필요 없습니다.

오히려 2~3개를 깊게 쓰는 편이 낫습니다.

 

추천 프로젝트 수

지원 단계	추천 프로젝트 수	설명
신입/주니어 PM	2~3개	많기보다 깊이가 중요
2~5년차 PM 이직	2개 핵심 + 1개 보조	성과가 있는 프로젝트 중심
5년차 이상 PM	2개 중심	영향력이 큰 사례 위주로 압축

포트폴리오를 많이 넣으면 풍부해 보일 것 같지만, 실제로는 반대인 경우가 많습니다.

프로젝트가 많아질수록 하나하나가 얕아지고, 결국 “많이 했지만 깊이는 없다”는 인상을 줄 수 있습니다.

---

 

PM 포트폴리오는 어떤 문장으로 써야 할까

문체도 중요합니다.

포트폴리오는 보고서이면서 동시에 설득 문서입니다. 너무 딱딱하면 읽히지 않고, 너무 가벼우면 신뢰가 떨어집니다.

 

추천하는 방식은 이렇습니다.

 

문장 작성 원칙

원칙	설명	예시
현상 먼저	문제 상황을 먼저 제시	“가입 완료율이 낮았습니다.”
근거 연결	숫자나 사용자 반응을 붙임	“특히 2단계 이탈이 48%로 높았습니다.”
판단 명시	왜 그런 결정을 했는지 적음	“입력 부담을 낮추는 방향으로 우선 개선했습니다.”
결과 분리	실행과 결과를 구분해서 씀	“개선 후 완료율이 12%p 상승했습니다.”
배운 점 포함	잘된 점보다 학습까지 적음	“다만 초기 가설은 일부 빗나갔고…”

즉, 포트폴리오는 “열심히 했습니다”가 아니라

“이 상황에서 이런 판단을 했고, 그 결과는 이랬습니다”의 연속이어야 합니다.

---

 

실전 예시 1: 주니어 PM 포트폴리오 프로젝트 예시

아래는 주니어 PM이 많이 다루는 형태의 예시입니다.

단순 화면 개선 프로젝트를 어떻게 PM다운 구조로 바꿀 수 있는지 보여드리겠습니다.

 

프로젝트 개요

• 프로젝트: 모바일 예약 화면 개선
• 역할: PM
• 기간: 6주
• 팀 구성: 디자이너 1명, 개발자 2명, PM 1명

 

흔한 나쁜 작성 방식

“기존 예약 화면이 복잡해서 사용성이 떨어졌고, 이를 개선하기 위해 UI를 개편했습니다. 날짜 선택 방식과 옵션 선택 방식을 바꿨고, 디자인을 더 직관적으로 변경했습니다.”

 

이건 디자이너 결과물 설명에 가깝습니다.

 

더 좋은 작성 방식

항목	예시
문제 정의	예약 진입 후 첫 단계에서 이탈률이 62%로 높았고, VOC에서 ‘선택지가 많아 시작부터 복잡하다’는 의견이 반복적으로 확인됐습니다.
목표	예약 시작 단계 이탈률을 낮추고, 다음 단계 진입률을 개선하는 것을 목표로 설정했습니다.
분석	예약 퍼널 데이터를 확인한 결과 첫 화면에서 옵션 선택과 날짜 선택이 동시에 요구되면서 인지 부담이 높아지는 구조였습니다.
핵심 판단	옵션을 한 화면에 모두 노출하는 대신, 사용자의 선택 흐름에 맞춰 단계를 분리하는 방향을 택했습니다.
실행	날짜 선택을 먼저 하도록 구조를 바꾸고, 옵션은 이후 단계에서 맥락에 맞게 제시했습니다.
결과	다음 단계 진입률이 18%p 개선됐고, CS 문의 중 ‘예약 방법이 어렵다’는 유형이 감소했습니다.
회고	초기에는 옵션 자체를 줄이는 방향을 검토했지만, 실제 원인은 옵션 수보다 선택 순서의 문제라는 점을 확인했습니다.

이런 식이면 훨씬 낫습니다.

문제, 분석, 판단, 실행, 결과가 살아 있기 때문입니다.

---

 

실전 예시 2: 이직용 PM 포트폴리오 프로젝트 예시

이직 포트폴리오는 더 직접적이어야 합니다.

“참여했다”는 표현보다 “어떤 결정을 주도했고 어떤 결과를 만들었는가”를 보여줘야 합니다.

 

프로젝트 개요

• 프로젝트: 멤버십 구매 전환율 개선
• 역할: PM
• 기간: 3개월
• 팀 구성: PM 1명, 개발 3명, 디자이너 1명, 마케팅 1명

 

이직용 PM 포트폴리오 예시

항목	예시
문제 정의	멤버십 상세 페이지 유입 대비 구매 전환율이 정체돼 있었고, 혜택 이해도가 낮아 이탈이 반복됐습니다.
비즈니스 맥락	멤버십은 리텐션과 재구매에 직접 연결되는 핵심 상품이었기 때문에, 전환율 개선 우선순위가 높았습니다.
분석	유저 인터뷰와 클릭 데이터 분석 결과, 사용자는 혜택이 많다는 점은 인식했지만 ‘내게 실제로 이득인지’ 빠르게 판단하지 못했습니다.
핵심 판단	혜택을 많이 보여주는 방식보다, 대표 혜택의 금전적 체감 가치를 먼저 제시하는 구조가 필요하다고 판단했습니다.
실행	혜택 영역을 요약형으로 재구성하고, 예상 절감 금액 메시지를 상단에 배치했습니다. 마케팅 문구도 혜택 나열형에서 사용 맥락형으로 변경했습니다.
협업	마케팅과는 메시지 우선순위를 조율했고, 개발팀과는 실험 범위와 이벤트 로그 설계를 정리했습니다.
결과	A/B 테스트 결과 구매 전환율이 9.4% 상승했고, 상세 페이지 이탈률은 11% 감소했습니다.
회고	혜택 자체보다 정보의 해석 비용이 더 큰 문제였다는 점을 확인했습니다. 이후 다른 구독 상품 상세 페이지에도 동일한 프레임을 확장했습니다.

이 정도는 되어야 이직용 포트폴리오답습니다.

단순 참여 이력이 아니라 판단과 영향력이 보입니다.

---

 

PM 포트폴리오에서 자주 나오는 실수

좋은 방향을 아는 것만큼, 피해야 할 실수도 중요합니다.

 

자주 나오는 실패 패턴

실수	왜 문제인가	개선 방법
화면만 잔뜩 넣음	문제 해결보다 결과 화면 설명으로 보임	문제 정의와 판단 근거를 먼저 배치
프로젝트 개요가 너무 김	핵심 전에 독자가 지침	개요는 짧게, 본론은 빠르게
“협업했습니다”로 끝남	실제 역할이 보이지 않음	누구와 무엇을 조율했는지 구체화
데이터 없이 감으로 씀	설득력이 약해짐	정량/정성 근거 최소 하나 제시
성과만 쓰고 배움이 없음	깊이가 얕아 보임	실패, 한계, 수정 포인트까지 작성
너무 많은 프로젝트 수록	전반적으로 얕아짐	핵심 사례 중심으로 압축

이건 정말 자주 보입니다.

포트폴리오를 예쁘게 만들수록 오히려 이런 구조적 약점이 더 잘 안 보일 때도 있습니다. 그래서 더 위험하죠.

---

 

PM 포트폴리오를 바로 만들기 위한 템플릿

실제로 따라 하기 쉽게, 바로 복붙해서 쓸 수 있는 형태로 템플릿을 드리겠습니다.

 

프로젝트별 작성 템플릿

섹션	작성 질문
프로젝트 개요	어떤 서비스였나? 내 역할은 무엇이었나?
문제 정의	어떤 문제가 있었고, 왜 중요했나?
목표	무엇을 개선하려 했나? 성공 기준은 무엇이었나?
분석	어떤 데이터, 인터뷰, VOC, 관찰을 활용했나?
선택지 검토	어떤 대안이 있었고 왜 이 방향을 선택했나?
실행	실제로 무엇을 만들고 바꿨나?
협업	누구와 어떤 이슈를 맞췄나?
결과	어떤 변화가 있었나? 수치나 반응은 어땠나?
회고	다시 한다면 무엇을 다르게 할까?

이 템플릿만 잘 써도 포트폴리오의 절반은 정리됩니다.

---

 

PM 포트폴리오 작성 순서

많은 사람이 처음부터 PPT를 열고 디자인부터 시작합니다.

그런데 순서는 반대여야 합니다.

 

추천 작성 순서

단계	해야 할 일
1	프로젝트 후보 5개를 먼저 적는다
2	각 프로젝트별 문제 정의와 성과 유무를 검토한다
3	가장 설명력이 높은 2~3개만 고른다
4	각 프로젝트를 템플릿 기준으로 글로 먼저 쓴다
5	빠진 근거, 숫자, 협업 디테일을 채운다
6	그다음에야 슬라이드나 문서 디자인을 입힌다

즉, 포트폴리오는 디자인 작업이 아니라 구조화 작업입니다.

이 순서를 지켜야 내용이 살아납니다.

---

 

PM 포트폴리오를 준비하는 사람이 지금 바로 해야 할 일

여기서 중요한 건 읽고 끝내지 않는 겁니다. 바로 실행해야 합니다.

 

오늘 바로 할 일 체크리스트

해야 할 일	설명
프로젝트 5개 적기	작든 크든 경험을 먼저 펼쳐놓기
문제-성과 기준으로 압축하기	설명력이 약한 프로젝트는 제외
템플릿 기준으로 초안 쓰기	PPT보다 문장 초안이 먼저
숫자와 근거 보강하기	VOC, 지표, 회고 포인트 정리
한 프로젝트를 깊게 다듬기	여러 개 동시에 하지 말고 하나부터 완성

이 단계까지 가면, 포트폴리오는 갑자기 훨씬 현실적인 문서가 됩니다.

막연했던 준비가 실행 단계로 넘어가는 지점이죠.

---

 

결론: PM 포트폴리오는 결과물이 아니라 판단을 증명하는 문서입니다

좋은 PM 포트폴리오는 “제가 이런 걸 만들었습니다”로 끝나지 않습니다.

그보다 더 중요한 것은, 왜 이 문제를 선택했고, 어떤 근거로 판단했으며, 무엇을 바꾸고 무엇을 배웠는지를 보여주는 것입니다.

 

주니어 PM이라면 잠재력을 보여줘야 합니다.

이직 준비 중인 PM이라면 이미 만들어낸 영향력을 보여줘야 합니다.

둘 다 공통점은 같습니다. 산출물보다 사고 과정이 먼저라는 점입니다.

 

결국 포트폴리오는 화려한 문서 대회가 아닙니다.

PM처럼 생각한 흔적을 얼마나 설득력 있게 남겼는가의 문제입니다.

 

그리고 이건 생각보다 거창한 프로젝트가 없어도 가능합니다.

작은 프로젝트라도 좋습니다. 다만 깊게 써야 합니다.

문제, 판단, 실행, 결과, 회고. 이 다섯 가지를 끝까지 밀어붙이면 됩니다.

 

앞으로 PM 채용은 더 쉽게 열리지 않을 가능성이 큽니다.

그럴수록 포트폴리오는 더 중요해집니다.

그래서 묻는 방식도 달라져야 합니다.

“무엇을 넣을까?”가 아니라, “내가 PM처럼 판단한 장면을 어떻게 증명할까?”를 먼저 생각해야 합니다.

---

함께 보면 좋은 글들

기능 조직 vs 제품 조직에서의 PM 역할 차이: 정의·책임·성과 기준

기능 조직 vs 제품 조직에서의 PM 역할 차이: 정의·책임·성과 기준

PM이 기술을 배워도 실력이 안 느는 이유

PM이 기술을 배워도 실력이 안 느는 이유

PM vs PO vs Planner 역할 비교: 기획 직무의 진화와 핵심 차이

PM vs PO vs Planner 역할 비교: 기획 직무의 진화와 핵심 차이