1.
창어4호가 달에 착륙했습니다. 아폴로11호가 착륙했던 곳이 아닌 뒷편입니다. 인류가 지구에 등장한 이후 현재까지 한번도 관찰하지 못한 ‘The Dark Side Of Moon’입니다. 보지 못해서 ‘토끼’가 산다거나 ‘히틀러’가 생존해 있거나 ‘외계인의 달기지’가 있거나 온갖 소문에 횡횡하였던 곳입니다. 허황된 상상이고 이번에 산산히 깨졌지만 여전히 달은 누군가가 소원을 빌 수 있는 곳으로 남아 있습니다. 그리고 낭만은 여전히 이어집니다.
세상에 존재하는 것이나 벌어지는 일들이 모두 밝은 면만 있지않습니다. 빛과 어두움이 같이 합니다만 우리는 의식적으로 한 부분만 바라봅니다. 편견입니다. 일부러 편견을 유포하는 경우도 있는데 대표적인 곳이 IT가 아닐까 합니다. 어려운 시절을 이겨내고 이제는 자리잡은 기업들, 예를 들어 네이버, 다음과 같은 곳은 빛이지만 SI와 같이 소프트웨어 개발공급을 하는 기업들은 어둠이 짖습니다. 단순히 어려움을 넘어서 영원한 어둠이랄 수 있는 죽음의 그림자가 드리웁니다. 2018년말 청와대 청원게시판에 올라왔던 내용입니다. 악명 높은 금융회사의 차세대프로젝트입니다.
산업은행 프로젝트는 기한 내에 끝내야 하는 빅뱅 방식을 고수했고, 쫓기고 쫓기는 중압감은 상상을 넘어선다고 설명했다. 수행사가 비용을 줄이기 위해 개발자를 쥐어짜고 수행사 수익은 개발자를 쥐어짠 결과물이라고 지적했다. 그러면서 (외주)개발자들은 스트레스에 공황장애, 뇌졸증, 심근경색 등 항상 위험에 노출되고, 과연 ‘이번 죽음의 개인의 죽음인가?’라고 되물었다.산업은행의 속칭 ‘반프리’ 인력채용도 문제가 있다고 지적했다. 이번 프로젝트는 하청업체 직원이 정규직이어야 하고, 사대보험 가입을 의무화했다고 밝혔다.산업은행은 프로젝트에 정규직만 들어 올 수 있는 규정을 만들었다고 설명했다. 결국 하청업체는 인력소개소 역할만 하고 아무런 책임을 지지 않는다.산업은행과 사업 총괄자인 SK C&C가 외주직원을 방배막이로 삼고, 책임을 지지 않아도 되는 ‘하청업체 정규직’을 만들었다고 하소연했다.
국민청원에 올라온 산업은행 차세대 외주개발자의 죽음중에서
2017년에도 비슷한 사건이 있었다고 합니다. 역시 시중은행의 차세대 프로젝트입니다.
최근 또 다른 금융그룹의 하청을 받은 중소기업 대표는 원청 업체의 부당한 요구와 폭언을 견디지 못해 스스로 목숨을 끊었다. 이 금융그룹은 차세대 전산 시스템 도입에 나섰지만 한 차례 공개 시점을 연기했다. 지난해 말에는 또 다른 중견 금융기업에서 프리랜서로 근무하던 IT 직원이 과도한 업무 스트레스와 개인사로 극단적인 선택을 했다.그러나 ICT 업계에선 이 같은 사실을 알면서도 애써 외면하고 있다. 일감을 받아야 하는 하청업체들로선 피해사실을 공론화하면 소위 ‘찍히기 때문에’ 시장에서 매장당할 것을 우려한다. 잇따른 비극적 소식에도 업체 관계자들이 쉬쉬하는 것도 이 때문이다.
[And 경제인사이드] ‘노예’ 대우에 극단적 선택… IT 하청업체 소리없는 아우성중에서
금융회사의 차세대프로젝트와 비슷한 지옥이 게임회사의 런칭입니다. 이 때문에 크런치모드가 인구회자했습니다.
게임개발자가 돌연사했다. 처음이 아니었다. 2016년 7월, 그리고 2016년 11월. 과로사로 추정됐다. 해당 게임업체는 “과로와 연관 지을 근거가 없다” “절대 과로사는 아니다”라고 못 박았지만, 사실 과로사 추정이 유별난 게 아닐 정도로 게임업계의 야근과 밤샘노동은 흔한 일이다.장시간 노동이 새로운 게 아님에도 불구하고 이렇게 갑작스럽게, 그리고 연달아 개발자들이 쓰러진 이유는 뭘까? 우리는 여기서 장시간 노동이라는 오래된 관행에 새로운 위험 요인이 더해지면서 발생한 사고라는 합리적 의심을 할 수 있다. 개발 환경의 변화가 어떻게 노동자의 건강 문제로 연결되는지 짚어봐야 하는 대목이다. 물론 잇단 사망사고를 예외적인 상황들의 우연한 연속으로 이해할 수도 있다. 그러나 우연적인 예외라 하더라도 노동자의 죽음 자체는 조직, 환경의 구조적 문제를 드러내는 상징적 징표가 된다. 또 망자의 연령대가 20~30대였다는 점, 사망사고가 여러 번 반복되었다는 점을 감안할 때 노동자들의 잇단 죽음에 구조적 문제들이 놓여 있음을 의심하는 건 자연스러운 일이다.통상적인 사망률에 비추어 봐도 우연이라고 넘기기에는 너무나 큰 사건이라는 지적을 눈여겨볼 필요가 있다. 뇌심혈관 질환에 의한 20~30대의 사망률이 10만 명 당 10명 미만인 것에 비해 위에서 언급한 사망 사건의 사망률은 10만 명 당 66.7명으로 매우 높기 때문이다(직원 3천 명을 10만 명으로 가정하고 사망률 추정).
크런치 모드 : 개발자들의 돌연사중에서
지옥같은 차세대프로젝트를 만든 이유가 무엇일까요? 공정기간과 가격의 불일치입니다. 적자를 탈피하려고 저가하청을 하고 작업자의 노동시간을 늘립니다. 처음에는 정시 퇴근하지만 20시에 퇴근하다가 22시에 퇴근하고, 다시 24를 넘깁니다. 어떤 때는 밤을 지새우기도 합니다.
이런 조건에서 차세대프로젝트의 결과물은 결함투성입니다. 2018년 여러번의 연기끝에 개통을 한 우리은행 차세대시스템은 개통이후에도 장애가 끊이지 않습니다. 품질이 목표에 부합하지 않습니다.
우리은행 차세대 전산시스템인 ‘위니(WINI)’는 지난 5월 개통 이후 잦은 장애 발생으로 고객 불편을 초래하고 있다. 추석 연휴를 하루 앞둔 지난 21일에는 오전 한때 온라인뱅킹 송금이 안돼 고객들의 원성을 샀다.우리은행은 차세대 전산시스템 구축을 위해 약 3000억원을 투입했다. 지난 2016년 3월 주사업자로 선정된 SKC&C와 우리은행의 전산 자회사인 우리FIS가 전산시스템 개발을 주도했다. 우리은행은 당초 올해 2월 차세대 전산시스템을 가동할 예정이었으나 시스템 불안으로 개통 시기를 3개월 연기했다. 그런데 지난 5월 가동 이후에도 전산장애가 자주 발생했다.우리은행 관계자는 “몇차례 오류가 발생한 이후 내부 감사까지 벌였는데, 전산장애가 계속 발생해 당혹스럽다”고 말했다.
금융당국, ‘잦은 전산장애’ 우리은행 경영실태평가 나선다중에서
2.
이런 경우가 한국에 국한된 현상이 아닌 듯 합니다. Tabb Forum에 실린 The Dirty Secret of Financial Technology은 이 점을 극명하게 보여줍니다. 기사의 첫 문장입니다.
The dirty secret of systems development in financial services and capital markets is that poor quality has become the norm. Late and overbudget delivery of new systems is the perennial experience of many, while a single word – “support” – summarizes the quality problem. How many finance directors have scratched their heads and asked, “What are they all doing?” when confronted with headcounts and budgets for support personnel? How many have received a convincing answer? Here is the honest answer: Support is just a euphemism for fixing it.
Support라는 말도 포장했지만 새로운 시스템의 고질적인 병폐가 품질이라고 합니다. 이 때 지원(Support)를 아래와 같이 해석합니다. 즉, 시스템을 개통한 이후 내부 및 외부 고객이 제기한 다양한 개선사항(결함을 포함)을 최초 요구사항을 정의할 때 누락된 기능(비기능 포함)목록으로 전환시키는 과정입니다. 이런 기능들은 핵심기능이 아니더라도 더 많은 비용과 시간이 필요합니다.
In this context, “support” does not mean the essential processes needed for real-time service delivery. Instead, it means the process of translating a multitude of complaints from internal and external customers about poor quality software (functionality, utility, and performance) into a list of items that either are missing and should have been there in the first place; or are in there but not working correctly. Low customer satisfaction is the outcome of this quality gap. Even when adding new functionality for new versions (a fundamentally worthwhile activity), support personnel can consume much more time and money than expected because of underlying quality problems with the system.
For the avoidance of doubt, “support” is not a cunning plan to extract more money in perpetuity from customers when the system is built by a third party, though that is how it turns out in reality. Rather, “support” has been allowed to become an industry norm. If everyone assumes – based on experience – that all systems will have to be fixed on an ongoing and permanent basis, then everyone behaves accordingly when planning, budgeting and building. But that is a mistaken assumption.
그러면 품질이 낮은 시스템을 개통(Production)하는 이유는 무엇일까요? 저자는 크게 네가지로 분석합니다.
첫째 철저하지 못하거나 허구의 인수시험( Weak or non-existent user and operational acceptance testing) 테스트 시나리오를 만들지만 형식적인 것이 많습니다. 그리고 둘째의 원인과 결합하여 충분한 시간이 주어지지 않습니다.
둘재 개인적으로 보면 가장 중요한 이유입니다. 정치적인 이유에 의한 납기일 준수(Political, competitive or egotistical drives for systems to go live on a certain date, no matter what) 프로젝트계약서를 작성할 때 개통일을 지정합니다. 개통일이 늦어지면 그에 따른 책임이 따릅니다. 이점은 수주사도 마찬가지입니다. 지연은 비용증가이기때문에 인사고과에서 낮은 점수로 이어집니다.
셋째 운영 및 개발 기술/경험의 부족이라고 하지만 한국의 경우 수주가에 맞춘 개발 및 운영팀 구성이 근본적인 원인입니다.(Lack of operational (service delivery) skills and experience in the development team. (Thank goodness for the DevOps movement, but it has a long way to go to be the norm and to have the power that it needs to say “no.”)
넷째 협업문화의 부재. (Poor communication among the development team and service delivery and infrastructure management organisations (see comment above about DevOps) 보통 개발을 발주 및 수주로 이해하지만 – 발주사 내부적으로 현업팀과 IT팀의 관계처럼 – 프로젝트의 관점에서 보면 틀립니다. 이해당사자들 모두의 프로젝트이고 이들의 소통이 프로젝트 성사에 무척이나 중요합니다.
저자는 마지막에 이렇게 가정을 합니다.
If you design systems well; adopt the right assumptions; employ people with the best attitudes, educations and motivations; measure quality in terms of customer satisfaction and whole-of-life cost; then solutions can be built on time, on budget and up to quality,
가능할까요? 한국에서는 비용과 시간때문에 불가능하다고 생각합니다. 최소한 금융회사에서는. 비단 한국만의 현상은 아닙니다. Delivering large-scale IT projects on time, on budget, and on value을 보면 대형프로젝트중 12%가 품질에서 심각한 결함을 가졌다고 합니다.
