IT조직을 방문하면서 늘 느끼는 것이 하나 있다. IT조직의 특성이나 크기에 상관없이 하나같이 IT프로세스가 동일하다는 것이다. 여기서 ‘동일’하다는 의미는 ‘표준’화의 의미가 아니라, IT조직의 ‘특색’이 없이 IT방법론을 ‘복사’ 한다는 것이다.
CMM과 같은 개발방법론이나 ITIL에서 제시하는 베스트 프랙티스들을 도입하는 과정에서, 해당 IT조직의 특성을 반영하기보다는 천편일률적으로 방법론이나 가이드의 틀을 그대로 옮겨놓고 있는 IT조직들을 발견할 수가 있다.
이런 IT조직들은, 사용하고 있는 IT프로세스에 ‘손대는’ 것을 두려워한다. 방법론이나 가이드에서 제시하고 있는 IT프로세스를 변경하면 큰일(?)나는 줄 안다. 경험에 의하면, IT조직들이 붕어빵 같은 IT프로세스를 갖게 되는 근본적인 이유는, 전체 IT방법론뿐만 아니라 방법론 내부의 개별 IT프로세스에 대한 ‘근본적인 이해’가 부족하기 때문이다.
■왜 그렇게 해야 하는가?
IT프로세스는 원래 그냥 그렇게 ‘생겨’먹은 것이 아니라, IT분야에서 오랫동안 실행을 해오면서 나름의 이유와 역사를 가진 것이다. 이것을 고맙게도 누군가가 잘 정리해준 것들이다. IT프로세스의 이유와 역사를 충분히 이해하지 못한다면, 이것들을 바꾸거나 응용해도 좋을지에 대한 ‘확신’이 부족할 수 밖에 없다.
왜 프로그램개발은 꼭 단위테스트, 사용자테스트, 통합테스트를 거쳐야 하는지, 왜 변경은 변경평가위원회(CAB, Change advisory board)를 거쳐야 하는지, 왜 장애는 사용자통지를 거쳐야 하는지 등에 대해서 한 번 따져본 적이 있는가?
IT프로세스와 IT프로세스내의 개별 활동들은 저마다의 필요 이유가 있으며, 만약 그 활동을 하지 않게 되면 부정적인 피해가 존재하기 마련이다.
■변경평가위원회의 도입 이유
예를 들면 변경평가위원회는 왜 생겼을까? 변경평가위원회는 변경에 관련된 다양한 이해당사자가 참여하여, 해당 변경이 IT에 미치는 영향을 사전에 평가하기 위해 만들어진 것이다.
변경평가위원회의 필요성을 착안해내기 전에는, 개별 변경 건에 대해 해당 구성요소의 담당자만이 변경에 대한 계획과 실행을 전담하였고, 그런 과정에서 다른 구성요소의 장애가 발생하는 경우가 빈번해서 이를 해결하기 위한 방법을 고민해오고 있었던 것이다.
변경평가위원회에 참여하는 이해당사자들은, 해당 변경이 몰고 올 자신의 구성요소와 관리영역에 대한 ‘영향’을 이야기하게 되고, 그 과정에서 변경의 주체는 그러한 영향을 최소화하기 위한 방법을 제시하게 되고, 그 방법이 받아들여지게 되면, 변경이 승인되는 것이다.
변경평가위원회의 도입 이유는 결국 변경프로세스의 중요한 목적인 사전 변경 영향 평가를 위한 것이므로, 변경평가위원회가 어떤 형태로 구성이 되던 간에 그 목적을 달성하기만 하면 된다.
■사소한 변경?
IT담당자들이 흔히 하는 질문중의 하나가, 사소한 변경도 모두 변경평가위원회를 거쳐야 하는가 이다. 그 답은 해도 되고 안 해도 된다 이다. 왜 그런가 하니, 만약 IT조직에서 변경평가위원회를 구성할 때 참여자를 상위 레벨의 관리자로 구성하였다고 한다면, 틀림없이 사소한 변경은 검토에서 홀대 받거나, 아예 검토 대상에 올라가지도 않을 가능성이 크다.
그러나, 변경평가위원회를 실용적인 측면으로 운영하기를 희망하거나, 적극적으로 모든 변경을 검토해보겠다는 의욕을 가진 IT조직들은 변경평가위원회의 구성에 실무자들을 포함하게 된다. 이런 경우는 사소한 변경조차도 변경평가위원회에서 다루어지게 된다.
상위 레벨의 관리자로 변경평가위원회를 구성하든, 실무자로 변경평가위원회를 구성하든 나름의 장단점이 있으며, 변경프로세스의 목적만 달성하게 된다면 문제가 없다. 그래서 IT담당자의 질문에 대해 ’사소한’ 변경이 무엇인가요 라며 다시 역 질문을 한다. 그리고 대부분의 장애는 사소한 변경이라고 지레 판단한 것에서 발생한 것이 많다는 것을 그간의 IT장애는 누누이 강조하고 있습니다 라는 말을 덧붙인다.
변경평가위원회가 존재하는가 또, 변경위원회가 어떤 변경들을 다루고 있는가도 중요한 사항이겠지만, 이보다 더 중요한 것은 변경평가위원회의 활동이 궁극적으로 변경프로세스의 목적을 유지할 수 있는 방법으로 운영되고 있는지를 확인하는 것이다.
■문제 프로세스의 사례
프로세스라는 것은 특정 결과를 얻기 위해 ‘분화’된 정형화된 활동들의 묶음이다. 분화되지 않거나 정형화되지 않은 활동들은 프로세스라고 부르기가 어렵다.
분화된 프로세스의 예로 ‘문제’프로세스를 들 수 있다. 과거의 장애프로세스 내에는 근본원인을 찾는 활동을 포함하고 있었지만, ITIL에서는 장애프로세스에서 근본원인을 찾는 활동을 덜어내서, 문제프로세스로 분화시켜 버렸다.
ITIL에서 이렇게 문제프로세스를 별도로 두게 된 이유는 두 가지다. 첫째 이유는 과거의 장애프로세스에 포함된 근본원인 조사 활동은 장애상황을 빨리 종료시키는 활동에 비해 그 실행이 저조하였기 때문이다. 대부분의 IT조직들이 장애상황이 종료되면, 근본원인 조사 활동도 흐지부지 종료시켜버리는 것을 반복하고 있었기 때문에 이 문제점을 해결하기 위해 분화시킨 것이다.
또 하나의 이유는 근본적인 조사활동을 좀더 체계적으로 진행할 필요가 있다고 판단한 것이다. 그냥 열심히 조사하는 것보다는, 하나의 문제로 ‘등록’을 하여 종류를 ‘분류’한 다음 조사를 ‘진행’하고, ‘완료’하는 라이프사이클을 가지도록 하는 것이 체계적이라는 것이다.
근본원인 조사 활동이 문제프로세스로 분화하게 되면서부터는, 문제에 대한 진척도(status)도 한 눈에 파악할 수 있어 장애활동에 비해 잘 진행되는 않는 문제 건들의 진행을 독려하기가 쉽게 되므로, 위에서 언급한 문제프로세스 도입의 첫째 이유도 동시에 만족시킬 수가 있게 되었다.
문제프로세스의 이러한 역사를 이해하고 있지 못한 IT조직은 문제관리프로세스를 어떻게 발전시킬 것인지, 아니면 어떤 방법으로 최적화할 수 있을 것인지에 대해 고민을 해 본적이 없다. 가이드나 툴에서 제시하고 있는 문제프로세스의 ‘샘플’들을 그냥 복사해서 쓰기만 하는 것이다.
■프로세스 목적을 알아야 ‘응용’을 할 수 있다
IT조직이 수행하고 있는 IT프로세스들은 지구상의 어느 누구도 그렇게 하라고 시킨 적이 없다. IT조직이 스스로 선택한 것이다. IT를 어떻게 운영해야 하는지를 전혀 모르거나, IT운영을 잘 할 수 있는 프로세스를 애타게 찾아온 IT조직에게는, IT 방법론이나 가이드가 제시하는 IT프로세스가 너무나 고마운 존재다.
그러나 IT프로세스의 고마움을 모른 채 사용하고 있는 IT조직은, IT프로세스에 별다른 감흥을 느끼지 못할 수밖에 없다. 이런 IT조직들은 IT프로세스의 목적에 관심이 없기 때문에, IT프로세스에서 정의하고 있는 활동들을 수동적인 입장에서 수행할 가능성이 크다.
수동적인 태도로 IT프로세스를 수행하는 IT조직들의 공통적인 특징은 IT프로세스가 ‘모방’에 머문다는 것이다. IT를 사용하는 사용자의 요구나, 비즈니스 변화 그리고 IT조직 자체의 개선 요구 등이 계속해서 IT프로세스의 변화를 요구하고 있음에도 불구하고, 수동적인 태도의 IT조직들은 기존의 IT프로세스가 방법론이나 가이드에서 근거한다는 이유로 이러한 변화 요구를 무시하거나 거부하고 있다.
그러나, 그보다 더 근저에 깔려있는 문제는 앞서 얘기한 것처럼, 이들 IT조직들이 IT프로세스의 도입이유와 목적을 잘 모르고 있다는 것이다. 그러다 보니, IT프로세스를 원하는 대로 변경해도 되는지에 대한 ‘확신’이 서지 않는 것이다.
IT프로세스의 목적을 명확하게 이해하고 좋은 사례들을 받아들인다면, 각자의 IT조직에 맞는 IT프로세스를 자신 있게 ‘창조’해낼 수 있다. IT프로세스에 대한 모방 단계를 넘어서서, 특화되고 독창적이면서도 원래의 목적을 달성할 수 있는 ‘IT프로세스 리엔지니어링’이, IT조직들의 일상화된 모습이 되는 시대가 빨리 오기를 기대해본다.
*본 칼럼 내용은 본지 편집방향과 다를 수 있습니다.
