기획자 경력 3년차, PM 채용 공고를 보면 "내가 했던 일은 여기 안 적혀 있는데?" 싶은 적 있으셨나요? 메트릭, 가설 검증, 데이터 기반 의사결정 같은 단어가 익숙한 화면 기획서와 거리가 멀게 느껴지죠.
그런데 막상 한국 IT 회사에서는 기획자, PM, PO 명칭을 혼용하는 곳이 많아요. 결국 "실제로 맡아서 한 일의 내용과 범위"가 직무를 정의해요[1]. 즉, 기획자 경력이 PM 시장에서 평가받지 못하는 게 아니라, 같은 경험을 PM 언어로 다시 정리하지 못해서 저평가되는 경우가 많아요.
이 글에서는 기획자가 PM으로 전환할 때 마주하는 진짜 갭, 이미 갖고 있는 무기, 그리고 이력서·면접에서 어떻게 재프레이밍할지 정리해 드릴게요.
이미지 제안: 기획서 위에 메트릭 그래프가 겹쳐지는 일러스트. alt — "기획서와 메트릭 그래프가 겹쳐 PM 사고로 확장되는 모습"
1. 기획자와 PM, 진짜 차이는 무엇일까요?
세 직무는 같은 듯 다르게 정의돼요[1].
구분 | 서비스 기획자 | PM (Product Manager) | PO (Product Owner) |
|---|---|---|---|
핵심 역할 | 설계·기획 | 관리·실행 | 혁신·의사결정 |
전형적 산출물 | 정책서, IA, 스토리보드 | 로드맵, 우선순위, 운영 지표 | 가설, 실험 설계, PMF 검증 |
무게 중심 | 화면·기능 정의 | 성장 궤도 제품 운영·개선 | 새로운 기회 발굴 |
토스는 PM을 "성장의 궤도에 오른 제품을 안정적으로 운영하기 위해 풀어야 할 문제를 정의하고 개선방향을 제시"하는 사람으로 정의해요[1]. PO는 쿠팡이 국내 최초로 도입한 직무로, 잠재 고객을 대상으로 새로운 서비스 가능성을 검토하는 역할이에요[1].
핵심 시사점은 이거예요. 기획자는 "어떻게 만들지"를 설계하고, PM/PO는 "왜 만들고, 무엇으로 측정할지"를 정의해요. 같은 화면을 만들더라도 출발점과 평가 지표가 달라요.
2. 기획자가 이미 가진 3가지 무기
PM 전환을 고민하다 보면 "내 경력이 다 지워지는 건가" 싶지만, 그렇지 않아요. 기획자 경력에는 PM 직무의 단단한 토대가 들어 있어요.
도메인 지식. 1~3년만 한 도메인을 깊이 다뤄도 신규 PM 입사자보다 사용자 맥락을 빠르게 이해해요. 한국 PM 채용 공고가 강조하는 "고객이 진짜 원하는 것을 발굴할 줄" 아는 능력의 출발점이에요[4].
요구사항 정의·문서화. 정책서·스토리보드를 써본 사람은 모호한 요구를 명세 가능한 단위로 쪼개는 훈련이 돼 있어요. PM의 PRD·기획 문서로 자연스럽게 확장돼요.
이해관계자 커뮤니케이션. 기획자는 개발·디자인·운영·CS·법무까지 두루 조율하는 일을 해요. PM 직무가 요구하는 "타인을 설득할 수 있는 논리력"[4]은 이미 일상에서 단련 중이에요.
이 세 가지는 사이드 프로젝트로 단기간에 따라잡기 어려운 경험 자산이에요. 전환의 출발점은 0이 아니라 +3이에요.
3. 채워야 할 3가지 갭
대신 기획자 → PM 전환에서 솔직히 채워야 할 영역도 있어요. 바로 이 부분이 채용 공고에서 보이는 낯선 단어들이에요[4].
메트릭·데이터 기반 의사결정. GA·SQL을 활용해 가설을 숫자로 검증하는 능력. 토스 PO가 가장 강조하는 자질도 "데이터 중심의 의사결정"이에요[2].
가설 검증·실험 설계. "이 화면을 만들었다"가 아니라 "어떤 문제 → 어떤 가설 → 어떤 실험 → 어떤 결과"로 사고하는 훈련. 토스는 채용 단계에서부터 "가설 기반 액션과 검증"을 이력서에 풀어 쓰라고 안내해요[3].
기술 이해. 깊은 코딩 실력보다는 개발자와 동등한 언어로 트레이드오프를 논의할 수 있는 수준이에요. 한국 PM 채용 면접에서도 개발 지식은 깊이보다 협업 가능성에 가중치를 둬요[4].
여기서 시야를 넓혀 주는 관점이 Marty Cagan의 Inspired예요. 좋은 PM은 valuable(고객 가치) · usable(사용성) · feasible(기술 실현성) · viable(비즈니스) 네 가지를 동시에 책임진다고 정리해요[5]. 기획자가 익숙한 영역은 usable이고, 갭은 주로 valuable·feasible·viable의 정량적 판단에서 생겨요.
4. 전환 시나리오 - 내부 전환 vs 이직
전환 경로는 크게 두 갈래예요.
경로 | 장점 | 단점 | 추천 상황 |
|---|---|---|---|
내부 전환 | 도메인 자산 100% 유지, 점진적 책임 확장 | PM 포지션이 열려야 함, "기획자 출신"이라는 라벨이 따라옴 | 회사가 PO 체제로 전환 중이거나 신규 프로덕트 라인이 열렸을 때 |
이직 | PM 타이틀로 새 출발, 시장 기준의 검증 | 새 도메인 학습 비용, 주니어 PM부터 다시 시작할 수도 있음 | 도메인을 살릴 수 있는 회사를 만나거나, 채용 공고에서 "주니어 PM·PO" 풀이 열렸을 때 |
토스 NEXT PO처럼 "PO 경력이 없어도 프로덕트 경험만 있으면 지원 가능"한 전형도 있으니[2], 이직 옵션을 미리 닫지 마세요. 단, 이때 평가 기준은 이력서가 아니라 문제 해결 사고(예: "토스 송금을 어떻게 개선할까?" 같은 Fit Test)예요[2].
내부 전환이라면 작은 단위부터 PM 영역으로 발을 들여 보세요. 다음 분기 KPI 한두 개를 직접 정의해 보거나, 내가 만든 기능의 성과를 SQL로 직접 들여다보는 식이에요.
5. 이력서·포트폴리오 프레이밍
PM 시장은 "내가 한 일의 목록"이 아니라 "내가 정의한 문제와 검증한 가설"을 봐요[3]. 같은 경험도 이렇게 다시 쓸 수 있어요.
Before (기획자 산출물 중심)
결제 화면 리뉴얼 기획서 작성. 정책 정의, IA 설계, 스토리보드 50p 산출.
After (PM 프레이밍)
결제 단계 이탈률 18%로 진단. "결제 수단 선택 단계가 인지 부담의 핵심"이라는 가설을 세우고 단일 페이지 통합안 A/B 실험. 이탈률 18% → 11%로 7%p 개선, 월 결제 전환 추가 매출로 연결.
가설·검증·정량 결과가 한 줄에 같이 들어 있어요. 토스는 이 구조를 "가설 기반 액션과 검증" + "객관적·논리적 성공/실패 기준"으로 표현해요[3].
이력서를 통째로 다시 쓰는 게 막막하다면, 이미 한 일을 그대로 두고 문장 구조만 재배열해 보세요. 트리업의 경험 관리 기능은 프로젝트별로 문제·가설·결과를 단위로 적도록 안내해 줘서 PM 프레이밍 연습에 잘 맞아요. 정리한 경험은 이력서 빌더에서 직무에 맞춰 재조합할 수 있어요.
6. 면접에서 자주 나오는 질문 카테고리
PM 면접 질문은 대체로 네 갈래로 나뉘어요. 각 질문은 결국 "어떤 사고 과정을 거치는 사람인가"를 보려는 거예요.
우선순위 결정. "리소스가 절반인데 두 기능 중 무엇을 먼저 할까요?" → 가설·임팩트·비용 프레임으로 답변.
메트릭 정의. "이 기능의 성공을 어떻게 측정할까요?" → North Star + 보조 지표(가드레일 포함) 구조.
실패 사례. "기획한 기능이 실패한 적이 있나요?" → 실패한 가설에서 뽑은 학습 포인트가 핵심[3].
기술 협업. "엔지니어가 일정이 두 배 든다고 할 때 어떻게 대응할까요?" → 기술 트레이드오프 이해 + 의사결정 프레임.
토스의 PO Fit Test처럼 "지금 이 화면 어떻게 개선할래요?"식 즉문즉답을 던지는 회사도 늘고 있어요[2]. 평소에 자주 쓰는 서비스 한두 개를 골라 문제 → 가설 → 실험 → 메트릭을 5분 안에 말해 보는 연습이 가장 효과적이에요.
마무리
기획자에서 PM으로의 전환은 "처음부터 다시 배우는 일"이 아니에요. 도메인 지식·요구사항 정의·이해관계자 커뮤니케이션이라는 무기는 그대로 가져가고, 그 위에 메트릭·가설 검증·기술 이해라는 세 층을 새로 쌓는 일이에요.
작은 실험부터 시작해 보세요. 다음 주 회의에서 기능 하나의 성공 지표를 직접 제안해 보거나, 자주 쓰는 서비스의 가설을 1페이지로 정리해 보세요. 작은 노력들이 모여 "화면을 그리는 사람"에서 "문제를 정의하는 사람"으로 바뀌어요.
