이 여섯곳에 대한 고객 만족도나 프로젝트 제안서, 개발자 이력서의 품질 등은 큰 차이가 없는 것으로 평가되었습니다. 여러분들은 다음 비교표를 보시고 어떤 회사를 선택하시겠습니까? (참고로 아래 사례는 실제 돈을 주고 진행되었던 연구입니다)
실제로 이 6곳에 모두 원하는 금액을 주고 프로젝트를 진행하게 했습니다. 각 개발사에 동일한 수준의 정보를 주고 동일한 정도의 지원을 해주려고 노력을 했습니다. 그렇게 해서 프로젝트를 완료할 때까지 가본 겁니다. 완료의 기준은 고객사가 미리 준비해 두었던 승인 테스트를 모두 통과하는 것이었습니다.
먼저 자신이라면 어느 회사를 고를지 꼭 마음을 정하신 다음에 계속 읽어주세요. ^^;
결과는 다음과 같았습니다.
A와 E를 비교하면 개발 시간만 따졌을 때 약 20배입니다. 당연히 라인수도 차이가 크고, 코드 복잡도(숨겨진 버그 개수, 유지 보수 비용, 디버깅할 때 버그를 삽입할 확률 등과 관련성이 높다고 밝혀진)도 차이가 크고요. 가독성도 차이가 큽니다. 이뿐만이 아닙니다. 추가적으로 개발이 종료된 시점에 각 회사에게 새로운 특정 요구사항을 반영하려면 얼마의 추가 개발시간이 필요하겠냐고 물었습니다. A회사는 2시간이라고 했고, E회사는 54시간이라고 답했습니다.
결과를 보고나서 생각은 어떻습니까? 미리 알았더라면 어느 회사를 골랐겠습니까?
어떤 분들은 자신이 처음부터 A회사를 골랐다고 기뻐하고 계실지도 모르겠습니다. "가장 저렴하고 가장 빠르다고 하니까 당연히 A를 골랐어야지"라고 하면서 자신이 정답을 골랐다고 생각하고 계실 겁니다.
사실 여기에는 정답이 존재하지 않습니다. 사후적으로 보면 A회사가 가장 좋은 선택이었기는 했지만 사전에 어느 회사가 좋은 회사인 걸 안다는 것 자체가 쉽지 않습니다. 가격이나 일정 기준으로 A회사를 골랐는데, 실제로도 A회사가 좋기는 했지만 그것은 운이 좋았던 겁니다.
연구에 따르면 전통적으로 외주 개발사를 선택하는 기준들이 효과적이지 않습니다. 다 뛰어나서 서로 큰 차이가 없다 싶은 회사들을 골랐는데, 실제로 동일한 요구사항 명세서를 주고 똑같이 일을 시켜보니 압도적인 차이가 벌어지는 겁니다. 이 프로젝트에 장기적으로 들어가는 비용면에서 보면 수십배 이상의 차이가 생기는 셈입니다.
예컨대 많이들 보는 "성공 사례" 경우 편향의 위험이 있습니다. 전체 몇 건 중에서 몇 건이 성공했다는 정보가 없이 성공한 사례만 소개되는 선택적 표본 선택의 문제가 있기 때문이죠. 온라인에 많이 광고하는 성형수술 비포어/애프터 사진들이나, 우리 병원에서 누가 수술해서 성공했다는 사례들이 그러합니다. 그래서 "근거 기반"(evidence-based)이 중요하다고들 하는 것이죠.
8천여개 프로젝트를 분석해 본 결과, 예를 들어 해당 외주업체의 경력(과거 얼마나 많은 프로젝트를 진행해 봤는가)은 프로젝트의 성공과 실패 여부에 영향력이 없었습니다. 하지만 8만여개의 입찰건을 함께 분석해서 나온 것은, 해당 입찰 업체의 프로젝트 수행 건수가 입찰한 업체들 중 평균보다 많으면 선택될 확률이 3배 가량 높았습니다. 성공과 실패에 영향력을 미치지 못하는 의미없는 노이즈에 신경을 쓴다는 말입니다.
가격(및 기간 -- 통상 기간과 가격은 비례)부분은 어떨까요? 앞에서 A회사를 고른 분들은 이걸 보고 골랐다고 하신 분들이 많을텐데요. 같은 연구에서 나온 결론은, 입찰 업체들 중 평균보다 낮은 가격의 업체를 선정하면 프로젝트 실패 확률은 24% 가량 높아집니다. 또한 가격이 낮은 업체를 주로 선정하는 고객들은 실제 스킬이 떨어지는 업체를 고르는 경향이 강하다는 분석도 나왔습니다. 더닝-크루거 효과(음의 생산성 참고)에 따르면, 실력이 떨어지는 사람들일수록 자신의 실력에 대해 지나치게 낙관적인 평가를 하는데, 마찬가지로 실력이 떨어지는 회사가 프로젝트 추정도 지나치게 낙관적일 수 있다는 말입니다.
그 외에 재미있는 부분은, 78만개 프로젝트에 대한 분석을 보면, 외주업체와 상관 없이, 이전 외주 프로젝트에서 성공 경험이 많은 고객사가 이번 프로젝트에 대해서도 성공할 확률이 높다는 결과가 나왔습니다. 확률로 보면 실패를 적게 경험한 고객사는 이번 프로젝트에서 실패할 확률이 그렇지 않은 고객사에 비해 51%나 낮았습니다. 실패 확률이 절반인 것이죠. 해석하자면, 소프트웨어 외주 프로젝트의 성공 실패에는 고객사의 역할(얼마나 잘 고르느냐, 어떻게 관리하느냐 등)이 중요하다는 것입니다.
자, 그러면 외주 프로젝트의 성공과 실패에 가장 영향이 큰 변수는 무엇이었을까요? 이전에 같이 협력해 본 적이 있느냐 하는 변수입니다. 이전에 협력을 해본 외주업체와 다시 일하는 경우, 실패 확률은 17%로 떨어집니다(78만개 프로젝트에 대한 연구 경우). 그렇지 않은 경우에 비해 약 6분의 일이 되는 셈입니다. 이건 무슨 뜻일까요? 보통 예전에 일해 보고 다시 일하는 경우는 만족할 경우입니다. 다시 말해, 한 번 일해보는 것 만큼 좋은 테스트가 없다는 것이죠. 앞서 말한 가격 요소를 무시해도 될 만큼 훨씬 더 영향력이 큰 요소입니다.
이런 결과들을 통합해 볼 때, 위 연구들에서 외주 업체 선정시 추천하는 방법은 "시험 외주"(trialsourcing)입니다. 시험 외주란 여러 입찰업체와 실질적으로 일을 하기 전에 업체를 평가하기 위해 일을 줘서 함께 일해보는 걸 말합니다. 시험 외주는 그냥 테스트만 하는 것이 아니라 외주라는 측면이 있어서, 실제로 우리에게 가치있는 일을 외주 주는 것이고, 따라서 시험 외주 참가에 대한 지불도 이루어 집니다. 이 시험 외주는 크게 보면 3가지 종류가 있습니다.
- 동일 작업 : 우리가 실제 프로젝트에서 하게 될 일 중 작은 부분 하나를 여러 입찰업체에게 주는 것입니다. 동일한 작업을 복수 진행하는 것이죠. 이 경우 금전적 부담이 늘어나게 되지만 가장 신뢰할만한 비교가 가능하다는 장점이 있습니다.
- 유사 작업 : 실제 프로젝트에서 하게 될 일 중에 유사하지만 다른 일들을 입찰업체에 나눠줍니다. 참고로 관련 논문에서는 모 텔레콤 회사에서 이 시험 외주 방식을 성공적으로 사용한 사례를 소개합니다.
- 상이 작업 : 전혀 다른 일들을 업체들에 나눠줍니다. 이 경우 비교가 쉽지 않지만, 그래도 논문에서는 분석에 따르면 안하는 것보다는 훨씬 낫다고 합니다.
사실 이 시험 외주는 애자일 방법론과 비슷한 면이 많이 있습니다. 폭포수 방식으로 프로젝트를 쪼갰을 때, 즉, 제안, 분석, 설계, 구현, 테스트, 전개 등으로 쪼갰을 때 어느 한 단계에 대한 피드백/평가로 다음 단계를 예측하기가 어렵기 때문에, 이것을 프랙탈 적으로 다 섞어서 반복 주기로 나누면, 하나의 반복 주기로 다음 반복 주기 예측이 비교적 유의미해진다는 것이 애자일의 주장입니다. 애자일은 쉽게 말해, 하나의 프로젝트를 마치 여러개의 프로젝트인 것처럼 만들어 각각의 프로젝트에서 배운 교훈을 다음 프로젝트에 적용하여 성공률을 높이는 것입니다.
분명 시험 외주가 추가적 비용이 들 수는 있지만, 업체 선정을 잘했을 때와 못했을 때의 차이가 엄청나다는 점을 고려한다면 투자할만한 가치가 있지 않나 생각이 듭니다. (이 때 원 프로젝트에서 어떤 부분을 쪼개어서 시험 외주 작업으로 선정하느냐와 평가시 무엇을 보는가가 전문성이 필요하고 또 차이가 큰 부분이긴 합니다)
그리고 꼭 시험 외주 방식을 적용할 수는 없더라도 이런 애자일적 접근법을 프로젝트에 어떻게 적용해 볼 수 있을까 고민하면 도움이 되지 않을까 싶네요.
제가 이 글을 쓰면서 참고한 논문은 다음과 같습니다. 정확성을 위해 몇 몇 부분은 원저자와 서신 교환을 통해 알아보고 확인했습니다.
- Better Selection of Software Providers Through Trialsourcing
- Failure Factors of Software Projects at a Global Outsourcing Marketplace
- When is a low bid price a thread and when an opportunity for your project? Analyzing projects in an online marketplace for outsourcing software development
- A Strong Focus on Low Price When Selecting Software Providers Increases the Likelihood of Failure in Software Outsourcing Projects