지난달에 PM 1년 차인 친구 이력서를 봐줬어요. 두 달 가까이 넣었는데 면접 제의는 손에 꼽을 정도였대요. 이력서를 열어보니 경력사항 첫 줄에 이렇게 쓰여 있더라고요.
사용자端 주문 모듈 이터레이션을 담당, 주문 플로우를 최적화하여 사용자 경험을 개선했습니다.
이 한 줄을 보고 저는 바로 감이 왔어요. 친구가 일을 안 한 게 아니에요. 프로젝트 얘기만 꺼내면 30분도 넘게 말할 수 있는 친구거든요. 문제는 이력서에 쓴 이 문장이, 주문 모듈을 조금이라도 만져본 PM이라면 누구나 그대로 베껴 쓸 수 있는 내용이라는 거예요.
이게 바로 PM 이력서에서 가장 치명적인 함정이에요. PM의 이력서를 그냥 '기능 목록'으로 만들어버린 거죠.
PM의 산출물은 기능 그 자체가 아니에요. 당신의 산출물은 '어떤 문제를 발견했는지', '그걸 어떻게 분석했는지', '어떤 의사결정을 내렸는지', '최종적으로 어떤 결과를 만들었는지'예요. 만약 첫 번째 단계인 '어떤 기능을 만들었는지'만 써놓는다면, 면접관이 당신에게 갖는 인식은 '프로토타입 그릴 줄 알고 요구사항 문서 쓸 줄 아는 사람'에서 멈춰요. 이 이미지로는 지금 시장에서 면접 잡기가 정말 어려워요.
아래에서는 프로젝트 경험, 데이터 정량화, 자기소개, 경험 없는 상황의 돌파구, 이렇게 네 가지 축으로 풀어볼게요. 각 축마다 변경 전과 변경 후 사례를 넣었고, 지어낸 게 아니라 PM이 매일 실제로 하는 '두뇌 노동'을 이력서 위에 재현한 거예요.
1. 프로젝트 경험: '어떤 기능을 만들었는지'가 아니라 '어떤 문제를 해결했는지'
PM의 프로젝트 경험은 두 가지 극단으로 빠지기 쉬워요. 하나는 '기능 나열형' — 했던 요구사항을 메뉴판처럼 쭉 늘어놓는 패턴이에요. 다른 하나는 '방법론 복창형' — '사용자 리서치', '요구사항 분석', '경쟁사 분석' 같은 단어가 화면 가득한데 구체적인 사례는 하나도 보이지 않는 패턴이에요.
두 가지写法의 결과는 똑같아요. 면접관이 다 읽고 나서도 당신의 강점이 뭔지 전혀 모르게 돼요.
먼저 '기능 나열형' 예시를 볼게요
변경 전:
이커머스 앱 주문 모듈의 이터레이션 최적화를 담당했습니다. 주문 플로우 재구성, 결제 수단 확장, CS 티켓 시스템 구축을 진행했습니다. 디자인, 개발, QA 팀과 협업하여 요구사항을 릴리즈했고, 프로젝트는 일정대로 런칭했습니다.
이 문장의 문제가 뭘까요? 면접관에게 전달되는 정보는 세 가지예요. '주문 모듈을 담당해봤다', '요구사항 문서를 쓸 줄 안다', '프로젝트가 일정대로 됐다'. 그런데 면접관은 읽고 나서 머릿속에 '이 사람 능력 괜찮네' 하고 연결될 만한 구체적인 그림이 하나도 안 그려져요. 왜냐면 모든 동사 — '담당', '협업', '완료' — 가 과정만 가리킬 뿐, 판단력을 가리키지 않기 때문이에요.
변경 후:
주문 제출 단계의 이탈 문제(장바구니에서 결제 확인 페이지로의 전환율이 38%에 장기간 머물러 있음)를 해결하기 위해 주문 플로우 재구성을 주도했습니다. 2000건 이상의 사용자 행동 로그 데이터를 분석한 결과, '주소 입력'과 '쿠폰 선택'이 두 개의 주요 병목 지점임을 밝혀냈습니다 — 각 단계에서 23%, 19%의 사용자가 이탈하고 있었죠. 해결책으로 주소 입력을 독립 페이지에서 하프 스크린 팝업으로 변경하고, 쿠폰은 최대 할인 금액 기준으로 자동 선택(원터치로 전환 가능)되도록 했습니다. 결과적으로 장바구니에서 결제 확인 페이지로의 전환율을 38%에서 64%로 끌어올렸고, 월 주문량이 약 3.2만 건 증가했습니다.
이 버전과 원래 버전의 차이가 뭘까요? 원래 버전은 '내가 어떤 기능을 만들었다'를 말하고 있어요. 변경 후 버전은 '내가 문제를 발견하고, 원인을 분석하고, 해결책을 제안하고, 효과를 검증했다'를 말하고 있죠. 이 네 단계가 합쳐져야 PM으로서 진짜 업무 사이클이 완성되는 거예요.
이번에는 '방법론 복창형' 예시를 볼게요
변경 전:
사용자 인터뷰와 경쟁사 분석을 통해 타겟 사용자의 핵심 니즈를 깊이 이해했습니다. RICE 모델로 요구사항 우선순위를 정하고 제품 로드맵을 수립했습니다. 디자인, 개발팀과 효율적으로 협업하여 요구사항을 높은 품질로 출시했습니다.
이 문장은 단독으로 봤을 때 사실 정보가 하나도 없어요. 이건 '특정 누군가'의 업무가 아니라, '모든 PM'이 하는 일을 묘사한 것에 불과해요. 면접관은 이런 문단을 보면 '이 사람 전문성 있네'가 아니라 '실무 경험이 부족해서 방법론으로 채우고 있는 건 아닐까'라는 의심을 먼저 해요.
변경 후:
입점 업체용 상품 관리 백오피스 개편을 담당했습니다. 첫 버전 출시 후, CS 피드백과 백오피스 조작 로그를 분석한 결과 입점사가 상품 하나를 등록하는 데 평균 11분이 걸린다는 사실을 발견했어요. 경쟁사는 3~5분이면 끝나는 수준이었죠. 활성 입점사 8곳을 인터뷰한 끝에 세 가지 핵심 문제를 찾았습니다. 스펙 입력 로직이 직관적이지 않다, 이미지 일괄 업로드가 안 된다, 재고 관리 진입 경로가 너무 깊다, 이렇게 세 가지였어요. 이에 맞춰 폼 구조 재설계, 일괄 업로드, 재고 바로가기 진입점이라는 세 가지 모듈을 개편했고, 입점사의 평균 상품 등록 시간이 11분에서 4분으로 단축됐으며, 주간 활성 입점사 수가 한 달 만에 120곳에서 210곳으로 증가했습니다.
차이가 보이시나요? 똑같이 '사용자 인터뷰'와 '제품 개선'을 했지만, 이 버전은 '누구를 인터뷰했는지', '무엇을 발견했는지', '무엇을 했는지', '결과가 어땠는지'를 썼어요. 방법론 자체는 중요하지 않아요. 당신이 그 방법론을 어떻게 써서 구체적인 판단과 결과를 만들어냈는지 — 그게 진짜 중요한 거예요.
PM의 프로젝트 경험 작성 공식
위 두 사례에서 간단한 작성 구조를 뽑아낼 수 있어요.
어떤 문제를 발견했는가 (구체적인 상황 포함) → 어떻게 원인을 찾아냈는가 (분석 과정 포함) → 어떤 의사결정을 내렸는가 (선택지와 선택의 근거 포함) → 어떤 결과를 가져왔는가 (검증 가능한 데이터 포함)
이 구조가 일반적인 STAR 기법과 다른 점은, PM은 '왜 당신의 분석이 옳은지'를 한 겹 더 써야 한다는 거예요. PM의 판단력은 '리서치를 했다'는 사실에서 드러나는 게 아니라, '리서치에서 어떤 인사이트를 뽑아냈고, 그 인사이트를 바탕으로 어떤 선택을 했는지'에서 드러나기 때문이에요.
2. 데이터 정량화: 데이터가 없을 때, 있을 때 어떻게 쓸까
구조 얘기를 했으니, 더 세부적인 문제인 데이터로 넘어갈게요. PM 이력서에서 데이터는 가장 강력한 무기예요. 하지만 주니어 PM이 가장 자주 마주치는 상황은 두 가지예요. '정말 데이터가 없는' 경우와 '데이터는 있는데 쓰는 법을 모르는' 경우예요.
데이터가 있는데 'XX% 향상'이라고 써버린 경우
전형적인 예시를 먼저 볼게요.
로그인·회원가입 플로우를 최적화하여 회원가입 전환율이 15% 향상되었습니다.
15%는 얼핏 긍정적인 숫자로 보여요. 하지만 면접관은 반드시 이렇게 물어볼 거예요. "원래 몇 퍼센트였는데요? 몇 퍼센트로 올랐나요? 절대값 15%p 상승인가요, 상대값 15% 상승인가요? 기준 수치는 얼마인가요?"
만약 여기에 답하지 못하면, 이 한 줄의 신뢰도는 0이 돼요.
그래서 PM의 데이터 정량화에는 철칙이 하나 있어요. 항상 'X에서 Y로'를 쓰고, 'XX% 향상'은 쓰지 마세요.
로그인·회원가입 전환율을 52%에서 67%로 끌어올렸습니다.
이 문장과 '15% 향상'은 같은 성과를 말하고 있지만, 면접관이 받아들이는 느낌은 완전히 달라요. 전자는 업무 보고서처럼 읽히고, 후자는 실제로 데이터를 만져본 사람의 말처럼 읽혀요.
여기서 한 걸음 더 나아가서 '어떻게 달성했는지'까지 보강하면, 데이터의 설득력은 한층 더 올라가요.
로그인·회원가입 전환율을 52%에서 67%로 끌어올렸습니다. 핵심 조치: 독립된 비밀번호 설정 페이지를 없애고 회원가입 완료 후 팝업으로 비밀번호 설정을 유도했습니다. SMS 인증번호 자동 입력을 적용해 수동 입력 단계를 줄였습니다.
면접관은 이걸 보면 굳이 추가 질문을 하지 않아도 당신의 사고 경로를 그대로 알 수 있어요.
세 가지 데이터의 우선순위
모든 데이터가 같은 무게를 가지는 건 아니에요. 약한 순서부터 강한 순서로 세 단계가 있어요.
첫 번째 단계: 절대값. 가장 약하지만, 없느니 나아요. 'DAU가 5만에서 8만으로 증가' — 변화는 알겠지만 설득력은 약해요. 그냥 시장 전체가 성장한 덕분일 수도 있으니까요.
두 번째 단계: 비교값. 절대값만 쓰는 것보다 강력해요. 예를 들어 '업계 평균 성장률 12%인 상황에서 우리는 45% 성장을 달성했습니다'. 면접관은 한눈에 '이 사람은 시장 흐름에 편승한 게 아니라, 이 사람의 액션이 효과를 냈다'는 걸 알아차려요.
세 번째 단계: 귀속값. 가장 강력한 데이터예요. 당신의 액션과 결과를 직접 연결해 주기 때문이죠. 예를 들어 '출시 후 장바구니에서 결제 확인 페이지까지의 전환율이 38%에서 64%로 상승했으며, 같은 기간 다른 페이지의 전환율은 안정적으로 유지되어 계절적 변동의 영향을 배제할 수 있었습니다'. 스스로 교란 요인을 배제한 거예요. 이 행위 자체가 당신이 기능의 효과를 어떻게 평가해야 하는지 알고 있다는 증거가 되는 거죠.
정말 데이터가 없을 땐 어떻게 할까요
많은 주니어 PM이 마주하는 진짜 상황은 이렇습니다. 만든 기능이 아직 출시 전이다, 핵심 지표를 담당하지 않는 모듈을 맡고 있다, 회사가 너무 작아서 데이터 대시보드조차 없다.
이런 상황에서도 당황할 필요 없어요. 면접관도 주니어 PM에게 처음부터 높은 수준의 데이터를 기대하지는 않아요. 당신이 해야 할 일은 정량 데이터 대신 '정성적 성과'와 '과정의 증거'로 보완하는 거예요.
다음 세 가지 작성법을 참고하세요.
1. 비즈니스 피드백 쓰기:
기획 리뷰 단계에서 운영팀이 "예전 백오피스는 조작 스텝이 너무 많아서 새 프로모션 하나 올릴 때마다 반나절이 걸렸다"고 말했어요. 새方案에서는 프로모션 설정을 7단계에서 3단계로 압축했고, 운영팀이 사전 리뷰에 참여해 사용성을 확인했습니다. 기획안은 단번에 통과되어 개발에 들어갔어요.
2. 사용자 검증 결과 쓰기:
프로토타입 완성 후 대상 사용자 6명(신규 사용자 3명, 기존 사용자 3명)으로 사용성 테스트를 진행해 4개의 주요 인터랙션 문제를 찾아내고 수정했습니다. 최종 버전은 2차 테스트에서 과업 완료율이 67%에서 100%로 올랐어요.
3. 비교 결론 쓰기:
시중의 동종 제품 5개의 회원가입 플로우를 단계별로 분해 분석한 결과, 업계 모범 사례는 보통 3~4단계로 회원가입을 완료하는 데 반해 우리의 기존 안은 7단계였습니다. 이 분석을 바탕으로 7단계에서 3단계로 압축했고, 디자인 리뷰를 한 번에 통과했어요.
이 세 가지 작성법에는 공통점이 있어요. 데이터를 조작하지는 않았지만, 당신이 '제품을 만드는 방식'이 엄밀하고 방법론에 기반해 있다는 걸 증명하고 있다는 점이에요. 주니어 PM에게는 진위를 알 수 없는 '30% 향상'보다 이게 훨씬 더 가치 있어요.
3. 자기소개: '논리적 사고'라고 쓰지 말고 증명하세요
PM 자기소개는 가장 심각한 재해 구역이에요. PM 10명의 자기소개를 보면 8명이 이렇게 생겼어요.
논리적 사고가 명확하고, 커뮤니케이션 능력이 뛰어나며, 사용자 니즈에 대한 예리한 통찰력을 갖추고 있습니다. 부서 간 협업과 프로젝트 추진에 강점이 있으며, 제품을 0에서 1로 효율적으로 이끌 수 있습니다.
이 문장은 쓰나 마나예요. 왜냐하면 PM 직무에 지원하는 사람이라면 누구나 똑같이 쓸 수 있는 말이니까요. '논리적 사고'는 자격증이 필요한 게 아니고, '커뮤니케이션 능력'은 등급 시험이 있는 게 아니에요. 면접관은 이런 문장을 보면 자동으로 건너뛰어요.
다시 쓴 사례
변경 전:
1년의 B2B 제품 경험. 논리적 사고가 명확하며, 요구사항 분석과 제품 기획 산출물 작성에 능숙합니다. 높은 프로젝트 추진력을 갖추고 있으며, 다양한 이해관계자를 조율하여 목표를 달성할 수 있습니다.
변경 후:
1년의 B2B SaaS 제품 경험. 입점사 도구 영역에 집중해 왔습니다. 요구사항 조사부터 출시까지의 전 과정을 단독으로 담당했습니다. CS 티켓 분석과 입점사 인터뷰를 통해 핵심 니즈를 찾아내고, PRD를 작성했으며 리뷰에서 기술方案에 대한 합의를 이끌어냈습니다. 최종 출시된 기능은 출시 한 달 만에 활성 입점사의 70%에게 도입되어 사용됐습니다.
차이가 뭘까요? 원래 버전은 모든 문장이 '자기 묘사'예요. 변경 후 버전은 모든 문장이 '자기 증명'이에요.
구체적으로 뜯어볼게요.
- '논리적 사고가 명확함' → 'CS 티켓 분석과 입점사 인터뷰를 통해 핵심 니즈를 찾아냄'으로 바뀌었어요. 보이시나요? '논리적입니다'라고 말하는 게 아니라, '논리를 가지고 이렇게 일했다'는 실제 사례를 보여주고 있어요.
- '요구사항 분석과 제품 기획 산출물 작성에 능숙함' → '요구사항 조사부터 출시까지 전 과정을 단독 담당…… PRD를 작성했으며 리뷰에서 기술方案 합의를 이끌어냄'으로 바뀌었어요. '기획서 쓸 줄 압니다'가 아니라, '기획서를 썼고 그게 실제로 통과됐습니다'를 말하는 거예요.
- '높은 프로젝트 추진력' → '최종 출시된 기능이…… 활성 입점사 70%에게 도입됨'으로 바뀌었어요. '추진력 있습니다'라는 말보다 훨씬 강력해요. 당신이 만든 기능이 실제로 쓰이고 있다 — 그게 추진력의 가장 확실한 증거니까요.
자기소개의 핵심 원칙
PM 자기소개에는 아주 간단한 판단 기준이 있어요. 이름을 가리고 다른 사람에게 보여줬을 때, 상대가 '이 사람이 대략 어떤 PM인지'를 말할 수 있을까요?
다 읽은 후 상대가 'PM 경험자네요' 정도밖에 말하지 못한다면, 당신이 쓴 건 범용 버전이에요. 상대가 'B2B 입점사 도구를 전문으로 하고, 직접 사용자 리서치를 수행했으며, 완전한 출시 사이클을 가진 PM이네요'라는 수준까지 말할 수 있게 고쳐야 자기소개로서 합격이에요.
길이는 서너 문장이면 충분해요. 각 문장이 면접관이 기억하기를 바라는 태그 하나씩에 대응되게 하세요. 당신의 전문 분야, 핵심 역량, 성과, 차별점 — 이 네 가지예요.
4. 제품 경험이 없을 때 — 전직과 신입의 돌파구
가장 많이 받는 질문이에요. "PM으로 전직하고 싶은데, PM으로 일해본 적이 없어서 이력서에 쓸 게 없어요. 어떻게 하죠?"
솔직히 말하면, 이 문제는 생각보다 훨씬 해결하기 쉬워요. 왜냐하면 '제품 경험이 없다'와 '제품 역량을 증명할 수 있는 에피소드가 없다'는 같지 않기 때문이에요.
지금 하는 일에서 제품과 연결된 부분을 캐내세요
많은 직무가 PM과의 경계가 모호해요. 운영, 마케팅, CS, 프로젝트 매니저 — 일상 업무 속에서 '문제 발견 → 원인 분석 → 해결책 제안 → 실행 추진'이라는 사이클을 한 번이라도 돌려봤다면, 당신은 이미 PM 업무의 일부를 해본 거예요.
운영에서 PM으로 전직하는 사례를 볼게요.
변경 전 (운영 관점):
커뮤니티 운영을 담당했습니다. 20개의 사용자 그룹을 일상적으로 관리하고, 정기적으로 커뮤니티 이벤트를 기획하여 사용자 활성도와 리텐션을 높였습니다.
이 버전에 쓰인 건 전부 운영의 실행 업무예요. 면접관이 읽은 느낌: 이 사람은 운영 담당자다. PM이 아니다.
변경 후 (제품 관점):
커뮤니티 운영 중에 사용자가 '강의 다시보기' 접근 경로에 대해 반복적으로 문의하는 현상을 발견했습니다 — 월 관련 문의가 300건을 넘었죠. 사용자의 일반적인 탐색 경로를 정리한 후, '강의 다시보기 진입 경로 개선안'을 제품팀에 제안했습니다. 강의 상세 페이지에 '지난 강의 다시보기' 진입점을 추가하고, 그룹 공지에 다시보기 모음 링크를 고정 노출하는 내용이었어요. 이 제안이 채택되어 출시된 후, 관련 문의량이 76% 감소했고 커뮤니티 운영 인력이 주간 약 15시간 절감됐습니다.
같은 경험인데, 서사의 관점을 '내가 어떤 운영 업무를 했는지'에서 '내가 어떤 사용자 문제를 발견하고, 어떤 해결책을 제안하고, 어떤 결과를 만들었는지'로 바꾼 것뿐이에요. 후자는 바로 제대로 된 PM이 하는 일이에요.
만약 당신이 CS, 영업, 기술 지원을 하고 있다면 — 당신은 사용자의 생생한 피드백과 현장의 니즈를 매일 접하고 있는 거예요. 이건 PM이라면 누구나 목말라하는 1차 정보예요. 이것들을 명확한 문제 기술과 개선 제안으로 정리하는 것, 그게 바로 당신의 '제품 사고력'을 가장 직접적으로 증명하는 방법이에요.
신입: 당신의 프로젝트를 '제품'으로 풀어내세요
학교 공식 SNS 계정을 운영했거나, 동아리 행사를 기획했거나, 수업 과제로 팀 프로젝트를 했거나 — 이건 당신 눈에는 '학교 안에서 한 것'일지 몰라도, 면접관 눈에는 당신이 내놓을 수 있는 훌륭한 '제품 경험'이에요. 단, 쓰는 방식이 맞아야 한다는 전제 아래에서요.
변경 전:
교내 창업 대회에 참가, 프로젝트 리더로서 팀을 이끌어 교내 중고 거래 미니프로그램의 제품 설계를 완료했습니다. 교내 2등상을 수상했습니다.
변경 후:
교내 창업 대회 프로젝트 (교내 2등상, 전체 80여 팀 중 상위 5위)
프로젝트 배경: 교내 중고 거래의 수요-공급 간 심각한 정보 불일치를 발견했습니다. QQ 그룹이나 SNS 타임라인에 올라온 정보는 빠르게 묻히고 검색도 어려웠어요. 그래서 프로젝트 방향을 '교내 중고 거래를 위한 가벼운 매칭 도구'로 집중시켰습니다.
개인 역할: 요구사항 조사와 제품 설계 담당
- 유효 응답 150건의 설문을 설계·회수하고, 경쟁사 분석(당근, 번개장터 및 교내 기존 채널과 비교)을 수행했습니다. 8페이지 분량의 요구사항 조사 보고서를 작성했어요.
- 조사 결과를 바탕으로 핵심 기능을 세 가지 모듈(판매글 작성, 검색, 대화)로 압축하고, 기존 안에 있던 사용자 평점 기능과 에스크로 거래 기능을 과감히 뺐습니다. 그 이유는 '교내 지인 커뮤니티에서는 복잡한 장치보다 가벼운 신뢰가 더 효과적'이라고 판단했기 때문이에요.
- 인터랙션 프로토타입을 제작해 20명의 학생을 대상으로 사용성 테스트를 했고, 피드백을 반영해 상품 등록 플로우를 6단계에서 3단계로 간소화했습니다.
프로젝트 성과: 교내 2등상 수상. 심사위원 피드백 "문제 정의가 명확하고, 기능 축소에 타당한 근거가 있음"
변경 전 버전으로 PM 직무에 지원하면, 면접관은 그냥 '대회 참가 경험이 있는 졸업예정자'로만 생각해요. 변경 후 버전이면 면접관은 이렇게 생각할 거예요. "이 사람은 문제를 정의할 줄 알고, 경쟁사 분석을 할 줄 알고, 사용자 리서치를 할 줄 알고, 상황에 기반해 기능의 우선순위를 정할 줄 아는 사람이군요. PM이 실제로 해야 하는 일을 해본 사람이네."
신입의 가장 큰 장점은 '무엇을 배웠는지'가 아니에요. 하나의 프로젝트 안에서 '발견 → 분석 → 설계 → 검증'이라는 완전한 사이클을 보여줄 수 있다는 점이에요. 경력직 PM 이력서는 오히려 이걸 보여주기 어려운 경우가 많아요. 회사에서 큰 시스템의 작은 모듈 하나만 담당하는 경우가 많으니까요.
전직과 신입이 빠지기 쉬운 두 가지 함정
함정 1: 방법론을 과하게 채워 넣기. '경험이 없으니까 방법론을 많이 써서 내가 알고 있다는 걸 증명해야지'라고 생각하는 분들이 많아요. 그 결과 이력서가 페르소나, 사용자 여정 지도, AARRR 모델, KANO 분석으로 가득한데 — 구체적인 사례는 하나도 안 보이는 상태가 돼요. 면접관이 이런 이력서를 보면 첫인상은 '학원 출신이구나'예요. 당신이 증명해야 하는 건 '제품에 대해 공부한 적 있다'가 아니라 '제품과 관련된 일을 실제로 해본 적 있다'는 거예요.
함정 2: 남의 프로젝트를 자기 실적인 것처럼 쓰기. 예를 들어 온라인 실습 프로그램에 참가해서 멘토의 가이드에 따라 가상 제품 분석을 한 경우예요. 이런 경험은 이력서에 써도 괜찮지만, '이건 학습 프로젝트다'라고 명확히 밝히고, '당신 개인의 사고와 판단'에 포커스를 맞춰서 써야 해요. 팀의 성과를 개인 실적으로 포장하는 것보다, 면접관에게 '이 사람의 머릿속이 어떻게 돌아가는지'를 보여주는 게 훨씬 더 중요해요.
5. PM 이력서에만 해당되는 세 가지 작은 노하우
여기까지는 구조와 큰 방향에 대한 이야기였어요. 아래 세 가지는 디테일하지만 정말 실용적이에요.
1. 'Axure, Figma 다룰 줄 압니다'라고 쓰지 마세요
툴은 핵심 경쟁력이 아니에요. 어떤 PM이든 일주일이면 새 툴에 적응할 수 있어요. 'Axure 능숙'이라고 쓰는 것보다, 'Axure로 40개 이상의 페이지로 구성된 입점사 백오피스 하이파이 프로토타입을 제작했고, 그대로 디자인 리뷰와 프론트엔드 개발 참고자료로 사용됐습니다'라고 쓰세요. 후자는 당신의 프로토타입이 그냥 연습 삼아 그린 게 아니라 실제로 개발팀에 전달되어 쓰인 것임을 증명해 주니까요.
2. 모든 경험에 '만약 당신이 아니었다면, 이 결과는 달랐을 것이다'라는 정보를 숨기세요
면접관은 이력서를 읽을 때 무의식적으로 하나의 답을 찾고 있어요. 이 사람은 그 경험에서 '팀을 따라간 사람'인가, 아니면 '일을 만들어낸 사람'인가.
만약 당신이 '요구사항 리뷰에 참여', '테스트 검수 지원'이라고 썼다면, 면접관이 읽는 정보는 이거예요. "요구사항 리뷰는 이 사람 없이도 열렸을 거고, 테스트 검수는 다른 사람이 해도 똑같았겠네." 이런 건 가점 요소가 아니에요. 오히려 '내 관여도는 깊지 않았습니다'라는 신호를 면접관에게 보내는 거예요.
이걸 이렇게 바꿔보세요. "요구사항 리뷰에서 기존 Y안 대신 X안을 제안했고, 그 이유는 …… 였습니다. 최종적으로 X안이 채택됐습니다." "테스트 단계에서 경계 조건의 결함을 발견해 개발팀이 릴리즈 전에 수정하도록 추진했고, 온라인 장애를 사전에 방지했습니다." 이건 면접관에게 이렇게 말하는 거예요. "이 사람은 그냥 자리에만 있었던 게 아니다. 이 사람은 일의 흐름을 바꿨다."
3. 이력서 그 자체가 당신의 첫 번째 '제품'이에요
이건 많은 PM이 생각하지 못하는 관점이지만, 최고 수준의 면접관은 반드시 이 각도에서 당신을 평가해요.
당신의 이력서는 본질적으로 하나의 '제품'이에요. 타겟 사용자는 면접관과 HR이고, 핵심 니즈는 '10초 안에 이 사람과 대화할 가치가 있는지 판단하는 것'이며, 핵심 지표는 면접 제의율이에요.
당신은 이 제품의 정보 구조를 어떻게 설계할 건가요? 가장 중요한 정보가 가장 눈에 띄는 위치에 배치되어 있나요? 모든 에피소드가 하나의 동일한 핵심 포지셔닝을 강화하고 있나요? 아니면 면접관이 다 읽고 나서 드는 생각이 "이 사람은 이것저것 조금씩 건드려본 것 같은데, 뭘 가장 잘하는지는 모르겠네"인 상태인가요?
만약 자기 이력서라는 '제품'조차 제대로 설계하지 못한다면, 면접관이 어떻게 당신이 진짜 제품을 설계할 수 있다고 믿겠어요?
작성 후 체크리스트
- 모든 프로젝트 경험의 첫머리가 '어떤 문제를 발견했는지'로 시작하나요? '내가 …… 를 담당했습니다'로 바로 시작하지는 않나요?
- 데이터가 있나요? 정량 데이터가 정말 없다면, 정성적 성과(사용자 피드백, 테스트 결과, 비즈니스 담당자 평가)로 보완되어 있나요?
- 자기소개 중에, 지워도 비슷한 경력의 다른 사람이 그대로 베껴 쓸 수 있는 문장이 있나요? 있다면 다시 쓰세요.
- 'Axure/Figma/Sketch 능숙'이라고 쓰지 마세요 — '이 툴로 무엇을 딜리버리했는지'로 바꾸세요.
- 이력서 전체를 다 읽은 후, '이 사람은 어떤 분야에서, 어떤 핵심 역량을 가진 PM인지'를 한 문장으로 말할 수 있나요? 말할 수 없다면 이력서의 정보 구조를 다시 설계해야 합니다.
- 다른 분야의 PM 직무에 지원할 때, JD에 맞춰 이력서를 다시 정렬하나요? 그렇지 않다면 당신이 쓰고 있는 건 범용 버전의 이력서예요.
결국 PM의 이력서는 '과거에 무엇을 했는지에 대한 목록'이 아니에요. '당신이 팀에 어떤 가치를 가져올 수 있는지에 대한 제안서'예요. 이 제안서의 논리를 명확하게 쓰고 증거를 충분히 제시하면, 면접관은 자연스럽게 당신과 더 이야기하고 싶어질 거예요.
이력서를 고친 후에도 면접관 눈에 어떻게 비칠지 확신이 서지 않는다면 — 솔직히 말해서 자기가 쓴 글을 스스로 객관적으로 보는 건 정말 어려운 일이에요. DeepResume의 무료 진단은 성과 정량화, 매칭도, 표현의 명확성 같은 여러 축으로 이력서를 전면 스캔해드려요. 각 경험마다 강점과 약점을 분석하고 개선 방향을 제시해 드려요.