차세대를 띄우면 외부에서 많은 용역 직원들이 들어와야 한다. 차세대기 때문에 OS, DB, ERP, 각종 유틸리티도 대부분 최신 버전이고, 그래서 어떤 때에는 우리나라에 전문가가 없어 외국 기술자를 불러와야 하는 일도 많다. 불러오는 것은 어쩔 수 없다고 쳐도 이들에게 한 달에 얼마나 지불해야 하는지 업계 사람들은 다 안다. 어떤 경우는 사정사정해서 모셔 오기조차 한다.
한국 기술자도 마찬가지다. 요즘에는 웹 기술자들이 상종가다. 특급이라고 왔는데 정말 특급인지 잘 모르는 때가 많다. 우선 처음 계약은 을과 하지만, 을도 자체 인력이 없어서 또 병과 계약하고, 병은 또 정과 계약하는 일이 발생한다. 누가 어느 회사 소속인지도 헷갈린다. 누가 어떤 기술을 갖고 있는지, 왜 무슨 일 때문에 프로젝트에 투입됐는지 잘 모른다. 그저 그 부분은 저 회사가 책임지고 있으니 그래서 저 사람 데려 왔겠거니 여기고, 한동안 일하다가 안 보이면 아 여기서 일 마치고 다른 사이트로 갔구나 추정할 따름이다. 이렇게 여기저기서 사람들을 불러 모으면 인력 관리, 계약 관리, 일정 관리, 품질 관리, 모두 어렵다. 더 골치 아픈 것은 여기저기서 기술자들이 들어오다 보니 회의가 많아질 수밖에 없다. 서로 용어가 다르고 경험한 업무 프로세스가 다르고 기반 기술이 다르다 보니 수시로 회의를 해서 어떤 일을 어떻게 해야 하는지 조정 해야 한다. 발주처에 경험 많은 프로젝트 매니저들이 많으면 자기가 맡은 부분을 꿰차고 이끌어 가지만 경험이 없으면 자기가 뭐 하는지 모르는 프로젝트 매니저들도 많다.
그러면 차세대 프로젝트를 어떻게 하면 성공시킬 수 있는가.
우선 CEO의 임기를 잘 볼 필요가 있다. 프로젝트 기간 중의 거버넌스 확립이 첫째 관건이다. 이 문제는 CEO 스스로 잘 판단해야 한다. 회사 어느 직원이 감히 CEO의 임기를 면전에서 언급하겠는가.
둘째는 업체 선정을 잘 해야 한다. 그게 하드웨어든 소프트웨어든 컨설팅이든 회사 명성만 보고 정해서는 안 된다. 제일 시장점유율이 높은 회사가 자기 회사에 제일 잘해 주는 것은 아니다. 실무자들은 제일 큰 회사를 선정해야 자기들이 나중에 편하다. 혹시 잘못 되더라도 업체를 잘못 선정했다는 지적을 받지는 않기 때문이다. 업체 이름을 보는 것이 아니라 실제로 누가 프로젝트에 투입될 것인지를 봐야 한다. 유사한 경험이 많은지 다른 사이트에서의 레퍼런스가 어떤지를 봐야 한다. 막연하게 세계에서 제일 잘나가는 큰 회사가 잘 알아서 해주겠지 하고 생각하면 안 된다. 영업을 잘하는 것과 프로젝트를 잘하는 것은 다르다.
셋째는 PMO 기능을 확실하게 챙겨야 한다. PMO가 뒤에서 관리하고 보조하는 것이 아니라 앞에서 끌어갈 수 있어야 한다. 프로젝트 담당 임원은 프로젝트 전체를 보고 각 프로젝트 관리 항목들의 연관관계를 머릿속에 그릴 줄 알아야 한다.
넷째는 현업 요구조건 수집에 너무 시간을 써서는 안 된다. 프로젝트 끝나고 자기가 그 기능을 요구했는지도 모르는 때가 많다. 현업에서 지금 핵심적이라고 주장하는 그 기능들도 2~3년 지나면 업무 자체가 없어지는 일이 많다. 프로젝트 끝나기도 전에 법규가 신설되고, 규제가 바뀌고, 업무가 바뀌는 것을 전제로 프로젝트를 해야 한다.
다섯째는 외부 인력관리를 잘해야 한다. 템플릿을 만들어 정확한 작업 지시서를 내려 주고 그 결과물을 챙겨야 한다. 프로젝트 요원이 100명을 넘어 가면 각자가 무슨 일을 하고 있는지 한눈에 안 들어온다. 사무실도 다르고 일하는 시간도 각기 다르기 때문에 작업관리가 치밀하지 않으면 곳곳에서 빈틈이 생긴다.
여섯째는 테스트를 잘해야 한다. 테스트 데이터, 테스트 시나리오, 테스터의 교육이 잘 준비 돼 있어야 한다. 테스트를 완료했다고 하고 사고치는 일도 많다. 테스트의 중요성은 아무리 강조해도 지나침이 없다. 일곱째는 현업 교육이 철저해야 한다. 운영계는 어쩔 수 없이 교육을 받겠지만 정보계에 대해서는 그냥 내용만 한번 듣고 마는 일이 많다. 차세대 시스템의 가치는 운영계보다는 정보계에서 나온다. 정보계 활용을 위해서는 현업 교육이 필수다.
여덟째는 유지보수 계획을 잘 챙겨야 한다. 시스템은 끊임없이 업그레이드하고 업그레이드해야 한다. 나중에 프로그래밍한 회사나 담당했던 개발 직원을 찾으러 다니는 사례를 많이 봤다.
현명해질 필요가 있다. 꼭 차세대라고 이름 붙이고 빅뱅으로 회사를 들었다 놨다 해야 하는 지 고민해 봐야 한다. 차세대 끝나고 각종 소송이 줄을 잇는 그런 프로젝트를 꼭 해야만 하는가. 시스템 로드맵 10년 계획을 짜고 큰 틀 안에서 차분히 그리고 꾸준하게 작은 프로젝트를 지속적으로 성공시키는 방안을 검토할 때다.
CIO포럼 회장 ktlee777@gmail.com