우리나라의 소프트웨어 환경의 문제점 중 하나가 고객이 잘 모른다는 것이다.
예를 들어 공공 SI 프로젝트의 경우 발주처인 공공기관의 담당자가 SI회사의 개발자들보다 업무를 잘 모르는 경우가 종종 있다. 공무원들은 몇년만다 한번씩 자리를 옮기기 때문에 자신의 업무를 빠삭하게 알지 못하고 SI회사에 많이 의지하게 된다. SI회사에서는 해당 분야의 업무만 오랫동안 개발해온 개발자들이 있어서 현업 담당자보다 더 잘 알곤 한다. 외국의 경우 몇십년씩 한자리에서 공무원이 최고의 전문가가 되는 경우와는 사뭇 다르다.
그래서 공공프로젝트를 진행할 때 SI회사가 많이 주도를 한다. 심지어는 발주처에서 해야 할 일도 다 SI회사가 해주곤 한다. 어떻게 보면 SI회사에 좋기도 하지만 문제도 많다. 요구사항 분석 때 충분한 정보를 주지 않아 나중에 요구사항이 많이 바뀌기가 일쑤이고 그로 인해서 프로젝트에서 손해도 많이 난다.
비단 공공분야만이 아니다. 소프트웨어 선진국에서는 기업이 소프트웨어 외주를 줄 때 해당 기업에서 충분히 분석, 설계 역량이 있고 스펙을 제대로 작성해서 외주를 주곤한다. 즉, 직접 개발할 역량도 충분히 있는데 비용이나 시간 상 외주를 주는 것이다.
그런데 우리나라에서 외주를 주는 형태를 보면 고객이 잘 모르기 때문에 대충 외주를 주고 개발 업체가 이거저거 정말 알아서 다 해줘야 할 때가 많다. 그러다 보니 계약도 불분명하고 다툼도 많다. 법정까지 가는 다툼도 많이 발생하지만 엉성한 계약서를 가지고 누구의 자잘못인지 따지기도 어렵다.
개발업체에서 스펙을 제대로 작성하기 위해서 고객 인터뷰를 하고 요구사항 분석을 해도 협조가 잘 되지 않는다. 정확한 인터뷰 대상 선정도 쉽지 않다. 업체에서 나름대로 최대한 노력해서 스펙을 작성해도 고객이 스펙을 충분히 검토해서 확인을 해주는 일도 드물다.
일단 고객이 스펙을 충분히 잘 검토할 수 있는 실력이 부족한 경우가 많다. 그래서 스펙을 봐도 잘 모르기 때문에 잘 보지 않으려고 한다. 또, 개발해 놓으면 언제든지 바꿔달라고 하면 되는 것으로 착각을 해서 개발 전에 스펙을 잘 보지 않아도 된다고 생각한다. 심지어는 스펙을 잘 검토해서 확인을 해주면 나중에 바꿔달라고 못할지도 모른다는 생각도 한다.
이런 비전문가적인 고객들은 개발업체를 엄청 괴롭히지만 프로젝트에도 긍정적이지 않다. 이런 환경에서 좋은 아키텍처의 소프트웨어가 나오기 어렵다. 개발업체도 제대로 개발하고 싶겠지만 그냥 어떻게 검수만 나도 된다는 식으로 개발하기 쉽다. 서로에게 모두 손해가 되는 것이다.
외주, 즉 아웃소싱이 제대로 되려면 고객이 전문가가 되어야 하는 것이다.
