PM 커리어 시작하기
자주 묻는 질문에 대한 답변
최근에 온라인으로 PM을 지망하시는 분을 코칭할 기회가 있었습니다.
작은 스타트업에서 이쪽 분야 업무를 조금씩 경험하다 보니 PM이 되고 싶다는 마음이 생기셨다고 하는데, 비슷한 내용으로 다른 분들에게 코칭을 하거나 답변을 드렸던 일이 떠올라 이번기회에 정리해 두면 좋을 것 같아서 글로 남겨볼까 합니다.
직장 경력이 전혀 없거나, 있더라도 얼마 안 된 분들 대상으로 쓴 글이니 이 점 참고해서 읽어주셨으면 좋겠습니다. 그리고 이미 본인의 적성이 PM이 맞다는 것을 발견했다는 것을 전제했습니다.
IT 제품이나 서비스를 만드는 PM(Project Manager)이 되려면
어떻게 시작하는 것이 좋을까요?
PM은 제품 팀을 전체적으로 리딩하는 역할이기 때문에, 관리자로써의 역량이 많이 필요하지만 업무 내용을 본다면 기획자와 많이 가깝다고 할 수 있습니다.
모호한 것들을 가져와서 일을 나누어 결과물을 낼 수 있는 명확한 상태로 바꿔가며 일해야 하기 때문입니다.
기획이 먼저고 이후에 디자인과 개발을 진행하는 것이 가장 일반적인 방식이기 때문에 기획자와 긴밀하게 업무를 진행해야 할 때가 많고, 때로는 스스로가 기획자의 역할을 동시에 수행해야 할 때도 있습니다.
그렇기 때문에 서비스 기획에서 UI 설계까지의 과정은 어느 정도 스스로 할 줄 알아야 합니다.
즉 PM이 되기 위해서는 우선 기획자의 업무를 배우는 것이 순서입니다.
IT제품을 만들기까지의 과정에서 기획자의 역할도 상당히 세분화되어 있습니다.
전략 기획, 서비스 기획, CX/UX/UI 기획, 디자인과 개발 업무 코디네이션, QA(Test), 론칭을 위한 업무, 운영, 마케팅 등으로 구분할 수 있을 것 같습니다.
편의상 세분화한 것이지, 이 모든 영역이 각각 담당자가 꼭 있어야 하는 것은 아닙니다.
이 중에서 PM이 되기 위해 기획업무를 시작한다면, 서비스 기획 ~ UI 기획까지를 먼저 경험해 보기를 추천드립니다.
PM을 초급으로 고용하는 기업이 거의 없는 것도 사실입니다. 아마도 기획 업무 먼저 시작하시게 될 텐데, '나는 PM이 되고 싶은데, 기획만 시키면 나중에 PM 업무를 할 수 없는 것 아닐까?'하고 조바심 내실 필요는 없습니다. 순서가 있다고 생각하시길 바랍니다. 전투기 조종사가 된 후에, 몇 대의 전투기를 리딩하는 전투기 편대장이 될 수 있는 것과 같은 이치입니다.
PM이 되기 위해서는 디자인과 개발을 배워야 하나요?
반대로 디자이너와 개발자인데, PM이 될 수 있나요?
디자인을 하시다가 또는 개발자로 커리어를 시작했는데, 기획자나 PM과 일하는 과정에서 PM에 더 흥미와 적성을 느끼시고 전향을 원하시는 경우가 많이 있습니다.
물론 디자이너나 개발자도 PM을 하실 수 있습니다. 하지만 아직 초급 디자이너나 개발자라면, 조금 더 디자인과 개발을 하다가 전향하시는 편이 좋습니다.
PM 업무를 진행하게 되면 디자이너와 개발자들과 밀접한 커뮤니케이션이 필요합니다.
이미 디자이너, 혹은 개발자라면 그쪽 분야의 커리어를 시작하시기 위해 많은 노력을 하셨을 것이라 생각됩니다. 디자이너 출신의 PM은 UI를 잘 볼 줄 알고, 개발자 출신의 PM은 그만큼 개발 이해도가 높아 복잡한 구조의 서비스를 만들 때 도움이 많이 됩니다. 조금 더 깊이 발을 담가봤던 분야에서 힘을 더 발휘할 수 있다는 뜻입니다.
이렇기 때문에 오히려 특정 분야에서는 그러한 출신 배경을 가진 PM을 더 찾기도 합니다. 그런데 이것은 어디까지나 그쪽 커리어를 어느 정도 쌓아보고 PM으로 전향했을 때의 상황인 것이지, 잠깐 경험했던 것으로는 부족함이 있습니다. 이왕이면 해당 분야에서 조금 커리어를 쌓아보고, 그러고 나서 PM일을 고민해 보시는 것이 좋을 것 같습니다.
PM이 되기 위해서 디자인과 개발을 배울 필요는 없습니다. 하지만 어떻게 디자인이 탄생하는지, 그리고 개발은 어떤 구조와 흐름으로 진행되는지 정도의 이해는 필요합니다.
우리가 만드는 것은 IT 제품이나 서비스이기 때문에, 그것을 만들어나가는 프로세스에 대한 이해도는 필수입니다. 그리고 그러한 내용들을 잘 알아야 디자이너와 개발자들과 커뮤니케이션을 할 수 있습니다.
요즘에는 디자인, 개발에 관련된 자료나 책과 자료들이 시중에 많이 나와 있어서 조금만 찾아봐도 전반적인 지식은 쌓을 수 있는 것 같습니다.
디자인은 UX/UI 차이점과 각 업무는 어떤 요소로 이루어져 있는지, 디자인에 많이 사용하는 툴(Photoshop, XD, Figma 등)에 대해서도 조금 익혀두실 필요가 있습니다.
개발은 Front-End, Back-End를 이루는 기술 요소들, 그리고 Database와 서버 구조 등 업무적인 미팅에서 때 말을 섞을 수 있는 정도를 미리 학습해 두시면 좋을 것 같습니다.
디자인과 개발을 얼마만큼 알아야 한다는 것은 없습니다. 아마 PM업무를 하시는 내내 계속 지식을 업데이트하셔야 할 거예요. 너무 처음부터 어느 정도 공부를 하겠다고 시작하기보다는, 업무를 진행하시면서 모르는 용어나 내용이 있을 때 잊지 말고 찾아보고, 그래도 잘 모르는 부분이 있다면 각 업무 파트에 잘 모르겠다는 것을 솔직하게 인정하고 설명을 요청하면 잘 설명해 주실 거예요.
인하우스와 대행사(에이전시, SI) 중 어느 곳에서 커리어를 시작해야 하나요?
각각 어떤 장점이 있나요?
결론을 먼저 말씀드리면, 고르지 마시고 구직활동 중에 인하우스와 대행사 중 먼저 취업되는 곳에서 시작하시면 됩니다.
인하우스는 자사의 인력으로 IT 제품을 만드는 곳이고, 대행사는 타사의 인력에게 요청하는 방식입니다.
인하우스 기획자 또는 PO의 경우 초급이라면 소규모 스타트업에 수요가 많은 편입니다.
중급 이상의 PO가 필요하기는 하지만, 상대적으로 대기업이나 어느 정도 규모에 오른 스타트업 쪽에서 많이 데려가고 있기 때문에 중급 정도의 인력은 뽑기 힘들어서 그나마 초급 기획자라도 뽑으려고 한다고 생각합니다.
이런 경우 기획 인력도 적고, 그 사람에게 특정한 업무를 맡기기 위해 뽑는 것이라 여러 업무를 두루두루 경험하기보다는 하나의 서비스, 또는 하나의 업무를 집중적으로 하시게 될 확률이 큽니다.
경험적인 면으로 볼 때, 대행사보다 적은 수의 프로젝트나 제품을 담당하게 되지만, 운이 좋다면 제품 아이디어에서부터 출발해 직접 제품을 만들고, 이후 운영까지 하면서 성장시켜 나가는 것들을 모두 경험해 보실 수 있습니다.
좋은 선배가 있다면 해당 도메인 내에서 깊이 있는 학습도 가능할 것 같습니다.
반면에 이직을 하지 않는 이상 너무 같은 서비스를 오래 경험한다는 단점도 있을 것 같네요. 그런 면에 있어서는 대행사가 조금 유리한 편입니다.
대행사에서 업무를 시작하는 경우, 짧게는 2~3개월, 길게는 1년 정도의 시간 동안 IT 제품이나 서비스를 구축하거나 리뉴얼하는 프로젝트를 진행하게 됩니다. 경우에 따라 동시에 여러 개의 프로젝트를 경험해 볼 수도 있습니다.
프로젝트라는 성격상 예산과 인력, 그리고 기간이 정해지기 때문에 인하우스보다는 좀 더 빠른 흐름으로 업무가 진행됩니다. 이러한 부분들이 조금 당황스러울 수도 있겠지만, 그만큼 여러 서비스들을 만들어볼 수 있다는 장점이 있습니다.
하지만 단일 서비스를 론칭한 다음, 메이저/마이너 업그레이드를 통해 지표를 올리며 성장시켜 보는 부분들은 대부분 대행사에 일을 맡긴 후 인계받은 인하우스 담당자들이 진행하게 되므로 특정 서비스를 깊게 다루어보지 못한다는 단점이 있습니다.
이제 막 커리어를 시작하는 사람이라면, 둘 중 어느 것이든 빨리 경험해 보고 경력을 쌓은 다음 다른 쪽으로 이직을 하실 수 있습니다. 물론 인하우스에서 시작해서 계속 인하우스에 계시는 분들도 있고, 대행사에서 시작해서 대행사에서 커리어를 끝까지 쌓아나가시는 분들도 있습니다.
각각 장단점이 있고, 그것이 본인에게 어떻게 작용할지는 어느 곳이든 일을 시작해 봐야 알 수 있습니다.
가기 전부터 둘 중 어느 것이 정답일까 고민하는 것은 불필요합니다.
빨리 취업되는 곳에서 시작하시기를 추천드립니다.
이렇게 말씀드리는 이유는, 한때는 초급의 경우 대행사로의 취업이 잘된다거나, 아니면 인하우스 기업에서 신입을 뽑아서 키워보겠다는 수요가 많았던 적도 있었지만, 코로나 이후 반짝 늘었던 수요가 지금은 IT기업 취업 혹한기라고 말할 만큼 얼어붙었습니다.
여러 기업, 업무 형태에 대한 생각을 열어 놓으시고 취업을 준비하시는 편이 좋을 것 같습니다.
서비스 기획, UI 기획은 어떻게 공부해야 하나요?
아쉽게도 기획은 학습보다는 습득의 영역인 것 같습니다.
디자인은 툴을 중심으로 프로세스를 배우고, 디자인 감각을 익혀나가는 방식으로 시작할 수 있고, 개발의 경우도 개발 언어를 한두 개 정해서 그 언어 학습을 기반으로 배워나갈 수 있지만 기획은 그런 방식이 별로 없습니다.
당연히 시중에 기획 학원도 많지 않고, 물론 PM/PO 부트캠프 등 커리큘럼 가지고 교육을 진행하는 업체도 있지만 한두 사이클 정도 제품을 제작하는 프로세스는 가볍게 경헝해볼 수 있어도 깊이 있게 습득할 수 있도록 교육이 대신해 줄 수는 없는 것 같습니다.
저 또한 많은 후배 기획자들과 함께 일했지만, 기획을 강의하듯 가르쳐본 경험은 거의 없습니다. 실무를 함께 하면서 조금씩 알려주고 틀린 것들만 바로잡아준 것 같아요.
기획은 실무에서 배우는 것이 중요한데, 실무를 해보기 위해서는 입사를 해야 하고, 회사는 또 어느 정도 실무를 해본 사람을 뽑고 있는, 여러모로 힘들고 아쉬운 상황입니다.
일단, 성공한 서비스들을 많이 보면서, 이 서비스는 고객의 어떤 pain point를 잘 짚어서 어떤 방식으로 해결해 나갔는지, 새로운 비즈니스를 만들어낸 서비스는 어떤 아이디어에서 출발했을까, A 서비스 대비 B 서비스가 성공한 이유는 무엇일까 등의 호기심을 갖고 서비스들을 살펴보는 것들은 여러모로 서비스 기획 관점에서 도움이 될 것 같습니다.
동종의 여러 서비스들을 모아서 벤치마킹 해보는 것들도 좋은 서비스 기획력을 높이는 방법입니다.
자신이 잘 쓰는 서비스, 또는 사람들이 많이 사용하는 서비스를 놓고, 이 서비스를 만들기 위해 어떤 기획문서들이 필요했을지 그 문서를 직접 작성해 보는 방법도 있습니다.
'역기획'이라고 많이 표현을 하는데, 그렇게 UI 설계서도 만들어보고, 유저 플로우도 그려보고, 메뉴구조도 파악해 보면서 서비스 기획단계의 문서들을 만들어보는 것도 도움이 많이 됩니다.
그냥 눈으로만 보지 말고, 간단히 메모도 하시고, 여력이 된다면 분석 내용을 콘텐츠로 만들어 블로그 등에 올려보는 습관도 좋을 것 같습니다.
디자이너는 포트폴리오, 개발자는 깃허브 링크 등이 있지만, 기획자는 이력서와 자기소개서 외에 어필할만한 자료들이 적은 편입니다. 그렇다 할 경력이나 포트폴리오가 없다면, 이때 잘 정리해 놓은 분석이나 설계 자료들을 입사지원 시 같이 첨부해 보는 것도 좋습니다.
제가 기획자 채용인터뷰를 할 때에 입사지원을 한 사람이 자신이 쓴 블로그나 브런치 링크를 보내오면 저는 상당히 꼼꼼히 읽어보는 편입니다.
글을 잘 쓰는 사람이 기획을 잘한다고 믿습니다.
커뮤니티 활동을 하는 것도 많은 도움이 됩니다.
Holix와 같은 주제별 커뮤니티, 그리고 단체 대화방 형태로 많은 커뮤니티가 운영되는 것으로 알고 있습니다.
그중에 기획과 PM, IT 주제로 많은 사람들이 모여서 활동하는 커뮤니티에 들어가면 대화에 참여하지 않더라도 얻는 것들이 있습니다.
비슷한 상황에 다른 분이 질문을 올리고, 그 질문에 경험자들이 답변을 올리는 것들을 참조할 수도 있고, 본인이 공부하거나 알려고 하는 노력을 했음에도 불구하고 방법을 찾지 못한 것들에 대해 질문을 올리면 많은 분들이 선의로 답변을 해주는 경우가 많습니다.
취업을 준비 중이시던, 입사를 했는데 가르쳐줄 선배가 없는 경우에 많은 도움을 받으실 수 있습니다.
다음에 또 답변거리가 쌓이면 다른 글로 이어나가겠습니다.
