PM 이력서 예시 — 고치기 전과 후

예시를 그대로 베끼면 안 되는 이유

아래 문장들은 지어낸 예시입니다. 실제 회사도 실제 성과도 아니어서 모두 표시를 달아 두었습니다. 그대로 옮겨 쓰면 면접 첫 질문에서 무너집니다. 읽는 사람이 확인하는 것은 문장의 완성도가 아니라 그 문장이 사실인지이기 때문입니다.

그래서 이 페이지는 완성된 이력서를 전시하지 않습니다. 대신 고치기 전과 고친 뒤를 나란히 놓습니다. 베낄 것은 문장이 아니라 무엇이 빠져 있었는지 알아채는 눈입니다.

직무 요약 — 이력서 첫 문단

맨 위 서너 줄은 대부분 가장 늦게 쓰고 가장 먼저 읽힙니다. 흔한 실패는 형용사로 채우는 것입니다.

[샘플] 사용자 중심으로 사고하며 데이터에 기반해 의사결정하는 PM입니다.

이 문장은 누구에게나 참이라 아무것도 구별해주지 않습니다. 대신 무엇을 다뤄봤고 어느 범위를 책임졌는지를 적습니다.

[샘플] 결제·정산 도메인에서 5년간 B2B 프로덕트를 맡았습니다. 실패한 결제를 자동으로 재시도하는 구조를 설계했고, 재무·CS와 정산 정책을 함께 조정하는 일을 반복했습니다.

경험 한 건 — 고치기 전과 후

경험 한 건은 무엇이 문제였는지가 들어가야 판단이 보입니다. 아래는 같은 일을 두 가지로 쓴 것입니다.

[샘플] 결제 실패 재시도 기능을 기획하여 결제 성공률을 개선했습니다.

무엇을 만들었는지만 있고 왜 그것을 골랐는지가 없습니다. 같은 자리에 판단을 넣으면 이렇게 됩니다.

[샘플] 결제 실패의 절반 이상이 카드사 일시 오류였는데 전부 사용자에게 실패로 안내되고 있었습니다. 즉시 재시도와 지연 재시도 중 카드사 정책상 안전한 후자를 택해, 실패 건의 상당수가 사용자 개입 없이 결제되도록 바꿨습니다.

⚠️ 뒷 문장에도 정확한 숫자가 없습니다. 기억이 흐린 수치를 지어내는 것보다, 검증 가능한 사실로 쓰는 편이 안전합니다.

협업과 조율을 성과로 쓸 때

PM 일의 상당 부분은 만드는 것이 아니라 합의를 만드는 것인데, 이력서에서 가장 자주 증발하는 부분이기도 합니다.

[샘플] 유관부서와 원활하게 소통하며 프로젝트를 성공적으로 이끌었습니다.

무엇을 조율했는지가 없으면 태도 서술로 읽힙니다. 무엇이 충돌했고 어떻게 정했는지를 적습니다.

[샘플] 정산 주기를 앞당기자는 영업 쪽 요구와 마감 정확도를 지켜야 하는 재무 쪽 요구가 부딪혔습니다. 두 요구를 같은 표에 놓고 주기별 오차 범위를 계산해 보여준 뒤, 오차가 허용치 안에 드는 선에서 주기를 줄이는 안으로 합의했습니다.

운영·유지보수도 경력이다

새 기능만 이력서에 올리는 경우가 많습니다. 그런데 실제로 오래 한 일은 대개 이미 있는 것을 굴러가게 만든 일입니다.

[샘플] 어드민 페이지를 개선하고 운영 업무를 지원했습니다.

[샘플] CS팀이 환불 처리를 할 때마다 개발자에게 조회를 요청하고 있었습니다. 요청 로그를 한 달치 분류해 상위 세 유형을 어드민에서 직접 처리할 수 있게 만들었고, 그 뒤로 같은 유형의 개발 요청이 거의 들어오지 않았습니다.

무엇이 뒷 문장들을 통과시켰나

네 쌍을 다시 보면 고친 쪽에 공통으로 들어간 것이 셋입니다.

• 무엇이 잘못돼 있었는가 — 이게 없으면 나머지가 업무 나열이 됩니다.
• 왜 그 방법을 골랐는가 — 버린 대안이 한 번 나오면 판단이 보입니다.
• 확인할 수 있는 결과 — 숫자가 있으면 숫자로, 없으면 사실로.

셋 다 이미 쓴 문서 안에 있습니다. 기획서의 배경 단락, 회의록의 대안 비교, 회고의 마무리가 각각 그 자리입니다. 이력서를 쓰는 일이 기억을 짜내는 일처럼 느껴진다면, 대개 그 문서들을 아직 안 열어봤기 때문입니다.

자주 묻는 질문