ITSM에서 기술적인 운영과 전술적인 부분을 담당한다면, IT통제 영역에선 주로 전략적인 부분을 담당하고 있다. 이 모델을 라이프사이클(lifecycle) 시각으로 접근하면 <그림 2>와 같다. IT 수요(demand)에서부터 시작하여 이를 처리하는 일련의 프로세스들의 상호동작과 흐름, 분기 등을 거쳐 IT서비스, 애플리케이션 공급(supply)까지를 유기적인 흐름으로 인지해서 이를 라이프사이클 측면에서 관리하고 있다.
IT 라이프사이클 접근(Lifecycle Approach)
IT 라이프사이클 접근의 전체 프로세스를 간단하게 설명하면 이렇다.
? IT에 대한 수요(demand)는 크게 전략적인 투자(strategic initiative)와 일일 운영 요청(day-to-day activity)으로 나눌 수 있다. 전략적 투자란 프로젝트를 예로 들 수 있다. IT에 대한 모든 종류의 요청은 수요 관리(Demand Management)를 통해 취합되고 관리된다. 기존의 헬프데스크가 일일 운영 요청에 대한 부분만을 주로 담당하고 있는데 반해 수요 관리는 IT에 대한 모든 수요들이 거치는 입구라고 할 수 있다. 이로써 IT 수요에 대해 정확한 인지를 할 수 있게 되며 이는 IT 라이프 사이클의 시작점이 된다.
? 아이디는 제안 단계를 거쳐 프로젝트 발주가 되는 과정 중 각 단계별로 그 타당성과 기대 효과, 리스크에 대해 다각적인 검토를 받게 된다. 각 유관 부서에서 단계별 분석을 통해서 단계별 승인을 하고 이에 대한 근거를 남기게 되고, 또한 이 자체가 프로세스화/시스템화된다. 각 단계별 승인 단계에서 발생한 결과들은 위원회 또는 의사결정자가 최종 결정을 하게 되는데 근거 자료가 되며, 최종 승인이 되면 프로젝트가 발주된다.
? 발주된 프로젝트는 리소스와 일정, 비용을 관리하면서 성공적인 결과물을 낼 수 있게 지속적으로 관리된다.
? 이제 개발 부서에서 개발 프로세스에 따라 애플리케이션을 개발하게 되며, QA 부서(Quality Assurance)에서의 부하, 성능 테스트 프로세스를 거쳐서 통과되고 나면, 서비스 시작 여부(Go/No-Go)에 대한 판단을 거쳐서 서비스가 시작된다.
? 운영 부서에서는 비즈니스 관점의 SLA를 통해 IT서비스 수준을 합의 수준 이상으로 유지할 수 있도록 관리한다. 이를 위해 장애, 성능, 구성 관리 등의 프로세스를 수행하게 되며, 개선 조치 및 주기적인 결과 분석을 통해 서비스 수준의 유지 및 개선을 목표로 관리된다. 이로써 전략적인 투자 성격의 IT 수요(demand)에 대해서 애플리케이션 또는 IT 서비스의 형태로 공급(demand)되기까지의 라이프사이클이 발생하게 되는데 이 일반적인 라이프사이클 형태를 시스템화하고 프로세스를 연결함으로써 IT통제와 IT관리가 통합되는 것이다.
? IT 수요의 또 다른 종류인 일일 운영 요청은 일상적으로 IT 운영 상 수행되는 활동들로써 버그 수정, 소프트웨어 업그레이드, 또는 서비스데스크 등을 통한 사용자의 요청 등을 들 수 있다.
이에 대해 접수를 하고, 개발/QA 등 각 유관 부서에서 프로세스화된 개선/조치 활동을 하게 되고 이에 대한 검증이 완료되면 적용을 하고 다시 운영상에서 모니터링 하는 사이클로 연결된다. 이 과정들을 통해 IT 수요의 또 다른 형태인 일일 운영 요청에 대해 개선 및 조치라는 방법으로 원활한 IT서비스를 공급하게 된다. 이 수요와 공급까지의 과정들은 프로세스, 기술(프로덕트), 사람 등의 상호작용으로 동작하게 되는 데 라이프사이클 접근 모델을 통해 프로세스들과 활동(activity)들을 유기적으로 연계시키고 시스템화함으로써 IT통제와 관리라는 두 가지 목적을 자연스럽게 통합할 수 있다.
통합 모델의 핵심·가시성
기업 입장에서 보면 IT부서는 현업의 IT에 대한 수요에 대해, 요청된 서비스나 제품을 원하는 시간 내에 예상 비용 내에서 공급하면 된다. 이런 본질적인 부서 기능을 효율적으로 수행하기 위해서는, IT와 비즈니스뿐만 아니라 IT 부서내의 각 기능 조직들 간에도 그 목적(objective)과 프로세스가 서로 연계(alignment)되어야 한다.
각 기능 부서들에서 개별적으로 진행한 프로젝트나 기술(프로덕트)의 도입이 운영 단계에서 흐지부지 소멸되는 경우도 전반적인 연계와 가시성의 부재라는 시각으로 접근해야 할 필요성이 있다. 그런 측면에서 보면 프로젝트 또는 기술의 도입, 발주 계획 및 검토 역시 가시성을 지닌 라이프 사이클 접근 방식에서 처음(수요)부터 끝(공급)까지 다루어지고 진행되어야 한다.
서비스 업종의 예를 들어 레스토랑으로 설명해보자. 메뉴의 기획에서 개발, 생산, 출시, (또는 서비스 개시) 모니터링, 리뷰, 수정 등의 단계로 생각할 때, 양질의 서비스와 맛을 위해서는 전체 프로세스에 대해 가시성이 있어야 하고 각 단계는 서로 유기적이어야 한다. 실효성 없는 메뉴가 기획될 확률도 낮지만, 그렇더라고 빨리 고객 반응을 반영해서 개선 조치를 (예를 들어, 더 나은 메뉴 개발)를 내놓기 마련이다. 이는 전 프로세스가 하나의 라이프사이클처럼 유기적으로 연결되어 있고, 전체에 대한 가시성을 가지기가 쉽기 때문이다.
주방장이나 매니져를 포함한 직원들은 고객 (비즈니스) 중심적인 시각으로 무장되어 있고, 그 반응이나 결과를 주방이나 홀에서 실시간으로 직접 빨리 확인할 수 있기 때문에 경쟁력 있는 조직이 되는 것이다.
논리로 보면 IT도 별반 다르지 않다. IT 부서가 레스토랑이라면 고객은 현업과 엔드유저가 되는 것이다. 그런데 실제 IT에서는, 별로 매상에 도움이 되지 않는 엉뚱한 메뉴가 자꾸 기획하고 개발한다든가, 고객만족도를 모니터링 하는 방식이 지극히 수동적이고 경영주 또는 고객 입장에서는 현실감이 없다든가 하는 일들이 자꾸 발생하는 점들이 IT와 레스토랑의 차이점이라고 할 수 있다.
그 이유들의 대부분은 IT가 상대적으로 복잡하고 조직이 크고 복잡한 프로세스로 연결되어 있어서 가시성을 가지기 어렵기 때문이며, IT가 기능적인 부서 중심이지, 고객 중심의 시각이 아니기 때문이다.
실제로 IT 운영을 하다가 성능 상의 장애를 조치한다고 할 때 대부분 운영 부서의 일로만 생각하고, 신속한 해결에 주안점을 두고 있으나, 실제 프로세스 상으로 보면 개발 부서와 변경 관리, 서비스 담당자 등이 모두 연결되어 있고, 그렇기 때문에 프로세스 기반의 유기적인 공조 하에서만 관리의 효율성을 높일 수 있다. <그림 3>과 같이 변경 관리 프로세스 및 유관 조직 예시를 보면 이런 연결 고리가 명확하게 나타난다.
IT 서비스 장애 인지를 운영 팀에서 발견하고 이에 대한 조치를 서비스데스크 팀과 공조하게 된다. 이관된 문제의 원인파악을 위해 레벨 1 지원 팀의 1차적인 분류와 지원을 거쳐서, 레벨 2 지원 팀(해당 전문가 팀)을 통해 원인 파악이 끝나면 원인 변경을 위해 RFC(Request for Change)를 요청하게 된다. 이 승인은 변경승인 관리자의 검토와 판단에 따라서 결정된다.
변경승인 관리자는 구성 요소들간의 영향과 상관관계를 분석해서 승인을 하게 되면 이 요청은 개발팀(또는 애플리케이션 지원 팀)으로 전송된다.
테스트 환경에서 개발과 QA를 거쳐서 승인이 되면 다시 한 번 변경관리에 대한 최종 승인을 받고, 그 후에 프로덕션에 적용된다. 적용된 후의 결과를 비교하여 개선 사항을 취합 정리하고 다시 정상적인 운영 서비스로 전환된다. 이처럼 단순한 성능 장애를 조치하는 데도 복잡하고 많은 유관 부서가 개입되는 데, 이때 IT 수요와 공급에 대한 전 과정이 언제 어디서나 한 화면에 상황을 파악하고 진행시킬 수 있는 가시성을 가지게 된다면 각 과정에서 발생 가능한 오류나 시행착오 등을 획기적으로 감소시킬 수 있다.
여기서 시스템의 역할은 각각의 다른 유관 부서들간의 복잡한 역할과 책임(Role and Responsibility), 프로세스들을 시행착오 없이 신속하게 하며 기술적인, 기능적인 요구 사항들을 자동화 또는 지원함으로써 효율성을 높이는 역할을 하게 된다. 마치 경쟁력 있는 레스토랑의 유기적인 라이프사이클을 그대로 적용할 수 있는 것이다.
그 점이 IT통제와 관리의 통합 모델이 주는 장점이라고 할 수 있다. 즉, 복잡한 프로세스와 조직 간의 가시성을 확보함으로써 투자비용의 중복과 비효율성을 제거할 수 있는 기반뿐 아니라, 앞으로 어떤 일을 해야 할지, 어떻게 일을 해야 할지에 대해 올바로 판단할 수 있는 보편타당한 기준들을 마련할 수 있다는 점이다.
프로세스 연계와 프로덕트 단절
단절된 프로세스나 활동(activity)를 예로 들 때 사일로(Silo)라는 단어를 많이 사용한다. 주로 조직 간의 프로세스 측면에서의 단절을 의미하는 데, 다른 한편으로는 기술(프로덕트)측면에서의 단절에 대해서도 고려할 필요가 있다. 프로세스를 기능적으로 시스템화하는 것은 프로덕트이기 때문이다.
일반적으로 프로젝트나 기술의 도입은 부서나 특정 기능의 개별적인 단위로 진행되어 왔다. 하지만 이런 개별적인 형태의 계획과 도입 및 운영은 기술적인 관점에서의 단절을 발생시킬 수 있다. 즉, 프로세스와 조직 간의 크로스오버뿐 아니라 프로덕트 간의 크로스오버도 중요하다는 점이다.
프로세스와 피플은 불가분의 관계이다. 프로세스와 조직(피플)이 논리적이고 개념적인 반면에, 프로덕트는 이런 프로세스와 활동들을 실제로, 구체적으로 구현하기 때문이다.
그렇기 때문에 프로세스와 조직이 당연히 논리적이라고 하더라도 그것을 뒷받침해주는 시스템들도 프로세스를 뒷받침할 수 있는 연결된 흐름을 가지고 있어야 한다. 하지만 대부분 지금까지의 형태는 부서나 특정 기능 별로 제품을 도입하거나 이를 기반으로 프로젝트를 발주하는 형태였기 때문에 프로덕트에서 사일로 현상이 발생하여 프로세스에도 영향을 주게 되어 지연과 커뮤니케이션 장애 등이 발생하게 된다. 그러므로 프로세스를 뒷받침할 수 있는 기술 시스템의 구축도 전체 통합 모델로써 중요한 부분이라고 할 수 있다.
핵심 프로세스들
IT통제와 IT관리 통합 모델에서 전반적인 라이프사이클 측면의 크로스오버를 고려할 때 주요 핵심 프로세스들이 있다. IT통제 및 관리 모델에 있어서 핵심 프로세스들을 도출하면 <그림 4>와 같다. 여기서 언급한 핵심 프로세스들은 라이프사이클 관점에서 가장 관심 있게 다루어져야 할 내용들을 일반적으로 정리한 것이며, 물론 이는 기업 환경과 운영 및 조직 형태에 따라 달라질 수 있다.
어떤 프로세스가 핵심 프로세스인지를 선정하는 것도 중요하지만 보다 더 중요한 것은 이들 프로세스 간의 연결이 프로세스와 더불어 조직(피플)과 기술(프로덕트)이 함께 상호작용을 해야 한다는 점이다. 이들 각각의 핵심 프로세스(Key process)들을 간단하게 알아보면 다음과 같다.
쪾 포트폴리오 관리(portfolio management)
쪾 성능 관리(performance management)
쪾 변경, 구성 및 배포 관리(change, configuration and release ma-nagement)
쪾 서비스 수준 및 장애 관리(service level management and pro-blem management)
포트폴리오 관리
포트폴리오 관리는 IT 수요 중 전략적인 투자에 관련된 요청을 수집하고, 각 단계별로 평가하고 난 후에 결정을 내림으로써, 위험을 감소시키고 효율성을 높이는 역할을 한다. 기존의 프로젝트 관리가 올바르게 관리하는 것(Do the things right)이라면, 포트폴리오 관리는 올바른 관리를 하는 것(Do the right thing)에 해당한다고 볼 수 있다.
그리고 라이프사이클 접근 시각에서 보면 단순히 포트폴리오에 대한 관리뿐 아니라 전체 IT 수요를 통합해서 전략적인 투자 요청에 대한 아이디어, 기안 등에 대한 평가를 진행해 나가는 흐름으로서의 관리이기 때문에 라이프사이클 측면에서 보면 통합 수요 관리(Demand Management)를 포함하고 있어야 한다. 그럼으로써 IT에 대한 통제 시각이 일반적인 IT 활동들과 연계되어 판단될 수 있다.
성능 관리
성능 관리의 의미는 개발/QA팀과 운영팀의 원활한 교류 및 커뮤니케이션을 의미한다. 버그 때문에 생긴 서비스 장애와 이를 수정하기 위해서 필요한 패치 생성 작업 시 동일한 측정과 기준으로 협업을 하게 되면 생산성 향상과 시행착오 방지 측면에서도 효과가 있지만 조직의 유기적인 운영이라는 측면에서 높은 경쟁력을 가질 수 있다.
변경 관리
변경(change) 관리는 구성(configuration) 관리 및 배포(release) 관리와 밀접하게 연결되어 있다. 개발/QA팀, 운영팀, 변경 승인 결정자 등이 엮여서 변경 프로세스가 발생한다. 이 때 발생할 수 있는 변경 관련 오류를 사전에 방지하고 감소시키기 위해서는 통제 환경에서 절차화된 프로세스를 시행시킬 수 있는 시스템화가 필수적이다. 즉, 절차화된 프로세스와 요구 활동 등을 지원할 수 있는 기술이 있어야 된다.
<그림 5>는 단계화된 변경관리 모델을 보여 주고 있다. 생산 시스템에 변경이 발생하더라도 영향을 끼치지 않도록 단계별 프로세스를 시스템화해서 통제할 수 있게 한다.
서비스 수준 및 장애 관리
IT 서비스 제공 및 운영의 중심에는 서비스 레벨 관리가 있다. 기술적인 요소들로 결합된 IT 서비스의 성과 측정을 비즈니스 관점의 서비스 수준 관리로 평가되고 이는 곧 운영에 직접적으로 반영된다. 그리고 이 서비스 운영 측정은 비용 측면에서의 투자와 대비하여 평가, 조정되고 다시 시행되는 순환 사이클을 통하게 된다. 즉, 전통적인 IT운영관리와 통제가 라이프사이클 관점에서 연결되는 것이다.
IT 통제와 ITSM 통합 모델 구현 방법
IT 통제와 ITSM 통합모델은 IT를 라이프사이클 관점에서 접근할 때 가장 유기적인 결합이 될 수 있다. 이 통합 모델의 구현을 위해서는 다음과 같은 특징들이 요구된다.
쪾 프로세스 기반(process framework)에 대한 지원
쪾 비즈니스와의 연계(alignment) 지원
쪾 가시성과 통제(control) 기반
프로세스 기반이라는 의미는 기존의 프로세스를 통제 환경에서 강제화 할 수 있는 프레임웍을 의미한다. 기술적으로 프로세스를 지원하는 기능적인 측면이 될 수 있다.
<그림 6>에서 볼 수 있듯이 변경관리를 할 때 준수해야 하는 프로세스를 나타내며 각 단계별로 유관 부서의 담당자가 그 과정을 수행해야 다음 과정으로 진행할 수 있으며, 이를 통해 프로세스의 시스템화를 구현할 수 있게 된다.
다음, 비즈니스 연계란 포괄적인 의미이다. 실제 IT수요와 공급에 관한 데이터를 확보함으로써 투자 우선순위에 있어 좀 더 올바른 결정을 하고, 중복이나 비효율성을 제거할 수 있는 투자 효율성과 이를 위한 시스템을 의미하는 동시에, 운영 및 서비스의 성과 측정을 현업과 비즈니스 관점으로 관리할 수 있는 기술적인 기능을 의미하기도 한다.
마지막으로 가시성과 통제는 IT 통제와 통합 모델의 핵심이기도 하다. 통제를 통해 원하지 않는 사건을 방지하고 위험을 줄여가면서 본래의 서비스를 전달할 수 있고, 일이 잘못되었을 때 이를 추적하고 수정할 수 있는 기준을 가질 수 있게 된다.
이런 통제 목적을 IT에서 달성하기 위해서는 가시성은 무엇보다 선결조건이 된다. 그리고 가시성을 갖추기 위해서는 위에서 언급한 대로 IT관리의 전통적인 기능들이 충실히 수행되어야 한다.
맺음말
지금까지 IT통제와 IT관리의 통합 모델의 필요성과 그 방안들에 대해서 알아보았다. IT통제의 전략적(Strategic) 역할과 ITSM의 전술적(Tactical), 운영적(Operational) 역할이 유기적인 라이프사이클 모델을 통해 동작할 때, 높은 효율성과 가치를 최적화할 수 있다.
IT는 지금까지 수많은 용어와 개념의 홍수 속에서 놀라운 기술 발전을 이루어 왔다. 하지만 기업 입장에서는 IT의 투자 대비 효용성에 많은 의구심을 가져온 게 사실이다. IT통제와 관리 모델의 통합은 IT가 기업 내에서 더 이상 관리와 통제가 어려운 이질적인 존재가 아니라 기업의 목표 달성에 효율적으로 기여하면서도 위험 관리가 될 수 있는 단계로 가는 중요한 전환점이 될 것이다. 또한, IT부서 차원이 아니라 기업 차원의 관련 법규 준수와 통제에 대한 외부 요구를 감안한다면, IT통제와 관리 모델의 통합은 앞으로 선택이 아닌 필수 과제가 될 전망이다.