이런 책을 시작했어요 “외주개발 실패하지 않는 법”
UFOfactory에 3명의 영업, 기획을 담당하는 로초, 썸머, 운짱이
외주개발 실패하지 않는 법
책을 쓰기 시작했습니다.
기업, 서비스회사, 스타트업, 비영리, 정부 SI 프로젝트를 하면서 겪었던 경험들과 진심으로 고객이 실패하지 않았으면 하는 바램이 있었어요. 회사 초기부터 지금까지 UFOfactory 내부의 PM, 기획, 디자인, 개발 영역을 막라하고, 프로젝트를 하면서 고객들에게 이런 노하우들을 자주 얘기드리고, 불필요하게 예산을 낭비하시지 말라고도 얘기 드렸죠.
자주, 빈번히 일어나는 실수들에 대해서 녹음해 놓고 얘기드리고 싶었습니다. 그리고 그런 노하우에 대해서는 잘 전달되고, 실패하지 않길 바라는 마음으로 시작했습니다.
물론, 저희와 함께했던 고객이나 프로젝트들도 모두 성공하지 않았으며, 우리 손을 떠나거나, 시작도 못한 경우도 많습니다. 그래도 제대로된 IT 서비스나 제대로 코딩된 서비스를 만들고, 이런 프로젝트를 해 왔던 부분에는 자신이 있습니다.
페이스북 메세지나 fortytwo@ufofactory.org 로 처음 나오면 이 책을 꼭 보고 싶다고 하시는 분들은 출판시에 어떻게 구매하실 수 있는지 안내해 드리도록 하겠습니다. :-)
아래는 책 내용중에 짧은 영역 3 부분을 발췌해서 붙여 놓았습니다. 흐름상 이어지지 않고 책의 3쪽을 잘라서 붙여놓았으니 참고해서 읽으세요.
“내부개발이냐 외주 개발이냐” From 로초
가장 좋은 방법은 내부에서 직접 개발하는 것이다. 회사에서는 구현하고 싶은 의도를 바로 바로 전달할 수 있으니 좋고, 개발자들도 안정된 직장에서 책임의식을 가지고 그 일에 집중할 수 있기 때문이다. 그런데 내부에 개발팀을 두는 것은 그렇게 쉽지 않다. 가장 먼저 비용 문제. 내부개발을 하려면 비용이 어느 정도나 들어갈까?
가장 먼저 웹서비스를 개발할 때 인력이 기능적으로 어떻게 구성되는지 살펴보자.
첫번째, 개발자가 있어야 한다. 개발자는 필수 인력이다.
두번째 디자이너가 있어야 한다. 물론 디자이너 없이 사이트를 만드는 경우도 있다. 우리나라는 이런 경우가 많지 않지만, 외국에서는 개발자가 기획부터 디자인까지 다 하는 경우도 적지 않다. 그러나 한국에서는 이런 웹사이트가 드물다. 한국 웹문화에서는 디자이너 역시 필수 인력으로 볼 수 있다.
세번째 기획자 혹은 PM이 있어야 한다. 사실 직종으로 보자면 가장 대체하기 쉬운 영역이 바로 기획자 영역이다. 개발과 디자인은 상당한 숙련이 필요하지만 기획은 좀 감이 있는 사람이라면 어찌어찌 할 수도 있다.
물론 기획 영역도 만만하게 볼 영역은 아니다. 간단한 사이트는 간단한 기획에 개발 디자이너가 소통만 잘되면 무리없이 결과물이 나올 수도 있다. 그런데 프로젝트 사이즈가 조금만 커져도 상황이 달라진다. 웹서비스 안에는 수많은 정책들이 들어가는데, 이 정책들을 개발자들에게 정하라고 넘기는 경우엔 대개 개발에 편한 방향으로 구현하기 때문에 실제로 구현한 이후 문제가 발생하는 경우가 부지기수다.
그래서 웹서비스에서 정책을 정리하는 것은 대단히 중요한 작업이고 보통 이런 작업을 기획자가 맡는다. 기획자가 사전에 이런 부분을 꼼꼼히 정리해 놓지 않으면 반드시 문제가 발생한다. 이런 이유로 프로젝트 사이즈가 약간만 커져도 기획자가 필요하다.
포털의 블로그나 워드프레스 같은 정해진 솔루션을 사용하는게 아니라면, 웹서비스는 통상 이렇게 3개의 직군이 함께 일을 해야 결과물이 나온다. 각각 한명씩 배치한다 해도 최소 3명이 필요하다. 물론 아주 드물게 3개 영역을 모두 하는 사람이 존재한다. 그런데 이런 사람들은 자기가 하고 싶은 서비스를 만들지 남의 회사에 들어가서 일을 할 이유가 없다. 즉 일반적인 회사에서 이런 사람을 구하는 건 거의 불가능에 가깝다. 그래서 결국 최소 3명이 필요하다. (그런데 요새는 또 경향이 바뀌었다. 웹서비스의 기능이 화려하고 다양해지다보니 개발자 기능이 서버 개발과 프론트(화면) 개발로 분화되었다. 얘기가 길어지니 이 부분은 생략하자.)
일단 최소로 잡아 3명이라 생각하고 비용을 산정해보자. 아.. 그런데 오픈 이후 일이 불명확하니 계약직으로 두고 싶다고? 그것도 불가능하지는 않다. 그런데 계약이 끝나고 난 후엔 당장 서비스 관리와 유지보수가 문제가 된다. 당분간은 계약직으로 개발한 사람에게 돈을 월 얼마씩 주고 운영할 수도 있지만, 만약 이 사람이 바빠지거나 돈이 얼마 안된다고 안하겠다고 하면 당장 서비스 운영에 공백이 생기기 시작한다.
자.. 그래서 일단 큰 맘먹고 개발팀을 정규직을 뽑는다고 생각해보고 비용 계산을 해보자. 대단한 기획자, 대단한 디자이너, 대단한 개발자들은 몸값이 비싸니 경력 3–4년차의 적당한 사람을 잘 꼬셔서 싸게 데려왔다고 치고, 프론트와 서버를 모두 개발하는 개발자를 싸게 구했다고 치면 대략 이렇게 될 것 같다.
기획자 연봉 3천만원
디자이너 연봉 3천만원
개발자 연봉 4천만원
일단 1년 연봉만 1억이다. 이건 단순 연봉이기 때문에 4대보험과 복리후생과 관리와 사무실 비용과 등등 기타 지출을 생각하면 연봉의 2배가 훌쩍 넘어간다. 최소로 잡아 2억은 넘는다. 즉 연 2억의 여유가 없는 회사라면 자체 개발팀을 꾸린다는 것은 대단한 모험을 하는 일이다. 게다가 이렇게 모인 3명이 호흡이 안 맞는 경우엔 문제가 심각해진다. 팀웍, 실력, 경험, 위기 대응 등 돈을 들여 개발팀을 구성할 수 있어도 해당 프로젝트를 성공적으로 수행할만한 팀웍을 갖춘 개발팀을 구축하기란 그렇게 만만한 일이 아니다. 또한 성공적으로 서비스를 오픈했다 해도 지속적으로 웹서비스를 확장할 계획이 없다면 이 3명의 역할이 애매모호해질 수 있다. 회사 입장에서는 고민스러운 상황이 발생하기도 한다. 개발팀을 내보내자니 서비스 유지가 문제가 되고 개발팀을 유지하자니 들어가는 비용이 만만치 않다.
이럴 때 선택할 수 있는 다른 방법이 외주개발이다. 좀 틀 잡힌 외주개발 회사들은 자체에 기획-디자인-개발 라인업을 갖추고 나름 팀웍을 가지고 있기 때문에, 내부 개발팀을 유지하는 비용보다 훨씬 싸게 (그리고 좋은 팀을 만난다면) 훨씬 안정적이고 빠르게 서비스를 개발할 수 있다.
그렇다고 외주개발이 만만할까? 그게 만만한 일이었으면 이 책은 씌여지지 않아도 되는 책일 것이다.
“원하는 것을 정확히 모를 경우” From 운짱
대부분의 클라이언트는 본인들이 무엇을 원하는지 정확히 알지 못한다.
스스로 정확한 이유는 모르지만 마음에는 들지 않으니 컨펌을 못하는 경우가 허다하다. 그래서 보통은 수행사가 2~3개 정도 컨셉을 가져간 다음 클라이언트가 결정을 할 수 있도록 돕는다.
고객은 컨셉들을 비교해 보며 섞거나, 그 중 한 두 가지를 결정해 더 좋게 개선해달라고 요청한다. 더 좋은 안으로 만들기 위해 무리한 수정 요청을 계속하게 될 경우, 가능하면 기획자, 디자이너, 개발자를 미팅에 참석시켜 정확한 이유를 찾아내는게 좋다. 시간도 줄이고, 더 좋은 방안을 찾을 수 있다.
기업이나, 관공서, 비영리 법인에서는 이런 부분이 어렵기 때문에 용역발주, 경쟁PT, 기업확인 등을 통해 “내가 원하는 것도 찾아내라 ~” 라는 내용을 포함한다. 외주 용역사는 마치 모든 것을 다 아는 것처럼 찾아내고, 제안하고, 조정해서 일을 해 나간다. 원하는 것을 찾아가는게 외주 개발사의 몫이지만, 결국 주요한 프로세스와 정책을 세우고, 문제를 제대로 알고 파악하고 있는 것은 다름 아닌 담당자와 발주 책임 회사이다.
원하는 것을 자꾸 물어보고, 확인하고 점검하자 !
더 충격적일 때는 스타트업이 이런 것을 모르고 있을 때… 좀 충격적이긴 하다. 물론 이 모든 것을 서로 배우고, 빠르게 학습하고 해야 하지만 비지니스 모델과 정책을 제대로 갖고 시작하는게 스타트업, 새로 시작하는 조직이므로 돈으로 해결하기 보다는 비지니스 모델과 정책을 스스로 정확하게 이해하고 본인들이 원하는 것을 정확하게 알고, 현실적으로 판단해야 한다.
“개발사를 잘못 만나는 경우” From 썸머
투입인력계획서를 거짓으로 작성하는 개발사
투입인력 계획서를 거짓으로 쓰는 경우가 있다. 파견 근무를 안한다는 조건으로 계약했을 경우 PM과 각파트별 PL들은 미팅을 통해 투입 되었다는 것을 확인할 수 있으나, 실제 프로젝트를 수행하고 있는 실 투입 인력이 어느정도인지 발주사는 알기 어려워 투입인력 계획을 수행사가 임의로 조정해서 개발하는 경우가 종종있다.
또한 파견 근무 조건으로 계약을 하더라도 거리가 멀다고, 또는 개발 기간이 늘어진다는 등 프로젝트 도중 파견근무를 하지 않고 따로 사무실을 얻거나 수행사 내부에서 처리하는 경우도 있는데 이 경우에도 초기에 100% 들어갔다면 이후 70% ~ 50%로 인력 감축을 하거나 다른 프로젝트를 동시에 진행하는 경우가 있다.
이런 식으로 프로젝트 실투입인력이 줄어들다보면 프로젝트 기간이나 퀄리티에 문제가 생기는 경우가 있는데 이때 발주사는 수행사에 투입인력을 확인 요청할 수 있다. 이를 통해 발주사는 수행사가 제출한 투입인력계획서를 기준으로 투입 적격을 확인하는게 좋다.
만약, 거짓으로 투입인력계획서를 작성한 수행사는 이로인해 문제가 발생할 수 있음으로 투입인력 계획서를 거짓으로 작성하거나 프로젝트 도중 인력을 감축시키는 행위를 임의로 결정하지 않아야 한다.
수행사는 프로젝트 도중 투입인력이 변경 되거나, 혹은 이슈가 있을 시에는 ‘이슈보고서’ 등을 통해 변경 내용을 발주사에 보고 또는 협의를 하면 된다.
글 모음 _ 운짱
