능력 성숙도 통합 모델

3. CMMI의 구성 요소

능력 성숙도 통합 모델(CMMI)은 조직이 프로세스를 정립하고 개선하기 위한 수단으로, 카네기 멜론 대학교(CMU)의 소프트웨어 공학 연구소(SEI)에서 여러 업계 및 정부 기관과의 협력을 통해 개발되었다.^[3] 2013년부터는 CMU 내 새로 설립된 CMMI 연구소에서 관리하고 있다.^[4] CMMI는 조직의 비즈니스 목표 달성을 돕는 프로세스 개발 및 개선 지침을 제공하며, 조직의 프로세스 성숙도를 평가하는 프레임워크로도 사용된다.^[3]

CMMI는 조직의 개발 프로세스를 평가하기 위해 5단계의 성숙도 레벨(Maturity Level^eng)과 6단계의 역량 레벨(Capability Level^eng) 기준을 제공한다. 이를 위해 약 20여 개의 프로세스 영역(Process Area|PA^eng)을 정의하고 있으며, 각 프로세스 영역은 달성해야 할 목표(Goal^eng)와 이를 위한 구체적인 활동인 프랙티스(Practice^eng)들로 구성된다. 이러한 구성 요소들은 조직이 프로세스를 체계적으로 관리하고 개선해 나가는 데 필요한 구조를 제공한다.

원래 CMMI는 제품 및 서비스 개발(CMMI-DEV), 서비스 구축 및 관리(CMMI-SVC), 제품 및 서비스 획득(CMMI-ACQ)의 세 가지 주요 관심 분야(constellation^eng)를 다루었으나, 2.0 버전부터는 이들을 하나의 통합된 모델로 제공한다.^[10]

CMMI 버전 1.3까지는 특정 프로세스 영역 개선에 집중하는 연속형 표현(Continuous Representation^eng)과 조직 전체의 성숙도 수준 향상에 초점을 맞춘 단계형 표현(Staged Representation^eng) 두 가지 방식이 존재했다.^[3] 단계형 표현은 SW-CMM과의 호환성을 높이고 조직 간 비교를 용이하게 했으며, 연속형 표현은 조직의 특정 요구에 맞춰 개선 활동을 유연하게 선택할 수 있도록 했다.^[3] 하지만 CMMI 버전 2.0에서는 이러한 구분이 없어지고 하나의 통합된 모델 구조로 변경되었다.^[10]

3. 1. 프로세스 영역 (Process Area)

• 프로세스 관리 (Process Management): 조직 차원의 프로세스를 정의, 계획, 배포, 모니터링, 통제, 평가, 측정, 개선하는 활동을 다룬다.
• 프로젝트 관리 (Project Management): 개별 프로젝트를 계획, 모니터링, 통제하는 활동을 다룬다.
• 엔지니어링 (Engineering): 제품 및 서비스의 개발과 유지보수에 관련된 기술적인 활동을 다룬다.
• 지원 (Support): 다른 프로세스 영역의 활동을 지원하는 활동을 다룬다. 예를 들어 형상 관리, 품질 보증 등이 포함된다.

가장 널리 사용되는 모델 중 하나인 "개발을 위한 CMMI(CMMI-DEV)"의 프로세스 영역은 다음과 같다.

이 외에도 시스템 공학, 소프트웨어 공학, 통합 제품 및 프로세스 개발, 공급자 소싱 등 특정 분야에 특화된 프로세스 영역들이 정의되어 있다. 예를 들어, 통합 제품 및 프로세스 개발 분야에는 통합 팀(Integrated Teaming) 및 통합 조직 환경(Organizational Environment for Integration)과 같은 프로세스 영역이 포함되며, 공급자 소싱 분야에는 통합 공급자 관리(Integrated Supplier Management) 등이 있다. 소프트웨어 공학의 프로세스 영역은 시스템 공학의 프로세스 영역과 동일하게 정의되기도 한다.

3. 2. 목표 (Goal)

• '''GG 1''' 특정 목표들을 달성한다 (Achieve Specific Goals).
• * '''GP 1.1''' 기본 프랙티스들을 수행한다 (Perform Base Practices).
• '''GG 2''' 관리 프로세스를 내재화한다 (Institutionalize a Managed Process).
• * '''GP 2.1''' 조직의 정책을 수립한다 (Establish an Organizational Policy).
• * '''GP 2.2''' 프로세스를 계획한다 (Plan the Process).
• * '''GP 2.3''' 자원을 제공한다 (Provide Resources).
• * '''GP 2.4''' 책임을 할당한다 (Assign Responsibility).
• * '''GP 2.5''' 담당자를 훈련시킨다 (Train People).
• * '''GP 2.6''' 구성요소를 관리한다 (Manage Configurations).
• * '''GP 2.7''' 관련 이해관계자들을 식별하고 포함시킨다 (Identify and Involve Relevant Stakeholders).
• * '''GP 2.8''' 프로세스를 관찰하고 통제한다 (Monitor and Control the Process).
• * '''GP 2.9''' 객관적으로 평가한다 (Objectively Evaluate Adherence).
• * '''GP 2.10''' 높은 수준의 관리자와 상태를 검토한다 (Review Status with Higher-Level Management).
• '''GG 3''' 정의된 프로세스를 내재화한다 (Institutionalize a Defined Process).
• * '''GP 3.1''' 정의된 프로세스를 수립한다 (Establish a Defined Process).
• * '''GP 3.2''' 개선 정보를 수집한다 (Collect Improvement Information).
• '''GG 4''' 정량적으로 관리하는 프로세스를 내재화한다 (Institutionalize a Quantitatively Managed Process).
• * '''GP 4.1''' 프로세스를 위한 정량적 목표들을 수립한다 (Establish Quantitative Objectives for the Process).
• * '''GP 4.2''' 하위 프로세스 성능을 안정화시킨다 (Stabilize Subprocess Performance).
• '''GG 5''' 최적화하는 프로세스를 내재화한다 (Institutionalize an Optimizing Process).
• * '''GP 5.1''' 계속적인 프로세스 개선을 보증한다 (Ensure Continuous Process Improvement).
• * '''GP 5.2''' 문제의 근본적인 원인을 식별하고 수정한다 (Correct Root Causes of Problems).

3. 3. 프랙티스 (Practice)

• GG 1 특정 목표들을 달성한다.

• GG 2 관리 프로세스를 내재화한다.

• GG 3 정의된 프로세스 내재화한다.

• GG 4 정량적으로 관리하는 프로세스를 내재화한다.

• GG 5 최적의 프로세스를 내재화한다.

4. CMMI의 성숙도 및 역량 수준

능력 성숙도 통합 모델(CMMI)은 조직이 프로세스를 개발하고 개선하는 활동을 지원하며, 그 수준을 평가하기 위한 프레임워크이다.^[3] CMMI는 조직의 프로세스 성숙도를 종합적으로 평가하는 성숙도 레벨(Maturity Level)과 개별 프로세스 영역의 능력을 세부적으로 평가하는 역량 레벨(Capability Level)이라는 두 가지 주요 평가 기준을 제공한다.

CMMI 모델은 본래 제품 및 서비스 개발(CMMI-DEV), 서비스 구축 및 관리(CMMI-SVC), 제품 및 서비스 획득(CMMI-ACQ)이라는 세 가지 주요 영역을 다루었으나, 버전 2.0에서는 이들을 하나의 통합된 모델로 합쳤다. 이 모델은 미국 피츠버그의 카네기 멜론 대학교(CMU) 소프트웨어 공학 연구소(SEI)와 업계 및 정부 전문가들이 협력하여 개발하였으며,^[3] 2013년부터는 카네기 멜론 대학 내 CMMI 연구소에서 관리하고 있다.^[4]

CMMI는 조직이 비즈니스 목표를 효과적으로 달성하기 위해 프로세스를 개선하는 데 필요한 지침을 제공하며, 동시에 조직의 현재 프로세스 수준을 객관적으로 평가하는 벤치마크로도 활용된다.^[3] 조직의 프로세스 개선 수준은 각 프로세스 영역(Process Areas)별로 정의된 특정 목표(Specific Goals, SP)와 여러 프로세스 영역에 공통으로 적용되는 공통 목표(Generic Goals, GG)의 달성 정도를 측정하여 평가한다.

과거 CMMI 버전 1.3에서는 모델을 표현하는 방식으로 단계형 표현(Staged Representation)과 연속형 표현(Continuous Representation) 두 가지를 제공했다.^[3] 단계형 표현은 조직 전체의 성숙도를 1단계부터 5단계까지의 성숙도 레벨로 평가하여, 조직 간 성숙도를 비교하거나 표준화된 개선 경로를 따르는 데 유용했다. 반면, 연속형 표현은 조직이 중요하다고 판단하는 특정 프로세스 영역에 집중하여 개선할 수 있도록, 각 프로세스 영역별 능력 수준을 역량 레벨로 평가하는 방식이었다.^[3] 하지만 CMMI 2.0 버전부터는 이러한 표현 방식의 구분이 없어지고 하나의 통합된 모델만 제공된다.^[10]

CMMI는 소프트웨어 개발뿐만 아니라 시스템 설계, 하드웨어 개발, 운영 등 시스템 통합(SI) 사업 전반의 프로세스를 평가하고 개선하는 데 폭넓게 활용될 수 있다. 이를 위한 표준 평가 방법론으로 SCAMPI(Standard CMMI Appraisal Method for Process Improvement)가 제공된다. CMMI는 항공전자공학 소프트웨어 개발이나 여러 국가의 정부 주도 프로젝트 등에서 널리 채택되고 있으며,^[28] 일부 국가에서는 정부 계약 시 특정 성숙도 레벨 달성을 요구하기도 한다. 일본 등에서도 CMMI를 도입하여 소프트웨어 개발 프로세스를 개선하려는 움직임이 확산되고 있다.

또한, 보안 관련 요구사항을 충족하기 위해 비공식적인 보안 가이드가 제공되기도 한다. 예를 들어, ''CMMI for Services의 보안 콘텐츠 사례 고려''는 '보안 관리' 프로세스 영역을 다루고,^[17] ''CMMI for Development, 버전 1.3을 이용한 설계 기반 보안''은 보안 개발 준비, 프로젝트 내 보안 관리, 보안 요구사항 및 기술 솔루션, 보안 검증 및 유효성 검사 등의 프로세스 영역을 포함한다. 이러한 보안 관련 프로세스 영역은 공식적인 성숙도나 역량 레벨 평가에는 직접적인 영향을 주지 않지만, 평가 결과에 부가 정보로 보고될 수 있다.^[18]

4. 1. 성숙도 레벨 (Maturity Level)

• 레벨 1 (Initial, 초기): 프로세스가 거의 정의되지 않아 예측 불가능하고 혼란스러운 상태이다. 프로젝트의 성공 여부가 주로 개인의 역량과 영웅적인 행동에 달려 있으며, 표준화된 프로세스가 없어 성공 경험을 반복하기 어렵다. 조직은 안정적인 환경을 제공하지 못하며, 프로젝트는 예산과 일정을 초과하는 경우가 많다.^[3]
• 표준화된 프로세스 없이 프로젝트 수행 결과 예측이 곤란한 조직
• 적용 프로세스 없음

• 레벨 2 (Managed, 관리): 기본적인 프로젝트 관리 프로세스가 도입되어 프로젝트가 통제되는 수준이다. 요구사항 관리, 프로젝트 계획, 추적 및 감시, 공급자 계약 관리, 측정 및 분석, 품질 보증, 형상 관리 등의 활동이 수행된다. 이를 통해 비용, 일정 등을 관리하고 과거의 유사한 프로젝트 성공 사례를 반복적으로 적용할 수 있게 된다. 그러나 아직 조직 전체의 표준 프로세스는 부족하다.^[3]
• 기본적인 프로세스 구축에 의해 프로젝트가 관리되고 있는 조직
• 적용 프로세스
• 요구사항 관리(Requirements Management, REQM)
• 프로젝트 계획(Project Planning, PP)
• 프로젝트 감시 및 통제(Project Monitoring and Control, PMC)
• 공급자 계약 관리(Supplier Agreement Management, SAM)
• 측정 및 분석(Measurement and Analysis, MA)
• 프로세스 및 제품 품질 보증(Process and Product Quality Assurance, PPQA)
• 형상 관리(Configuration Management, CM)

• 레벨 3 (Defined, 정의): 조직 전체의 표준 프로세스가 정의되고 문서화되어 있다. 각 프로젝트는 조직의 표준 프로세스를 상황에 맞게 조정하여 사용하며, 이를 통해 일관성 있는 프로세스 수행이 가능하다. 요구사항 개발, 기술적 해결, 제품 통합, 검증, 확인 등 엔지니어링 프로세스와 조직 프로세스 중점, 조직 프로세스 정의, 조직 훈련, 통합된 프로젝트 관리, 위험 관리, 의사 결정 분석 및 해결 등 조직 차원의 프로세스 관리가 강조된다.^[3]
• 세부 표준 프로세스가 있어 프로젝트가 통제되는 조직
• 적용 프로세스
• 요구사항 개발(Requirements Development, RD)
• 기술 솔루션(Technical Solution, TS)
• 제품 통합(Product Integration, PI)
• 검증(Verification, VER)
• 확인(Validation, VAL)
• 조직 프로세스 중점(Organization Process Focus, OPF)
• 조직 프로세스 정의(Organization Process Definition, OPD)
• 조직 훈련(Organization Training, OT)
• 통합 프로젝트 관리(Integrated Project Management, IPM)
• 위험 관리(Risk Management, RSKM)
• 의사 결정 분석 및 해결(Decision Analysis and Resolution, DAR)
• 통합 조직 환경(Organizational Environment for Integration, OEI)
• 통합된 팀 구성(Integrated Teaming, IT)

• 레벨 4 (Quantitatively Managed, 정량적 관리): 프로세스와 제품 품질에 대한 정량적인 목표를 설정하고 데이터를 수집하여 관리한다. 통계적 기법을 활용하여 프로세스 성과를 분석하고 예측하며, 이를 통해 프로젝트 결과를 안정적으로 관리할 수 있다.^[3]
• 프로젝트 활동이 정량적으로 관리·통제되고 성과 예측이 가능한 조직
• 적용 프로세스
• 조직 프로세스 성과(Organizational Process Performance, OPP)
• 정량적 프로젝트 관리(Quantitative Project Management, QPM)

• 레벨 5 (Optimizing, 최적화): 정량적인 데이터를 기반으로 지속적인 프로세스 개선 활동이 이루어진다. 혁신적인 아이디어를 도입하고 성과를 분석하여 조직 전체의 프로세스를 최적화하며, 문제의 근본 원인을 분석하고 해결하여 재발을 방지한다.^[3]
• 지속적인 개선 활동이 정착화되고 최적의 관리로 프로젝트가 수행되는 조직
• 적용 프로세스
• 조직 혁신 및 이행(Organization Innovation and Deployment, OID)
• 인과 분석 및 해결(Causal Analysis and Resolution, CAR)

4. 2. 역량 레벨 (Capability Level)

• 레벨 0: 불완전 (Incomplete): 프로세스가 제대로 수행되지 않거나 부분적으로만 실행되는 상태이다. 해당 프로세스 영역에서 달성해야 할 하나 이상의 특정 목표(Specific Goals)를 만족하지 못한다.^[31] 프로세스 개선 활동의 시작점으로 볼 수 있다.
• 레벨 1: 수행됨 (Performed): 프로세스 영역의 특정 목표를 달성하는 데 필요한 기본적인 작업들이 수행되고 관련 작업 산출물이 생성된다.
• 레벨 2: 관리됨 (Managed): 레벨 1의 요건을 충족하면서, 프로세스가 프로젝트 관리 계획에 따라 체계적으로 관리된다. 여기에는 계획 수립, 자원 배분, 책임 할당, 성과 측정 및 통제, 이해관계자 관리 등이 포함된다.
• 레벨 3: 정의됨 (Defined): 레벨 2의 요건을 충족하면서, 조직 차원에서 표준화된 프로세스를 활용한다. 프로젝트의 특성에 맞게 조직의 표준 프로세스를 조정(Tailoring)하여 사용하며, 프로세스 수행을 통해 얻은 경험과 자산이 조직 전체의 프로세스 개선에 기여한다.

5. CMMI의 평가 방법 (SCAMPI)

CMMI는 조직의 SW 개발뿐만 아니라 시스템 설계, 하드웨어, 운영 등 시스템 통합(System Integration, SI) 사업 전반에 대한 프로세스를 평가하고 정의하는 방법인 '''SCAMPI'''(Standard CMMI Appraisal Method for Process Improvement)를 제공한다.

조직은 CMMI 인증을 받을 수는 없으며, 대신 ''평가''를 받는다. 많은 조직은 다음 이유 중 하나 이상을 위해 평가를 수행하여 진행 상황을 측정하는 데 가치를 둔다.

# 조직의 프로세스가 CMMI 모범 사례와 얼마나 잘 비교되는지 확인하고, 개선할 수 있는 영역을 식별하기 위해

# 조직의 프로세스가 CMMI 모범 사례와 얼마나 잘 비교되는지 외부 고객 및 공급업체에 알리기 위해

# 하나 이상의 고객의 계약 요구 사항을 충족하기 위해

CMMI 모델을 사용하는 조직에 대한 평가는 ARC(Appraisal Requirements for CMMI) 문서에 정의된 요구 사항을 준수해야 한다. 평가에는 A, B, C의 세 가지 클래스가 있으며, 개선 기회를 식별하고 조직의 프로세스를 CMMI 모범 사례와 비교하는 데 중점을 둔다. 이 중 클래스 A 평가는 가장 공식적이며 레벨 등급을 받을 수 있는 유일한 평가 유형이다. 평가 팀은 CMMI 모델과 ARC를 준수하는 평가 방법을 사용하여 조직에 대한 평가를 안내하고 결론을 보고하며, 평가 결과는 조직의 개선 계획 수립에 사용될 수 있다.

SCAMPI는 ARC 요구 사항을 모두 충족하는 평가 방법이다. SCAMPI 평가 결과는 평가된 조직이 승인하면 SEI의 CMMI 웹사이트에 게시될 수 있다. SCAMPI는 또한 ISO 15504, SPICE 프로젝트(소프트웨어 프로세스 개선 및 역량 결정) 평가 등의 수행을 지원한다.

이 접근 방식은 EPG(Engineering Process Group) 및 PAT(Process Action Team) 구성원이 CMMI 교육을 받고, 비공식(SCAMPI C) 평가를 수행하며, 프로세스 영역의 개선 우선 순위를 지정하도록 권장한다. 상용 CMMI 호환 프로세스의 배포와 관련된 더 현대적인 접근 방식은 규정 준수 달성 시간을 크게 줄일 수 있다. 소프트웨어 공학 연구소(SEI)는 초기 소프트웨어 CMM 및 CMMI를 채택한 조직의 "상승 시간"에 대한 통계를 유지해 왔는데, CMMI가 출시된 이후 레벨 1에서 레벨 2로 이동하는 데 걸리는 중간 시간은 5개월이며, 레벨 3으로의 중간 이동은 21개월이다. 이는 과거 CMM 시절(각각 23개월, 20개월)에 비해 단축된 시간이다. 이러한 통계는 6개월마다 성숙도 프로필로 업데이트되어 게시된다.

6. CMMI의 적용 분야 및 효과

능력 성숙도 통합 모델(CMMI)은 조직의 프로세스 개선을 위한 프레임워크로, SEI에 의해 개발되었다.^[3] 이는 소프트웨어 개발 과정의 비용, 품질, 일정 등을 개선하고 특정 성숙도 수준에 도달하기 위한 최소한의 기준과 활동을 제시하며, 조직의 비즈니스 목표 달성을 돕는 프로세스 개발 및 개선 지침과 성숙도 평가 기준을 제공한다.^[3]

CMMI는 소프트웨어 개발뿐만 아니라 시스템 설계, 하드웨어, 운영 등 SI 사업 전반에 적용될 수 있으며, SCAMPI라는 공식 평가 방법을 통해 조직의 프로세스 수준을 평가한다. 조직은 평가 결과에 따라 성숙도 수준(1~5)이나 역량 수준 프로필을 부여받는다. 평가는 주로 조직 프로세스의 현황 진단, 개선 영역 식별, 외부 이해관계자와의 소통, 계약 요구사항 충족 등을 목적으로 수행된다.

CMMI는 제품 및 서비스 개발, 서비스 구축 및 관리, 제품 및 서비스 획득 등 다양한 영역에 적용될 수 있으며^[3], 조직의 공정 및 관리 능력 향상을 목표로 한다. 전 세계적으로 많은 기업이 CMMI를 도입하고 있으며, 프로젝트 참여나 제품 공급의 전제 조건으로 요구되는 경우도 증가하고 있다. 이에 따라 IT 서비스 기업을 포함한 다양한 산업 분야에서 CMMI 적용 및 평가를 추진하고 있으며, 이를 통해 프로세스 개선 및 성과 향상을 기대한다.^[19]

6. 1. 적용 분야

• 제품 및 서비스 개발 (CMMI for Development, CMMI-DEV): 소프트웨어 개발 및 시스템 공학을 포함하여 제품 및 서비스 개발 프로세스의 개선에 중점을 둔다. 여기에는 요구사항 개발(Requirements Development), 요구사항 관리(Requirements Management), 기술 솔루션(Technical Solution), 제품 통합(Product Integration), 검증(Verification), 확인(Validation) 등의 엔지니어링 프로세스 영역 활동이 포함된다.^[3] 복잡한 제품 개발 시 특히 유용하다.
• 서비스 구축 및 관리 (CMMI for Services, CMMI-SVC): IT 서비스 관리, 고객 지원, 서비스 수준 관리 등 서비스의 효과적인 구축 및 관리에 적용된다.^[3]
• 제품 및 서비스 획득 (CMMI for Acquisition, CMMI-ACQ): 제품이나 서비스를 외부 공급자로부터 획득하는 프로세스를 다룬다. 공급망 관리, 계약 관리, 공급업체 평가 및 선정, 통합 공급자 관리(Integrated Supplier Management) 등이 관련 활동이다.^[3]

6. 2. 효과

7. CMMI와 다른 표준과의 관계

기존의 다양한 소프트웨어 및 시스템 공학 성숙도 모델들은 정의와 표준이 달라 교육, 평가, 개선 활동에 혼란과 추가 비용을 발생시키는 문제가 있었다. 이러한 문제를 해결하기 위해 통합된 모델의 필요성이 제기되었다.

한편, 국제 표준화 기구(ISO)와 국제 전기 표준 회의(IEC)는 ISO/IEC 15504(SPICE)를 소프트웨어 프로세스 개선 및 능력 평가를 위한 국제 표준으로 채택했다. 이러한 국제 표준화 동향은 미국 카네기 멜론 대학의 소프트웨어 공학 연구소(SEI)가 CMMI를 개발하고 배포하는 데 영향을 미쳤다.

8. CMMI에 대한 비판과 한계

CMM/CMMI가 소프트웨어 개발 프로세스 성숙도 모델로 널리 알려지면서 여러 비판도 제기되었다.^[29][30]

우선 CMMI가 규정하는 프로세스, 특히 문서 관리 요구사항이 실제 개발 환경과 맞지 않다는 지적이 있다. 예를 들어, 애플, 시만텍, 마이크로소프트와 같은 상용 패키지 소프트웨어 개발 기업 다수는 CMMI 레벨 2 달성에 필요한 수준의 문서를 거의 관리하지 않는 것으로 알려져 있으며, 이 기준대로라면 레벨 1에 해당할 수 있다. 소프트웨어 업계는 다양하고 변화가 많으며, 모든 소프트웨어 개발 방법론에는 지지자와 비판자가 존재한다. 이는 CMMI 모델이 특정 유형의 조직, 특히 정부 계약을 수행하거나 규모가 큰 관료적 조직에 더 적합할 수 있음을 시사한다. 이러한 조직에서는 CMM 감사를 위한 팀을 운영하고 경영진에 보고하는 것이 권장되기도 하지만, 이 과정에서 실제 애플리케이션 소프트웨어 개발이나 고객 요구, 시장 변화 대응보다는 CMM 방식 자체를 준수하는 데 치중하게 될 수 있다는 비판이 있다. 특히 납기가 중요한 프로젝트에서는 CMM의 절차 준수가 오히려 방해가 될 수도 있다.

또한, CMMI를 따른다고 해서 반드시 프로젝트 성공이나 경영 상태 개선이 보장되는 것은 아니다. CMMI는 성공한 조직의 모범 사례를 정리한 것이지, 유효한 개발 조직을 만드는 방법을 직접적으로 제시하지는 않는다. CMMI를 준수하는 것이 본질적인 목표 달성보다 프로세스 자체에 치중하는 형식주의로 흐를 수 있다는 비판도 있다. 예를 들어, 최종 사용자에 대한 서비스 제공보다 예측 가능성을 지나치게 강조할 수 있다는 것이다. 상업적으로 성공한 다른 방법론(예: 래셔널 통합 프로세스)들이 특정 최종 사용자의 요구사항(유스 케이스) 만족에 초점을 맞추는 것과 대조될 수 있다. 실제로 CMMI 레벨 5를 취득한 후에도 경영 실적이 악화된 기업 사례(저스테크, 미쓰비시 전기 정보 시스템즈 등)도 존재한다.

CMMI 인증 과정과 관련해서도 비판이 있다. CMMI 준수를 공식적으로 인증하는 제3자 기관은 없으며, 조직 자체의 검증이나 SEI가 아닌 인증된 리드 어프레이저(Lead Appraiser)에 의한 평가 결과에 의존한다. 이 때문에 CMMI를 법률이나 규칙처럼 반드시 '준수'해야 하는 강제 규정으로 오해하는 경우도 있으나, CMMI는 개선을 위한 참조 모델이지 엄격한 기준은 아니라는 점을 유의해야 한다. 리드 어프레이저의 역할 역시 단순히 레벨을 판정하는 것이 아니라 조직의 프로세스 개선을 촉진하는 데 있다.

국내 기업의 경우, CMMI 도입 효과가 기대만큼 크지 않다는 지적도 있는데, 이는 국내 소프트웨어 개발 문화의 차이나 CMMI 적용 방식의 차이 등에서 기인할 수 있다.

9. 결론 및 향후 발전 방향

CMM/CMMI는 본래 국방 조직이 소프트웨어 하청업체의 역량을 평가하기 위한 기준으로 개발되었다. 이를 통해 하청업체가 정해진 기한과 예산 내에서 요구되는 품질 수준의 소프트웨어를 납품할 수 있는지 검증하고 기술하는 데 성공적으로 기여해왔다.^[1] CMMI는 조직의 소프트웨어 개발 성숙도를 객관적으로 평가하는 기준으로 자리 잡았으며, 특히 아웃소싱이나 소프트웨어 개발 외주 시 중요한 판단 도구로 활용된다. 인도, 아일랜드, 이집트 등 여러 국가에서는 CMMI를 자국 기업이 미국 등 선진국의 아웃소싱 계약을 확보하는 데 유리한 기준으로 평가하기도 한다.^[2]

CMMI는 단순히 평가 기준을 넘어 조직 차원의 프로세스 개선을 위한 효과적인 틀을 제공한다. 기업은 CMMI를 활용하여 자체적인 프로세스 개선 계획의 우선순위를 설정하고 체계적으로 관리할 수 있다.^[3] 개선 초기 단계인 성숙도 레벨 2부터 측정 지표를 활용한 분석을 시작하며, 이를 바탕으로 조직의 비즈니스 목표 달성에 기여하는 실질적인 개선 활동을 추진할 수 있다. 특히 성숙도 레벨 4, 5와 같은 높은 단계에서는 개선 활동의 효과를 정량적으로 파악하고 관리하는 것이 가능하다.^[4]

CMMI 평가 과정에는 해당 조직의 구성원들이 평가팀으로 직접 참여하는 것이 특징이다. 이를 통해 조직의 실제 상황에 맞는 정확한 평가 결과를 도출할 수 있으며, 평가에 참여한 구성원들은 프로세스 개선에 대한 이해도를 높이고 향후 조직 내 개선 활동에서 핵심적인 역할을 수행할 인재로 성장하는 기회를 얻게 된다.^[5] 결과적으로 CMMI는 조직의 프로세스 관리 능력을 향상시키고 경쟁력을 강화하는 데 유용한 도구로 평가받고 있다.

참조

_[1] 웹사이트 CMMI Content Changes. Release: V3.0, 6 April 2023. https://cmmiinstitut[...] CMMI Institute
_[2] 웹사이트 Trademark Electronic Search System (TESS) http://tmsearch.uspt[...] 2016-12-21
_[3] 간행물 What is CMMI ? software.gsfc.nasa.g[...] NASA presentation 2008
_[4] 웹사이트 CMMI Institute - Home http://www.sei.cmu.e[...]
_[5] 웹사이트 CMMI V1.3: Summing up https://www.benlinde[...] 2011-01-10
_[6] 웹사이트 CMMI V1.3: Agile https://www.benlinde[...] 2010-11-20
_[7] 웹사이트 CMMI V1.3 Released: High Maturity Clarified https://www.benlinde[...] 2010-11-02
_[8] 웹사이트 CMMI V1.3: Deploying the CMMI https://www.benlinde[...] 2010-11-16
_[9] 웹사이트 CMMI Overview http://www.sei.cmu.e[...] Software Engineering Institute 2011-02-16
_[10] 웹사이트 CMMI Institute - Core Practice Areas, Categories, and Capability Areas https://www.cmmiinst[...] 2018-12-15
_[11] 웹사이트 CMMI V1.3 Process Areas https://www.benlinde[...] 2023-09-18
_[12] 웹사이트 SEI Web site http://sas.sei.cmu.e[...] 2007-02-06
_[13] 웹사이트 Standard CMMI Appraisal Method for Process Improvement (SCAMPISM) A, Version 1.2: Method Definition Document http://www.sei.cmu.e[...] Software Engineering Institute 2006-09-23
_[14] 웹사이트 Process Maturity Profile http://www.sei.cmu.e[...] 2011-02-16
_[15] 웹사이트 SEI Digital Library https://resources.se[...] 2024-02-09
_[16] 웹사이트 TSP Overview https://resources.se[...] 2010-09-13
_[17] 문서 Considering the Case for Security Content in CMMI for Services 2010-10
_[18] 문서 Security by Design with CMMI for Development, Version 1.3 2013-05
_[19] 웹사이트 CMMI Performance Results of CMMI http://www.sei.cmu.e[...] 2006-09-23
_[20] 웹사이트 Scrum and CMMI Level 5: The Magic Potion for Code Warriors http://jeffsutherlan[...]
_[21] 서적 Agile Development Conference (ADC'05) 2005-07-20
_[22] 웹사이트 CMMI Roadmaps https://resources.se[...] 2008-10-31
_[23] 웹사이트 CMMI V1.3: The CMMI Project roadmap https://www.benlinde[...] 2010-12-07
_[24] 웹사이트 CMMI V1.3: The CMMI Product and Product Integration roadmaps https://www.benlinde[...] 2010-12-14
_[25] 웹사이트 CMMI V1.3: The CMMI Process and Measurement roadmaps https://www.benlinde[...] 2010-12-28
_[26] 웹사이트 Using CMMI to Improve Earned Value Management https://resources.se[...] 2022-06-30
_[27] 웹사이트 Capability Maturity Model®Integration (CMMI®) Version 1.2 Overview http://www.sei.cmu.e[...] SEI 2006-10-28
_[28] 웹사이트 What is CMMI? - Worldwide Adoption http://www.sei.cmu.e[...] SEI 2006-10-28
_[29] 서적 Quality is Free http://www.wppl.org/[...] Mc Graw Hill 1979
_[30] 서적 Quality is Free (paperback) http://www.wppl.org/[...] Mc Graw Hill 1980
_[31] 웹사이트 August 2002 edition of CMMI http://www.sei.cmu.e[...] SEI 2006-10-28
_[32] 웹사이트 A Software Process Immaturity Model http://www.cs.ucl.ac[...] University College London 2006-10-28
_[33] 웹사이트 The Capability Im-Maturity Model http://www.stsc.hill[...] The Air Force Institute of Technology 2006-10-28