IT 벤처를 시작하거나, 시작하기를 원하는 팀의 분류방식은 여러 가지가 있을 수 있다. 그 중 개발자의 유무로 판단 하는 것은 아이템이나, 학력이나, 기획자의 능력으로 구분하는 것보다 그 팀이 갈 방향을 더 명확하게 판단하는 방법이다. 친한 한 벤처 투자가는 'IT벤처의 역량의 80%는 개발 능력에서 나온다'라고 주저하지 않고 말했다. 아마 많은 벤처인들이 이 말에 공감할 것이라 생각한다.
그러나 뛰어난 개발자로 이루어진 팀도 지속하여 흙만 파먹을 수는 없기에, 수익을 창출하기 위한 여러 시도를 하게 된다. 이러한 와중에 많은 팀이 정부 지원을 받으려고 시도하거나 개발 외주를 함으로써 단기간의 유동자금을 끌어 모으려고 시도 한다. 그러나 많은 개발자들이 여기서 일단 막히게 된다. 외주는 어떻게 구하고, 그 가격은 어떻게 산정해야 할까? 또 좋은 외주는 어떤 것일까? 이런 분들을 위하여 필자의 경험을 바탕으로 간단한 팁을 적어보고자 한다.
(1) 되도록 과거 직장의 외주 사업을 하여야 한다. 만약 그것이 힘들다면, 안면이 있는 회사의 외주를 하여야 한다.
- 만약 외주를 하기로 마음먹었다면, 과거 직장부터 체크하는 것이 좋다. 이 점이 학생출신보다 직장 3-5년 재직 후 벤처에 뛰어든 사람의 강점 중 하나이다. 과거 직장의 외주를 시도해야 하는 이유 중 가장 큰 이유는 무엇보다 ' 절감' 이다. 외주도 영업이다. 안면이 없는 회사에 새 일감을 얻는 것은 매우 힘들다. 좋은 외주팀일 경우에도 외주 계약건을 외주 미팅한 회사의 개수로 나누어 보면 3할이 채 안될 것이다. 그러나 과거 직장의 외주를 구하는 경우에는 이 확률을 70-80%까지 가져갈 수 있다.
- 외주를 시작하면 해당 회사와의 커뮤니케이션에도 시간이 들어간다. 업무의 이해부터 이 솔루션을 사용할 사용자가 누구인지, 어디에 들어가는지를 알면 상당한 개발 코스트를 줄이면서도 더 높은 퀄리티의 제품을 생산해 낼 수 있다. 외주 발주한 직원이 과거 자신의 상사나 후배였다면 커뮤니케이션이 더 수월할 것이고, 이는 개발 기간의 단축으로 이어진다.
(2) IT 회사의 외주발주가 최우선순위다. 대기업 IT팀에서 발주한 외주가 두 번째 우선순위다. IT와 관련 없는 회사의 외주는 삼가야 한다.
- 만약 능력 있는 팀이 이제 외주를 할 것이라고 선언하였다면, 수많은 회사들의 문의가 쏟아질 것이다. 학원솔루션을 만들고 싶다, 체육관 솔루션을 만들고 싶다, 우리 이번에 광고성 앱 하나 만들고 싶다...... 필자도 하루에 수십 건의 요청을 받은 적이 있다. 결론부터 말하자면, 기존 IT업무와 관계없는 사람들이 제안한 요청을 수행하는 것은 매우 피곤한 일이다.
- 소비자가 스스로 무엇을 원하는지 모른 다는 것은 굳이 설명할 필요가 없는 매우 유명한 말이지만, SW업계에서는 기획하는 사람 조차 자신이 무엇을 기획하는지 모르는 경우가 태반이다. 때문에 IT와 관련된 사람의 기획자나 관리자가 필요하다. 식음료회사, 학원, 체육관 등의 외주를 시작하면 후에 그것 때문에 골치가 아파질 확률이 매우 높다. 필자가 멋 모를 때 학원 솔루션을 하나 맡아본 적이 있었다. 필자가 생각하기에 학원이란 것의 프로세스는 기껏해야 학생 관리일 테니, 며칠 간단하게 작업하면 끝낼 수 있을 것이란 생각을 하였다. 그러나 실제 숨겨진 오퍼레이션이 매우 많았고, 담당 클라이언트도 이런 오퍼레이션에 대한 요청을 지속적으로 하여 왔다. 도중 프로젝트를 몇 번 뒤엎다가 결국 심신이 피로해진 상태로 프로젝트가 중지되었다.
IT 회사의 외주발주를 추천하는 이유는 무엇보다도 개발 도중의 커뮤니케이션이 편하다는 점, 그리고 보통 어느 정도의 난이도를 갖는 프로젝트이기 때문에 기술력을 쌓기 좋다는 점, 그리고 회사 네트워크의 확장이라는 점에서 1순위로 추천한다.
(3) 기획서를 확인한 다음 계약하라. 개발 도중 기획서가 심하게 변동되면 바로 계약을 취소하라.
- 제대로 된 마인드를 가진 회사라면 계약 전에 기획서를 보여줄 것이다. 기획서 없이 '그냥 그렇게 만들면 되요' 라고 말하는 회사나, 자신이 외주를 먼저 문의하였으면서도 '기획서를 직접 만들어 오세요' 라고 말하는 회사라면 그 회사의 속 사정이야 뻔하다. 즉 자신이 원하는 것이 뭔지 모른다는 이야기다.
- 물론 가장 좋은 외주는 개발사가 아이템에 대하여 클라이언트와 컨센서스를 맞춘 후, 직접 기획서를 만들고, 먼저 제안한 다음, 그것을 발주 받는 것이다. 이럴 경우에는 보통 '인정상' 개발비를 후하게 쳐주는 것이 보통이다. 그러나 클라이언트에서 먼저 개발외주가 제의 들어왔는데 기획서를 갖추고 있지 못하다고 하면 기획서에 대한 컨센서스를 맞추는 데만 2주일이 걸린다.
(4) 개발자 없는 IT 벤처회사의 외주는 추천하기 힘들다. 그 회사가 무슨 공모전에 수상을 하였던, 언론을 몇 번 탔건 신경 쓰지 마라.
- 이런 경험이 있다. 휴대폰 회사 출신의 한 벤처회사가 필자의 회사에게 개발의뢰를 요청하여왔다. 필자가 대략 판단하여 보니 '벤처허세'를 부리는 회사 같아 무시하려고 했는데, 한 개발자가 그 프로젝트가 맘에 들었는지 굳이 하겠다고 나섰다. 그러나 IT 특성을 모르는 회사라는 것이 곧 드러났고, 기획서는 수십 번의 변동사항이 있었고, 초기 개발비에다 0하나를 더 붙여야 되는 최종 기획서가 탄생하였다. 이러한 회사일수록 언론을 이용하여 자신을 포장하려고, 과거 무엇을 하였다는 '추억의 허세'를 부리는 일이 많다. 제대로 된 IT 벤처회사라면 In-house 개발자 없이 무언가 만들 수 있다는 착각은 하지 않을 것이다.
(5) 계약이 되면, 클라이언트는 계약 상대방이 아닌 자신의 상사다. 최대한 자주 연락하고, 기술적/기획적인 모든 요소를 보고하라.
- 계약서에 도장을 찍는 순간 클라이언트와 당신은 더 이상 거래관계라기보다는 한 '팀' 이라고 생각하는 것이 좋다. 개발 프로세스를 최대한 잘게 쪼개어서 주기적으로 보고하고, redmine 등과 같은 툴을 이용하여 진행률을 보고하는 것도 좋다. 솔루션마다 다를 수는 있겠지만 필자의 경험상 대다수의 솔루션 개발은 일주일 1~2회 보고를 하였다.
- 이러다 보면 클라이언트가 보고받는 것에 대하여 무신경해질 수 있는데, 상대방이 개발에 대하여 무신경하거나 답장 메일이 없을 시라도 꾸준히 연락하고 최대한의 정보를 송부하여야 한다. 클라이언트와 관계가 친하다고 개발팀 마음대로 일정을 가져가거나, 여러 상황에 대한 변명을 하는 케이스를 많이 보았는데 클라이언트와 친한 관계를 유지할 수 있는 조건은 개발팀이 자신의 업무를 철저하게 완수하는 것 임을 명심하여야 한다.
(6) 가격
- 아마 가장 민감한(?) 부분일 것이다. 개발 외주의 가격은 일단 다음을 기준으로 한다.
<자격기준>
기술사: 기술사 자격 취득자
특급기술자: 고급기술자 자격취득 후 3년이상 SW기술분야 업무 수행자
고급기술자: 중급기술자 자격취득 후 3년이상 SW기술분야 업무 수행자 or 박사학위자중 기사자격 취득자
중급기술자: 기사 자격 취득 후 3년이상 SW기술업무 수행자 / 산업기사 취득 후 7년 / 공인민간 자격 취득자로 3년이상 SW 기술분야 업무수행자 / 기사 또는 민간자격증 취득한 석사가 2년이상 SW 업무 종사
초급기술자: 기사자격 취득자 / 산업기사 취득자 / 공인민간자격증 취득자 or 전문학사학위 소지자
고급기능사: 산업기사 취득 후 4년이상 / 기능사 취득 후 7년이상
중급기능사: 산업기사 취득자 / 기능사 취득 후 3년이상
초급기능사: 기능사 자격 취득자
자료입력원: 자격조건 없음
과거 정부에서 개발 커리어 별로 개발자를 분류하였고, 이에 따라 업무의 특성도 반영하지 않은 이상한 노임단가표를 '하한선' 이라고 제시하였다. 그러나 실제 LG CNS, 삼성 SDS등의 개발 발주는 이것이 '상한선'으로 작용하였고, 곧 이 '상한선'이 IT 회사들에게서 널리 퍼지게 되었다.
그러나 업무의 특성, 강도, 개인의 능력차도 구별하지 않은 이 노임단가는 곧 시장의 외면을 받게 된다. 외주 개발사로는 납득하기 어려운 개발 단가를 참여도 부풀리기, 인원 부풀리기, 기간 부풀리기 등으로 해소하려 하였다. 그리고 외주 발주한 팀에서는 편법을 쓸 수 밖에 없는 사정을 인정하게 되었다. 정부는 결국 이 제도가 말이 안 된다는 것을 인정하고 2012년부터 해당 노임표는 더 이상 나오지 않고 있다.
그러나 산업계 현실상, 개발사들은 클라이언트와의 원활한 커뮤니케이션을 위하여 이러한 자료를 기반으로 커뮤니케이션 하는 것이 유리하다 (다만, 실제 금액은 케이스 by 케이스라는 것을 유념할 필요가 있다). 필자의 경우는 처우를 특급개발자에 준하게 하고, 기술료를 별도로 산정하는 선에서 커뮤니케이션을 하고 있다.
금액 산정 시에 가장 주의해야 할 부분이 있다. '많이 받는 것이 좋은 것은 아니라는 것' 이다. 이 세상에 공짜는 없으며, 많이 받은 만큼 많이 일하고, 적게 받은 만큼 여유시간이 많게 된다. 같은 업무를 하더라도 지나치게 돈을 많이 받게 되면 반드시 그 돈을 다시 버려야 하는 일이 생김을 유념해야 한다.
(7) 마지막으로, 개발외주, 과연 해야 할까?
개발 외주는 마약이란 말을 자주 들었다. 할 수 없어서 하는데, 개발외주를 하다 보면 돈이 들어오고, 돈이 들어오니 사람을 고용하여 개발 외주를 더 하게 되고, 이런 것이 반복되다 보니 본래 아이템을 잊어버리고 SI성 개발외주만 작업하게 된다는 것이었다. 실제로 그러한 회사를 많이 보아왔다. 다만, 자신의 아이템을 개발하는 데에 드는 비용을 무시할 수 없기에 개발 외주도 그렇게까지 무시할 것은 아닌 것 같다.-by 보통개발자
