[칼럼]숨겨진(?) IT프로젝트들 - 최영석 . BSI코리아 심사위원 YoungSug.Choi@bsigroup.com 2009.10.29 / PM 06:22
[지디넷코리아]IT조직에서는 기존에 존재하지 않는 ‘어플리케이션’이나, ‘인프라’ 또는 이들의 복합체인 ‘시스템’이 새로 도입되는 경우를 ‘프로젝트’라고 부른다. 또는 금융권에서 수년 전부터 진행해 오고 있는 ‘차세대 전환’과 같이, 기존에 존재하는 어플리케이션, 인프라 또는 시스템이지만, 대규모 ‘개편’이 일어나는 것들도 ‘프로젝트’라고 부른다.
이러한 ‘프로젝트’의 대척점에는, 기존에 존재하는 어플리케이션, 인프라 또는 시스템의 가벼운 변경을 의미하는 ‘유지보수’가 존재한다.
하지만 IT조직들을 관찰하다보면, 프로젝트와 유지보수를 구분하는 기준이 모호하거나, 기준이 있다고 하더라도, IT품질이나 IT보안 관점에서는 치명적인 누락을 감수하고서라도 굳이 유지보수로 분류하고 있는 이상한 상황들을 자주 맞닥뜨리게 된다.
이번 칼럼에서는 IT조직내부의 이해관계에 따라 혼용되고 있는 프로젝트와 유지보수 아야기를 해 보겠다.
* 혼동을 방지하기 위해 IT인프라보다는 주로 어플리케이션 개발에 초점을 맞추어 이야기를 풀어보겠다.
■‘투자’ 유무에 따라 프로젝트?
새로운 비용이 추가되는 경우에만 프로젝트로 다루는 IT조직들이 있다.
‘기존’의 개발인력만으로는 사용자의 추가 개발 요구를 만족하지 못할 경우에는 외부의 IT자원을 투입해서 개발하게 된다. 이 경우에는 추가 투자가 발생하게 되므로, 내부적으로 기획부서와 재무부서를 통과하게 되는 투자품의 과정을 거치게 된다.
개발 부서 입장에서는 자체 부서내에서 진행하지 못하고 전사 부서의 결재 라인을 거쳐야 하므로, 이러한 개발을 ‘공식’적인 프로젝트의 형태로 진행할 수 밖에 없다.
반면에, 개발 요구에 대해 추가 투자 없이 내부 개발 인력만으로 진행이 가능하다고 한다면, 프로젝트가 아닌 ‘유지보수’로 대부분 처리하게 된다. 전사 부서의 결재 라인을 거치지 않기 때문에 이러한 개발건에 대해서는 IT조직 자체의 ‘관리하’에 둘 수 있게 된다.
아웃소싱을 자주 사용하는 IT조직에서 이러한 경향을 볼 수 있는데, 여기에서의 프로젝트와 유지보수의 정의는 결국 이렇다.
“프로젝트: 추가 투자가 발생하는 개발요청건, 유지보수: 자체 자원으로 처리가능한 개발요청건”
■물리적인 ‘규모’에 따라 프로젝트?
개발 요청건을 처리하기 위해 소요되는 물리적인 규모를 기준으로, 프로젝트를 결정하는 IT조직들도 많이 있다.
개발자 1명이 한 달 내내 해당 개발 요청건을 처리하게 된다면, 이를 1M/M(Man/Month)라고 부르고, 특정 M/M 규모 이상(예를 들면, 2M/M, 또는 3M/M)의 자원이 소요되는 개발 요청건을 프로젝트라고 정의하고 있다.
이 IT조직들은 개발요청건이 신규 어플리케이션인지 아닌지의 여부보다는, 자원 투입 규모에 따라 프로젝트 유무를 결정하게 된다. 이들의 용어정의는 다음과 같다.
“프로젝트: n M/M 이상의 자원이 소요되는 개발요청건, 유지보수: n M/M 이하의 자원이 소요되는 개발요청건”
■프로젝트의 존재이유
IT조직들내에서 조차 혼란스러운 프로젝트와 유지보수의 기준을 맞닥트릴 때마다, 프로젝트의 존재 이유를 생각하게 한다.
프로젝트는 왜 유지보수와 구분되어야 하는가? 누가 어떤 필요에 의해서 이처럼 다른 이름을 불러 주는 것일까? IT분야가 아닌 곳에서도 프로젝트라는 이름을 자주 사용한다. 건설 분야의 **단지 개발 프로젝트, 연구분야에서는 AA제품 개발 프로젝트 등이 그 예다.
이들 분야에서의 프로젝트들은 시작과 끝이 명료하다. 프로젝트의 자원을 투입한 결과로 새로운 단지가 조성되거나, AA제품의 시제품이 완성되는 것이다. 기존에 없던 것이 새로 생기거나, 기존에 있더라도 전폭적으로 바뀌게 되는 결과를 얻을 수 있다.
IT분야에서의 프로젝트를 동일한 관점으로 본다면, 프로젝트는 새로운 어플리케이션을 창조하게 하거나, 기존의 어플리케이션을 대폭적으로 변경하게 만드는 활동이라고 할 수 있다. IT분야의 ‘프로젝트’는 결국, 큰 변화를 성공적으로 운영하고 당초의 개발목적을 달성할 수 있도록 도와주는 유용한 도구라고 볼 수 있다.
여기에는 외부자원이 투입될 수도 있고 아닐수도 있으며, 또 규모가 클 수도 있고 상대적으로 작을 수도 있는 것이다.
■IT조직의 기피대상, 프로젝트
IT조직에서 근무해본 경험이 있는 사람들은 IT조직이 프로젝트를 기피하는 경향을 보인다는 것을 안다.
일단 개발건이 프로젝트로 결정되면, 해당 프로젝트에 포함된 사람들은 프로젝트의 까다로운 절차, 내외부 감리 및 많은 양의 산출물 등을 우선적으로 떠올리며 괴로워한다.
안그래도 프로젝트의 일정을 맞추려면, 밤을 세워도 모자랄 판에, 절차도 지켜야 하고, 내외부 감리도 신경써야 하며, 활동들의 대부분을 기록으로 남겨야 하니 프로젝트에 참여하는 개발 인력들은 개발건이 프로젝트로 선정되는 것을 좋아할리가 없다.
그러다보니 IT조직내에서 유지보수와 프로젝트를 ‘주체적’으로 수행하는 부서에서는 가능한한 개발건들이 프로젝트보다는 유지보수로 처리되기를 ‘희망’하는 것이다.
■유지보수에 숨겨진 프로젝트들
프로젝트가 없이 유지보수활동으로만 개발이 일어나고 있다고 주장하는 IT조직들에는 숨겨진 프로젝트들이 존재한다. 외부자원이 투입되는 경우에만 프로젝트로 결정하는 IT조직의 경우, ‘내부자원’이 투입되는 새로운 어플리케이션이나 대폭적인 변경건이 발생하는 경우가 있다.
특히 요즘처럼, IT경기가 어려운 시점에는 IT조직이나 사용자 조직에서 신규 투자가 동결되거나 긴축 모드로 운영되는 경우가 많다. 이런 경우 내부자원을 최대한 활용하라는 재무 지침에 따라, 모든 개발건들을 내부 개발 인력으로 처리하게 된다. 이때 추가 비용이 발생하지 않으므로, 모든 개발건들은 ‘유지보수’로 처리가 된다.
새로운 어플리케이션을 창조하거나 기존의 어플리케이션을 대폭적으로 변경하게 하는 개발건이라하더라도 추가 비용이 발생하지 않기 때문에 일상적인 유지보수로 다루어 지게 되는 것이다.
물리적인 규모로 프로젝트를 결정하는 IT조직의 경우도, 규모는 작지만 새로운 어플리케이션을 만드는 경우도 있으며, 큰 규모의 프로젝트를 쪼개서 여러개의 유지보수건으로 위장하는 경우도 있다.
■숨겨진 프로젝트의 문제점들
신규 어플리케이션의 도입이나 기존 어플리케이션의 대규모 변경을 반드시 프로젝트로 수행해야 하는가에는 여러가지 의견이 있을 수 있다. 만약 이러한 개발건들을 ‘유지보수’를 통해서도 성공적으로 완료할 수 있다면, 프로젝트로 수행하지 않는 것에 대한 비난에서 자유롭지 않을까?
하지만 현실은 그렇지않다. 유지보수로 완료된 숨겨진 프로젝트들의 ‘진행과정과 결과’들을 살펴보면, 부실 투성이인 경우가 대부분이다.
어플리케이션을 하나의 ‘제품’으로 본다면, 숨겨진 프로젝트로 만들어진 제품들은 불량률이 높다. 또 소비자 보호를 위해 필요한, 제품의 ‘안전기능’에 해당하는 어플리케이션의 ‘보안기능’도 고려가 되지않았거나, 고려되었다 하더라도 제대로 작동하지 않는 경우가 많다. 이것은 IT조직의 유지보수 활동이 프로젝트 활동을 대신하기에는 무리가 있다는 반증이며, 숨겨진 프로젝트가 많이 존재하는 IT조직일 수록 이러한 경향이 더 크다는 것을 경험으로 느끼고 있다.
■유연한 프로젝트의 도입 필요
개발과 관련하여 ‘무겁고 유일한’ 프로젝트방법론을 가지고 있는 IT조직들의 공통점은 스스로 약속한 방법론의 덫에 걸려 있다. 모든 프로젝트에 대해서 높은 수준의 성숙도 모델을 적용하기로 천명한 IT조직들이, 유연성 없는 유일의 방법론을 무거운 방법으로 고수하겠다고 약속하게 된다면, 숨겨진 프로젝트의 함정은 언제나 존재하게 되어 있다.
프로젝트의 개별 산출물에 집중하기 보다는, 프로젝트를 통해서 달성해야 하는 ‘원칙과 목적’을 이해하고 이를 중요시하게 된다면, 프로젝트의 성격과 크기에 맞는 유연한 프로젝트 방법론을 창조해낼 수 있을 것이라고 본다.
형을 형이라 부르지 못하는 ‘호형호부의 한’은, 프로젝트를 프로젝트라고 부르지 못하는 IT조직들에게도 존재하고 있다. 프로젝트는 프로젝트로 부르는 것을 이제 그만 허락하도록 하자.
Posted by 홍반장
