2005년도 초반에 본 글입니다.
해외영업을 한다고 일본,대만,중국,싱가포르를 가보았지만 한국의 SW개발자처럼 고객에게 푸대접을 받는 경우는 많이 보지 못했습니다. 예전의 직원들이 하는 말.”와전 노가다취급하네요” 그렇죠 그분들 시각으로는 코딩을 하는 사람으로 보이니까? 90년대에는 그렇지 않았는데 2000년대가 되면서 완전히 노가다보다 못한 취급을 받는게 SI프로젝트를 하는 SW개발자의 처지입니다. 문제의 시작은 인터넷버블이 있었고 IMF를 탈출하려고 일자리를 만들어야 했던 DJ 정권의 정책에서 기인하는 바가 큽니다. 아무나 재교육을 시키면 SW개발자가 될 수 있다고 생각했고 사람들에게 SW개발자를 그런 시간으로 보게끔 만들었던 정책…물론 SW개발내부에 산업발전단계에 맞게끔 업무를 분화하고 표준화하고 고도화하는 내부의 노력도 있지만…
어찌되었든 많은 SW개발자들이 업계를 떠나고 있습니다. 특히 금융SW업계를 떠나고 있습니다. 제품을 인정하지 않고 모든 것을 SI라는 이름으로 인력파견을 받아서 개발해야 하고 그러면서 사생활을 없고 개인성장도 없는 그런 금융 SW업게를 …..
왜 SI 프로젝트는 지식 노동자를 불러 노동 집약적으로 일하는 것일까?
원고 청탁을 받고 필자는 상당히 고민을 하지 않을 수 없었다. 많은 훌륭한 IT 산업 종사자들이 필자의 붓놀림에 매도당하지나 않을까 하는 걱정이 들었기 때문이다.
그 럼에도 불구하고 과감히 글을 쓰게 된 것은 대형 SI 프로젝트에서 발생하는 어제 오늘의 현상들을 보면 기업의 비즈니스를 시스템화한다고 하면서 일련의 프로젝트 수행 방식은 너무도 비시스템적이고, 비합리적이고, 비상식적인 수준이라는 생각에서다. 이제 대형 SI 프로젝트에서 발생하는 문제점을 조목조목 따져 보고자 한다.
어느 시기부터인지 정확히 말할 수는 없지만 IT 업계에 아웃소싱이라는 용어가 사용되기 시작했고 지금은 보편화되어 있다. 아웃소싱을 하는 가장 주된 이유를 든다면 전문가의 참여, 시간 절약, 이를 통한 비용 절감 등을 꼽을 수 있을 것이다.
프로젝트 조직 구성은 몇 점입니까?
필 자가 IT 업계에 발을 들여 놓은 지 십몇 년의 세월이 흘렀지만 아직도 SI(System Integration) 프로젝트의 첫 번째 성공 요소는 업무에 정통한 현업 사용자의 참여다. 물론 IT 업계에 종사하는 사람이 해당 비즈니스 영역에서 10년 넘게 새로운 기술로 프로젝트를 계속 수행해 온 컨설턴트라면 예외가 될 수도 있겠지만, 프로젝트 조직을 구성하는 시점에서 발주처는 프로젝트 비용을 제공하는 회사이므로 프로젝트 수주처는 발주처의 감정을 상하면 이득이 될 것이 하나도 없기에 발주처가 이것저것 하자는 데로 끌려가는 경향이 상당히 있다.또한 프로젝트를 수주하는 업체의 입장에서는 경쟁사를 제치고 프로젝트를 수주하기 위해서 물불을 가리지 않고 모든 것을 다 해줄 수 있는 것처럼 고객에게 접근하는 경우가 비일비재하다.
상 황이 이렇다 보니 프로젝트 조직을 구성하는 데 있어서 고객사의 업무 전문가들을 프로젝트에 참여시키는 일이 험난한 경우가 다반사다. 특히 현업의 업무 전문가들은 현재의 업무를 수행하는 데 있어서도 핵심 요원들이기 때문에 중장기적으로 이루어지는 프로젝트에 현업 전문가를 참여시키기에는 많은 어려움이 있다.
SI 프로젝트는 독자들이 다 아는 바와 같이 고객사의 업무 수행에 도움을 주기 위해 컴퓨터라는 도구를 사용하여 정보 시스템을 구축하는 것이다. 정보 공학의 아버지라 불리는 제임스 마틴(James Martin)은 그의 저서에서 프로그래머가 프로그래밍 언어를 잘못 사용하여 밤을 새면서 프로그램 코딩을 하는 경우는 5～10%도 채 안 된다고 말하고 있다. 프로그래머가 밤을 새는 이유는 대부분이 구축하고자 하는 시스템의 대상 업무를 잘못 파악해 프로그램을 수정하는 것이라 하고 있다.
분석을 하여 데이터 모델이나 프로세스 모델을 만드는 목적 중에 가장 중요한 것은 비용 절감이다. 시스템을 구축한 후 테스트하고 문제를 발견하여 고친다면 비용이 초과될 뿐만 아니라 적기에 납품을 못해 고객사의 업무 차질 등 많은 비용을 치러야만 하는 일이 발생할 것이다. 이러한 비효율을 없애고자 모델링을 하고 그 모델을 가지고 시뮬레이션을 하여 문제점을 발견해 미리 대처하고자 하는 것이다
프로그램이 제대로 만들어졌는지 구축 후 테스트를 하는 과정에서 어차피 많은 현업 요원이 값이 맞는지에 대해 테스트할 것을 차라리 분석 과정에서 업무를 미리 제대로 설명해 주면 구축 후 프로그램을 고치는 많은 수고를 덜 수 있지 않겠는가. 매일 밤새는 프로그래머와 이야기를 해봤자 나오는 것은 눈덩이처럼 불어나는 사후 관리 비용이다.
프로젝트를 처음 만들어 가는 과정에서 현업 요원이 확보되어야 한다는 당위성을 충분히 인식시키고 그러한 사람들을 반드시 확보해야만 프로젝트 성공 요소 중 충분조건은 아니더라도 필요조건 중의 가장 중요한 하나를 확보하는 것이니 많은 SI를 하는 업체들은 이를 충분히 고려했으면 하는 바람이다.
프로젝트 관리자의 역할은?
이 해를 돕고자 프로젝트 관리자의 역할을 다른 곳에서 찾아본다면 아마도 오케스트라 지휘자와 비슷하지 않을까 하는 생각이 든다. 오케스트라 지휘자는 청중(고객)이 원하는 바를 위해 단원들이 자신의 역할을 제대로 할 수 있도록 끊임없이 훈련하고, 관리하고, 지휘한다. 가장 중요한 것은 팀원들이 각자의 소리를 내면서도 이것이 지휘자의 역량에 의하여 가장 훌륭한 화음을 내어 청중을 감동시킨다는 것이다. 왜 필자의 주변에는 프로젝트가 끝난 후 감동을 받았다는 고객이 없는 것일까?현실의 프로젝트를 살펴보면, 일단 지휘자의 악보에 해당하는 것들을 제대로 읽을 줄 아는 프로젝트 관리자가 부족하다. 그저 팀원들에게 명령하고, 보고받고, 그것을 고객에게 보고하는 수준 정도다. 오케스트라의 지휘자는 단원들 개개인의 특성과 악기의 특성, 악보의 정확한 해독을 통해 훌륭한 화음을 생산해 낸다. 이와 마찬가지로 프로젝트 관리자도 프로젝트의 정확한 목표 의식, 이 목표 의식의 팀원과의 공유, 팀원 개개인의 특성, 프로젝트시 사용하는 하드웨어나 소프트웨어에 대한 해박한 지식, 인적 자원, 고객 관리, 리스크 관리 등 많은 부분을 제대로 알고 프로젝트를 진행해야 한다.
하지만 현실의 프로젝트 관리자들을 보면 대부분 일정 시점이 지나면 기술적인 측면에서 떠나 행정적인 측면만을 관리하다 보니 프로젝트를 관리하는 데 있어서 상당히 프로답지 않은 면면을 볼 수 있다.
내일은 어디로 모실까요?
필 자가 본 최악의 경우는 여러 가지가 있었다. 프로젝트 관리자가 프로젝트는 관리하지 않고 고객의 비위를 맞추기 위해 허구한 날 고객과 술자리를 같이 하는 경우도 있었으며, 데이터 모델링을 하는 데 수신 2일, 여신 3일, 외환 3일 이런 식으로 일정을 잡는 관리자와도 프로젝트를 같이 한 적이 있었고, 프로젝트를 수주한 업체가 다른 업체와 협업으로 프로젝트를 수행하면서 발주처에 자기들이 잘 모르고 있다는 모습을 보이기 싫어 절대로 발주처(갑)와는 직접 접촉하는 것을 금하는 프로젝트도 수행한 적이 있다.대 부분의 대형 업체와 함께 프로젝트를 수행하는 중소 규모의 업체들 또한 자기들을 부른 업체를 무시할 수 없으므로 거의 아무 소리도 내지 못하고 프로젝트 관리자가 하라는 데로만 프로젝트를 수행하니 아무리 잘못된 사항이 눈에 보이더라도 말을 할 수 없는 분위기를 프로젝트 관리자가 만들어 가는 경우가 많다.
요즘 수행되는 대부분의 프로젝트는 과거처럼 한 회사가 수주해 수행하는 경우는 거의 없다. 여러 업체가 협업으로 수행하게 되는데 이러한 구조에서 가장 중요한 사항은 열린 마음이다. 서로가 서로의 필요에 의해 전문가라는 사람들을 불러서 쓰는 것인데 이러한 전문가들끼리 마음이 닫혀 있으니 배가 산으로 갈 수밖에 없다. 자신의 의사가 소통되는 것이 아니라 일방적으로 하달 지시되는 답답한 프로젝트 상황에서는 본인이 아무리 능력을 발휘하고 싶더라도 한계가 있다.
필자의 편견일지 몰라도 SI를 수행하는 대기업 직원들보다는 중소업체 직원들이 오히려 강호의 세계에서 갈고 닦아 기술적으로 상당한 사람을 많이 보아 왔다. 이러한 상황에서 프로젝트 관리자는 주종 관계의 낡은 사고방식을 버리고, 진정한 계약 관계에서 여러 사람의 의견을 반영하면서 합리적인 판단을 한다면 좀 더 즐겁고 보람차게 팀원들이 프로젝트를 진행할 수 있을 것이다. 이상하게도 대형 프로젝트는 지식 노동자들을 불러 모아 왜 노동 집약적으로 일을 하는지 도저히 이해가 가지 않는 부분이 많다.
프로젝트 팀원들의 역할은?
필자가 프로젝트를 수행하면서 ‘현재 구축하고자 하는 시스템이 진정으로 나의 일이다, 즉 고객의 일이 나의 일’이라고 여기면서 일을 수행하는 프로젝트 팀원들을 본 경우도 거의 없다. 이유야 어쨌든 이러한 현상이 발생하지 않도록 발주처와 수주처의 프로젝트 관리자들은 팀원의 마음가짐부터 바꿔야 하지 않을까.사람이 사람을 보는 눈은 거의 비슷비슷한 것 같다. 어느 팀원이 훌륭하다고 해서 보면 진짜 훌륭하고 남들도 다 그렇게 생각한다. 여러 사람으로부터 이러한 신뢰를 구축하는 것은 그 프로젝트뿐만 아니라 자신이 세상을 살아가는 데 있어서 무형의 어마어마한 자산이 될 것이다. 그러한 직원들을 보면 고객이 원하는 것이 무엇인지를 정확히 파악하여 자신의 모든 기술을 이용하여 고객의 문제점을 해결하려고 노력한다.
이런 팀원이 있는가 하면 본인이 기술적인 부분을 좀 안다고 고객을 무시하고, 프로젝트를 같이 진행하는 다른 회사 직원을 무시하고, 조그마한 문제가 생기기만 하면 서로 책임을 전가하는 등 도저히 상식적으로 이해할 수 없는 일이 종종 발생한다.
물론 세상에는 무시를 당할만한 고객도 있고 협력사 직원도 있다. 하지만 모든 프로젝트 팀원들이 다 잘 할 수만은 없는 것이 또한 현실인 것을 독자들도 잘 알 것이다. 앞에서 말한 바와 같이 프로젝트 팀원들도 또한 열린 마음을 가지고 상대방을 대해야지 서로 남의 탓만 하면 프로젝트가 잘 될 리 없는 것 또한 명약관화할 것이다.
사실 프로젝트에서 탁월한 능력을 가진 사람들은 그리 많지 않다. 자신이 탁월한 능력을 가지지 못했다면 다른 팀원들에게 피해는 주지 말아야 할 것을 다른 사람의 발목을 잡는 경우가 비일비재하다. 하지만 팀원들에게 무슨 죄가 있겠는가? 프로젝트 관리자들이 진정으로 제 역할을 해준다면 이러한 문제도 상당히 해소될 것으로 생각한다.
프로젝트 발주처가 사라진 이유
경 영학의 대부인 피터 드러커 교수의 말을 빌리면 CEO가 자기가 보고 싶은 정보가 무엇이라고 얘기해야 하는데 그저 CIO에게 내가 의사 결정을 하는 데 도움이 되는 시스템을 만들어 달라고 한다는 것이다. 이러한 노 대학자도 CEO와 CIO의 역할을 정확히 구분하고 있는데 우리의 프로젝트에서 보면 이러한 발주처는 상당히 찾아보기 힘든 것 같다.분명히 정보 시스템을 구축하는 목적과 방향은 업무 효율을 높이기 위해서인데 발주처가 업무를 설명해 주려는 노력은 하지 않고 그저 전산 전문가에게 너희들이 전문가이니, 너희들에게 용역비를 제공했으니 알아서 시스템을 잘 구축하라는 것이다. 필자는 도대체 이러한 사고방식을 발주처가 가지게 된 이유가 무엇인지 아무리 생각해 봐도 이해할 수 없다.
물론 앞에서도 얘기한 대로 현업의 업무 전문가는 현재의 일을 수행하는 데 있어서도 필수 요원이기 때문에 프로젝트에 전적으로 참여하기가 힘들겠지만 나중에 시스템을 사용해야 하는 사람이 사용할 시스템에 대해 ‘이러이러한 사항이 이랬다면 좋겠다’하는 요구사항을 구체적으로 내놓지 않고 일단 프로그래머들이 개발하고 나면 그때부터 이래라 저래라 하는 경우가 비일비재하니 도대체 프로젝트를 하자는 것인지 사람 불러다 놓고 스트레스 테스트하는 것인지 이해할 수 없는 경우가 너무도 많다. 심한 경우 전산을 한다는 것이 심지어 과거에 무슨 잘못을 했기에 발주처 직원들에게 이리도 설움을 당해야 하나 하는 경우도 허다하니 심히 안타까운 마음을 금할 수가 없다.
시스템과 프로젝트는 그것을 구성하는 요소요소가 유기적으로 결합하여 이루어질 때만 원활하게 진행되고 훌륭한 결과를 낳을 수 있는 것이다. 협업을 제대로 해도 기간 내에 목표를 달성하기가 어려운 것이 SI 프로젝트인데 용역비를 제공한다는 그 이유 하나만으로 사람 위에 군림하여 자기 본분을 망각하고 문제가 발생하면 오로지 수주 업체에 지체 보상금을 물리는 이러한 관행은 빨리 시정되어야 한다고 본다.
이러한 문제 또한 누구나 알고 있는 사항이면서 고쳐지지 않아 결국은 피해를 보는 것이 발주처인데 아주 좁은 마음으로 프로젝트를 진행하니 이 또한 안타까운 마음을 금할 수 없다. 결과적으로 프로젝트에 문제가 생겨 손해를 보게 된다면 여기서 가장 많은 손해를 보는 것은 발주처라 할 수 있을 것이다.
프로젝트 접근 방식(방법론)의 문제
초 창기 컴퓨터가 사용되기 시작한 곳은 국방이나 연구소였다. 이곳에서는 대량의 데이터를 다루는 것이 아니라 계산 알고리즘이 중요하게 여겨졌다. 이러한 컴퓨터를 기업이 사용하면서, 즉 대량의 데이터를 다루면서 문제가 된 점이 중복된 데이터에 의한 유지 보수의 과중, 시스템 통합의 한계, 생산성 저하 등을 들 수 있다.많은 학자들이 이러한 점을 개선하려고 했고 처음에 나온 방법론이 1970～80년대 풍미했던 구조적 방법론이다. 이것은 기본적으로 기업의 프로세스를 구조적으로 파악하여 앞에서 말한 문제점을 해결하고자 하는 것이다. 하지만 이러한 방법론이 한계를 가져 또 다시 개선하고자 한 것이 데이터를 중심으로 기업 업무를 파악하는 방법론으로 80년대 후반부터 시작하여 현재까지 사용되고 있다.
하지만 아직도 대형 SI 프로젝트에 들어가 보면 구조적 방법론에 익숙한 사람이 많이 남아 있다. 관계형 데이터베이스에 대한 정확한 개념 없이 과거의 파일 시스템 사고에 젖어 새로운 시스템을 구축하면서도 과거의 방법론을 그대로 적용하거나 현재의 방법론을 사용하면서도 데이터베이스 구축은 과거 파일 시스템처럼 여전히 중복된 데이터를 많이 가져가는(많이 개선됐지만) 경향이 대형 프로젝트에 비일비재하게 발생하는 현상이라 할 수 있다.
물론 현재는 프로젝트에서 대부분 이것보다 한 단계 진보한 오브젝트 또는 CBD(Component Based Development) 방법론을 사용하고 있지만 데이터베이스는 관계형 데이터베이스를 사용하고 있는 것이 현실이라 하겠다. 이 오브젝트 개발 방법론도 기본적으로 프로세스(use case)를 먼저 파악하는 것으로 반드시 고려해야 할 사항이 데이터 중복을 어떻게 피하는가라 할 수 있겠다.
대형 프로젝트의 수주처는 대부분 대형 SI 업체들이다. 지금은 많이 바뀌고 있지만 아직도 데이터의 중요성을 모르는 곳이 많다. 물론 프로세스도 중요하다. 프로젝트 방법론을 잘못 적용하여 중복된 데이터로 인한 정보의 적시성, 정확성 등에 상당한 영향을 미치고 있다.
데이터는 한 곳에 있으면서 여러 기능에서 이 데이터를 가져다 사용하는 특성을 가지고 있다. 그런데 프로세스 접근 방식으로 하다 보면 데이터의 정의나 알고리즘을 모든 프로그램에 정의하는 경향이 있다. 이런 식으로 접근하다 보면 문제가 생길 수 있다.
각각의 프로세스에 데이터 항목을 정의했는데 이 정의가 고객과의 협의 과정에서 잘못된 것을 알고 고치게 됐다고 가정해 보자. 그러면 얼마나 많은 부분에 이것을 정의해 놓았는지부터 파악이 안 된다. 자연히 고쳐야 할 부분을 고치지 못하게 되고 데이터 정합성이 깨지는 것이다.
또한 데이터 명칭으로 이음동의어 내지 동음이의어를 사용하게 되어 데이터에 대한 표준을 잡기도 너무 어려운 부분이 있다. 프로그래머는 데이터를 입력·수정·조회하는 데이터의 바다를 항해하는 사람이라 할 수 있다. 입력 프로그램 소스의 대부분은 데이터를 검증(정확성 체크)하여 데이터베이스에 값을 집어넣는 것이다. 많은 사람이 생각하고 있는 프로그램의 로직이라는 것이 실은 데이터의 값이 정확한지를 체크하고 이를 조회하는 것이지 대단한 로직이 들어가는 것은 아니다.
단순 노동의 내성을 언제까지 키울 것인가?
필 자가 살고 있는 아파트에는 지하 주차장이 없어 매일 주차 전쟁을 벌이곤 한다. 이런 상황에서도 아파트 주차장에는 화재 발생시를 대비해 소방차가 들어갈 수 있는 통로와 지정된 주차 공간이 확보되어 있다. 이 공간은 아무리 주차 공간이 부족해도 경비 아저씨의 따가운 소리를 듣기 싫어서인지 텅 비어 있다. 그런데 어느 날부터 이 공간에 차가 주차된 모습이 눈에 띄었고, 이제는 주차 공간과 구분이 되지 않고 있다. 이유는 경비 아저씨가 바뀌면서 눈 감고 넘어가는 태도 때문이었다.대형 SI 프로젝트가 많은 문제가 있다는 점은 누구나 알고 있을 것 같다. 하지만 대부분 눈 한번 질끈 감고 넘어간다. 당신이 눈 한번 질끈 감을 때 마다 단순 노동의 내성은 점점 강해질 것이다. @
