다음을 통해 공유

CMMI의 배경

  • 아티클

Software Engineering Institute에서는 CMMI(Capability Maturity Model Integration) for Development에 대한 이해를 돕기 위해 "CMMI: Guidelines for Process Integration and Product Improvement"라는 책을 발행했습니다. 이 책에서는 작성 당시 최신 CMMI 제품군 내의 모델 중 하나인 CMMI-DEV(CMMI for Development) 버전 1.2에 대해 구체적으로 설명하고 있습니다. 이 모델은 매우 안정적이며 2010년 현재뿐 아니라 앞으로도 계속 통용될 것입니다. "CMMI Distilled: A Practical Introduction to Integrated Process Improvement"도 이 주제를 다루는 유용하고 이해하기 쉬운 책입니다. 이 두 책에 대한 자세한 내용은 이 항목 뒷부분의 추가 리소스를 참조하십시오.

CMMI는 1987년 Carnegie-Mellon 대학의 연구 센터인 Software Engineering Institute의 한 프로젝트였던 CMM(Capability Maturity Model)이라는 이름으로 처음 도입되었습니다. 이 센터는 미국 국방부의 자금으로 설립되어 운영되고 있습니다. 1991년에 처음 발표된 CMM for Software는 70년대 말과 80년대 초에 수행된 소프트웨어 개발 프로젝트의 주요 성공 요인을 정리한 검사 목록을 기반으로 합니다. 이 모델은 IBM(International Business Machines) Corporation의 연구소와 20세기의 품질 보증 선도자인 Philip Crosby 및 W. Edwards Deming에 의해서도 알려졌습니다. Capability Maturity Model이라는 이름과 이 항목 뒷부분에서 설명하는 계층적 표현(Staged Representation)의 다섯 가지 수준은 모두 Crosby의 Manufacturing Maturity Model에서 비롯된 것입니다. 주로 국방 프로그램에 적용되었던 CMM은 상당히 많은 프로젝트에서 채택되면서 여러 번의 수정과 반복을 거쳤습니다. 또한 그 성공적인 결과 덕분에 소프트웨어를 넘어선 다양한 분야에서 CMM을 개발하기에 이르렀습니다. 새로운 모델이 급증하여 혼란을 야기하자 미국 정부에서는 200명 이상의 업계 및 학계 전문가가 참여하는 2년 기간의 프로젝트에 자금을 지원하여 시스템 엔지니어링, 소프트웨어 엔지니어링 및 제품 개발을 통합한 확장 가능한 단일 프레임워크를 만들었습니다. 그 결과로 탄생한 것이 CMMI입니다.

CMMI-DEV에 관하여 알아야 할 가장 중요한 점은 이것이 모델이라는 점입니다. 즉 CMMI는 따라야 할 절차나 규칙이 아니라, 단지 소프트웨어 개발 및 시스템 엔지니어링에 있어서 가치가 있다고 입증된 일련의 조직적인 동작입니다. 이러한 모델을 사용하는 이유는 무엇일까요? 또한 그 목적은 무엇이며 이를 가장 잘 활용하는 방법은 무엇일까요? 이러한 질문은 CMMI와 관련된 중요한 내용이면서도 어쩌면 가장 오해하기 쉬운 내용이기도 합니다.

항목 내용

  • 모델을 사용하는 이유

  • CMMI 모델의 목적

  • CMMI 모델을 사용하는 가장 좋은 방법

  • CMMI 모델의 요소

  • 추가 리소스

모델을 사용하는 이유

조직의 작업 방식, 조직에 필요한 기능 및 이러한 기능 간의 상호 작용 방식에 대한 모델이 없다면 작업을 개선하기가 어렵습니다. 모델을 사용하면 조직의 산재하는 요소들을 올바르게 이해하고 개선이 필요한 사항과 이러한 개선을 달성할 수 있는 방법에 대한 의사 소통 및 토론을 체계화할 수 있습니다. 모델은 다음과 같은 이점을 제공합니다.

  • 의사 소통을 돕는 일반적인 프레임워크 및 언어를 제공합니다.

  • 수년 동안의 경험을 활용할 수 있게 해 줍니다.

  • 거시적인 안목을 유지하면서 개선에 특히 중점을 둘 수 있도록 합니다.

  • 대개 교육 담당자 및 컨설턴트의 지원을 받을 수 있습니다.

  • 불일치 문제를 해결하는 데 유용한 표준을 제공할 수 있습니다.

CMMI 모델의 목적

책에서는 모델의 목적이 조직의 프로세스 완성도를 평가하고 향상된 제품을 얻을 수 있도록 프로세스를 개선하는 데 관한 지침을 제공하는 것이라고 설명합니다. 하지만 Software Engineering Institute에 속한 사람이라면 CMMI가 위험 관리를 위한 모델이며 조직의 위험 관리 능력을 나타내는 지표라고 설명할 것입니다. 이러한 지표는 조직이 약속을 이행하거나 시장의 관심을 끄는 고품질의 제품을 제공할 수 있는 가능성에 대한 증거입니다. 이를 달리 생각하면 모델은 문제 상황에서 조직의 업무 수행 능력을 나타내는 좋은 지표를 제공한다고 할 수 있습니다. 완성도나 업무 수행 능력이 높은 조직에서는 예기치 않은 문제 상황을 수월하게 뛰어 넘고 적절하게 대처, 변화 및 전진합니다. 반면 완성도나 업무 수행 능력이 낮은 조직은 문제 상황에서 혼란에 빠지거나, 기존의 해결 과정을 맹목적으로 따르거나, 모든 프로세스를 포기하고 무리한 긴축으로 대혼란에 빠지는 경향이 있습니다.

CMMI가 조직의 경제적 성과를 나타내기에 적합한 지표라고 입증되지는 않았습니다. 완성도가 높은 조직일수록 위험 관리 능력이나 예측 능력이 뛰어나지만 완성도가 높은 기업이 위험 회피 성향을 보인다는 증거가 있습니다. 위험을 회피한다면 혁신이 불가능하거나, 준비 기간을 연장시키고 경쟁을 없애는 관료적 성향이 강하다는 것을 나타냅니다. 완성도가 낮은 기업일수록 보다 혁신적이고 창조적이지만 무질서하고 예측할 수 없는 경향이 있습니다. 성과를 얻더라도 개인이나 상급 직원의 영웅적인 노력으로 얻은 결과인 경우가 많습니다.

CMMI 모델을 사용하는 가장 좋은 방법

이 모델은 프로세스 개선을 위한 기준으로 사용하기 위해 개발되었으며, 개선도 측정을 위한 지원 시스템으로서 평가용으로만 개발되었습니다. 이러한 용도로 사용하여 얻은 결과는 성공적인 경우도 있고 그렇지 않은 경우도 있습니다. 이 모델을 프로세스 정의와 혼동하여, 기존 프로세스에서 해결해야 하는 문제를 나타낸 지도 대신 이 모델을 따르려고 하는 경우가 많습니다. CMMI의 기본 빌딩 블록은 목표 및 대개 목표를 충족하는 데 사용되는 몇 가지 작업을 정의하는 프로세스 영역입니다. 프로세스 영역의 한 가지 예로는 프로세스 및 제품 품질 보증이 있습니다. 구성 관리도 프로세스 영역의 예입니다. 프로세스 영역은 프로세스가 아니라는 점에 유의하십시오. 단일 프로세스가 여러 프로세스 영역에 해당할 수도 있고 개별 프로세스 영역이 여러 프로세스와 관련될 수도 있습니다.

CMMI-DEV는 실제로는 동일한 기본 요소를 공유하는 두 개의 모델입니다. 이 중 첫 번째이자 가장 익숙한 모델인 계층적 표현 모델에서는 다섯 가지 수준의 조직 완성도 중 하나에 매핑되는 22개의 프로세스 영역을 제시합니다. 조직 평가에서는 조직의 운영 수준을 평가하며 이 수준은 조직의 위험 관리 능력과 그에 따른 약속 이행 능력을 나타내는 지표가 됩니다.

CMMI 단계적 표현

수준 4 및 5는 대개 완성도가 높은 것으로 간주됩니다. 정량적 관리 및 최적화 성향을 보이는 높은 완성도의 조직과 관리만 되거나 정의된 프로세스를 따르고 있는 낮은 완성도의 조직 간에는 대개 분명한 차이가 있습니다. 높은 완성도의 조직에서는 프로세스의 변동성이 낮으며 대개 선행 지표를 통계적으로 방어 가능한 관리 방법의 일부로 사용합니다. 따라서 높은 완성도의 조직은 예측 능력이 뛰어날 뿐 아니라 다른 관료주의적인 장애가 없을 경우 새로운 정보에 대처하는 속도도 빠릅니다. 낮은 완성도의 조직이 매우 많은 노력을 기울이는 데 반해, 높은 완성도의 조직은 문제 발생 시에도 프로세스를 맹목적으로 따르느라 프로세스를 변경하는 것이 보다 적절한 대처임을 인식하지 못하는 수도 있습니다.

두 번째인 연속적 표현 모델에서는 22개의 각 프로세스 영역 내에서 개별적으로 프로세스 수행 능력을 모델링하므로, 조직에서는 개선 노력을 가장 높은 비즈니스 가치를 창출하는 프로세스에 맞출 수 있습니다. 연속적 표현이 Crosby의 원래 모델과 더 부합합니다. 이 모델을 토대로 평가를 수행하면 업무 수행 능력을 숫자 하나로 나타내는 것이 아니라 프로필로 나타낼 수 있습니다. 물론 조직의 완성도는 대부분의 관리직 및 경영자가 이해하는 수준이므로 연속적 모델 평가의 결과를 다섯 계층에 매핑하는 방법도 있습니다.

CMMI 연속 표현

계층적 모델을 프로세스 개선 프로그램의 기초로 사용할 경우 구현자가 CMMI는 프로세스 또는 워크플로 모델이 아니라 단지 프로세스 및 워크플로에서 달성할 목표를 제공한다는 것을 잊을 수 있으므로 위험합니다. 이러한 목표를 충족하는 것은 조직의 완성도와 프로세스가 계획한 대로 전개될 가능성을 향상시키는 것입니다. 아마도 가장 큰 실수는 단지 높은 완성도를 얻는 것만을 목적으로 프로세스와 인프라를 평가에 통과하기 쉽도록 단순하게 만드는 태도일 것입니다. 모든 프로세스 개선 활동의 목표는 단순한 수치가 아니라 실제로 측정 가능한 개선 결과여야 합니다.

연속적 모델은 프로세스 개선 지침으로 성공적인 것으로 보이며 일부 컨설팅 회사에서는 연속적 모델을 기반으로 한 지침만 제공하기로 선택하고 있습니다. 가장 분명한 차이점은 연속적 모델을 기반으로 고안된 프로세스 개선 프로그램에는 완성도로 한정되는 인위적인 목표가 없다는 점입니다. 또한 연속적 모델은 보다 본질적으로는 조직의 경제적 이득을 높여 줄 가능성이 큰 영역에서 프로세스 개선을 적용하는 데 유용합니다. 따라서 연속적 모델을 따르는 조직은 CMMI 모델을 기반으로 하는 사안에서 긍정적인 평가 결과를 받을 가능성이 높습니다. 더욱이 긍정적인 평가 결과는 뛰어난 개선 주기를 개발하는 원동력이 될 가능성이 높습니다.

CMMI 모델의 요소

CMMI 모델은 다음 표와 같이 22개의 프로세스 영역으로 나뉩니다.

약어

프로세스 영역

CAR

원인 분석 및 해결(Causal Analysis & Resolution)

CM

구성 관리(Configuration Management)

DAR

의사 결정 분석 및 해결(Decision Analysis & Resolution)

IPM

통합 프로젝트 관리(Integrated Project Management)

MA

측정 및 분석(Measurement & Analysis)

OID

조직 혁신 및 이행(Organizational Innovation & Deployment)

OPD

조직 프로세스 정의(Organizational Process Definition)

OPF

조직 프로세스 중점 관리(Organizational Process Focus)

OPP

조직 프로세스 성과(Organizational Process Performance)

OT

조직 교육(Organizational Training)

PI

제품 통합(Product Integration)

PMC

프로젝트 모니터링 및 통제(Project Monitoring & Control)

PP

프로젝트 계획(Project Planning)

PPQA

프로세스 및 제품 품질 보증(Process & Product Quality Assurance)

QPM

정량적 프로젝트 관리(Quantitative Project Management)

RD

요구 사항 정의(Requirements Definition)

REQM

요구 사항 관리(Requirements Management)

RSKM

위험 관리(Risk Management)

SAM

공급자 계약 관리(Supplier Agreement Management)

TS

기술 솔루션(Technical Solution)

VER

확인

VAL

유효성 검사

계층적 표현에서 이러한 프로세스 영역은 다음 그림에 표시된 것과 같이 각 계층에 매핑됩니다.

프로세스 영역이 표시된 단계 표현

연속적 표현에서 이러한 프로세스 영역은 다음 그림에 표시된 것과 같이 기능적 그룹으로 매핑됩니다.

프로세스 영역이 표시된 연속 표현

각 프로세스 영역은 필수 구성 요소, 기대 구성 요소 및 정보 구성 요소로 구성됩니다. 이 모델을 기준으로 한 평가를 만족시키는 데 실제로 필요한 것은 필수 구성 요소뿐입니다. 필수 구성 요소는 각 프로세스 영역의 구체적이고 일반적인 목표입니다. 기대 구성 요소는 각각의 구체적이거나 일반적인 목표를 달성하기 위한 구체적이고 일반적인 방법입니다. 기대 구성 요소는 단지 기대될 뿐 반드시 필요한 것은 아니므로 구체적이거나 일반적인 방법을 같은 종류의 다른 방법으로 대체할 수 있음을 나타냅니다. 기대 방법은 구현자와 평가자를 안내하는 용도로 사용됩니다. 대체 방법이 선택된 경우 평가자에게 조언하고 대체 방법이 적절한 이유를 설명하는 것은 구현자가 할 일입니다. 정보 구성 요소는 구현자가 CMMI 모델의 지침을 따르는 프로세스 개선 활동을 쉽게 시작할 수 있도록 세부 정보를 제공합니다. 정보 구성 요소에는 일반적이고 구체적인 방법의 세부 방법과 일반적인 작업 산출물이 포함됩니다.

일반적이고 구체적인 목표만이 필수 구성 요소라는 점을 이해하는 것은 매우 중요합니다. 그 밖의 모든 구성 요소는 안내 용도로 제공됩니다. CMMI 연구에서 제공되는 기대 구성 요소와 정보 구성 요소의 예는 대규모 우주 및 국방 시스템 통합 프로젝트에서 흔히 찾아볼 수 있습니다. 이러한 프로젝트는 Carnegie-Mellon 대학의 Software Engineering Institute를 후원 및 지원하는 업체에서 실행된 것입니다. 이러한 프로젝트는 개별 조직에서 맡은 프로젝트의 유형과 맞지 않을 수도 있고, Agile 소프트웨어 개발 방법의 출현과 같은 업계 최신 동향을 반영하지 않을 수도 있습니다.

추가 리소스

자세한 내용은 다음 웹 리소스를 참조하십시오.

참고 항목

개념

MSF for CMMI Process Improvement v5.0