프로젝트 실패에 대하여
예전에 지인으로부터 통칭 한국의 SI(시스템통합)이라고 하는 프로젝트의 문제점이 무엇인가?라는 질문을 받은 적이 있다. 나는 그 구성원 중에 가장 말단인 데다가 실력도 그럭저럭인 그저 발에 채이는 개발자 역할로서만 참여한 터라 잘 모른다고 답을 드렸지만 방금 이 문제에 대해 생각해 보고 정리하고 싶어 순수하게 개인적인 입장에서 한번 정리해 본다. 브런치란 그게 가능한 곳이니깐
아직 한번도 만들어보지 않은 시스템에 대해서 가장 최적화된 계획으로 제안을 하는 업체 담당자는 (영업, 사업담당자) 는 실제 일을 하지 않는다. 하지만 제안시 최적화된 빠른 업무 빌드를 제안하지 않으면 계약이 안된다. 경쟁 업체도 동일한 조건에서 준비하기 때문이다.
이후에 제안이 채택되어 계약이 되면 일을 해줄 사람을 구해서 의자에 앉힌다. 계약서에는 사전에 인원을 다 준비하라고 하겠고 그 시점에 구두로 약속한 인원이 일부 있지만 그들은 이미 다른 일을 하고 있을 것이고, 아직 계약되지 않은 일에 대기를 시킬 수 있는 재산이 업체에게는 없다. 짧으면 몇달 길어지면 몇년이나 늘어지는데다가 자칫하면 입찰이 실패하는 위험부담을 업체는 감당할 수 가 없다. 바로 파산할게 뻔하니깐.
일이 시작된 이후에 일을 하기위해 들어온 사람은 이 일을 새로 접하는 사람들이 대부분이므로 최적화된 계획에 비해서는 아무래도 일정 지연과 이슈를 발생시킬 확율이 높다. 잘하는 사람으로 셋팅했겠지만 생각보다 시스템 구축에 필요한 기술 스펙은 학습 곡선이 긴 편이고 여러개를 사용하는데다가 프로젝트마다 약간씩 상이해서 그렇다.
물론 그렇게 발생되는 지연, 이슈나 생각하지 못했던 추가요구사항, 요구 누락 등등 문제가 수북이 쌓일텐데 이런 시스템구축시 발생되는 문제들은 당연이 노력,시간, 인력, 자원을 들이면 해결될 수 있는 것들이다. 하지만 프로젝트는 방금 언급한 노력, 시간, 인력(자금) 이 고정값이다. 보통은 일정이 지나고 오픈일이 가까워질수록 그 문제의 숫자나 심각도가 해소되지 않고 점점 많아지고 커진다. 프로젝트가 지연을 시작하면 해당 팀은 사전에 약속되어 정해진 일정 에 포위사냥당하는 사슴처럼 쫓기게 되며 점점 구성원들은 지치고 특정 임계점이 지나면 좀더 무리 할 수 있는 능력을 잃고 최소한의 일만 하는 조직으로 변신해 버린다.(추진 능력을 잃었다고 한다) 아직은 실패가 아니다. 해당 상태에서 특정 이벤트(높은 분에게 시연시 치명적인 업무 오류 발생 또는 특정 놀리기 좋은 오류가 sns나 기사가 나서 이슈화 되는 경우)를 경험하면서 모든 구성원들이 마음의 희망을 잃으면 실패에 한걸음 가까이 가게된다. 물론 아직도 실패하지 않았다. 마치 고백하지 않았지만 이미 거절의 의사를 인지한 사람처럼 마음을 접었을 뿐이다.
위의 경과는 많든 적든 발생하므로 계약업무 담당자(갑) 과 영업담당자(을)은 마지막에는 실패를 선언하기 보다는 타협점을 찾는 방향으로 나아간다. 상황은 모두 타버린 밀밭이나 이삭이 떨어진걸 주워서 모와오거나 완전하게 타지 않고 익은 밀알이 있다면 잘 키운것으로 취급해주는 것이다.
협상은 주로 지금까지 확인된 이슈나 추가요구를 시간을 좀더 들여 인력을 남겨서 또는 추가투입하여 해결해 주기로 하거나, 인력 몇을 안정화에 지원하도록 그렇게 합의를 하고(요새는 요구사항에 명시를 한다. 그리고 점점더 이 규모나 기간이 길어지는 추세다) 제품이 인도된다면 잘 끝난 프로젝트라 할 수 있으며 우리가 이야기할 주제인 실패 라는 단어를 달아주는 프로젝트 리스트에서 빠지게 된다. (대부분 프로젝트가 이렇게 된다.)
결국 대부분 프로젝트는 실패하지 않는다. 많은 실패라 생각했던 시스템은 골치 아픈 경험을 이겨내고 서비스 되고 있고 앞으로 더욱더 안정화 될 것이다.
각 구성원들은 다음과 같이 프로젝트에 대해서 입장을 가질것 같다.
고객들이 최초 요구사항을 이야기한 시점과 개발팀이 프로그램을 충분하게 동작하도록 작성하여 납품하는 시점은 작게는 몇 개월 길게는 몇 년의 시간 차이를 가진다. 이에 따라 고객의 시간에 따른 요구 변화는 합리적으로 여겨진다. 그렇다면 변화 수용에 따른 시간, 인력, 재화가 추가되어야 될것 같지만 위에서도 언급했지만 3가지 항목은 고정값이다. 고정값 이라는 것은 변화에 굉장히 취약하다는 것이다.
업체는 대부분 납품 실적이 있는 업체고 경험도 많고 성공사례도 가지고 있는 편이다. 이전에 이번에 계약한 시스템보다는 작은 규모의 경험을 가지고 있거나 메인 업체가 아닌 일부 인력을(이마저도 프리랜서로 구성하여) 책임졌을수도 있다. 하지만 계약 후 업체 담당자인 영업, 업체투자자 등은 투입인원의 숫자만을 보는 편이다. 기술이슈는 일정에 큰 영향을 미치는 건에 한하여 관리자에 의해 언급될 때만 관여할 수밖에 없을 것이다. 관리하는 프로젝트가 1개만 있는 게 아닐 것이므로. 그리고 여기도 건설처럼 하청 계약이 성행한다. 이를 위한 개선안이 발주 담당자 머리카락을 줄이면서(고민하면서) 계속 개선되어 추가될테지만 기존 실패 업체의 진입을 막지 못하고 신규업체의 진입만을 막을 용도로만 잘 쓰여진다. (물론 신규업체는 큰 규모의 계약을 잘 처리할 수 없을 가능성이 높긴하다)
관리자도 역시 투입인력숫자, 일정 등 금액에 관련된 항목에 대하여 열을 올릴 것이다. 이슈는 앞에 언급한 항목과 관련 있는 하위 항목일 뿐이다.
설계자는 보통 하나하나의 문서는 업무에 따라서 차이가 있겠지만 200-400 페이지 작성에 일주일 주면 많이 주는 편이다. 그정도 시간이면 초안을 급하게 때려넣고 맞춤법 검사하고 이후 보완 및 추가 작성이 지시되면 기계적으로 수정할 시간 정도 일 것이다. 이런 업무에 담당하는 인원들 상태도 확인해야하고, 수시로 업무 관련 수시 보고서도 작성하고 5일중 3일 정도는 회의로 보낼 가능성이 크다. 이런 상황에서 SI에서 제시하는 표준 문서의 참된 의미를 일일이 생각해서 입력해 개발단계까지 이어지도록 작성하는 열정이 있는 설계자는 많지 않아 보인다.
개발자는실제 제품을 만들어내는 포지션 이므로 중요하나, 이 부분도 큰 업체들은 경험치를 가지고 있어 이제 한명이 얼마나 개발 할지 양 측정이 가능하여 바쁘게 움직이고 설계서에 오류가 없고 설계자에게 궁금한점을 그때 그때 바로바로 해소할 수 있을때 아마도 하루 일정을 지킬 수 있을것으로 보인다. 부족한 점은 개인이 야근을 한다던지 해서 메꿔서 이슈를 막으려 들 것이지만. 그정도면 이슈가 아니다. 요구사항같은 개념이 규정집의 내용이나 설계 내용(개발 규격이므로 지켜야 된다) 과 많은 부분이 달라 판단을 여러개 받아야 할 때 개발자는 손을 멈추게 된다. 만들어도 다시 개발해야 할게 분명하므로.
