mentah

📋 Coaching Brief — Sample

코칭 전에
이미 분석이 끝나 있습니다

당신의 이력서와 커리어를 먼저 읽고,
시장에서의 위치와 선택지를
정리한 상태에서 코칭이 시작됩니다.

멘티개발자 7년차 (백엔드) · 시리즈B 스타트업 재직
주제 1직무 전환 — 개발자에서 PM으로, 시장에서 통하는가주제 2이직 전략 — 타겟 설정, 포지셔닝, 전환 로드맵

이 브리프는 코칭 이전에 작성된 객관적 분석 문서다. 멘토와 멘티는 아직 만나지 않았다. 팩트, 데이터, 시장 해석만 담겨 있고, 판단이나 방향 제시는 포함하지 않는다. 코칭에서 탐색할 질문으로 끝난다.

I. 현재 위치

시장에서 어디에 있는가

직무 전환의 현실성을 판단하기 위해, 현재 보유한 것과 부족한 것을 데이터 기준으로 정리한다. 커리어 경로, 전환 시 강점과 약점, 본인 인식과 시장 해석의 차이를 확인한다.

커리어 경로

순서회사기간역할이동 맥락
1중견 SI 기업3년백엔드 개발자 (Java/Spring)신입 입사. 의도
2시리즈A 스타트업2년백엔드 개발자 → 테크리드소규모 팀에서 기술 의사결정 경험. 의도
3시리즈B 스타트업 (재직)2년테크리드 (백엔드 4명)PM과 직접 협업하는 환경. 의도

읽히는 패턴: SI 개발 → 스타트업 테크리드 → PM 인접 역할로 점진적 이동. 코드 작성에서 기술 의사결정으로, 기술 의사결정에서 프로덕트 의사결정 인접으로 이동해온 경로. 이동에 공백이 없고 맥락이 일관된다.

현재 상태

현 직장: 시리즈B 스타트업 테크리드. 백엔드 4명을 리드하며 PM과 직접 협업. 스프린트 플래닝, 기술 스펙 리뷰, 릴리즈 관리를 담당. 최근 6개월간 PM 부재 기간에 임시로 프로덕트 백로그 우선순위를 직접 설정한 경험이 있다.

본인이 밝힌 전환 동기: (1) 기술적 문제보다 사용자 문제를 정의하는 일에 관심이 커졌다 (2) 코드를 쓰는 시간보다 PM과 스펙을 논의하는 시간이 더 몰입된다 (3) 기술 깊이보다 프로덕트 전체를 보는 역할을 원한다.

이직 현황: PM 포지션 2곳 서류 지원, 전부 탈락. 이력서가 개발자로만 읽힌다고 본인은 판단하고 있다.

강한 카드 / 약한 카드

개발자에서 PM으로 전환을 시도하는 경우 기준. 시장이 PM에게 기대하는 역량과 비교한다.

강한 카드

  • 기술 트레이드오프 판단 경험 7년 — 아키텍처 설계, 기술 부채 관리, 스케일링 의사결정을 직접 해옴. PM이 개발팀과 소통할 때 가장 부족해하는 역량
  • 스프린트 운영 경험 — 테크리드로서 2년간 스프린트 플래닝, 백로그 관리, 릴리즈 사이클을 직접 운영. PM 실무의 절반을 이미 경험한 상태
  • 정량 성과 보유 — API 응답시간 40% 개선, 장애 발생률 월 3회→0.2회, 배포 주기 2주→3일. 시스템 지표이지만 프로덕트 품질 지표로 전환 가능한 숫자들
  • PM 부재 기간 프로덕트 의사결정 경험 — 6개월간 백로그 우선순위 직접 설정, 사업팀과 기능 요구사항 조율. 짧지만 PM 역할의 핵심을 경험

약한 카드

  • 사용자 리서치 경험 0 — 유저 인터뷰, 설문 설계, 페르소나 정의를 해본 적이 없다. PM 실무에서 문제 정의의 출발점
  • 비즈니스 지표 해석 경험 부족 — DAU, 리텐션, 전환율, CAC, LTV를 일상적으로 다뤄본 적이 없다. 시스템 지표와 비즈니스 지표는 해석 프레임이 다르다
  • 이해관계자 관리 경험 제한적 — 기술 조직 내 커뮤니케이션은 익숙하나, 마케팅·세일즈·경영진 등 비기술 이해관계자와의 조율 경험이 적다
  • PRD(Product Requirements Document) 작성 경험 0 — 기술 스펙은 작성하지만, 사용자 스토리 기반의 요구사항 문서를 직접 작성해본 적이 없다

자기 인식 vs 시장 해석

본인 인식시장의 해석판정
개발만 했으니 PM 역량이 없다테크리드 경험 자체가 PM 역량의 일부다. 스프린트 운영, 기술 의사결정, 스펙 리뷰, 릴리즈 관리는 PM이 매일 하는 일. 부족한 건 사용자 리서치와 비즈니스 지표 해석이라는 특정 영역과소 인식
개발자 출신은 PM 서류에서 불리하다테크 PM, 플랫폼 PM 포지션에서는 개발 경력이 직접적 우위. 다만 일반 프로덕트 PM 포지션에서는 리서치·비즈니스 역량 부재가 감점 요소로 작용할 수 있다조건부 사실
7년차인데 주니어 PM부터 시작해야 한다테크 PM이나 플랫폼 PM으로 들어가면 경력이 바로 연결될 수 있다. 일반 프로덕트 PM으로 들어가면 연차 대비 저평가 가능성이 있다. 진입 포지션에 따라 달라진다포지션 의존
기술력이 PM에서는 의미 없다기술을 모르는 PM이 개발팀과의 소통에서 가장 많이 막힌다. 기술 깊이는 PM 시장에서 희소 자원. 다만 기술력만으로 PM의 다른 역량(리서치, 전략, 커뮤니케이션)을 대체할 수는 없다과소 인식

코칭에서 확인할 것

  • 전환의 동기가 기술 피로인지, PM 역할에 대한 실질적 관심인지를 구분해야 한다. 기술 피로라면 전환 외의 해결책도 존재한다
  • PM 부재 기간의 프로덕트 의사결정 경험에서 어떤 부분이 몰입되었고, 어떤 부분이 힘들었는지를 구체적으로 확인할 필요가 있다
  • 코드 쓰는 일을 완전히 놓을 수 있는지, 하이브리드 역할을 원하는지에 따라 선택지가 달라진다

II. 직무 전환

전환 선택지와 트레이드오프

개발자에서 PM으로의 전환에는 복수의 경로가 존재한다. 각 경로는 서로 다른 트레이드오프를 가진다. A~D 중 어느 것이 낫다는 판단은 이 브리프의 범위 밖이다.

선택지 한눈에 보기

A~D는 우열이 아니다. 전환 속도, 리스크 허용 범위, 장기 커리어 설계에 따라 최적 선택지가 달라진다.

A. 테크 PM (빅테크)B. 스타트업 PMC. 개발+PM 하이브리드D. 개발 시니어 유지
경력 연결성높음 (기술 깊이 직접 연결)중간 (기술+제품 감각 모두 필요)최고 (기존 역할 확장)해당 없음
PM 실무 학습중간 (체계적이나 범위 좁음)최고 (0→1 포함 전 범위)제한적 (PM 일부만 경험)없음
진입 허들높음 (대기업 채용 프로세스)중간 (개발 경력 인정)낮음 (현 직장 내 조율)가장 낮음
연봉 영향유지 또는 상승 가능소폭 하락 가능유지유지 또는 상승
핵심 리스크기술 스펙 좁은 PM에 한정될 수 있음리서치·비즈니스 역량 부족 노출PM 타이틀 없이 시간만 흐를 수 있음전환 시점이 계속 밀림

A. 테크 PM — 빅테크/대형 IT 기업

예시 포지션: 플랫폼 PM, 인프라 PM, 개발자 도구 PM, API PM

기회: 기술 깊이가 직접적 가치가 되는 포지션. 개발팀과의 소통에서 다른 PM 대비 명확한 우위. 아키텍처 이해, 기술 트레이드오프 판단, 시스템 설계 역량이 셀링 포인트가 된다. 체계적 PM 프로세스를 배울 수 있다.

리스크: 대기업 채용 프로세스가 길고, PM 경험 0년이 서류 단계에서 걸릴 수 있다. 테크 PM은 기술 스펙 중심으로 역할이 좁아질 수 있어, 사용자 리서치·전략·비즈니스 역량을 쌓을 기회가 제한될 가능성이 있다. 입사 후 코어 프로덕트 PM으로 이동이 보장되지 않는다.

B. 스타트업 PM

예시 포지션: 시리즈A~C 스타트업의 프로덕트 PM, 50~200명 규모

기회: 역할 경계가 유연하여 PM의 전 범위(리서치, 기획, 개발 협업, 데이터 분석, GTM)를 경험할 수 있다. 개발 배경이 스타트업에서 특히 가치가 높다 — 기술 실현 가능성을 직접 판단할 수 있는 PM은 드물다. 0→1 경험 기회.

리스크: 사용자 리서치, 비즈니스 지표 해석, 이해관계자 관리 등 부족한 영역이 바로 노출된다. 체계가 없는 환경에서 PM 기본기를 독학해야 할 수 있다. 개발 출신이라는 이유로 기술 문제 해결에 계속 끌려갈 가능성.

C. 개발 + PM 하이브리드

예시 포지션: 현 직장에서 테크리드 + 프로덕트 오너 겸임, 개발자 출신 PM이 필요한 소규모 팀

기회: 진입 비용이 가장 낮다. 현 직장에서 역할을 점진적으로 확장하면 이직 없이 PM 경험을 쌓을 수 있다. 개발과 PM을 동시에 하면서 적성을 확인하는 기간으로 활용 가능. 연봉 변동 없음.

리스크: PM 타이틀이 공식적으로 부여되지 않으면 이력서에 쓸 수 없다. 양쪽 역할을 하다 어느 쪽도 깊이를 못 가져갈 수 있다. 시간이 지나도 시장에서 PM으로 인정받지 못할 가능성. 현 조직의 구조적 한계에 묶일 수 있다.

D. 개발 시니어 유지

기회: 백엔드 시니어 → 아키텍트 → CTO 트랙으로 기술 리더십 커리어를 지속한다. 7년차 백엔드 개발자의 시장 가치는 현재 높은 편이다. PM 전환으로 인한 레벨 리셋, 연봉 하락, 적응 리스크가 없다.

리스크: 전환 의지가 있는 상태에서 현 경로를 유지하면 기회비용이 누적된다. 8년차, 9년차로 갈수록 전환 비용은 올라간다. 기술 피로가 동기라면, 개발을 유지해도 피로가 해소되지 않을 수 있다.

코칭에서 확인할 것

  • 네 가지 선택지 중 본인이 즉각적으로 끌리는 것과 이유를 확인해야 한다. 끌리는 이유가 현실적 판단인지, 회피인지를 구분할 필요가 있다
  • 리스크 허용 범위 — 연봉 하락, 레벨 리셋, 적응 기간을 어디까지 감당할 수 있는지가 선택지를 좁히는 핵심 변수다
  • 개발을 완전히 놓을 수 있는지, 아니면 개발을 계속 하면서 PM에 가까워지고 싶은 것인지. 이 답에 따라 A/B와 C/D가 갈린다

III. 이직 전략

이동한다면 어떤 조건인가

7가지 필터

기준현재 파악된 상태
산업SaaS·핀테크·개발자 도구·인프라. 기술 깊이가 PM 역할에 직접 연결되는 환경
회사 규모50~500명. PM 조직이 존재하되, 개발 출신 PM에 대한 수용도가 있는 곳
조직 문화엔지니어링 중심 또는 PM-엔지니어 대등 구조. PM이 기술을 이해해야 하는 환경
프로덕트 스테이지1→10 또는 10→100. 0→1은 리서치 역량 부재가 즉시 노출될 수 있음
도메인B2B 또는 B2D(Developer). 기술 의사결정이 프로덕트 가치와 직결되는 환경
직군테크 PM, 플랫폼 PM, 인프라 PM — 기술 깊이가 직접 가치가 되는 포지션
직급선택지에 따라 다름. A는 미드레벨 가능, B는 주니어~미드, C는 직급 변동 없음

이력서 리프레이밍 방향

언어 전환 포인트

  • 기술 구현 성과 → 프로덕트 임팩트로 언어 전환. API 응답시간 개선은 사용자 경험 지표, 장애 감소는 서비스 안정성 지표로 읽힌다
  • 테크리드 → 기술 의사결정 + 프로덕트 협업 프레이밍. 스프린트 운영, 스펙 리뷰, 릴리즈 관리는 PM 실무와 겹치는 영역
  • PM 부재 기간의 프로덕트 의사결정 경험을 별도 항목으로 분리. 백로그 우선순위 설정, 사업팀 조율은 PM의 핵심 업무
  • 시스템 설계 역량을 기술 트레이드오프 판단 역량으로 재정의. PM이 개발팀과 논의할 때 가장 필요로 하는 역량

타이밍 시나리오

전환 시점에 따라 준비할 수 있는 것과 감수해야 하는 것이 달라진다. 세 가지 시나리오를 동일한 비중으로 정리한다.

3개월 내6개월 내12개월 내
준비 가능한 것이력서 리프레이밍, 타겟 기업 리스트업, 네트워크 커피챗위 + 현 직장에서 PM 역할 확장 시도, 사이드 프로젝트 1개 완주위 + 사용자 리서치 경험 확보, PM 커뮤니티 활동, 포트폴리오 구축
장점전환 의지가 강할 때 바로 행동. 시장 피드백을 빨리 받을 수 있다역량 갭을 부분적으로 메운 상태로 진입. 이력서에 쓸 수 있는 PM 경험이 생긴다가장 준비된 상태. 서류 통과율이 높아지고, 면접에서 경험을 말할 수 있다
단점역량 갭이 그대로 노출. 서류 탈락 가능성 높음현 직장에서 역할 확장이 불가능할 수 있음. 6개월이 공전할 리스크전환 시점이 8년차로 밀린다. 연차가 높아질수록 시장의 기대치도 올라간다
전제 조건탈락을 학습으로 활용할 수 있는 멘탈현 직장에서 PM 역할 확장을 조율할 수 있는 관계12개월을 일관되게 투자할 수 있는 동기 유지

코칭에서 확인할 것

  • 7가지 필터 중 본인에게 비협상 조건이 무엇인지를 확인해야 한다. 모든 조건을 충족하는 포지션은 존재하지 않는다
  • 이력서에서 개발자→PM 전환 내러티브를 어떻게 구성할 것인지. 기술 피로 탈출이 아니라 프로덕트에 대한 관심 확장으로 읽혀야 한다
  • 타이밍 선택은 현 직장 상황(조직 변화, 프로젝트 사이클), 재정 상태, 가정 환경 등 개인 맥락에 의존한다. 이 맥락을 코칭에서 확인할 필요가 있다
  • 전환이 아닌 유지(D 선택지)를 선택했을 때의 1년 후, 3년 후 시나리오도 동일한 비중으로 검토할 필요가 있다

실제 코칭 브리프의 구조와 깊이를
보여주기 위한 샘플입니다.
개인정보는 가상 데이터로 대체되었습니다.

← 1:1 코칭으로 돌아가기