#10. 외주가 해결책이 될 수 없다.
외주 개발을 선호하는 기업은 100% 실패한다.
오늘은 프로젝트를 관리하는 입장에서 '외주에 얽힌 이야기'를 해볼까 한다.
"당신은 기획자인데 왜 기획서에 대한 내용은 세세하게 다루지 않죠?"라고 묻고 싶거나 궁금해할 수도 있을 것이지만 그 이유는 간단하다. 그러고 싶지 않기 때문이다.
기획서나 기획을 하는 문서 능력에 대해 프로그램 툴이나 어떤 방식을 설명하기 시작하면 이 브런치는 일종의 전문서적같은 느낌으로 쭈욱 가야 할 것 같다.
또한 대부분 기획서, OO분야 현직 기획자가 말해주는~ 같은 제목의 블로그를 보아도 매번 비슷한 것을 알 수 있다. 대개 알고 싶어하는 내용은 건너뛰거나 기본적인 내용만 쭈욱 나열 된. 사실 해당 키워드를 검색해서 블로그에 들어갔다는 건 실제, 현장에서 통용되는 기획서의 양식, 틀, 내용을 보고 싶어하는 것인데 제목은 그렇게 써두지만 정작 알맹이는 없다. 대외비라는 이름으로. 그렇게 작성할까봐 아예 양식, 틀, 내용의 이야기는 피하는 것이다.
외주? 내 사전에 외주란 없다.
외주 개발사 근무나 프리랜서를 하시는 분들이 보면 왠지 욕을 할 것 같다. 하지만 정말로 '내 사전에, 내 팀에 외주는 없다.' 물론 외주개발사나 그 분들의 실력이 낮거나 그런 이유는 절대 아니다. 감히 내가 누구의 능력을, 실력을 평가 할 주제도 안되지만 그 분들의 실력만 놓고 본다면 절대 낮은 수준이 아니다.
그럼에도 내가 외주를 기피하는 이유는 분명하다. 외주를 의뢰해 좋은 결과를 맞이한 적이 거의 없기 때문이다. 외주 결과물이 안좋아서 그런 경우도 있지만 대부분은 외주의 문제가 아닌 의뢰한 회사의 문제가 많기 때문이었다. 그래서 난 프로젝트의 외주화를 선호하지 않으며 CEO들의 외주 추진에도 반대표를 던지곤 한다.
외주를 맡긴 프로젝트가 외주사에서 온전하게 끝이 나면 다행이지만 대개 중소 개발사들의 경우 그런 사례는 거의 없고 그것을 자체 개발팀이 이양하거나 개입하는 일들이 벌어지곤 한다.
그리고 그 순간에는 어김없이 양 회사의 개발인력간 기 싸움이 생기고 잡음이 생기기도 한다.
외주도 외주만의 문제가 분명 있지만 대부분 외주를 맡긴 프로젝트의 실패는 "의뢰한 회사의 탓"이 가장 크다고 생각한다. 그럼 왜 그런지 이유를 설명해보겠다.
대부분 무언가를 개발하고 출시하겠다고 하는 소위 스타트업, 벤처회사들 중에 유독 개발 출신의 인력 1~2명을 데리고 일을 진행하는 경우가 있다. 그리고 그 개발인력은 대부분 외주 관리에 집중한다.
하나~열까지 모두 외주를 맡기다 보니 일일히 챙기고 협의하고 자료를 만들어주는 것도 일이고 추후 일정이 바뀌거나 정책이 변경되기라도 하면 서서히 골치 아파지는 경우가 많다.
또한 외주 기간이 길어질수록 비용도 증가하고 이젠 외주가 외주가 아닌 '주'가 되는 상황이 연출되기도 한다.
외주사의 경우에도 어느 정도 단기적으로 처리해주고 끝내는 의뢰를 선호할 것이다. 중장기적으로 가야 하는 경우 외주사로서도 리스크가 크기 때문이다.
그럼 왜 일부 CEO들은 외주를 맡기는 것일까.
이유는 간단하다. 첫째 일 떠넘기기이고 둘째 외주는 짧은 시간 내에 결과물을 가져올 수 있다라고 믿기 때문이며 셋째 개발인력을 건트롤 할 능력이 없고 넷째 하고 싶은 일들은 많기 때문이다.
자체 인력으로 개발을 하려면 물리적인 시간은 필수적이다. A를 만들고 B를 만들고 C를 만들어야 한다.
따라서 기획이 선행되고 이에 따라 디자인과 개발이 병행적으로 이루어진다. 만들다 보면 예기치 못한 문제도 생기는 등 여러가지 문제들이 발생한다. 또한 만약 A와 B를 동시에 개발하고자 한다면 그만큼 인력을 충원해야 하고 그에 따른 부대비용도 증가된다. 그래서 외주를 맡기는 것이다.
그런데 문제는 "구체적인 계획과 실행 방법을 모르는데" 있다. 구체적인 계획을 마련할 시간도, 여력도 없어 외주를 택한 것인데 정작 기획을 떠안는 경우이다. 개발 시간이 짧다보니 당연히 외주사는 "기획서"를 요구한다.
CEO들은 대략적인 사업 개요를 작성해 넘기고 이를 토대로 '무작정 시작'이 진행된다. 즉, 기획과 개발이 분리되는 것인데 물론 이렇다고 모두 실패를 하는 건 아니지만 대개는 실패를 한다. 제대로 된 구상이 없는 기획서는 그 한계가 있다. 따라서 외주사는 "기획서가 없어서,","기획서대로"라는 쉴드가 생기는 것이고 의뢰사는 난감해지는 것이다. 그리고 이때쯤 돼서야 많은 CEO들이 결정하는 방안이 기획자 채용이다.
일은 만들었는데 수습이 안되고 자신도 방법을 모르니 기획자를 채용해 이를 해결하려고 한다. 그런데 여기서 발생되는 또 하나의 문제는 기획자에게 주어지는 시간이 많지 않다는 것이다.
면접 때 이에 대한 이야기가 진행되기도 하지만 면접에서 듣는 것과 실제 입사 후에 맞이하는 현실은 차이가 있다. 기획자가 짧은 시간 내에 그것을 파악하고 분석해서 기획서라는 결과물을 산출하려면 기획자의 경험이 풍부해야 하는 점도 있지만 회사의 자료가 절대적으로 필요하다.
그리고 그것이 있다고 해도 읽고 이해하는데 들어가는 물리적 시간도 절대적이다.
내용을 파악하고 이해하고 일을 시작해야 하는데 이미 오랜 시간 허송세월을 했기 때문에 기획자가 충분히 검토하고 대안을 마련할 시간은 주지 못한다. 책임과 의무를 강요한다. 따라서 대개 기획자들이 여기에서 퇴사를 결정할 수 밖에 없게 된다. 그나마 부족한 내용의 자료마저 제대로 정리되어 있지 않고 이야기도 하지 않는다.
아마 대부분의 기획자, 그리고 PM분들이 들어보셨을 것이다.
"외주사랑 이야기해서 처리해."
"그게 뭐가 문제야? 협업하는 사람들끼리 의논해서 처리하라는 건데"라고 생각한다면 잘못 된 생각이다.
외주사에 배경과 그 동안의 진행 사항을 물어보면 외주사는 자신들의 입장에서만 이야기를 한다. 구구절절 맞는 이야기이고 그렇게 되면 이제 기획자가 처리해야 할 문제만 산더미인 것이다. 이런 경우를 "X치운다."라고 하는데 대개 이런 경우로 프로젝트 후반에 무너지는 경우가 허다하다. 그리고 대부분의 CEO들이 외주와 직원들의 무능으로 이를 포장한다.
이런 바보같은 사태가 왜 중소 개발사에는 만연할까?
그런 CEO들은 다른 아이템으로 회사를 창업해도 똑같은 실수를 반복하는 경우가 많은데 왜 그럼 자꾸 이런 일들이 반복되는 것일까. 가장 큰 원인은 경영진의 "공언, 공약"에 있다.
자금력이 미흡한 중소 개발사는 자금을 투자받거나 지원받기 위해 약간의 과장, 거짓말을 한다. 예를 들어 투자자와 미팅을 하면서도 투자자가 원하는 기능이나 요소에 대해 "아~ 그건 6개월이면 개발 끝납니다.", "저희도 그런 의견이 있었어서 준비 중에 있었기 때문에 금방 만들 수 있습니다."라고 약속을 해버리는 경우가 많다.
또한 그런 이야기가 없더라도 투자자들은 "언제쯤 그럼 결과물을 볼 수 있지?"라고 묻는 경우가 많은데 이때 대부분의 CEO들이 개발진과 상의없이 일정을 정해버린다. 물론 투자를 받기 위한 답변이었다는 건 이해할 수 있지만 상식 이하의 일정을 결정해버리는데 있다. 이런 경우는 국내에서 주로 많이 볼 수 있는데 그것은 "기다릴 줄 모르는 한국의 정서와 밀접하다."라고 보는 게 나의 견해이다.
약속을 했으니 일단 그것이 이루어지고 있음을 증명해야 한다. 서둘러 작업에 착수하는데 빨리 보여줘야 하기 때문에 외주를 선택한다. 문제는 자신도 그에 대한 완벽한 계획이 없기 때문에 외주사에 제대로 된 내용을 전달하기 어렵다. 외주는 선금을 받았거나 받기 위해 일단 시작을 한다. 그리고 "자료주세요.","어떻게 하면 되죠?"라며 압박을 준다. 이 빌미는 물론 의뢰사가 준 것이다.
외주를 맡길거면 아예 통으로 맡기면 되는데 책임도 지지 못하면서 일단 기획을 해서 준다고 말을 하고 기획자를 채용해 화두만 던져주고 일을 처리하려고 한다. 아무리 뛰어난 경력의 기획자라도 자신이 구상하지 않았거나 화두만 들은 내용에 대해 100% 투자자와 회사가 만족할만한 구상안을 마련할 수는 없다.
이런 배경들이 반복되면서 물론 소소하게 적은 비중으로 서로 윈-윈하는 경우도 있지만 대개는 실패한다.
무엇때문에? "제대로 된 계획의 부재"과 "외주는 다 가능하다."라는 막연한 신념 때문에.
실제로 회사에 입사를 하다 보면 자주 직면하게 되는 경우가 있다.
"외주사랑 이야기해서 처리하면 됩니다."라는 말에 외주사를 만나 이야기를 하다보면 전혀 조금도 개발에 대한 정보나 자료가 전달되지 않은 경우가 허다하다. 외주사들은 "관련 내용 정리해서 주신다고 했는데 온 게 없어요."라고 답변을 한다. 그래도 상대적으로 시간이 많다면 해결할 수 있는 방법은 있으니 그나마 다행이지만 개발 끝무렵에 입사를 하게 되는 경우는 문제가 많다.
아무리 경력과 경험이 많은 기획자, PM이라도 이런 경우 해결책이 뚜렷히 나오긴 어렵다.
첫번째는 외주와 초기부터 어떤 대화와 이야기가 됐는지를 모르고 이제와 그것을 모두 되짚어본다는 건 사실 말이 안되는 일이다. 외주 입장에서야 다시 처음부터 시작할 수도 있으니 수익적인 면에서 기쁠 수도 있지만 말이다. 둘째로 그 시간까지 지나오는 동안에 대한 내용을 정리한 자료는 1도 없고 이를 간단하게 설명할 수 있는 인원도 없다는데 있다. 따라서 대부분 돌아오는 말은 "지난 날 떠들어봐야 의미없고 해결해줘."이다.
해결은 억지를 부린다고 되는 게 아니다. 잘못 된 점을 빨리 파악하고 개선하는데 있다.이런 걸 해결해야 진짜 능력이지? 그걸 '억지'라고 부른다. 해결은 억지가 아님을 알아야 한다
대개 이런 경우 기획자나 PM은 결단을 내려야 한다. 이 침몰해가는 배에서 내릴 것인지, 아니면 어떻게든 수선해서 항해를 이어갈 지에 대해 말이다. 물론 전자는 퇴사를 말하는 것이고 후자는 해결을 의미한다.
어떤 선택을 해도 그것을 능력과 결부시킬 수는 없다. 퇴사 역시 해결책 중 하나이기 때문이다.
목적지까지 많이 남았는데 트럭이 운행 도중 멈췄다고 생각해보자. ( 전화해서 AS를 부르지 같은 건 빼고 )
막연하게 도움을 기다리는 건 누가봐도 손해적인 일이다. 이때 운전수(대표)는 "야. 일단 밀어봐. 좀 가다 보면 뭐라도 나오지 않겠냐."라고 결정을 해버릴 수 있다.
만약 목적지까지 아무 것도 없는 지역이라면 직원들은 무거운 트럭을 계속 낑낑거리며 밀고 나아가야 한다.
이것을 보고 해결이라 말하는 MCN은 없을 것이다. 이걸 억지라고 부른다.
이때 올바른 생각은 "수리를 해서 빨리 이동하자"에 있다. 어차피 밀고 가는 것도 시간이 오래 소요된다. 시간도 오래 소요되지만 직원들이 느끼는 피로도는 배가 된다. 가다가 멈출 확률이 매우 높은 하책인 것이다.
반면 그 자리에서 수리를 하는 것도 물론 시간이 오래 소요되지만 수리가 완료되면 더 빨리 나아갈 수 있다.
이 두가지 방법은 분명한 차이를 보여주고 있다. 억지를 부리는 것은 고장의 원인이 자신의 탓이 아니라고 말하고 싶은 것이다. 관리가 미흡했고 제대로 관심을 갖지 않았다는 소흘함을 인정하지 않고 싶은 것이다.
수리를 한다는 것은 굉장한 결단이 필요하다. 자칫 수리가 안될 수도 있다는 전제를 포함하고 있기 때문이다.
이는 관리 부실을 인정하고 해결책을 강구하는 자세라고 볼 수 있다.
억지로 밀고 가다가 넘어져 모두 쓰러지는 것과 수리를 해서 가능할 경우 나갈 수 있다는 희망이 있다는 것.
무너지면 끝인 것과 한번의 기회를 더 가질 수 있다는 것. 이 차이는 분명하게 다르다.
희망이 있는 것과 희망이 없는 것은 매우 다르고 사람에게 주는 열정과 자세도 달라지게 한다.
그러나 대부분의 CEO들은 "안돼. 어떻게든 가야 돼."라고 주장을 한다. 이미 자신을 날린 지난 날은 잊고 지금부터 너희들이 해결해야 하는 것만 생각하는 것이다. 전형적인 무책임의 표본이다.
외주는 잘 활용하면 매우 좋은 파트너지만 막연하게 활용하면 자체 개발보다 더 힘든 상황을 만드는 계기가 될 수 있다. 간단한 프로젝트라면 크게 상관없지만 그것이 아니라면, 그리고 회사의 주력 아이템이라면 자체적으로 개발인력을 두고 만드는 것이 가장 좋다. 외주는 만능 치트키가 아님을 알아야 한다.
