좌충우돌 서비스 론칭기 - 3

외주 개발은 피할 수 있다면 피하라.

새로운 서비스는 대부분 아이디어에서 시작한다. 서비스를 제공하다가 변화되거나 파생된 서비스로 발전하는 게 아니라면 새로운 서비스 인프라를 개발해야 하는데 스타트업은 이런 인프라 개발을 위한 개발인력이 충분하지 않기 때문에 가장 쉽게 접근하는게 외주 개발이다.

외주 개발사들은 아이디어만 고민하세요~ 앱은 저희가 만들어 드립니다. 라고 광고하지만 새로운 서비스를 처음 만드는 스타트업이라면 외주개발은 우선 배제하는 걸 추천한다. 앞 글에서도 말했지만 IT프로젝트 관리로 잔뼈가 굶은 전문 PM도 결국 외주 프로젝트에서 쓴 맛을 보았기 때문이다.

스타트업 서비스라는 게 완벽한 모델로 시작하는 게 아니므로 설계하면서 개발하면서 변화될 가능성이 매우 높다. 외주 개발은 초기 계약된 기능과 화면을 기준으로 프로젝트가 수행되기 때문에 변화에 대한 반영은 거의 불가능하다. 또한 기술을 잘 모르는 관리자가 프로젝트를 관리할 경우 개발사 마음대로 새로운 기술과 라이브러리는 사용하기 때문에 개발이후 운영에서 어떤 위험이 생길지 모른다.

필자의 경우 3번의 외주 프로젝트에서 1번째 완벽 실패, 2번째는 절반의 성공, 3번째 되어서야 제대로된 성공을 했다고 생각한다.

1번째는 그야 말로 아이디어를 앱으로 만들어 드립니다~ 라고 자신있어 하는 곳 중에서 그나마 괜찮아 보이는 곳을 고르고 골라 계약을 맺었다. 상세 기획, 디자인, 개발 전체를 맡겼기 때문에 잘 진행되는 듯 했지만 점점 개발이 늦어지더니 6개월이상 지연되면서 개발산출물 역시 오픈할 수 없는 수준이었다. 

앞서 말했듯이 처음 서비스를 론칭하면서 완벽한 설계가 없었기 때문에 우리는 이리저리 요구사항을 변경하고, 개발업체도 제대로된 개발자를 투입하지 않아 결국 실패로 끝나고 말았다. 

2번째는 자사의 서비스 론칭을 준비하는 아는 업체에 맡겼다. 사장님이 의욕적으로 기획을 새로 해오셨고, 구루처럼 보이시는 시니어 개발자는 라라벨 프레임워크를 이용해서 뚝딱뚝딱 개발을 해나갔다. 어찌어찌 서비스론칭은 했으나, 앱과 서버간의 송수신 데이터는 암호화도 안된 상태로 돌아다녔고, Table설계도 엉망이었다. 결국 서비스 운영을 해가면서 조금씩 보수를 해나갈 수 밖에 없었다. 

2번째 외주로 어찌 어찌 오픈한 앱은 안드로이드앱이었고, B2C서비스였던 우리 서비스는 iOS 앱 론칭이 절실했다. iOS개발자를 채용한다는 것은 무리였고, 채용도 쉽지 않았기 때문에 우리는 결국 또 외주를 주기로 했다. 

3번째 외주는 위OO이라는 IT외주 매칭 플랫폼을 이용했고, 제안을 해준 업체중에서 가장 경험이 많은 곳과 계약을 체결했다. 몇개 업체와 인터뷰를 진행하고 나서 자신이 좀 붙었다. 우리가 진행하려는 외주는 Android App을 똑같이 만드는 것이었기 때문에 범위가 명확하고 Sever 쪽은 우리쪽에 맡고 있어서 Architecture 위험도 적었다. 

당시 Server를 맡고 있던 내가 API 정의서를 Google Drive Sheet파일을 공유해서 전달하고 개발사는 API에서 제공해주는 대로 iOS Native App을 개발했다. 2주만에 개발, 1주 테스트, 2주 보완 및 App Store 등록까지 해서 App을 론칭할 수 있었다. 성공적이었다. 원격지 개발이었지만 협업툴로 실시간 소통을 하고 드라이브로 API문서를 공유해서 별다른 이슈 없이 끝낼 수 있었다. 원격으로 개발이 이렇게 잘 될 거라고는 생각을 못했는데 범위가 명확하니 원격 개발도 문제가 없다는 걸 처음 알게 되었다. 세상세 알아서 해주는 외주 개발사는 없다. 외주를 줘야 하는 범위가 명확하고 모든 것을 제어할 수 있어야 제대로된 외주 개발이 진행될 수 있다는 점을 명심했으면 한다. 그렇지 않으면 결국 천만원이든, 오천만원이든 외주 개발비만 날리게 된다.