요새 정부에서 분할발주를 하겠다는 정책이 있다. 정책의 방향은 100% 찬성한다. 하지만 방법이 문제다. 정책의 자세한 내용을 가지고 왈가왈부해 봐야 탁상공론식으로 찬성, 반대, 우려, 상황론에 의한 합리화등 너무 많은 이슈가 얽혀 있어 쉽게 결론이 나지 않는다. 진실의 이슈가 아니라 이 이슈도 정치적인 이슈가 되어 버렸기 때문이다. 정치적인 이슈의 특징은 아무리 오랜 세월이 지나도 모양만 변형될 뿐 노블리스 오블리제는 없이 각자 이득을 취하기 위한 본질은 변하지 않는다. 일단 올바른 정책을 펴기 위해서는 먼저 본질을 정확히 파악하고 있어야 한다. 또 역량도 없이 증상만을 치료하기 위해 인기영합적인 정책을 수립한다면 필연적으로 다른 문제가 생긴다.
아래에 필자의 저서인 "글로벌 소프트웨어를 말하다, 지혜 (2014/06)"에서 쓴 "인도에 개발 외주 주는 방법" 이 있다. 이 글이 분할발주에 대한 실리콘밸리 소프트웨어 회사에서의 기본적인 원칙과 방법론을 말해준다. 원칙에 어긋나는 정책은 시행착오를 일으키며 또 몇 년의 세월을 낭비할 것이다. 또 역량이 없으면 방법이 원칙에 맞더라도 실패할 수 밖에 없다. 불행이도 국내에는 개발 앞 단계의 분석을 등한시 하는 문화가 오랫동안 진행되어 왔기 때문에 먼저 분석역량의 제고에 신경써야 할 것이다. 또 분석과 설계를 한 덩어리로 묶어서 얘기하는 경우가 있는데 이 둘은 완전히 다른 역량을 필요로 한다. IEEE SWEBOK의 분석부분을 번역해 놓은 것이 이 블로그의 SWEBOK 카테고리의 Post에 있으니 참고하기 바란다.
34장 인도에 개발 외주 주는 방법
실리콘밸리를 미국이라고 하니까 백인들이 많을 것이라고 생각한다. 실리콘밸리에는 동양인들이 백인들보다 많다. 버클리 대학에도 인종으로는 동양인이 가장 많다. 특히 실리콘밸리같이 IT 분야에는 중국 개발자와 인도 개발자가 전체 개발자의 반 정도 된다. 중국이야 원래 인구가 많아 캘리포니아에 많이 살고 있었고 따라서 중국인 회사도 많았다. 필자가 1980년도에 실리콘밸리에 도착했을 때도 중국 식당이 가장 많았었다. 그러면서 미국의 전문인력 이민(H1B) 정책으로 전세계 인재들이 몰려들면서 중국과 인도의 개발자들이 대거 채용되어 왔다. 이것도 연쇄작용이라 그렇게 온 이민자들이 또 동료들을 불러오고 하니까 점점 더 많아진 것이다. 인도는 또 영어권이라는 장점 때문에 미국 회사의 외주 프로젝트를 많이 수행하면서 소프트웨어 산업이 발전하고 강국이 되었다. 그렇게 된 원인은 단 두가지이다. 싼 임금과 영어권이라는 것이다. 특별히 머리가 좋아서도 아니고 원래 소프트웨어에 적당한 문화라서도 아니다. 솔직히 정직성이나 책임감은 인도나 중국보다는 상대적으로 한국 개발자들이 더 좋다고 생각한다. 성공의 원인은 미국에서 배운 개발방식이다.
미국 회사는 영어가 잘 통하고 임금이 싸다는 장점으로 인도에 많은 소프트웨어 프로젝트를 주었다. 그래서 TCS, Infosys, Wipro, Sapient 같은 세계적인 거대 시스템통합업체가 발전했다. 그러면서 미국의 소프트웨어 개발방식을 배워 강국이 되었다. 소프트웨어 개발을 맡길때 정직성을 믿고 시스템 없이 맡기는 것과 모든 개발자를 믿을 수 없는 인간이라고 가정하고 시스템을 믿고 개발하는 것과 어느 것이 좋을까? 즉 사회를 통치할 때 성선설로 보는 것과 성악설로 보는 것 중 어떤 방법이 사회를 더 평화롭게 만들 수 있을 까? 미국은 근본적으로 소프트웨어 개발은 성악설에 기반한 개발 문화이다. 누가 무슨 일을 하는 지 명확하게 정의하고 진행하는 과정에 대해서도 투명하게 돌아간다. 투명 그 자체이다. 비밀스럽게 일하는 사람들에게는 무척 거북한 시스템이다. 이런 방식은 인도와의 관계 때문이 아니고 미국 회사 내부에서도 똑같은 방식이 사용된다. 일년 365일 내가 어느날 몇 줄의 소스코드를 고쳤는지를 누구나 항상 알 수 있다. 즉 인도 때문에 개발방식이 바뀐 것은 없다. 그러면서도 창조성이 필요한 곳은 허용해 준다. 창조도 투명하게 하는 것이지 창조성이 몰래 하라고 내버려두는 무정부상태가 아니다. 법과 질서를 잘 지키는 것이 창조성과는 아무런 관계가 없다. 참견하지 않는 것은 창조성이 아니라 무책임한 것이다.
국내 소프트웨어 회사에서 내부 프로젝트를 수행할 때나 외주를 줄 때나 상대가 인도라고 가정해보자. 과연 계약서에 서명을 하고 인도에 프로젝트를 줄 수 있는가? 물론 영어는 문제가 아니라는 가정하에서다. 필자가 보기에 인도에 프로젝트를 줄 수 있는 회사는 거의 없다. 국내 소프트웨어 회사는 대충 개발하는데 너무 익숙해져 있어서 그렇게 사는 게 인생인 줄 안다. 그리고 합리화를 할 수 있는 무기는 많이 있다. 대충 몇 개만 나열해 보면 다음과 같다.
? 계약시에는 그렇게 자세한 내용은 알 수가 없어서 진행하면서 정해가야 합니다.
? 새로운 제품이라서 먼저 대충 화면이 나오고 사용자 평가를 받아보면서 조정해야 합니다.
? 시간이 없어서 대충 계약하고 일단 시작해야 합니다.
필자가 귀가 따갑도록 들은 앵무새 같은 소리들이다. 한국에 처음 왔을 때는 신기했지만 이제는 그런 소리를 들으면 안타까울 뿐이다. 새로운 혁신적인 프로젝트는 한국보다는 미국이 훨씬 더 많다. 그리고 자세한 것을 모르는 상태나 시간이 없는 상태는 전 세계 모든 소프트웨어 회사의 공통점이다. 이제는 착각에서 깨어날 때도 되었다.
인도와 외주 계약을 한다고 가정하면 계약금액이 있고 일정이 있고 사양이 있어야 한다. 계약이 성립하려면 발주자나 수주자나 개발종료에 대한 확실한 기준이 있어야 한다. 대부분의 소프트웨어 방법론에서는 인수테스트(Acceptance Test Plan)라고 한다. 한국의 방식에서는 수주자가 개발이 종료했다고 선언한 다음에 발주자가 인수를 위한 검증을 수행한다는 희안한 과정이 들어 있다. 전혀 잘못이 없어 보이는 이 과정은 발주자인 갑의 무소불휘의 권리이자 최후의 방어선이기도 하다. 이 인수 검증이 바로 모든 문제의 원인이다. 이런 식의 발주자의 주관적인 검증은 미국이나 인도 회사가 도저히 받아들일 수 없는 계약조건이다. 프로젝트 계약이 성립할 수 없는 근본 원인이다.
인도의 수주한 개발자도 스스로 제품에 하자가 있다 없다는 것을 개발이 끝나기 전에 알고 있어야 한다. 개발자도 모르는 상태에서 발주자의 주관적인 판단에 맡긴다는 것은 엄청난 리스크이다. 그런 상태에서라면 계약을 하지 않는다. 대부분의 국내 발주자 같은 진상고객을 만나면 낭패다. 추가 비용만이 문제가 아니라 다음 프로젝트 일정도 망가지고 회사 계획이 엉망이 된다. 즉 결론은 납품할 제품이 검증을 통과할지 안할지를 개발자가 명확히 알 수 있는 내용이 있어야지만 계약이 성립된다. 그렇기 때문에 구체적으로 적힌 인수테스트를 통과하면 그냥 개발종료된 것이다. 발주자가 이의를 제기할 수가 없는 것이다. 발주자의 검증은 개발자가 자체적으로 인수 테스트를 수행할 때 옆에서 지켜보는 것으로 끝나기도 한다. 발주자가 인수테스트를 수행한다는 것은 똑같은 테스트를 두 번 하는 것으로 시간낭비이다.
그래서 개발자들은 발주자와는 대화 한번 없이도 약속한 날자에 인수테스트를 통과한 제품을 납품함으로써 끝난다. 발주자가 강심장이라면 납품일자까지 가만히 있다가 인수테스트를 통과했으면 끝난 것이고 아니면 소송해서 위약금을 받아내면 된다. 통상적으로는 리스크를 줄이기 위해 중간에 점검을 하지만 계약서가 바뀌는 것은 아니다. 이런 시나리오가 성립되려면 무엇이 필요할까 하는 것은 방법의 문제이다. 이 책의 이 부분 저 부분을 다 엮으면 방법이 나올 것이다. 이것이 바로 실리콘밸리 회사에서 개발이 진행되는 기본 원리이다. 먼저 이 원리를 확실히 이해하고 그 다음에 방법을 찾아가기 바란다. 방법까지 찾고 실행까지 할 수 있다면 개발역량 만큼은 글로벌 회사 수준이다. 생각을 도와주기 위한 시나리오를 준다면 다음과 같다.
1. 계약서에 사인을 하고는 나중에 결과물을 인수받을 때까지 서로 간에 얘기할 필요가 없다.
2. 그러려면 계약시에 납품 통과 기준을 인수테스트 목록으로 명확히 알려주어야 한다.
3. 인수테스트 목록만 패스하면 그 외에 아무리 오류가 많아도 그대로 제품을 인수 받아야 한다.
4. 개발자는 스스로 모든 인수테스트 목록이 통과할 때 까지 개발을 계속한다.
5. 약속한 날자에 제품과 인수테스트 결과보고서를 첨부해서 납품하면 끝이다.
6. 발주자가 검증한다는 것은 인수여부를 위해서가 아니라 자기들이 미처 생각하지 못한 것이 있나를 검증하는 것이다. 있다면 자기 잘못이다. 미리 계약때 포함시켰어야 한다.
7. 납품받으면 끝이다. 그 때 필요한 추가 기능이 생각나서 인간적으로 해주세요 빌어도 안 해준다. 잔금으로 협박하지 말고 깨끗이 추가 계약을 하는 수 밖에 없다. 한국식으로는 했다가는 소송걸려서 이자와 재판비용까지 물어야 한다.
8. 그럼 인수테스트를 그렇게 잘 적으려면 무엇이 필요할까? SRS가 필요하다.
9. SRS에는 인수테스트를 위한 기능목록은 기본이고 성능사양, 비기능 사양등 원하는 모든 것이 포함되어 있어야 한다.
10. 결국 SRS를 잘 적어야 한다. 보통 국내회사에서 생각하는 것과는 상상을 초월할 만큼 양이 많다.
11. SRS를 잘 적기 위해서 누가 적으며 어떻게 해야 잘 적을까? 이게 문제이다. 또 다시 제1원인에 도달했다.
여기까지는 쉽게 제1원인을 찾아서 올 수 있었으나 여기서부터가 문제다. 요약하자면 미국 회사와 인도회사는 한 쪽은 SRS와 인수테스트를 잘 적고 한 쪽은 내용이 충분한지 검토한 다음 계약을 한다는 것이다. 이 과정에서 인도 회사들은 SRS를 읽고 개발을 해주는 역량부터 기르기 시작해서 서당개 3년이면 풍월을 읇는다고 SRS를 적을 수 있는 역량도 서서히 생겨난 것이다. 이런 SRS를 템플릿이나 샘플보고 적는다고 생각하는 것은 국내 개발자들의 망상이다. 차라리 책보고 골프배우는 것이 훨씬 쉽다. 이것이 바로 소프트웨어 개발에서 가장 어렵다는 분석역량이라는 것이고 수 많은 경험이 필요한 것이다.
지금 이 시나리오는 모든 소프트웨어 개발의 가장 기본 원리를 설명한 것이다. 방법론이나 프로젝트의 종류에 따라 응용에 차이가 있을 지는 모르나 이것은 소프트웨어 회사라면 절대적으로 가져야 하는 역량이다. 이 역량이 없는 이상 영원히 소프트웨어 선진국이 될 수 없다. 예외 중의 하나는 연구 프로젝트이다. 연구 프로젝트는 어차피 결과에 대한 약속도 없이 버리는 돈이라고 생각하고 서로 상대방과 미래의 파트너가 될 수 있을까 하는 탐색전 정도이기 때문에 이 시나리오에는 해당되지 않는다. 국내에서는 대부분 제품 프로젝트를 연구 프로젝트처럼 진행한다.
국내회사 중에 영어 문제가 없다고 했을 때 인도에 외주를 줄 수 있는 회사가 있을까? 그럴 수 있는 회사는 없다 라고 말할 수 있다. 인도와 외주계약을 할 수 있는 역량이 없다면 내부프로젝트도 제대로 할 수 없다. 문서의 양의 차이이지 생각하는 방식은 똑같아야 한다. 망쳐도 소송만 걸리지 않는다 뿐이지 혼란스럽고 일정연기, 사양변경, 품질저하는 필연적이다. 결국 국내 소프트웨어 회사는 이런 외주 역량이 없이 한국말을 한다는 편리성과 약자인 을을 잔금이라는 치졸한 무기를 동원해서 마음대로 부릴 수 있다는 생각으로 엉터리 외주 혹은 내부 프로젝트를 진행한다. 미국과 인도의 계약에서는 갑도 없고 을도 없다. 계약서 대로만 수행하면 되는 것이다.
위에서 말한 외주 방식을 Turn-Key 방식이라고 한다. 반면에 그냥 개발자 몇 명이 필요해서 임시직원처럼 사용하는 Time-and-Material (시간제 임금) 방식으로도 원격으로 인도 인력을 사용할 수는 있다. 필자가 선호하는 방식이다. 이런 경우에도 당연히 SRS도 있어야 하고 인사관리도 해야 하고 업무배분도 해야하고 프로젝트 관리능력이 있어야 한다. 인도에다 Turn-key로 모든 것을 맡기기에는 역량은 없고 불안하니 리스크를 조금 줄이는 방식이다.
앞 부분에서 말한 대로 소프트웨어 개발방식은 어떤 특정한 문화나 어떤 민족성에 상관없이 최악의 상황에서도 개발할 수 있는 방식으로 진화되어 왔다. 인도나 중국사람들이 전세계 소프트웨어 업계에 가장 많은 개발자를 가질 수 있는 것은 인종이 훌륭해서가 아니라 실리콘밸리의 개발방식때문이다. 한국과 같이 인정이 많고 인간적인 유대관계로 서로 믿고 개발하다가 소송하는 방식으로는 절대 선진국이 될 수 없다. 아는 사람한테 일을 맡긴다고 대충하려면 하지 않는 것이 현명하다. 믿는 사람과 대충하는 것보다는 시스템으로 일을 할 수 있는 모르는 상대방이 훨씬 안전하다.
댓글 없음:
댓글 쓰기