분석 #10. 잘못된 국내 Outsourcing 계약 방식과 글로벌 계약 방식

이 기사는 일전에 게재한 기사인 “분할발주의 허구와 진실” 과 바로 앞 기사인 베트남의 Outsourcing 회사에 관한 기사와 연관되어 있다. 국내 개발 Outsourcing 생태계의 도전적인 숙제이자 염원이기도 한 “분할 발주”도 하고 싶고 글로벌 고객을 상대로 개발 Outsourcing 비지니스도 하고 싶겠지만 열정과 의지만으로 되는 것은 아니고 그를 수행할 수 있는 기본 역량부터 있고 다양한 고객을 상대할 수 있는 경험도 있어야 한다.

대부분의 국내 회사는 거의 미신과 같은 국내의 기존 관행에 몇십년을 젖어 있었기 때문에 우물안 개구리의 문제점을 눈치 채기도 어렵다. 이 기사를 읽어도 눈치 챌 수 있는 사람은 극히 소수일 것이다. 꿈속에서 사는 삶이 있고 현실의 삶이 따로 있는데 이런 추상적인 문제에서는 계속 꿈속에서 사는 것이 통상적이다. 영화 매트릭스에서 얘기한 빨간 약을 먹으면 계속 행복한 환상의 세계에서 살고 파란 약을 먹으면 고통스러운 진실과 마주한다는 것과 같다. 현실에서는 진실을 모르는 것이 더 좋은 경우가 더 많다. 어느 쪽을 택할 지는 순전한 각자의 선택이다.

먼저 소프트웨어 외주 개발 계약의 방식부터 간단히 살펴보자. 필자의 저서와 블로그에서 여러 번 언급했듯이 계약에는 Time and Material(T&M)과 Turn-key 의 두 가지 방식이 있다.

T&M은 인력의 노동시간(Time)으로 비용을 지불하는 방식이다. 발주자나 인력 업체나 간단하다. 인력을 어떻게 사용할지는 발주자가 알아서 관리한다. 계약한 숫자의 인력만 제대로 공급해주면 법적인 소송의 여지도 없다. 주로 개발 앞쪽의 분석 단계에서 사용된다. 산출물에 대한 객관적인 기준을 정할 수 없는 경우에는 T&M 방식이 가장 좋다. 정확하게 말하면 인력의 시간외에 실제 들어가는 장비나 물품((Material)이 포함한다.

반면에 Turn-key 방식은 서로 약속한 제품을 미리 정해진 가격(Fixed Price)과 일정에 개발해 주기로 하는 것이다. 즉 한 사람이 개발하건 10명이 개발해 주건 상관할 필요가 없다. 예를 들어 책상을 주문했는데 몇 명이 만들 건 상관이 없다. 원하는 제품을 만들어 주면 되는 것이다. 자동차를 주문해도 마찬가지이다. 몇 명이 만들었는지도 모르고 알 필요도 없다. 그런 자유가 있는 반면에 책임도 크다. Turn-key 방식은 약속한 물품을 제 일정에 배달하지 못하면 당연히 피해 보상등 법적 소송의 문제가 발생한다.

소송에서 시시비비를 판단하려면 제품에 대한 정확한 스펙(SRS)이 있어야만 가능하다. 정확한 스펙을 작성하는 것이 얼마나 어려운 지는 그 동안 필자가 누누히 설명했다. 정밀도의 문제와 같다. 1센티를 따지는 스펙과 1밀리미터를 따지는 스펙은 양과 질에서 차이가 난다. 소프트웨어도 홈페이지 만드는 정밀도와 금융 소프트웨어를 만드는 정밀도가 다르다. 간단한 홈페이지 프로젝트는 적당한 계약에 애자일 방법론도 좋고 주먹구구식으로 개발해도 큰 문제가 없다. 문제가 있으면 별 피해 없이 고치면 된다. 금융 소프트웨어는 1분만 다운되어도 피해보상 소송이 빗발치니 처음부터 문제 없도록 개발해야 한다.

스펙에 대해서는 여러 곳에서 충분히 설명했기 때문에 여기서 생략하고 Turn-Key 계약에 스펙보다 더 핵심인 인수테스트(Acceptance Test Plan, ATP)를 추가로 소개한다. 회사마다 용어가 약간 다를 수 있으나 가장 혼란 없이 이해하는 용어인 ATP를 사용하기로 한다.

위에서 말한 T&M 방식의 계약에는 인력 공급 내용만 있지 산출물은 정해지지 않았기 때문에 검증할 인수 조건이 없다. 쉽게 말해 일당으로 비용이 계산되는 일용직 고급 근로자라고 보면 적절하다. 통상적으로 분석이나 설계 작업과 같이 하루에 수천불 가격인 매우 비싼 직업이다. 개발의 첫 단계에서는 계약에 명시할 스펙도 없고 인수 조건도 나올 수 없다. 이런 비싼 고급 전문가를 잘 사용하고 관리하는 것은 전적으로 발주자의 역할이다. 전문성이 높은 분석가나 아키텍트인 만큼 대부분은 발주자를 리드하고 주도해서 일을 할 수 있는 능력이 있다. 그런 능력 때문에 비싼 값을 지불한다.

Turn-Key 방식의 핵심이 스펙이라고 이전에 필자가 계속 말해 왔는데 일부만 사실이다. 진짜 핵심은 인수조건이다. 인수테스트로 대표되는 인수조건이 핵심이다. 하지만 인수테스트만 가지고는 개발을 할 수 없기 때문에 개발할 내용을 설명하는 스펙이 필요한 것이지 법적인 상황에서는 스펙보다는 ATP로 시비를 가린다. 근본적으로 ATP를 통과하면 계약은 종료된 것이고 ATP 중에 하나라도 실패하면 계약이 종료되지 않은 것이다. 개발사가 폭포수 모델로 개발하건, 애자일방식으로 개발하건 반복적모델로 개발하건 상관이 없다. 100개가 넘는 시중의 개발방법론, 또 수만개는 되는 다양한 종류의 템플릿 중에 어떤 것을 사용하건 상관할 필요가 없다. 그냥 약속한 일정에 ATP를 통과한 물품을 배달하기만 하면 된다. 이상적인 상황이라면 중간에 서로 대화를 할 필요도 없다. 배달 날자까지 기다렸다가 인수를 하든지 피해보상 소송을 하든지 둘 중의 하나이다. 이 부분은 명백한 흑백논리가 적용된다. 예를 들어 ATP에 포함된 10,000개의 테스트 케이스 중에서 1개라도 실패하면 실패한 것이다.

Turn-key 계약의 인수조건은 아주 명백하지만 아무나 이렇게 하기 어려운 두가지 이유가 있다. ATP에 포함되는 테스트 케이스를 만들기 어렵다. 국내에서 ATP를 이용해서 계약을 한 회사는 필자는 본 적이 없다. 대부분은 엉성한 스펙만으로도 몇 백억짜리 프로젝트도 계약 한다. 성공하면 기적이다.

누가 테스트 하느냐에 따라서 ATP에 들어가는 테스트 케이스의 개수는 10배도 더 차이가 난다. 회사의 내부에서 제품도 잘 알고 늘 테스트 해 오던 사람들이 하는 경우와 외부의 인력이 테스트 할 경우에 테스트 케이스의 숫자가 10배 정도의 차이가 날 수 있다. 전혀 모르는 사람에게 스펙을 적어 줄 때도 마찬가지이다. 내부 인력이라면 10 페이지 적으면 되는 양을 외주 계약을 위해서는 100 페이지를 적어야 하는 경우가 전혀 이상한 것이 아니다. 필자에게 “스펙이나 ATP를 얼마나 자세히 적어야 됩니까?” 라는 질문을 많이 하는데 고객과 상황에 따라 다르다는 답 밖에 없다. 이런 상황에 따른 유연성이 진정한 소프트웨어 공학의 영역이다. 건강에 좋은 음식이 사람에 따라 다른 것과 마찬가지이다. 만약 누가 정형화된 답을 준다면 그것은 이론이며 가짜 소프트웨어 공학인 것이다.

우여 곡절 끝에 많은 시간을 들여서 외부 사람들을 위한 방대한 ATP 테스트 케이스를 작성했다고 가정하자. 그렇다고 개발업체만 믿고 계약 마지막 날에 완성이 될 것이라고 기다리기에는 불안하다. 100만원에 1주일짜리 프로젝트라면 그렇게 해도 괜찮겠지만 100억에 1년 걸리는 프로젝트를 하는데 그렇게 할 수는 없다. 그래서 ATP는 완료 평가의 척도는 되지만 중간에 개발이 제대로 진행되는지 확인하기 위해서는 다른 방법이 필요하다. 그래서 Design Review, Integration Test, 몇 번의 Iteration등 중간 중간에 진행 상황을 검증할 수 있어야 한다. 물론 여기에서도 몇 명이 개발하는지는 중요하지 않다. 천재 1명이 개발하든 초급개발자 100명이 개발하든 그건 개발업체의 선택이다.

정확한 스펙과 ATP도 없이 수행하는 Turn-key 계약은 근본적으로 거대한 위험성을 내포하고 있다. 성공할 가능성은 없다고 보면 된다. 나중에 그냥 서로 눈감고 대충 넘어가거나 소송으로 가거나 둘 중의 하나이다. 거대한 제품을 개발했는데 인수를 거절해서 소송이 벌어진 경우도 있다. 정확한 스펙과 ATP 없이 계약하려고 하니까 뭔가 안전장치를 만들어야 하고 담당자는 책임도 회피해야 하니 투입할 인력을 명시하게 된다. 더군다나 발주자가 확인할 수 있는 장소에 상주하도록 요구한다. 그러다 보니 Turn-key 계약에 액수, 일정, 인력까지 명시하는 것이다. 상식적으로 말이 안되지만 담당자가 책임을 회피하기 위해서는 가장 쉬운 방법이 인력이다. 그러니 원래 어려운 원격 개발은 이래저래 더 어렵다.

그래서 T&M 방식도 아니고 Turn-key 방식도 아닌 비상식적인 계약이 그동안 국내에서 멀쩡하게 사용되어 왔다. 그럴 수 밖에 없는 근본적인 원인은 스펙의 부정확성, ATP의 부족이나 부재, 그리고 중간에 Monitoring 할 수 있는 역량이 부족하기 때문이다. 국내에서는 이런 식의 계약에도 거부감을 느끼지 못하겠지만 이런 비상식적인 계약은 소프트웨어 선진국의 정상적인 상황에서는 존재할 수 없다. 발주자인 갑의 역량부족으로 인해서 생긴 계약의 횡포일 뿐이다. 이 모든 문제를 해결하려면 ATP를 작성할 수 있는 역량이 있어야 하는데 ATP를 만들기 위해서는 정확한 스펙이 있다는 가정하에서만 가능하다.

진정한 Turn-key로 계약하고 관리할 수 없는 회사에서 과연 훌륭한 소프트웨어를 만들어 낼 수 있을까? 없다고 생각한다. 전략 없는 숙련공들의 혼란스러운 개발이 될 수 밖에 없다. 스펙을 개발 도중에 변경하는 일도 빈번하고 따라서 회의나 번잡스러운 일이 많아지고 관리비용이 엄청나게 추가된다. 개발보다는 관리에 더 집중하기 쉽다. 그래서 관리를 잘해 보겠다고 또 새로운 시스템을 도입하거나 PMO니 하는 얘기가 나오는데 방향을 잘못 잡는 것이다. 합리화 하기 위한 방법으로 실리콘밸리의 영웅담 같은 얘기는 꼭 인용한다. 악순환이 계속된다. 대부분의 문제는 관리로 해결될 수 있는 문제가 아니기 때문이다. 좌절한 개발자가 중간에 사라지는 것도 늘 보는 현상이고 납기 지연은 너무 당연하다. 종종 나오는 뉴스가 알만한 큰 프로젝트들이 지연되었다는 기사이다.

국내는 인간 관계로 적당히 실패를 덮어 버릴 수 있다. 그러나 그럴 수 없는 국제간의 심각한 계약을 한다고 생각해 보면 ATP를 작성할 수 있는 역량이 없으면 T&M 방식으로 계약하는 방법 밖에 없다. 글로벌 회사에서는 발주자나 개발업체나 둘 다 엉성한 Turn-key 계약은 할 수 있는 근거도 없고 그런 위험하고 무책임한 계약은 하지도 않는다.

거의 모든 국내 소프트웨어 관련 소송은 이 부류에 속한다. 소송 당사자들은 국내 관행대로 했는데 왜 소송을 당했는지를 이해하지 못한다. ATP와 같은 객관적인 평가 기준이 없으니 자신들 유리한 대로 해석하고 서로 상대방만 비난한다. 개발업체는 몰상식한 악덕 발주자를 만나서 억울하다고 하고 발주자는 회사에 손해를 끼친 엉터리 개발업체라고 분에 차있다. 처음부터 사기를 치려고 하지 않았다면 대부분의 경우 둘 다 50% 씩 잘못이다. 이 모두 ATP만 있었다면 소송에 갈 필요도 없다.

분할 발주, 원격 개발, 탄력있는 근무 시간등 아주 듣기 좋은 말들이다. 정부가 강제로 계약에 관련된 이런 정책을 법제화 하려고 하는 것은 좋지만 생태계가 준비되지 않은 상태에서는 더 큰 문제를 불러 올 수 있다. 근본적인 이해 없이 눈 앞의 증상만을 치료해 보고자 하는 단세포적인 정책은 또 다른 문제를 불러온다. 극히 조심해야 한다.

스펙이나 ATP 작성 역량은 계약을 위한 역량뿐은 아니고 소프트웨어를 제대로 개발하기 위해 꼭 필요한 역량이다. 이런 기초 체력 없이 소프트웨어 강국이 되려는 생각은 허황된 망상에 불과하다. 그냥 국내에서 국내 고객을 위해 국내용 소프트웨어를 개발하는 정도로 만족해야 한다. 그것도 하나의 훌륭한 성공이다. 많은 시간과 경험이 필요한 이런 역량을 교육으로 해결하겠다는 생각을 하는 사람들도 많이 봤는데 태권도를 이론 교육으로 가르치려는 것과 같다. 이는 학교에서는 절대 가르칠 수 없는 현실의 문제이고 바로 진정한 소프트웨어 공학 역량이다.