PM·PO 이력서 작성법 가이드

PM 이력서가 유독 어려운 이유

이력서를 앞에 두고 막히는 순간, 대개 재료가 없어서가 아닙니다. 몇 년간 기획 문서를 쓰고 지표를 보고 팀을 설득해 왔는데, 그 일들이 이력서 문장으로는 잘 옮겨지지 않습니다.

개발자에게는 만든 것이 남고 디자이너에게는 화면이 남습니다. PM·PO가 한 일은 대부분 판단이고, 판단은 결과물의 형태로 남지 않습니다. 남아 있는 것은 그때 쓴 문서들인데, 그 문서는 회사 안에서 통하는 언어로 쓰여 있습니다. 그래서 이력서 쓰기는 기억을 되살리는 일이라기보다 번역에 가깝습니다.

번역이라고 보면 순서가 정리됩니다. 먼저 원문을 모으고(무엇을 쓸 것인가), 그다음 옮길 형식을 정하고(어떻게 구성할 것인가), 마지막으로 읽는 사람에 맞춰 다듬습니다. 아래는 그 세 단계를 차례로 다룹니다.

무엇을 쓸 것인가 — 재료가 있는 자리

기억에서 시작하면 인상적인 몇 개만 떠오르고 나머지는 묻힙니다. 대신 이미 남아 있는 문서에서 출발하면 빠짐이 줄어듭니다. PM·PO에게는 아래 넷이 사실상 경력 기록입니다.

• 기획 문서(PRD·정의서)— 무엇을 왜 만들기로 했는지가 배경 단락에 남아 있습니다. 이력서에서 가장 자주 비는 ‘문제’ 조각이 여기 있습니다.
• 회고·릴리즈 노트 — 무엇이 예상과 달랐는지가 적혀 있습니다. 판단력을 보여주는 재료는 성공보다 여기에 많습니다.
• 실험·분석 기록 — 가설과 결과의 쌍. 접기로 한 결정도 성과입니다.
• 운영 지표 — 매일 보던 대시보드. 담당 지표가 아니어도 변화폭은 씁니다.

이 단계에서는 고르지 말고 모으기만합니다. 쓸 만한지 판단하면서 모으면 “이건 별거 아닌데” 하고 지우게 되는데, 익숙함은 성과의 크기와 관계가 없습니다. 매일 보던 사람에게 당연한 개선이 지원하는 회사에는 처음 듣는 이야기입니다. 판단은 다음 단계에서, 재료가 다 나온 뒤에 합니다.

먼저 — 지금 쓰는 것이 어느 문서인가

채용 공고가 요구하는 서류는 보통 이력서, 경력기술서, 포트폴리오 셋입니다. 이름이 비슷해 한 문서를 길이만 바꿔 세 번 내는 경우가 있는데, 그러면 어느 것도 제 역할을 못 합니다.

• 이력서— 짧게 훑고 ‘더 볼지’를 정하게 하는 문서. 요약과 선별이 핵심입니다.
• 경력기술서 — 그 판단이 맞는지 확인받는 문서. 프로젝트별 근거를 자세히 씁니다.
• 포트폴리오 — 과정과 산출물을 직접 보여주는 문서. PM·PO에게는 필수가 아니고, 요구될 때만 준비하면 됩니다.

셋이 서로 다른 이야기를 하지 않는 것이 가장 중요합니다. 그러려면 경력기술서를 먼저 채우고 거기서 이력서를 줄여 뽑는 순서가 안전합니다. 반대로 하면 이력서에 쓴 성과가 경력기술서에서 사라지는 일이 생깁니다.

셋의 차이와 “지금 무엇을 준비할지”는 이력서·경력기술서·포트폴리오 차이에서 더 자세히 다룹니다.

이력서에 들어가는 것과 들어가지 않는 것

PM·PO 이력서는 대체로 네 덩어리입니다. 순서를 바꿀 수는 있지만 빠지면 곤란한 것들입니다.

• 요약 3~5줄 — 어떤 도메인에서 어떤 문제를 다뤄 온 사람인지. 여기서 읽을지 말지가 갈리므로 가장 마지막에 씁니다. 재료가 다 모인 뒤라야 무엇을 대표로 내세울지 정할 수 있습니다.
• 경력 사항 — 회사·기간·직함·소속 조직. 사실 정보라 손댈 것이 적지만, 제품과 팀 규모를 한 줄로 덧붙이면 뒤의 성과가 훨씬 잘 읽힙니다.
• 주요 경험 — 이력서의 본체. 프로젝트 단위로 3~6개를 고르고 각각을 아래 서술 프레임 중 하나에 넣습니다.
• 스킬·도구 — 나열이 길수록 약해집니다. 협업 도구는 대부분 변별력이 없으니 줄이고, 직접 다뤄본 분석·데이터 환경처럼 검증 가능한 것만 남깁니다.

반대로 빼는 편이 나은 것도 있습니다. 담당했다는 사실만 있고 결과가 없는 프로젝트, 직무와 무관한 수상·자격, 그리고 “커뮤니케이션 능력”처럼 누구나 쓰는 표현입니다. 자리를 차지하는 만큼 다른 문장이 밀립니다.

어떻게 구성할 것인가 — 서술 프레임 세 가지

같은 경험도 어떤 틀에 넣느냐에 따라 전달되는 강점이 달라집니다. 프로젝트마다 맞는 틀이 다르므로, 하나를 정해 전부 통일하기보다 경험별로 고르는 편이 낫습니다.

• 상황 중심 — 상황과 과제를 먼저 세우고 내 행동과 결과를 잇습니다. 맥락 설명이 필요한 프로젝트, 특히 제약이 심했던 일에 적합합니다.
• 문제 해결 중심 — 문제 정의에서 시작해 원인과 해결로 갑니다. PM·PO의 기본값에 가깝습니다. 무엇을 만들었는지보다 왜 그것이었는지가 드러납니다.
• 성과 리포트형 — 결과를 앞에 두고 근거를 뒤에 붙입니다. 숫자가 뚜렷한 프로젝트에 강하고, 반대로 숫자가 약하면 빈약해 보입니다.

고르는 기준은 취향이 아니라 그 경험에서 가장 센 조각입니다. 결과가 세면 리포트형, 판단이 세면 문제 해결 중심, 상황 자체가 어려웠으면 상황 중심입니다.

평가자가 읽는 순서

이력서는 처음부터 끝까지 읽히지 않습니다. 훑으면서 네 가지를 이 순서로 확인합니다. 어떤 규모에서 어떤 역할이었나, 다룬 문제가 얼마나 컸나, 그중 내 기여는 어디까지인가, 그래서 무엇이 달라졌나.

그래서 각 항목의 첫 한두 줄이 거의 모든 일을 합니다. 문장을 다듬을 때는 뒤가 아니라 앞을 봅니다. 배경 설명이 길어져 내가 한 일이 세 번째 줄로 밀려 있다면, 그 항목은 읽히지 않은 채 넘어갈 가능성이 큽니다.

[샘플] 커머스 앱의 검색 개편 프로젝트에 참여했습니다. → [샘플] 검색 이탈이 가장 높던 구간을 찾아 보정 로직 도입을 결정하고, 4주 만에 결과 0건 질의를 줄였습니다.

주제별 가이드

위 단계에서 가장 자주 막히는 두 지점을 따로 다룹니다. 숫자로 쓸 성과를 찾는 문제와, 이력서와 짝을 이루는 경력기술서를 쓰는 문제입니다.

• PM 이력서 성과 지표 정량화하는 법숫자로 쓸 성과가 없다고 느끼는 PM을 위해, 이미 한 일에서 지표를 찾아내고 과장 없이 문장으로 옮기는 방법을 정리합니다.
• PM 경력기술서 작성법이력서와 무엇이 다른지부터 항목별 구성까지, PM·PO 경력기술서를 문제 해결 서사로 쓰는 방법을 정리합니다.
• 이력서·경력기술서·포트폴리오 차이세 문서가 각각 무엇을 증명하는지, 포트폴리오는 언제 필요한지, PM·PO는 무엇부터 준비하면 되는지 정리합니다.
• PM 이력서 예시 — 고치기 전과 후직무 요약·경험 서술·협업·운영을 고치기 전과 후로 나란히 놓고, 무엇이 문장을 통과시키는지 짚습니다.
• PM 포트폴리오 작성법공고가 포트폴리오를 요구했을 때 무엇부터 정하고 한 프로젝트를 어떻게 펼치는지, 공개할 수 없는 자료는 어떻게 다루는지 정리합니다.

다 쓴 뒤에 점검할 다섯 가지

초안이 나오면 문장을 다듬기 전에 아래를 먼저 봅니다. 표현보다 구조에서 깎이는 점수가 훨씬 큽니다.

• 같은 직함이면 누구나 쓸 수 있는 문장이 있는가 — 있으면 그 자리는 비어 있는 것과 같습니다. 직무 소개가 아니라 내가 한 판단이 들어가야 합니다.
• 내 기여 범위가 드러나는가 — 팀 성과를 주어 없이 쓰면 면접에서 반드시 되묻습니다. 먼저 밝히는 쪽이 신뢰를 얻습니다.
• 결과가 없는 항목이 있는가 — 과정만 있으면 판단할 근거가 없습니다. 숫자가 없으면 남은 산출물과 채택 여부로 대신합니다.
• 지원하는 포지션과 순서가 맞는가 — 가장 관련 깊은 경험이 위에 있어야 합니다. 시간순이 항상 정답은 아닙니다.
• 이력서와 경력기술서가 같은 이야기를 하는가 — 두 문서를 따로 쓰면 쉽게 어긋납니다. 어긋난 순간 둘 다 신뢰를 잃습니다.

한 가지 더. 이력서는 지원할 때마다 처음부터 쓰는 문서가 아닙니다. 재료를 평소에 모아두면 지원 시점에 남는 일은 고르고 순서를 바꾸는 것뿐입니다. 이직을 결심한 뒤 몇 년 치를 한꺼번에 되짚는 일이 어려운 이유는 분량이 아니라, 그때의 판단 근거가 이미 흐려졌기 때문입니다.

서비스기획자·신입은 무엇이 다른가

서비스기획자로 일해 온 경우, 직함이 다르다고 이력서 구조가 달라지지는 않습니다. 문제를 정의하고 해결 과정을 이끄는 축은 같습니다. 다만 채용 공고가 쓰는 단어와 내 문서의 단어가 다를 수 있으므로, 지원하는 조직이 쓰는 용어에 맞춰 이름을 맞춰주는 작업은 필요합니다. 하는 일을 바꾸는 게 아니라 라벨을 맞추는 일입니다.

경력이 짧은 경우에는 프로젝트 수가 적은 것이 약점이 아닙니다. 적은 만큼 하나를 깊게 씁니다. 무엇을 몰랐고 어떻게 알아냈는지까지 적으면, 완성도가 낮은 결과라도 일하는 방식이 드러납니다. 평가자가 신입에게서 확인하려는 것도 대개 그쪽입니다.

자주 묻는 질문