‘IT시스템’이 탄생하게 되는 과정은 ‘제품’이 탄생하는 과정과 유사하다.
제품의 경우, 고객의 요구에 따라 연구 개발부서를 통해 시제품을 개발하고 테스트를 거친 후, 다수의 고객들에게 본격적으로 공급하기 위한 ‘양산 체제’로 전환이 된다.
IT시스템의 경우, 비즈니스나 사용자의 요구에 따라 IT시스템의 필요성이 대두되고, IT개발 프로젝트를 통해 설계, 개발 및 테스트를 거친 후, 다수의 IT사용자들에게 IT시스템을 본격적으로 제공하기 위한 ‘운영 환경’으로 전환이 된다.
제품이 ‘양산 체제’로 전환되기 전에 반드시 거쳐야 하는 일들이 있다. ‘양산’을 위한 설비체계와 생산 조직을 확보하고, 제품에 대한 상세한 스펙을 확정하게 된다. 양산 체제에서는 확정된 스펙이 변경될 경우 매우 엄격한 변경관리 과정을 거치도록 하고 있다.
IT시스템도 ‘운영 환경’으로 전환이 되기 전에 운영 부서가 주도가 되는 인수(acceptance)라는 과정을 거치고 있다. 인수과정을 거친 후 제품과 마찬가지로 엄격한 변경프로세스를 유지하게 된다.
그러나 국내 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시스템의 변경이 통제되지 않는다는 점이다.
사용자들이 IT시스템을 사용하기 시작하면 약간의 시행착오를 거쳐 점차 익숙해져 가게 된다. 그런데 프로젝트의 많은 변경들은 사용자들의 익숙함을 일거에 날려버린다. 이러한 변경들은 사용자에게 특별한 ‘통지’(notification)가 없이 진행되므로, 사용자들의 불만을 증폭시킨다.
■표준에서 제시하는 전환을 위한 준비활동들
하나의 IT시스템이 프로젝트에서 운영으로 전환된다는 것은, 사용자와 IT조직 모두에게 중요한 사건이다.
따라서 IT조직들은 사용자를 위해서도, 내부의 운영담당자들을 위해서도 전환에 필요한 ‘준비활동’들을 운영 전에 완료해야 한다.
IT서비스 표준인 ISO20000과 ITIL에서는, 이러한 준비활동에 대한 가이드를 제시하고 있다. 사용자를 위한 준비 활동으로는, 사용자 ‘대표’와 서비스수준협약(SLA, Service Level Agreement)을 협의하는 것과, 일반 사용자들을 위한 서비스 카탈로그(Service Catalogue)를 준비하는 것을 권고하고 있다.
서비스수준협약과 서비스 카탈로그에는 해당 IT시스템의 서비스 수준 목표, 중요도, 장애복구목표시간, 재해 시 복구 목표시간, 업무부하특성과 사용자의 문의 및 요청사항을 대응하는 서비스데스크에 대한 내용들이 포함된다.
특히 서비스 카탈로그는, 서비스가 개시되는 IT시스템에 대한 정보를, 일반사용자들의 입장에서 쉽고 간결하게 기술한, 일종의 상품목록이므로 일반사용자들을 위한 매우 유용한 서비스 팁으로 제시하고 있다.
또 운영담당자를 위한 준비활동으로는, IT시스템의 모든 구성항목과 연관관계를 구성관리데이터베이스(CMDB)에 등록하여, 운영상의 모든 프로세스가 이 정보를 즉각 활용할 수 있도록 보장하는 것을 권고하고 있다.
■준비활동 이전에 갖추어야 하는 전제조건들
표준이나 가이드에서 제시하는 것들이 언뜻 보면 평면적인 요구사항인 것처럼 보이지만, 그 내용을 구체적으로 이해하게 된다면, 적용이 그리 쉽지만은 않은 내용들이다.
사용자를 위한 준비 활동은 사용자 대응을 위한 ‘서비스’ 마인드가 기본 장착이 되어야 가능하고, 운영담당자를 위한 준비 활동은 기존 운영프로세스들이 구성관리데이터베이스를 중심으로 견고하게 운영되고 있어야 가능하다.
‘운영’중인 IT시스템조차 사용자들을 잘 이해하고 있지 못하고 있거나, 운영 프로세스가 잘 지켜지지 않는 IT조직의 경우는, 굳이 프로젝트에서 운영으로의 전환을 고민할 필요가 없다. 운영중인 IT시스템을 어떻게 잘 다룰 것인지에 대해 우선 집중하라는 얘기다. 운영에 대해 어느 정도 확신이 든 이후에 전환에 대한 준비활동을 고민하는 것이 맞는 순서다.
근래에 발표된 ITIL V3에서는, ‘프로젝트 초기 단계’부터 서비스 준비 활동을 반영해야 한다는 서비스라이프사이클 개념을 도입하였다. 프로젝트에서 운영으로 전환하는 단계보다 훨씬 앞 단에서 준비활동을 하라는 것이다. 결국 IT 수준을 높이고 싶은 IT조직은, 다음의 순서를 잘 이해하라고 하고 싶다.
‘운영’의 서비스 고도화->’프로젝트, 운영’간의 서비스 고도화 ->’프로젝트를 포함한 서비스 라이프사이클’ 전 단계의 서비스 고도화
좋은 개념들을 빨리 도입한다고 당장에 그 수준이 달성되는 것이 아니다. 당장에 ITIL V3의 수준을 달성하고 싶은 IT조직들이 있겠지만, 순서대로 진행하기를 권하고 싶다.
*본 칼럼 내용은 본지 편집방향과 다를 수 있습니다.
