Home

1996년 처음 발표된 COBIT은 ISACA가 개발한 IT 관리 프레임워크로 기업이 정보관리 및 거버넌스와 관련된 전략을 개발하고, 조직하고, 이행하는 데 유용하다. 전사적 전략, 목표 및 규모, IT의 역할, 규정준수 요구 사항 등의 설계 요소(Design factors)와 SME, 보안, 위험, 개발 및 운영 등의 초점영역(Focus area)을 토대로 정보 및 기술을 위한 맞춤형 전사적 거버넌스 시스템이 구성됨을 볼 수 있다. 맞춤형 거버넌스 시스템은 우선순위 거버넌스 및 관리 목표, 초점영역의 특정 지침, 목표 용량 및 성능 관리 지침 등의 주요 지침서로 구성되어 있다[10]. COBIT은 개발프로세스 점검 항목을 도메인과 프로세스로 정의하고 있으며 자세한 사항은 그림 2와 같이 EDM(평가, 지휘, 모니터링) 5개 항목 , APO(연계, 기획, 조직화) 14개 항목, BAI(구축, 획득 및 구현) 11개 항목 , DSS(제공, 서비스, 지원) 6개 항목 및 MEA(모니터링 평가 및 진단) 4개 항목으로 구성되어 있다[11][12]. 본 논문에서는 BAI, DSS, MEA 3개 영역의 전체 점검 항목 21개를 기준으로 정보시스템 평가를 진행한다.

Fig. 2. 
Domain and process of COBIT 2019[8]

CMMI는 1930년대에 Walter Shewhart에 의해 발표된 통계적 품질관리(SQC, Statistical Quality Control)개념을 1991년 미국 카네기 멜론대 부설 소프트웨어 공학 연구소(SEI, Software Engineering Institute)가 받아들이면서 소프트웨어 개발 및 유지보수 프로세스를 지속적으로 개선하기 위한 모델이다[13][14].

CMMI는 개발프로세스 기준은 표 1과 같이 PA(Practice Area)로 정의되며 이는 18개의 CORE PA와 2개의 DEV PA로 구분되어 있음을 알 수 있다. 각각 PA는 점검 항목을 포함하고 있다.

Practice Area는 CORE PA와 DEV PA로 구분되는데 성숙도 수준 레벨 2에서는 CORE PA의 형상관리에서 인프라 이행까지 모두 이행되어야 함을 나타내고, 성숙도 레벨 5에서는 MPM과 CAR이 반드시 이행되어야 한다. 표 1에서와 같이 전체 PA는 20개이며 각 PA 별 점검 항목을 합산하면 전체 185개의 점검 항목이 존재한다. 본 논문에서는 이들 20개 PA별 전체 점검 항목 185개를 기준으로 정보시스템 평가를 진행한다.

1980년대 후반, 영국정부에 의해 만들어진 ITIL은 IT서비스 관리 분야에서 전 세계적인 “de-facto”표준으로 IT서비스를 지원 구축, 관리하기 위한 일련의 IT서비스 관리 “Best Practice”로 Enterprise 기업이 고객에게 고품질의 IT서비스를 제공함으로써 비즈니스 목표를 달성할 수 있는 기반을 제공한다. ITIL 4는 서비스 Value에 중점을 둔 SVS(Service Value System)을 기반으로 운영된다. 그림 3에서와 같이 SVS는 조직의 가치 창출을 위한 구성요소와 활동이 체계적으로 함께 작동하는 방법을 설명하는 가치 체계를 기반으로 한다[15][16].

Fig. 3. 
Structure of SVS(Service Value System)

그림 3에서 SVS의 핵심 입력은 기회(Opportunity)와 수요(Demand)이며, 출력은 제품과 서비스가 제공하는 가치이다. SVS의 구성 요소는 Guiding Principles, Governance, Service Value Chain, Practice, Continual Improvement의 5개 영역으로 구성된다. 여기에서 프랙티스(Practice)는 ITIL이 개발프로세스 점검 항목으로 규정한 것을 의미하며, 표 2와 같이 일반 관리영역, 서비스 관리 영역, 기술 관리영역으로 구분되며, 각각 14개. 17개, 3개로 본 논문에서는 점검 항목 34개를 기준으로 정보시스템 평가를 진행한다.

유통 ERP앱에 대해 55개의 감리점검항목에 따라 평가를 진행하였으며, 감리점검항목이 정성적인 항목으로 구성되어 있어, 항목별 ‘상’(H), ‘중’(M), ‘하’(L)로 구분하여 각각의 개수로 평가하여 표 3과 같이 정리하였다.

표 3에서 감리 시점을 중심으로 요구분석 시점에서 ‘상’은 3개, ‘중’은 7개, ‘하’는 6개임을 알 수 있으며, ‘상’의 개수는 18.8%로 중, 하에 비해 낮음을 알 수 있다. 분석/설계 시점에서 ‘상’은 10, ‘중’은 6, ‘하’는 4개이며, ‘상’의 개수는 50%로 높음을 알 수 있다. 구현 시점에서 ‘상’은 5, ‘중’은 10, ‘하’는 4개임을 알 수 있다. 전체적으로 ‘하’로 평가된 항목이 25.5%임을 알 수 있다. 55개의 항목 중 ‘하’로 평가된 14개 점검항목 중 보안은 5개 항목, 계획은 4개의 항목, 표준은 2개 항목, 문서화는 2개 항목, 기타 사항은 1개 항목이다.

보안 및 계획 영역에서 ‘하’로 평가된 항목이 많음을 알 수 있는데 이는 보안 관련 내부규정이 없는 상태에서 개발되었음을 의미하며. 중소기업의 특성상 시작 단계에서 명확한 개발 계획 없이 개발자의 능력에 따라 계획이 유동적으로 쉽게 변경될 수 있음을 보여준다.

요구분석 시점에서 시스템 아키텍쳐, 응용시스템영역에서 ‘상’이 1개씩으로 낮은 평가가 나왔는데 이는 프로그램 개발시 요구분석이 충분히 이루어지지 않았음을 알 수 있다. 반면 모든 감리 시점에서 데이터베이스 감리영역에서는 ‘하’가 적어 개발자가 데이터베이스 개발에 높은 역량 및 많은 주의를 가지고 임했음을 알 수 있다.

그림 2에서와 같이 COBIT 2019 도메인 및 도메인별 점검항목에 따라 평가를 진행하였으며, COBIT점검항목은 정성적인 항목으로 구성되어 있어, 항목별 ‘상’, ‘중’, ‘하’로 구분하여 표 4와 같이 나타내었다.

또한 COBIT 2019에서는 CMMI 성능 관리 체계를 사용하고 있기 때문에 도메인 내 점검 항목과 Level별로 세분화하여 개발프로세스 기준이 제시되어, 그에 따라 평가를 하였으며 그에 대한 결과를 표 5에 나타내었다. BAI의 항목 중 Level3 수준을 성취하기 위해서는 Level 미 설정 항목과 Level3에 해당하는 항목을 모두 충족 해야한다.

표 4에서 ‘하’ 항목이 BAI(구축, 획득 및 구현)도메인에서 1개 밖에 나오지 않았음을 알 수 있으며 전체 21개 항목 중 ‘상’의 개수는 9개. ‘중’의 개수는 11개이며, ‘상’의 경우 전체 43%임을 알 수 있다. 따라서 개발 프로그램이 COBI 기준에는 상당히 만족함을 알 수 있다. COBIT 점검 항목 중 ‘하’로 평가된 항목은 조직에서 조직변경관리 한 개의 항목이다.

2017년 9월부터 2020년 7월까지를 기준으로 한국의 CMMI 인증 건수를 수준별로 분류했을 때 Level 2와 Level 3의 수준을 취득한 기업은 총 70개로, 비율은 약 80%를 차지하고 있으며 CMMI의 성숙도 수준 중 Level 3~5의 경우 Practice Area 구성이 동일하여 본 연구의 평가 기준을 Level 2~3으로 삼았다[17]. CMMI의 경우 성숙도에 따라 항목이 Level별로 분류되어 있으며, 정량적 체크 리스트로 항목별 구분되어 있어 ‘상’, ‘중’, ‘하’가 아닌 Pass/Fail로 구분하여 평가하였으며 평가 결과를 표 6에 나타내었다. 표 내 숫자는 점검 항목 수를 ( )로 나타냈으며 점검 항목 수 앞에 Pass개수를 표현하였다. 예로 1(2)은 점검 항목 수 2개에 Pass개수 1을 의미한다.

표 6에서 해당 프로그램은 Level 1~2에 대한 사항은 대부분 충족하는 것으로 파악되며, Level 3에 대한 사항 또한 57.7%에 해당되어, 감리를 하지 않고 개발된 프로그램이 개발자 기본 역량만으로 CMMI Level 2~3수준이 충족된 것으로 평가된다.

평가 결과 총 PA는 20개이며 각 PA 별 점검 항목 185건을 통하여 점검을 한 결과 Pass는 130건이고, Fail은 55건이다. Level 별 Fail 건수는 Level 2가 11건, Level 3이 30건으로, Level 2에 비해 Level 3의 Fail율이 3배가 높다. 본 평가의 기준인 Level 2~3 중 ‘Fail’로 선택된 항목은 총 41개 항목에서 ‘Fail’로 선택이 되었다. 조직교육훈련(OT)영역에서 6개 항목이 ‘Fail’로 가장 많았으며, 의사결정 분석/해결(DAR)항목은 5개, 성과 및 측정 관리(MPM)항목은 4개이다. 중소기업의 경우 개발 관련 인력이 부족한 경우가 상당수이기 때문에 관련된 교육지원과 유지보수 및 개발의 대체인력 확보의 어려움이 OT 항목의 Fail율을 상승시키는 요인이 되었다고 판단된다. 특히 내부 절차 및 표준이 존재하지 않으며, 패키지 개발업체의 특성상 성과 및 측정에 대한 관리 기준이 없이 지속적으로 유지보수를 한 점이 기타 요인의 Fail율을 높이는 요인이 되었다고 추측된다.

ITIL기준에 따른 평가는 표 2의 ITIL Practice에 따라 평가를 진행하였으며, 정성적인 항목으로 개발프로세스 점검 항목이 구현되어 있어, 항목별 ‘상’, ‘중’, ‘하’로 구분하였으며 결과를 표 7에 나타내었다. 일반 관리영역에서는 ‘상’은 28.6%, ‘중’은 57.1%, ‘하’는 14.3%였으며, 서비스 관리영역에서는 ‘상’, ‘중’ 각각 47%, ‘하’는 5.9%였으며 기술관리 영역에서는 ‘하’로 평가된 항목은 없는 것으로 나타났다.

기 개발된 소프트웨어에 대해 국내·외 정보시스템 개발기준에 따라 수행한 평가결과 표 3, 표 4, 표 6을 바탕으로 정성적인 항목을 가진 국내 정보시스템 감리기준, COBIT, ITIL의 경우에는 ‘상’인 항목은 5점, ‘중’인 항목은 3점, ‘하’인 항목은 1점으로 측정하여 계산하였고, 정량적인 항목을 가진 CMMI는 ‘Pass’인 항목은 1점, ‘Fail’인 항목은 0점으로 측정하여 계산하여 종합적으로 비교하였다. 결과는 표 8과 같으며 국내감리기준에 의한 평가가 가장 낮게 나왔으며 COBIT에 의한 평가가 가장 높게 나왔다. 평균적으로 70%정도의 점수를 얻은 것으로 평가되었다.

또한 정보시스템 감리기준, COBIT, ITIL의 경우 ‘하’로 평가된 항목을, 정량적인 개발프로세스 기준인 CMMI의 경우 ‘Fail’로 평가된 항목들을 분석해 볼 때 ‘구현’, ‘조직’, ‘보안’ 등의 순으로 누락된 항목이 많은 것으로 집계되었다. 구현의 경우, 사내 표준 및 프로세스가 부재하여 누락되는 사항이 가장 많았다. 조직의 경우, 인력 개발을 위한 교육과정이 존재하지 않거나, 각 프로세스 별 담당 관리자의 부재 및 역할 분담이 명확히 이루어지지 않아 누락되는 사항이 발생하였다. 보안의 경우, 내부 기준이 없어 개발자의 역량에 따라 개발이 되어 역량 별 누락되는 편차가 큰 것으로 확인되었다. 감리를 받지 않는 경우, 문서화, 표준화, 프로세스화와 같이 정량적인 기준을 만들고, 그에 따라 관리를 하는 부분에서 부족한 부분이 가장 많은 것으로 판단된다. 개발 시 정해진 표준에 따라 설계, 분석, 구현이 이루어져야 할 것으로 생각되며, 이를 통하여 위험 예방을 할 수 있을 것으로 판단된다.