PM으로 직무 전환을 결정한 이유에 대하여
독자는 미래의 나, 그리고 같은 고민을 하는 누군가

저는 개발자입니다. 였습니다가 맞으려나요. 프론트엔드 개발자로 공부하고 일한 기간은 2년 정도, 백엔드 개발자로 일한 기간이 2년 정도 되어갑니다. 그리고 최근에 PM 직무로 옮기게 되었습니다.
오늘의 글은 제가 왜 이런 결정을 했는지 기록하고 공유하는 것이 목적입니다. 그리고 미래의 제가 저를 돌이켜 보았을 때 나는 이때 이런 생각으로 결정을 했구나 이해할 수 있게 되는 것을 기대합니다. 다른 분들도 제 결정을 참고해 도움을 얻을만한 지점이 있을지도 궁금합니다.
1. AI 시대가 왔습니다
AI 시대가 올 것입니다.는 이제 과거입니다. 이미 왔습니다. 제가 회사에서 백엔드 개발자로 일하면서 직접 코드를 작성하지 않은지가 3개월이 지나갔습니다. 그만큼 이제 AI는 코드 작성을 잘합니다.
물론 책임은 사람이 집니다. 때문에 AI가 한 일들을 관리/감독할 역할이 개발자에게 부여됩니다. AI가 내 머릿속을 다 들여다보지 않는 이상 내가 원하는대로 구현해주었을지, 설계와 아키텍처를 확인할 책임은 개발자에게 남아있습니다.
할 일이 남아있더라도 개발자의 역할이 변하고 있음은 분명합니다. 이제 그들은 코드를 직접 작성하는 사람이 아니라, AI를 관리하는 사람입니다. 할 일이 줄어든다는 것은 전혀 아니지만.. 개발자와 기획자의 역할의 범주가 점점 가까워지고 있다는 생각을 했고, 이 타이밍에 PM으로 직무를 전환하는 것이 유의미하겠다 싶었습니다. 이런 생각을 가지고 있던 차에 PM 동료가 퇴사를 했습니다. 소중한 동료가 퇴사한다는 사실은 마음 속에 큰 아쉬움을 가져다 주었지만, 동시에 저에게는 기회가 되었습니다. 잠깐의 고민 끝에 팀장님께 PM 직무를 해보고 싶다는 의사를 전달했고, 저는 그렇게 PM으로 직무를 전환하게 되었습니다.
2. 저의 성향을 고려했을 때 몰입의 가능성이 높아보였습니다.
최근 제가 신나게 사용중인 에이전트가 있습니다. 제가 개인적으로 만들어 둔 상담 에이전트인데, 이 친구를 구성할 때 제가 했었던 7가지 성격검사 결과지와 제가 직접 입력한 커리어 히스토리 및 배경을 입력하고, 그 내용을 토대로 저에 대한 분석을 시켰습니다. 그리고 그 분석 결과를 바탕으로 profile 문서를 만들었고, 문서는 상담 에이전트의 핵심 컨텍스트 문서로 사용되고 있습니다.
이 친구가 분석해준 내용을 통해 찾아낸 제가 가장 몰입할 수 있는 조건 3가지는 1.만들기 2. 아이디어 내기 3. 누군가를 가르치기(설득하기) 였습니다. 저는 이 분석에 감탄했고, 깊은 공감을 했습니다.
"만들기" 는 제가 개발자로써 가장 많이 했던 활동입니다. 이 부분은 이미 저의 욕구가 충족되고 있었습니다. 그러면서도 언제나 마음 한 켠에서는 충족되지 못하는 2가지 욕구에 대한 아쉬움이 있었습니다. 충족되지 못하는 2가지 욕구 중 하나는 "아이디어 내기" 였습니다. 개발자로 일하면서 저는 주로 무엇을 만들지가 이미 결정된 이후에 등장했습니다. 어떻게 만들지를 고민하는 것은 충분히 흥미로운 일이었지만, 언제나 어딘가 비어있는 느낌이 들었습니다. 고객이 어떤 문제를 겪고 있는지를 직접 발굴하고 싶었고, 어떤 것이 만들어져야 하는지에 대한 논의에 참여하고 싶었습니다.
나머지 하나는 가르치기(설득하기) 였습니다. 저는 무언가를 설명하고, 이해시키고, 함께 생각하는 과정에서 이상하게 활기가 납니다. 에이전트 분석을 통해 알게 된 것 중 하나는 저는 가르치기 위해 탐색할 때 가장 깊이 몰입한다는 것이었습니다. 탐색이 독립적으로 작동하는 것이 아니라, 누군가에게 전달하려는 목적이 있을 때 탐색 자체가 본격적으로 켜진다는 이야기였습니다.
돌이켜보면 납득이 갔습니다. 대학교 때 발표 자리를 찾아다녔고, 없으면 직접 만들었습니다. 개발 공부를 하면서 블로그 글을 쓸 때 가장 즐거웠던 순간은 개념을 완전히 이해했을 때가 아니라, 그것을 누군가에게 설명하는 방식으로 정리했을 때였습니다. 그 글이 주간 트렌딩에 올랐을 때 느낀 것도 유명해졌다는 감각이 아니라, 내 설명이 누군가에게 닿았다는 감각이었습니다.
PM이라는 역할은 이 2가지 동기가 동시에 발휘되는 자리처럼 보였습니다. 고객 문제를 발굴하고 정의하는 것, 무엇을 왜 만들어야 하는지를 팀원들과 이해관계자들에게 설명하고 설득하는 것. 거기에 저는 개발자로써의 경험이 있으니, 만드는 역할도 필요에 따라서 수행할 수 있을것이라 생각했습니다.
3. 이왕 할 거라면, 이 회사에서 하고 싶었습니다
저는 트레바리가 세상에 주고 있는 가치를 좋아합니다. 세상을 더 지적으로, 사람들을 더 친하게 만든다는 문장도 좋지만, 제가 고객으로 직접 독서모임에 참여하면서 사람들이 이 서비스를 좋아하고 가치를 누리는 것을 보고 있습니다. "이렇게 좋은 사람들을 어디서 만날까요", "밖에서는 잘 못하던 대화를 여기서는 할 수 있어요", "4개월의 시간 동안 함께한 멤버들과 대화를 나누면서 제가 굳게 믿고 있던 생각에 금이 갔습니다." 등등의 이야기를 직접 제 귀로 듣다보면, 진심으로 뿌듯함을 느낍니다. 단순히 '이 제품이 좋아요' 수준이 아니라, 그들의 삶에 무언가 긍정적인 영향을 미친다는 점에서 저는 이 가치를 더 잘 주고 싶다는 생각을 하고 있습니다. 개인적으로는 회사가 고객에게 주는 가치에 대해서 이 정도의 공감을 주는 회사를 만나지 못했습니다. 그리고 아직 제 안에는 하고 싶은 일, 할 수 있다고 느끼는 일이 많이 남아 있습니다.
조금 더 이야기해보면 저는 독서의 문화를 확산시키는 것에 무척 관심이 많습니다. 제가 믿는 종교 다음으로 독서가 세상을 조금 더 살만한 곳으로 만들어준다고 생각하기 때문입니다. (왜 그렇게 생각하는지는 다음 기회에 이야기해보겠습니다.) 심지어 책을 읽는 것 뿐만 아니라, 지적인 주제로 대화를 나누는 것 또한 저는 독서로 바라봅니다. 이러한 종류의 문화를 잘 만들고 진심으로 돕고 싶습니다. 그런 문화를 만드는 회사가 트레바리라고 생각합니다.
그런데
개발자로 일하면서, 돕고 싶은 마음과는 별개로 물음표가 생기는 순간들이 있었습니다.백엔드 개발자로 일하던 중에 투표 시스템을 만든 적이 있습니다. 이때 의구심이 들었습니다. 이거 왜 만드는 거지? 이 기능은 우리 제품의 어떤 방향과 닿아 있는 걸까? 물음표는 기능 단위에서 끝나지 않았습니다. 이 제품의 로드맵은 무엇인지, 비전은 무엇인지, 그것이 충분히 정의되어 있는지에 대한 물음으로 올라갔습니다. 그리고 거기에 기여하고 싶다는 생각을 했습니다.
머릿속에는 늘 아이디어가 떠다녔습니다. 이거 하면 좋겠다, 저거 하면 좋겠다. 기획 미팅에 참여하고 싶었고, 의견을 말하고 싶었습니다. 하지만 개발자로서 그 선을 넘는 것이 맞나 하는 생각에 스스로 절제하는 순간들이 있었습니다. 누가 막은 것도 아니었고, 저 스스로가 멈추곤 했습니다.
그런데 절제할수록 오히려 선명해지는 지점이 있었습니다. 나는 이 선 너머에서 일하고 싶은 사람이구나. 고객이 우리 서비스에서 진짜로 느끼는 가치가 무엇인지 직접 정의내려보고 싶고, 그 가치에 닿기까지의 마찰을 찾아내고 싶고, 그것을 해결하기 위해 무엇을 해야 할지 더 적극적으로 고민하고 싶고, 나아가 이 제품이 어디로 가야 하는지 로드맵을 함께 그리고 싶구나 생각했습니다. 개발자로 일할 때는 전달받은 문제와 해결책을 어떻게 구현할지에 초점이 맞추어져 있었습니다. 저는 그 이전 단계에서부터 참여하고 싶었던 것입니다.
아직 PM으로서 한 일보다 하고 싶은 일이 훨씬 많은 상태입니다. 잘할 수 있을지도 모릅니다. 다만 하고 싶은 일의 방향이 선명해졌고, 그 방향으로 한 발을 내디뎠다는 것. 지금은 그것으로 충분하다고 생각합니다.
미래의 저에게 — 이때의 나는 이런 마음으로 이 결정을 했습니다. 돌이켜봤을 때 부끄럽지 않은 선택이었으면 좋겠습니다.