#softwareengineering > [!abstract] Introduction > 이번 글에서는 대표적인 프로세스 표준 모델 중 하나인 CMMI*Capability Maturity Model Integration*에 대해 알아봅니다. # CMMI란? CMMI는 미국 카네기 멜론 대학의 부설 연구개발 센터인 소프트웨어 공학 연구소*Software Engineering Institute, SEI*에서 개발한 프로세스 표준 모델이다. 고객과 최종사용자의 니즈를 충족시키는 품질있는 제품과 서비스를 개발하는 활동에 초점을 둔 베스트 프랙티스의 집합이며, 2016년 ISACA*Information Systems Audit and Control Association*가 CMMI 연구소를 인수한 이후로는 ISACA가 이 모델을 발전시켜 현재는 CMMI v3.0까지 개발된 상태다. # Maturity CMMI를 이해하기 위해서는 우선 성숙도*Maturity*라는 개념부터 알아야 한다. 소프트웨어 공학에서 말하는 성숙도는 조직에 적용되는 개념이며, 따라서 미성숙한 조직이 있고 성숙한 조직이 있다. 그렇다면 두 조직의 차이는 무엇일까? ## 미성숙한 조직 vs 성숙한 조직 미성숙한 조직은 프로세스가 불안정하고 반복적이지 못하다. 따르기로 한 프로세스도 종종 무시되며, 일정이나 예산 계획도 비현실적이라 실현 가능성이 낮다. 납기일에 쫓기다 보니 제품의 품질을 희생할 수 밖에 없어 품질을 예측할 수가 없으며, 객관적으로 품질을 측정하는 기준이 없다. 반면 성숙한 조직은 계획에 따라 실제 작업을 수행한다. 정의된 프로세스와 그 프로세스가 실제로 이행된 모습이 일치하며, 따라서 사람이 바뀌면 프로세스도 바뀐다. 구성원 각자의 역할과 책임이 잘 정의되어 있고 관련 그룹 간 의사소통과 협력이 활발하게 이루어진다. 그리고 무엇보다 경영층이 관심을 가지고 조직을 지원*commit*한다. # CMMI의 5가지 성숙도 레벨 CMMI는 바로 이 성숙도를 제시하는 모델이다. v1.3을 기준으로 CMMI는 조직의 프로세스 성숙도를 Initial - Managed - Defined - Quantitatively Managed - Optimizing의 다섯 단계로 구분한다. ![[CMMIOrganizationalMaturityLevels.png]] CMMI는 조직의 프로세스 성숙도를 5단계로 구분한다. 각 레벨은 이전 레벨의 특성을 포함하며, 단계적으로 조직의 프로세스 역량을 향상시키는 구조로 설계되어 있다. 이러한 단계적 접근은 조직이 현실적으로 달성 가능한 목표를 설정하고, 지속적인 개선을 이루어갈 수 있도록 돕는다. ## Level 1: Initial (초기) 레벨 1은 조직의 프로세스가 임시방편적이고 예측 불가능한 상태를 의미한다. 이 단계의 조직은 정형화된 프로세스 없이 개인의 역량과 경험에 의존하여 프로젝트를 수행한다. ![[CMMAManagementViewofVisibility.png]] ### 주요 특징 레벨 1 조직에서는 프로세스가 체계적으로 정의되어 있지 않다. 프로젝트의 성공 여부는 개발자나 프로젝트 매니저의 개인적 능력에 크게 좌우되며, 같은 상황이 반복되더라도 매번 다른 방식으로 접근하는 경우가 많다. 일정과 예산은 자주 초과되고, 품질은 일관성이 없다. 프로젝트가 위기 상황에 처하면 계획된 프로세스마저도 포기하고 즉흥적으로 대응하는 경우가 빈번하다. ### 실무 시나리오 중소 스타트업 A사를 예로 들어보자. 이 회사는 모바일 앱 개발 프로젝트를 진행하고 있다. 프로젝트 초기에 간단한 요구사항 문서를 작성했지만, 개발 과정에서 고객의 요구사항이 변경될 때마다 체계적인 변경관리 없이 바로 코드를 수정한다. 어떤 개발자는 Git을 사용하지만, 다른 개발자는 여전히 이메일로 코드를 주고받는다. 테스트는 출시 직전에 급하게 진행되며, 버그가 발견되면 야근으로 해결한다. 프로젝트가 성공하더라도 그 경험이 문서화되지 않아 다음 프로젝트에서 같은 실수가 반복된다. ### 레벨 2로 이동하기 위한 실무 적용 방법 레벨 1에서 벗어나기 위해서는 먼저 현재 상태를 정직하게 진단해야 한다. 조직은 다음과 같은 기본적인 프로젝트 관리 프로세스를 도입해야 한다. 1. 요구사항 관리 프로세스를 수립한다. 모든 요구사항을 문서화하고, 변경사항을 추적할 수 있는 시스템을 마련한다. 간단한 스프레드시트나 이슈 트래킹 도구를 활용할 수 있다. 2. 프로젝트 계획 수립 프로세스를 정립한다. 프로젝트 시작 전에 작업 범위, 일정, 예산, 필요한 자원을 명확히 정의하고 문서화한다. 이때 과거 프로젝트의 데이터가 있다면 이를 참고하여 보다 현실적인 계획을 수립할 수 있다. 3. 기본적인 형상관리 체계를 구축한다. Git이나 SVN과 같은 버전 관리 시스템을 도입하고, 모든 팀원이 이를 사용하도록 교육한다. 4. 공급업체 관리나 하청 관리가 필요한 경우 계약 조건과 작업 범위를 명확히 정의하는 프로세스를 마련한다. 이러한 기본 프로세스를 도입하면서 중요한 것은 너무 복잡하게 시작하지 않는 것이다. 조직의 규모와 상황에 맞는 경량화된 프로세스로 시작하여 점차 정교화하는 것이 현실적이다. ## Level 2: Managed (관리) 레벨 2는 프로젝트 수준에서 기본적인 관리 프로세스가 확립된 상태를 의미한다. 이 단계에서 조직은 프로젝트의 요구사항, 일정, 비용, 품질을 관리할 수 있는 능력을 갖추게 된다. ![[CMMAManagementViewofVisibility.png]] ### 주요 특징 레벨 2 조직은 프로젝트 계획을 수립하고 이를 기반으로 프로젝트를 추적하며 관리한다. 요구사항 변경이 발생하면 체계적으로 검토하고 승인하는 프로세스를 따르며, 이해관계자들과 정기적으로 커뮤니케이션한다. 프로젝트 진행 상황이 계획과 크게 벗어날 때는 조기에 이를 감지하고 시정 조치를 취할 수 있다. 하지만 이 단계의 프로세스는 아직 프로젝트마다 다를 수 있으며, 조직 전체에 표준화되어 있지는 않다. ### 실무 시나리오 B사는 레벨 1에서 레벨 2로 성장한 중견 소프트웨어 개발 회사다. 최근 대형 전자상거래 플랫폼 개발 프로젝트를 수주했다. 프로젝트가 시작되기 전, 프로젝트 매니저는 고객과 함께 상세한 요구사항 문서를 작성하고, 모든 요구사항에 우선순위를 매긴다. 이를 기반으로 6개월의 개발 일정을 수립하고, 각 단계별 마일스톤과 검증 기준을 명확히 정의한다. 개발이 진행되는 동안 매주 프로젝트 상태 회의를 열어 진척도를 검토한다. 3개월차에 고객이 결제 시스템에 대한 추가 요구사항을 제시했을 때, B사는 변경영향분석을 수행하여 일정과 비용에 미치는 영향을 산정하고, 고객의 승인을 받은 후 프로젝트 계획을 업데이트한다. 모든 소스코드는 Git으로 관리되며, 주요 변경사항은 코드리뷰를 거친다. 품질보증팀은 각 스프린트가 끝날 때마다 테스트를 수행하고 결과를 문서화한다. 프로젝트는 예정보다 2주 지연되었지만, 조기에 위험을 식별하고 대응했기 때문에 큰 혼란 없이 완료되었다. B사는 이 프로젝트의 경험을 정리하여 다음 프로젝트에 참고할 수 있는 데이터를 축적하기 시작했다. ### 레벨 3으로 이동하기 위한 실무 적용 방법 레벨 2에서 레벨 3으로 성장하려면 개별 프로젝트에서 잘 작동하는 프로세스를 조직 전체의 표준 프로세스로 발전시켜야 한다. 1. 조직 표준 프로세스를 정의한다. 여러 프로젝트에서 성공적으로 사용된 프로세스를 분석하고, 조직의 특성에 맞는 표준 개발 프로세스를 문서화한다. 이 프로세스는 모든 프로젝트의 출발점이 되지만, 각 프로젝트의 특성에 맞게 조정*tailoring*할 수 있어야 한다. 2. 조직 프로세스 자산 라이브러리를 구축한다. 과거 프로젝트의 산출물, 교훈, 측정 데이터, 재사용 가능한 컴포넌트 등을 체계적으로 저장하고 관리한다. 위키나 공유 저장소를 활용할 수 있다. 3. 통합된 프로젝트 관리 체계를 수립한다. 프로젝트 계획, 모니터링, 위험관리가 표준 프로세스에 따라 일관되게 수행되도록 한다. 4. 교육 프로그램을 체계화한다. 신입 직원이나 새로운 프로젝트에 투입되는 인력이 조직의 표준 프로세스를 학습할 수 있는 교육 과정을 마련한다. 5. 조직 차원의 측정 및 분석 체계를 구축한다. 생산성, 품질, 일정 준수율 등의 지표를 정의하고, 프로젝트들로부터 일관된 방식으로 데이터를 수집한다. 이 과정에서 중요한 것은 프로세스가 너무 경직되지 않도록 하는 것이다. 표준 프로세스는 각 프로젝트의 특성에 맞게 조정할 수 있는 유연성을 제공해야 하며, 프로세스 개선을 위한 피드백 채널을 마련해야 한다. ## Level 3: Defined (정의) 레벨 3은 조직 전체에 표준화되고 문서화된 프로세스가 확립되어, 모든 프로젝트가 이를 기반으로 일관되게 수행되는 단계다. 개별 프로젝트는 조직의 표준 프로세스를 프로젝트 특성에 맞게 조정하여 사용한다. ![[CMMAManagementViewofVisibility.png]] ### 주요 특징 레벨 3 조직은 조직 차원의 표준 프로세스 세트를 보유하고 있다. 이 프로세스들은 명확하게 정의되고 문서화되어 있으며, 지속적으로 개선된다. 각 프로젝트는 이 표준 프로세스를 기반으로 자신만의 정의된 프로세스를 수립한다. 조직은 과거 프로젝트의 경험과 데이터를 체계적으로 관리하며, 이를 새로운 프로젝트 계획 수립에 활용한다. 엔지니어링 활동도 표준화되어 설계, 개발, 테스트 프로세스가 일관되게 수행된다. ### 실무 시나리오 C사는 금융 소프트웨어를 전문으로 개발하는 100명 규모의 기업이다. C사는 지난 5년간 축적한 경험을 바탕으로 "C사 표준 개발 프로세스"를 정립했다. 이 프로세스는 요구사항 분석, 아키텍처 설계, 상세 설계, 구현, 통합 테스트, 시스템 테스트, 배포의 7단계로 구성되어 있으며, 각 단계마다 필수 산출물, 검토 기준, 품질 게이트가 명확히 정의되어 있다. 새로운 인터넷뱅킹 시스템 개발 프로젝트가 시작될 때, 프로젝트 팀은 조직의 표준 프로세스를 검토하고, 이 프로젝트의 특성을 고려하여 조정한다. 예를 들어, 보안 요구사항이 특히 중요하므로 각 단계에 보안 검토 활동을 추가하고, 외부 보안 전문가의 검증을 받는 절차를 포함시킨다. 이러한 조정 사항은 프로젝트 계획서에 명시되고, 조직의 프로세스 그룹에서 승인한다. 개발 중 팀은 조직의 재사용 컴포넌트 라이브러리에서 인증 모듈과 로깅 프레임워크를 찾아 활용한다. 이전 프로젝트에서 검증된 컴포넌트를 사용함으로써 개발 시간을 단축하고 품질을 향상시킨다. 프로젝트가 진행되는 동안 팀은 표준 프로세스에 따라 각 단계별로 동료 리뷰를 수행하며, 주요 마일스톤마다 품질 게이트 리뷰를 거친다. 프로젝트 종료 시점에 팀은 프로젝트 회고를 진행하고, 이 과정에서 발견한 개선사항을 조직의 프로세스 그룹에 제안한다. 특히 보안 검토 절차가 효과적이었다는 평가에 따라, 이 절차가 조직의 표준 프로세스에 반영되어 향후 금융 프로젝트에서 활용된다. ### 레벨 4로 이동하기 위한 실무 적용 방법 레벨 3에서 레벨 4로 발전하려면 정성적 프로세스 관리에서 정량적 프로세스 관리로 전환해야 한다. 1. 조직의 품질 및 프로세스 성과 목표를 정량적으로 정의한다. 예를 들어 "출시 후 3개월 내 심각한 결함 발생률을 1000라인당 0.1개 이하로 유지"하거나 "일정 준수율 95% 이상 달성"과 같은 구체적인 수치 목표를 설정한다. 2. 프로세스 성과 기준선과 모델을 수립한다. 과거 프로젝트 데이터를 통계적으로 분석하여 조직의 프로세스가 정상적으로 작동할 때의 성과 범위를 파악한다. 이를 통해 어떤 프로젝트가 기준선에서 벗어나고 있는지 조기에 감지할 수 있다. 3. 통계적 프로세스 제어 기법을 도입한다. 관리도*control chart*와 같은 통계 도구를 활용하여 프로세스 성과를 모니터링하고, 정상 범위를 벗어나는 변동이 발생하면 원인을 분석하고 시정한다. 4. 측정 데이터의 품질을 보장하는 체계를 구축한다. 데이터 수집, 저장, 분석의 일관성을 유지하고, 측정의 정확성과 신뢰성을 검증하는 프로세스를 마련한다. 5. 예측 모델을 개발한다. 과거 데이터를 기반으로 프로젝트의 일정, 비용, 품질을 예측할 수 있는 통계적 모델을 구축하고, 이를 프로젝트 계획 수립과 의사결정에 활용한다. 이 전환은 조직에 상당한 도전이 될 수 있다. 충분한 양의 신뢰할 수 있는 데이터가 축적되어 있어야 하고, 조직 구성원들이 통계적 사고방식을 갖추어야 하며, 측정과 분석에 투자할 자원이 필요하기 때문이다. ## Level 4: Quantitatively Managed (정량적 관리) 레벨 4는 프로세스가 통계적 기법을 사용하여 정량적으로 관리되는 단계다. 조직은 프로세스 성과를 측정하고 예측할 수 있으며, 데이터 기반으로 의사결정을 내린다. ![[CMMAManagementViewofVisibility.png]] ### 주요 특징 레벨 4 조직은 프로세스 성과와 제품 품질에 대한 정량적 목표를 설정하고, 이를 달성하기 위해 프로세스를 관리한다. 주요 프로세스의 성과는 통계적으로 예측 가능한 수준이며, 예상 범위를 벗어나는 변동이 발생하면 특수 원인을 찾아 제거한다. 프로젝트는 정량적 목표와 계획에 따라 관리되며, 프로세스 성과 데이터를 기반으로 위험을 조기에 식별하고 완화한다. ### 실무 시나리오 D사는 임베디드 시스템 소프트웨어를 개발하는 대기업이다. 지난 10년간 100개 이상의 프로젝트 데이터를 축적해왔으며, 이를 기반으로 정량적 관리 체계를 구축했다. 새로운 자동차 인포테인먼트 시스템 개발 프로젝트를 시작하면서, D사는 과거 유사 프로젝트의 데이터를 분석하여 이 프로젝트의 품질 목표를 설정한다. "코드 리뷰 단계에서 발견되는 결함 밀도는 1000라인당 4.2개 이상, 통합 테스트에서 발견되는 결함은 1000라인당 1.5개 이하"와 같은 구체적인 수치 목표를 정의한다. 이러한 목표는 과거 데이터의 평균과 표준편차를 고려하여 설정된 것이다. 프로젝트가 진행되는 동안 매주 주요 프로세스 성과 지표를 측정하고 관리도에 표시한다. 개발 4개월차에 코드 리뷰에서 발견되는 결함 밀도가 급격히 낮아지는 것을 관찰한다. 통계적으로 정상 범위를 벗어난 것으로 판단되어 원인 분석에 착수한다. 조사 결과 새로 투입된 외주 개발자들이 코딩 표준을 제대로 이해하지 못해 낮은 품질의 코드를 작성하고 있었고, 리뷰어들이 이를 제대로 걸러내지 못하고 있었다는 것을 발견한다. 즉시 시정 조치로 외주 개발자들에게 집중 교육을 실시하고, 리뷰 프로세스에 체크리스트를 추가했다. 2주 후 결함 밀도가 정상 범위로 돌아왔고, 이후 프로젝트는 안정적으로 진행되었다. 출시 후 6개월간 필드에서 발견된 결함은 목표치인 1000라인당 0.08개보다 낮은 0.06개를 기록했다. 프로젝트 종료 후 팀은 이번 프로젝트의 성과 데이터를 조직의 프로세스 성과 기준선에 추가하고, 외주 인력 투입 시 초기 교육을 강화하는 것을 표준 프로세스에 반영했다. ### 레벨 5로 이동하기 위한 실무 적용 방법 레벨 4에서 레벨 5로 성장하려면 단순히 프로세스를 관리하는 것을 넘어, 지속적으로 혁신하고 최적화하는 문화를 구축해야 한다. 1. 조직의 전략적 비즈니스 목표와 프로세스 개선을 연계한다. 시장 경쟁력 강화, 고객 만족도 향상, 출시 시간 단축 등 조직의 비즈니스 목표를 달성하기 위해 어떤 프로세스를 어떻게 개선해야 하는지 체계적으로 분석한다. 2. 혁신적인 프로세스 개선을 시범 적용하고 효과를 정량적으로 평가하는 체계를 마련한다. 새로운 개발 방법론, 도구, 기술을 도입할 때 파일럿 프로젝트에서 먼저 시도하고, 측정 데이터를 기반으로 개선 효과를 검증한다. 3. 결함의 근본 원인을 체계적으로 분석하고 예방하는 메커니즘을 구축한다. 단순히 결함을 수정하는 것이 아니라, 왜 그런 결함이 발생했는지 프로세스 수준에서 분석하고, 유사한 결함이 재발하지 않도록 프로세스를 개선한다. 4. 지속적 학습과 개선의 문화를 조성한다. 실패를 처벌하지 않고 학습의 기회로 삼으며, 개선 제안을 장려하고 보상하는 제도를 운영한다. 5. 전사적으로 개선 활동을 조정하고 우선순위를 관리하는 체계를 수립한다. 제한된 자원을 가장 효과적인 개선 활동에 집중 투자할 수 있도록 한다. ## Level 5: Optimizing (최적화) 레벨 5는 조직이 지속적인 프로세스 개선에 집중하며, 혁신적 기술과 아이디어를 적극적으로 도입하여 조직의 목표 달성을 최적화하는 단계다. ![[CMMAManagementViewofVisibility.png]] ### 주요 특징 레벨 5 조직은 정량적 데이터를 기반으로 프로세스의 약점을 식별하고 지속적으로 개선한다. 결함과 문제의 근본 원인을 분석하여 재발을 예방하는 체계적인 메커니즘을 갖추고 있다. 새로운 기술, 방법론, 도구를 시험하고 도입하는 것을 조직 문화의 일부로 만들며, 이러한 혁신이 비즈니스 목표 달성에 기여하는지 정량적으로 평가한다. 프로세스 개선은 단순히 반응적으로 문제를 해결하는 것이 아니라, 선제적으로 기회를 찾고 조직의 역량을 지속적으로 향상시킨다. ### 실무 시나리오 E사는 클라우드 기반 SaaS 제품을 개발하는 글로벌 기업으로, 1000명 이상의 개발자가 근무하고 있다. E사는 지난 15년간 CMMI 여정을 거쳐 레벨 5에 도달했으며, 지속적 개선을 조직 DNA의 핵심으로 삼고 있다. E사의 프로세스 개선 그룹은 매 분기마다 전사 프로세스 성과 데이터를 분석한다. 최근 분석에서 특정 유형의 보안 취약점이 반복적으로 발견되고 있다는 것을 파악했다. 근본 원인 분석 결과, 개발자들이 입력 검증을 구현할 때 일관된 패턴을 따르지 않고 있으며, 코드 리뷰에서도 이를 효과적으로 감지하지 못하고 있다는 것을 확인했다. 이에 대응하여 E사는 세 가지 개선 활동을 시작했다. 첫째, 입력 검증을 위한 공통 라이브러리를 개발하여 개발자들이 안전한 방식으로 쉽게 입력을 검증할 수 있도록 했다. 둘째, 정적 분석 도구를 CI/CD 파이프라인에 통합하여 코드가 커밋될 때마다 자동으로 보안 취약점을 검사하도록 했다. 셋째, 코드 리뷰 체크리스트에 보안 검토 항목을 강화했다. 이러한 개선사항을 3개 팀에서 3개월간 파일럿으로 시험했다. 측정 데이터를 분석한 결과, 입력 검증 관련 결함이 87% 감소했고, 개발자들의 만족도도 향상되었다는 것을 확인했다. 투자 대비 효과가 검증되자 이 개선사항을 전사에 확대 적용하기로 결정했다. 동시에 E사는 AI 기반 코드 리뷰 도구의 효과를 평가하기 위한 실험도 진행하고 있다. 일부 팀에서 AI 도구를 시험 사용하며, 리뷰 시간 단축과 결함 발견율 향상 효과를 정량적으로 측정하고 있다. 이러한 데이터를 바탕으로 전사 도입 여부를 결정할 예정이다. E사는 또한 DevOps 성숙도를 높이기 위해 지속적으로 배포 파이프라인을 개선하고 있다. 작년에는 배포 빈도를 주 1회에서 일 1회로 증가시켰으며, 배포 실패율은 오히려 5%에서 2%로 감소했다. 이는 자동화된 테스트와 배포 프로세스 개선의 결과다. ### 레벨 5 조직의 지속 가능성 유지 방법 레벨 5에 도달했다고 해서 여정이 끝난 것은 아니다. 이 수준을 유지하고 더욱 발전시키려면 지속적인 노력이 필요하다. 1. 개선 문화를 유지하기 위한 리더십의 지속적인 관심과 지원이 필수적이다. 경영진은 단기적 실적 압박 속에서도 장기적 프로세스 개선에 투자하는 결단을 내려야 한다. 2. 외부 환경 변화에 민첩하게 대응해야 한다. 새로운 기술 트렌드, 고객 요구사항의 변화, 경쟁 환경의 변화를 지속적으로 모니터링하고, 이에 따라 프로세스를 진화시켜야 한다. 3. 측정과 분석의 정교함을 계속 높여야 한다. 더 정확한 예측 모델, 더 빠른 피드백 루프, 더 세밀한 성과 분석이 가능하도록 측정 체계를 발전시킨다. 4. 지식 관리를 강화해야 한다. 조직이 축적한 프로세스 개선 경험과 노하우가 체계적으로 문서화되고 공유되어, 새로운 구성원도 빠르게 학습하고 기여할 수 있도록 한다. 5. 다른 조직들과의 벤치마킹과 협력을 통해 새로운 아이디어를 얻고, 조직의 강점을 객관적으로 평가한다. # CMMI 도입 시 주의사항 CMMI를 조직에 도입할 때는 몇 가지 중요한 사항을 고려해야 한다. ## 점진적 접근 가장 중요한 것은 점진적으로 접근하는 것이다. 레벨 1 조직이 갑자기 레벨 3을 목표로 한다면 조직 구성원들의 저항과 혼란을 초래할 수 있다. 현재 수준을 정확히 파악하고, 한 단계씩 착실히 발전하는 것이 현실적이다. 각 레벨의 프랙티스를 충분히 내재화한 후 다음 단계로 나아가야 한다. ## 형식보다 실질 CMMI 인증 자체를 목표로 삼는 함정에 빠지지 않도록 주의해야 한다. 인증을 받기 위해 형식적으로 문서를 작성하고 프로세스를 만들지만, 실제 프로젝트 수행에는 적용하지 않는 "두 가지 프로세스" 문제가 발생할 수 있다. 프로세스는 조직의 실제 업무 방식을 개선하기 위한 도구여야 하며, 인증은 그 결과로 따라오는 부산물이어야 한다. ## 조직 특성에 맞는 조정 CMMI는 프레임워크이지 엄격한 규칙이 아니다. 조직의 규모, 산업 특성, 문화, 비즈니스 목표에 맞게 프랙티스를 조정하고 해석해야 한다. 10명의 스타트업과 1000명의 대기업이 동일한 방식으로 CMMI를 적용할 수는 없다. 핵심 원칙은 유지하되, 구현 방식은 유연하게 접근해야 한다. ## 사람과 문화 프로세스 개선의 핵심은 사람이다. 아무리 훌륭한 프로세스를 정의해도 구성원들이 그 가치를 이해하고 자발적으로 따르지 않으면 성공할 수 없다. 프로세스 도입 과정에서 충분한 교육과 의사소통이 필요하며, 구성원들의 피드백을 적극적으로 수렴하여 프로세스를 개선해야 한다. 프로세스가 업무를 돕는 도구가 아니라 방해하는 장애물로 인식되면 실패한 것이다. ## 균형 잡힌 접근 프로세스의 엄격함과 민첩성 사이의 균형을 찾아야 한다. 과도하게 엄격한 프로세스는 조직의 유연성을 저해하고 변화에 대한 대응력을 떨어뜨릴 수 있다. 특히 빠르게 변화하는 시장 환경에서는 프로세스의 안정성과 함께 변화에 대한 적응력도 중요하다. 애자일 방법론과 CMMI를 통합하는 시도들이 이러한 균형을 찾기 위한 노력의 일환이다. ## 측정의 목적 프로세스 성과를 측정하는 것은 통제하기 위함이 아니라 개선하기 위함이다. 측정 데이터를 개인의 성과 평가나 처벌의 근거로 사용하면, 구성원들은 정확한 데이터를 보고하지 않거나 숫자를 조작하려는 유혹에 빠질 수 있다. 측정은 조직 전체가 현재 상태를 객관적으로 파악하고 개선 방향을 찾기 위한 도구여야 한다. # 마치며 ![[CMMProcessCapability.png]] CMMI는 조직이 프로세스 성숙도를 체계적으로 향상시킬 수 있도록 돕는 강력한 프레임워크다. 레벨 1의 혼란스러운 상태에서 시작하여, 프로젝트 관리가 가능한 레벨 2, 조직 표준이 확립된 레벨 3, 정량적 관리가 가능한 레벨 4, 그리고 지속적 최적화의 레벨 5까지, 각 단계는 조직의 역량을 한 차원 높이는 여정이다. 하지만 CMMI는 만능 해결책이 아니다. 조직의 상황과 필요에 맞게 적절히 적용해야 하며, 프로세스 자체가 목적이 되어서는 안 된다. 궁극적인 목표는 고객에게 더 나은 가치를 제공하고, 조직의 비즈니스 목표를 달성하는 것이다. CMMI는 그 목표를 달성하기 위한 수단이며, 조직의 지속 가능한 성장을 지원하는 도구다. CMMI를 이제 막 도입하려는 조직이라면, 현재 위치를 정확히 파악하고 작은 개선부터 시작하여 점진적으로 발전해나가는 것이 성공 확률을 높여줄 것이다. 그 과정에서 구성원들의 참여와 공감을 이끌어내고, 개선의 효과를 측정하고 공유하며, 실패로부터 배우는 문화를 만들어가는 것이 성공의 열쇠다. --- # 출처 - Jalote, P. (2000) _CMM in practice: processes for executing software projects at Infosys_. Reading, Mass Bonn: Addison-Wesley (SEI series in software engineering). - Paulk, M.C. _et al._ (1993) _Capability Maturity Model for Software, Version 1.1:_ Fort Belvoir, VA: Defense Technical Information Center. Available at: [https://doi.org/10.21236/ADA263403](https://doi.org/10.21236/ADA263403).