Showing Posts From

되려면

PM이 되려면 '경력 3년 이상'이어야 하는 이유, 그리고 개발자는 어디에나 있는 이유

PM이 되려면 '경력 3년 이상'이어야 하는 이유, 그리고 개발자는 어디에나 있는 이유

PM이 되려면 '경력 3년 이상'이어야 하는 이유, 그리고 개발자는 어디에나 있는 이유 공고를 보다가 채용 공고를 본다. 개발자 공고 50개, PM 공고 5개. 개발자: "주니어 환영", "신입 가능", "성장하고 싶은 분" PM: "3년 이상", "유관 경력 필수", "프로젝트 리딩 경험" 똑같이 IT 직군인데 왜 이렇게 다를까. 궁금했다. 아니, 솔직히 짜증 났다. 내가 6년 동안 개발했는데 기획은 신입으로도 못 가냐고. 그런데 생각해봤다. 시장은 감정이 없다. 이유가 있을 거다. 개발자가 흔한 이유 첫째, 만들 수 있다. 부트캠프 6개월 하면 뭐라도 만든다. 토이 프로젝트, 클론 코딩, 포트폴리오. 눈으로 보인다. "이 사람 할 줄 아네" 판단이 쉽다. 둘째, 검증이 빠르다. 코딩 테스트 보면 3시간 만에 실력 나온다. 알고리즘 풀어, 프로젝트 만들어, 깃헙 보여줘. 끝. 틀리면 틀렸다고 바로 나온다. 컴파일 에러, 테스트 실패, 버그. 명확하다.셋째, 교육 인프라가 있다. 학원, 부트캠프, 유튜브, 인강. 코딩 배우는 루트는 천 개다. "파이썬 배우고 싶어요" 검색하면 무료 강의 100개 나온다. 패스트캠퍼스, 코드잇, 노마드코더. 선택만 하면 된다. 그러니까 주니어 개발자는 계속 공급된다. 시장이 원하니까 만들어진다. 넷째, 스케일이 안 된다. 개발자 1명이 100명 몫 못 한다. GPT 시대에도 누군가는 프롬프트 짜고, 코드 검수하고, 배포하고, 유지보수한다. 회사는 개발자가 많이 필요하다. 그래서 주니어도 뽑는다. 키우면 되니까. PM이 귀한 이유 첫째, 만들 수가 없다. PM 포트폴리오가 뭐냐. 기획서? PRD? 로드맵? 그거 혼자 써봤자 검증이 안 된다. 실제로 출시됐냐, 성과 냈냐가 중요한데 그건 회사 안에서만 가능하다. "저 혼자 기획해서 유저 10만 모았어요" - 이러면 뽑는다. 근데 그럴 수 있는 사람이 몇이냐.둘째, 검증이 느리다. 기획은 3개월 뒤에 결과가 나온다. 출시하고, 유저 반응 보고, 데이터 쌓이고. 그 전까지는 "좋은 기획인지 나쁜 기획인지" 아무도 모른다. 면접에서 "이 사람 PM 잘하겠네" 판단이 어렵다. 말은 누구나 잘한다. 셋째, 교육 인프라가 없다. PM 학원 없다. 부트캠프도 최근에 생긴 거 몇 개. 그것도 "실무 경력자 환영"이다. "PM 되고 싶어요" 검색하면 나오는 거? 추상적인 조언. "사용자 중심으로 생각하세요", "커뮤니케이션이 중요해요". 구체적인 방법론은 회사에서 배운다. OKR, 스프린트, 백로그, 우선순위. 실전이 교육이다. 그러니까 PM은 회사 안에서 자란다. 밖에서 키워질 수가 없다. 넷째, 스케일이 된다. 좋은 PM 1명이 10개 프로젝트 망하는 걸 막는다. 나쁜 PM 1명은 30명 개발팀 3개월 날린다. 회사는 PM을 신중하게 뽑는다. 실수하면 비용이 크니까. 시장의 로직 정리하면 이렇다. 개발자는 "만들어지는" 직군이다. 교육하면 나온다. 검증하면 쓸 만한 애들 걸러진다. 회사는 많이 필요하다. 그래서 주니어도 뽑는다. PM은 "자라는" 직군이다. 회사 안에서 경험 쌓아야 한다. 실패 비용이 크다. 회사는 적게 필요하다. 그래서 경력자만 뽑는다.시장은 냉정하다. 감정 없다. 수요와 공급, 리스크와 리턴만 계산한다. 나는 이게 이해가 됐다. 억울하지만 논리는 맞다. 그럼 나는 어떻게 6년 개발했다. 이제 PM 하고 싶다. 근데 신입 PM 자리는 없다. 방법은 세 가지다. 1. 사내 전환 지금 회사에서 PM으로 옮긴다. 제일 현실적이다. 개발 경력이 증명이 된다. "쟤 6년 했으니까 시스템은 이해하겠네", "개발팀이랑 소통은 되겠네". 인사팀한테 말한다. "PM 해보고 싶습니다, 기회 주세요". 6개월 시범 운영도 좋다. 리스크: 회사에 PM 자리가 없으면 끝이다. 아니면 몇 년 기다려야 한다. 2. PM 필요한 스타트업 시리즈 A, B 정도 스타트업. 개발자는 있는데 기획자가 없는 곳. "개발 경력 6년, PM 전환 희망"이라고 쓴다. 일부는 관심 있다. 연봉은 깎인다. 6200에서 5000 정도? 근데 타이틀은 PM이다. 리스크: 스타트업 망하면 경력 1년도 안 쌓고 튕긴다. 3. PO 포지션 노리기 Product Owner, Technical PM 이런 자리. 개발 백그라운드 환영하는 곳. 대기업, 중견 플랫폼 회사에 종종 있다. 개발 + 기획 하이브리드. 완전한 PM은 아니지만 발 들이기엔 좋다. 리스크: 자리가 진짜 적다. 공고 보기 힘들다. 나는 1번 준비 중이다. 팀장한테 슬쩍 얘기했다. "요즘 기획 쪽에 관심이 생겨서요". 반응은 애매했다. "음... 그래? 근데 개발도 잘하잖아". 그래, 잘한다. 근데 GPT가 나보다 10배 빠르다. 이건 말 안 했다. 착각하지 말 것 PM이 개발자보다 쉬운 거 아니다. 어떤 개발자는 착각한다. "코딩보다 기획이 쉽겠지, 말만 잘하면 되잖아". 아니다. PM은 책임이 무겁다. 프로젝트 망하면 PM 탓이다. 개발자는 "기획이 이상했어요" 하면 된다. PM은 정답이 없다. 코드는 돌아가면 맞는 거다. 기획은 출시해도 맞는지 모른다. PM은 설득이 일이다. 개발팀, 디자인팀, 경영진, 고객. 하루 종일 설득한다. 내가 PM 할 수 있을까? 모르겠다. 근데 개발은 확신이 없다. AI가 더 잘한다. 이건 확실하다. 5년 뒤 개발자 연봉은 내려간다. 공급이 늘어나고, AI가 대체한다. 시니어 개발자는 살아남는다. 아키텍처 짜고, 주니어 관리하고, AI 검수하는 사람. 주니어, 미들은? 글쎄. PM은 어떨까. AI가 PRD 써주고, 로드맵 짜주고, 데이터 분석해준다. 그래도 "뭘 만들지" 결정은 사람이 한다. 책임도 사람이 진다. 당분간은. 나는 그쪽에 베팅한다. 틀릴 수도 있다. 5년 뒤에 "개발 계속 할걸" 후회할 수도 있다. 근데 지금 이대로는 5년 못 버틴다. 확신이 없다. 시장을 이해하면 억울해하지 않게 된다. "왜 PM 신입은 안 뽑냐"고 화내지 않는다. 시장의 로직을 안다. 대신 전략을 짠다. 어떻게 경력을 만들지. 어떻게 검증을 받을지. 어떻게 리스크를 줄일지. 나는 지금 회사에서 기획 문서를 쓴다. 아무도 안 시켰다. 그냥 쓴다. 다음 스프린트 제안서, 기능 개선 PRD, 데이터 기반 우선순위 분석. 노션에 쌓인다. 팀장이 본다. "오, 이거 괜찮은데?" 한다. 1년 뒤에 "PM 해보고 싶어요" 말할 때 근거가 된다. "제가 이미 6개월 동안 이런 거 해봤거든요". 시장은 냉정하다. 하지만 룰은 있다. 룰을 이해하면 게임을 할 수 있다.공고를 보다가 빡쳤다. 이제는 전략을 짠다. 시장이 원하는 걸 만든다.