외주개발 이렇게만 하면 99.999% 말아먹을 수 있다.

정부 창업 지원을 받은 스타트업 10곳 중 7곳이 실패한다는데, 그 중 높은 비율이 외주개발 단계에서 문제를 겪는다고 합니다.

이번 컨텐츠는 외주개발을 고민하는, 외주개발을 시작하는, 외주개발을 이미 하고 있는 모두의 성공적인 외주개발을 위해 역으로 외주개발 실패하는 방법을 3단계로 나눠 준비해보았습니다.

수 백 만원에서 수 억원에 이르는 외주개발, 당연히 합리적인 비용도 중요하지만, 선택하려는 개발사가 경험도 없고, 포트폴리오도 적고, 언제 망할지도 모르는 불안한 개발사라면 정말 타 개발사 대비 견적이 낮다는 이유만으로 의뢰할 수 있을까요?

저렴한 견적으로 빠르게, 고퀄리티로 원하는 모든 내용을 담아 만들어 주는 개발사가 있다면 정말 좋겠지만, 개발사도 이익을 남겨야 하는 사업체이니 낮은 견적에는 다 이유가 있는 법이죠.

시간, 비용, 개발 품질 간에 가장 좋은 균형을 찾아 나가야 해요.

외주개발 업체를 고를 때 포트폴리오를 확인하라는 조언을 수도 없이 들으셨죠? 여기서 “누가 더 많은 수의 개발을 했는가?” “누가 더 네임밸류 있는 기업의 의뢰를 받았나?” 이런 점이 중요할까요?

아닙니다. 반드시 나의 서비스와 유사한 프로젝트 경험이 있는지를 꼭 확인하는게 포인트입니다.

학습용 앱을 개발하기 위해 외주 업체를 알아보는 상황을 가정해보죠. 대기업과 의뢰를 많이 진행한 A 업체와 그렇지 않은 B 업체의 포트폴리오는 각각 아래와 같습니다.

A 업체 : 창작물 거래 툴 개발, 부동산 중개 플랫폼 개발, 중고거래 플랫폼 개발 ··· B 업체 : 비대면 학습 플랫폼 개발, 공유 학습 협업툴 개발, 학습 솔루션 앱 개발 ···

포트폴리오를 비교해 보면 B 업체가 유사 프로젝트 경험이 많은 편입니다. 외주개발에서 유사 프로젝트 개발 경험은 곧 시간과 비용, 특히 개발 퀄리티와 직결됩니다. B업체는 경험을 토대로 프로젝트를 진행할 때 이슈 대응 등 상대적으로 수월하게 프로젝트를 진행할 수 있겠죠?

그 느낌, 개발사에겐 잘 보이지 않습니다. 일정도 밀리고, 개발 결과물도 마음에 안들고, 돈도 날리게 되는 지름길이라고 말할 수 있죠.

단순한 사업 계획이나 레퍼런스만으로 제대로 된 개발이 정말 가능할까요? 구체적인 요구사항을 정리한 기획문서 없이 개발을 진행한다면 프로젝트는 산으로 가기 마련입니다. 이 경우 개발 막바지에 법적 분쟁이 발생할 가능성이 높은데, 책임 소재가 클라이언트에게 몰릴 가능성이 높아요.

“기획이 너무 어려워요!”

서로 편한게 외주개발일까요? 확실한 요구사항을 전달하지 않으면, 서비스의 최종 테스트 과정에서 마음에 들지 않는 부분, 생각대로 구현되지 않은 부분을 수정하려다 정말 많은 시간을 낭비하게 됩니다. 계약 때 요구했던 요구사항 그 이상의 내용에 비용이 추가되는 것은 당연하구요.

클라이언트는 의도한 바를 상세히 요청하지 않고 개발사는 모호한 사항들을 검토 받지 않는 최악의 상황에서 과연 어떤 결과물이 나올지 상상이 되시나요?

개발사는 체계적인 소통 프로세스를 통해 클라이언트의 요구사항을 명확하게 정리해야 해요. 클라이언트를 귀찮게 자꾸 물어보고 괴롭히지만, 요구한 건 착착 해내는 개발사를 선택하세요.

물론, 클라이언트는 개발사의 소통 프로세스를 잘 활용해서 꼭 크로스체크를 해주셔야 합니다.

모든 과정에서 클라이언트의 컨펌을 구했던 개발사는 난감한 상황입니다. 게다가 클라이언트의 기준에게 단순한 수정 사항으로 느껴지는 내용이, 개발자 입장에서는 큰 공사로 이어지는 경우가 많습니다. 피라미드를 거의 다 지어가는데 맨 아래에 있는 돌을 빼서 교체해야 하는 꼴이죠.

프로젝트 일정에 차질이 발생하는 건 물론이고, 최악의 경우 말도 안되는 추가 개발비가 발생할 수 있습니다.

개발사의 귀책사유로는 추가 비용을 청구할 수 없습니다. 프로젝트의 히스토리 기록이 중요한 이유입니다. 클라이언트의 모든 요청사항과 컨펌 여부가 기록되어 있다면 귀책사유를 굳이 따질 필요도 없겠죠?

네, 발생할 수 있습니다. 이 세상에 완벽한 서비스는 없거든요. 글로벌 유저가 사용하는 유튜브도, 인스타그램도에도 오류는 존재합니다. 당연히 올바른 개발사라면 단위별, 기능별 QA 부터 전체 QA 테스트까지 진행하지만, 클라이언트도 개발된 서비스를 꼼꼼히 테스트하여 여러 조건에서 잘 작동하는지, 화면이 잘리거나 해상도가 깨지는 부분이 없는지 등의 크로스 체크는 필수입니다.

엠브이픽에 문의하는 클라이언트 중 개발 완료 후 “개발사부터 아무런 문서를 이전 받지 못했는데 어떻게 해야하냐”라고 물어보시는 분들이 꽤 있습니다.

개발사에 다시 요청해서 자료를 받으면 다행이지만, 담당 개발자가 퇴사하며 자료를 찾을 수 없거나, 개발사 자체가 없어지는 경우가 생각보다 빈번합니다. 이 경우 다른 개발 업체에 유지보수나 추가 개발을 문의해도 접근 자체가 불가하여 프로젝트를 거의 새로 개발하는 수준의 시간과 비용이 들 수도 있습니다.

위에서 언급했듯이 글로벌 서비스도 여전히 오류를 수정하고, 더 나은 서비스 사용환경을 위해 노력합니다. 서비스 개발 보다 훨씬 더 많은 투자가 이루어져야 하는 부분이죠. 유저의 피드백에 따른 기능 수정 및 추가, 그로스해킹 방법론에 따른 UI 수정, 시장 상황에 따른 트렌드 반영 등 할 일이 태산이죠. 대응이 더디면 기껏 개발한 서비스의 경쟁력을 잃게 됩니다.

처음부터 완벽한 서비스는 없습니다. 꾸준한 유지 보수는 유저들에게 안정적인 서비스와 만족을 제공 및 경쟁우위 유지, 최종적으로 사업의 지속성까지 보장할 수 있습니다.

지금까지 외주개발을 99.999% 말아먹을 수 있는 다양한 방법들을 살펴보았습니다. 재미적인 요소로 포장했지만 실제로 발생하는 사례인 만큼, 진행 중이신 외주개발 프로젝트의 성공에 도움이 되셨으면 좋겠습니다