대기업 IT부서가 PM 커리어의 무덤이 되는 이유
대기업 'IT기획자' 를 바라보고 있는, 주니어 PM들을 위해 작성합니다.
시니어보다는 주니어분들이 읽어봤으면 좋겠습니다.
나는 '기획자' 라고 부르는 것을 싫어한다. (해외에는 '기획자'라는 단어가 있던가? 잘 모르겠다.)
특히 IT바닥에서의 '기획자'라는 단어는 그 의미와 뉘앙스가 '잡부'의 그것과 별반 다르지 않기 때문이다.
전통 대기업에서 바라보는 IT기획은, 일반 네이버나 카카오 등 IT플랫폼 기업의 PM이 일하는 내용과 완전히 다르다. 아예 전혀 다른 별개의 직무라고 봐도 무방하다. 지원하려면 확실한 각오를 하고 덤벼야한다.
무엇을 하느냐면.
대기업 IT '기획자'들은 IT 예산을 잡고, 개발자 모니터와 각종 케이블등 비품을 신청하며, 상급자나 임원을 보좌한다. 여기서 보좌라 함은 그들을 위해 PPT장표도 만들고, 시장조사도 하고, 회의도 잡는 등 '수명업무'를 한다는 거다. IT '총무부'가 하는 일을 할 가능성이 높다.
물론 IT서비스 기획도 한다. 그런데 그게 이런 식이다.
"ㅇㅇ씨, 이번에 인공지능으로 자동화하는거 그런거 있잖아. 하나 그럴듯하게 기획서 써서 가져와봐."
"네, 인공지능이요? 어떤 자동화를 말씀하시는지. 조금 더 구체적으로 문제사항이나 혹은 외부 요청내용, 큰 방향에 따른 목적 등을 말씀해주실 수 있을까요?"
"그런건 없어. 전무님이 하고 싶다고 하시니까. 그냥 일단 기획서부터 하나 써와봐. 윗분들 관심이 큰 건이니까, 신경써."
문제가 뭔지, 그래서 하고자 하는 목적이 뭔지, 궁극적인 방향이 뭔지 그런거 없다. 실장이나 팀장 등 관리자들은 '윗선에서 더 높으신 분들이 인공지능 관심있다고 하셨으니, 그럴듯하게 기획안 만들어 보고해서 내 실적 챙기고, 그러면 자리 보전에 문제 없겠지?' 라는 생각 뿐이다. '기획자'는 그냥 이런거저런거 다 하는 사람이니 대충 던져놓고 알아서 하라고 하는 식이다.
요새 제조 대기업 등에서 개발자들을 많이 채용했다. 또 채용하는 중이다. 하지만 실력있는 개발자들은 그런 곳에 잘 가려고 하지 않는다. IT서비스 기업에 가는 것이 커리어에 훨씬 도움이 되기 때문이다. 그렇다면 누가 가는가? 퇴직을 앞둔, 본인 입지가 애매한, 실력이 없어 불안한, 그런 시니어 개발자들이 최근 대기업으로 많이 자리를 옮겼다.(물론 IT회사보다 제조업이 정말정말 좋아서 옮긴 분들도 어딘가 있을테다. 하지만 적어도 내 경험상 그랬다.) 나이도 있으니 이제 따뜻한 정년을 바라보는 것이다. 그런 개발자를 리더로 만들고 '자 이제 IT해봐!' 라고 판을 깔아주는데, 그 리더들이 PM을 바라보는 관점이 00년대에서 많이 벗어나지 못한 상태다. '개발 이외의 모든 건 기획자가 한다'는 마인드다. 죄다 PM에게 던진다. "개발자는 개발하느라 바쁘니까, 그런건 기획자들이 전부 앞에서 협의하고 처리하세요" 라는 말을 매일 듣게 된다. 아마 팀도 결국엔 개발팀/기획팀으로 나누자고 할 가능성이 높다. 귀찮으니까. 에이전시와 일하는 SI업체의 태도와 비슷하다고 생각하면 편하다. PM은 모든 잡동사니 업무를 도맡는다. (개발만 빼고)
이런 식으로 '기획자'라는 단어의 직무를 만들어 놓고 온갖 종류의 일을 시킨다. 그래서 네이버나 카카오 등에서 일하는 서비스 PM들이 하는 업무와는 전혀 다른 일을 담당할 가능성이 높다.
기획자의 '성장'? '성장'이 뭔지 아예 모른다. 관심도 없다. 인터넷 교육 몇개 들으라고 하고 '됐지? 알아서 성장해~' 라고 한다.
최근 PM들 중에는 SQL에 능통하고, 파이썬 등은 어느정도 코딩이 가능하신 훌륭한 분들이 많다. 그리고 그것을 장려하는 추세이기도 하다. 그런데 대기업 어떤 IT부서의 장은 '기획자가 테이블을 왜 봐! 기획자면 기획자 답게 백엔드 설계다 API다 관심갖지 말고, 화면 그림 그리고 정책 문서나 잘 만들어!'라고 대놓고 이야기한다. 이게 현실이다. 이러니 각종 툴로 예쁘게 금칠한 화면 그리는 데만 혈안이 될 수 밖에.
업무 협업 툴도 유심히 살펴보자. 컨플루언스나 지라, 노션, 슬랙 등 업계 전반에서 두루 쓰이는 툴이 아닌, 들어보지도 못한 묘한 툴을 사용한다면? 갈라파고스 섬으로 스스로 걸어들어가는 꼴이다. IT업계에서 일반적으로 사용되는 툴들을 적극적으로 사용해 몸에 익히고, 연습해도 모자랄 판에 통용되지도 않는 협업 툴을 사용해야 한다면, 결국 시장에서 도태되고 낙오하는 것은 당연하다. 서서히, 자기도 모르게 시나브로. 이것 또한 커리어의 무덤이 되는 이유 중 하나다.
어떤 대기업에서는 아예 'IT기획부'를 따로 만들어놓고, 마치 SI업체처럼 사용한다. 윗 분들이 관심있는 과제들을 던져서 기획/구현 시키고, 마무리되면 또 다른 과제를 내리고, 서로 연관성 없는 과제를 동시에 진행하기도 한다. '기획 공장'인 셈이다. 컨베이어 벨트에서 물건을 찍어내듯 기획서를 찍어낸다. 사업에서 요구하는 대로 납품을 처리한다. 이런 조직 구조에서는 PM이 자신의 '담당 도메인' , '담당 프로덕트'를 가질 수 없다. 제품에 대한 깊은 고민과 이해를 바탕으로, 긴 호흡으로 계획하는 일 따위는 없다. 운영시 발생하는 데이터와 지표를 확인하며 인사이트를 얻기 어렵다. 테이블 구조? 그걸 왜 기획자가 알아야 하는데? 백엔드 설계? 그걸 기획자가 왜 신경써? 결국 단순히 화면을 그리는 수준에 머문다. ‘도메인 구조’ , ‘운영 방안’ , ‘비지니스 이해’ , ‘데이터 파이프라인’ 등에 대한 고민은 사치다. 사업이 해달라는대로 듣고, 기획서 써서, 외주 통해 구현하고, 다시 사업에 넘기면 그만이다. 그냥 건 바이 건으로 '시키는 일 기획하는' 에이전시 기획자로 일하는 것이다.
반드시 PM 이라고 불려야 한다. P가 Product 여야 하고, 때에 따라 Project가 되어야 한다. PM이라면 반드시 본인의 프로덕트를 가져야 한다. 직접 운영하며 문제점을 찾고, 고도화 포인트를 파악하고, 매일 데이터를 확인하고, 담당 개발자와 끊임없이 대화하며, 자신의 제품에 대해 오래, 치열하게 고민해야 한다. 그 고민의 깊이와 총량이 결국 담당하는 제품의 가치로 나타난다. Owner로서의 자세로 연습해야 한다. 그러면 깊은 통찰을 갖고 우아하게 성장할 수 있다.
하지만 대기업 IT부서는 그렇게 일하지 않는다.
다시 이야기하지만, 대기업에서 불리는 '기획자'는 일반적인 제품 PM의 업무와는 다른 일을 한다.
반드시 기억해야 한다.
대기업 IT부서의 기획자로 입사한다면, IT서비스 PM으로서의 커리어는 꼬이고 박살난다.
요새는 조금 유혹하는 방향이 달라졌다. (일종의 함정이다)
일부 대기업 IT부서 JD를 살펴보면 서비스 기획을 한다고 기재되어 있긴 하다. 하지만, 현혹되지 마라. 실제로는 IT총무부 의 업무를 한다. 반드시 그렇다.
서비스 기획도 하고, 이것저것 수명 업무도 하는, 무엇이든 시키는 건 다 하는 잡부 '기획자'가 되는거다. 본인 도메인에 주인 의식을 가지고 몰입하는 PM과는 전혀 다른 직무이다. 개발자가 하기 싫어하거나 귀찮아하거나 하는 모~든 일을 '이런건 기획자가 좀 봐줘야지?' 하면서 던진다. (당연히 개발자도 할 수 있는 업무다)
이는 제조업 베이스일 경우 더 심해진다.
아예 IT관련 마인드가 장착되지 않은 조직장들이 득시글대는 곳에 떨어진 '기획자'는 좋은 먹잇감이 된다. 최악의 경우에는 임원 wifi 설정 등 PC 셋팅만 담당하게 되는 경우도 있다. 혹시 신규 입사자라면, 반드시 HR 페이지를 확인해보라, 본인 직무에 'IT기획' 이라고 되어있지 않고 '사업지원' 이나 '총무'(요새는 이런 것들을 '전략'이란 단어로 포장하곤 한다) 등의 직무로 기재되어 있을 수도 있다.
운이 좋아 서비스 기획자로 일할 수 있게 된다면, 컨베이어 벨트 앞의 단순 노동자처럼 '공통IT기획부'에서 연관도 없는 서비스들의 기획서를 찍어내는 일을 반복할 가능성이 높다. 개발자와 이야기할 일은 거의 없다. 기획서를 개발팀에 넘기고 내 역할은 끝나기 때문이다. 혹시 개발자와 협업할 기회가 주어진다 쳐도, 외주 프리랜서 계약을 맺은 개발자분들과 일하게 된다. 제품에 대한 애정보다는 '구현 후 철수'에 목적을 둔 분들이 많은 것은 당연하다. 이 과정에서 일부 주니어 기획자들은 '갑질'을 하는 못된 습관을 배운다. 그 무엇보다 중요한 '태도'가 박살나는 것이다. '태도'가 망가진 주니어들은, 기괴한 방식으로 자라나, '협업'이 아닌 '지시'에 익숙해진다. 그런 고압적인 업무 태도는 결국 인생에도 영향을 끼친다. 선배들을 보고 익힌 오만하고 무례한 '갑'의 태도에 젖어 'PM'이 아닌 단순 '관리자'가 된다. 참고로 '관리자'는 다가오는 미래에 사라질 직업 1순위다.
혹시 연차가 제법 있는 시니어인가?
그럼 그나마 좀 낫다. 당신이 걸어온 길이 이미 당신의 역량을 증명해주기 때문이다. 연차가 있는 당신을 채용했다면, 아마 이도저도 안되는 서비스의 '담당자' 역할을 바라는 것일 수 있다. 여기서 '담당자'에 주목해야 한다. 'PM'이 아니다. '담당자'다. 말도 안되는 요구 사항 구현, 도무지 대화가 통하지 않는 사업현업과의 커뮤니케이션, 임원의 어이없는 상상 실현 등을 맡을 '담당자'가 될 가능성이 높다. 윗 분들은, 나는 잘 모르겠고, 신경쓰기도 귀찮고 하니, '맡아서 처리해, 나의 성과로 만들어줄 누군가'가 필요할 뿐이다. 아마 이런 식의 지시사항이 내려올 가능성이 높다. “네이버가 이런거 하던데, 우리도 준비해서 진행해” , “카카오는 하는데 우리는 왜 못해? 우리도 TF만들어서 그런거 추진해“
주니어인가?
그렇다면 조심하고 또 조심하라. 이렇게도 쓰고, 저렇게도 쓰려고 일단 뽑아놓고 보는 대기업들이 많다.(자기들이 고용하는 사람이 무슨 일을 해야하는지도 모르는 채용담당자들이 태반이다.) 위에 이야기한 '기획자'로 뽑아서, 서비스 기획도 시키고, (임원이 궁금해하는) 업계 현황 조사도 시키고, 예산 업무도 시키고, 비품도 사다 채우고, 사내 인사지원도 나가고, 잡다한 수명 업무도 시키는 것이다.
대부분 철저한 상명하복 문화가 밑바닥까지 자리잡은 곳으로, 일을 해야하는 이유에 대한 설명이나 동기 부여 등은 애초에 기대하지 않는 편이 좋다. 그냥 까라면 까는거다.
자기들이 채용한 PM이 Backend 에 특화되어 있는지, 유저 Flow등 UI/UX에 특화되어있는지, 프로젝트 관리가 중점 역량인지 등은 아예 관심이 없다. 아니, 당신의 상급자들은 아예 그런게 뭔지 전혀 모를 가능성이 높다. “아무나 대충 뽑아서 가르치면 되는거지 뭘 그렇게 까다롭게 채용하나?” 라고 말하는 기획팀 리더가 실제로 존재한다. 그런 리더에게, 팀원들의 커리어패스 케어나 역량 성장을 위한 관심 같은건 애초에 기대하지 마시라.
먼저, 채용 공고에 '검색 Product', '송금 Product' , '여신 Product' 등과 같이 명확한 도메인 명이 기재되어 있지 않고, 'IT시스템 전반' 혹은 '다양한 서비스 플랫폼 기획' 등 모호하게 업무가 기재되어 있다면 쳐다보지 않는 것이 좋다. 위에서 이야기한 '기획 공장'의 컨베이어 벨트 앞에 서게 될 가능성이 높기 때문이다.
또한, 팀명 혹은 조직명을 잘 확인해보라. ’검색팀‘, ‘송금팀’ 처럼 도메인의 명확한 아이덴티티가 드러나지 않고 ‘IT서비스 기획팀’ 으로 얼렁뚱땅 부른다면 컨베이어 벨트가 당신을 부르고 있는 것이다.
회사만 보고 지원하지 마라. 단순히 ‘대기업이니까 가고 싶다’는 생각은 곤란하다. 아니 위험하다. 원하는 도메인을 명확하게 목표로 설정하고 커리어를 만들어나가라.
혹시 인터뷰까지 진행되었다면, 내가 담당할 도메인에 대해 명확히 물어보라. 인터뷰어가 '전반적인 IT시스템 기획을 담당하시게 될꺼에요', '여기저기 바쁜 업무가 많아서, 그런 곳 위주로 지원하시게 될꺼에요', ’고정은 아니고, 이번 ㅇㅇ 프로젝트 런칭이 끝나면 다음 프로젝트를 맡아 진행하시게 될 꺼에요‘ 등으로 담당할 업무에 대해 뭉툭하게 답한다면 공장행이다. “저는 앞으로 ㅇㅇ 도메인의 PM으로서 런칭부터 운영 및 고도화까지 오롯이(지속적으로) 담당하게 되나요?“ 라고 단도직입적으로 물어보라. 메뚜기처럼 이 프로젝트 저 프로젝트를 뛰어다니며 맥락없이 일하고 싶지 않다면 말이다.
다시 말하지만, 내 제품이 있어야 한다.
한 프로덕트의 담당자로서 깊이 있게 고민해야 한다.
매일매일 본인 제품의 지표를 확인하고 의미를 읽어내야 한다.
본인의 프로덕트 개발자와 끊임 없이 소통하며 기술적으로도 성장하는 PM이 되어야 한다.
그 치열한 과정을 거쳐 한 분야의 전문가가 되시라.
대기업이라는 달콤한 향기를 맡고 개미지옥에 빠져 홀린 듯 멋모르고 지원하는 주니어들이 많다.
단순히 '대기업'이라는 이름을 갖고 싶은 욕망에 본인의 앞날이 어떻게 될지도 모른채 불구덩이로 뛰어드는 격이다. (실제로 내가 아는 어떤 분은 데이터 분석가의 능력을 겸한 훌륭한 백엔드 주니어 PM이었으나, 대기업의 유혹에 빠져 이직한 후 1년이 넘도록 테이블 쿼리 하나 날려보지 못한 채 허송세월 하고 있다. 현재 그의 주 업무는 실장의 PPT 보고서 작성이다.)
그런 포지션에 채용되어 입사한 주니어들은 커리어 관리에 온 신경을 집중해야 한다.
몇 년 후, 제대로 된 프로젝트 하나 없이, 허술해진 이력서를 들고 한참을 후회하기 싫다면 말이다.
대기업 IT부서의 채용 담당 직원분들은, 제발 주니어들의 커리어를 생각해서 채용해주면 좋겠습니다.
채용을 담당하고 있으니 아마 해당 부서 조직장 혹은 실무리더 일 가능성이 높을텐데,
어떤 인력을 채용해야 할지 잘 모르겠으면 막내 기획자들이나 개발자들에게 물어보세요.
명확한 JD를 오픈하여, 지원자들이 착각하지 않도록 했으면 좋겠습니다.
지원자가 없어서 어쩔 수가 없다구요? 이상한 사람들만 지원한다구요? 20년차 가까이 되는 관리자들만 지원한다구요? 제대로 된 실무급 지원자가 없는 건, 이미 내부 문화와 일하는 방식에 대해 안 좋은 평판이 퍼져있다는 겁니다. ‘블라인드’가 있잖아요. 시장에서의 소문은 빠르고, 젊은 친구들은 엄청나게 똑똑합니다. 몰랐으면 좋겠지만, 사람들은 다 알아요.
좋은 평판은 내부 구성원들이 알아서 홍보해줍니다. 문화를 개선해 직원들의 만족도를 높이면, 좋은 사람들은 저절로 모입니다.
지원자가 없어서 어쩔수 없다는 핑계로, 거짓말하면 당연히 안됩니다.
잡다한 일을 시킬꺼면, <기타 수명 업무 및 총무 담당 역할> 이라고 확실히 기재해주세요. ㅇㅇ 서비스 기획(30%) / IT 총무(70%) 라고 비중을 명확히 숫자로 표현하면 더 좋겠습니다. ‘기획 공장’이라면 상세히 설명해 주시구요. 어설프게 뭉뚱그려서, 부디 멋모르는 주니어 PM들이 커리어를 망치는 일이 없도록 하면 좋겠습니다.
그러다 벌 받아요.
주니어 PM 분들은
'어떤 사람이 되고 싶은지' , '어떤 커리어를 쌓고 싶은지' 고민하고 또 고민했으면 좋겠습니다.
항상 눈을 크게 뜨고 관찰하세요.
'직장'을 갖지 말고, '직업'을 갖도록 노력합시다.
건투를 빕니다.
