열악한 소프트웨어 외주 개발 문제는 우리나라에서 소프트웨어가 3D 취급을 받는 주요한 원인 중 하나다.
'갑을병'으로 이어지는 외주도 모자라 '갑을병정무'까지 3,4단계 외주를 주기도 한다. 하청에 재하청이 이어질수록 열악한 댓가와 무리한 일정 그리고 부정확한 요구사항은 외주 개발을 점점 구렁텅이로 내몰고 있다.
소프트웨어 외주 개발 문제를 얘기하면 할 말이 많은 사람들이 꽤 있을 것이다. 필자는 그 중에서 접해 본 사례를 중심으로 소프트웨어 공학과개발 문화적으로 문제점을 지적해보고자 한다.
A사는 새로운 서비스를 시작하면서 서비스 개발을 야심차게 인도에 외주를 줬다가 큰 낭패를 봤다.
지금도 왜 인도에 외주를 줬는지 궁금하지만 추측컨데 실리콘밸리 외주 형태를 흉내를 낸 것이 아닌가 생각한다. 그런데 인도 개발사는 개발 완료 후 L사에서 기대한 것과 전혀 다른 것을 전달해왔다. 프로토콜도 완전히 다른 것이고 도저히 서비스에 사용할 수 있는 상황이 아니었다.
이런 일이 벌어진 가장 큰 이유는 스펙을 제대로 전달하지 않았기 때문이다. 인도 개발사에 전달된 스펙은 간단한 기획서 수준이었고 프로토콜도 제대로 언급하지 않았다. 게다가 인도 개발사가 소프트웨어를 완성해서 전달할 때까지 중간에 제대로 점검을 하지 않았다.
한국 업체 같으면 억지를 부려서 잔금을 안주면서 다시 개발을 강요 했겠지만 인도 개발사는 계약대로 개발을 했고 억지는 통하지 않았다. 잔금을 안줄 수는 없었다. 결국 인도 개발사가 개발한 소프트웨어는 모두 버리고 다급하게 한국업체를 통해서 다시 개발을 했다. 돈은 돈대로 더 들고 서비스도 뒤죽박죽이 되었다.
B사는 1년이 넘는 꽤 긴 프로젝트를 제대로 된 스펙도 없이 외주를 주고 고치기를 반복한다.
외주 개발사에는 핵심 기능을 정리한 한 두 페이지 정도의 요구 사항 문서가 전달된다. 외주 개발사는 전체 프로젝트 기간 중 20~30% 정도 기간 안에 소프트웨어를 만들어 보여줘야 한다. 남은 70~80% 기간은 B사의 요구대로 거의 매일 소프트웨어를 수정하고 보여주기를 반복해야 한다.
외주 개발사는 해당 분야의 전문 회사라 이런 부정확한 요구사항으로도 대충 B사가 원하는 것을 이해해 개발할 수 있었다. 개발사의 PM은 수시로 고객사에 불려가 요구사항 변경 회의를 해야 했고 소프트웨어를 계속 고쳐나가기 때문에 아키텍처를 제대로 유지하기가 어려웠다.
심지어 막판에 요구사항이 크게 바뀌어서 다 버리고 다시 만드는 일도 발생했다. 외주 개발사는 비용도 과도하게 투입해야 하고 프로젝트 관리를 제대로 하기도 어렵다. 하지만 B사가 가장 큰 고객이므로 시키는 대로 할 수 밖에 없었다. B사는 이런 식으로 프로젝트를 진행하는 것을 아직도 당연하게 생각한다.
C사와 D사는 소프트웨어 개발 외주가 제대로 진행이 안돼 외주사 개발자를 회사 내부에 앉혀 놓고 같이 개발하는 형태로 개발을 한다.
외주 프로젝트지만 옆에서 같이 개발하지 않으면 제대로 개발이 안되기 때문에 같이 일해야 한다. 옆에 앉혀 놓고 개발한다 뿐이지 개발 방식은 다른 외주와 별반 다를 바가 없다. 요구사항은 계속 변하고 애써 작성한 코드를 버리고 고치기를 반복해야 한다.
외주사도 이런 방식이 비효율적이라서 원하지 않지만 고객사의 우월한 지위를 꺽을 수가 없고 이렇게 일하다 보니 외주 개발 내용 외에 그냥 직원처럼 부림을 당하는 경우가 많이 발생한다.
D사는 외주를 줬다가 소스코드가 없어져서 소프트웨어를 버려야 했다.
D사는 소스코드를 받을 수 없는 외주 계약으로 개발을 했다. 처음 몇 년은 유지보수를 잘 했지만 몇 년 후 외주 개발사는 망해서 없어졌다. 그 과정에서 소스코드가 D사로 제대로 전달되지 않아서 최신 소스코드를 찾을 수 없는 상황이 되었다. 결국 외주 개발한 소프트웨어는 모두 버리고 다시 개발해야 하는 상황이 되었다.
E사는 개발자가 해야 할 개발자 테스트를 외주업체에 맡긴다.
개발자는 열심히 코딩만 하고 옆에 앉아서 외주개발자가 기본적인 개발자 테스트를 해준다. 속된 말로 '따까리'라는 말이 적합하다. 비싼 자사 개발자가 너무 바쁘기 때문에 그렇게 한다고는 하지만 자칫하면 잘못된 개발 습관이 쌓일 수 있다.
또한 이렇게 해서는 코드 품질을 보장하기 어렵다. 완벽한 로직의 코드인지는 개발자 본인이 가장 잘 확인 할 수 있는데 대충 만들고 발견된 문제만 해결하는 방식이 습관화 될 수도 있다. 개발자는 완벽한 소스코드를 적는데 최선을 다해야 하는데 이런 개발자의 의무를 망각하면 프로그래밍은 기초부터 흔들리게 된다.
위에서 살펴 볼 수 있듯 외주 문제의 주된 원인은 부실한 스펙이다. 모호한 요구사항 정도로 계약을 하게 되니 중간에 요구사항이 계속 바뀌어도 어쩔 수 없고 프로젝트 종료 기준도 모호하여 담당자 맘에 안들면 잔금을 받기도 어렵다. 소송도 종종 일어나지만 시간도 오래 걸리고 소송을 해도 해결하기 쉽지 않다. 고객이 대기업인 경우 소송을 하기도 쉽지 않다. 스펙을 제대로 적는 것은 소프트웨어를 개발하는데 있어서 가장 어려운 일이기 때문에 한마디로 설명할 수는 없다.
소프트웨어를 직접 개발하지 않고 외주 개발을 하는 주된 이유는 다음과 같다. 직접 개발할 수는 있는데 내부 인력이 부족할 때와 특정 요소기술을 내부에서 보유하고 있지 않을 경우다. 내부에서 개발할 수 없을 만큼 잘 모를 때는 외주를 주기도 어렵다. 모르는 상태에서 대충 외주를 주면 원하는 결과를 얻기도 어렵고 분쟁이 일어나기 쉽다.
기술력이 뛰어나거나 전문 기술을 가지고 있는 외주 개발사와 협업을 잘하는 것은 소프트웨어 생태계를 만드는데 아주 중요하다. 제대로 외주를 주기 위해서는 고객도 스펙을 제대로 적을 수 있을 만큼 잘 알아야 한다.
부품 업체 다 망하고 나면 자동차 회사도 망하듯이 수많은 전문 소프트웨어 회사들이 망하고 나면 우리나라 소프트웨어 업계도 망하는 것이당연한 수순이다. 대만이 자전거 산업에서 세계를 호령하는 이유는 자전거 부품회사와 꾸준히 상생을 해와서 대만에는 뛰어난 자전거 부품회사가 많기 때문이다. 그에 비해서 생산비 절감에만 몰두한 우리나라 자전거 산업은 전세계 자전거 산업에서 명함도 못 내밀고 있다. 이미 많은 중소 소프트웨어 회사들이 사라졌거나 고사 상태인 지금 자전거 산업과 비슷한 미래가 예상되는 것은 안타까운 일이 아닐 수 없다.
이제 와서 말로만 베풀듯이 상생이라고 외치는 것은 들을 때마다 거북하고 막상 그 내용도 해결책의 핵심은 아니다. 우리나라에서 소프트웨어 개발이 3D라는 인식에서 벗어나라면 이런 열악한 외주 환경이 바뀌지 않으면 안된다.
이글은 ZDNet Korea에 기고한 칼럼입니다.
