오늘의 상황
튜터님과 상담을 하면서 이런 질문을 받았다.
왜 PM이 하고 싶나요?
나는 “문제 해결하는 것이 좋아서요”, “내 제품을 만드는 것이 좋아서요” 같은 대답을 했다.
하지만 튜터님은 그 정도의 답변으로는 부족하다고 피드백해주셨다.
이미 개발자로 4년의 경험이 있기 때문에, 단순히 “좋다”, “해보고 싶다” 정도의 답변이 아니라 왜 개발자가 아니라 PM이어야 하는지에 대한 더 명확한 이유가 필요하다는 말씀이었다.
튜터님은 내가 PM이 된 뒤에도 적성에 맞지 않으면 그다음 선택은 어떻게 할 것인지 걱정되어 더 깊게 물어보신 것 같았다.
처음에는 조금 당황했고, 약간 혼나는 것처럼 느껴지기도 했다.
생각은 많은데 말이 정리되지 않아 더 조급해졌다.
왜 답변이 잘 안 나왔을까
돌아보니 내가 내 경험을 충분히 체화했다고 생각했지만, 실제로는 그것을 긴 문장으로 쭉 써본 적이 없었다.
머릿속에는 여러 조각이 있었다.
- 개발자로 일하면서 기능을 만드는 것만으로는 해결되지 않는 문제를 봤던 경험
- “왜 이 기능을 만드는지” 모른 채 구현만 했던 답답함
- 사용자 문제와 비즈니스 목표가 연결되지 않은 기획을 보며 느꼈던 의문
- 직접 사이드 프로젝트를 하며 문제 정의, 팀 운영, 사용자 반응까지 고민했던 경험
- 훌라 수업과 개인 사업을 하며 고객의 반응과 운영 문제를 직접 마주했던 경험
하지만 이 조각들이 하나의 답변으로 정리되어 있지는 않았다.
그래서 질문을 받는 순간, 많은 생각이 동시에 떠올랐지만 명확한 문장으로 나오지 않았다.
오늘 깨달은 것
“왜 PM이 되고 싶은가?”라는 질문은 단순한 취향 질문이 아니었다.
PM이 좋아 보여서 하고 싶은가?
아니면 내 경험상 PM의 역할이 필요하다는 것을 직접 느꼈기 때문에 하고 싶은가?
를 묻는 질문에 가까웠다.
튜터님이 원한 답변은 “문제 해결이 좋아요”가 아니라, 아마 이런 구조였을 것이다.
- 나는 개발자로 어떤 문제를 반복해서 경험했는가?
- 그 문제는 개발 역량만으로는 왜 충분히 해결되지 않았는가?
- 그 과정에서 PM의 어떤 역할이 필요하다고 느꼈는가?
- 그래서 나는 왜 PM으로 전환하려 하는가?
- PM이 되었을 때 어떤 방식으로 가치를 만들고 싶은가?
즉 “왜 PM인가?”는 감정이나 선호의 문제가 아니라, 내 경험에서 출발한 커리어 선택의 논리를 묻는 질문이었다.
지금의 나에게 필요한 정리
앞으로 이 질문에 답하려면, 내 경험을 단순히 나열하는 것이 아니라 하나의 흐름으로 정리해야 한다.
예를 들면 이렇게 정리할 수 있다.
- 개발자로서 느낀 한계
개발자로 일하면서 기능 구현 자체는 할 수 있었지만, 때로는 “이 기능이 왜 필요한가?”, “이 기능이 어떤 사용자 문제를 해결하는가?”, “이 기능이 비즈니스 목표와 어떻게 연결되는가?”가 충분히 공유되지 않은 상태에서 일한 경험이 있었다.
그때 나는 단순히 코드를 잘 짜는 것만으로는 제품의 문제를 해결하기 어렵다는 것을 느꼈다.
- 사이드 프로젝트에서 경험한 PM 역할
사이드 프로젝트에서는 아이디어 제안, 팀 구성, 문제 정의, 일정 조율, 사용자 반응 확인까지 직접 해봤다.
이 과정에서 기능을 만드는 것보다 더 어려운 것은 “어떤 문제를 풀 것인가”를 정의하고, 팀이 같은 방향을 보게 만드는 일이라는 것을 알게 되었다.
- 사용자와 비즈니스 사이를 연결하고 싶은 욕구
훌라 수업과 개인 사업을 하면서도 고객이 말하는 요구와 실제로 필요한 것이 다를 수 있다는 것을 경험했다.
사용자가 원하는 것을 그대로 제공하는 것보다, 그 뒤에 있는 진짜 문제를 이해하고 더 나은 경험으로 연결하는 일이 중요하다고 느꼈다.
- 그래서 PM을 하고 싶은 이유
나는 기능을 구현하는 것에서 더 나아가, 사용자 문제를 정의하고, 비즈니스 목표와 연결해, 팀이 실행 가능한 방향으로 움직이게 만드는 일을 하고 싶다.
그래서 PM이라는 역할에 끌린다.
답변 초안
아직 최종 답변은 아니지만, 지금 단계에서는 이렇게 말해볼 수 있을 것 같다.
저는 개발자로 일하면서 기능을 구현하는 일 자체보다, “왜 이 기능을 만들어야 하는지”, “이 기능이 어떤 사용자 문제와 비즈니스 목표를 해결하는지”가 명확할 때 더 몰입한다는 것을 알게 되었습니다.
이전 회사에서는 상위 목표나 문제 정의가 충분히 공유되지 않은 상태에서 기능을 구현하는 경우가 있었고, 그때 단순히 개발을 잘하는 것만으로는 제품의 문제를 해결하기 어렵다는 생각을 했습니다.
이후 사이드 프로젝트와 개인 사업을 하면서 문제를 정의하고, 사용자의 반응을 보고, 팀을 설득하고, 실행 방향을 정하는 경험을 했습니다. 그 과정에서 제가 더 오래 고민하고 싶어 하는 지점은 “어떻게 구현할까”보다 “무엇을 왜 만들어야 할까”에 가깝다는 것을 느꼈습니다.
그래서 저는 PM으로서 사용자 문제를 비즈니스 목표와 연결하고, 팀이 실행 가능한 방향으로 움직이게 만드는 역할을 하고 싶습니다.
앞으로 할 일
이번 질문에 제대로 답하려면, 감으로 말하지 말고 내 경험을 더 구체적으로 정리해야 한다.
앞으로 이틀 정도 아래 질문에 답해보려고 한다.
- 개발자로 일하면서 가장 답답했던 순간은 언제였는가?
- 그 답답함은 단순히 회사 문제였는가, 아니면 내가 더 하고 싶은 역할을 보여주는 신호였는가?
- 사이드 프로젝트에서 내가 가장 몰입했던 순간은 언제였는가?
- 훌라 수업과 개인 사업에서 고객 문제를 직접 마주한 경험은 PM과 어떻게 연결되는가?
- PM이 되었을 때 내가 만들고 싶은 가치는 무엇인가?
- 내가 PM으로 가도 다시 힘들어질 수 있는 지점은 무엇인가?
- 그럼에도 불구하고 왜 이 방향을 선택하려 하는가?
오늘의 한 줄
“왜 PM이 되고 싶은가?”라는 질문은 직무 선호를 묻는 질문이 아니라, 내가 어떤 문제를 반복해서 보고 있고, 앞으로 어떤 방식으로 가치를 만들고 싶은지 묻는 질문이었다.
덧붙임
오늘은 멘토링을 받으며 당황했고, 생각이 많아져서 바로 답변을 잘하지 못했다.
하지만 그 덕분에 내가 아직 내 커리어 전환의 이유를 충분히 언어화하지 못했다는 것을 알게 되었다.
이제는 머릿속으로만 생각하지 않고, 내 경험을 글로 풀어보면서 “왜 PM인가?”에 대한 답을 더 명확하게 만들어가야겠다.
