SI프로젝트에서의 위험률 관리

"SI프로젝트의 성공"은 적절한 인력과 자원으로 계획된 일정을 모두 소화하여 고객이 원하는 결과 시스템을 구축해 내는 것이다.
하지만, 개발자 개인에게는 조금 다른 성공의 의미가 부여되어야만 한다.
고객사는 언제라도 업체와의 거래를 끊을 수 있다. 개발자도 언젠가 다니던 회사를 나오게 될 수 있다. 대부분이 그렇다. 개발자 입장에서의 "SI프로젝트의 성공"을 생각해 보아야 한다.
개발자에게  SI프로젝트 성공 기준의 첫번째는 "성취감"이다. 그 밖에, 좋은 사람들을 만나고, 많은 것을 배우고, 새로운 경험을 얻고, 강제에 의한 야근 같은 한심한 행동을 하지 않으며 지냈다면 그 프로젝트는 개발자에게 있어 성공적이었다고 말할 수 있다. 물론, 이런 모든 것을 한번에 얻을 수 있는 프로젝트는 거의 없다.

'사람들과 트러블이 많았지만, 내가 생각하는 모든 것을 했다.'
'매일 야근을 해야하는 상황이었지만, 좋은 사람들과 즐거웠다.'
라는 식으로, 성공의 지표 가운데 하나라도 얻을 수 있으면 그나마 다행인 상황이다.

개발 본연의 업무 외적인 부분에서 힘들어하는 개발자들이 자신의 주위를 둘러보고, 자기가 처한 위험과 팀이 처한 위험을 이해하여, 각자의 상황을 보다 나은 방향으로 이끌고, 자신을 지켜낼 수 있기를 바라며, 개발자로서의 지속가능성을 높힐 수 있기를 바라며, 모두가 위험률을 산정하기를 바란다. 처음에는 지나치게 높게 책정된 위험률도 있겠지만, 우리는 어차피 내일을 알지 못한다. 단지, 내일은 오늘보다 나은 모습이 되어 있어야 한다는 것을 다짐할 뿐이다.

이 글에서 표현하는 위험률은 "자원 확보율 대비 업무량"을 의미한다. 굳이 "위험률"이라는 표현으로 시선을 끌어보려는 이유는 프로젝트 기간 내내 위험률의 변화를 포괄적으로 지켜보지 않게 되는 경우 80%까지 원만하게 진행되던 프로젝트가 어느 순간 부터는 재자리 걸음을 하게 되는 상황이 벌어질 수 있다는 것에 대한 경각심을 고취 시키기 위함이다.

위험률은 경제 원리에 따라 최소의 비용으로 최대의 효과를 얻으려는 고객과 개발업체 간에 있어, 자신에게 좀 더 많은 이익이 되도록 하기위해, 계약을 체결하는 상황에서 처음으로 발생하게 된다. 많은 SI프로젝트가 모든 스펙이 정확하게 확정된 상태에서 계약이 이루어지지 않는다. 기능, 성능, UI, 동작 등에 있어 업무량은 줄어들수도 있고, 늘어나게 될수도 있다. 물론 기술적인 부분에 있어서 생산성과 예상 할 수 있는 성능 이슈를 최대한 해결하는 방법으로 업무량을 줄일수도 있다. 개발 업체의 입장에서는 기술적으로 실질적인 업무량을 줄이는 방법을 고려하지 않고 공수를 산정하여 이 때의 위험률을 100%으로 하여 계약을 하는 것이 바람직하다. 이러한 방식은 대체로 가시화 된 자료를 고객에게 제시할 수 있어, 대략적인 금액으로 견적을 보낸 경쟁 업체에 비해 신뢰도 면에서의 경쟁력을 얻기도 한다. 하지만, 신뢰도를 높혀도 금액이라는 경쟁력 확보의 필요성도 여전히 남아 있게 된다. 이 때 고객은 네고를 요구하게 된다. 이제 최대 20% 수준에서 네고가 진행된다. 물론, 고객은 차기 프로젝트, 지속적인 협력관계, 또는 공동 개발을 미끼로 더욱 많은 네고를 요구하게 된다. 이 때 개발업체가 당장의 계약에서 금전적인 이익을 확보하겠다고 결정을 내렸다면 20% 이상의 네고는 벌어지지 않는다. 하지만, 고객이 던진 미끼에 더 큰 가치 비중을 둔다면, 그 이상의 네고나 공동개발로 계약을 진행하게 된다.

40%의 네고를 하고도 개발업체가 금전적인 이익을 얻게되는 경우는 많이 있다. 문제는 그 과정에서 터무니 없이 부족한 인력 배치, 현실을 무시한 기간 단축이 요구된다는 것이다. 검증되지 않은 인력, 근거 없는 기간 단축은 프로젝트의 성패를 개발자의 노력으로 충당하려는 행위라 할 수 있다. 분석과 설계에 80%의 노력을 기울여야 하고, 개발에 80%의 기간을 할애해야 하는 바람직한 SI프로젝트의 모습은 이미 망가지고, 개발이 진행되며, 잘못된 분석은 추가적인 요구사항을 만들어내고, 잦은 설계 변경을 발생시키고, 이미 개발된 모듈을 변경된 설계에 맞춰 재개발하게 되는 일이 벌어지게 된다. 그러다 어떻게든 80%의 완성도를 보이는 시점엔 설계를 변경할수도, 요구사항을 수용할수도 없는 상황이 벌어지고, 이후의 프로젝트는 제자리를 맴돌게 된다.

분석, 설계 및 요구사항 정의를 위해 필요한 4명의 선임 개발자가 1개월 간 선행 작업을 진행하고, 이들을 포함한 총 8명의 개발자가 4개월 간 UI 및 프로세스를 개발해야 하는 프로젝트에서 40%의 네고가 발생하면 선임개발자 2명에 후임 개발자 4명이 프로젝트를 진행하게 된다. 기간은 총 5개월에서 4개월로 단축된다. 위험률은 160%가 되었고, 60%의 요구사항을 반려하지 못한다면 프로젝트는 산으로 갈 것이다. 분석, 설계 기간은 2주로 단축되고, 충분하지 않은 분석 자료에 의해 설계된 아키텍쳐를 가지고 UI와 프로세스 개발이 시작된다. 4M/M가 필요한 분석, 설계를 1M/M로 처리하려다 보니, 오후 8시에 잡히는 고객과의 비지니스 회의에는 지친 몸으로 참여하게 되고, 고객사 업무 담당자들도 퇴근 시간이 지나 참여한 회의에 무성의하게 참여하게 된다. 하지만, 고객이 제공한 정보에 무언가 부족한 정보가 있다고 해도 다시 회의를 소집할 시간은 만들어지지 않는다.

위와 같이 근거 없는 네고만이 아니라, 가능한한 많은 비용 절감을 바라는 회사의 입장은 계약과 무관하게 작용하기도 한다. 일부 SI업체는 필요한 공수를 산정하고 비용을 추정하여 계약과 무관하게 프로젝트 비용을 할당한다.
소요 예상 경비 총액 2억5천만원안에 프로젝트를 완수한다. 회사가 어떤 이익을 얻는지에 대해서는 프로젝트에서는 관심을 두지 않는다. 이 금액에서 예산이 남으면 리더의 기여도로 넣는 경우도 있고, 팀원들에게 인센티브가 지급되는 경우도 있지만, 이러한 제도에도 불합리한 부분이 있어 아무런 보상 없이 회사의 이익으로 남는 경우도 있다. 이러한 경우는 리더가 재량적으로 추가적인 업무를 진행하여 잔여 비용을 소진하는 경우도 있다.

하지만, 대부분의 SI프로젝트에서는 계약된 금액에 비하여 일정 비율을 프로젝트 비용으로 산정한다. 아니, 산정 자체가 없는 경우가 대부분이다. 추가 인력이 필요하다고 하면 안된다는 결론을 내린다. 그래서 프로젝트가 진행되지 않는다는 것을 보여주면 2주가 지난 후에 추가 인력을 배치하도록 허가가 나고, 또 한 주가 지나야 추가 인력이 투입된다. 회사는 3주의 시간 비용을 아꼈지만, 초반에 방향이 결정되는 프로젝트에 있어서는 3개월 이상의 비용을 낭비한 것이나 다름이 없다.

충분한 비용을 지불하고 역할을 일임하려는 노력보다는 최소의 비용으로 책임을 전가하려는 노력이 자본주의적 합리주의로 받아들여지는 사회에서 이는 우리가 헤쳐나가야 할 또 하나의 난관임에 틀림 없다.

물론, 위와 같은 상황이 아니더라도 위험률이 높은 프로젝트는 어디에나 있다.
레거시를 포함한 요구사항 분석의 어려움, 충분한 검증을 거치지 않은 기술 도입, 팀이라 부를 수 없는 프로젝트 팀의 조직문화, SI에 적합하지 않은 성향의 개발인력 배치, 프로젝트 관리 및 리더쉽의 부재로 인해 위험률이 높아지는 것은 우리가 언제나 고민하고 관심있게 지켜봐야 할 대상이다.

어떠한 이유로든 위험률이 변화되는 추이를 놓히지 말아야 한다. 150%에서 출발한 프로젝트를 100%수준으로 끌어내리며 마무리할수도 있고, 80%로 출발한 프로젝트가 200%까지 올라가며 Drop 직전에 참여한 몇몇 개발자에 의해 120%로 마무리 되며 20%의 잔여 업무를 유지보수로 넘기는 경우도 있다. 위험률이 80% 미만이면 리더를 포함한 팀원들의 마음이 해이해지거나 개발자 간에 경쟁이 생겨나는 경향이 있다. 자신의 컨디션을 관리하지 않는 팀원, 다른 팀원과 경쟁하는 팀원을 관심있게 지켜봐야 하는 상황이 벌어지는 것이다. 위험률이 120%를 넘으면 어떤 개발자는 자신에게 책임이 돌아오지 않게 노력하는 경향을 보이기도 한다. 위험률이 140%까지 높아질 동안 업무에 소극적이고, 모르쇠로 일관하던 팀원이 위험률이 110%로 낮아지자 그제서야 프로젝트에 적극적으로 참여하는 모습을 봐야 하는 것은 결코 즐거운 경험이 아니다.

이렇듯 위험률은 누구나가 알면서도 간과하는 경향이 뚜렷하다. 위험률이 100%을 넘지 않는 수준에서 조직문화를 바람직하게 이끌 수 있는 범위로 위험률을 관리한다면 SI프로젝트는 결코 어렵지 않다. 그러다 보면, 위험률이 150%인 프로젝트를 만나도 프로젝트 기간 내내 위험률을 조금씩 낮춰가는 성취감을 만끽하며 원만하게 프로젝트를 마무리 할 수 있는 때도 올 것이다.

이렇듯 위험률은 누구나가 알면서도 간과하는 경향이 뚜렷하다. 위험률이 100%을 넘지 않는 수준에서 조직문화를 바람직하게 이끌 수 있는 범위로 위험률을 관리한다면 SI프로젝트는 결코 어렵지 않다. 그러다 보면, 위험률이 150%인 프로젝트를 만나도 프로젝트 기간 내내 위험률을 조금씩 낮춰가는 성취감을 만끽하며 원만하게 프로젝트를 마무리 할 수 있는 때도 올 것이다.

감당할 수 있는 수준의 위험률을 유지시킬 수 있다면 고객과의 지속가능성은 물론, 팀의 지속가능성도 확보 할 수 있을 것이다. 위험률이 낮아지는 것을 고객이 알게 되면 보여주기 위한 야근도 하게 된다. 이 때 위험률을 높혀서라도 의미 없는 야근을 막지 못한다면 이후 위험률의 관리는 불가능하게 될수도 있다.

지나온 길을 돌아보아 나아갈 길을 예측하는 것이 지속가능성을 확보하기 위한 한가지 방법이 될 수 있다. SI프로젝트의 지표로서, 추상적으로라도 위험률 추이를 지켜보는 것이 우리의 지속가능성을 확보하는 방법이라는 것을 생각해 보아야 할 것이다.

개발자 개인으로서도 자신과 팀의 위험률을 살펴야 한다. 자신의 위험률이 지나치게 낮고, 동료 개발자의 위험률이 지나치게 높을 때 아무런 행동을 취하지 않는다는 것은 스스로의 지속가능성을 포기한 행동으로, 동료 개발자가 처한 어려움은 머지 않아 자신에게 닥칠 위험이라는 것을 알고 동료 개발자, 인접한 팀의 어려움을 함께 해결해 나가려는 모습이 필요하다.