제가 좋아하는 블로거이신 류한석님이 “한국에서 SW개발자가 성공하지 못한 이유“라는 글을 ZDNET Korea에 기고를 하셨네요…물론 저는 한번도 본 적이 없습니다. 그냥 글로만 접한 분이니까….
글중에 이런 부분이 있습니다.
첫 째, 업계 구조가 SI 중심으로 왜곡되어 있다. 국내의 소프트웨어 산업은 패키지나 솔루션 비즈니스가 제대로 작동되지 않는 상태에서, 대기업 중심의 SI 업체들이 시장을 차지하고 있다. 그 과정에서 산업의 혈액 순환이 잘 되지 않아, 대기업만 돈을?벌뿐 중소기업들은 협력 업체라는 미명 하에 근근이 먹고 살고 있는 형편이다. 통계에 따르면 전체 매출의 80% 이상을, 그리고?영업 이익의 90% 이상을 대기업 계열 SI 업체 상위 3개사가 가져가고 있다.
SI는 소프트웨어 산업을 구성하는 한 가지 요소일 뿐이지만 국내에서는 거의 SI 밖에 없는 수준이다. 그런 상태에서 빅3업체가?모든 것을 가져가고 있으며, 산업 전반에 하청 및 재하청에 따른 죽음의 순환 고리를 형성하고 있다. 그런 생태 구조에서 개발자는 단지 머리 수에 불과할 따름이다. 또한 전문적인 지식에 대한 가치 판단이 제대로 이루어지지 않고 있기 때문에, 소프트웨어?아키텍처까지도 비전문가에게 맡겨지는 경우가 많다.
SI 중심의 산업 구조, 그리고 전문가에 대한 평가 체계가 없고 단지 머리 수에 의해 개발자에 대한 판단이 이루어지는 상황에서?개발자의 성공 사례는 나올 수 없다. 대기업의 협력 업체에서 일하는 많은 개발자들이 과중한 업무로 인해 참다못해 전업을 하거나 건강이 나빠져서 자의반 타의반 일을 더 이상 할 수 없게 되곤 한다. 그러한 이유 때문에 많은 개발자들이 스스로를 막장?인생이라고 표현하고 있다.
100% 공감합니다. 왜 그럴까를 생각해 보았습니다. 저는 SI라는 것을 한국적인 상황이라고 인정하고 이 안에서 그리고 경영자의 입장에서? 원인을 먼저 찾고자 합니다.
첫째는 SW의 가치를 인정하지 않습니다.
일반적으로 SI 프로젝트를 수주할 때 공급자쪽에서 “구매소프트웨어” + “개발Framework” + “분석설계” + “개발자”등을 공급합니다. 그런데 구매소프트웨어라는 하는 것중 대부분이 외국 대형SW업체들의 소프트웨어 – DBMS나 WAS 혹은 미들웨어 등등 – 이어서 이부분은 100% 고객사에서 구매를 합니다. 문제는 개발Framework입니다. 보통 국내 금융기관의 경우 100% 패키지형태의 제품을 구매하기보다는 50%이상으로 최적화(?) – 제가 보기에 최적화라기 보다는 기업환경에 맞게끔 적용하는 수준에 머물르는 것이 아니라 화면등에서 고객사의 문화에 맞게끔 변화를 줍니다 – 를 요구합니다. 그래서 개발Framework의 도입이 중심이 아니라 그에 따른 Customizing개발자가 중심이 됩니다. 이 경우 개발 Framework에 대한 가치를 가격에 반영되어야 하는데 이부분은 항상 구매소프트웨어항목으로 처리되는 것이 아니라 그냥 인건비범위에 포함되어 발주처리됩니다.? 인건비산출도 투입인원과 투입기간에 따라 결정되기때문에 기업에선 개발Framework와 관련된 비용을 받을 방법이 없게 됩니다..(?) 따라서 공급자입장에선 나름대로의 노하우와 비용을 투입하여 개발한 개발Framework가 오직 가격경쟁력을 확보하는 수단외에는 사용할 방법이 없게 됩니다.
둘째 같은 이유로 Source Code를 요구합니다.
앞서 말했던 개발Framework를 제품으로 판단하는 것이 아니라 SI프로젝트의 산출물로 판단하기때문에 공급자는 소스코드를 발주처에 공급할 수 밖에 없고 이 때문에 유지보수와 관련된 추가매출을 기대하지 못하거나 아니면 아주 적게 기대할 수 밖에 없습니다. 물론 발주처입장에선 공급자의 규모때문에 파산에 대한 리스크를 관리할 필요성이 있습니다. 그렇다고 하면 Software Escrow제도를 이용하여 위험에 대비하는 것이 올바른 방법일 텐데 발주처가 협상력이 뒤진다는 이유로 당연히 Source Code를 요청합니다. 기업의 전산시스템에서 유지보수가 차지하는 비중이 작지않기때문에 이부분은 공급자에게 아주 많은 영향을 줍니다. 또한 금융기관의 경우 협력유지보수업체가 있기때문에 공급자쪽에서 유지보수매출을 기대하는 것은 어렵습니다.
셋째는 계약변경에 대한 적절한 보상이 이루어지지 않습니다.
현재 SI계약의 경우 토목건축과 관련된 관행을 따르고 있다고 들었습니다. 그런데 이미 토목이나 건축에선 설계변경이 발생할 경우 별도의 추가비용을 지불하는 것으로 알고 있습니다. 그런데 SW는 눈에 보이는 제품이 투입되지 않는다고 생각해서인지 대부분의 계약에 설계변경에 대한 부분이 빠져있거나 있더라도 발주처에 일방적으로 유리한 형태로 되어 있습니다. RFP 혹은 SOW에 기술되어 있는 부분에 요구사항을 명시하여도 그렇고 SOW상에 요구사항을 명확히 하고자 하여도 발주처의 준비부족으로 작성을 하지 못한 경우도 그렇고…프로젝트중반 혹은 끝에 새로운 요구사항이나 변경으로 나옵니다. 물론 아무런 추가비용없이….
넷째는 RFP등으로 표현되는 공급자의 요구사항이 사전적으로 명확히 준비되지 않습니다.
단적으로 프로젝트와 관련된 요구사항이 딱 한장 담긴 RFP를 받아본 적이 많습니다…그러면 결국 나머지는 공급자가 알아서 제안하라는 것입니다. 근데 문제는 예산은 이미 정해져 있다는 것입니다….”하고자 하는 업무”를 추상적으로 정리되었기때문에 당연히 프로젝트중에 많은 변화를 발생합니다. 다 비용입니다. 그런데 이미 예산은 정해졌고 그 예산보다 낮은 금액으로 보통 계약을 하기때문에 그 이후부터는 다 공급자손실입니다.
그런데 문제는 이런 생각을 하여도 변화시킬 수 있는 방법이 없다는 점이 아닐까 합니다…한국같은 좁은 나라에서 고객하고 위와 같은 문제로 분쟁이 발생하면 그것은 곧 “시장에서 퇴출”입니다. 그렇다고 그런 꼴을 보기 싫어서 다른 쪽을 기웃기웃 거려도 마땅히 수익모델을 만들 수 있는 것이 없거나 – 물론 저의 능력이겠죠 – 있어도 자본의 문제가 생깁니다. 울면 겨자먹기…혹은 목구멍이 포도청이죠…아니면 “중이 절이 싫으면 떠나라”는 말을 공급자쪽에서 하겠죠….
그래서 저같은 경우 해외와 공급계약을 체결할 때 최소 회사가 자체적으로 개발한 Framework 나 제품의 경우 소스공급이 포함된 계약을 체결하지 않습니다. 소스공급을 한다고 해서 그에 따른 적절한 비용을 받는 것도 아니기때문에 공급하지 않습니다. 그래서 대만의 모증권회사로부터 4년동안 유지보수 및 업그레이드와 관련된 매출을 지속적으로 올리고 있습니다.큰 돈은 아니라도….
