COBIT Series(3) - IT 프로세스 개선과 성숙도

프로세스(process)와 절차(procedure)

먼저 개념 정리 차원에서 프로세스에 대한 정의부터 살펴보는 것이 도움이 될 것이다. 문헌마다 다양한 표현으로 정의를 하고 있으나, COBIT의 성숙 모델의 기초가 된 대표적인 모델인 CMMI(Capability Maturity Model Integration)에서는 ‘프로세스는 실무(practices)의 구현(implementations)으로 인식될 수 있는 활동들(activities)이다.’라고 정의하고 있다.

이와는 달리 COBIT에서는 ‘프로세스는 일반적으로 여러 소스 -다른 프로세스도 포함- 로부터 입력을 받고, 이를 처리하여, 결과(물)을 생산하는 조직의 정책 및 절차(procedure)에 의해서 영향 받는 절차의 모음’이라고 정의하고, 그리고 ‘그것은 존재할 업무상 이유, 소명할 수 있는 오너, 프로세스 실행의 명확한 역할 및 책임, 그리고 성과를 측정하는 수단을 가지고 있다.’는 특성을 함께 기술하고 있다. 그리고, 절차(서)는 ‘어떠한 활동을 완수하기 위한 방법을 명시한 단계들을 포함하고 있는 문서이며, 프로세스의 일부’로 정의하고 있다.

여기에서 ‘절차’의 의미를 완전히 이해해야 하는 것이 매우 중요하다. 간단히 말해서, 앞의 정의들 이면에는 IT 의 활동과 위험은 관리되어야 한다는 전제가 깔려있으며 활동 및 위험을 통제하기 위한 절차가 프로세스 속에 함께 포함되어야 함을 함축하고 있다는 점이다. 이점이 갖는 의미는 프로세스를 설계할 때, 적절한 통제 혹은 거버닝(governing) 시점(point)을 결정하고, 이 시점에 적합한 절차를 포함시켜야 한다는 사실이다. 따라서, IT 보증(assurance) 활동의 핵심 요소인 통제 설계의 유효성 평가 시에도 프로세스 속에 필요한 절차가 적절히 내포되어 있느냐 없느냐는 점이 중요한 평가 기준으로 작용한다.

프로세스-지향(process-oriented)

COBIT 프레임워크가 추구하는 ‘프로세스-지향’ 정신은 IT 의 전통적 책임 영역인 계획(Plan), 구축(Build), 실행(Run) 그리고 모니터(Monitor) 에 관하여 IT 활동들을 정의하고 있다. 실질적으로 COBIT은 전통적 책임 영역(PBRM)의 각각을 솔루션 전달과 서비스 전달에 대한 방향을 제시하는 ‘계획 및 조직(PO: Plan and Organize)’, 솔루션을 제공하고 이들을 서비스로 전환하도록 인도하는 ‘획득과 구현(AI: Acquire and Implement)’, 솔루션을 인수하여 최종사용자가 사용할 수 있도록 하는 ‘전달 및 지원(DS: Deliver and Support)’ 그리고 제시된 방향을 추구하도록 보증하기 위해 모든 프로세스들을 모니터하는 ‘모니터와 평가(ME: Monitor and Evaluation)’ 영역에 사상(mapping)시켜서 모두 34개의 IT 프로세스들을 정의하고 있다.

정의된 34개의 IT 프로세스는 조직의 IT 활동 및 책임에 대한 완전성, 즉 필요한 모든 것들을 망라하고 있다는 점을 충분히 보장할 수 있는 것이 COBIT이 갖는 장점일 것이다. 그렇지만, 이들을 모두 도입 및 적용할 필요는 없으며, 개별 기업마다 필요하다면 통폐합하여 사용할 수도 있다.

측정-주도(Measurement-driven)

‘측정-주도’를 위해서 COBIT에서 제공하는 것으로는 다음과 같은 것들이 있다:

1. 벤치마킹과 필요한 역량 개선사항의 파악을 가능하도록 하는 성숙 모델: level 0 non-existent 부터 level 5 optimized

2. 프로세스들이 비즈니스 및 IT 목표를 충족시키는 방법을 보여주고 그리고 균형성과표 원리에 입각해 내부 프로세스 성과를 측정하는데 쓰여지는, 프로세스들을 위한 성과 목표 및 측정기준

3. 효과적 프로세스 성과를 활성화시키는 활동 목표

이 가운데 성숙 모델에 한해서 보다 자세히 살펴보고자 한다. COBIT은 일반성숙모델(GMM: Generic Maturity Model)을 제공하고 있는데, 보다 나은 이해를 돕기 위해서 GMM 개발의 근간으로 사용된 역량성숙모델(CMM: Capability Maturity Model)과의 비교 설명이 도움이 될 것이다. 먼저 서로의 유사점은 아래의 각각의 개발 동기에서 찾아볼 수 있을 것이다.

CMM의 개발 목표

- 조직의 프로세스들이 CMM 모범 실무들과 비교하여 얼마나 좋은지 결정하기 위해서

- 조직의 프로세스들이 CMM 모범 실무들과 비교하여 얼마나 좋은지를 외부 고객과 공급자들에게 알려주기 위해서

- 고객들의 계약 요구사항을 충족시키기 위해서

GMM의 개발 목표

- 조직이 현재 머물러 있는 상대적 위치에 대한 결정을 지원

- 조직이 나아가야 할 곳을 효율적으로 결정하는 방법을 제공

- 목표 대비 진척도를 측정하기 위한 도구를 제공

그러나, 이들 간에는 차이점이 존재하는데, 첫째, GMM은 전반적인 IT 프로세스들 모두에, 반면 CMM은 소프트웨어 개발과 관련한 프로세스들에 초점을 맞추고 있는 점, 둘째는 GMM의 경우 연속적 표현(continuous representation) 방식만을 정의하고, CMM(I)에서는 연속적 표현과 더불어 단계적 표현(staged representation) 방식을 채택하고 있다는 것. 셋째, GMM은 주로 프로세스 오너를 비롯한 조직 내부의 이해관계자를 위한 자가 진단(self-assessment)을, CMM은 소프트웨어 개발 관련 서비스 제공자들에 대한 심사를 위한 것 등이 태생적 차이에 해당하는 것이다.

GMM의 강점

이제는 GMM이 지닌 유일한(?) 특징을 살펴보고자 한다. 그것은 프로세스 성숙도를 측정하는데 있어 GMM은 ‘다면 평가’에 대한 원리를 제시하고 있다는 사실이다. 다시 말해서, GMM은 프로세스 성숙도 측정에 있어서 ‘인식과 소통’, ‘정책, 계획 그리고 절차’, ‘도구 및 자동화’, ‘스킬 및 전문적 지식’, 수행 책임과 소명 책임’, 그리고 ‘목표 설정 및 측정’ 등의 6가지 속성을 사용해 종합적인 평가를 하도록 명시적으로 기술하고 있다.

그렇다면, 이러한 다면 평가를 이용한 프로세스 성숙도 진단이 갖는 장점은 무엇인가? 그 동안 우리의 서비스 제공자들이 CMM을 통한 소프트웨어 개발 프로세스의 성숙도 인증(?) 이후에 그 효과를 지속적으로 유지하는데 실패한 사례들을 통해서 역설적으로 그 답을 찾을 수 있을 것이다. 이와 같은 실패를 통해서 우리는 프로세스를 위한 정책, 절차, 계획서 등의 준비, 또한 관련 도구 및 자동화 구현은 짧은 기간에 준비가 가능할 수도 있지만, 프로세스에 참여하는 사람 또는 조직체가 지녀야 할 프로세스의 필요성과 역할 및 책임에 대한 의식 수준, 그리고 스킬 및 전문 기량의 확보는 그토록 짧은 시간에는 불가능하다는 점을 깨달을 수 있다. 따라서, 눈에 보이지 않는 역량이 눈에 보이는 역량을 지배한다는 사실, 쉽게 말하면, 프로세스의 이행 주체인 사람이 절차에 대한 형식적인 제도화보다 훨씬 강한 지배 요소라는 사실을 알 수 있다.

물론, 이러한 실패는 CMM 자체의 문제점에서 비롯된 것은 전혀 아니다. CMM에서도 프로세스는 스킬, 훈련 그리고 동기부여를 지닌 ‘사람’, 태스크들의 관계를 정의하는 ‘절차와 메소드’ 그리고 ‘도구 및 장비’ 등 핵심적인 3가지 영역을 모두 지닌다고 분명하게 지적하고 있다. 그렇기 때문에 그러한 실패는 우리가 해당 성숙 모델이 지닌 품질 철학을 먼저 이해하지 못한 상태에서 받아들인 데 원인이 있다고 생각한다.

이 밖에도 소프트웨어 프로세스의 품질로 소프트웨어 제품의 품질을 좌우할 수 있다는 믿음에서 출발한 프로세스의 도입 열기가 식게 된 이유로는 다음과 같은 사실들을 꼽을 수 있다. 물론 이들은 모든 IT 프로세스에 공통적으로 적용될 수 있는 원인들이다.

- 프로세스를 너무 복잡하게 설계 (조직이 클수록 절차는 단순하여야 한다고 함)

- 조직 구성원들의 잦은 출입(이직 및 채용)으로 자신들이 따라야 할 프로세스의 존재 조차도 모르는 경우가 발생

- 조직의 통폐합으로 인해 역할 및 책임이 불분명해짐 (프로세스를 최신 상태로 유지/관리할 책임자 조차도 누구인지 모르게 됨)

- 프로세스의 섣부른 자동화로, 유연성과 탄력성을 떨어뜨림

- 위기의 연속으로 프로세스의 효과보다도 효율성을 강조

- 사고의 고착화로 변화에 대한 대응 부족

GMM에 대한 오해

(이 내용은 그리 많지 않은 경험에 따른 것일지라도 앞으로도 반복될 수 있는 개연성이 있다고 생각되어 공유하려는 것입니다.)

프로세스 성숙도 진단 과정에서 지속적으로 발생 가능한 오해 소지는 다면 평가를 위한 6가지 속성 가운데 ‘정책, 계획 및 절차’의 레벨 5에 설명되어 있는 ‘외부의 모범 실무와 표준을 적용한다.’와 ‘스킬 및 전문지식’ 속성의 레벨 5에 있는 ‘가이드를 위해서 외부 전문가와 업계 리더들을 활용한다.’ 라는 기준 명세에 기인한다. 이러한 기준 명세 때문에 외부 컨설팅을 경험한 조직들은 해당 프로세스에 대한 자신들의 성숙도가 고수준(level 5)에 해당한다고 생각하는 경향이 있는데, 프로세스 성숙도는 어느 하나의 특정 기준의 충족만으로 도달될 수 없음을 반드시 이해할 필요가 있다.

또 다른 오해로는 통제 목적들에 대한 준수 수준(adherence level)과 프로세스 성숙도(maturity level)와의 관계는 서로 무관한 것임에도 서로 관련이 있다고 생각한다는 사실이다. 물론 일부 컨설턴트들이 이러한 오해에 대한 빌미를 먼저 제공한 탓일 수 있음을 이해한다. 예를 들면, 통제 목적의 준수 수준을 억지로 수치화시켜 비교 제시함으로써 고객의 오해에 대한 원인을 제공하였다고 볼 수 있다. 어쩌면, 컨설턴트도 이들이 서로 관련이 있다는 생각을 하였을지도 모르는 일이지만.

부연 설명을 위해서 일명 통제 수준으로 불리며 실전에서 사용되고 있는 통제 목적에 대한 준수 수준을 몇 가지 소개하면 다음과 같다.

가. COBIT 에서 정의하고 있는 각 세부 통제 목적별로 수준별 기준을 정함. (예, 수준 1 ~ 5까지)

- COBIT 4.1 의 210개 세부 통제 목적 모두에 대하여 수준별 상태 기술

- 예, Enterprise Architecture의 경우

Level 1: 인식 제고 중임

Level 2: EA 관리 기반을 구축

Level 3: EA 제품을 개발

Level 4: EA 제품을 완성

Level 5: EA를 변화 관리에 활용

그러나, 이 방법의 사용은 모든 통제 목적에 대해 위와 같이 점진적 준수 단계를 기술하는 것은 불가능하기 때문에 비현실적이다.

나. 모든 세부 통제 목적에 공통적인 기준 적용

공통 기준 1: (인터넷 자료)

공통 기준 2: (IT 거버넌스 인터내셔널)

공통 기준 3: (ISACA 지료)