기획자는 사원, 개발자는 차장, 발의자는 대표?
초급 기획자, 무시당하고 부딪히며 성장하는 법
그 날의 퇴근길은 너무나 무거웠다. 허한 마음에 회사 옆의 쇼핑몰을 휘휘 돌다가 거울을 비친 내 모습을 본 순간 울컥하며 눈물을 왈칵 쏟아냈다.
종합 쇼핑몰 신규 구축 프로젝트의 끝무렵, 테스트 기간이었고 나는 초급 기획자로 테스트에 투입되어 기획 요소대로 제대로 되고 있는지 점검하는 업무를 진행 중이었다.
야, 아가씨가 너 찾아왔다~
결함내용을 설명하러 찾아간 개발자들에게 나를 지칭하는 단어는 바로 '아가씨'.
설명하는 동안 제대로 듣지도 않던 담당 개발자는 기획과 내용에 차이가 있다는데도 결함사항에 대해 수긍하지 않으려 했다. 결함 등록 건에도 처리하지 않겠다며 별다른 이유도 달지 않고 없이 ‘기각’을 해 버리는 상황.
그렇게 한참을 실랑이했으나 해결이 안 되었는데 내 위에 남자 대리가 가서 한마디 하니까 바로 태도 전환하고 수정을 시작하는 개발자. 그 뒤로도 몇 번의 비슷한 사건을 겪으며 '무시' 당하고 있다는 것을 뼈저리 게 실감했었다.
항상 함께 지내는 상주 개발자의 경우, 팀워크를 가지고 함께 동지애를 느끼는 분들도 많다. 하지만 가끔 구축을 위해 많은 수의 프리랜서를 기용하여 외주 개발사가 참여할 경우, 갑작스럽게 여럿이 동원되기 때문에 협업하기에 좋지 않은 사람을 만날 수도 있다. 나는 그때 운이 없었고 그 프로젝트도 상당히 운이 없는 상태였다.
성격이 나쁜 동료보다 비즈니스에 대해 잘 알지도 못하고 경험 부족으로 대안조차 제시 못하는 ‘어린 기획자’로 사는 건 꽤나 피곤하고 억울한 일이었다. 그때의 일들은 마음속에 두고두고 상처로 남았다. 반면에 내 가 연차가 쌓이면 절대 무시당하지 않겠다고 다짐했던 날이었다.
그런데 얼마 전 완전 아기 같은 우리 신입에게 비슷한 일이 있었다. 눈물이 그렁그렁해서 돌아온 우리 신입.
일 그런 식으로 하는 거 아니라며 혼났어요
자초지종을 들어보니 어이가 없었다. 신입은 개발 테스트 관련하여 필요한 데이터가 없어 개발 PM과 상의를 하기 위해 메일을 보냈단다. 그리고 이에 대해 개발 PM에게 이야기를 들은 띠동갑도 더 되는 실무 개발자가 우리 신입을 옥상으로 불러냈던 거였다. 담배 한대를 입에 물고 그 요청 메일에서 제외돼서 기분이 몹시 나빴다며 일을 그렇게 하면 안 된다고 혼을 냈단다.
신입은 쩔쩔매며 죄송하다고 기분 푸시라고 돌아왔지만 신입 기획자의 눈에서 눈물이 터져 나왔다. 펑펑 우는 신입에게서 펑펑 울던 예전의 내 모습이 보였다. 이미 꽤나 시간이 지난 것 같았는데 역시나 신입 기획자에게는 협업 조차도 쉬운 일은 아니었다.
처음부터 베테랑을 상대해야 하는 신입 기획자
이런 예시만 들다 보니 개인 성향과 예의의 문제처럼 보이지만, 사실 이런 상황은 생각보다 흔하다. 이 경험을 이야기해보면 많은 사람들이 비슷한 경험을 털어놓는다. 구조적인 면에서 기획자 누구나 처할 수 있는 환경적 요인이 이미 형성되어 있기 때문이다.
기획자는 신입도 프로젝트에 투입된다. 아무리 서브 기획자로 참여해도 정책을 이야기해야 하고 기획안을 설명할 줄 알아야 한다. 기획자라는 직무는 크든 작든 자신의 프로젝트에서는 방향성과 정책에 대해서 정리할 수 있어야 하기에 신입이라면 자신의 낮은 맨파워는 이런 에피소드 하나쯤 생겨나는 게 이상하지 않다.
에피소드가 발생하는 시점은 여러 가지가 있겠지만, 그중에서도 가장 큰 문제는 기획자의 연차와 업무 협업자의 연차는 전혀 비례하지 않는다는 점에 있다. 서비스가 고도화될수록 기획은 세분화되지만 개발 소스는 걷잡을 수 없이 복잡해진다. 초급 기획자는 아무리 신입이라도 선배의 도움을 받아 정책적인 이해와 고객의 시선이라는 무기로 기획 업무를 시작할 수 있지만, 개발자는 일단 연차가 좀 있고 경험이 많은 분이 복잡도를 견뎌낼 수 있다. 조직의 크기가 커질수록 기획의 요청을 처음 듣고 판단하는 존재는 말단이 아니라 개발 PM이 된다.
즉, 간단히 배너 하나를 붙인다고 해도 신입 기획자의 협업 대상자는 대부분 기획자보다 직급과 경험이 많은 사람일 경우가 많다.
업무 요청자도 마찬가지다. 기존 정책을 뒤흔드는 무리한 요구사항은 기획자가 판단해서 수용범위를 협의할 수 있어야 하는데, 기획자의 지식은 부족하고 요청자의 직급은 훨씬 높을 때에도 문제는 발생된다. 보통 현업 부서의 시스템 개선을 판단할 수 있는 대리 이상이 요청을 하고, 심하게는 임원이 소소하게 그러나 압박적으로 발의하게 되는 경우도 많다.
이럴 경우 기획자는 협의하는 한마디 한마디가 너무 어렵다. 온갖 도움을 받아 메일을 써도 도대체 얼마나 더 납작 엎드려서 써야 예의에 어긋나지 않을까 고민하게 된다. 어떤 신입은 존칭에 존칭을 더하다 보니 거의 임금님 상소문처럼 된 메일을 쓰는 것도 종종 봤다.
(ex. ~~ 해주시길 부탁드리며 ~해주시면 감사드리고 ~참고해주시길 부탁드립니다)
그렇다 보니 몇 개월만 지나도 이런 탄식이 나온다.
기획자는 왜 죄다 아쉬운 소리만 하고 다녀야 해요?
그러나 다행스럽게도 이런 상황은 연차가 쌓일수록 개선된다. 단순히 연차가 쌓였기 때문이 아니다. 소위 ‘커뮤니케이션 능력’이라고 하는 기획자의 역할을 어렵사리 해내는 동안 서비스에 대한 정책적 지식이 늘어나고 협업 대상자들로부터 신뢰를 받을 수 있게 되었기 때문이다. 그때서야 동료로 인정받는다고 해야 할까.
나의 과거를 포함해서 수많은 신입 기획자들은 처음 신뢰를 받기까지 과정에서 가장 큰 어려움을 겪고, 이 직무에 질리는 사람들도 있다. 이 끔찍한 시기를 빠르게 지나가는 방법은 단 하나다. 기획자가 결정과 판단을 내릴 수 있을 만큼 정책을 익히고 직무적인 신뢰를 받기 시작해야 한다. 그러다 보면 아쉬운 소리 대신에 어느새 리더십을 발휘하는 자신을 발견할 수 있다.
그렇다면 신입 기획자가 협업에서 성장하려면 어떻게 해야 할까?
똑똑하게 지고(loose), 겸손하게 성장하자.
커뮤니케이션 대상이 신입에게 우호적이지 않다면 가장 확실한 방법은 역시나 시간이다. 시간이 지나면 자연히 시간 대비해서 얼마나 잘하는지 계속 같이 하면서 기획자로서의 역할은 잘 해내는지 협업 대상자들도 판단하게 된다. 그리고 그 기획자 밑에 또 신입이 생기고 하는 과정을 통해 업무 상대로 자연히 인정받게 된다.
다시 말하지만, 이 모든 문제는 '신뢰의 결여'의 문제다. 반대로 말하면 기획자에게는 '신뢰받는 것'이 가장 중요한 역량인 것이기도 하다.
하지만 이런 말로는 당장 속상하고 억울해서 복잡해진 신입 기획자에게 도움이 되진 않을 거다.
내가 지금까지 봐온 기획자들은 이 ‘신뢰의 게임’에서 여러 가지 방법으로 대응해서 그 문제를 빠져나갔다.
이 대응이란 관계 회복에 대한 것이 아니다. 핵심 목표는 기획자로서 무시받는 상황에서 효과적으로 기획의도를 관철시키고 이해시키는 것에 있다.
유형 1. 팀장(상사) 이용하기
유형 1의 기획자들은 자신의 요청이나 기획에 대해 일방적인 공격이나 불만에 부딪힐 때 자신이 의사결정자가 아님을 강조한다.
개발자 : 이 기획은 말도 안 되어요. 시스템 기존 정책을 알아보긴 한 거예요?
기획자 : 저는 아직 온 지 얼마 안 되어서 사실 모르는 부분이 많아서요.
팀장님(또는 상사)께 확인해보고 다시 말씀드려도 될까요?^^
제가 잘 몰라서 그러는데 혹시 이유를 설명해주시면, 팀장님께 보고드릴 때 말씀드릴게요.
이럴 경우 요청과 비난의 대상에서 벗어날 수 있고, 또 이미 형성된 팀장님 또는 상사의 신뢰도에 기대서 무시의 대상이 될 수 있는 부분에서 벗어날 수 있다. 게다가 보고를 핑계로 현재 개발자나 협업자가 가진 지식에 한걸음 다가갈 수도 있다. 찬찬히 의견을 듣고 나서 기획을 수정하고 수정 방안을 내 상사에게 보고 드리면 협업자와 우리 팀 간의 의견차도 좁힐 수 있다.
유형 2. 과외 선생님 모시기
나보다 잘 아는 사람은 다 선생님이란 마음으로 아예 처음부터 도움을 구할 수도 있다. 잘 모르는 상태에서 기획부터 해가면 당연히 '잘 모르는 소리'만 하기 쉽다. 잘 모를수록 먼저 물어보고 기획에 참고하면 마지막에 한방에 욕먹는 걸 피할 수 있다.
유형 2 기획자 : 잠깐 시간 괜찮으세요? 제가 쿠폰에 대한 기획을 하게 됐는데요.
잘 모르는 부분이 있는데 이 부분은 차장님이 제일 잘 아신다고 해서요.
몇 가지만 여쭤봐도 될까요?
이렇게 먼저 신뢰를 보이며 지식을 물어본다면 무시받기보다는 설명을 받는다. 같이 고민해주며 기획한 기획이 되면 훼방이나 무시보다는 같이 더 방법을 찾아주도록 노력하게 되어있다.
그러나 질문 수준은 덮어놓고 다 물어봐서는 안 된다. 기본적인 건 조사하되 그게 맞는지를 물어봐야 한다. 바쁜 시간을 내어준 상대방에 대한 respect다.
유형 2 기획자 : 제가 알아본 바로는 이러이러하다고 들었는데, 제가 이해하고 있는 게 맞나요?
특히 설명이 내가 알고 있는 것과 다를 때는 아는 것이 다르다며 따지지 말고 이런 식으로 돌아서 물어보면 갈등을 피하고 정확한 지식을 얻을 수 있다. 시스템 정책은 관리 안된 정책서보다 개발자가 까서 직접 보고 있는 소스 속에 가장 정확한 경우가 많다.
유형 3. 호형호제 하기
협업자들과 사적 관계를 돈독히 하여 친해지는 방법이다. 점심이나 차를 마시거나 과자 같은 것들을 전달하면서 친해지고 대화시간을 늘린다. 그러다 보면 자연스럽게 자신이 해야 하는 기획내용이나 상황 등을 이해시킬 수 있다.
반대로 기획자가 전혀 알지 못했던 실제 현업이나 개발의 관점에서 기획 요건의 잘못된 점을 스스로 깨닫는 기회를 주기도 한다. 결국은 회사에서 업무는 사람이 하기 때문에 사람들 간의 업무관계나 상황은 다 있기 마련이다.
상황적인 이해를 통한 프로젝트 진행의 컨센서스가 이루어지면 각자의 입장에 따라 주장하면서도 서로 입장을 이해하는 상황에서 시작할 수 있다. 바보 같은 신입으로 보일 것이 아니라, 동료로서 보일 수 있는 기회가 되기도 한다.
이 세 가지 유형의 공통점이자 시작점은 '모르는 것을 인정하고 배우려는 태도'다. 기획자라고 해서 상대방을 이기려고만 하면 부러지기도 쉽다. 상대방이 이상한 사람이라고 해도 어쨌거나 더 잘 알고 설득하면 적어도 업무는 대등하게 협의를 통해 좁혀질 수 있다. 그러다 보면 신뢰받는 기회자가 되는 날도 온다.
우리 신입의 눈물이 멈추고 난 뒤 나는 내 선배가 그랬듯이 그분을 찾아가 대신 이야기해주었다. 의미심장하게 활짝 웃으면서 '우리 애한테 잘해주세요:)' 라며 그 개발자를 찾아가서 웃고, 담당 PM에게 주의 깊게 챙겨주기를 항의했다.
하지만 그전에 회의실 하나에게 후배에게 그럴 때는 속으로 'ㅅㅂ!!!'을 외쳐보라고 말해줬다. 기분 나쁠 때는 울고불고 자신만 책망한다고 상황은 별로 달라지지 않는다. 한번 울었으면 속으로 크게 'ㅅㅂ!!!'하며 풀어내고 정책과 비즈니스를 씹어먹자. 상대방이 절대 무시할 수 없는 실력자가 될 수 있다면 상황은 언제든지 바뀌게 될 테니까.
