"5년째 코드를 짜고 있는데, 문득 '내가 왜 이걸 만들고 있는지' 답답한 순간이 늘어나신 적 있으세요?" 개발자에서 프로덕트 매니저로 전환하는 건 최근 몇 년 사이 꾸준히 늘고 있는 커리어 경로예요. 토스나 쿠팡처럼 프로덕트 오너십이 강한 문화의 회사가 늘어나면서, 엔지니어가 "What과 Why를 직접 결정하는 자리"에 관심을 갖게 되는 거죠.
기술 배경은 분명 강력한 자산이에요. 하지만 잘못 쓰면 오히려 전환을 방해하는 독이 되기도 해요. 이번 글에서는 전환 전 스스로 물어봐야 할 질문부터, 기술 경험이 유리한 영역과 함정, 현실적인 전환 경로, 그리고 전환 후 첫 해에 꼭 해야 할 일까지 한 번에 정리해봤어요. 내 경험을 어떻게 PM 스토리로 재구성할지 고민된다면 트리업의 커리어 탐색에서 커리어 준비도부터 점검해봐도 좋아요.
정말 PM이 맞나요? — 전환 전 체크 질문 3가지
많은 전환 실패는 "결정 자체가 틀려서"가 아니라 "이유가 틀려서" 생겨요. 내가 진짜 원하는 게 뭔지 먼저 점검해봐요.
"코드 짜는 게 싫어서"인가, "더 큰 문제를 풀고 싶어서"인가?
전자는 몇 달 후 같은 답답함을 PM 자리에서도 반복해요. 한 한국 엔지니어 출신 PM은 솔직하게 이렇게 적었어요 — "개발이 예전처럼 재밌지 않았다"[4]. 하지만 그 뒤엔 "고객 문제를 발견해 해결하고 싶다", "다양한 전문성을 하나의 목표로 묶고 싶다"는 명확한 positive 동기가 함께 있었어요[4]. 부정적 동기만으로는 지속되지 않아요.
애매한 결정을 편하게 내릴 수 있나요?
PM 일의 본질은 persistent ambiguity예요. 엔지니어는 clear feedback loop 안에서 일하지만, PM은 "day-to-day productivity is less tangible" 하고 impact는 몇 달 뒤에야 드러나요[2]. 확실성 없이 결정하고 앞으로 나아갈 수 있어야 해요.
고객·이해관계자를 연결하는 게 진짜 즐거운가요?
PM의 하루는 코드가 아니라 대화로 채워져요. Mind the Product의 저자는 이렇게 말해요 — "nothing can ever replace the good, old-fashioned business of talking to them."[3] 이 일이 "인내해야 할 일"이 아니라 "에너지를 얻는 일"이어야 오래 해요.
기술 배경이 진짜 유리한 3가지 영역
전환을 결심했다면, 당신의 unfair advantage는 어디서 나오는지 알고 있어야 해요.
1. 엔지니어와의 신뢰 관계
역할 분담의 기본은 이거예요 — PMs are responsible for the "what" and "why" while engineers are responsible for the "how" and the "when"[5]. 엔지니어 출신 PM은 "how"의 현실을 알기 때문에 "지금 이게 가능한가, 얼마나 걸릴까"를 감으로 잡을 수 있어요. 스펙 리뷰에서 엔지니어가 "이건 좀 어려워요"라고 할 때 무엇이 어려운지 바로 이해해요.
2. 기술 트레이드오프 의사결정
단기 속도 vs. 장기 유지보수, 복잡도 vs. 확장성 같은 트레이드오프는 비기술 배경의 PM에게 가장 어려운 영역이에요. 기술 경험은 이런 판단을 직관적으로 할 수 있게 해줘요.
3. 데이터 기반 사고
SQL을 직접 쓸 수 있고, 지표의 정의를 스스로 설계할 수 있다는 건 큰 자산이에요. 데이터 팀의 지원을 기다리지 않고 가설을 빠르게 검증할 수 있거든요. 엔지니어가 이미 갖고 있는 analytical thinking은 PM 면접에서도 강력한 차별점이 돼요.
오히려 장애물이 되는 3가지 함정
같은 기술 배경이 정반대 방향으로 작동할 수도 있어요. 이 세 가지는 전환 1년 차에 가장 흔히 마주치는 함정이에요.
함정 1. 솔루션부터 말하기
엔지니어는 훈련을 통해 "문제가 들어오면 곧바로 해결책을 설계"하는 사람이에요. 하지만 PM은 정반대예요 — "not jump into solution mode, but rather to start with the WHY?"[2]
"이 기능 만들면 돼요"보다 "이 사용자는 왜 이 문제를 겪을까요?"를 먼저 묻는 게 PM의 일이에요. 솔루션 점프는 전환 PM이 가장 먼저 고쳐야 할 습관이에요.
함정 2. 구현 디테일에 빠지기
전 엔지니어가 가장 유혹을 많이 받는 지점이에요. Mind the Product의 한 전환 PM은 본인이 이런 말을 하고 있다는 걸 깨달았대요 — "All you need to do is add another column to the campaign table, and a small dropdown over here to set it."[3]
의도는 좋았지만 결과는 최악이에요. 엔지니어는 자신의 전문성이 무시당했다고 느끼고, PM 본인은 전략 일을 할 시간이 사라져요. PM은 "어떻게 만들지"를 결정하는 사람이 아니에요.
함정 3. 성과 측정 기준 혼동
엔지니어는 "lines of code written, pull requests opened, story points completed"[2] 같은 일일 지표로 성취감을 얻어요. 하지만 PM은 자기가 지표 자체를 소유해요. 매일매일의 productivity는 불투명하고, 임팩트는 몇 달 뒤에 나타나요[2]. 이 변화에 적응하지 못하면 "내가 뭔가 하긴 한 거야?"라는 불안에 계속 시달려요.
전환 경로 2가지 — 내부 vs. 외부
Lenny Rachitsky는 수많은 전환 사례를 본 뒤 이렇게 정리해요 — "Internal transition at a large company — Generally the easiest and quickest route."[1]
내부 전환 (현재 회사에서)
Lenny가 말하는 내부 전환에 필요한 3가지예요[1]:
내부 transfer 프로세스 — 회사가 직무 전환을 공식적으로 허용하는가
역량을 보여줄 기회 — 지금 자리에서 PM스러운 성과를 만들 수 있는가
내부 PM 챔피언 — 전환을 지지해줄 시니어 PM이나 리더가 있는가
Mind the Product 저자도 같은 결론에 도달했어요 — 외부 이직보다 내부 전환이 훨씬 쉬웠던 이유는 "stakeholders already knew his reputation and work"였기 때문이에요[3]. 한국처럼 경력 PM 선호가 강한 시장에서는 특히 내부 전환이 현실적이에요.
실행 팁: 지금 역할에서 PM처럼 행동해보세요. Lenny가 추천하는 구체적 액션은 — 사용자 피드백 수집, 제품 분석 보기, 제품 기획 미팅 참석, 제품 제안서 직접 작성이에요[1]. "엔지니어 출신이지만 제품 관점까지 가진 사람"이라는 reputation을 먼저 쌓는 거죠.
외부 전환 (이직)
외부 전환의 가장 현실적인 첫 걸음은 Associate PM(APM) 또는 Technical PM 포지션이에요. 다만 Lenny가 지적하듯 APM 프로그램은 "companies with APM or internship programs"로 한정돼요[1]. 한국 시장에서는 APM 포지션이 드물기 때문에, 대개 Technical PM 또는 기술 도메인 특화 PM으로 입사하는 게 현실적이에요.
이력서 리프레이밍 팁: 기존 개발 프로젝트를 "구현 내역"이 아니라 "제품 의사결정" 관점으로 다시 써보세요. 예를 들어 "API 서버 성능 개선"이 아니라 "사용자 대기 시간 40% 단축으로 이탈률 감소 기여"처럼요. 트리업의 이력서 맞춤 기능으로 PM 공고의 핵심 키워드를 뽑아 내 경험과 매칭해보면 구조가 훨씬 선명해져요.
전환 후 첫 해에 반드시 할 일
전환에 성공한 뒤 첫 해는 "엔지니어 잘하던 사람"에서 "PM 초보"로 리셋되는 시기예요. 이 시기를 잘 넘기는 게 전환 성공의 반이에요.
커뮤니케이션 채널 재설정 — 엔지니어 단톡방 밖으로 나와 디자인·비즈니스·고객 미팅에 의식적으로 참여하세요. PM의 가장 큰 자산은 대화의 폭이에요.
협업 근육 키우기 — 한국 엔지니어 출신 PM은 전환 직후 이렇게 고백했어요 — "혼자 할 수 있는 게 정말 적고 동료의 힘이 절실함"[4]. 엔지니어 시절엔 혼자서 큰 결과를 낼 수 있었지만, PM은 다른 사람의 손을 빌려야만 일이 돼요.
팀의 심리적 안전 만들기 — 기술적 우월감은 독이 돼요. Mind the Product 저자도 강조해요 — "people perform much better in psychologically safe spaces."[3] 내가 코드를 짤 줄 안다는 걸 강조하는 대신, 엔지니어의 판단을 신뢰한다는 신호를 주세요.
성과 지표를 재정의 — "몇 개 배포했는지"가 아니라 "어떤 사용자 문제를 풀었는지"로 자기 성과를 측정하세요. 지표 자체를 소유하는 게 PM의 일이에요[2].
마무리
개발자에서 PM으로 전환하는 건 "강등"도 "승격"도 아니에요. 도구가 바뀌는 거예요. 코드라는 직접적 도구에서 결정·커뮤니케이션·우선순위라는 간접적 도구로 바뀔 뿐이에요. 기술 경험은 사라지지 않고, 배경 자산이 돼요.
전환이 고민 중이라면, 먼저 지금 자리에서 PM처럼 행동해보세요. 스스로 "내가 왜 이걸 만들고 있는지" 질문하고, 사용자와 이야기해보고, 작은 기획서 한 장을 써보세요. 그 경험이 쌓이면 내부 전환도, 외부 이직도 훨씬 가까워져요.
작은 노력들이 모여 큰 성장을 만들어요. 한 걸음씩 시작해보세요!
